Definitive versus Empirical

Ever heard of the cone of uncertainty? The cone shows the historical error at certain time periods in a tropical cyclone forecast. What happens today and what has happened in the past is pretty much all we know. We can certainly use all kinds of scientifically proven processes or models to try to predict the future. But, in the end, we won't know what tomorrow will bring until tomorrow. If you are dealing with machines, you should be able to predict upcoming events with relative certainty. If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none.

We need to assume that baselines may change significantly during a project or in life. In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

Definitive

You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins. You do everything you can to lay it all out, attempting to account for every possible variable. Unfortunately, you don’t know what tomorrow will bring. So, the further out the schedule goes, the greater the risk something is going to change. What’s it going to be? Is scope going to change or maybe the schedule will slip? With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.

Empirical

In reality, you begin with the greatest unknown. Even some of the unknowns aren't even known. Just accept it! You can’t predict the future. The only thing that is guaranteed is something is going to change. So, plan for that change. Know the goal you’re trying to reach. Keep your eye on that goal. Now, do what you do. Develop, lead, manage…it doesn’t matter. What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again. Make some adjustments and repeat. You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.

Summary

You can not predict the future, only plan for it. You can not steer a hurricane, only plan for it. You can not prevent change. Can you guess what comes next? That’s right, you plan for it.

Organize Around Teams

Several years ago, I was working with a client who was obsessed with keeping resources (in this case, people) 100-percent utilized. The client boasted that he had a strong matrixed organizational structure and everyone was a member of multiple teams working on multiple projects. When I came on board, I noticed that people were spread extremely thin between the projects. There was a lot of work being performed but very little was getting done. How can you make real progress if you have multiple managers asking you to deliver that high priority something for them? How can you make real progress if you have to constantly shift gears and go in different directions?

In theory, having a matrixed organization sounds really great. Resources can potentially be utilized up to 100 percent. In reality, the goal is not utilization of a resource. The goal is throughput and delivering something of value. In the end, having a matrixed organization made people busy but it did not make them more productive. Perhaps managers felt more productive because they essentially had more people they had to manage. But again let me stress, the goal is not to manage people. The goal is to deliver something of value. When I did my original assessment, there were two common complaints. First, team members didn't know who to take direction from. Second, team members never seemed to have time to just focus on one thing and get it completely done.

Status quo organizes teams around projects

• Projects are initiated
• We beg, borrow and steal, looking for the right people to work the project
• We pull a few hours from here and a few hours from there
• Everyone is "fully utilized" by working on several projects at the same time
• When the project is complete, we release some portion of each person’s hours back into the pool and start again
• Endless resource-management frustration

Bring the right projects to the right teams

• Teams focus on one or two projects at a time and get them done quickly
• Management prioritizes projects and queues them up for the appropriate teams
• May need to move a few people around but hopefully not many and not constantly
• Much of the resource management problem goes away
• We also get fewer simultaneous projects, more focus, and more speed of delivery

Once we got people grouped into several (cross-functional) teams and then collocated in team areas, we actually started making deliveries on projects. The PMI would define this reorganization as being projectized. But, let us not forget that this is about the teams and creating an environment in which they can deliver value.

In our Enterprise Agile Workshop, we explain how organizing around teams allows you to estimate, plan, and deliver at a more accurate level of granularity.


HT: LitheSpeed Enterprise Agile Workshop

A Conversation on Using Agile at the Program Level

As organizations scale to more agile teams, a shift to agile program management is inevitable. In this podcast, Bob Payne sits down to discuss agile program management with Johanna Rothman, management consultant, author, and enterprise program management expert.

The goal in program management is to effectively manage several projects run by multiple teams to get the product out the door. We’re talking about big deliverables here. Johanna talks about the challenge of moving the usage of agile up to the program level. She lays out the steps a program manager can take in order to help facilitate this kind of development, including the use of a program architect, program storyboards, and cross-team collaboration.

During the conversation, Johanna also addresses the importance of a product or program team's ability to make decisions when there are competing interests.

And finally, Bob and Johanna discuss the meaning of "done.” According to Johanna, a product isn't done until the team can answer in the affirmative to the following three questions:

1) Does it meet the acceptance criteria, including the norms for the team?
2) Has the product been reviewed and tested?
3) Is the product deployable and installable?

Listen to Bob's conversation with Johanna now: http://agiletoolkit.libsyn.com/agile-2010-johanna-rothman-agile-program-management.