Agile – Page 4 – In Search Of

Agile Predictability

Posted on August 21, 2011Leave a comment

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.

so predictable

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.

Agile Productivity

Posted on August 18, 2011Leave a comment

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.

Agile Benefits

Posted on August 16, 2011Leave a comment

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.

Early Delivery Part 2 (from my old blog)

Posted on February 20, 2009Leave a comment

Early delivery has been considered the first commandment of agile. In the principles behind the Afile Manifesto, the first paragraphs says:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Early and Continuous delivery of valuable software… I take this to mean that we are going to structure a project (or delivery stream), such that usable software “features” are completed as frequently as possible. The shortens the feedback loop and allows the customer to decide when sufficient value has been delivered to justify a deployment or distribution event.

Different software development situations, call for different decisions regarding deployment:

1) For a company whose primary presence is via software and/or the web, especially where the revenue is driven by the software (think yahoo or google), the frequent delivery of new or enhanced features is a way to drive customer satisfaction. The product manager responsible for these decisions, strike a balance between new ideas, and enhancements or fixes to existing.
2) For a more enterprise software application, used by employees of a company, the cost of deploying and retraining staff on new software features, and the criticality of correctness. The business process change management around delivery of new software features may drive a very different roll-out cycle.
3) A software vendor, selling software to business units within an enterprise, or small businesses, may have yet another model for making decisions about deployment. They may be driven by demands from new customers, and prospects, as well as a backlog of requests from existing customers.
4) Software that is to be “embedded” in a physical device may have a completely different decisions cycle, and a much more rigid schedule. The delivery of the rest of the device into which the software is to be embedded, and the revenue derived from the sales of the devices, completely determine the schedule. In this model, partial delivery has little or minimal value.
5) Software that is deployed in industries that are heavily regulated (blood bank) or that have critical quality requirements (military/aerospace) may have much more rigid schedules that are driven by decisions made well before the development starts. In this model, the ultra-high cost of quality assuranceand regulatory certification reduces the value of partial delivery to near zero.

It is easy to see why the value of agile principles is readily apparent to some, and a complete mystery to others. It is the decision model that works in between need and deployment that determines the value of early or frequent delivery. From a whole project perspective, this is clear. But let’s look from a intraproject perspective.

Why “Velocity” Is Not As Bad As They Say

Posted on February 7, 2009Leave a comment

Glen Alleman of the Herding Cats blog is one of the most experienced project managers I have ever read. His background is amazing. He is bright, and has practical knowledge of projects that I will never have. However, he is missing the point on agile and velocity.
I recently read his post “Simple Never Is” and have this response to offer.
I have been working on software projects for some 20 years, and while I am not a practitioner of any formal agile methodology either project management or software development, I have been exposed to incredibly ad hoc practices in managing software projects. I agree with Glen when he says that agile (spokesmen) railing against traditional project management have never been exposed to good traditional software management practices. Most project managers that I have worked with, take a couple classes, manage a couple projects, and maybe get a PMP cert and then do the same thing over and over, with varying results, because they personally suck, not because their methodology is fundamentally flawed. I have been this project manager, and I sucked as well. I think that most of this is because the organizations that I have worked for did not sponsor, fund, or require good project management practices.

Agile, and specifically scrum, are a reaction to the suckage. It is the project team reacting to the fact that project managers don’t use practices that help. What scrum and other agilish methods and practices around project management do is help the team remove two specific smells from project management:

plan fiction – the two most prevalent fictions I have experienced in project plans are a) plans that don’t reflect how the work is really done b) capture of partial task completion in percent based on the developers opinion. Neither of these conditions necessitate a deliberate deception, but can be the simple result of laziness or communication issues.

inconsistent plan maintenance – when at the outset of a project, there is no establishment of team values and rules around how estimates will be performed, adjusted and maintained in the plan, how the plan will be elaborated, what acceptable task effort is. When there is no enforced measurement frequency, or commitment around reflecting the current work breakdown and task sequence in the plan, even though it changes from week to week, then the plan itself becomes useless.

The thing that Glen is missing is that velocity is not a project completion measure, but a team productivity measure. Agile project management is more about team than project. Thus it makes sense that the most visible measure is team productivity, not project progress. From a project progress perspective, velocity is exactly what Glen says – predicting the future by evaluating the past. He calls this driving by rear view mirror. Velocity, however, is good for the team. It tells them whether their current pace is likely to match the published/committed schedule, and when measured frequently enough (like every week), it tells them early enough, that they can decide to adjust something to stay on schedule.

Velocity is a factor that is involved in the measurement of current projected duration. Current projected duration is a simple measure – remaining work / average velocity = projected duration. This measure has a bunch of assumptions:

productivity is the primary predictor of duration – this is a big leap, but I think that this is what Glen reacts to, because there are not many large projects where this is true of the project overall. However for many software projects during the development milestone, the team is focused on this, and are held accountable for this and this alone.
there is enough parallelism in the plan that sequencing of task execution is not rigid – that is the team can reassign tasks and resequence tasks to mitigate the impact of delays on one task or deliverable.
the plan is updated at least as frequently as it is measured – As the work goes on, the plan is updated – newly discovered work is added into the plan, and work that is determined to be less, or not necessary is removed from the plan. that is, remaining work is not only adjusted by the work complete, but by periodic adjustments to task estimates, and by addition of tasks when new work or re-work is required.

I think that Glen’s characterization of velocity as a “rear view mirror” and “yesterday’s weather” metric is largely because of his believe that past performance is not always a good indicator of future results. While this is true, velocity and current projected duration are useful metrics that can be applied in many ways to measure productivity and schedule. Glen says that velocity is a level of effort measure, and I disagree. Here’s why:

Remaining work is always an estimate. Properly calculated, velocity is the sum of the effort estimates for the completed tasks for a period, and requires that the task estimates not be adjusted during the measurement period when the tasks are completed. Velocity is meaningless if not used to project duration, therefore velocity must be in the same units as remaining work.

If calculated this way it is not, as Glen suggests, a LOE measure, but much closer to EV, because it approximates the budgeted effort. The thing about velocity that many project managers struggle with is that it is not precise, and it doesn’t contemplate many aspects of the project timeline, only team productivity. I believe this is because agile disciplines are mostly focused on the behaviors of the team, and increasing/maximizing team productivity, and as a result, the delivery of value by the team.

Here are some things that I have done with velocity (in combination with other measures):

Working backward from an published end date and remaining work, assuming resource allocation is constant, we can calculate required periodic velocity – or the amount of work that must be completed per period (week?) on average to acheive completion by the end date. I use this to ensure that we are planning (committing) to complete enough work each period (week) to stay on schedule.
We can capture personal velocity metric to capture each team members average productivity, versus their own estimates. I have measured velocity vs. committment to help team members plan more effectively, and to help the team re-allocate work to stay on target. This is a great help to managers who want to coach developers into higher performance, on both development and estimation.

In my experience, velocity alone is insufficient for many projects, as it doesn’t really contemplate the complexity of external dependencies, interactions between teams, etc. When these factors are in play additional measures can be devised or adopted to present conditions where the project is at risk. When my team is largely in control of the project and there are fewer connections and dependencies, I have experienced the benefit of this simple measure (velocity) because it is easy to understand, and difficult to fake out. These two factors allow a development of trust between project manager and team and a focus on solutions (adjusting the plan).