Recently in Agile Category

This is a guest post from Bill Krebs, owner of Agile Dimensions LLC

The agile methodology of "scrum" is known for its 15-minute daily meetings. Its format contains three questions. Participants state what they did yesterday, what they will to today and what road blocker stands in their way.

The meetings can be deceptively powerful--if used correctly. But oftentimes they drag on for half an hour or more.

So what goes wrong? And how can you get back the benefits? Here are some ideas.

Focus

There are two kinds of work covered in a scrum meeting: Specific tasks from your project plans (or iteration backlog), and general interrupts and overhead (such as e-mail and meetings). Do team members ramble on about work that has nothing to do with their iteration backlog? Do they say a lot just to impress other teammates? 



Focus the talk on things that relate only to the tasks identified for that particular two-week block of work (an iteration). And then encourage people to focus on and finish two tasks per day. This will discourage the inefficiencies of multitasking. Team members are not limited to calling out roadblocks. They should mention any that appear. 



Have you ever heard someone who is "80 percent done" with a task every day? Each new day shows only partial progress, but never completion. Focusing on what was actually finished yesterday, and what will be finished today, helps cure this problem.

The scrum meeting is not about status. It's about completion.

Control the Number of Participants
Let the core testers and developers on the team do the talking. Other people may have an interest in the meeting, but they should just listen.

If your meeting gets bigger than nine people, hold two separate meetings and then have a "scrum of scrums" every few days where representatives from each group get together.

Go Offline
Our inner geek often wants to deep dive into architecture on the fly. (Who can resist?)

In those moments, however, the scrum master (who facilitates the meeting) should say, "That's a great topic, let's set up a time for the two of you to discuss after the meeting."

Don't leave everyone hanging while two people talk. And if you go a week without hearing your scrum master say, "take it offline," there may be room for improvement.

Remember My Three A's:
Awareness: The meeting is about knowing what your teammates are up to.



Ad: The meeting is an advertisement for collaboration. Micro teams of two to three people form, which makes for great collaboration later in the day.

Attack: Attack the blockers. The team can rally to address a problem--either within one minute in the scrum meeting, or more often, after the meeting. Problems that require detailed work by a subset of the team can be arranged for after the meeting. That way, people who are not involved don't have to sit through the discussion.



Those tips will cut the fluff--and speed up your work!

Agile and scrum are a passionate point of discussion. Just check out Michael Hatfield's
recent post, where he contends agile is just an excuse for scope creep Taking on Project Management Myths, Part 5, or see Lynda Bourne's post Agile: The Great Debate.

Despite the controversy, the number of people using agile approaches and scrum has spiked in the past three or four years, according to Jimi Fosdick, a certified scrum trainer at Danube, Portland, Oregon, USA.

When I talked to him a couple weeks ago, he said although there's a way for traditional project management methodologies to coexist with agile and scrum, challenges remain:

Organizational Structure: Companies aren't usually set up to handle the way the work is done in scrum and agile--and that's a very difficult thing to change.

Corporate Culture: Scrum is built on the principles of self-organization and self-management. So the development team doesn't really have a boss or a manager telling them what to do. And that's very scary for a lot of organizations. There's a prevailing belief--left over from the scientific management of the 1950s and 1960s--that unless you're watching what your people are doing, they won't complete the task at hand.

False Assumptions: Many of the policies and progress metrics in place in organizations and the artifacts and reporting required, are often counterproductive and run contrary to scrum. Some tasks--like needing sign-off on a full requirements document before development can start--interferes with the ability to do something in an agile way.

Read more on agile from Voices.

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!