What if Congress used Agile?

Eric Camulli posted this interesting question in the Agile Alliance LinkedIn group:

Could Agile help Congress with healthcare reform? I'd like to see someone take a stab at applying scrum principles to the "great development project" of our day...

Our country's healthcare "project" could end up looking like many Waterfall projects...not on time, over budget and not meeting customer's needs in the end.

Unfortunately the conversation quickly started to veer off into moral, ethical, and political opinions/viewpoints/jokes unrelated to agile...

But I thought about this a little bit and I did find some comparisons between our legislative system and large companies that aren't agile. Here is what I ended up writing:

I think the real problem with anything going through Congress is that they don't "go to the gemba". They rely too much on research and lobbyists to translate the needs of the "customer" for them.

Congressman act as if they are Product Owners, but they don't have the domain knowledge or "end user" interaction to truly own that role.

So... I guess my solution is that we need to find a way to decrease the feedback loop distance between those affected by policy and those creating it.

Does anyone else have any ideas or insight into this one?

The PO is part of the team, get over it!

The other day I posted about charging a fine for being late to the standup. I knew this would get some reactions, but one thing I should have been clearer about was that this wasn't a team problem, it was a PO problem. Sure enough, several of the LinkedIn forums got fired up over it and some heavy hitters had some good points to make (thanks Rachel Davies!).

I agree that this concept can backfire (fine, I'll pay the fine so I don't have to come), and there are solutions to that (double the fine for each offense). I also agree that if the majority of people need a fine to appear at the standup, then there is a much bigger problem occurring.

So, that background aside... one of the conversations appropriately focused on the issues we were having with the Product Owner. Why didn't he want to participate? Why was this an issue?

Lesson learned on that point: when this company went agile, we trained the developers, then the QA and analysts. Following the rules of Scrum & XP, we understood the metaphor of the Chicken and Pig very well. Unfortunately by following this rule, we optimized the team but de-optimized the whole value stream. It wasn't until the PO's got some agile training that they understood how to evolve for the new agile world.

This post is in response to the following comment in regards to fining the PO for being late to the standup:

Why wait for the PO for a stand up? The PO should not be in a position to cause the problem. We try and utilize the Chicken and the Pig approach.

And my response:

There are many people who feel the PO is a member of the team: http://www.danube.com/blog/dan_rawsthorne/who_is_the_project_manager_in_scrum
Thus making them a Pig.

Also, the chicken and pig concept is dead in my mind. It's a coping mechanism for bad managers: http://www.langrsoft.com/blog/2008/08/pigs-chickens-and-asses.html

As our agile team matured, we found that many of our early retrospective discussions led back to the fact that the PO wasn't accessible enough. When your PO is the voice of many customers distributed globally, the PO is very important. If you have direct access to your customers (example: internal employees), then this might not be as important.

The last thing you need is for a team to go to the sprint review and demo lots of software that fails PO acceptance. Instead of making decisions in his absence and hoping they were right, avoid this waste and just treat him as a team member. If you can't do this, then get a proxy in place (lead analyst), or get direct access to the most important users to reduce the risk (beta customer).

Market Take-over vs. Proven Success...

My first agile project began as a disaster, which is why we chose to try agile. Nothing else had worked, so we threw agile at it knowing the ship was starting to sink. Thus far, we were always 2 years from delivering. The beast was huge and we were doing more work descoping and handling change management than actually getting functioning code out the door. Oh, and we were under ISO and other audits (risk mitigation being more important on a life critical system.)

But, it ended up being one of the best teams and projects I've ever worked on. I still stay in touch with many of the people on that team and it was such a huge turn-around that many of us have been working with agile since then.

This morning I was reminded of this as I read Przemysław's blog post about "Half-dead projects". It reminded me how our project start was focused on a team of 5 clinicians pulling from their various experiences to create the "scope" and requirements needed to displace competitor products from the market. They spent over a year figuring out what it would take to perform a market take-over. The goal was to be a #3 product in the space within 3-5 years. Starting from nothing, that meant we had a long path to pursue. To make it worse, our product had to be a global product fulfilling all the needs of each culture and continent. There were always exceptions and special cases uncovered every day for a specific country or language. We were constantly descoping to pretend our deadline was obtainable. Our focus was on the day where we sold our product to 25-50 customers.

Then one day we realized we were close to being done. Unfortunately it was "dead done", not deployed done. We needed to survive. We had a contract in place with a beta customer... they also needed us to survive. So we threw the kitchen sink at it and we went agile.

On some level we threw out the entire MRS, PRS, SRS, and 50 other piles of documentation. In 3 days, we created a whole new backlog with stories and estimates. Then we stepped back and we realized this was still too much.

So we threw that out and started again. We went to the beta customer and asked... "What do you need to start using this?" What they "needed eventually" turned out to be much different than what they "needed to start". Turns out, a lot of time is spent setting systems up in the health care setting. Provide some screens to start configuring x, y, and z... it will be 2 months before that is ready to be used. Build this next... etc. We focused on one customer... right here, right now. Every 2 weeks (instead of every 3 months), we demonstrated what we had built and we asked what was next. Our product owner made sure that none of our steps were unique to the one customer and our work still fit the long term global strategy (you can't focus completely on right now), and we kept making little victories.

Six months later, that beta customer had software in their hands. Think about that... we went from 2 years to 6 months. It turned to be much more important to have one active customer than 15% of of our product built.

My favorite confirmation was when they told us how much better the process was. How they now understand why it was so hard and that by being involved, they could work with us as a team to make hard decisions and insure something of value was handed to them sooner.

That is one of the core impacts of going agile! You know it is working when you have proven success! I now believe that a market take-over is achieved by convincing EACH customer to buy your product or service. It is not done by defining up front what they all need. Every customer is slightly unique. Prove that you can make one customer happy, then five, then 20, then 100.

You can take over the world one customer at a time with proven successes. You can't do it any other way.

What makes a good Product Owner?

Kanban Jedi put up a good blog post about Product Owners. After a little banter back and forth, I figured I had a few words to add myself:

• If you have a single customer, the mature agile team doesn't need a product owner. Their customer is the product owner. Direct communication is critical.
  
• If you have many customers (for example, 6 beta customers and a market potential of 100's), then you need a product owner to go out and be the liaison between all these opinionated parties. It is the product owner's responsibility to find the core set of requirements for all customers without including requirements unique to a few.
• Your product owner should understand technology. Prioritization of the backlog is greatly dependent on understanding the cost of features which includes the complexity of building them. A basic understanding of technology will aid in this discussion. If they have implemented a software system, then they at least have an idea of how complex it can be.
• Your product owner shouldn't represent the techonlogy, but instead represent the domain. They represent the customer. The customer doesn't care what language it is coded in, or how cool the algorithms are. They want something that meets their business needs. Make sure the product owner is responsible for the domain first and foremost. They should not be the architect or tech lead or anything close to that role.

Anything you would like to add to the list?

2 great links...

• You get what you measure posted on Daniel Brolund's Weblog. It's a good factual background on a point I've made previously about not abusing your metrics.
• The product owner and the product-shaped hole posted on AgileProductDesign.com. Very thorough post about the role of an agile product owner or customer and how it is much more than stories and software functionality. Actually, it is a good follow-up to one of Jeff's past posts about the backlog.
  

Enjoy!