The more I see teams transition to agile, the more I am convinced that each team is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context? (I wrote Manage It! because I believe in a context-driven approach to project management in […]
Join me for a webinar on March 10, 2014 at 7pm Eastern. My topic is “Overcoming 7 Common Pitfalls of Transitioning to Agile in Software Engineering.” I’m speaking as part of the Graduate Professional Studies Spring 2014 Guest Speaker Series. Register here. P.S. If you missed the webinar, here is the audio recording. Enjoy!
I have a new column up on project management.com. It’s called Debugging Your Geographically Distributed Agile Team. (You have to register to read it. Registration is free.) You can do agile with geographically distributed teams. You might not be able to do Scrum. You have other choices of approaches. Helping a team form is tough.
Back when I was a Director of many things at one company, we had an urgent patch to go to a customer. My VP wanted it “yesterday.” Well, time only goes in one direction. I gathered my continuing engineering team, explained the pickle we were in. “Everyone wants this patch right away. However the customer
I’ve outlined five potential costs of delay in the previous five posts: The delay from not releasing on time, part 1 The delay from multitasking,part 2 The delay from indecision, part 3 The delay from technical debt, part 4 The delay from other teams as part of a program, part 5 The real problem is
Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release. One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all
Cost of delay part 1 was about not shipping on time. Cost of delay part 2 was due to multitasking. Cost of delay part 3 was due to indecision. This part is the cost of delay due to technical debt. One of the big problems in backlog management is ranking technical debt stories. It’s even
In Part 1, we discussed the cost of delay of not shipping on time. In Part 2, we discussed the cost of delay of multitasking. In this part, we’ll discuss a cost of delay due to management indecision. Here’s a problem I encounter often. A middle manager calls me, and asks for an estimation workshop.
In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk. Sometimes, you don’t have short projects, so projects
Do you know about the Cost of Delay? It’s the way to think about the revenue you can lose plus the cost of continued development. One of my managers many years ago had a back of the napkin approach to cost of delay. “Johanna, we want to ship this product in the second quarter this