Viewing entries tagged with 'agile'
In my last article on Discovery Sprints I mentioned the concept of Discovery Coaches and several people asked me about that, so I thought I’d describe more about what this role is and when it’s helpful.
I find that many teams, especially those new to modern product techniques, are looking for a structured introduction to modern product discovery. In this article, I’d like to describe the concept of a discovery sprint, and also introduce you to a new book that goes into depth on this technique.
Most of us are working on solving some pretty hard problems, and it usually ends up taking some fairly complex systems in order to power these solutions. As such, for most teams there are two very significant challenges to tackle:
I should have written this article many years ago.
Starting around 2004 and 2005 I began seeing an increasing number of teams moving to Agile, and of course the first thing they needed was training and often some coaching.
However, more often than not, I had to go into these companies after the training and try to clean up the mess that the trainer left behind.
Note: This article is a collaboration between myself and my long-time friend and colleague Jeff Patton. We often work together to help product teams.
In my last article, I discussed how we manage public commitments in an Agile, Dual-Track environment. In that article I talked about those public commitments that are needed to run a business, such as when a customer can count on getting some capability, or when a development partner can plan on testing, or determine what will be available for the upcoming holiday season.
The past several articles have discussed the nature of Continuous Discovery and Dual-Track Agile. In this article I'd like to discuss another dimension of working effectively in an Agile environment, which is how we manage commitments.
When I first start working with an Agile product team, one of the most common situations I find is where the teams have long and frustrating Sprint planning meetings because backlog items are poorly defined and not well understood; they have slow velocity as well as poor design because details are still being worked out during the Sprint; and the amount of waste and rework is very high because backlog items have not been validated.
Recently I spoke with a team of very frustrated Scrum engineers. They were frustrated because they felt like all they were doing for the past year was chasing features and that the product manager really had no clue where they were heading or what they were really trying to accomplish. When I spoke to the product manager (product owner in Scrum lingo), he explained that he thought the whole idea of Agile methods like Scrum was to remain flexible and “agile” and that he didn’t think he was supposed to worry about or lock in a longer-term direction.
Many software product teams are either currently experimenting with Agile methods, or have recently moved. I have written elsewhere about the benefits of Agile methods, including Scrum and XP, but I wanted to highlight here the keys for product management in an Agile environment.