What is Agile?

Agile? Sourced from http.yogadogz.com

Agile is not a project management methodology but Agile principles can and should be applied to the management of projects and in the right circumstances the various forms of Agile offer an effective way to develop software. In their original design, Waterfall and the various forms of Agile are software development methodologies, not project management methodologies, and effective project management adapts to the processes being used to develop the project’s deliverables.

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 endeavours; 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, for more on this see: De-Projectising IT Maintenance

With these misconceptions cleared, there seem to be two key areas for discussion.

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

• There is the need top select the right projects for Agile, for more on this see: Selecting the right projects for Agile
• There is a need for a much lighter “touch” managing an Agile project; for more on this see: Managing Agile Projects
• There is a need for a higher level of trust in managing Agile teams, for more on this see: Advising Upwards
• There is a need for robust change management and configuration management to track the evolution of the Agile project
• There is a critical need to develop 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

Our discussion paper Thoughts on Agile looks at theses questions in more detail. The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated. The paper can be downloaded from: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

Selecting the right projects for Agile

I have just read an interesting article by Bob McGannon on selecting the right IT projects for Agile development. Bob is a Founder and Principal of MINDAVATION, a company providing project management training, consulting, keynotes & coaching services throughout North America, Europe, the Middle East and Australia.

Here is a précis of Bob’s guide to creating an appropriate filter for determining which projects would benefit from the use of Agile processes.

• An eager sponsor willing to conduct frequent reviews and evaluations of the evolving product.
• Ambitious, knowledgeable and available business representatives – The Agile process is purposefully collaborative.
• Minimal time to verify product viability: its power comes from its ability to produce quickly, adjust consistently to new knowledge and business change but only if the learning can be understood, interpreted and absorbed quickly.
• Minimal business exposure if the product produced is broken; it would be high risk to put a piece of functionality into a production environment if an error in that product would have a substantial impact on the business.
• A willingness to consider a very different approach; the ability to invest in a different work and management approach is necessary for the project stakeholders.
• The ‘DNA’ to deal with a bit of ambiguity. Priorities are consistently reassessed and work sequences changed.

The full article can be found at http://www.mindavation.com.au/articles/may10_intellections3.html

Bob’s approach is closely aligned to the ideas discussed in Mosaic’s White Paper on Project Strategy; see: http://www.mosaicprojects.com.au/WhitePapers/WP1038_Strategy.pdf; one approach to every problem seldome dilivers optimum outcomes.

Project Management 2.0

Project Management 2.0 (PM 2.0) seems to be going the same way some Agile anarchists are trying to take software development which is essentially not to do project management and hope a group of people with good will and good luck will create something useful.

Not doing ‘project management’ is a really good idea if you and your client have no idea what’s needed, when its required, or how much budget is available. Journeys of exploration can be fun and can be highly creative but are nothing to do with managing projects.

Wikipedia (retrieved 27/9/2009 from: http://en.wikipedia.org/wiki/Project_management_2.0) lists the following differences between PM 2.0 and ‘traditional’ project management.

PM 2.0 -v- Traditional PM

Whoever wrote this has absolutely no idea what good traditional project management looks like and has probably never worked on a successful major project. Good traditional project management differs from this highly subjective and biased list in many ways:

• Control is not centralised, authority and responsibility are devolved to the appropriate management levels.
• All good project management is based on collaboration.
• All good project management requires open access to the plan both as an input to its creation and to know what needs doing during delivery.
• Access to information is vial when and where needed.
• Open and effective communication is critical.
• Project are,  by definition, separate management entities – a holistic approach (ie, not doing projects) is called general management.
• Tools, see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. Easy to use and flexible are fine if you know exactly what you are doing, it is a recipe for wrong information and wrong decisions if you don’t.

The table is correct in so much as project management involves a degree of top down planning. Project management is about delivering a required output to the specifications requested by the client. The product or service is a failure if it does not meet the quality requirements set by the customer; which may include time, cost and scope parameters.

It is also correct in respect of the implied structure – projects work because there is an implied structure that sets a framework for collaboration. If you don’t know who is doing what it is nearly impossible to collaborate. Even Wikipedia and Linux have structure in their collaborative frameworks.

I have emphasised good project management throughout this post. Bad project management involves excessive attempts to ‘control the future’, lack of stakeholder involvement, excessive bureaucracy, and many other problems. These traits are bad management full stop.

One comment on the Wikipedia article is important though: PM 2.0 is good for small jobs. This is consistent with a survey of construction projects in the UK undertaken by the Chartered Institute of Building, focused on time management, which found that on ‘simple projects’ there was no difference in performance between those projects with a properly developed and managed schedule and those without. The same proportions finished early, on time and late.

However, as soon as the projects became ‘complex’; there was a marked difference in performance. Projects with effective schedule control performed significantly better than those without, and the bigger/more complex the project, the more significant the difference. ( I will put up a post on the CIOB’s work and its new practice standard for scheduling in a few days).

The CIOB’s findings and a closer look at many of the blogs and comments on both PM 2.0 and Agile seem to fit this trend. I would suggest two conclusions could be drawn:

1. If the work is small, simple and easy to understand there is no need for much in the way of traditional project controls. Knowledgeable people know what needs to be done and can just get on with the work.
2. If the required output is not capable of being determined by the client and the objective is to ‘create something wonderful’ it is very difficult to apply too many project management techniques – basically you don’t know what needs to be planned, costed and scheduled, etc. Time and cost are secondary to creativity and the exploration of problems.

In both of these circumstances traditional project management may not be appropriate. In fact I would question if either circumstance is actually a project given the definition of a project is to produce a defined product, service or result that meets the needs of a customer.

The challenge for senior organisational management is recognising the threshold where PM 2.0 and ‘free form Agile’ cease to be appropriate and more traditional forms of project management are needed. Traditional project management does not mean ridged control, the type of project influences what’s needed (see: Projects aren’t projects – Typology) but appropriate systems do help optimize cost, time and quality to deliver client satisfaction.

This does not mean dumping the new ideas, rather melding them into an improved project management process. Agile software development fits in nicely to ‘rolling wave’ planning. Similarly some aspects of PM 2.0 can really help enhance team communication and collaboration. Used wisely, these ideas and technologies simply help improve the way projects work to deliver quality outputs to their clients. This change is really no different to the shift from faxes and carbon copy paper to emails. Good project management has always adapted to use improvements in processes and technology to improve the quality of service provided to the project’s clients. This next wave of improved technologies should be no different.

However, be wary of the zealots suggesting the ‘old ways’ don’t work and should be abandoned and use examples of really bad project management to prove their point. This is even more important if the zealots also advocate employing them to solve all of your problems for a fee. Management fads come and go – modern project management has been generally successful in achieving positive outcomes for well over 50 years now and continues to evolve and improve. For further comment see Glen’s post on: Herding Cats

Thoughts on Agile

Following on from a rather lengthy on-line discussion covering various aspects of the interface between the Agile software development methodologies and project management, we have developed a discussion paper that looks at how the two processes can be integrated.

The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated.

The paper can be downloaded from: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

Agitating Agile

I have been involved in a series of posts on both my SRMM Blog (see post) and the PMI Voices on Project Management blog (see post) that have stirred up sections of the agile software development community.

Despite the Agile Manifesto focusing on providing excellence to stakeholders, many Agilists seem intent on advocating their rather extreme view of agile including no documentation, little planning or architectural design and less control. The mantra is ‘give the software developers free reign and you will get better software’. Whilst this may be true (although I somehow doubt it in anything but the smallest and simplest projects) it ignores the needs of the project’s key stakeholders.

Most IT projects exist to enhance the capability of the organisation. Consequently the software development is only one part of an overall project to change the organisation, deliver new capabilities or similar. In these typical circumstances, the IT component needs to meet predetermined requirements; any change in the IT capability delivered requires changes in other parts of the project. In fact the best IT solution may turn out to be an unacceptable business solution.

Meeting the needs of the businesses key stakeholders demands discipline and communication not just within the ‘scrum’ or XP team but to the customer’s managers. This needs at the very least a minimum of documentation to prove the IT team and its immediate customers understand their scope of work and other constraints and know how they will achieve the outcomes needed to support the business. Adequate documentation and effective communication are essential.

This post is not suggesting a return to Waterfall or other heavily documented software development process (they don’t work very well anyway – refer the Standish reports) but rather for an appropriate level of documentation to meet the genuine needs of senior management stakeholders. Saying ‘trust me’ is not enough and is not good stakeholder management.

Identifying the key stakeholders, assessing their requirements and expectations and then managing these key relationships so the stakeholders realistic expectations can be realised definitely involves up-front planning and effort, needs tools and methodologies such as the Stakeholder Circle® and involves on-going monitoring and control but is, I would suggest, worth the effort. Your project is unlikely to be seen as successful if the stakeholders expectations are not realised!

In most aspects of life the long term enjoyment of real freedom required a significant measure of self discipline. The agile extremists may do well to consider this and focus on meeting the needs and expectations of all of the stakeholders involved in their work.

PMI Launches the PMI Agile Community of Practice

The Agile Community of Practice is dedicated to raising awareness of Agile practices and techniques among PMI’s members. Its focus will be on building an emerging knowledge base using wikis, blogs and discussion threads. Plus additional resources include articles, tools and techniques, links to Agile project management literature and more. During the launch, membership is free to PMI members.

For more information see: http://www.pmi.org/GetInvolved/Pages/PMI-Specific-Interest-Groups.aspx

The collaborative management paradigm inherent in Agile – a new frontier

The Agile software development methodology has a fascinating range of ideas that can provide valuable learning’s to traditional project managers and in the wider sphere of stakeholder management.

Over the last few months I have been publishing a series of posts on this topic on the PMI Voices on Project Management blog. The key posts with a brief summary and links are:

Agile: The Great Debate
An overview of the Agile software development methodology and its impact on project management.

Creating Trust in Agile
Managing upwards, the trust and communication needed for Agile to succeed.

The Role of Agile Advocates
Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements.

The Gentle Art of Managing Agile
Applying the PMBOK to managing Agile projects.

Learning From Agile
The importance of customer engagement and going ‘light and lean’.

I invite you to read these posts and think on your project management and/or stakeholder management practices.

The Last Planner and other Old Ideas

I never ceased to be amazed by the number of people who either have no knowledge of project management history and established practice or chose to ignore established practice in favour of a new fad that is the old practice recycled. Given modern project management is less than 60 years old this is a worry (for more on this see The Origins of Modern Project Management)

One of the more annoying ‘new ideas’ is the Last Planner® this methodology has at its root, the idea that the best people to involve in the planning process are the front line supervisors and team leaders who will actually have to do the work. This is a really great idea that has been used by good schedulers since the 1960s. Certainly when I was learning the craft of scheduling construction projects in the early 1970s one of the key messages from my teachers was that there was no point in developing a schedule unless; (a) the foreman though the sequence of work was best and (b) the foreman understood what was involved in the work. In effect my job was to make sure the foremen totally agreed with and understood all of the work implications in the schedule. As a bonus the foreman also was likely to know more about what was involved in doing the work than a green scheduler so we ended up with a realistic and achievable schedule.

Fast forward 40 years and a whole new idea called Last Planner® is being marketed with the idea the front line supervisors should be actively involved in scheduling the work using techniques such as affinity diagrams (Last Planner calls this post-it-notes stuck on the wall). There’s nothing wrong with the ideas in Last Planner® it just not new – the fundamental processes were being used by skilled schedulers 40+ years ago.

The reason this sort of recycling is seen by so many as ‘new ideas’ has been canvassed in A Brief History of Scheduling – Back to the Future. The advent of desktop PCs virtually wiped out the scheduling profession.

Similar adaptation of sound ideas from the past can be found in the concepts of ‘Light’ and ‘Lean’ project management. Both of these seem to be mantras of the Agile software development community (no guys – Agile is not a project management methodology, it is a way to develop software: see Agile is NOT a Project Management Methodology and two later posts).

Lean manufacturing was made famous by Toyota. Some of the key principles such as minimising unnecessary movement and waste, simplifying process and continuous improvement have huge potential in both software development and project management. But Lean is Lean, it was developed by Toyota and can be adapted to areas other than manufacturing. It’s a good idea but it was not invented as a part of Agile.

Light is a different philosophy focused on minimisation of unnecessary overhead. Complex plans and processes should be simplified, but only to remove excess complication, not to remove core requirements. This philosophy is certainly a part of Agile but again hardly revolutionary. Its roots can be traced back to the ideas of Scientific Management in the early 1900s and Parkinson’s writings in the 1950s.

Perhaps as the song goes; ‘everything old is new again’? Or maybe only a few of us have been around long enough to either remember the song or know our history?? At least a few of us old time schedulers will be able to kill off a few more brain cells in Boston next week (by the moderate use of good wine and beer) at the PMI COS conference ‘Revolutionary Scheduling’. It will be interesting to see all of the new ideas as well as adaptations of old ones.

PMI’s ‘Voices on Project Management’ Blog

Just a quick note to let you know I have joined the PMI ‘Voices on Project Management’ team of bloggers. Over 40 people commented my recent post discussing the Agile software development methodology [see my posts].

Given PMI’s central role as a project managment standards developer, you are all encouraged to join in the discussions sparked PMI’s range of ‘voices’ on their blogs to help drive the evolution of project management world-wide.

Managing Agile Projects

The two earlier blogs in this series focused on what’s NOT project management.

Agile and Waterfall are two different software development methodologies (see: Agile is NOT Project Management)

Operational maintenance with stable teams dealing with new work and maintenance upgrades on an organization wide basis is not project management even if there are new features being added to the IT infrastructure. This type of work is traditional operational management even if scrum and other Agile techniques are being used (see: De-Projectising IT Maintenance)

Traditional IT project management has grown up around and closely aligned with the Waterfall software development methodology. As with most engineering projects the final product to be delivered is scoped, designed, built, tested and implemented – in that order. This is OK if the client knows what it needs precisely and the number of changes is relatively small. Waterfall falls down (pardon the pun) if the project is a quest to achieve an objective and everything changes routinely.

Agile seems to be an ideally suited methodology for developing the software but if the work is also a project how should the PMBOK® Guide processes be applied? This blog will outline some ideas at a high level, later blogs may dig into some areas more deeply.

The PMBOK® Guide 4th Edition (2008) has 8 knowledge areas:

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

This makes ‘Verifying the Scope’ interesting. There needs to be clearly defined way to assess if the capability has been delivered. How do you measure a ‘user friendly interface’? It’s not impossible to do but how it’s done needs to be clearly defined.

Change control is also more challenging, as is configuration management.

Project Time Management
Ideally time should not be an issue if the objective is to achieve a required capability. In reality there are usually deadlines.

In an Agile project, scheduling and workflow become closely aligned. The key requirement is an overall system architecture that defines the sequence modules need to be built in to allow progressive testing and implementation of capability. The software architecture defines the build sequence that defines the schedule.

Scheduling is at a much higher level though. A ‘sprint’ is likely to be a single activity of 1 to 2 weeks duration. The sequencing of the ‘sprints’ and the number of sprints that can operate in parallel define the resource requirements and the project duration.

Project Cost Management
Agile projects have to be based on a cost reimbursable system. One tool designed to include a degree of competition with the ability to properly compensate the contractor for its work is southernSCOPE the methodology requires tenders to bid on a project at a $ per function point rate based on a project description and the estimated number of function points. At the end of the project the same independent person who prepared the initial estimate, re-counts the function points and the price is determined.

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 Human Resource Management
Basically remains unchanged but the skills of the people needed for an Agile project are likely to be different.

Project Communications Management
The level of trust needed to run a Agile project is much higher than a traditional project. Effective ‘real’ communications in all directions are essential. This is different to producing project reports! More later.

Project Risk Management
Recognize you are on a journey focused on delivering value. Significant time and cost contingencies are needed and should be used to optimize the value of the final product. More later!!

Project Procurement Management
This should not change significantly BUT the procurement process needs to be aligned to what it is buying. Agile works in a collaborative partnering space. In the engineering world these are call Alliance Contracts. Traditional contracts will not support Agile delivery methods.

In conclusion: align the PMBOK to an Agile project delivery method and the overarching PM process will enhance the probability of success. Treat an Agile project in the same way as a traditional Waterfall project and the PM processes will guarantee failure!