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

Traffic Lights and Project Status

For years, I have ranted against traffic lights as a way to discuss project status. That’s because on serial lifecycle projects, or on long projects, the traffic light was always yellow or red. And, because managers, especially senior managers expected the light to turn green by itself with no outside intervention. But Lisa Crispin noted at Belgium Testing Days that her project was mostly green. It’s an agile project, and the build mostly works, and the tests mostly pass. It’s a rare day when things don’t work. And, now my friend and colleague Yves Hanoulle has another really good use of red and green highlighting in a report that shows more testing, fewer warnings, unreachable code detected. I really like that unreachable code detected! The nice thing about using red and green is that red means stop and green means go. It still doesn’t help the color-blind people, but it’s a nice use of the contrasting colors for those of us who can see the colors and understand that if we want to fix something we’d better. For me, these uses of red and green are different than the traffic light project status. For one thing, they are binary status: either red or green, not yellow. And, the teams’ reactions are different. Lisa’s and Yves’ teams (I suspect, I don’t know for sure) are much more likely to pounce on a red piece of data than when a project team had a yellow traffic light status. So, I have to be clearer on how I rant about using traffic lights to describe project status. For agile projects, traffic lights,...

Agile Program Management: Possible or a Pipe Dream?

Have you ever waited weeks for one piece of functionality so you could release a large project? Have you been in the situation where the software is waiting for the hardware? Or where the database admin held up the entire release because his work wasn’t coordinated with the feature-based teams? That’s because you were working on a program, not a project. Program management is the art of coordinating several sub-projects to a common objective. Until the parts are assembled into the whole, the parts–while useful–have no business value to the organization. The whole program delivers business value to the organization. Agile approaches help manage risk for projects. Is it even possible to scale agile approaches to programs? Yes, and it’s not trivial. There are four areas to consider when scaling agile to programs: backlog management, product architecture, managing risks across the program and explaining program state. Manage the Backlogs If you’re lucky, you have a product where the subprojects or subsystems are relatively independent. For example, consider a cell phone system. You can imagine that the call handling subsystem is independent from the voicemail, which is independent from the camera and so on. The applications on a cell phone are just that–applications. They have some defined interfaces, but the project teams can work independently to deliver the applications. In that case, you can manage the backlog for each application separately. You do need architects and an overall product owner to look for and manage the backlog interactions. It’s easier to develop and manage a program backlog if you have a platform and applications as your product. Each item on...

Sunny Skies or Storms

Summary: Long-time advocate of status reports, Johanna Rothman has come across a new way of reporting the movement of a project using something we experience everyday–the weather. In this week’s column, she sheds a little sunshine on this new technique, which demonstrates the status of a project a lot like meteorologists announce current weather conditions. I’ve long advocated test managers having a mission of assessing the state of the project and reporting on it. This assessment compares where the project is to where it should be—not including audits of the project or the process. To be honest, I don’t care whether the project manager or the test manager assesses the project on a regular basis—only that someone does it. A project dashboard explains all the details about the project state . And, in most organizations, people need to understand what the data means. What better way to lift the fog of confusion than to present your information in a concise way everyone will understand? And everyone knows weather. Weather reporting is great technique to explain the project state assessment. Some may use the traffic light model–red, yellow, and green–to denote the project’s state. This model shows today’s state, but it’s hard to see where the project is headed. I haven’t found the traffic light useful, due to the static nature of the assessment and the limit of three levels to denote project state. And unlike traffic lights that automatically change, projects don’t change unless the project manager and the team act to change them. Projects tend to continue in the direction the team is heading. Most senior managers want to see a weekly...

Are You Done Yet?

by, JB Rainsberger and Johanna Rothman, © 2008 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. I have never been a manager, so everything I think I know about managing is theoretical at best. That’s why I enlisted the help of Johanna Rothman, the manager’s manager, to help me talk about a sore topic for some: working well with your manager. We know that the single biggest cause of divorce is arguing over money, and similarly, the single biggest wedge between programmer and manager is arguing over the schedule. I could see this problem from the programmer’s point of view, so I’ve asked Johanna to provide the manager’s perspective. A programmer and manager collaborating effectively–it can be done! Do you get along well with your manager? Not as well as you’d like? Not well at all? Think you should have an adversarial relationship with your manager? The best managers work to develop harmonious relationships with their staff. The problem with relationships is that they involve humans, and as a result, improving them lands many people in uncomfortable territory. I became a programmer in part because I know what the computer does and doesn’t do, and I can reasonably predict its behavior–at least, most of the time. People don’t make it so easy. The bad news is that most people get...