More Talking to Project Managers

Here is my last post for Artem's Agile Software Development... republished here for the benefit of my Leading Agile readers.

Last post we explored some ways to introduce agile concepts to traditional project managers and how to make a case for agile in a way that has a chance to really resonate. We explored how to discuss time, cost, and scope… talked a little about dealing with uncertainty… and a little about the factors that are really constraining our projects.

If you are interested in catching up with the conversation, go back and take a look at my post "How to Talk to Project Managers" at http://agilesoftwaredevelopment.com/blog/mcottmeyer/how-talk-project-man...

This past Tuesday, I was up in Vancouver doing a workshop on these very topics. About half the class self-identified as a PMP certified project manager… the others were either uncertified project managers or development leads. Most of the folks rated themselves a three or four (out of ten) on their agile expertise. We had a few folks in the class that rated their knowledge in the five to eight range, and after doing the course, I agreed with their assessment.

Most of the people in the course were there to learn more about agile or to learn how to sell agile in their organizations. They wanted to understand the agile value proposition and how to go back and communicate agile in a way that really resonated with their businesses. We were off to a good start.

My talk generally followed the outline from "How to talk to Project Managers". People were taking notes and seemed engaged... but, sometime around lunch things started getting more difficult. After laying the foundation around the triple constraints, uncertainty, and project drivers; I had hoped to move into agile principles and project management techniques. What I found is that I had left out a critical component of the discussion.

I had not addressed how their organizations were currently structured and the barriers this would introduce to agile adoption. I started talking about teamwork and collaboration and they were thinking about matrixed organizations, task sequencing, and resource management… I had needed to address this issue head on and my failure to do this caused the class to spin a little out of control.

We ended up spending a great deal of time talking about merits of generalization and the challenges associated with specialization. We talked about how to deal with agile teams when some degree of specialization is required. We explored what it meant to be a team and what creating teams would mean for their organizations. We talked about the differences between iterative and incremental development versus agile development. We explored what it means to be a project manager in an agile organization.

What I learned was that there is a bunch more we needed to talk about before we could move to agile principles and practices. We needed to introduce a few more concepts before we started talking about agile project management. We needed to address matrixed organizations, building teams with specializing generalists, and the role of the project manager on an agile team.

Here is some thinking I've done on these topics over the past year:

http://www.leadingagile.com/2008/07/managing-too-much-complexity.html
http://www.leadingagile.com/2008/04/what-about-me.html
http://www.leadingagile.com/2008/10/agile-or-iterative-and-incremental.html
http://www.leadingagile.com/2008/06/project-managment-is-not-enough.html

Happy reading. Please comment on how you are talking to your organization about agile and what messages you have found that resonate. If I use something you submit in a talk, I make sure to credit your contribution.

Subscribe to this blog Subscribe to Leading Agile

Planning for Value

"Reduce your plans to writing. The moment you complete this, you will have definitely given concrete form to the intangible desire" - Napoleon Hill

"Plans are of little importance, but planning is essential" - Winston Churchill

"No battle plan survives contact with the enemy" - Colin Powell

One of the most significant contributions of the Agile community has been the realization that creating software is an uncertain business. Unfortunately, this realization has led some of us to the conclusion that the act of creating software cannot be planned. There is a big part of me that can empathize with this point of view. What's the point of creating a plan if we know the business objectives are going to change, requirements are going to change, and even technologies are going to change? I have worked in many traditional projects where change management was the single biggest part of my job. Why not just get going and see where we end up?

The challenge is that business planning doesn't work that way. Product owners are asked to create their business cases months in advance of the upcoming fiscal year. Once funding is approved those guys are on the hook for the revenue. This is a big part of our reluctance to let go of the big up front planning processes. As businesses, we want some sort of assurance that we can deliver on our revenue targets. To these companies, funding a project with only the promise we'll get the most important features first is not very reassuring. We must KNOW that those features are going to deliver the EXPECTED value. Our jobs depend on it.

When the context we operate in is uncertain, we have to plan for that uncertainty. To do this, let's look at the following three planning alternatives:

Make sure the project will yield an acceptable return with less than 100% of the desired features.

Sure… I want a crystal ball too. Problem is we don't have one. If we have a firm date, a firm cost, and a fixed set of features; odds are we are going to fail. If time and cost are king, we have to be flexible on features. We need to know up front that we can go to market with less and still produce acceptable value to the company.

Commit to high level features so team has room to negotiate through the life of the project.

In most corporations, there are at least a few other teams that must know ahead of time what you are going to deliver and when. Marketing comes first to mind, so does sales. For those guys to be successful, they need to know what is going to be delivered much earlier than most of us are willing to commit. Committing to high-level features gives us enough specificity to communicate about the product while allowing the team to fine tune the implementation of those features as the product progresses.

Manage the project's value stream rather than changes to features or tasks.

We know that project requirements are going to change along the way. They should. As we build the product we are going to learn more about what we need and how best to build it. Those changes still need to be managed. The company decided to invest so many dollars to yield a particular return. Do we know how any given change will impact the value of the product? Let's start looking at how our changes impact the metrics we really care about... value.

Let's not be afraid to plan in the name of agility. Let's just be smart about what we are planning and leave ourselves room within the plan to be successful. At the end of the day, it is the value that we deliver to the organization that matters, not how well we followed the plan.

Here is a link back to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/planning-for-va.html

 Subscribe to this blog

Subscribe to Leading Agile

I Want Control

As an Agile Project Leader, I feel like I have lost control.

In my last post "The Road to Agility", my original premise was that in order to be trusted, we have to be trustworthy. To earn the trust of our organizations, teams have to consistently deliver. To deliver regularly, we have to have structure and control.

I wimped out. I substituted the word discipline for control because I was concerned I would lose my audience. I was afraid people would react to the word control and stop listening.

I lost control, now I want it back.

As an Agile Project Leader, why should I be scared to use the word control? As a community, are we scared to be in control of our projects? I sure hope not.

But wait... we want collaboration, not control.... right? Control suggests authority. It suggests top down management. It suggests all those outdated project strategies we have seen fail time and time again.

Maybe when we talk about control, we just need to be specific about what we are controlling. Are we controlling people or are we controlling processes? Are we trying to control using predictive methods or recognizing the need for empiricism. These things matter when we talk about being in control.

As I write this, I am on a plane to Denmark. I sure hope my pilot is in control of this aircraft. Does that mean he knows every pocket of turbulence or mechanical issue we might encounter? Of course not. I do expect him to know where he is, to measure frequently to make sure we are on track, and adjust if we are not. I have to trust he will know we are off course long before we find ourselves out of fuel and having to land short of our destination.

Control on an agile project is all about visibility, inspection, and adaptation. You need to know what you have delivered and what is left to do. You need to know where you are at all times in relation to your goal. When you adjust, you need to be able to understand and communicate the impact to where we thought we were going.

Just like the pilot relies on a skilled support team to help him stay in control of the aircraft, the agile leader needs to collaborate with the team to maintain control of the project. It is not either collaboration or control, we must have both.

Don't be afraid to be in control of your projects. Your teams and your business owners will thank you for it. Subscribe to Leading Agile