Agile Chronicles

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.

Photo Credit: www.projectstrategy.com

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.

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

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?

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.