Failure: The Road to Success?

Anyone who's been around in the agile space for a while knows the standard agile mantras: inspect and adapt, people over processes, and my own personal favorite: fail fast and learn fast.

Since my personal predilection tends toward trying to ensure success come what may, it's been fairly tough for me to develop a personal discipline of learning from failure. I remember the turning point - it was a keynote session delivered by Henry Petroski at the 2001 OOPSLA conference on Success and Failure in Design. From James Cooper's summary,

"The thrust of Petroski’s lecture was that the design of large architectural elements such as bridges went through a number of evolutionary steps, starting with limited understanding of the physical forces and material strengths and weights and moving towards much more sophisticated design. The key to success in building these structures is a thorough understanding how failure can occur, and design that includes allowing for that failure."

Closer to the agile homestead, and nearer in time, the Lean Startup model has rocketed in popularity. The Lean Startup model contains, I believe, an eminently viable model for agilists to learn from failure, or to experiment in conditions of high uncertainty. Actually, it's called pivoting, and the focus is completely on learning, and not on the failing because of the high speed and low cost with which it is accomplished. Our friend @DavidJBland, with whom I sometimes think I have a Wi-Fi mind meld, tweeted today about success and failure. He reiterates the Lean Startup essentials:

1. Customer Development
2. Business Model Generation
3. Agile Software Development

As David points out: survival without any of the above is pretty tough.

If you're more of a general management than a product management type, you might appreciate this: India's famed Tata group employs an interesting technique in its quest for increased innovation and global growth. Chairman Ratan Tata has instituted a prize for the best failed idea.

Columbia Business School professor Rita McGrath also identifies Google's myriad failed ideas: Google Wave, Google Search Wiki, Google Audio Ads, Dodgeball, Google Print Ads, and Google Answers to name a few, and reminds us that a few blockbuster successes are built on many failures (pivots?).

Your thoughts on the role of failure and learning in success?

Is Your CEO an Agilist?

A few days ago, I blogged about "monumental" agile adoption, and discussed about how large-scale adoption (not just large projects), with 1000s of people involved in an agile transformation needs not just bottom-up, grass roots momentum and buy-in, but top-down executive support. I also was involved in a Twitter conversation about agile companies. The conversation led to how, while the numbers and the scale of agile adoptions are growing, we still need to see more companies leveraging agile methods to deliver business agility.

Jim Highsmith has described agility as, "the ability to create and respond to change." So, by this definition, an agile business must be able to both create and respond to change. It stands to reason that such a company needs executive leadership that understand, appreciates and is able to institutionalize agility. There is direct financial benefit to this sort of Enterprise Agility. As Jim points out, Enterprise Agility generates 30% higher profit.

The theme of this year's Agile Executive Forum, organized by the Agile Alliance in collaboration with the Agile Leadership Network at the Agile Alliance's annual conference is "Now is the Time to move to Enterprise Agility." As my Twitter friend asked me, is their CEO an agilist?

I'll be blogging more on this topic shortly, but in the meantime, let us know: is your CEO an agilist?

"Monumental" Agile Adoption

Some years ago, I had the privilege of being involved in a massive agile adoption at Capital One. That adoption succeeded, I believe, because of the powerful combination of top-down executive support and bottom-up grass-roots momentum.

I've found that, though these large-scale adoptions do not represent the vast majority of adoptions, we still love hearing about them. What is it about these large adoptions that captivate us? I think it is their large, visible, monumental nature that strikes us with awe and respect. [Incidentally, I think this is why we hear (see?) much more about Egypt than the larger and equally accomplished Indus Valley civilization. For history buffs, the Indus Valley civilization is believed to have been democratic, and not authoritarian.]

Anyway, over the past few years, I've been looking forward to hearing more about other, newer monumental adoptions. There are large-scale adoptions underway with several 1000s of people at Siemens and Huawei. Reportedly, 70% of all projects at Huawei use agile methods.

Now, ERP giant SAP reports "all well" with its own monumental agile adoption. Working toward building a "culture of innovation," co-CEO Jim Hagemann Snabe reports that delivery cycles have been cut from 15 months down to 6-9 months. Some of SAP's agile-in-a-large-company specifics, across 14,000+ developers:

1. Forming smaller teams that are empowered to make decisions on their own
2. Customers are in the room from the beginning, not at the very end
3. Switching to Scrum for iterative development, with 4-week Sprints

Hopefully, these changes will help SAP turn its bureaucratic culture around and achieve desired business results.

Meanwhile, Capital One has moved on and is doing well. If you're interested in the larger business focus of how Capital One "loves to change," check out this paper, Building a Change Capability at Capital One Financial: http://ceo.usc.edu/pdf/g08_09.pdf.

Do you know of any monumental adoptions? Do tell...we all love them, don't we?

The PMI's "Agile Certified Practitioner" Certification

After a few years of inexorable movement, we are very close to seeing the Project Management Institute (PMI) launching its agile certification. After some early involvement in 2008 with the PMI Agile Community of Practice, and 2009 at the Agile Conference in Chicago, I had to drop out of the organizing group. So, I am glad to see this movement coalesce and move toward certification. Kudos to Mike Griffiths, Jesse Fewell, Derek Huether (now with LitheSpeed!) and others in the PMI leadership for pulling off this difficult task.

In looking for details about the certification and what it entails, I've found Mike Griffiths' site to be most illuminating. So, here are links to 3 pages that I found most useful:

1. More details about PMI's Agile Certification
2. Inside PMI's Agile Certification Exam Content Outline
3. PMI Cert to be called "Agile Certified Practitioner"

Then of course, we should be diligent enough to review the information coming from the source, so here is the PMI's page on the subject: http://www.pmi.org/Agile.aspx.

I'd like to congratulate Mike Griffiths and Jesse Fewell -- two bridge builders who worked tirelessly for the past few years to make this a reality. Thanks also to Rory McCorkle and his team at the PMI for doing the long hard work within the PMI.

In closing, for those in the LitheSpeed CSM community -- have no fear -- your 16 PDUs earned doing the CSM qualify towards the required 21 PDUs needed to take the exam.

Free Agile Tool!

Did that get your attention? We all love a freebie now and then, but I think our friend David Bland has outdone himself with this one.

Check out David's incredible Blog post on creating a Burndown Chart with Google Docs: http://www.scrumology.net/2011/05/03/how-to-create-a-burndown-chart-in-google-docs/.

Okay so, it's not Version One, but I haven't seen something as simple, light and quick as this in many years.

Thank you David for your yeoman service to the agile community, and for this incredibly detailed, useful and bound to be popular advice!

Stop versus Done, Part 2 of 2 David Bulkin

This is part two of a two part post, so if you didn't read part one yet, you can read it now.

Per part one, it is easy stop work on fine grained tasks without ever getting anything to the point where it is truly done.

Good agile teams have just a few stories in play at a time, and use the story acceptance criteria as the most basic definition of done.  They also include additional generic criteria at the story level that must be met, such as the code is checked in.

At the feature level, we rely on the product owner to define done, as they decide if the stories already completed address the feature sufficiently enough, perhaps to the point where no further work is required for that feature.

In this post we will look beyond the story and feature level to the sprint level and beyond.

Sprint Level Criteria

Sprint level done criteria covers items that are addressed in aggregate, instead of at the user story level. Some samples that may apply are listed below.  

1. Installation documentation has been updated
2. Security scans and tests performed and all problems addressed
3. Installation scripts have been updated and tested
4. Release notes have been updated

Why not at the Story Level?

Getting to done earlier rather than later is a good thing so you could specify the above criteria at the story level.  One way of deciding if criteria should be applied at the sprint level is to ask if it will be best for one person (not necessarily the same person each sprint) to be responsible for this criteria for all stories in a sprint.

As an example, you want one consolidated set of release notes that is coherent across the team.  It is easy to have one person be responsible for updating the notes getting input from the rest of the team.

Why not at the Release Level?

The criteria that we listed as sprint level, could be story level criteria, but most teams, especially those new to agile, do the reverse and keep them as release level criteria.

For example, security testing is frequently deferred until just before a release, generally because it is painful to deal with the large number of exceptions found. 

Does waiting make it less painful, or does it just push increased pain off until the future? 

The simplest way to make the pain go away is to perform the security test more often, perhaps daily (maybe even with each story, thus making this story level done criteria). The fast feedback simplifies the remediation work.

Across Multiple Sprints

We prefer not to defer, but there are some things that may best occur outside the context of a single Sprint. One common example is performance and load testing. 

Perhaps the test environment we need costs several million dollars and is shared across several teams. In this case, maybe we only get a testing window every other month for a week. Assuming two weeks Sprints, this means that our done criteria must span four Sprints.

What happens if we find serious performance issues after four sprints of work? 

• Do we have to unwind many hours of work?  
• Do we have to create multiple branches of code? 

Ok, you already got that point, delaying the feedback cycle is a bad thing. But let’s assume, that in our example, we simply can’t get to the performance environment more than once every other month.

Would it be possible to do performance and load testing on a scaled down environment that would shorten our feedback cycle and allow us to address most issues early? 

• In many cases the answer is yes, if so, you can include “Passes load and performance test on scaled down environment” as part of your sprint level done criteria. 
• Your release level done criteria can then include “Passes load and performance test on environment that models production”.

Release Level

There should be little deferred to the release level.  Items that are truly release level should generally be at the periphery of the teams work, like training for the impacted staff, assisting with verbiage for the sales campaign, etc.

Closing

Create your done criteria to ensure rapid feedback and recognize that deferring the point at which you reach done likely increases pain and complexity, while balancing this with the need for your done criteria to be practical.

As always, feedback is welcome.

Stop versus Done - Part 1 of 2 By David Bulkin

Project manager often rely on detailed task lists to monitor progress. The thought is that having lots of fine grained tasks provides visibility.

Unfortunately it is easy to get lost in the details and we often end up being lax in determining if a task is truly complete. As such, we simply consider a task done when the assigned individual stops work on it.

Just because work is stopped, doesn’t mean that anything valuable has really been done.

Good agile projects track just a few user stories (instead of many tasks) at a time and apply strict criteria, specified in advance, to determine when a deliverable is truly complete, e.g. done.

This post, and the follow up, help your team define done criteria at various levels, from story to release, in a way that will engender fast feedback and increase effectiveness to define done criteria in a way that encourages early feedback and ensures that when we stop, we are truly done.

In this first post we will look at the basics, user story and feature level definitions of done.

Story Done

A user story is not done until it meets all story acceptance criteria and has been accepted by the product owner. In addition to the user story specific acceptance criteria, teams should have generic story level specifications similar to the following.

1. Code has been checked in
2. The agile lifecycle management tool and task board have been updated
3. Testing has been performed and the code passed
4. Code has peer reviewed and approved (e.g. code is clean)
5. Automated testing is in place for the code
6. Help system has been updated to reflect changes to the story

Don’t Defer Testing

In all cases we want to define done criteria in a way that encourages early feedback and ensures that when we stop, we are truly done.

A primary example is testing which we have included as story level done criteria. All too many teams defer writing test cases for a story until after the coding is stopped.  This means that in most cases the code is not tested until the subsequent sprint.

Testing a sprint behind defers feedback and results in a cascade of complexity as we eventually have to resume coding that we had previously stopped (e.g. we weren’t really done).

For example, assume we are in Sprint 12. What happens when find a large number of bugs in the stories that we stopped coding in Sprint 11?

• Do we stop work on the user stories planned for Sprint 12?
• Do we continue some work on our planned stories and spend some time fixing bugs?
• Or do we just defer the bug fixing to Sprint 13?

When when we stop coding and then do testing, we are really not done coding because testing will find bugs. As such testing should occur roughly in parallel with coding and be completed in a single sprint, meaning our story level done criteria should include that all tests have been executed and passed.

Help System Updated, Another Example

The update of a help system is interesting as, with testing, it is often deferred.  In the case of help systems, they are often specified as release level done criteria.  The logic is that the technical writer is a part time team member and teams want to have everything in place for them.

Our goal is to make the team and organization more effective, not to optimize the performance of the technical writer. 

Documenting a user interface is a great way to help with quality. If a UI is hard to document, it is generally also hard to use, so if we work on end user documentation in parallel with the development work, the feedback informs and improves our design.

So include the help system update as a story level done criteria (or perhaps you can include as sprint level criteria if your sprints are generally focused on related changes) and modify your teams approach, by sharing the writing load or by getting more writing resources. 

Feature Level Done

The done criteria for a feature (e.g. something to big for a sprint, a.k.a. an epic) can be viewed as getting to done on enough of the high priority child stories (e.g. the sub stories) to the point where the product owner believes that no more stories should be worked on.

As most good agile teams have learned, this means that we often decide not to work on many of the original user stories we created. Sometimes the best decision we make is what not to work on!

Closing

In summary remember not to confuse stopping work with being done, don't defer to later what you can do now, and also remember that you don't need to do everything you originally specified (e.g. less can be more especially at the feature level).

In part two, we will look at definitions of done for the sprint level and across sprints.