Project Management is Not Enough

Are you a software project manager? If so, your job is changing. It is no longer enough to keep the risk list up to date. It is not enough being the person to schedule the meetings and do the minutes. Knowing how to calculate earned value and critical path is the price you pay to even call yourself a project manager.

Great project managers take those skills for granted. Great project managers are defined by how well they lead their teams. Great software project managers establish context. They create organizational alignment and guide their projects toward successful project outcomes. Great project managers focus on team building, they open lines of communication, they trust people, respect and empower them, and maintain sufficient control to hold everyone accountable for project outcomes.

In my experience, project managers tend to look at themselves in one of two ways. Some PMs want to be at the center of the project, in control of everything, in the middle of every decision. Like the illustration on the right, they try to be the center of the wheel with all team members connecting through them.

Others lead from the boundaries, they create the context. They establish the parameters of the project, the outer limits. They trust the project team to deliver the desired outcomes within those limits. These project managers build teams, get them what they need to be successful, and remove any barriers that could stand in their way. The project manager on the left is intentional about creating and maintaining connections between team members and acting as the buffer to the rest of the organization.

Traditional project management tends to focus more on the science of project management and less on the leadership and team aspects. Agile can sometimes focus too much on the softer side. It's my view that the process driven, scientific side of project management should be a given. That is your ticket in the door. Its time we start hiring great project leaders. It's up to us to get serious about becoming great leaders.

Otherwise, don’t call yourself a project manager.

Here is a link to my post on Agile Chronicles: http://blog.versionone.net/blog/2008/06/project-managem.html

Subscribe to this blog

Photo Credit: http://www.projectstrategy.com

Subscribe to Leading Agile

Announcing the 3rd Annual "State of Agile Development' Survey

It is that time of year again - Version One has launched it's 3rd Annual 'State of Agile Development' Survey.

This is not a vendor or tool survey, it is meant as a global survey on the general state of Agile development (hence the catchy name). Last year the survey received 1,700 completed surveys from 71 countries. The results from past surveys have been written up in publications ranging from CIO Magazine to InfoQ to SDTimes and the Agile Journal. The results are also e-mailed directly to participants.

Learn more and take the survey HERE

It should take 5 - 10 minutes to complete and your participation is greatly appreciated.

What do you get for participating? By contributing and sharing data anonymously, you will help create the largest data collection on the value of Agile development practices and have direct access to the aggregated results. VersionOne is also giving away participation prizes consisting of 3 Amazon.com gift certificates totaling $1,250.00.

Thank you in advance for your participation.

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Cost Management

Next up is cost management. According to PMI, cost management includes the processes involved in planning, estimating, budgeting, and controlling costs so that the project can be completed within the approved budget. This knowledge area only includes three process, but as you might expect, we are going to put a little different spin on them and see what we can do to make them more agile.

Cost Estimating

PMI Definition: Developing an approximation of the costs of the resources needed to complete the project activities

We discussed in the last post that agile projects typically start with time and cost as the primary constraints and float scope through the life of the project. While this is true, there should always be some sort of assessment at the beginning of the project to determine what value the customer might expect at what level of investment.

The product owner might approach the team with a high level backlog of features that need to make the next release. The team would then estimate the backlog and calculate how many iterations they expect the work to take. There would be a negotiation of scope, team composition, and release duration as everyone comes to consensus around what is possible.

The cost of the project is then established as the product of team size and project duration.

Cost Budgeting

PMI Definition: Aggregating the estimated costs of individual activities or work packages to establish a cost baseline

Agile teams assess the relative size of each item in the backlog. Some teams also put a numeric value on the expected ROI of each feature in the backlog. In aggregate, the size of the backlog determines how many features can be delivered and thus the overall value of the release. Because costs are assumed to be a constraint, cost budgeting on an agile team is much more a statement of how much value can be delivered, over the life the project, for the approved budget.

The budgeted amount of value for the project is represented in the release backlog.

Cost Control

PMI Definition: Influencing the factors that create cost variances and controlling changes to the project budget

With the cost of the project now established as a project constraint, agile project are not nearly as concerned with controlling the costs and variances of individual work items. Agile teams are most concerned with how quickly the project begins delivering value and at what rate. We need to monitor how well we are delivering the anticipated features and if we have deviated from the rate we had originally expected.

If the project is not progressing as well as we might have hoped, we may need to remove less important features from the backlog. This will decrease the value to the customer and implicitly increase the cost per feature. If the product owner chooses to extend the duration of the project, to realize all of the anticipated value, this would increase the real costs to the project.

Delivered value is tracked primarily by measuring project burndown. Here we assess the total value of the release, what value the team had expected to deliver at the end of every iteration, and compare the actual value delivered against the ideal.

By monitoring project burndown the team can assess and control the cost impact to the overall project.

Next up... Scope Management

Subscribe to this blog Subscribe to Leading Agile

Agile Managers?

What are we going to do with all the managers when we realize the vision of fully self-organizing teams? What incentive to managers have helping teams become more independent if they are in effect working themselves out of a job? I was up at the Agile Coaches Camp this past weekend in Ann Arbor, Michigan. A few of us bounced this idea around a bit and came up with a proposal.

On a self-organizing agile team, the resource manager is responsible for supporting their team's career development, personal growth, and training; they are also responsible for removing organizational impediments that hamper their team's ability to perform. Just as a ScrumMaster protects and supports the project team, the Resource Manager protects and supports the resource team.

What do you think? Too simple?

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Time Management

The first knowledge area we are going to tackle is Time Management. According to PMI, time management involves those processes that contribute to the on-time completion of the project. This knowledge area includes six project management processes designed to accomplish this goal. We'll explore all six and see how we can adapt these processes to make them a little more Agile.

Activity Definition

PMI Definition: Identifying the specific schedule activities that need to be performed to produce the various project deliverables.

To make this process more agile, you first need to think in terms of defining the features of the system, not the activities. Up front we want to know how the system is going to behave. These feature specifications need to be small and independent of each other. Agile teams usually call these features a user story or a backlog item. Collectively the list of product features is called the product backlog. The backlog represents the scope of an agile project.

Activity Sequencing

PMI Definition: Identifying and documenting dependencies among schedule activities

While discussing activity definition, we stated that the backlog items need to be independent of each other. The reason they need to be independent is because we want to have the ability to change requirements as our understanding of the evolving system changes. By definition we are seeking to minimize the dependencies between the work items on our project. Sequencing on an agile project is based less on dependencies and more on risk and business value. We want to focus on sequencing based on which features are going to reduce the most risk and deliver the most value as early in the project as possible.

Activity Resource Estimating

PMI Definition: Estimating the type and quantities of resources required to perform each schedule activity.

In traditional project management approaches, we are usually trying to determine the type and quantities of resources when we know the least about what it is we are going to build. Spending time and money to get a better understanding of these variables is not going to yield a substantial return. Agile approaches use a technique of estimating that relies on the collective understanding of the team to determine a relative size estimate of the feature, often measured in units such as story points or ideal engineering hours. These units only asses the size of the feature relative to the other features in the backlog.

Activity Duration Estimating

PMI Definition: Estimating the number of work periods that will be needed to complete individual schedule activities

We've discussed that each feature in the backlog needs to be small. Our goal is to have every backlog item small enough that it can be delivered within a single iteration. Agile teams build in this constraint and then measure how many features they are able to complete in a given iteration. By measuring how many story points, or ideal hours, they are able to complete each iteration, the team can predict how many iterations it will take to complete the backlog.

Schedule Development

PMI Definition: Analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule

Typical agile projects begin with a time constraint, iterations are fixed periods of time and release schedules are usually established at some fixed interval. Each of these are set by the team and the product owner, but once set do not change. That language might sound a little strong but agile is about building trust with your customer. Good agile teams can always make their date, it is the scope that will vary.

Schedule Control

PMI Definition: Controlling changes to the project schedule

Because the iteration and release timeframes are fixed, it all comes down to a discussion around scope. These discussions are a constant collaborative effort between the product owner and the team. The product owner always has the option of adding additional iterations to include more features. Because the features are discrete, and the team is always working on the highest priority features first, the product owner also has the option of calling the project complete at the end of any iteration.

As always, if you think there is anything I left out, or should have dealt with in more detail, please let me know via response to this post. I speak on this subject quite a bit so anything you have to contribute to make this brief explanation more understandable would be really appreciated.

Next up we'll deal with cost management processes.

Here is a link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/06/refactor-your-p.html

Subscribe to this blog Subscribe to Leading Agile

Mike's Agile2008 Abstracts

The Agile 2008 conference is just around the corner. This is a great opportunity to hear some fantastic speakers and get to know the broader Agile community. It is a blast getting together with other folks that are passionate about Agile and want to make a difference. You can get more information about the conference by clicking here.

For those not familiar with the content selection process, the entire community was encouraged to submit session proposals. These proposals were publicly reviewed and all comments were available to everyone. Some people really did not pull any punches, it was pretty brutal. After a period of review, the selection committee took a crack at the proposals and made their decisions. Everything was very transparent and I was really impressed with the process.

I will be giving three talks over the course of the week, all three on topics I am very passionate about and have blogged on over the past few months. If you happen to be at the conference, I would love to meet you and hear your feedback on my writing at Leading Agile or over on Agile Chronicles.

Here are the session titles and abstracts I've submitted for the conference proceedings:

Leading Volunteers With Agility

Volunteer organizations are unique because people are not paid for their contribution and your organization is in competition for space in an already over-booked schedule. By necessity, volunteer organizations require a more human-centric approach to leadership. This workshop will explore the 10 things you better be doing if you want to harness the passion and enthusiasm of your team of volunteers. Topics such as empowerment, self-organization, and short-cycle delivery will be addressed using real world scenarios.

Wednesday August 6th from 2:00 - 3:30 in the Huron Room

The Good and Bad of Agile Offshore Development

Companies today are attempting to lower costs and increase their staffing flexibility by taking some [or even all] of their development activities overseas. Simultaneously, many of these same organizations are exploring agile development practices in an effort to increase quality and to improve project performance. This report explores the intersection of these two significant trends common in today’s software development organizations. We will show how our team built an effective agile offshore development capability, what we learned along the way, and what we would do differently next time around.

Thursday August 7th from 4:00 - 5:30 in Conference Room H

Using the Unified Process as a Scaling Framework for Scrum

One of the common complaints about the Unified Process is that it is too prescriptive and document focused. An often heard complaint about Scrum is that it does not scale to large projects and you never quite know where you are going until you get there. What if we could leverage the best of both methodologies? What if we could deliver with just enough structure and documentation to scale the project but maintain the collaborative, human centered approach of Scrum? This talk will show you how it’s done.

Friday August 8th from 8:30 - 10:00 in Conference Room C

My Bio

Mike is a Product Consultant and Agile Evangelist for VersionOne. Prior to joining VersionOne, Mike was a Senior Project Manager for CheckFree Corporation where he led a portfolio of projects for their online banking and bill payment business unit. Mike has a background in traditional project management but has worked primarily with agile methodologies for the past four years.

Mike is a certified PMP project manager and a certified ScrumMaster. Mike co-created the DSDM Agile Project Leader certification. He holds this certification at the Foundation, Practitioner, and Examiner levels and was recently named an honorary member of the DSDM consortium. Mike is on the board of APLN and the current Treasurer.

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP

In software engineering, refactoring a module of code means that you change its internal workings while leaving its external interfaces intact. A developer might do this to make the internal workings of their software simpler, more efficient, or easier to understand. The key is that refactored code maintains it's contract with the surrounding system. Everyone can still get what they need from the refactored system component in exactly the way they have always gotten it.

There is something here we can draw from as project managers. As we make the switch to agile project management, we must stay plugged in with the language of the organization. We need to maintain the contract the business has come to expect. Over time we may be able to influence how our organizations think about project management best practice. At some point we may even be able to renegotiate the contract.

For now, we need to take what we know about adaptive and traditional project management and establish a framework for delivering in the language of the business. The PMI process groups and knowledge areas provide a well thought out and disciplined foundation on which to build. Our challenge is to approach the discipline of project management with an agile mindset. To figure out how to leverage agile practices within the constructs of the accepted project management best practices.

Over my next few posts we'll break down the PMI process groups, knowledge areas, and processes to explore how we can build an effective agile framework using the established contracts. If you are interested in a little pre-reading, check out the following posts from my blog and a few others:

Assumptions are Made to be Validated - Mike Cottmeyer

Inverting the Iron Triangle - Mike Cottmeyer

Calgary APLN Meeting Slides - Mike Griffiths

PMBOK 4, This Time It's Agile - Mike Griffiths

Herding Project Managers - Mike Cottmeyer

The Role of the Project Manager - Glen Alleman

Subscribe to this blog

Subscribe to Leading Agile

Agile is Risk Management

There was a great question last week in the comments of one of my blog posts. The reader asked if agile offered any unique proposals for managing risk on a project? I've been blending my traditional background in project management with agile for several years now and sometimes I have to remind myself of what I've taken from what sources.

After reviewing the PMBOK section on Project Risk Management, I had to conclude that Agile doesn't really offer anything new. Surprised? The PMBOK has processes for developing a risk management plan, identifying risks, performing qualitative and quantitative analysis, conducting risk response planning, and monitoring and controlling risks.

You can clearly make the case the agile might take a lighter approach to risk management, maybe rely less on documentation, but fundamentally you are doing many of the same activities on an agile project as you might on a traditional project. Why are agile methodologies so good then at identifying and mitigating risk?

Agile is so effective at managing risk because risk management processes are built into the very fabric of how we run the project.

There is an implicit understanding that risk is EVERYWHERE on a project. Risk cannot be contained in a risk list. Risk cannot be mitigated in a team meeting or a periodic risk review session. Dealing with risk has to be an obsession. Our mitigation strategies don’t live outside the project, but influence the very nature of how we structure and plan our work.

Many project managers take a boiler plate approach to risk management. They deal with the easy stuff, the obvious risks that could be assigned to almost every project. Are we going to run out of money? Are we going to lose a key contributor? What happens if the project is late? While these are all important, they only represent a small slice of the kinds of risk we need to consider.

As project managers, we tend to assume that the business vision is accurate. We assume that if we deliver to the spec we'll satisfy the market needs. We gloss over technical uncertainty because the technology guys are responsible for making all the code work. More detailed planning and designs do not mitigate risk. The only thing that really mitigates risk is delivering product.

Agile mitigates risk by building project frameworks that encourage frequent delivery, constant inspection and review, and allow us to adapt when things are not going as you expect.

In short, agile is risk management.

Subscribe to this blog Subscribe to Leading Agile

Taking Agile Offshore

Companies today are attempting to lower costs and increase staffing flexibility by taking some, or even all, of their development activities overseas. Many of these same organizations have teams that are using agile development practices in an effort to increase quality and improve project performance. Some teams might find themselves in a situation where they didn't choose to take their teams offshore; but that decision was, in fact, made for them.

What happens when these two trends in our industry intersect?

There are tools and techniques that you can draw from agile that are essential for any kind of offshore endeavor. Development practices such as test driven development, continuous integration, and pair programming can be a powerful risk reduction mechanism to ensure the quality of your product and reduce uncertainty.

Defining requirements as user stories, building out thin slices of the product, and frequently reviewing those features with the customer can go a long way to making sure you are building the right product. Using these techniques help mitigate timeline risk because the product is always in a nearly releasable state. Daily stand-up meetings, sprint planning, and sprint closedown provide essential visibility into the development process and create an environment where you can inspect progress and adapt based on that feedback.

You never get too far off before you have the opportunity to adjust.

Teams working across dramatically different time zones, separated by thousands of miles, are going to need more documentation to stay in synch. There is not enough communication bandwidth to keep everyone busy and on the same page. Documentation needs to be viewed as a means of communication and not the deliverable. It is overhead. Keep doc as simple as possible to get the point across. Having a solid architectural description, very specific story descriptions, and clearly articulated acceptance criteria are key.

You'll need to adapt some of your agile leadership philosophies to accommodate the unique characteristics of your offshore team. You might have to take a more prescriptive approach as the team is coming up to speed. Not everyone may be culturally ready to accept the level of responsibility that agile requires. You may need to have a senior team member hand out stories, rather than having the team self select, to accommodate background and experience.

Be intentional about these deviations and have a coaching strategy for moving team members where you need them to be.

Taking an agile approach to offshore development is going to expose you to more junior staff than you might be used to working with. The market, especially in India, is very tight. As developers gain experience, many of the best people will move into management. You may experience 2-1, 3-1, or even 10-1 productivity differences between your more senior onshore guys and the offshore team.

These differences, coupled with increased documentation, increased communication delays, increased management and tracking burdens, and increased coaching overhead; create a much more complicated financial picture than just hourly rate. Using offshore talent will result in increased working hours and increased demand on the capability of the onshore developers. If cost savings are your primary driver for going offshore, you might want to look very closely at the numbers and measure if you are really getting the savings you expect.

The hourly rate is not all you need to take into consideration.

If you have had a different experience with agile in an offshore model, please feel free to comment, especially if you disagree with my conclusions. If you are a developer working for an 'offshore' outsourcing firm, please let us know if you think these experiences here are typical. Do you have any thoughts on how the typical offshore relationship will evolve, over time, as rates and technical experience go up? These are all interesting questions.

I will be sharing an experience report with the community at Agile 2008. If you feel strongly about these topics, please come find me. I would love to hear how using agile with an offshore team has worked for you.

Subscribe to this blog

Subscribe to Leading Agile

The Agile Edge Conference

Next week Valtech and VersionOne are co-sponsoring a one day conference called the Agile Edge. This will be an intense introduction to Agile designed to give attendees tools they can use to drive organizational transformation and breakthrough performance. David Anderson will be kicking off the event so it should prove to be a very informative and exciting day.

The conference will offer three tracks, each covering a different role on the project: product owners, developers, and project managers. I have the honor of doing the talks on the Agile Management track. We've prepared three presentations that are geared toward traditional project managers making the switch to agile.

Refactoring your PMPs
Successfully moving to Agile Project Management will hinge largely on how well we adopt new ways of thinking about project structure and control. Building on the principles of PMI and the Project Management Body of Knowledge (PMBOK) we will explore how a PMP can adapt their knowledge and experience to become an effective Agile Project Manager.

The Agile Power Shift
Agile methods build high-performing project cultures and put a great deal of emphasis on trust, empowerment, and self-organization. Agile moves us away from command and control project structures and toward structures that help us tap into the passion, creativity, and enthusiasm of the team. This team centric approach can leave the traditional project manager wondering about their new role on an agile project. This talk will explain the essentials of agile team dynamics, how teams contribute to project success, and what we must learn to become effective agile project leaders.

Agile Project Management Explained
Agile represents a dramatic shift in thinking about project management. It also represents a pretty radical shift in what a project manager does. At some point project managers have to transition from thinking about Agile to actually making it happen. This talk will explain the mechanics of running an Agile project and how these techniques support the principles behind Agile methodologies.

For those that cannot make the talk next week in DC, we'll be offering this conference in other cities around the country. Next up is New York on June 25th. Click here for more information and to register for the event. Looking forward to seeing everyone there!

Subscribe to this blog

Subscribe to Leading Agile