Agile Axioms from Paul Beavers

Paul Beavers, Senior Director of R&D at BMC Software, has been blogging about the successful BMC agile enterprise transformation experience. Paul was a collaborator of mine on that fun project, and as a senior director, he was personally responsible for driving much of the change that facilitated success. He has been synthesizing this experience into a set of “agile axioms” and has been posting on his blog at working software every two weeks. Paul is a pretty direct guy and he doesn’t mince or waste words, so it’s some concise, pithy, and practical content. For example his first three axioms are:

Agile Axiom #1 – Agile development actually requires more discipline that traditional waterfall methods.

Agile Axiom #2 – Without automation it is mathematically impossible to stay releasable at the end of every iteration.

Agile Axiom #3 – An automated build system is critical to the success of most Agile software projects.

If you are transforming a large enterprise, you might want to subscribe to his blog.

Meeting Deadlines: What’s wrong with this Release Plan #2? (AERP8)

In my last post, Meeting Deadlines: What’s wrong with this Release Plan #1, I noted that the ability to commit to and deliver on near term deadlines is a reasonable and necessary accomplishment of a professional agile team and enterprise. To achieve this, we depend a lot on the release planning function (see Release Planning category on this blog and this article in the Agile Journal). In the last post, we looked at a flawed release plan from one perspective. In this post, we’ll look at the same plan from another perspective.

In Waltzing with Bears by DeMarco and Lister, the authors posit that software teams aren’t historically very good at estimating and meeting deadlines. In my personal experience, that has absolutely been the case and the projects I have tracked over the years are typically late by about 50-100% of the initial schedule. In other words, six months becomes more typically nine or twelve. (Here’s a fun exercise: you do the math to see what an old-time, twelve-month plan becomes. And then reflect back on your last big waterfall project!).

This is illustrated with the probability-of-meeting-the-deadline graph from their book, which looks roughly as follows:

Don’t worry too much about the shape of this curve, because it isn’t a science and I can’t draw worth a hoot anyway, but the point is that the probability of delivering before the deadline is basically zero. This is because we’ve most likely identified all the tasks that must be done on the project and they can’t likely be accelerated due to all resources being allocated.

And since the area under the curve (total probability of meeting the plan) is 100% (assuming that it will eventually be delivered at some point), then the probability that it will be delivered on any one day predicated in advance, including the deadline date, cannot be 100%! In other words, while it could happen, it isn’t very likely and it would be a stupid thing to build external dependencies on. In addition, since it can’t be delivered early as we discussed above, the logical conclusion is that it will probably be delivered late. Sadly, our own experience has aptly illustrated that this is the most likely outcome.

DeMarco and Lister hold that the proper thing to communicate is not the deadline itself, but the probability of meeting any particular date over time. However, that is a pretty sophisticated notion for most of today’s enterprises.

So are we forever doomed to bad outcomes relative to plan?
Do we need to consider a career change?

Not if we take the lessons learned and adjust our predictive model.

Now, back to my earlier post. We saw in this post that the first plan proposed by the team was flawed, i.e.:

Relative to the risk profile curve above, the flaws are pretty obvious, i.e.:

The probability of meeting the deadline is small, since it cannot possibly be delivered early and there is no allowance for the inevitable gotchas.

In response, the team came up with a revised plan as follows:

This plan was better received at the release planning session.

Why might this plan work when the other likely would not? Because it builds in the allowance for deadline risk mitigation as the following figure shows:

This has the effect of moving the probability curve to the left. Since the third iteration is lightly loaded, it might be possible to deliver a little early, thereby starting the upward curve earlier. Moreover, with the lightly loaded third iteration having the capacity to take on the unanticipated tasks and absorb any underestimated tasks from iterations one and two, it is much more probable to deliver it on time.

The probability is still not 100%, because it can’t be 100% at any particular date, but the area under the curve indicates that there is a higher probability of meeting the date than there is of being late!

Perhaps that’s as good as it gets. This is Research and Development after all. And it’s all software, even at that.

(Refer to Waltzing with Bears for a deeper and more meaningful treatment of the probability curve and its effect on risk management.)

Meeting Deadlines: What’s Wrong with this Release Plan? (AERP7)

Ideally, we wouldn’t have deadlines in agile. As Tom Gilb noted “it’s as though I as a project manager weren’t allowed to know the projects end until the date arrived. The only instructions I’d get in advance would be to “be ready to pack whatever you’ve got every morning and deliver it by close of day” (Waltzing with Bears, pg 132). That would sure force extreme incrementalism the XP way!

Practically, however, deadlines DO matter and the ability to predict a reasonable near term deliverable is one of the hallmarks of effective agile enterprise teams. After all, many outside teams and customers are dependent on us, and it’s reasonable to expect some degree of confidence, at least in a near term deliverable. Any reasonable degree of professionalism demands it.Fortunately, defining and meeting near term deadlines is one of the purposes of release planning, that quintessential practice designed to coordinate and steer large numbers of agile teams in a common direction. (Note: an entire discourse on release planning is posted under the cleverly named category “Release Planning” elsewhere on this blog.

I recently published an article in the agile journal (Experiences in Release Planning at Enterprise Scale: Two Seminal Days in the Life of an Agile Newbie) , an inside-out (i.e. practitioners) view of agile release planning, I don’t know yet if anybody read it, and it’s a little long anyway, but I thought this little extract might speak directly to the topic. In this article, in response to some objectives from product management, Mo and his team came up with a release plan that looks as follows:They were pretty proud of this plan, as it appeared to meet the deadline and left room for some “hardening” activities (reduction of iterative technical debt) at the end of the release. The agile coach, Bill however, quickly underwrote their confidence with the following dialog:

Bill: It looks like you guys are in pretty decent shape for the release? But the plan looks pretty heavily loaded?
Mo: Yeah, we think it’s doable.

Bill: I see you have some stories in the hardening iteration. Do you think you’ve identified every story that you will need to meet the release objectives in the earlier iterations?
Mo: Well most of them.

And then the killer question sequence came in rapid fire…

Bill: What’s the probability that no new and significant stories will be discovered in the next 60 days”?
Mo: ummm, probably zero.

Bill: What’s the probability that you have estimated all the stories you have identified accurately, or overestimated the time it would take for each
Mo: ummm, probably zero.

Bill: What’s the probability that every dependency you have on other teams will be addressed exactly as planned?
Mo: ummm, probably zero.

Bill: “What’s the probability that no one on your team will be sick or take a currently unannounced vacation in the next 60 days?”
Mo: ummm, probably zero.

Bill: “What’s the probability that integrations with the other components will work as smoothly as you hope?”
Mo: ummm, probably zero.

Bill: “So what’s the probability that you will be able to deliver your component on time?”
Mo: ummm, ummm, probably zero.

Bill: “I think you need to rethink your release plan and come in tomorrow with an answer way above zero.

After some out-of-box, productivity-enhancing thinking, (see the article) they came up with a revised plan which looks as follows:

This plan, at lease, would seem to have a much higher probability of success. Here’s why:

1. It leaves room for stories that could not be anticipated at the time of the plan
2. It reserves an entire iteration for the reduction of technical debt
3. It leaves room for overflow of stories that were initially underestimated
4. It leaves room for the inevitable gotchas, interdependencies and refactoring that are sure to follow

Some might call this a “gutless” plan as it doesn’t look stretched beyond belief. And it isn’t. Rather it is simply, considered, logical, practical and probable. In other words, just one less impossible thing to believe in.

On Agile Maturity and Hardening Iterations

I’ve noted a teams need for an occasionally “hardening iteration” in SSA Chapter 13 as well as in a number of posts (Release Planning at Enterprise Scale: an Inside-out Narrative.) The hardening iteration is dedicated to eliminating technical debt, such as minor refactors, bugs, testing across multiple platforms, final QA, docs etc., that is most typically scheduled at the end of a GA release cycle.

Some might argue that needing a hardening iteration is a sign of agile immaturity and it’s just a testing waterfall phase by an agile name. In practice, however, I’ve seen really good agile teams continue this practice for years, so I personally think it’s a practical solution to a real world problem and I typically encourage teams to adopt a hardening iteration pattern in their initial iteration and cadence models.

In a recent post, Paul Beavers notes an email thread from an agilist friend of his, noting that the use of hardening iterations can be both a sign of immaturity (lots of such iterations at the end) or a sign of maturity (occasional hardening iterations in mid-release cadence drawing towards elimination of the need for hardening over time). In any case, it’s a pretty reasoned treatment of the question and it can be found at: Indications of Agile Maturity.

Release Planning- Day 2 Narrative (AERP6)

Note: This is part of a series of posts (AERP1-n) highlighting the critical role that release planning plays in achieving enterprise agility. (These are organized under the Release Planning Category on this blog.) In my last post, Release Planning Day 1 Narrative, I described the program and content of the first day of a two day enterprise event (see the post Organizing and Planning the Release Planning Event). In this post, I’ll finalize this sub-thread with the Day 2 Narrative.

(Also – for a different perspective on this topic, I recently Published an “Inside-out” view – taken from the perspective of a newbie agilist – of this entire release planning process in the Agile Journal at:

Experiences in Release Planning at Enterprise Scale: Two Seminal Days in the Life of an Agile Newbie )

Bur for this thread, here’s where we left off last time……

Where We Left Off Last Time:

By the end of the last program session on Day 1 (Problem Solving/Draft Commitment) it was obvious to all in the room, including the senior product managers and executives present who have ultimate accountability for the outcome, that the objectives of the release are likely impractical. We also noted that this conclusion, while perhaps disconcerting, is actually quite reasonable in that we would question the aggressiveness or competitive edge of any enterprise or process that brings together such resources in order to discover a release plan that is already “in the bag”. So having more work to do and some scope to be cut is likely, reasonable and appropriate.

And while the last session on Day 1 was reserved for problem solving, scope management and tacking these hard issues, in all probability, this can’t be accomplished in the one or two hours left in that meeting. After all, that’s why we have scheduled the session for two days – not one.

Session VI – The Evening after Day 1

While informal and ad hoc, the evening of Day 1 is typically a valuable working session for most teams. There are a number of reasons the teams will likely want to meet independently that evening:

• Reviewing the draft release plan with members of the team who could not be present for the full day session, re-estimating stories, adding missing stories for infrastructure and the refactor backlog
• Brainstorming shortcuts and applying out-of-box thinking for ways to meet the objectives of the release with the resources already available
• Assessing the impact of any scope reductions, interdependencies, etc. that surfaced during day 1

All with the goal of:

• Revising the component teams release plan to see if a plan can be created that meets the (potentially modified) objectives of the releases

Program Agenda for Day 2

We described the program template for the day 1 session in the following graphic.

In a like manner, the program graphic for the Day 2 session is as follows:

Session VII – (Day 2, Session 1) Revised Objectives for the Release

The plenary session on Day 2 is reserved for whatever purposes might be necessary. Typically, this includes executives and senior product managers summarizing the tentative conclusions from Day 1, resetting objectives as necessary for the upcoming internal release, reassigning resources to teams with critical bottlenecks and setting the agenda and objectives for Day 2.

Session VIII – (Day 2, Session 2) Re-planning as Necessary

Component Team Breakouts: Based on this input and the conclusions from the teams prior evening’s working session, the teams again breakout to update and modify their particular release plans. It is often the case that many teams are already done, in which case they may use that session for localized problem solving and agile process adjustments or perhaps getting a jump on planning the next iteration in more detail. In any case, this breakout session should provide the opportunity for all teams to come up with a plan that IS compliant with the revised objectives of the release.

Product Manager Breakout: This is an opportune time for the product managers to get together and assess their roadmap based upon the tentative conclusions of the session. At this point, they should have a high fidelity (and highly probably) understanding of what the teams will deliver in their next internal release (IR1) and they can use this data to update their communication plans and longer term roadmap. In many cases, some of the backlog that didn’t get into the first internal release objectives will roll over into IR2, and since they already had some objectives that were not on the first draft IR1 objective list, they will now likely have a reasonably likely view of the next two internal releases (120-180 days of feature/forecast visibility). The output artifact is an updated “plan of record” roadmap for the next few internal releases that might take a format something as follows:

In addition the PM team will also develop a mapping of internal releases to external release candidates, so as to start having some visibility as to what they intend to deliver to the market, and when.

Session IX – (Day 2, Session 3) Final Plan Review

The third Day 2 session is a plenary session that essentially repeats the session 3 (Initial Re-planning Session) from day 1. Each team presents their plan for review and input – issues are noted – and the next team takes its place until all teams have presented. By now, a plan should be visible that does meet the revised objectives of the next IR, with a little backlog visibility into IR2.

Session X – (Day 2, Session 4) Commitment

Now comes the crucial test. However, before asking for a commitment from the team, the issues list must still be addressed. In this process, the facilitator, engineering managers, program managers (whoever is chairing the entire process) leads an item by item review. This process is complete when every item is either:

1. Resolved to the satisfaction of the entire group, or
2. Assigned to an accountable team, manager, or executive who has accepts the responsibility to resolve the issue before it has the potential to put the release at risk.

Then and only then, can the leaders ask the team for a commitment to the release objectives. Some teams have used the “fist of five” voting scheme which provides a visible outcome of the confidence of the teams in meeting the release objectives. In this process, each attendee is asked to vote (in full view of all the others) with a confidence factor in a show of fingers ranging from zero (meaning that there was no way we were going to do this plan or anything like it) to five (extremely high confidence).

With any luck at all, after all this work, the team will reach a high confidence factor (perhaps an average of 4-5 fingers) and the meeting can be adjourned shortly thereafter. (If not, a subset of the process must to be repeated again until a commitment can be reached.)

Final Session – Closing Comments

Based on the evidence before the teams and the conclusions that can be drawn, the meeting leaders will often provide a few closing comments. This section might include any of the following elements:

• A discussion of how the release will be tracked as progress develops and how progress mitigation and ongoing scope managed will be addressed and communicated
• A presentation of the updated roadmap by the product managers
• A general thank you to the attendees, perhaps with some small gift or token of appreciation

In any case, it’s important to put a nice “wrapper” on the end of the meeting so that teams leave with the confidence they voted and they feel good about the hard work that they invested to reach that point. Most importantly, the teams must also leave with an understanding that they have now committed – to themselves – to their teammates – and to the company, to doing whatever is necessary to meet the objectives of the release.

Anti-patterns in Enterprise Agility

Based on my continuing experiences in applying agility at enterprise scale, I’ve observed a few anti-patterns (common but ineffective practices) that appear fairly frequently. If not addressed, any one of these could seriously limit the productivity and quality benefits that agile can deliver. Taken together,  it could be a real nightmare.

My short list includes:

• Insufficient refactoring of testing organizational structures and inadequate test automation resources to meet the needs of agile development teams
• Lack of team training and/or proficiency in basic agile technical practices themselves (shared code ownership, continuous component and system level integration, concurrent testing, pair/peer review, extreme incrementalism, etc), resulting in iterations and sprints being treated as branched, parallel development and feature-driven milestones, rather than shippable increments of software
• Insufficient or inadequate organizational depth and competency in the critical product owner role
• Inadequate coordination of vision and delivery milestones due to nonexistent or ineffective coordinated, multi-level release planning

These can occur individually or together within the same enterprise.

If your enterprise is experiencing any of these, feel free to send me a note and I’ll respond with some tips and suggestions. Also, if you have experiences to share and suggestions of your own, I’d be happy to post those as well, with or without attribution at your request. In any case, I’ll try to provide a few suggestions to address these particular challenges in one or more future posts.

Enterprise Agility Tips from “Waltzing with Bears”

I admit to coming pretty late to DeMarco and Lister’s interesting (2003) book on risk management in software projects entitled “Waltzing with Bears“. While the book wasn’t written as a text on agile software development practices and not all of its recommendations are strictly agile, I found that it offers an interesting, mature and professional perspective on enterprise-scale software development risk management, and of course to me that implies risk management through agile practices. The chapter on the Denver airport baggage system alone was worth the price of admission (especially for those of us who live in Colorado and lived through those frustrations in the headlines every day.) Lesson learned therein: If you have to achieve something on the critical path and the cost of failure is beyond imagination, then you need a backup plan! (in other words, a design continuum with at least two points on the spectrum – “best case” and “what if?”)

I also found the grabber in the prologue particular compelling as it reminded me of my life as a project manager back in my waterfall days. This little vignette is derived from Through the Looking Glass as the Queen responds to Alice’s protests that “one cannot believe impossible things.”

“Why, when I was your age, sometimes I’ve believed in six impossible things before breakfast”
– The Queen

“There is probably no job on earth for which an ability to believe six impossible things before breakfast is more of a requirement than Software Project Management”
– DeMarco and Lister

That does kind of hit the nail on the head, does it not?

The book is a great read for anyone with the responsibility to help manage risk in a software project. And with our agile practice of pushing the decisions and the responsibilities to the team who actually implements the system, who isn’t?

Building Scalable, Robust Architecture with Agile: Lessons Learned at Amazon

For any out there worried about whether or not large scale systems can be build with emergent (or intentionally emergent) architecture, I found the following post on the “High Scalability” blog by Todd Huff. http://highscalability.com/amazon-architecture.

In this post, Todd reflects on lessons learned at Amazon on architecture and scalability. The information was derived from various blog posts by Amazoners and interviews and talks with Amazon’s CTO, Werner Vogels.

I don’t know that Amazon applied agility in any defined methodology sense, but you’ll see agility spread throughout the philosophy of build-out and deployment of the architecture. I’ve included only a few pithy agilist-philosophy extracts with respect to enterprise-scale agility below. For a deeper treatment of their large scale, decentralized, SOA-based web services architecture, refer to the post itself and its various sources.

From the post:

• “Only way to manage a large distributed system is to keep things as simple as possible – making sure there are no hidden requirements and hidden dependencies in the design. Cut technology to the minimum you need to solve the problem you have.
• You must change your mentality to build really scalable systems. In traditional systems we present a perfect world where nothing goes down and then we build complex algorithms (agreement technologies) on this perfect world. Instead, take it for granted stuff fails, that’s reality, embrace it.
  

• Create a shared nothing infrastructure. Infrastructure can become a shared resource for development and deployment with the same downsides as shared resources in your logic and data tiers. A service oriented architecture allows the creation of a parallel and isolated development process that scales feature development to match your growth.

• Organizing around services gives agility. You can do things in parallel is because the output is a service. This allows fast time to market. Create an infrastructure that allows services to be built very fast.
  

• Use measurement and objective debate to separate the good from the bad. …. expose real customers to a choice and see which one works best and to make decisions based on those tests. ….get rid of the influence of the HiPPO’s, the highest paid people in the room. This is done with techniques like A/B testing and Web Analytics. If you have a question about what you should do code it up, let people use it, and see which alternative gives you the results you want.
  

• People’s side projects, the one’s they follow because they are interested, are often ones where you get the most value and innovation. Never underestimate the power of wandering where you are most interested.
  

• Create a staging site where you can run thorough tests before releasing into the wild.
  

• Have a way to rollback if an update doesn’t work. Write the tools if necessary.
  

• Innovation can only come from the bottom. Those closest to the problem are in the best position to solve it. Any organization that depends on innovation must embrace chaos. Loyalty and obedience are not your tools.
  

• Creativity must flow from everywhere. Everyone must be able to experiment, learn, and iterate. Position, obedience, and tradition should hold no power. For innovation to flourish, measurement must rule.
  

• Developers themselves know best which tools make them most productive and which tools are right for the job.
  

• Don’t impose too many constraints on engineers. Provide incentives for some things, such as integration with the monitoring system and other infrastructure tools. But for the rest, allow teams to function as independently as possible.
  

• You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer – essential for improving the quality of the service. ”
  

Release Planning at Enterprise Scale – An Inside-Out Narrative

Some of you may have been following the series I’ve been posting on Release Planning at Enterprise Scale. This series of posts is aggregated under blog the category “Release Planning” and identified as (AERP1-n.) You may find it most helpful to read the posts from oldest (#1) to newest (#n) as it makes a better story.

In any case, I got a little bored with my traditional writing style and its abstracted, top-down description of best practices and thought I’d try a different tact for this important practice. The result is an article that was just published in the Agile Journal, which, by the way, is a great source for continuous and current thinking on the state of this movement. It also offers some of the best and current thinking on adoption patterns as well as team-based and enterprise practices.

This article provides an “inside out” (software practitioners perspective) view of enterprise release planning. You can find it here:

Experiences in Release Planning at Enterprise Scale: Two Seminal Days in the Life of an Agile Newbie

I’m interested to see whether readers find this style of writing effective, or not. Please feel free to comment there (on the content) and here (on the style.)

Who Can Afford to Say they are NOT Agile?

In a recent post (Agile Adoption on the Rise? Problems Ahead), Pete Behrens notes that along with an increase in agile awareness comes an increase in the risk of what it means to be truly agile. Pete notes:

“This means that the rise in agile awareness and adoption will coincide with a rise in a veil of “agility” covering almost anything – including traditional software development methods.”

Most of us who coach agile teams have seen this paradigm at work, perhaps a daily Scrum or standup, and perhaps even decent agile project management practices at play. And yet, when you look under the management covers, sprints or iterations are more like mid-development milestones, lots of code in parallel, some features and a demo working in a branch, and yet the teams have not yet mastered the basic mantra of “working, tested code in a short timebox” and the system is nowhere near a “potentially shippable increment”. So long as the teams are working towards that goal, no blood no foul, but if the standup is used as an excuse for agility and the teams are resting solely on their agile project management laurels, and have not mastered the technical practices of shared code ownership, concurrent testing and continuous integration, then that’s a different matter entirely.

Moreover, at the enterprise level. the term “agile” has always engendered such confusion, because after all, what executive would say “no, we are not an agile enterprise?”