Viewing entries tagged with 'agile'
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.
If your engineering team hasn’t already moved to some form of Agile methods (like Scrum or XP), then it’s likely they’re at least considering it. Agile really does attack some key problems that have plagued software teams for decades. But many product managers and designers, and to a lesser extent QA staff, are initially confused by Agile, unsure of their role in these methods. To be clear, these methods absolutely require these roles, but I attribute the confusion to the origin of Agile methods, and I’ve found that when I explain the origins, it helps to illuminate the problems that Agile was designed to solve, and what challenges remain.
NOTE: "Design" below refers to User Experience Design, and not Architectural or Systems Design.