You adopt practice to “make the team go”. However, every practice you adopt has a cost. The time you spend “making the practice go” is somewhat then a cost of making the team go. I like to talk about the cost of your practices as “Feed the Beast!” But what you really want to make your team go is to “Ride the Beast!” where the practices we have adopted start to carry the team faster than they could go without them.Continue Reading
Before we talk about whether agile practices provide any benefits toward risk mitigation or risk reduction, we really need to talk about the nature of risk in a software development project or process.
In any discussion of risks, there are any number of attritbutes by which we can classify or characterize risks, but in order to discuss mitigation, comparing two methodologies side by side, it makes sense to me to use the source or cause of the risk as the primary taxonomy. So I will describe these risk sources, and how agile might offer some advantage in dealing with risk.
Risk Source – Customer: Risks emanating from the customer inevtably involve scope, schedule and money. Sometimes it is that scope cannot be succinctly defined, or understood (requirements), sometimes it is that the buiness need changes more rapidly than expected due to external factors. Sometimes it is simply that the customer for whatever reason cannot make decisions.
Risk Source – Project team: Risks emanating from the project team inevitably involve productivity, skill, or leadership.
Risk Source – Organization: Risk emanating from the company or department producing the software, involve policy, resource management, coordination.
Risk Source – Technology/Environmental: Risk emanating from technical infrastructure or software development technology platform.
I have listed these in the order of frequency or likelihood based purely on my own experience. You can argue with me on the customer risk being the most frequent or likely, and that all scope, schedule and financial risk emanate from the customer, but it’s their scope, it’s their schedule, and it’s their money, and all decisions around those three elements are made by the customer.
So how do agile practices help mitigate risk emanating from the customer?
- By producing working software as early as possible, effectively shortening the feedback and delivery cycles, agile practices actually retire risk of unknown. When you produce working software capabilities that is ready to deploy, any risk of unknown that was attached to those capabilities is effectively retired. This includes risk of incomplete or incorrect requirements, or inaccurate translation between business and technical abstractions.
- By assuming a model that inherently drives down the cost of deferred decisions by eliminating pre-work, the risks of changes to schedule or budget emanating from the customers funding model or the customers market strategy are mitigated.
- By developing a model with a higher frequency of customer interaction, and reducing the scope (size and impact) of customer decisions (one milestone at a time) risks emanating from the customers own organizational decision making process, or internal committment model are mitigated.
- By establishing a value scoping paradigm with finer granularity, agile practices can reduce the scope of customer decisions, and the minimum time span of value delivery. More granular deliverables (stories?), make it easier for the customer to prioritize and sequence, ensuring that key value propositions are delivered as early as possible. Customers have a increased ability to discriminate essential scope from non-essential (apple polishing or lily guilding) scope, and so can defer the non-essential, until all of the essential scope is accepted.
Likewise, how do agile practices help mitigate risk emanating from the project team?
- By increasing the frequency of measurement (of productivity), agile practices give more timely feedback on the productivity from each skill to management, enabling adjustments as early as possible, rather than later.
- By establishing a regular cycle during the project of milestone retrospectives, the project team can adapt and adjust without the permission or engagement of outside leadership.
And for risks emanating from the delivery organization?
- By establishing cross-functional teams, and empowering the team to self-adjust their process, agile practices reduce policy oriented risks, as separate teams forming separate (and un-aligned) policies do not inherently collaborate or coordinate.
- By increasing the frequency of measurement, feedback to resource management is actionable sooner, mitigating risk emanating from resource management.
- Agile practices do not appear to provide distinct advantage in coordinating across delivery teams, or with service providers or vendors. But it also does not appear to disadvantage the team in any material way.
Finally, for risks emanating from the technical infrastructure or development platform?
- Agile practices do not appear to provide distinct advantage in dealing with hardware or software environments or development tools. But it also does not appear to disadvantage the team in any material way.
While I am not suggesting that traditional software development life cycle does not have risk management capabilities, only that they are different, and especially, do not retire risk as early. The basis of the traditional lifecycle is that risk of unknown is mitigated by doing ALL of the analysis and ALL of the design up front, in an effort to optimize the development, which is thought to be the risky portion. I think that modern software tools, paradigms and techniques have made the development less risky, which means that the risk is more likely that the requirements that we captured change over time, or simply were inadequate, and that we cannot retire that risk, until we put software capabilites in front of users. That is where agile practices take us – in exactly that way.
Agile practices claim to delivery greater value to the customer. This claim is based on agile tendencies to deliver software capabilities more frequently, which in and of itself, means that the customer starts realizing value from our efforts sooner. OK – this one is obvious. Traditional phase gated life cycles effectively require you to do all the work through each phase – all the requirements, all the design, all the development, all the testing – before any value is actually delivered to the customer. Agile practices – actively proclaim (this is not a passive benefit, but an assertion of the philosophy) that it is better to finish the smallest increment of usable software capability and deliver it to the customer as early as possible.
While agile does not claim to have invented this concept, it does seem to have taken it to the extreme. Here is the “thing” – in a corporate culture where results are measured in quarters and not years, the faster we can implement even incremental improvements in work process, the faster we can show results (cost savings, risk mitigation, staff headroom, etc). The balancing factor is how frequently/rapidly can the organization assimilate change. Yet, even in an organization that is not particularly good at change management, the early delivery of value emanating from agile practices, puts the organizational management in the drivers seat. You can have a “pile” of completed, validated software changes ready to go, and you control the pace of change by scheduling releases. Whether the company wants two releases per year or twelve doesn’t matter to the team – because they just keep piling up the value and the customer controls when it is released into the enterprise. The customer controls the sequence of value that is being piled up, and the customer controls the timing of when the pile is rolled out.
Here is how it works pragmatically:
1) The customer constructs a list of valuable changes (scope).
2) The customer ensures that the list of changes are organized by sequence of delivery (converts scope to a backlog).
3) The team and the customer analyze (write requirements and estimate) these valuable changes in sequence and decide how many of them can be done in a measurement milestone (sprint).
4) The team delivers the changes (designed, coded, tested) for customer review.
5) The customer reviews the delivered changes, and adds any observed deficiencies to the backlog.
6) Repeat steps 2 – 5
One of the things that agile does, simply by sequencing by deliverable value, rather than by skill or life cycle phase, is that it makes it easy to decouple releases from life cycle phases. In a phase-gate lifecycle, I can’t release until all phases (analyze, design, code, test) are complete. Using an agile lifecycle decouples release from phase, because it assumes sequencing by deliverable, instead of sequencing by activity. Other than the “extra” activities required to release (regression testing, data conversion, code migration and deployment) the software itself is continually in a “releaseable” state.
This change in sequence assumption actually gives the “customer” more control over what order value will be delivered in, and allows them to alter the order of value delivery without loss of productivity. This is true, when the order is not altered during a measurement milestone, but for the next milestone, because very little work is done on deliverables before the milestone begins. In a phase-gate life cycle, all of the analysis is done for all deliverables before the design starts, all the design is done for all deliverables before the code starts, all the coding is done before the testing starts, etc – so the later you alter the scope (or change the sequence by swapping one scope item for another) the more completed work you are “throwing away”, which becomes lost productivity or waste. This is why everyone in phase-gate life cycle works so hard to avoid change in scope – we use change control because we recognize that change after analysis is complete means lost productivity.
Now of course WE ALL KNOW that it doesn’t really work like that in phase-gate life cycles – phases are allowed to overlap, and plans are optimized for dependencies, and we can carry risk of unknowns for later analysis or design on our projects – but because of the assumption in sequence by activity inherent in the life cycle model, these things add complexity to the planning process, and to the measurement process, and to the execution of the project because they are execptions, rather than the rule. This complexity itself has a cost in lost productivity and extra coordination or collaboration. The point being that because overlap and deferred analysis are inherent to the agile lifecycle, they do not increase the complexity of the project, plan, or execution, and the collaboration and coordination points are baked into the practices designed to implement the agile life cycle.
The key difference between agile and more traditional phase-gate life cycles is the key assumption around delivery sequence, and all of the implications emanating from that assumption, especially the greater control of delivery of value afforded to the customer. It is this greater control over the delivery of value that the term agile describes – agile life cycles respond to changes in strategy, direction, market conditions, available budget much more gracefully, and with much less drama than traditional phase-gate life cycles. This is a direct win for the customer, and as such, can be sold as an advantage for the provider.
Predictability is probably the least hyped benefit of agile practices. It is not sexy or fun, nor does the team gain from it, in a positive way. But the team does benefit from it, from a management perspective.
The benefit of a predictable software delivery process is realized in three ways:
- Rational Planning Process – when I can measure the capacity of the team, I can create a rational plan. This allows consulting firms to bid project or enterprise software organizations to budget more accurately.
- Builds customer trust – when I can predict the delivery pace, I can communicate this to the customer, and build trust and reputation. This allows for repeat engagements in consulting, or greater latitude in decision making within the enterprise. When the team demonstrates predictable delivery, the customer can relax and focus on defining the output rather than the mechanisms of accountability.
- Sustainable Pace – when I can project delivery based on the capacity of the team, I can ensure a more sustainable pace. I can negotiate in trust with the customer, understanding their need. I can increase capacity when needed, rather than forcing the team to stretch (work overtime) to meet goals.
These are serious benefits, but we haven’t said that agile practices deliver – only why and how predictability benefits an organization. So how does agile deliver on this benefit?
- Frequent, measurement on regular intervals – by defining arbitrary milestones at regular intervals ( iterations, sprints, time boxes, etc) and measuring the output of the team through each interval, agile practices generate the metrics that support predictability. While it is important to measure, it is also important to have a light weight measurement practice – so that the team doesn’t trade productivity for predictability. The velocity metric (calculated as completed units of estimated effort per unit of duration) is typical. Combined with a remaining estimated effort metric, and planned cost per unit of duration, or average cost per unit of estimated effort allows an accurate projection of both duration and cost. If my measurement frequency is a week, I can know each week how far off plan I am in terms of both schedule and budget. I can choose how I react to this knowledge.
- Cross-functional milestones – what differs within agile software life cycles from more traditional gated software life cycles is that each milestone in agile is self-contained, and has elements of all phases of software delivery – analysis, design, development, testing. This means that each skill is consumed and measured in each milestone. In a phase gate life cycle, the last skill (testing) is not consumed or measured until the last milestone – and so is not predictable – so I am using measurements from other projects at best. If I form virtual teams for projects (consulting), I can only predict at best from prior individual performance, which does not account for team dynamics.
- Repeatable, lightweight measurement framework – agile practices propose a lightweight estimation practice, a repeatable practice of measuring delivery against estimate. Agile estimates are done with less precision, but much less effort than gated methodologies – again trading productivity for predictability. Traditional project managers (Glen Alleman) get aggravated by this, because it does not have the precision of the more industrial strength estimation and measurement frameworks, however, it also does not have the overhead. Agile applies that same principle to planning that it applies to software delivery (YAGNI) – that is, I do not implement more sophisiticated measurement or estimation schemes, unless the nature of the work, or the project merits that level of precision. If the customer provides requirements that are less defined, I will by definition, provide estimates that are less precise, even using the industrial strength mechanism. Since software development is a largely non-repeatable process, with no standard units of measurement for output, agilists argue that using a precise estimation and measurement framework that costs more is a waste, because it does not yeild greater predicitability.
- Lower planning skill requirement – agile planning practices are typically simpler, easier, and less effort, than other practices. This means that your project manager doesn’t need to know how to do a PERT chart, a Critical Path Method (CPM) or Earned Value measurement. In agile plans, you don’t focus on dependencies between tasks, you simply sequence the deliverable capabilities in the order of customer value, and go. All of the more sophisticated plan maintenance, are optimizations that may not be necessary, or beneficial, given the level of unknown in the work being contemplated. Here is the kicker – because it is easier to implement, it gets done more consistently. It gets done with more discipline – so a lower fidelity process executed with greater discipline actually delivers higher predictability over time than a higher fidelity process being executed with less discipline.
- Emphasis on learning and improvement – agile practices call for retrospectives after each milestone. The purpose of the retrospective is to identify opportunities to improve practices in use. As the team works together, they find ways of working better, and have a stated process for proposing, deciding and implementing improvements. Since the team owns the process, and the improvements they are incented to implement (it was their idea) and thus each team adapts agile practices to suit their specific situation and goals. Through the process of self-improvement, the team becomes more predictable, because this milestones surprises become opportunities.
- Progressive elaboration – in phase gated software development life cycles which assume that all inputs are known early – (requirements, design, etc.) the temptation is to plan in more detail than you actually know. This introduces fiction and reduces predictability. Agile’s preference for progressive elaboration in requirements, designs, and plans recognizes the FACT that you cannot know everything before you start. This leads to plans that grow and shrink as knowledge is acquired and accounted for, but always currently reflect the state of our understanding of the work. This provides the ability to decide and adjust based on a plan that is as accurate as it can be with the knowledge that we have. Anything more is speculation, or fiction, that leads to poor decisions and improper adjustments.
The benefit of predictability is one that is less intuitive that the rest. Who really benefits from it? In the end, all benefit. Management has more control, the customer is satisfied, and the team can reach a sustainable pace – that sounds like win-win-win.
One of the hyped benefits of agile software development practices is increased productivity. It is also the benefit that I am most skeptical of. Software productivity is notoriously difficult to measure. That is because there are no relatively standard units of measurement of output. Martin Fowler said this in 2003, and as far as I can tell it is still relatively correct. This is true regardless of whether you are using agile practices or not. In fact, the measurement of software output itself is an expensive activity, so in any normal case study it would be hard to prove. Since books have been written on this topic, I do not feel the need to delve deeper into this topic, except to say that all of the problems described in Fred Brooks’ famous Mythical Man Month still exist today, and there has not been a universally adopted solution.
Nevertheless, I am not totally willing to call bullsh*t on the productivity benefit. There are three completely anecdotal reasons for this:
1) Agile practices tend to focus less on documentation and more on producing working software. This leads to spending less time on speculative documentation that ends up being revised many times. Rather than guessing what users want, agile teams build it as quickly as possible, and get feedback, and revise it, until it IS WHAT THE CUSTOMER WANTS! So from a productivity perspective, it is less work to deliver what the customer wants, not what they thought they wanted or what we thought they wanted. Is this real measurable productivity? NO – but it sure as hell feels good to both the developer and the customer.
2) The shorter measurement cycles that agile favors help resources focus on the needful, rather than the fanciful. This means that developers are focused on working in the next feature. Management theories put forth by Elliot Jacques talk about time span – the individuals ability to plan into the future. Developers typically do not a have long time span. I have often experienced developers who became overwhelmed trying to figure out what order to work in, and ended up being unproductive or paralyzed by unscoped tasks. The rhythm of consistent pacing, tends to allow the team to relax around planning, because there are regular intervals of planning activity, broken by longer periods of uninterrupted development. Is this real measurable productivity? NO – but the developers will tell you that they are able to relax and focus on solving technical problems rather than worrying about deadlines and planning.
3) The agile principle YAGNI (Ya Ain’t Gonna Need It) reduces the investment in complex architecture, or over-engineered solutions, or premature optimization. The principle is less about improving the productivity of individuals, and more about improving the output of the team. It is a principle that allows the team to hold itself accountable to deliver the smallest, thinnest, cheapest version of each capability, rather than the most ornate, most performant, most scalable, most beautiful version. Agile principles direct us to deliver an acceptable solution with the least effort, rather than an acceptable solution that anticipates all future events. Is this real measurable productivity? NO – but as I learned early in my career – the best way to get more done is to figure out all the things that don’t need to be done and not do them.
When I evaluate these reasons, I recognize that the perceived increase in productivity may be much greater than any actual increase, but at the same time, perceived increase in productivity can improve morale and reputation in ways that by themselves lead to real increases in productivity. Agile life cycle projects often feel less like a “death march” than gated life cycle projects, and that alone can lead to increased productivity and motivation.
Of course there has been loads of hype about agile in the software development community. Lots of folks have now been certified as Scrum Masters. I have been involved in agile transformation since 2004/5 when I had a proprietary methodology forced on me from above. Said methodology was brought by a “Management Science” consultant, who incidently was also selling a software product that would help implement said methodology. This same consultant was also married to a signficant client of our firm, and so you can do the math.
Like any other practice, people who have a positive experience with agile, are looking for opportunities to repeat that positive experience. After I rid myself and our firm of the management science consultant and his methodology and his product, I took a long hard look at what he was trying to accomplish. I read some of the broader agile literature. I was looking specifically at the benefits that were being hyped.
Like any other business change program – if you are going to adopt agile practices, you must start by describing the benefits you expect to get. Before you challenge me on business change, let me just smack you down. Software development is a business activity. Whether it is a consulting practice for cash, as a software vendor building a product to sell, or as a company building bespoke systems – software development is a business activity. To adopt a new methodology, life cycle, set of practices, technology stack, etc. is therefore a business change program and should rightly be treated like a business change. That means:
- you don’t start until you are prepared to invest sufficient resources to make the change stick.
- you have to be ready to sell executive management on the investment.
- you have to be able to articulate the benefits you expect to get from the investment.
So what are the benefits that are so overhyped?
1) Productivity – agile practices claim to be “lighter weight” processes, meaning you spend less effort on maintaining the process and more delivering valuable software.
2) Predictability – agile practices claim to deliver greater predictability, meaning that we will know earlier that our plans are reasonable, and have more time to adjust if they are not.
3) Improved Value Delivery – agile practices claim to delivery greater value to the customer, this claim is based on agile tendencies to deliver software capabilities more frequently, which in and of itself, means that the customer starts realizing value from our efforts sooner.
4) Improved Risk Mitigation – agile practices claim to reduce certain types of project risks faster and more effectively than other practices, meaning after the same amount of time an agile project has less remaining risk than otherwise would be true.
In a following series of posts, I would like to describe each of these benefits in more detail, and how I have seen agile practices deliver these benefits. I think that agile practices certainly can deliver these benefits, but I do not believe that there is a guarantee, nor is agile the only way to get these specific benefits.