Agile Project Management

Share this eBook:

Overview
In 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 players

www.agilealliance.org Agile 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.org Scrum 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.org Dynamic Systems Development Method (DSDM) is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

Origins
The 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.

Share this eBook:

Alistair Cockburn creates Crystal Methods - lightweight development approach

DSDM became generic development and project management approach

Study by Takeuchi & Nonaka for Harvard Business Review

SCRUM presented by Jeff Sutherland at OOPSLA 95

Agile Manifesto launched

1940s

1986

1988

1992

1994

1995

1999

2001

2003

2007

2010

Triumph of the Lean Production System by John Krafcik Kanban/Lean approaches at Toyota identify 7 wastes

eXtreme programming launched

Agile Project Management launched

DSDM first released

Lean Software Development published

Other points of interest in the history of Agile include: of the term lean in the paper that John Krafcik wrote for his PhD identifying the Introduction 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. of the eXtreme Programming approach by Kent Beck, Ward Cunningham and Ron Creation Jefferies in 1999, advocating frequent releases in short development cycles, to improve
2001 there was a meeting of all the key players in agile, leading to the formation of the In Agile Alliance and the creation of the Agile Manifesto. of the book Lean Software Development by Mary and Tom Poppendieck which Launch demonstrated how the 7 processes in lean can be successfully adapted to create an Agile approach to software development. of the project management elements of DSDM into a project management Transition qualification by the same examining body that manages the PRINCE2 qualification.

productivity and introduce checkpoints where new customer requirements can be adopted.

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.

Share this eBook:

Growing popularity of Agile Project Management

Why are we having conversations about Agile project management now? Obviously there are a variety of answers but these are my views: are always trends and the waterfall methods have been in active use but havent There 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.

level of uncertainty in the business environment has increased, leading to greater The 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.

emphasis on the need for project to demonstrate return on investment is addressed Greater through early availability of project deliverables that lead to early benefits realisation. of the project team fits with the cultural requirements of Generation Y and the Empowerment Millennials. Their desire to work outside of a strict hierarchy and involve themselves directly with users is supported by Agile working. continued popularity of lean approaches, which align with Agile approaches, increases The the popularity of Agile methods. developers were not interested in taking their approach mainstream, and that they Software 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.

Share this eBook:

Qualifications
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.

Context for the Agile Project Management Qualifications

Risk Management Change Management Benefits Management Service Management Delivery Management

ACCREDITED BY

Portfolio Management

Programme Management

Project Management

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).

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. is a foundation level that is gained by passing a 60 question multiple choice paper, There where the pass mark is 30 marks out of the available 60 marks. is a practitioner level, which is based on a scenario where you select how you believe There 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.

Share this eBook:

What is Agile?
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 interactions Working software Customer collaboration Responding to change over over over over Processes and tools Comprehensive documentation Contract negotiation Following a plan

People and interactions

Those 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 software
Working 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 collaboration
Customer 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 change
Responding 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.

Share 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: understand the context, perspective and needs of the business community who will be Really using the project outputs a move on and deliver outputs to them as quickly as possible because we are working in Get 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 Plan and analyse

Design

Build

Test

Correction Test Deploy

Agile Analyse Plan Design Build Test Deploy Analyse Plan Design Build Test Deploy

Share 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.

Share this eBook:

Impact of Agile on the role of the Project Manager

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.

Business Sponsor Project Level

Business Visionary

Project Manager

Technical Coordinator

Technical Advisor

Business Analyst

Business Advisor Solution Development Team

Business Ambassador

Team Leader

Solution Developer

Solution Tester Other Workshop Facilitator DSDM Coach

10

Share this eBook:

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.

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

Share this eBook:

11

Maven Company Overview

Maven provides business transformation solutions to our clients in a project management environment. Maven can help your organisation in these areas: Management - help you understand why change is required, implement the change Change necessary to advance and realise the benefits in doing so development identify the people within your organisation who can drive Leadership 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 techniques

Maven employs the use of various tools and techniques to help you achieve your goals, some examples of which include: Management Framework - designed to help you apply a methodical and structured Change approach to your change programme blueprint - designed to assist individuals to identify their own personal leadership Leadership style and competencies, and structure their long term approach to leadership Capability Assessments - this tool helps your staff to assess their current skills Competency 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:

For further information about Maven Training please contact: Telephone: 020 7403 7100 e-mail: info@maventraining.co.uk www.maventraining.co.uk

Follow us on: Twitter Facebook LinkedIn Slideshare YouTube Scribd

Share this eBook: www.maventraining.co.uk

13