Tag Archives: lean

A Better Project Model than the “Waterfall” – Jeff Gothelf – Harvard Business Review

Quote

Posted on by
Reply

Despite the confidence inspired by all of this upfront planning and design, the only guaranteed thing to come out at the end of this waterfall process is the wrong solution.

Instead of presenting their teams with lists of features to build in a sequence, organizations should present their teams with business problems to solve. Provide constraints for the solution and any assumptions that currently exist about that business problem and its target audience. Most importantly, each team should be handed specific success criteria. These criteria should be quantifiable and point to specific outcomes that prove the customer’s need has been met and the business problem has been solved.

via A Better Project Model than the “Waterfall” – Jeff Gothelf – Harvard Business Review.

Great article Jeff!  Focusing on business problems and not “requirements” is something I’ve been working on with teams for awhile now.  It can be a difficult transition to make, but definitely worth it.

Creating a Kaizen Culture for a High Maturity Agile Organization | The Agilista PM

Link

Reply

Creating a Kaizen Culture for a High Maturity Agile Organization | The Agilista PM.

An agile transformation is far more than simply a process change.  At it’s core, an agile transformation is a culture change.  Ensuring you have a “kaizen culture”, or a culture that fosters continuous improvement is key to success.  I started my professional career at Caterpillar where I learned about 6 Sigma, Kaizen, and lean.  That foundation of learning is what really got me interested in agile.

Is Working Software Enough?

Posted on by
4

For the past few weeks, maybe even months, I have started to feel like the dynamics between the Scrum team and myself, the product owner, were not working in the best interest of the product overall. The team seemed very concerned about achieving a high velocity. They showed reluctance to slow down and spend more time in “grooming” and planning. Previously, in an effort to optimize velocity and reach “hyper-productivity” the team had capped the amount of time the product owner could use for grooming at 5% of the sprint. However, I was starting to think that really wasn’t enough time. It was forcing a lot of important design decisions off onto myself and the UX designer without getting the opportunity to explore different options and get feedback from the development team. There may be situations where this setup works well, however I have a very smart and talented development team and I felt that spending more time grooming and brainstorming potential solutions to the problems on the backlog with the team prior to designing the solution would, in the end, result in a much better product. Not only that, but that additional grooming time would help increase the shared vision among the team which also seems to have been suffering. So I began to think about what the root of this problem was and why this reluctance might exist.

What about value?
One of the core values of the Agile Manifesto is…

Working Software over Comprehensive Documentation

Don’t get me wrong, I definitely agree that working software is much more valuable than comprehensive documentation. However, is working software really enough? What about valuable software? What about software that delights the customer?

If you go past the manifesto and dig into the Principles behind the Agile Manifesto, you see that the very first principle gets at this point as well…

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

So there we have it, the highest priority is to satisfy the customer with valuable software. I wonder, if this really is the highest priority, why didn’t it earn a spot on the actual manifesto? The fact that it has been left off the manifesto itself seems to have driven some potentially suboptimal practices. If you look at most of the mainstream materials out there on Scrum, for example, there are lots of resources talking about how to track and calculate velocity. But what is velocity? It is simply a measure of how fast the team can deliver working software. It helps the product owner determine how long it will take to get through the backlog. This is definitely important and useful information…but where in the manifesto or the principles do we value development speed? I can’t find it mentioned anywhere. So if we don’t value speed, why is it the primary thing we are measuring?

If our highest priority is “to satisfy the customer through early and continuous delivery of valuable software” shouldn’t we be measuring that? Shouldn’t we be measuring the amount of value delivered per sprint, or the effect of a sprint on customer satisfaction? Granted, these are much more difficult things to measure and track, but I have never even encountered the idea of attempting to track this mentioned in any mainstream agile materials. If we aren’t measuring and tracking it, how can we hope to optimize it? Instead, we are measuring and tracking velocity, so that is what we will naturally optimize. Scrum says it is the product owner’s responsibility to maximize the value of the product, but I have found few resources with suggestions on how to do that. I also haven’t found any mainstream materials that even recommend tracking value in a measurable way or pay attention to a metric such as value delivered per sprint or release. Instead we plaster velocity everywhere. We externalize the tracking of value and assume it is being optimized while we focus on optimizing velocity when in reality, we should all be focusing on optimizing value.

Thoughts from Agile2011
I was pleasantly surprised at how well many of the presentations I attended at Agile2011 tied into the value concept. I sat in on a few Lean Startup sessions and that movement seems to be much more in tune with this idea. Typically, they will complete one thing at a time, release it into production, and measure the results in order to validate their prior assumptions, then take the knowledge they have gained and make some more adjustments. So they definitely seem to put more value on the outcome (increased signup, conversion, or whatever they are trying to improve) than the output of working software. There was a great example of this recently on 37signal’s blog where they walk you through how they set out to increase the signup rate on their Highrise homepage in a three part post (Part 1, Part 2, Part 3). They had a goal of increasing the signup rate, so they would make a change, push it to production and do A/B testing to see the result. They would then take what they learned and make further tweaks, measure again, and keep repeating until they were satisfied with the results. This is definitely much more focused on delivering value than the typical agile project I have seen.

The Design Thinking camp also seems to be on the right track. I missed Mary Poppendieck’s presentation on this, but was able to attend a separate session on Design Thinking and reviewed Mary’s slides afterward. She is definitely in agreement that “the only valid measure of our success is their [product owner] success” implying that if the product owner is not tracking and prioritizing for optimal value, it really doesn’t matter what your velocity is. She also has a lot of good information on her blog like Don’t Separate Design from Implementation that talks about some of the problems with pushing the focus of design and value off the Scrum team.

I also sat in on a great presentation by Steve Denning about Creating Customer Delight that is summed up very well in his posts on Forbes.com entitled Agility is not Enough. He makes a very good argument that satisfying the customer with valuable software is not enough. We should be focused on delighting the customer. In fact, not only should the agile development team focus on delighting the customer, it should be a strategic objective for the entire company.

Next Steps?
Hearing all these great ideas at the conference helped me see the bigger picture and see what may really be at the root of the problem. Velocity is being measured and plastered all over the place so the team is very focused on optimizing velocity instead of optimizing value. Also, with many of the comments I heard from other attendees at Agile2011, it seems that this problem is much more widespread than just my team. I can definitely understand how this is a problem with the fact that what is claimed to be the “highest priority” principle associated with the Agile Manifesto is constantly glossed over and not emphasized in much, if any, of the mainstream materials. Not only that, but there is almost always pressure from above to “go faster” and now, with agile, we have this nice easy metric of velocity to measure how fast we are going.

So how do we get this intense focus off of speed and shifted onto value? I definitely don’t have the answers and am still working on ways to measure value and increase the visibility of that measure so it can be optimized. I’m also working to communicate that increased velocity is not the ultimate goal. Sometimes you have to slow down to speed up. However, I fear that communication can only go so far. Until there are measurements around value that are given as much visibility as velocity, the desire to optimize what we are measuring may just be too much. How does your team measure value and work on optimizing value?

Agile2011 Recap

Posted on by
Reply

Agile2011 in Salt Lake City is wrapped up now and I am back home.  I had originally planned to do some summary posts while I was there, but with all the great company and activities I just never found the time.  I did find the time while out in the west to do a little mountaineering though!  Myself and another agilist from the Indianapolis area hiked up Mount Olympus Sunday afternoon.  It was a great view, though my legs were sore for most the rest of the week.

The week started out with a great session from Mary Gorman and Ellen Gottesdiener entitled The Product Partnership – Using Structured Conversations to Deliver Value.  It was basically one of their training sessions squished into a 3 hour session giving an overview of a framework they have developed to help guide agile teams in structured conversations to ensure that iterations are resulting in real value to the customer.  I look forward to looking into their framework a little more closely as I think it can definitely help address some of the issues our team has been experiencing.

There were several great user experience related sessions I attended.  Product Stewardship by Tim McCoy discussed better ways at integrating the UX team into agile teams.  In Integrating UX Into Agile Jon Innes gave an overview of a matrix that he uses to help track the status and impact of user experience related work.  Finally, in my final session aside from the closing keynotes, Jeff Gothelf gave an amazing overview of Lean UX and how to effectively utilize UX in an agile environment by getting the UX team out of the deliverables business.  All of these fit together very well and have provided me lots of ideas on ways to improve the UX processes on my current team.

Another grouping of sessions I attended focused on Agile Leadership, Lean, and Customer Delight.  Jim Highsmith gave a great presentation on Adaptive Leadership, Abby Fichtner gave a good overview on Lean Startup with some good follow-up discussions on how this related to Agile, Mike Russell gave a good overview of Design Thinking, and Steve Denning gave a great presentation on Creating Customer Delight.  Looking at the description of these I did not really expect them to relate much at all, but all of them inter-related very nicely suggesting that there is something beyond Agile.  Steve even suggested that maybe it is time to revisit the Agile Manifesto, that perhaps it could use some revisions.  I hope to expand on this seed of though with a follow-up post in the near future.  In the meantime, however, Steve has a few great articles over on Forbes.com (be sure to click through to parts 2 and 3).

In addition to these great sessions (and this is just a sampling of the sessions I attended) the Agile Alliance did a great job at selecting keynote speakers.  Kevlin Henney gave a very interesting presentation on code and some different ways to look at and think about it.  Then there were the two seemingly “weird” presentations focused much more on our emotions and mind and how Positive Thinking (Barbara Fredrickson) or an Agile Mindset (Linda Rising) may affect our work.  I’ll admit I was as skeptical as anyone about these talks, but I’m very glad the organizers took the chance to bring in these talks as they were very thought provoking.  Linda’s talk was especially interesting, being that I am the father of a four year old “bright little girl”.  I was glad to see I was not the only person in the audience that enjoyed the talk as Linda received a well deserved standing ovation at the end.  I will definitely provide a link to the recording once it is available.

If you didn’t make it to Agile2011, I definitely encourage you to check out the content on the website.  They are still working on getting some of it available, but hopefully every sessions will have links to slides soon and some of them were recorded as well.  If you are involved or interested in Agile at all, I definitely recommend this conference as something to look at attending in 2012.  You get exposure to lots of great ideas and have lots of time available to discuss those ideas and maybe some of your own thoughts with the leaders in the field.