Laying Groundwork for an Agile Transition
- jimschibler
- Oct 1, 2016
- 6 min read
Agile development processes are all the rage these days, and for good reason: they produce demonstrably better results than traditional ‘Waterfall’ methodology in situations that involve many unknown factors. Many companies (mostly younger ones) have already adopted Agile methods, which use short development cycles and frequent course corrections to develop products based on measured results and lessons learned. However, established companies often stumble when attempting to transition to Agile, because Agile methods are so radically different from the project-centric, “plan the work, work the plan” mindset of Waterfall methodology.
To successfully move to Agile, you need to gain buy-in at all levels of management, coupled with new behaviors at all levels of the company. These behaviors include developing an understanding of what Agile really means, and letting go of old habits like demanding detailed plans for projects that cannot be planned in advance with any accuracy. Old habits are hard to change, which explains why many companies struggle to make the transition.
You can improve your chances of a successful transition by taking a few initial steps to start changing the cultural mindset of your organization, before you take the leap to fully implement Agile methodology.
Stop Planning Your Way to Disappointment
There’s an old saying: “if you want to make God laugh, make a plan”. Regardless of how straightforward a project may appear, and much experience a team has, there are always factors that can invalidate any plan. And with projects that have many unknowns, variance from the plan is virtually certain. So why should we announce specific dates, create unrealistic expectations, and set ourselves up for failure?
One school of thought says “Without a deadline, nothing gets done”, but putting too much focus on dates seldom leads to success, and often leads to compromises in product quality. Deadlines are not effective at motivating teams to produce good results.
Nevertheless, there are legitimate reasons that we are compelled to announce project dates: they’re needed to make go/no-go decisions on development investments, to manage budgets, and to manage dependencies—dependencies such as related development projects, marketing campaigns, and promises that sales people feel they desperately need to be able to make. (Unenlightened leaders also use dates to measure team performance, which often leads teams to compromise on quality in order to meet timeline targets. Enlightened leaders pay more attention to functionality and quality than to dates.)
There’s no getting away from the need to set and communicate target dates, but we can manage expectations more effectively by clearly communicating the uncertainty associated with those dates. To do this, I recommend resisting the temptation to declare a single precise date for any milestone, and instead start defining three dates: a best-case date, a worst-case date, and an expected-case date.
At the beginning of a project, the ‘error bar’ (gap between best and worst cases) can be fairly large, especially if the project or its related market has many unknowns. As the project progresses and learning happens, the number of unknowns decreases, and the error bar should also decrease:
Characterizing uncertainties up front has important benefits:
it forces team members to think about the risks around dates, which can often lead to insights that can produce better time estimates
it allows up-front contingency planning – such as identifying which features to drop if reality trends toward worst-case, or if things are going better than expected, choosing between options (add more features, accelerate release date, test more thoroughly)
it helps stakeholders understand the risks associated with project dates, and better manage their own contingency plans
In short, this technique gets everyone to admit that aspects of the project are unknowable and that estimates will have to be refined over time. It’s a good first step toward getting people to stop believing the illusion that dates in a project plan are accurate and precise.
Simplify Your Prioritization System
In an Agile shop using Scrum, all product requests are prioritized using a single Product Backlog, from which items are selected by the development team to be worked on in short development cycles (sprints). The Product Owner is responsible for maintaining and prioritizing the Product Backlog, but does not get to dictate the work of the development team.
In contrast, a Waterfall shop typically will have a Product Manager define the product requirements for a project of much longer duration, get time estimates from the development team, and work with a Project Manager to lay out a project plan. Of course, as the project progresses, unknowns will cause variances that require adjustments to the plan—features may need to be dropped or added—so requirements still need to be prioritized. How to best do this can be a tricky question.
I’ve seen arbitrary approaches like “Must Have, Should Have, Nice to Have”, or numeric weightings, but these always seem to be difficult to interpret at the time it really matters: when plan adjustments need to be made. Lack of clarity about the meaning of assigned priorities makes the challenging task of triage even more difficult.
I’ve also seen schemes that attempt to assign a business value to each feature. One of the better ones is the Kano model, which weighs customer value against cost of implementation. Assigning business value to every proposed feature brings some objectivity into the prioritization process, but it can be an exhausting exercise, and the results are always subject to debate because many assumptions must be made.
I came up a simple prioritization scheme that helped me quickly achieve some clarity with only a modest investment of effort:
Priority 1: Feature that must be implemented before the product can ship
Priority 3: Feature that won’t make it into this release (but was considered, and should be kept in mind for a future release)
Priority 2: Feature that has not yet been classified as Priority 1 or 3, but will be as the project progresses
This scheme gives the development team and stakeholders clarity about:
which features cannot be compromised away
which features won’t be done and should be grieved now (including those ‘pet’ ones from the C-suite)
which features might be considered for inclusion if the project goes better than expected
My 3-level prioritization scheme helps the developers stay focused on the most important features, while still keeping awareness of other feature requests that might make sense to incorporate into the current project. The simplicity of the scheme also helps the Product Manager gain clarity, and complete the difficult task of prioritization more expediently.
Identifying Priority 1 items is usually fairly straightforward, and it’s usually not hard to identify some Priority 3 items, but Priority 2 items can be rather challenging – you can’t justify making them Priority 1, but you can’t quite give them up too easily either. Sooner or later you’ll need to reclassify them, so it’s best to keep the number of items in this category relatively small. (I suggest a workload that adds up to 20-40% of the workload of the Priority 1 items).
Prioritize By Successive Approximations
Whether you’re a Product Owner in an Agile shop or a Product Manager in a Waterfall shop, your task of prioritization involves balancing the value of features versus their cost. Determining the cost carries a cost itself; developers need to take time to think through your proposed features in order to come up with estimates of the work involved. Developers are understandably reticent to invest a lot of time into preparing reliable estimates for features they’ll never implement. This can lead a stalemate: the Product Manager can’t decide which features to include in the product requirements or product backlog, and the developers can’t or don’t want to prepare time estimates for all the features that the Product Manager needs to consider.
One way to break the stalemate is to ask only for very rough estimates at first, with the emphasis being on speed rather than accuracy. Estimates that could be off by a factor of 5 are still good enough to enable the Product Manager to postpone or rule out a large fraction of the proposed features. For the items still under consideration, the Product Manager can then ask for higher-quality estimates, perhaps within a factor of two or three, and use those estimate to further limit and refine the product requirements or product backlog. If appropriate, the process can be repeated a third time to reduce uncertainty.
This method of successive approximations enables progress toward the goal of a refined set of features, in the form of product requirements or a product backlog, that maximizes return on investment and net value to the business.
Putting It All Together
Transitioning to Agile is a big undertaking that requires not only new processes, but also new thinking and new behaviors. To achieve a successful transition, your entire organization needs to be unified in its commitment to the change. You can help lead the change to new thinking and new behaviors by adopting some new practices in your product planning. This article described three such practices:
clearly indicating the uncertainly associated with any proposed date
implementing a simple, practical prioritization system that everyone can understand
using successive approximations to quickly arrive at reasonable estimates of effort for product features
Not only will these practices help you position your organization for a transition to Agile, they’ll also make life more manageable for you in your current Waterfall environment.
Comments