Agile Release Planning Kick-Starts Agile Adoption
Last Updated on Tuesday, 4 February 2014 11:37 Written by Doug Brophy Wednesday, 3 July 2013 07:00
Organizations just starting out in their Agile adoption are eager to begin seeing results. After proper Agile teams have been formed and trained in the basics of Agile, they are ready to begin practicing. But what is the first step in your Agile adoption, where should they start? Agile Release Planning is the answer.
Agile Adoption : Release Planning
Agile Release Planning enables teams to speed up their Agile adoption. It brings the stakeholders together in a working session focused on developing the software requirements and plans to develop the software incrementally and iteratively. Risks, issues, dependencies and assumptions are identified and addressed in the planning.
This kick-starts the Agile adoption practices, enables teams to begin delivering results quickly, and sets them up for success with the release. A recent coaching engagement provided a good example of this.
An Agile development team had been formed to build the next generation platform for a Resource and Operational Planning tool suite. A new platform with a single, common database and user interface was needed to better integrate and present the product offerings, in line with the product vision and roadmap. The legacy platform had become overly burdened with technical debt after years of ad hoc development, and became costly to support and extend.
The new team was in its forming stage. There were conflicting views and differences in understanding of the requirements for the next generation platform. There were strong differences of opinion about what and how to leverage from the existing platform architecture and code base, which was large and complex.
Most of the new team came from the legacy platform development team. But the Product Owner (PO) and Product Manager (PM), two developers and a tester were from a different but similar product suite. The PO had recently been part of a similar platform uplift program for the other product suite, and had a developer background. As such, the PO had strong opinions about how to execute this project, including on the subject of architecture and code reuse. He strongly advocated for starting over with a new clean architecture since, for example, the existing platform had lots of business logic tightly coupled with the UI.
But the legacy development team members were very concerned about doing this. They were counting on re-using a lot of the legacy code (and architecture). In their minds, that would be the fastest way to complete the project, since they were very experienced in development of the legacy platform.
Agile Adoption : Release Planning Workshop
To overcome these issues, we held a Release Planning Workshop. Representatives from Product Management, Development, and other stakeholders in the release were in attendance. Our workshop began with an intentional focus on reviewing the business goals and associated product vision and roadmap, as a precursor to talking about architecture, epics, features, and stories. This quickly made it clear to Product Management that they were not fully prepared to discuss the platform requirements in this manner.
We were able to identify some epics/ features and stories on that first day of the workshop, but it was mostly a training exercise for the team to learn what and how we do release planning to improve their Agile adoption. With this new understanding, Product Management asked for a week to go “do their homework” to fully prepare for another try at Agile release planning.
Agile Adoption : Outcomes
We reconvened a week later for “take two” of release planning. This time we made rapid progress and accomplished the goals of release planning. Notable outcomes include the following.
1) Development finally understood and accepted that Product Management wanted a new, simplified, de-coupled architecture – not just a refactoring of the existing architecture. This would be the basis for a normalization of how data entry, processing, and presentation would be done across products/ features running on the new, common platform.
2) Delivery date would be negotiable as the project progressed. Development had been assuming that there would be a fixed due date 9-12 months later, which they would be pressured to accept, even though it would be high risk to commit to a delivery date that far out. But Product Management did not have a fixed due date in mind. Instead, getting the new platform they envisioned was the priority for them. They could be flexible about the final completion date.
3) Product Management did want to see incremental milestones of progress, and fortunately, that is exactly what Agile release planning is designed to provide. The plan was for Development to deliver a release every quarter, internally only, incrementally and iteratively building up the platform with every internal release, leading up to the final product release.
4) With a well-groomed release backlog coming out of the gate, the team could begin planning and executing sprints, and gauging their velocity. This in turn would enable refining of the release plan as the project progressed.
5) The team delivered a demo by the end of the second sprint, and every sprint thereafter. They recently made their first quarterly release milestone.
Agile Adoption : Summary
For a new development team with only basic Agile training prior to release planning, within two weeks we had a mutually agreed upon viable release plan that enabled the team to begin executing sprints aligned to the first quarterly release. They had learned how to capture product requirements as user/ role and goal –centric epics, features and stories, create acceptance criteria, estimate stories in relative story points, and they were ready for the first sprint planning and execution.
Without good Agile release planning, teams often try to start sprinting with a poorly groomed backlog, with no clear direction towards delivering on release goals. This can result in wasted time and effort (money), engraining of bad habits, as well as frustration and disappointment with Agile adoption.Learn More
How to Own a Really Big Complex Product #agile2010
Last Updated on Thursday, 15 November 2012 12:38 Written by Mike Cottmeyer Thursday, 12 August 2010 10:42
Hey folks… here is the deck I am doing this morning at Agile2010. I am pretty excited to do this talk… I finally feel like I’ve got the slide sequence and story right. It’s amazing what a good night sleep will do for you! My talk is in E-2 on the Ballroom level, hope to see you guys there!Learn More
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Tuesday, 19 May 2009 01:00
There is a FREE event for Product Management types in Atlanta. The first ProductCamp Atlanta will be held Saturday, June 6, 2009 at the GTRI Conference Center (250 14th Street, NW, Atlanta, GA). You can find the details here… http://barcamp.org/ProductCampAtlanta.
They are looking for sponsors and session leaders. (Product Manager types LOVE Agile topics). Please forward this post to other people who might able to come to Atlanta for the event. This is going to be really cool, I have done a few barcamp type events and they are great learning opportunities.
Right now I am a strong maybe to go… my wife and I are leaving for Vegas (SQE Better Software Conference) the week after so I don’t know what is going on with the kiddies that Saturday. If I were not travelling the week after… I would definately take a Saturday to go. I strongly encourage you guys to make this happen!Learn More
More Second Order Agile Scaling…
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Thursday, 30 April 2009 07:27
In my post Second Order Agile Scaling, I suggested that building teams around capabilities was the first step toward untangling our portfolio management mess. The second step… and equally as critical… involves having the discipline not to start projects we don’t have the capacity to finish. We know from our experience with small team agile that writing requirements we can’t develop is waste. The exact same thing goes for building capabilities that can’t be consumed by the project team or the business.
Agile portfolio management involves identifying our most pressing business problems… or most lucrative market opportunities… and coordinating the capabilities of the organization to deliver the highest return on investment with the least amount of risk to the business. Our agile organization is going to organize around capabilities… understand and measure the throughput of each team… and focus on delivering the highest priority projects first.
Let’s consider a simplified model for what this kind of project intake and decomposition might look like…
Here is the idea behind this diagram… the business is constantly looking for things to fix and opportunities to take advantage of… opportunities that will align with overall strategy and objectives of the enterprise. The business knows that these opportunities are going to leverage the combined capabilities of several teams within the organization… but early in the life of the project… we are not quite sure which ones. How do the strategic planners know what the organization can deliver… and when… so they know how to make commitments to customers?
The answer lies in progressive elaboration of requirements… the progressive elaboration of the solution architecture… while restraining our tendency to over-specify the solution too early. We need to make commitments… while keeping our options open… while we figure out the details. Let’s look at this in a little more detail…
Circle 1: Strategy and Enterprise Architecture
When projects arise for consideration by the business… there must be a team in place that is responsible for assessing the set of possible business solutions (requirements) and the set of possible technical solutions (design). This teams job is to consider the objectives of the business to identify a high level solution that can be delivered within the time and cost constraints necessary to deliver the expected value with minimal risk to our investment.
See my post called Software Requirements Balancing Act for a little more around what I am talking about here. Putting this into more day to day terms… we need to identify the major epics and themes that will make up the product requirements. We also… and this is really important.. need to identify the organizational capabilities (feature teams, component teams, or services teams) that will be leveraged to deliver those high level requirements. In my mind… I call this enterprise architecture… the set of big block decisions that the organization makes to constrain the set of possible technology outcomes.
Circle 2: Product Management and Software Architecture
Once the business has decided what it wants to do… it needs to engage the capabilities of the organization to deliver. The themes and epics are assigned to the Product Owner team to break down into user stories. If there is a need to manage technical dependencies between component teams or services teams… this is where you begin to establish the high level software architecture. Admittedly… I’m not talking much about building software yet… but I fully expect this level of the organization to explore options… and validate decisions… by building out and delivering working code.
The goal at this stage of the planning process is to bring our understanding of the problem space and the solution space down to the next level of granularity. Just as the strategy team and the enterprise architecture team collaborate to keep the requirements and solution in balance… the Product Owner Team and the architect collaborate to keep the user stories and software architecture in balance with the constraints established by the strategy and EA teams.
Circle 3: Product Ownership and Detailed Design
At this point, I am sure that you can see where we are going here….just like themes and enterprise architecture constrain the decisions of the Product Owner team… user stories and software architecture constrain the decisions of the capability teams. We are taking the problem from a very high level of abstraction… through progressive elaboration… to the point we are ready to assign user stories to a capability team where user stories can be specified, designed, and coded at the detailed level.
This is where the rubber really meets the road. This is where the actual capabilities of the business are delivered. You have a team of engineers collaborating with a product owner on a day to day basis… making the daily trade-offs to deliver within the constraints established by the Product Owner team and the Software Architect. Again… each higher order team constrains the decisions of the lower order teams… not in a vacuum… but collaboratively with an established feedback mechanism.
Constraints and Feedback
In this model… business decisions have to be made up front at a pretty high level of abstraction… that’s reality and we have to deal with it. Enterprise teams do not get a free pass to deliver whatever they want… after all… most business do not have an emergent business model… they operate under a goal oriented model. Teams deliver on the goals and strategic objectives of the larger enterprise.
These business decisions though need to be made at the appropriate level of abstraction so that the teams can inspect and adapt their way to delivery. The business establishes the constraints but the team is free to be agile within those constraints… they can do what they need to do to deliver on the higher order objectives.
Okay… so what if the constraints are invalid or limit our options in an inappropriate way?
The idea is to mitigate the issue within the capability team… or if possible… at the current layer of abstraction. When the problem transcends the ability of that layer to resolve… it gets escalated up the abstraction hierarchy and mitigated at the next higher level. As deep or as wide as your agile enterprise is… constraints come down the hierarchy… and feedback goes up the hierarchy. Each level is responsible for managing trade offs until you reach a point where the issue has to be taken up to the next level.Learn More
Second Order Agile Scaling
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Wednesday, 22 April 2009 11:42