Scrum and Management: Planning and Focusing

Scrum and Management: Planning and Focusing Over the last several years, teams of developers have been trying Agile and getting success at their level. Now, management is getting engaged, both to figure out how to do this across divisions and the enterprise, as well as how to do a better job in less-than-simple situations that most enterprises face. There have been notable examples where things did not go as well as expected when teams face complexity, where the fit is not exactly good, where maybe the initial approach taken was just too simplistic. It is management's job to help teams look at ways to improve. This is why at conferences, we are encountering more and more mid-level managers. And they are asking very different sorts of questions than technical, development teams ask. This is stimulating and exciting. Clearly, Agile is beginning to enter the mainstream as a better way to manage software product development. In this podcast, we will touch on two topics Alan that are concerns for management: Release Planning and Focus. Release Planning For example, one of Alan's talks at SQE focused on User Stories. Now, typically, developers want to know about how to use User Stories to write features and code. Managers, on the other hand, ask questions about how to get User Stories in the first place, how to manage them, how to use them to create more business value. This is a great question. It comes from the perspective about why we are doing something rather than what we are doing next. Our approach, which is covered in our Agile Analysis course, uses Minimally Releasable Feature Sets. Here is an example. Suppose you are embedding graphic presentation of data streams on a web page and your customer is very particular about how the graphics look. Looking just at features, you might specify a releasable feature is that you provide a histogram, which is a useful type of chart. A second releasable feature might be a pie chart. Another might be choosing colors. And so forth. Each of these features might involve many stories. The question is what is the minimum set of releasable features required before giving it to the customer? From a technical standpoint, you might want to have them all done first. It feels less risky, technically, and may make for a greater initial splash in the market. But what if, instead, you provided a basic histogram that let the customer validate the entire data collection and display process and the rough placement on the web page? And, with that basic system, they could begin showing it to early adopters in the marketplace and thus begin to establish market penetration? Which option provides the most business value? How would you feel if you targeted release of all of the features in 6 months only to find that your competition promised to release half of the features in 3 months with the rest of the features in another 3 months. Would that put you at a competitive disadvantage? There might be good arguments for various alternatives. The point is that as a product development team, you need to have the conversation and not make assumptions. The outcome of your conversation will be the minimum set of features required for a release. And then you can still talk about how you will package the features into the final release to the customer. This bringing the business perspective to Agile release planning is a needed corrective to what many Scrum teams do. Too often, they dive right into stories and then try to coordinate with Epics and Themes. This local team approach is, perhaps, too narrow of a perspective; it cannot address the portfolio of products that the business needs to be working on.   Iteration Planning Now, it is different when it comes to planning an iteration. Now that you have specified the minimum set of features that will go into the release, you are not constrained to work on one feature and then another. You are not required to work according to adding business value iteration by iterati