The problem with estimation is that software is not construction. We can’t create software the same way we build a house or manufacture anything else. We can't say, “We can build this software for x dollars per square foot.” But other people often think of our estimates that way. What can you do?
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development.
She was the agileconnection.com technical editor for six years. Johanna is the author of these books:
- From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver (with Mark Kilby)
- Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd edition
- Agile and Lean Program Management: Scaling Collaboration Across the Organization
- Project Portfolio Tips: Twelve Ideas for Focusing on the Work You Need to Start & Finish
- Diving for Hidden Treasures: Finding the Value in Your Project Portfolio (with Jutta Eckstein)
- Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost
- Manage Your Job Search
- Hiring Geeks That Fit
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management (with Esther Derby)
Read her blog and other articles on her site, jrothman.com. She also writes a personal blog on createadaptablelife.com.
All Stories by Johanna Rothman
If you are starting a transition to agile, first ask yourself: Why do we want to transition to agile? Agile is about the ability to respond to change. Once you understand what your organization’s issues are and you can resolve them, you can move to a program.
Sony is now worth a fraction of what it was ten years ago because the company started asking, "What will make us the most money right now?" Your question should not be how much something costs; you should be asking, “How much value will this project provide?” Learn to tell the difference.
When you move people from project to project before they've finished their work, you deny them the opportunity to learn domain expertise. You want to leave people to finish projects, learn the product, and create solid teams. Good managers don't move employees like chess pieces.
You have any number of choices for your lifecycle if you are a geographically distributed team transitioning to agile. But some choices are better than others, and you may need a coach. Similarly, there are many tools available, but you, the team, should choose which you use, not your management.
For programs, the risks are too high to have longer times between integration points and demos. Waiting too long increases potential delays, which increases risks. You want feature teams in your program working together, so you want short iterations and small stories connecting often and everywhere.
Why does senior management split developers and testers? Because they do not realize that software is about collaboration. Success happens when you hire feature teams in one location. When CIOs are under pressure to reduce budget and release faster, they think offshoring—but that has other costs.