A few weeks ago, I presented an overview of Jumpstart as a methodology for organizing software development as a continuous activity, and briefly outlined its key elements. In subsequent blogs, my colleagues Sashikanth, and Seshu Loka talked about the importance of aligning organizational structure with product lifecycle, and taking a strategic approach to product management respectively. In this blog, I would like to focus on the importance of having a lean, repeatable, and agile process encompassing the full spectrum of software lifecycle to ensure development and delivery of consistently high quality software.
Scrum is one of the most popular methodologies used for software development, derived from agile philosophy. Over the past 15 years, Scrum has achieved an impressive level of maturity and is successfully adopted by technology companies of all sizes ranging from start ups to major global enterprises. At its core, Scrum is an approach for iterative software development through small self-contained teams, achieving a clearly defined goal (functionality) in short bursts (typically 2-week sprints). Depending upon the organizational and product lifecycle stages, the roles and responsibilities associated with implementing Scrum vary significantly, which I will attempt to elaborate further in this blog.
In some ways this is the easiest phase for rolling out a simple, and practical Scrum implementation, as you will practically have a blank slate, and won’t be dealing with any legacy issues. At this nascent stage (for both the product and organization), focus on the following aspects, which will make the Scrum rollout a lot easier to manage:
- Use workflow tools for capturing user stories as well as project management and link them to Continuous Development (CD), Continuous Integration(CI) activities
- Wherever possible try to adopt automation for CD and CI activities including daily builds, unit tests, and regression tests
- It will be ideal to have two separate individuals functioning as Product Owner and Scrum Master
With the help of workflow tools, and automation you will achieve “built-in quality” in your software, allowing you to focus more on achieving functional completion for a Minimally Viable Product (MVP), which is your primary goal at this stage.
At this stage, you are dealing with a existing software developed probably using a non-agile methodology, and might be based on a legacy technology stack. Typically you will see companies at this stage struggling to handle the technology debt that would have piled up, and at the same time trying to figure out how to build a new version of their software, preferably on the latest technology stack with new architecture, and shift to an agile process like Scrum. Even at the best of the times, this transition is tricky as one has to handle the maintenance and support of the legacy solution, while developing the new software on a parallel track. At this phase, the following aspects should be considered in adopting Scrum:
- Clearly demarcate functions and roles responsible for maintaining and supporting legacy solutions
- Create ownership for critical functions such as Product Management, Product architecture, Development, and Quality
- Transition into a full-fledged departments with multiple Scrum teams, which could be either component or functionality based, with clearly identified roles and responsibilities
- Span of control for product management and architecture could be across multiple Scrum teams
- Factor in time for maintenance of legacy solutions; if the allocated bandwidth is unutilized, the teams can focus on building new functionality
- Be prepared to handle the challenges associated in dealing with multiple scrum teams, and even geographically distributed teams; the workflow and automation framework should handle this scenario
- Role of Scrum Master, Product Owner and a centralized Project Management Office (PMO), will be extremely critical in managing the transition to a scaled agile framework
At this phase, you have already transitioned to a scaled agile framework, and would be looking at achieving further refinement and fine tuning with the help of metrics. At this stage, the following aspects become critical as the organization transitions to achieving maturity of the Scrum process:
- Product Management Body (PMB), must play a lead role in prioritizing and realizing the product roadmapfrom a functional perspective
- Product Architectural Board (PAB), must lead and setthe direction for achieving the technology roadmap with a focus on ease of deployment, security, performance, scalability, maintenance and support.
- Engineering management becomes extremely important in achieving both the technology as well as product roadmap
- As the scale of the organization grows with multiple scrum teams, the role of senior personnel such as CTO, VP Engineering, Product management head, Enterprise Architect (EA), and Release management head becomes crucial
At this stage, the goal of the organization should be to achieve the process maturity for getting into a rhythm of continuous innovation, and continuous release.
At all these stages, I would like to stress the importance of the role of a Scrum Master or a body of Scrum Masters in removing the bottlenecks for continuous orchestration towards a smooth, and predictable release process.