Agile Accelerate

April 9, 2012
by jim Leave a comment

Broadening the Grounds for Self Improvement

We all have our least favorite phrases or questions that come up in day to day coaching. One of mine goes along these lines: “No one has complained about this, so why change?

————–

How many of us complained about not having a PC on our desk before HP created one and Apple popularized it?

How many of us complained about not having a mouse and a point-and-click interface before Xerox PARC invented it and Apple popularized it?

————–

Making changes that address complaints or known problems certainly makes sense. But doesn’t it also make sense to make changes that simply improve the ability to deliver, even if there isn’t an obvious problem to solve?

For just one example, I have worked with teams who used a big visible task board to track progress on their stories, but the board was so confusing that it didn’t add much value. Simplifying it and making it more readable generally helped to improve the clarity of each story status and the progress of the sprint, and I would notice people starting to have discussions around the board. Conversations improved, collaboration increased, and the team performance often went up as a result. Yet, no one had ever complained about the board.

When a team retrospects, they often focus on the things that didn’t go well over the past sprint. For instance, they might devote a few collective hours of time to solving a very specific problem that was raised; e.g. “I didn’t have the login credentials necessary to access this particular database that I needed to consult to find out some information for my story.” But, instead they could have spent time figuring out how to collaborate better on identifying business requirements – an activity not driven by any complaints or problems, but one which could generate significant benefits in terms of velocity or delivering value.

————–

How many of us complained about not having a web interface on top of the Internet before Mosaic?

How many of us complained about not having a smart phone before IBM created one and Apple popularized it?

————–

Marcus Buckingham, leader of the strengths movement , notes that a person’s “greatest room for growth” is not one of their weaknesses but their strengths. Might not this also apply to agile teams?

What if, instead of always focusing our retrospectives on fixing the things that are broken, we sometimes take a critical look at things we already do well, but could get so much incremental value out of doing even better?

Investing in cross training, for example, has to potential to be one of those practices that can generate huge improvements in team productivity, even for a team with already broad skill sets. A team could become so efficient at being cross functional that they never would find tasks blocked due to the lack of an available person with the right skills or knowledge. Tasks and stories will flow even better and overall team productivity can only go up. The same might be said for building foundational principles like commitment and empowerment.

Continuous improvement isn’t about fixing problems. It is about inspecting everything that you do, good and bad, making decisions about where change can make the most impact, and validating your decisions.

January 5, 2012
by jim Leave a comment

Agile Myths Busted

Ever run across these guys? People whose lack of experience or fear of change cause them conjure up all kinds of reasons why agile won’t work for their project?

Let’s bust those myths!

Myth: Agile Doesn’t Work for Projects in the Highly Regulated Medical Environment. (The reason usually given is that FDA regulations require detailed requirements prior to project approval; hence, waterfall. However, in reality, you can develop in phases, with small incremental sets of requirements and the FDA requires only enough documentation to demonstrate your process.)

Truth: Abbott Labs overcame medical device regulation and stringent Class 3 certification and developed the m2000 Real-time PCR Diagnostics System, a human blood analysis tool, with four agile teams. Compared to the prior methodology in use, this project resulted in a less cumbersome process, fewer defects, a reduction in costs of 43%, and a reduction in cycle time of 25%.

(Rasmussen, R., Hughes, T., Jenks, J. R., & Skach, J. (2009). Adopting agile in an FDA regulated environment. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 151-155)

Myth: Agile Doesn’t Work in Government

Truth: The FBI overcame a CMMI level 3, ISO 9001, government-mandated document-driven waterfall life cycle and developed the Domestic Terrorist Database & Data Warehouse with three agile teams. Compared to the prior methodology in use, this project resulted in significant improvements in release planning, developer satisfaction, and a focus on the true goal: “to catch bad guys.”

(Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 96-100.)

For another example, the U.S. Department of Defense developed the Strategic Knowledge Integration Website utilizing three agile teams. Compared to the prior methodology in use, this project resulted in improved quality, fewer defects, better teamwork, and a 200% productivity increase.

(Fruhling, A., McDonald, P, & Dunbar, C. (2008). A case study: Introducing extreme programming in a U.S. government system development project. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), Waikaloa, Big Island, Hawaii,USA, 464-473.))

Myth: Agile Doesn’t Work for Large Products

Myth: Agile Doesn’t Work with Distributed Teams

Truth: Google’s AdWords product busts both of these myths. With 20 teams and 140 people across 5 different countries, this large agile program was a groundbreaking success at Google and resulted in more predictable releases, higher quality, and an improved ability to accommodate changes, as compared to the prior methodology in use.

(Striebeck, M. (2006). Ssh: We are adding a process. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 193-201)

Myth: Agile Doesn’t Work in the Regulated Telecom environment

Truth: British Telecom moved their entire IT department to agile, starting with 2000 people from 2004-2007. This large transformation resulted in an improvement from 10% value stream effectiveness to 55%, created an attitude of delivering real value to the business through IT, and shifted the company’s perception of IT from a service provider to an integral part of the business solutions.

(http://www.agilistapm.com/casestudy-british-telecom/. http://scalingsoftwareagility.files.wordpress.com/2008/06/scrumbt-v14.pdf)

Myth: Agile Doesn’t Work for Client-based projects

Myth: Agile Doesn’t Work for Fixed Price projects

Myth: Agile Doesn’t Work well when integrating a Third Party Product

Truth: I coached an agile team at a prominent consulting company through a project with a client who was a well known record label. They built a new, fully rebranded, eCommerce website using open source CMS and Search engine, and a third party eCommerce provider. The site included product bundling, integrated music player, and social networking integration. It was implemented using Scrum/XP with a single team of about 12 people over 5 months. The result was an award-nominated site that improved conversion rates dramatically, ultimately profitable for and considered a strong success for both the agency and the client.

Myth: Agile Doesn’t Work for Manufacturing Vehicles

Truth: Wikispeed developed a 4 passenger, 100 mpg, street-legal road car in 3 months using modular, off-the-shelf, carbon-fiber body construction, with no capital investment, and no paid employees. Agile processes were utilized with a single international team. The project went beyond the prototype phase and cars are available online.

(http://www.solutionsiq.com/the-agile-ceo/bid/51480/Agile-Innovation-or-How-to-Design-and-Build-a-100-MPG-Road-Car-in-3-Months)

What else ya got?

(note: leads for some of these case studies came from David Rico’s presentation on Lean & Agile Project Management for Large Programs & Projects)

January 4, 2012
by jim Leave a comment

An Agile Vacation: Why Agile Coaches Shouldn’t Take Stickies Abroad

Some of the people on my teams like to play a game called “Tease the Agile Coach by Pretending Everything He Does is Agile.”

Last fall I went on a 2-week vacation with my wife in France. When I returned, of course, the gag was “Did you run your vacation agile style?” “Did you start every morning with a scrum?” I love playing along, but as I thought about it, to my horror, there was a lot of “agility” to my vacation, and maybe their teasing wasn’t so far from the truth.

As an example…

We spent three days in Paris and the rest of our time roaming around the country in a car. It was essentially a sightseeing vacation. I maintained a big list of things that we intended to see.

A Backlog.

Much of the time, we woke up in one town and the only real objective for the day was making it by nightfall to a town where our next reservation was.

Sprint goal.

While we might have several things we wanted to see and do every day…

Sprint backlog.

…there were always things that got in the way of our plans, like unexpected traffic or bad weather. Sometimes we simply left a little late having spent extra time savoring our croissants and café au lait. As a result, we might have to drop the least important excursions.

Continuous prioritization.

We wouldn’t always have a clear idea of exactly what we wanted to do once we arrived at a new destination, but we usually had no problem coming up with a plan.

Grooming the Backlog.

At one point, we found ourselves in the Alps with inclement weather. My plan to take the cable car up to the top of Mont Blanc fell apart because they were having snow and whiteout conditions at the top of the mountain and high winds closed the cable car. So we changed plans and headed south to the Riviera one day early.

Sense and respond.

At the end of the trip, during the TGV ride back to Paris, we reflected on our trip. I asked my wife if she were to plan the trip all over again, what would she do differently?

Retrospective.

I don’t know whether to be embarrassed or proud.

At least the inside of our car wasn’t covered with stickies.

October 11, 2011
by jim Leave a comment

The Math Behind Agile and Automation

Every once in a while, we encounter individuals on our teams who have a healthy dose of skepticism about these new Agile practices they are learning. For those who tend to be scientifically-minded, or need more evidence than just a good story, I have found that it is important to give them real data to look at.

As an example, it is interesting to combine the usual Cost per Defect curve for a software project with a histogram that maps the probability or frequency of finding defects to the corresponding project phase. The result is mathematical support for both Agile as well as the value of Automation and good Agile QA practices.

Figure A below shows the typical Cost curve for a waterfall project (source: The Economics of Testing, Rice Consulting) along with an overlay showing the probability of finding defects in various phases of the project.

As can be seen, most defects are found during the testing phase, as one might expect. Using some industry standard numbers, the cost to fix per defect is about $490.

Note, however, what would happen if you are able to find defects earlier in the process.

Figure B shows the same cost curve, but the histogram representing the probability of defects found is pushed earlier in the process. The kinds of practices that might result in such a change include collaborative QA and developer testing, pairing, and automation (which helps prevent the defects from being found in the expensive tail of the curve). This doesn’t mean spending more on QA, just utilizing tighter feedback loops that help prevent defects from getting to the later phase of the project. So, even with a waterfall process, or a non-agile iterative process, one can easily see how collaborative testing and automation can reduce the cost of defects considerably, in this case down to $220 per defect.

The Agile cost curve is actually a little different, as shown in Figure C.

There is still the hockey stick effect when the software goes into production, but the rest of the cost curve would be flat, since the cost of fixing is pretty much the same from iteration to iteration. The defect frequency histogram is drastically different and is flattened and spread out across the entire life cycle of the release.

In this model, Agile practices alone, such as sprint-based functional testing and having QA and developers working off of the same requirements, are responsible for about a factor of two improvement in overall cost of defect fixing per release. Automation and good collaborative practices are responsible for another factor of two, which gets the overall cost per defect down to about $130.