Share this eBook:

Agile Project Management

Share this eBook:2

OverviewIn this paper we will explore a brief history of Agile Project Management, review the wider context of agile methods and identify which organisations govern the methods. We will examine Agile working against other project management methods and see how the approach challenges the role of the traditional project manager.

The key playerswww.agilealliance.orgAgile Alliance supports those who explore and apply Agile principles and practices in order to make the software industry more productive, humane and sustainable.

www.scrum.orgScrum is a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge

www.dsdm.orgDynamic Systems Development Method (DSDM) is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

OriginsThe birth of agile can be traced back to 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review.

In that study Takeuchi and Nonaka outlined how software development was managed similarly to a relay race in that as each group of specialists finished their piece of work it was passed to the next group of specialists, just like the baton in a relay race. However, they suggested that high performing, cross functional teams working similarly to those in a rugby team could constantly move the ball (or the project deliverables) back and forth between them ensuring that the speed of the project is much greater than in a ‘relay’ style.

3Share this eBook:

Other points of interest in the history of Agile include:

Introduction of the term ‘lean’ in the paper that John Krafcik wrote for his PhD identifying the set of tools that can be applied to eliminate waste and improve the quality of processes, not just of manufacturing but also of software development.

The first release of DSDM in 1994 and the creation of the Scrum method in 1995.

Creation of the eXtreme Programming approach by Kent Beck, Ward Cunningham and Ron Jefferies in 1999, advocating frequent “releases” in short development cycles, to improve productivity and introduce checkpoints where new customer requirements can be adopted.

In 2001 there was a meeting of all the key players in agile, leading to the formation of the Agile Alliance and the creation of the Agile Manifesto.

Launch of the book ‘Lean Software Development’ by Mary and Tom Poppendieck which demonstrated how the 7 processes in lean can be successfully adapted to create an Agile approach to software development.

Transition of the project management elements of DSDM into a project management qualification by the same examining body that manages the PRINCE2 qualification.

The interesting aspect of this timeline is why it has taken so long for Agile to impact on how projects are managed. It really is only in the last few years that aligning Agile and waterfall methods such as PRINCE2 has come to prominence. Although Agile methods and PRINCE2 were born around the same time (PRINCE2 was first launched in late 1996) the project management world has been dominated by the PRINCE2 waterfall method.

®

®

®

®

®

Kanban/Lean approaches at Toyota

identify ‘7 wastes’

‘Triumph of the Lean Production System’ by

John Krafcik’

DSDM first released

eXtreme programming

launched

Lean Software Development

published

Agile Project Management

launched

Agile Manifesto launched

SCRUM presented by Jeff Sutherland

at OOPSLA ‘95

Study by Takeuchi & Nonaka for Harvard

Business Review

Alistair Cockburn creates Crystal Methods - lightweight

development approach

DSDM became generic development and project management approach

1986 1988 1992 1994 1995 1999 2001 2003 2007 20101940s

4 Share this eBook:

Growing popularity of Agile Project ManagementWhy are we having conversations about Agile project management now? Obviously there are a variety of answers but these are my views:

There are always trends and the waterfall methods have been in active use but haven’t delivered all of the benefits we would have hoped for. Certainly there are concerns that blind allegiance to methods such as PRINCE2 can produce lots of documents about the project but this does not guarantee that what the project delivers is capable of realising the benefits outlined in the business case.

The level of uncertainty in the business environment has increased, leading to greater recognition that requirements evolve and that we cannot punish people for this but have to have a way of dealing with this. In an environment of fast paced change there is a need to deliver small changes that address a specific issue and that individuals can assimilate quickly rather than waiting for a comprehensive solution to the issue which takes so long to develop that the problem has become something different and the solution does not work.

Greater emphasis on the need for project to demonstrate return on investment is addressed through early availability of project deliverables that lead to early benefits realisation.

Empowerment of the project team fits with the cultural requirements of Generation Y and the Millennials. Their desire to work outside of a strict hierarchy and involve themselves directly with users is supported by Agile working.

The continued popularity of lean approaches, which align with Agile approaches, increases the popularity of Agile methods.

Software developers were not interested in taking their approach mainstream, and that they did not see themselves as part of the wider management or governance of their organisation so did not push for Agile to have a higher profile or become more widely adopted. However, as IT increasingly becomes core to the business, how IT projects are managed becomes core to how change is achieved.

®

5Share this eBook:

Context for the Agile Project Management Qualifications

Qualifications

Agile Project Management is about ensuring that the solution related to one specific idea is delivered so that it is fit for purpose and capable of realising benefits. In other words, Agile Project Management is a project management approach, it does not address programme management or portfolio management. This is because it does not address where the idea has come from or how important the idea is to the organisation as a whole i.e. Management of Portfolios (MoP ) nor is it about managing the idea in conjunction with other initiatives i.e. Managing Successful Programmes (MSP ).

®

®

In this video, Melanie Franklin explains how to blend Agile and PRINCE2 . This tutorial looks at roles and responsibilities, similarities and difference between the two approaches.

®

Risk Management

Portfolio Management

Programme Management

Project Management

Change Management

Benefits Management

Service Management

Delivery Management

ACCREDITED BY

®

6 Share this eBook:

Agile Project Management Foundation and Practitioner qualifications are an important step on the development path for project managers:- your team members want to work in an Agile way- need to incorporate Agile approaches into existing project management methods

The Agile Project Management qualification is managed by the same examining body that manages PRINCE2 , Managing Successful Programmes, Management of Portfolios etc and the examination style is similar.

There is a foundation level that is gained by passing a 60 question multiple choice paper, where the pass mark is 30 marks out of the available 60 marks.

There is a practitioner level, which is based on a scenario where you select how you believe Agile Project Management should be applied to the project scenario. There are four questions, each with several sub questions. These questions are objective test style which means they are a mixture of complex multiple choice, matching, ordering and assertion reason questions. To pass you have to gain 30 marks out of the available 60 marks.

®

7Share this eBook:

First of all, Agile is not necessarily Agile Project Management. Agile is a way of working and Agile Project Management is an approach that combines Agile software development and best practice project management.

This table is a very popular summary of the beliefs that underpin Agile working:

People and interactionsThose devising Agile methods often talk about the importance of putting a ‘humane’ front onto the software development process, or the technical work that they do. Certainly there is support for face to face communication and talking things through rather than writing things down to keep the momentum and avoid delays.

Working softwareWorking software refers to having ‘fit for purpose’ products as soon as possible in the development cycle so that users can experience it, work out how to use it and embed it in their working practices. Agile working has grown out of the software development industry and whilst it is now used for many other types of work including marketing campaigns and non IT product creation, there is still a lot of IT jargon used to describe how things should be done.

Working software could easily be replaced by a usable product or service and it would still mean the same thing. The emphasis remains on getting something usable in front of those that use it in preference to taking the time to document each step of the development process and create comprehensive user documentation.

Customer collaborationCustomer collaboration sets the expectation that Agile working is about partnership and not a combative relationship between those who do the work and those who are paying for the work. The impact of this collaboration is greater involvement by users in the project activities, working alongside the project team on a daily basis to shape and guide what the project delivers. This is best demonstrated in the organisation structure that underpins Agile Project Management where the project team is a balance of developer roles and customer or business roles.

Responding to changeResponding to change emphasises the need to evolve what is to be done, how it is to be done and the order of the work as new requirements emerge. The critical change from other approaches is that Agile working ensures you plan only as far as the next delivery to the customer, ensuring that those deliveries are as early in the project lifecycle as possible. Prototypes can be evaluated and changes to requirements identified during the project. These requirements can be incorporated rather than waiting for a single delivery of output at the end of the project, when changes to requirements become issues that need to be managed.

What is Agile?

People and interactions over Processes and toolsWorking software over Comprehensive documentation

Customer collaboration over Contract negotiationResponding to change over Following a plan

7Share this eBook:

What is Agile Project Management?

The philosophy of Agile Project Management is to ensure that project goals align with the business need and deliver early and real business benefits.

This means doing enough and no more to satisfy the user requirements, because a ‘fit for purpose’ product up and running is capable of realising business benefits, whilst deliverables still being developed by the project team, who are perfecting them by adding in as many features as possible are not realising benefits because they still have not been deployed.

For me this means that Agile Project Management drives two key themes:

Really understand the context, perspective and needs of the business community who will be using the project outputs

Get a move on and deliver outputs to them as quickly as possible because we are working in a fast moving world which rewards those first to market

Integrating waterfall and Agile approaches:Traditional project management is based on a ‘waterfall’ method - completion of one thing triggers completion of the next, just like passing the baton in a relay race (as described earlier in this paper).

Waterfall

Agile

Plan and analyse Design

BuildTest

CorrectionTest

Deploy

Analyse AnalysePlan Plan

Deploy Deploy

DesignBuildTest

DesignBuildTest

8 Share this eBook:

9Share this eBook:

PRINCE2 and the approaches defined in the bodies of knowledge for the Association for Project Management and the Project Management Institute are based on this waterfall approach. This means that projects need to be planned in detail at the start so that each of the phases or stages can be understood, and decisions can be taken about where the decision points on the project should be.

This works very well for projects where the outputs are very well understood and there is a lot of experience in how each step in the project lifecycle fits with the other steps. For example, if you are constructing a building, undertaking an office move or designing and managing an event a waterfall process will work very well.

This approach also works well when the project is part of a larger initiative, and the outputs required are fixed, as they are inputs to other projects within the programme. For example, if you are working on a project to create seating for an aircraft, the specification of your seats will need to be agreed in detail at the start of the project because their size, weight etc will have an impact on other projects involved in the design of the whole aircraft.

However, if your project involves the creation of deliverables that have not been designed before, and where the business environment into which they are to be implemented is subject to continuous change then it may be better to adopt an Agile approach.

There is some initial planning of the scope and high level deliverables for the project but the detailed deliverables and agreement on exactly which requirements will be met will evolve as users are presented with prototypes and early deliverables which they can experiment with, defining new requirements and changing their minds on what is needed based on their ‘live’ experience.

The diagram shows that an Agile approach leads to several ‘deployments’ and that the first deployment happens early in the project lifecycle, increasing the chance of achieving ‘quick wins’ that motivate the users and the project team.

Waterfall methods such as PRINCE2 and Agile methods are not mutually exclusive. They work well together because waterfall approaches encourage project managers to establish strong governance for their projects, whilst at the same time enabling team members to get on and create their deliverables. Instead of creating deliverables according to a pre-prepared work package, an Agile project team is empowered to create the deliverables within a pre-agreed timeframe, but prioritising the requirements as they go to ensure that they meet that timeframe.

®

®

9Share this eBook:

Impact of Agile on the role of the Project Manager

Business Sponsor

Business Advisor

Project LevelSolution Developm

ent TeamO

ther

Solution Developer

Team Leader

Solution Tester

DSDM Coach

Technical Coordinator

Project Manager

Business Analyst

Business Visionary

Business Ambassador

Workshop Facilitator

Technical Advisor

The organisation structure within Agile Project Management establishes 13 roles that represent those with specialist knowledge of the products being created by the project and those with business knowledge. Agile Project Management is much more explicit in establishing roles for those within the business and states how they must collaborate with those with specialist knowledge if the project is to be successful.

10 Share this eBook:

11Share this eBook:

Impact of Agile on the role of the Project Manager

PRINCE2 , MSP and MoP are registered trade marks of the Cabinet Office.® ® ®

Whilst the role of Project Manager and Team Leader exist as they do in PRINCE2 , the emphasis on the responsibilities is very different and this can cause some adjustment for those project managers coming to Agile from a waterfall background.

The project team is empowered to plan their work in detail and to address issues as they arise with whoever is best placed to solve them. This means that not all communication comes through the Project Manager. Therefore, I find the biggest challenge is how I have to change how I work to meet the needs of a self directed project team. I am not formally managing the project team, but I must be on hand to guide them and to help remove any obstacles that will impede their progress. At the same time, I need to be fully aware of the progress that the project team is making so that I can relay this to the stakeholders and ensure they have enough information to assure themselves that the project is on track and will deliver what they need.

For project managers used to planning every aspect of their project and conveying this information to team members via detailed work packages, this lack of control over the day to day work can appear threatening. This is why trust and honesty between the team and the Project Manager is vital, as is knowing when to stand back and let the team get on with their work.

Another challenge is removal of hierarchical ‘chains of command’. In Agile, team members are encouraged to solve problems for themselves, which includes consulting with and asking the advice of anyone that they think might be able to help them. Therefore, situations can arise when team members might approach senior managers directly for assistance, when the Project Manager does not even know there is a problem. The advantages of this expediency have to be balanced with the need to appear coordinated and controlled especially in front of critical stakeholders and decision makers.

A challenge for the organisation (and not just the Project Manager) is finding sufficient business resources that can be released to work on the project. Often the most gifted resources already have a full schedule of business as usual responsibilities and are contributing to other projects taking place in their department.

I think the emphasis that Agile Project Management places on filling the roles of Business Sponsor, Business Visionary, Business Ambassador and Business Specialist is very important in making the point that projects and the changes they deliver cannot be done in isolation from those expected to use what is being created. The closer the collaboration between business and specialist resources, the faster the delivery times and the greater the chance of products that realise business benefits.

®

Maven Company Overview

Maven provides business transformation solutions to our clients in a project management environment. Maven can help your organisation in these areas:

Change Management - help you understand why change is required, implement the change necessary to advance and realise the benefits in doing so

Leadership development – identify the people within your organisation who can drive change forward

We deliver our interventions through supporting your organisation and working with you to recognise and build on the ultimate vision for the future. Our aim is to always help organisations through change, not to do change to you.

Tools and techniquesMaven employs the use of various tools and techniques to help you achieve your goals, some examples of which include:

Change Management Framework - designed to help you apply a methodical and structured approach to your change programme

Leadership blueprint - designed to assist individuals to identify their own personal leadership style and competencies, and structure their long term approach to leadership

Competency Capability Assessments - this tool helps your staff to assess their current skills levels, identify skills gap and focus on areas of improvements

All Maven services are delivered in line with our quality management system and processes.

12 Share this eBook:

13Share this eBook:www.maventraining.co.uk

For further information about Maven Training please contact:

Telephone: 020 7403 7100e-mail: info@maventraining.co.uk

www.maventraining.co.uk

Follow us on:

Twitter

Facebook

LinkedIn

Slideshare

YouTube

Scribd