How to Talk to Project Managers

Last week, I had had the distinct pleasure, the rare opportunity, to attend the PMI Global Congress in Denver, Colorado. I missed the deadline to propose a talk but there were at least 5 agile presentation happening over the course of the event. That is really good news. The PMI crowd is interested and trying to understand what this agile stuff is all about.

I was working the VersionOne booth, so while I had a full conference pass, I did not get to go to any of the talks... bummer.

Note: This post was written last week, so I am writing like I am there now. I decided to leave the language that way... hope it is not too distracting!

Talking to Project Managers

It has been really fun talking to all the folks that have come by to see our software. The people that stop to talk to us have already been exposed to agile on some level, so my perspective might be biased, but there are many more agile friendly people that I expected. Again, people are interested and want to know more.

After my first full day of meeting and greeting the conference attendees, there is one thing I would like to share with the agile community. When you talk to a traditional PM about agile project management, you need to be prepared to speak their language. While teamwork and collaboration are important, that is not the language of the PMI crowd. Empowerment is essential but can be very threatening to someone that is accustomed to being "in control".

I've found that a good place to start is with a discussion of the triple constraints.

Managing the Triple Constraints

Most traditional projects start with some assessment of scope; an assessment of what the stakeholders want to be built and what they are willing to invest money to have. From there the team does some analysis, figures out how big the request is, and what will be involved in building it. We do an assessment of the team, understand who is available (and when), and begin to lay our dependencies and calculate the critical path. From there we determine a date.

Ask your PM friend if that sounds much like their personal experience? They will inevitably nod 'yes' because that is what project managers are taught to do. Next ask them what happens after they communicate the project costs and delivery date of the project? I would bet money that their response will be somewhere along the lines of: we are given a date, we are given a budget, and then we start de-scoping the project.

Sometimes, if management really does not care about successful delivery, they are just given the date, and the budget, and are made to deliver all the requirements anyway.

Our Real Project Drivers

This is where you can explain that they are given the date and the budget because those were really the project constraints to begin with, not the requirements. We pretend the requirements are the constraint because, like most people, stakeholders hope that we will be able to get everything we want for what they are able to spend. Most of the time that is not the case.

So, where do we go from here? I will typically explain that agile project management starts with time and cost as the primary constraints and introduces techniques that enable the business, in partnership with the team, to decide what is the best set of requirements to build. After delivering this line, be prepared for the blank stares.

But I Have to Deliver Everything

The blank stares are because project managers are trained that they have to deliver everything. The executives demand it and the stakeholders cannot take the product to market unless they have everything. Now it is time for more questions. Ask them if that approach ever works? The answer is always 'no'. Ask them what happens when projects start this way. They will answer that the project is always late or over budget.

The reality is that by demanding ALL the scope, in the face of data that says otherwise, the business is making the implicit decision that their project will be late. You are generally not rewarded, or very popular with your stakeholders, if you bring this to their attention. Project managers are often incented to keep their heads down, do their best, and take their lumps when things are late.

As a quick aside this is the main reason most project managers rely so much on process and documentation. It allows them to cover themselves and be 'successful' in an impossible situation.

Most Project Managers Don't Make the Call

The reality in many businesses is that the project managers are not empowered to make the time, cost, and budget decision; and even if they bring these issues to the attention of senior management, they may be forced to proceed with the project anyway. This is your hook to talk about why agile can be such a valuable addition to their PM toolkit.

Delivering in short cycles and measuring done gives you real data about the health of your project. Managers often assume the team has overinflated the estimates. They assume the team is sandbagging. Agile gives you real empirical data about the status of your project and what the team is capable of delivering. Agile gives the business real data, and real options; options that go beyond just how late and over budget do you want the project to be.

Put the Business Back in Control

Agile gives the business the opportunity to effectively de-scope on the fly, to change their mind, to increase the cost of the project, to lower the cost of the project, to deliver early, to deliver late, or to kill the project all together if the business objectives cannot be met. They get this information early, when there is still time to deal with it and make a rational business decision.

The senior managers I have worked with will make good decisions when presented with good data and real alternatives. Bad decisions are made in low trust environments with poor information.

Now Let's Talk Agile

So, with that groundwork in place, you can start talking about teamwork, collaboration, and empowerment. You can start talking now about pair programming, continuous integration, and test driven development. Those things just don't mean much to the PM community until you help them understand how agile will fundamentally put them in a position to deliver quality projects: on time, on budget, and with the highest value that can possibly be delivered.

Until then, people are just not going to get it. So next time you are talking to someone with a PMP next to their name, make sure you are speaking a language they can really understand. The traditional community is willing to listen, we need to make the most of our opportunity.

Reposted from Artems Agile Software Development blog: http://www.agilesoftwaredevelopment.com

Subscribe to this blog Subscribe to Leading Agile

The Agile Project Plan

When we think about a project plan, what do we typically think about? Most people I talk with think a project plan is the schedule…. they think about the Gantt chart… the dependencies... and the critical path. The project plan can contain the schedule, but it is bigger than that. A project plan is a project manager's strategy for how the project is going to be run. It is a tailoring of the project management framework and describes what processes are going to be applied to run the project.

Business Case and Charter

My approach to writing project management plans is certainly not unique, but I am also not sure it is 100% standard. A good project management plan should start off with the business case and charter. This is a statement of the value we expect from the project and your authorization to move the project forward. These documents set context for the product vision and development activities. They establishe the project constraints, known risks, and any assumptions the business is making that could have an impact.

The Product Vision

The vision should describe the customers of the product and the value they will derive from using it. It might address the market segments you are going after and any business constraints the project is operating under. There can be quite a bit of overlap between this document, the business case, and the charter depending on how your team uses these artifacts. I like to think of the vision as the place we really get specific about the product and what it needs to actually do.

You can think of the vision as describing the actors or personas that will use the system, the major product themes, and major epics that are going to be delivered to market. I might also consider delivering a high level release plan to communicate the overall project schedule.

A Note on Documentation

When talking to an agile audience, I always try to be careful to state that these documents do not have to be 100 page monsters. If you are working with a small team and with an embedded and empowered product owner, these documents can live on a whiteboard or a wiki. If you are running a large, and possibly distributed program, you may want to leverage a wiki or some other lightweight electronic communication tool. If you are working in a traditional document driven organization, you might have to create something in document form. Just keep it as lightweight as possible.

The PM Knowledge Areas

Now comes where we describe how we are going to deliver to the expectations of the business. We need to state how we are going to manage cost, time, and scope and explain how our project will manage risk. We need to let the business know our strategy for communicating progress and how will we will ensure quality. We need to communicate what we are going to do if we need to buy anything or hire anybody into the team. We need to get on the same page about how we are going to make staffing decisions and how we will handle any HR issues along the way. We need to communicate how we are going to make sure everything is working together to deliver value.

These are not questions only for traditional teams, agile teams have to answer them too. Often, we assume these things because agile processes have the answers built in. It is just part of the process. Sometimes we need to be willing to explicitly communicate how we are going to proceed in language that the business understands. A lightweight project plan can be just such a tool.

It's all about communication

Sure... the plan might change... we want to preserve the ability to inspect and adapt. That is why we keep the artifact as lightweight as possible. The act of writing this stuff down makes sure that we think it all through, that we don't take anything for granted, that everyone has a common understanding of how we are going to approach the project.

I have had great success in the past walking my PMO through each of the PMI knowledge areas and documenting how our agile techniques are going to manage time, cost, scope, risk, quality, procurement, human resources, communication, and integration management. The point of the exercise is not about the document, it is about getting everyone on the same page, it is about communication and understanding.

After all... that should always be the point of documentation… communication and understanding.

Subscribe to this blog Subscribe to Leading Agile

Supporting Agile

John Boghos is writing a blog. This post is to let you know a little about John and why you need to care about his new site... Supporting Agile.

John and I work together at VersionOne. John is our customer support lead and is passionate about being excellent in customer service. John is one of those rare... albeit strange folks that are really interested in this space and want to explore how to do it better.

I did a few years of customer support early in my career. It is a hard, often thankless job, and I did not last long. John has made a career out of this. Over the past twenty-four years John has worked in food service, telemarketing, telecommunications, project management, and the software industry.

John's blog is going to explore how to manage a support queue using agile techniques and principles. He will also discuss how to best work with an agile team when you are the guy supporting their product. This is an interesting space that needs some more attention.

There are lots of teams out there using iterations, story points, backlogs, and velocity to try to make some sense out of their support queues. These are teams that are striving to become more predictable and eliminate waste in their processes. I am really interested in what John has to say and look forward to reading more from his experiences.

Visit http://www.supportingagile.com to hear what John has to say. I doubt you will be disappointed.

Subscribe to this blog Subscribe to Leading Agile

Agile Portfolio Management

Functional silos… matrixed teams… unnecessary levels of specialization… these are the factors that make it really hard to run stable projects.

People are spread across too much stuff. Keeping up with where people are supposed to be (and when) is a nightmare. When projects change, it is very difficult to assess the impact because of the number of cascading interdependencies.

Unpredictable projects make for unpredictable portfolios. One significant change and the whole thing falls apart. The cost of change is way too high.

When faced with overwhelming system complexity, we move toward service oriented architectures. In the face of overwhelming requirements complexity, we move toward user stories and use cases. These strategies create independence between agents, hide their complexity, and have them interact with each other across defined boundaries.

It helps make each problem self contained and very well defined. When one component is changed, these strategies contain the cascading impact.

Think about Bill Wake's INVEST model for user stories. Stories should be independent, negotiable, valuable, estimateable, small, and testable. What if we applied the same logic at the project level? What if we created a project portfolio that followed this same general framework?

Let's see what that might look like?

Independent - Projects have minimal dependencies between them. They only share resources when absolutely necessary. You align releases to minimize date dependencies.

Negotiable - Project objectives are defined up front, not detailed requirements. Negotiable is manifest in the agile backlog.

Valuable - Expected return is defined up front. At the end of the project we can clearly assess if the project yielded the expected return.

Estimateable - Projects are well defined enough to get a handle on their size

Small - No project bigger than 3 - 6 months. Make investment decisions in smaller increments.

Testable - Projects must have well defined acceptance criteria

Could an organization run a backlog of projects like it runs a backlog of stories? Could a portfolio owner make decisions about what projects to bring into the next release based on their priority and relative business value? Could we take the sprint planning metaphor and elevate it to the portfolio? The same kinds of things we do to manage the flow of backlog items through the system would be done to manage the flow of projects, just one level up?

Stories are to projects as projects are to portfolios

Do these same metaphors apply? I know some folks are doing this. I don't know of anywhere where this is being written about. Anybody know of someone that has defined a model like this?

Photo Credit: http://www.onshoretechnology.com/EnterpriseServices/BusinessConsulting/tabid/132/Default.aspx

Subscribe to this blog Subscribe to Leading Agile

Why Twitter?

Staying in Touch is Hard

As you might imagine… I lead a pretty busy life. I travel some for my work to train, consult, and speak at conferences. I have three kids involved in Boy Scouts and Tae Kwon Do. My wife and I run a private school we helped start. My free time is usually spent in coffee shops or places as deep in the woods as I can walk. It is very hard to find time for my close friends and family.

There is almost no time for the folks who I genuinely value, would like to stay in touch with, but are not part of my immediate circle.

Prior to the whole social networking movement, those people just drifted away. I might be lucky to see someone at a 20 year reunion or happen upon them in an airport somewhere. Even if you are able to spend time writing email or occasionally talking, it is really intense trying to get people up to speed with what is going on. The result is that people are only marginally connected and only marginally involved in your life.

Keep People in the Know

The beauty of Twitter is that people can stay involved in your life no matter where they are, what they are doing, or what you are doing. When you do get the opportunity for face time, you are not starting from scratch. There are people I have not seen in a year that, next time we get together, will know about my trips to Milan, Paris, and London; they will know what I am thinking about and interested in, they will have seen the latest pictures of my kids, and maybe even know who I intend to vote for.

We have a much better starting place to begin a new conversation.

I can't tell you how many people came up and wished me a happy birthday last month because Facebook or Plaxo let them know it was coming up (it was September 29th by the way). That is a pretty small thing, but it was meaningful to me. I'll bump into people around town that will ask about my last vacation or how some issue I was complaining about got worked out.

Again… it gives us a point of reference and a place to start besides "hey… what have you been up to lately"… they already know.

Building Relationships

There is this one guy who started following me on Twitter that I follow as well. I have never met this guy but I know he is a product manager for a small software company in Toronto, he is obsessed with Batman, likes to play video games, and eats out frequently with his wife. He made an offhand comment one day about a VersionOne competitor so I responded directly to him.

This opened up a dialog that we took off Twitter and onto email. I was able to help him with an agile question he was dealing with and he returned the favor by reviewing a white paper I am writing. That is pretty amazing. Here are two people that never met but in effect know each other so well they are willing to go out of their way to help each other out.

When I was in London a few weeks ago, I was getting really frustrated with some of the poor presentations I attended. I twitted that I was going to write a blog about delivering great presentation (http://www.leadingagile.com/2008/10/delivering-great-presentation.html). A friend of mine in the Netherlands picked up my twit from Facebook and mentioned that he was writing a presentation on giving presentations.

I happened to be traveling with a mutual friend from Denmark who was also writing a presentation on how to deliver a great presentation. I was able to hook the two of them together and now they are going to collaborate rather than working independently. Creating connections where connections don't exist is powerful stuff.

It gives us one more way to stay connected with each other in an increasingly depersonalized world.

Over the Top?

My wife thinks I am a nut. On a good day, I'll probably send out 8-10 updates. Does anyone really care what I am doing that many times a day? Probably not…. but the people in my network are now a bigger part of my life than they would have been otherwise.

If you have any of your own Twitter success stories, I would love to hear them. You can post a response to this blog or shoot me an email directly. If you are interested in following me on Twitter, my id is @mcottmeyer. I'll d you my email address. I'd love to have you come along for the ride!

Staying Connected

Here are just a few things that I do to stay connected:

• Update Twitter from my iPhone
• Twitter updates automatically feed into Plaxo and Facebook
• I use Twitterfeed to automatically generate a twit when I post a blog either to blog.mikecottmeyer.com or www.leadingagile.com.
• My agile blog automatically publishes on Plaxo
• I use TripIt to manage my itineraries and push a travel feed to both my blogs. This let's people know where I am headed and when I will be there.
  
• I have Picassa and Del.icio.us automatically update Plaxo as well
• I have become a guest writer on Agile Software Development in an attempt to grow my network and I also allowed DZone to republish my posts from www.leadingagile.com
  

Anything else you think I should be doing to stay connected?

Subscribe to this blog Subscribe to Leading Agile

Scream Free Project Management

So here is another post I originally did for Artem's Agile Software Development blog. This is one of my attempts to blend a non-agile topic (parenting) with agile thinking and project management. Hope you enjoy it.

Scream Free Project Management

A few weeks ago I had the opportunity to read a book by Hal Edward Runkel called Scream Free Parenting. The title is a little misleading because the book is not really about screaming and the lessons Hal teaches go beyond just parenting. The book is about controlling your anxiety so you can build healthy relationships.

The key idea of the book is that anxiety is at the root of much our conflict. Think about it… we want better behavior from our kids, we are not getting it, and not getting that desired behavior stresses us out. When we yell at our children, we are really saying "I want to be calm, you are not allowing me to be calm, I demand you change your behavior so I can be calm".

How about with our teams? We desire a certain outcome on the project, we might not be getting it, so we start to get anxious. We might not scream at our team but we do exert pressure, we threaten, we manipulate, and we control. When we behave this way as managers, we are in effect screaming at the team to change their behavior so we can be at peace.

The problem is that the more we try to control, the more pressure we put on people, the less likely we are to get what we really want. Princess Leia said it best back in the 70's… "The more you tighten our grip Tarkin, the more star systems will slip through your fingers". The more we scream… the more we demand… the more we try to control… the less likely we are to get what we want.

Being anxious leads us to demand control. The more we try we try to control, the less likely we are to actually get the outcomes we desire.

As project managers we need to get ourselves under control first. We need to operate from a position of confidence and strength. It is up to us to lay out the vision and lead the team. We can establish boundaries and set guidelines for behavior. As project managers we monitor the system, give support, and ensure accountability.

At the end of the day… an empowered, self-directed team will deliver more than one that is being heavily managed. It is this kind of team that will help us meet our goals and deliver on the objectives of the organization. Our anxiety is all that is standing in our way… it the only thing stopping us from creating the kinds of teams that are really going to deliver. The challenge is that we have to get ourselves under control first!

Projects come in all shapes and sizes. Some are software… some are community organizations… and some projects live in your house and eat all your food. Focus on creating context… focus on managing the environment… focus less on managing people and controlling outcomes and you've got a much better shot at making things happen.

You'll lead a richer life and have more fun along the way.

Here is a link to the original post on ASD: http://www.agilesoftwaredevelopment.com/blog/mcottmeyer/scream-free-project-management

Subscribe to this blog Subscribe to Leading Agile

Delivering a Great Presentation

Many of you know that a few weeks ago I started writing for Artem Marchenko's Agile Software Development Blog. If it wasn't for that commitment to Artem, I am not sure if I would have posted anything the past few weeks. This post is one I delivered last week while in London for the Agile Business Conference. I am reposting here for the benefit of my Leading Agile readers.

Delivering a Great Presentation

This week I am in London attending the Agile Business Conference. A few weeks ago I got to attend Agile 2008 in Toronto. Over the next few weeks I will be at the APLN Leadership Summit in Atlanta, the PMI Global Congress in Denver, the Vancouver Agile Conference, and the Better Software Conference down in Orlando.

That is a lot of conferences, a lot of speakers, and a lot of presentations.

If you are delivering a talk over the next few months, especially one that I am attending, please ask yourself the following question: are you are talking with the audience or are you talking at the audience? It is not enough to tell me what you think, you need to make me part of the conversation. Great speakers engage their audience, they show empathy, and they understand what their audience needs to take from the experience.

They deliver value.

Sometimes speakers are content to just get through their 45 minutes and be done with it. It is as if the audience does not exist. Far too many speakers don’t know how to really listen to their audience. It is the speaking equivalent of having a big up front design and following your plan to the end. As speakers we need to be able to adapt to the changing needs of our listeners.

In other words, You need to embody the change you are speaking about.

Here is an idea to consider… why not think about your talk like you would a software project? You could prepare your outline to be a high level roadmap… a vision if you will for where you plan to take the audience. Have a prioritized backlog of key points you want to make and information you want to deliver. Deliver your talk in short iterations and seek feedback from your audience. Adapt based on what you hear. Always… always… deliver value.

To hard? Maybe, but that is why you were asked to come talk in the first place!

Reposted from Artem's Agile Software Development Blog:
http://www.agilesoftwaredevelopment.com/blog/mcottmeyer/delivering-great-presentation

Photo Credit:
www.jpprufino.com/?p=104

Subscribe to this blog Subscribe to Leading Agile

Agile or Iterative and Incremental

Many companies want the benefits of agile but are not ready to make the organizational changes necessary to take full advantage of the methodology. Companies want to say they are agile… they want to derive the benefits of agile… but they are not fundamentally ready to do the heavy lifting required to really make it work. People want to hold onto predictive planning. They want to hold on to functional silos. They want to hold onto matrixed teams. People want to keep their specializations and spread their time over multiple concurrent projects.

What does a concept like velocity mean in such an environment? What about empowered teams? When I talk about iteration planning, daily meetings, and retrospectives; people can't comprehend how they will do this with every project they are working on. They fear they will spend all their time in meetings, and you know what… they are right. Agile assumes team. It assumes you are part of a cohesive whole that plans together, works together, and delivers together. Agile trades the big up front design, heavy documentation, and predictive planning for collocation, teamwork, and collaboration.

You can't collocate, work as a team, and collaborate when you spread across so many projects. You can't stop doing heavy project documentation if you aren't willing to replace it with high bandwidth communication between team members. To get that level of communication and collaboration, people need to be in the same room, they need to know each other, and they need to work together on a daily basis. People need to be part of a real team; not a collection of loosely coupled individuals.

The bottom line is this… you won’t get the speed and adaptability you are looking for unless you are willing to make the tough organizational changes that allow this to happen.

You can still get some mileage from delivering software in two or four week cycles, daily interactions between project members, and frequent project reviews. You can make use of loosely coupled requirements, prioritized backlogs, and rolling wave planning. There is value in understanding the definition of done and making sure that once you've delivered, you have really delivered. Managers can do product planning, release planning, and iteration planning without being particularly agile.

Even though you won't get the speed and adaptability of an agile team, you can still derive some benefits from iterative and incremental delivery. Just keep in mind that while agile prescribes iterative and incremental delivery, not all iterative and incremental delivery is agile. Agile adds all the aspects of team, collaboration, empowerment, inspection and adaptation. For a good article on the difference between incremental and iterative vs. agile, take a look at the following post I found on the AgileCollab blog:

http://www.agilecollab.com/iterative-and-incremental-is-not-equal-to-agile-key-aspects-of-agile

For a siloed waterfall team, this might be a good first step. It would definitely move the needle toward becoming agile.

What get's confusing is when we equate iterative and incremental with agile. Agile is incremental and iterative but it is also a value system… a way of structuring teams… a way of treating individuals. Agile is an approach to engineering products, a technique for managing projects, and philosophy for leading organizations.

It is valuable for leaders to know how to define what their teams are doing. It is valuable for teams to understand where they are in comparison to where they want to be. We can take baby steps towards greater organizational and project agility by implementing some of the practices. If we declare victory before we've done the hard work, we risk never meeting our goals and diluting what it means to be an agile organization.

We should acknowledge where we are, understand where we want to be, and ask ourselves if we are really willing to make the changes required to get there.

Image Source:
http://www.dorlingkindersley-uk.co.uk/static/clipart/uk/dk/rock/image_rock004.jpg

Subscribe to this blog Subscribe to Leading Agile