Recently in Agile Category

It's finally time to expose the biggest myth as I close out my taking-on-the-myths series, hopefully generating plenty of lively responses.

Myth 2: Comparing your project's budget to actual costs is a natural way of assessing cost performance.

Truth: Comparing budgets to actuals is not only useless, it's misleading.

To back up this little piece of iconoclasm, I will invoke the widget example I use when teaching the subject of cost performance measurement.

Imagine you are a project management assigned to a project to make 2,000 widgets in two months with a budget of US$2,000.

You time-phase your budget US$1,000 in month one and US$1,000 in month two.

At the end of the month one your accountant tell you that you've spent US$1,100. How are you doing?

If you said "poorly" based on the fact that you have spent US$100 more than you budget, go to the back of the class.

If you said, "It depends on how many widgets you've made," go to the front of the class.

Because if you've made 1,300 widgets, and each widget is worth US$1, then the proper comparison is obviously the US$1,300 in earned value against the US$1,100 it took to make them.

A very simple example, I grant you, but it starkly supports my assertion.

The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry.

Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted.

My take is that the most lethal practice to project health is to allow informal changes to the technical baseline without changing the cost of schedule baselines--a practice commonly known as scope creep.

The IT industry is particularly susceptible to this, since changing the size of a building or the speed of a ship is hard to miss and affect. But changing the look, feel and capability of a software package may require little more than adding a few lines of code--and how hard that can be.

What started happening within the IT industry, on a common and costly basis, was that seemingly small changes in the various code modules created a configuration management nightmare.

So, we see the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda.

But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary.

So what do you think? Myth or reality?

Editor's note: PMI members who are interested in agile should check out PMI's new Agile Community of Practice.

Here's the number one thing I've learned by attending the Agile 2009 Conference: The agile community is an excited and engaged one.

I'm a first-time conference attendee and fairly new to the subject of agile, so while I can't say for sure this engagement is not an anomaly, my guess would be no.  

Whether it was Alistair Cockburn's keynote address or Programming With the Stars or just casual conversations, everyone I've come in contact with seems to be having a good time and to be passionate about the topic.

I've had the opportunity to attend several sessions, including two experience reports (also known as case studies): Jesse Fewell's session, "Marriott's Agile Turnaround," and Philip Abernathy's session "Hook, Line and Sinker--The Role of Line Management in Relation to Agile Teams."

Even to a novice, both were great. Both speakers were animated. Both were ready for whatever questions were thrown their way--and there were several of them.

Audience members weren't shy about interrupting (politely for the most part) with questions and follow-up. They weren't afraid to engage their fellow attendees in discussion. They weren't sitting in the back of the room playing on their iPhones.

When the conference ends, I will still be an agile novice, but I will have a better understanding of the roles within the agile community and the important role it is playing in organizations around the world.

Escorted on stage by a bagpipe rendition of Amazing Grace, Alistair Cockburn, Ph.D., began his keynote address for the Agile 2009 Conference by waxing Shakespearean on the death of agile as we know it:
 
I come to bury agile, not to praise it;

The evil methods do lives after them,
The good is oft interred with their bones,
So let it be with agile.

The noble Waterfall
Hath told you agile was ambitious:
If it were so, it was a grievous fault,
And grievously hath agile answered it.

(Adapted from Julius Caesar, Act 3, Scene 2. You can read Alistair's full monologue here.)

Melodramatic (in a good way) to be sure.

But Alistair, an IT strategist and co-author of the Agile Manifesto, doesn't really believe agile has "met its maker" as the saying goes. Instead, he said agile is in transition--it's not the agile of the 1990s. The landscape has changed. It's grown beyond small organizations and is being applied to much richer, much more complex concepts and projects.

Agile shouldn't be "new news," he said. "We're focusing so heavily on things that are 15 years old, I want to start focusing on things that are current."

He also shared three pillars of 21st century software development:

•    Software development is a craft: Developers must pay attention to their skills and to the medium--they must relearn every few years.
•    Software development is a cooperative game of invention and communication: It relies on teamwork, communication and strategies.
•    Software development should use lean processes: That means small queues, cross-trained people and varied processes.

Hosted by the Agile Alliance, the conference has pulled in 1,400 attendees from more than 38 countries. You can follow all of the conference happenings on Twitter.

Did you attend Alistair's keynote address? What did you think?

More to come. 

One element missing in much of the discussion around project management is a focus on the key early decisions that determine the project delivery strategy.  

At the project level, strategic decision-making focuses on optimizing the way the project will be structured and managed. Choosing between using Agile or Waterfall, pre-fabrication or on-site assembly, won't change the required project deliverables but will have a major influence on how the project is delivered and its likely success.

One size does not fit all; simply following previous choices ignores opportunities to enhance the overall probability of the project meeting or exceeding its stakeholders expectations.

Some of the key steps in designing a strategy for success include:

•    Familiarization with the overall requirements of the project and its stakeholders
•    Determining the key elements of value and success for the project
•    Outlining the delivery methodology and getting approval from key stakeholders
•    Developing the project's strategic plan based on the available know-how, resources and risk appetite of the stakeholders (including the project management team)

The problem with implementing this critical stage of the overall project delivery lifecycle is that it crosses between the project initiators and the project delivery team. Both parties need to be involved in developing a project delivery strategy that optimizes the opportunity for a successful outcome.

Unfortunately, the opportunities to engage in discussion and planning for project delivery are difficult to arrange. Frequently contract documents effectively prescribe a delivery process, and/or the client and senior management don't know they need to be engaged at this stage of the project lifecycle.

I suggest that project managers and project management offices start focusing more on the project delivery strategy during critical early stages of a project. What has worked or not worked on your projects?

I am just back from the PMI Global Congress 2009--EMEA in Amsterdam, Netherlands.

PMI seemed focused on the environment--with a keynote emphasizing the need to be more green--and on the value of project management, with the Research Working Session and a few tracks by PMI personnel on the subject.

The majority of tracks, however, seemed to hit on different topics, including:

1.    People issues, like decision-making, leadership, communication, culture, politics and stakeholder management
2.    The strategic link of projects, like organizational project management, project selection, portfolio and program management and the PMO
3.    Agile

I think this last one is a growing trend in project management.

Many of the concepts of Agile can be traced back to fast-track construction projects, where basic principles like co-location, fast prototyping, iterative development, daily orientation meetings and other concepts were developed.

In IT, the Agile methods evolved in the mid-1990s in reaction to what is called the "waterfall model," a sequential approach to programming.

In 2001, 17 prominent thinkers of what were then called "lightweight methods" issued the Agile Manifesto, which states four basic principles:

•    Individuals and interactions over processes and tools
•    Working software over comprehensive documentation
•    Customer collaboration over contract negotiation
•    Responding to change over following a plan

Although, in a way, Agile seems to be the antithesis of project management, as explained in A Guide to the Project Management Body of Knowledge (PMBOK® Guide), it can be very advantageous to use it in turbulent and strategic settings.

As project management is used more and more to manage strategic change and projects become more complex, Agile principles will influence more and more the management of projects, and more specifically, program management.

More in my next post ...

The Agile community has some good ideas to pass down to conventional project managers, including:

Customer Engagement
While it may not be possible to iterate the building of a piece of machinery, engaging and explaining to the customer in their language--no jargon--what's happening will highlight issues early. If the customer doesn't like something, the sooner you know, the better.

One of the key tenets of Agile is to engage effectively with your customer and end-users, understand their needs and problems, and then deliver an effective solution. This requires regular and effective communication, openness and accountability, and a good measure of trust to support robust relationships between the project team and their key stakeholders. It's a pity so many project managers put their energies into fighting the client rather than collaborating.

Going Light and Lean
Those are hardly new ideas, but they've been embraced by the Agile philosophy for a good reason: They work. Lean was developed by Toyota as a manufacturing philosophy and has been adapted to many other areas. Some of its key principles--such as minimizing unnecessary movement, simplifying process and continuous improvement--have huge potential in project management.

Light is focused on the minimizing unnecessary overhead. Complex plans and processes should be simplified, but only to remove excess complication, not to remove core requirements.  

Slimming down the project management overhead to its optimal level is probably the easiest way to free up the resources needed to engage your stakeholders more effectively and is definitely supported by the A Guide to the Project Management Body of Knowledge (PMBOK® Guide).

For more information, see Light Versus Lean -- Steps to Improve Project Efficiency from PMI's Community Post.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)--Fourth Edition has nine technical knowledge areas plus the overall integration processes.

By aligning these processes to the Agile delivery methodology, effective project management will enhance the probability of success. But you must recognize the processes are applied differently.  

Some of the areas that need an Agile approach include:

Project Scope Management
Traditional project management expects scope management to define the output. The final outputs in an Agile project should be defined in terms of achieved capabilities--how the capability will be achieved will be discovered along the journey.

Change control will be more challenging, as is configuration management. The overall project needs a really good systems architect to keep each iteration or sprint focused on contributing to the big picture.

Project Time Management
In an Agile project, scheduling and workflow become closely aligned. The overall system architecture optimizes the sequence modules needed to be built in to allow progressive testing and implementation of capability.

This defines the schedule. Scheduling should be at a much higher level; each sprint is likely to be a single activity of one to two weeks' duration.

Project Cost Management
Agile projects should be based on either a cost-reimbursable system, or the client accepts scope is a variable based on achieving the maximum improvement possible for a pre-set budget. This is a totally different philosophy to traditional project governance.

Project Quality Management
This is probably easier under Agile. Quality is continually assessed by the involvement of the client and the iterative release of modules to production.

Project Communications Management
The level of trust needed to run an Agile project is much higher than a traditional project. Effective communications in all directions are essential.

Project Procurement Management
Agile works in a collaborative partnering space. In the engineering world these are called alliance contracts. Traditional contracts do not support Agile delivery methods very effectively.

More later....

This is a continuation of the post Creating Trust in Agile.

Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements. Yet far too many technical managers see this as unnecessary hard work--and then they wonder why their projects end up unsuccessful.
 
Forget the jargon of "sprints" and "iterations." Communicate in your stakeholder's language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective?

Mind you, this is probably good advice for 90 percent of IT and technical projects. The challenge facing AAs is they don't have detailed plans and traditions specifications to benchmark progress against. New ideas need to be developed.
 
AAs should also create ways of managing and reporting risk, scope, cost, time and quality--not from the technical in-team perspective but from a senior management perspective.

The essence of Agile is flexibility and change. The traditional way of dealing with these issues is by measuring the current variance from a predetermined baseline. The issues are no less important in Agile. They just have to be managed and reported differently. The challenge for AAs is developing effective ways of communicating how they are being managed to their senior management.
 
Finally, AAs need to have ways of differentiating problems suitable for Agile solutions from those that need a different approach. Agile is not a cure-all for every project and problem--senior management knows this and AAs need to focus on areas where real value is created by the methodology.
 
I'm not an AA. So I'll leave it up to the Agile community leaders to work out a solution ...

Over to you for comment!
 

Trust--backed by skilled developers--is the core element of any Agile methodology. Within the project team, the trust is relatively short term and the model is trust, but validate.

The sub-teams are trusted to build a module in a short sprint of some form and the results are validated. Where a paradigm shift in trust is needed is between the organization's senior management and the Agile project leadership.
 
Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time.
 
The concept of predictability flowed into Waterfall; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt.
 
An Agile approach to problem solving is quite different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end."
 
With the right level of two-way trust, senior management can use Agile to maximize value. Essentially they can guide their teams using one of two approaches:

We want the biggest bang for our buck. You have X budget and X months to do the most you can. We trust you to spend our resources wisely to achieve the greatest value.

We need this regulatory requirement embedded in our systems by X. We trust you to deliver the required change in the most cost- and time-efficient way.
 
In both scenarios the Agile team is trusted to craft the optimum solution working with the end-users. The challenge is developing this level of trust. Unfortunately, even where change is desperately needed, it rarely occurs. In Leading Change, J.P. Kotter suggests over two-thirds of change efforts fail. Clearly, building the trust needed to allow the benefits of Agile to be realized will require some serious project management discipline.
 
To be continued ...

Editor's Note: This post is part of a continuing discussion on Agile. View Lynda's recent entries.
 

Over the last week or so, there seems to have been a flurry of activity in the blogosphere discussing Agile and waterfall software development, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and project management. This is an important debate.

A letter in the Feedback section of the March PM Network said Agile is not a project management methodology--I agree. Waterfall and various forms of Agile are definitely software development methodologies, not project management methodologies.

However, we can learn a lot with an open dialogue in both directions.

One common misconception among IT professionals is the assumption that the PMBOK® Guide approach to project management and the waterfall software development methodology are synonymous. Nothing could be more wrong.

Certainly you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development.

Another misconception is that any new software development is automatically a project. Projects are temporary endeavors--this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work.

With these misconceptions cleared, there seem to be three key areas for discussion. (Your comments will be welcome leading into some future blogs.)

What are the differences in the way project management processes are applied in an Agile project compared to a waterfall project? Some thoughts:

•    The need for a much lighter "touch" managing an Agile project
•    The need for a higher level of trust in managing Agile teams
•    The need for robust change management and configuration management to track the evolution of the Agile project
•    The critical importance of developing the correct strategy and architecture at the beginning of the Agile project

Can traditional project management learn from Agile? Some of the trends in Agile seem to have wider application in any project involving knowledge work, including:

•    The need to trust knowledge workers more than manual workers
•    Success measured by customer satisfaction rather than quantitative outputs
•    The need to keep the client involved

What triggers the choice between operational maintenance and development versus projects and waterfall versus Agile.

More later.