Make Stories Small When You Have "Wicked" Problems

If you read my Three Alternatives to Making Smaller Stories, you noticed one thing. In each of these examples, the problem was in the teams’ ability to show progress and create interim steps. But, what about when you have a “wicked” problem, when you don’t know if you can create the answer? If you are a project manager, you might be familiar with the idea of “wicked” problems from   from the book Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms. If you are a designer/architect/developer, you might be familiar with the term from Rebecca Wirfs-Brock’s book, Object Design: Roles, Responsibilities, and Collaborations. You see problems like this in new product development, in research, and in design engineering. You see it when you have to do exploratory design, where no one has ever done something like this before. Your problem requires innovation. Maybe your problem requires discussion with your customer or your fellow designers. You need consensus on what is a proper design. When I taught agile to a group of analog chip designers, they created landing zones, where they kept making tradeoffs to fit the timebox they had for the entire project, to make sure they made the best possible design in the time they had available. If you have a wicked problem, you have plenty of risks. What do you do with a risky project? Staff the project with the best people you can find. In the past, I have used a particular kind of “generalizing specialist,” the kind where the testers wrote code. The kind of developers who were also architects. These are not people...

Three Alternatives for Making Smaller Stories

When I was in Israel a couple of weeks ago teaching workshops, one of the big problems people had was large stories. Why was this a problem? If your stories are large, you can’t show progress, and more importantly, you can’t change. For me, the point of agile is the transparency—hey, look at what we’ve done!—and the ability to change. You can change the items in the backlog for the next iteration if you are working in iterations. You can change the project portfolio. You can change the features. But, you can’t change anything if you continue to drag on and on and on for a give feature. You’re not transparent if you keep developing a feature. You become a black hole. Managers start to ask, “What you guys doing? When will you be done? How much will this feature cost?” Do you see where you need to estimate more if the feature is large? Of course, the larger the feature, the more you need to estimate and the more difficult it is to estimate well. Pawel Brodzinski said this quite well last year at the Agile conference, with his favorite estimation scale. Anything other than a size 1 was either too big or the team had no clue. The reason Pawel and I and many other people like very small stories—size of 1—means that you deliver something every day or more often. You have transparency. You don’t invest a ton of work without getting feedback on the work. The people I met a couple of weeks ago felt (and were) stuck. One guy was doing intricate SQL queries....

Small Internal Releases Lead to Happy Customers

If you saw Large Program? Release More Often, you might have noted that I said, You want to release all the time inside your building. You need the feedback, to watch the product grow. Some of my clients have said, “But my customers don’t want the software that often.” That might be true.  You may have product constraints, also. If you are working on a hardware/software product, you can’t integrate the software with the hardware either until the hardware is ready or that often. I’m not talking about releasing the product to the customers. I’m not talking about integrating the software with the hardware. I’m talking about small, frequent, fully functional releases that help you know that your software is actually done. You don’t need hardening sprints. Or, if you do, you know it early. You know you have that technical debt now, not later. You can fix things when the problem is small. You see, I don’t believe in hardening sprints. Hardening sprints mean you are not getting to done on your features. They might be too big. Your developers are not finishing the code, so the testers can’t finish the tests. Your testers might not be automating enough. Let’s not forget architectural debt. It could be any number of things. Hardening sprints are a sign that “the software is not done.” Wouldn’t you like to know that every three or four weeks, not every ten or twelve? You could fix it when the problem is small and easier to fix. Here’s an example. I have a number of clients who develop software for the education market.  One...

Posted: What Is A Professional?

I write a twice-yearly column for Better Software magazine. The title of the column is called “Technically Speaking.” For this column, I decide to tackle the question of “What’s a Professional?” If you don’t already subscribe to the magazine, you do have to join the site. It’s a free registration to...

Organizing An Agile Program, Part 4: Start From the Teams and Work Up

We got here because I started with Managing the Stream of Features in an Agile Program. That got me to Organizing an Agile Program, Part 1:Introduction, Organizing an Agile Program, Part 2: Networks for Managing Agile Programs, Organizing an Agile Program Part 3: Large Programs Demand Servant Leadership. Sorry I got behind. Life interfered. Some Principles for Large Programs In this post, I’m going to talk about what the teams need to do, and how you, as a program manager will manage those principles. These principles are: Batch size matters. You need to make sure the batch size, the number of features the teams address before they integrate is as small as the teams can manage. Yes, that means you want to get the entire program as close to continuous integration as possible. Iterate on the backlog and the roadmap. You want to see if you can finish the program early. I realize the schedule advances are rare in a program, but you want to allow for them. Encourage the idea that not all features in an area need to be complete before the product owner can proceed to another area. This is why the product owners need a community of practice and why there needs to be a Program Product Owner and a program roadmap, and a program burnup chart (maybe) to see the progress on all the features. You don’t need to see completion on features. You need to see if enough has been done on the features before you proceed to other features. In Manage It!, I said the project manager needs to ask “How little...