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....

Fixing—or Not—Healthcare Dot Gov

Did you see Dwayne Phillips’ post today, Adding People to a Late Project? Dwayne says: Adding people to a late project only makes it later. We have known this for decades. Especially in the article he refers to, it seems as if there might be no end to the number of people added. Did anyone ask the people on the project if they needed more people? Maybe they needed to know which requirement is top on the list. Maybe they needed acceptance criteria for each feature. Maybe they needed each feature to stay put for more than a nanosecond. There is more than enough blame to go around for this particular project. Most of the blame has nothing to do with the developers and testers. Now, if they had asked me what I would do, here is my plan. What is the most important thing people need to do to sign up for health care? Get a cross-functional team to work on that, get it to done, and make sure it works. Use reviews, acceptance criteria, release criteria, whatever it takes to finish the work. Timebox that work to one week. Make sure you have performance tests. Roll it out. (Oh, do not let people work overtime. Make sure they can keep to a sustainable pace.) What’s the next most important thing? Do that in the second week. What’s the third most important thing? Do that in the third week. Now you have a shot of understanding the architectural needs. Go fix the underlying architecture. Make sure you have unit tests, integration tests, database tests, performance tests, and oh...

Is Offshoring Less Expensive? Exposing Another Management Myth

I was in the midst of an assessment when the CIO came to me, and shut the door. “I have a serious question for you.” I nodded for him to continue. I put aside my papers to show him I was providing him my undivided attention. “I’m thinking of offshoring all the testers. What do you think?” “You can do that. If you do, you will take longer to get a release out the door. Since you brought me in to see why it’s taking you 18 months to get your 9-month releases out, I’m not sure it’s a wise thing to do. Why are you thinking this?” “All the other CIOs I know are doing this.” This was in 2002, just as the offshoring/outsourcing boom was starting. Agile had not yet become an accepted way of working. I had recommended working in feature teams and working in timeboxes, with small(monthly) deliverables, with people working on just one project at a time. Yes, you can see my current thinking in that report. That CIO was not alone. His management and his board was exerting tremendous financial pressure on him to reduce the cost of his projects. At the same time, they were exerting the same pressure to release faster. He was stuck between a rock and hard place. In another assessment, just a few years ago, I encountered the same situation, where senior management had made the decision to hire developers in New York City and testers in Singapore, a 13 hours time difference. I’ve met people in my teaching who have developers all over the US and testers...

Slides and Audio from Let's Test Posted

I delivered a keynote at Let’s Test in Sweden last week, “Becoming a Kick-Ass Test Manager.” A lovely gentleman, Aleksis Tulonen, recorded the audio. Thank you, Aleksis! I attempted to marry the audio to the slides. I was not successful. However, the audio is up on slideshare. You can download the slides, page through them and listen to the audio. There are gems, such as, “I’m not done yet. This is my keynote.” On the slideshare, there is a link to my original keynote, the video of my StarWest 2012...