Successful Business Sponsorship of Agile IT projects.

Chris Mundy Managing Director, Clearcast

https://uk.linkedin.com/in/mundychris

ChrisMundyLdn

Too many IT projects end in Failure. As Business Sponsor of an Agile project you need to ensure this doesn’t happen to you. These slides contain questions to help you keep on track.

What is Agile development?

• An alternative to traditional project management intended to help teams respond to unpredictability through incremental, iterative work periods, known as sprints (eg 2 weeks).

• Agile methodologies are an alternative to waterfall, or traditional sequential development.

• A project is broken down into “Epics” which are large chunks of work and further down into “User Stories” which are short descriptions of functionality that is required.

• How the User Stories for a sprint will be delivered are worked through at the start of each sprint

Characteristics of Agile

1. Active user involvement 2. Team empowered to make decisions 3. Requirements evolve but the timescale is fixed 4. Requirements captured at high level; lightweight & visual 5. Develop small, incremental releases and iterate 6. Focus on frequent delivery of products 7. Complete each feature before moving on to the next 8. Apply the 80/20 rule 9. Testing is integrated throughout the project lifecycle – test

early and often 10. Collaborative & cooperative approach between all

stakeholders is essential Source: http://www.allaboutagile.com/what-is-agile-10-key-principles/#sthash.9KyO8gG9.dpuf

Five business risks of Agile

Risk Consequences

Unclear user needs Wasted effort: building code, tearing it down and rebuilding it. Extra costs. Inefficient planning

Focusing on the immediate detail, losing sight of the big picture

Project derails / runs out of road

Scope creep Project goes over budget, is delivered late or cancelled

The project comes under pressure as a result of the above and collaboration between buyer and vendor strains

Impossible to work in an agile fashion without collaboration. Inadequate product is delivered.

Questions the Business Sponsor Should Ask.

“Why are we doing this Agile?”

• Agile may be the best approach for your project, or it may increase the risks of successful delivery.

• Agile is great for projects : • That can be delivered in stages, maybe generating early

revenues • Where you want to get something up quickly then improve on

it • Where you want to encourage users to help shape it • Flexibility is important

• Be confident you won’t risk overruns or extra costs going down the agile route

“How detailed and/or definitive is our spec? Is the supplier as clear as us?”

• Have both the Business and Technology signed off the spec.? • Don’t rely on one to be expert on the other’s area.

• Realistic pricing will depend on good understanding. • What is clear and specific to you may not be to your supplier

• If areas of a technical spec are open to interpretation then they aren’t specific. This may be fine, as long as you both have same understanding

• Supplier may feel (and have contracted) on the basis that a simpler solution than you expect will suffice.

• Test: where would you stand legally in event of disagreement?

• Also… if the specification is very definitive then agile may not be the best approach.

• Better suited where there is the opportunity to co-invent the best solution

“Does the supplier have a deep understanding of our needs?”

• Demonstrated by workflow diagrams, wireframes, proof of concepts.

• Worth investing in proving before full commitment

• Good project planning at the outset will avoid the need to rework later.

• Agile means flexibility to iterate but nothing (e.g. database structure) should be locked down without planning complete

• Do everything possible to surface any mismatch between supplier expectations and yours up front

“Are our internal roles sufficiently clear? Who has sign-off for what?”

• There will usually be at least a Business Lead, a Technical lead and a Project Manager.

• Is there clarity of roles? • Who is ultimately responsible for ensuring the system meets business

needs? • Who chairs user group meetings? • Is there a clear, documented, internal sign-off process for all decisions

• Any uncertainty in roles and responsibilities adds risk

“Are we on track? How do we know”

• This is a hard one for agile because it’s not delivered using a fixed road map.

• Especially important for fixed cost projects.

• Are all the Epics* mapped out at a high level? Has resource allocation been allocated to each one.

• Is progress being mapped against the original plan?

• Are realistic revisions being made as the project progresses to ensure it still delivers?

Epic 1 20%

Epic 2 15%

Epic 3 10%

Epic 4 10%

Epic 5 20%

Epic 6 25%

Project

*Epics are larger items of feature-level work that encompass many user stories. For example, an epic might include all aspects of a user being able to manage their account.

% is of total project development resource

“What is the process for signing off user stories and acceptance criteria?”

• User stories* are the building blocks of the system.

• Each user story should have acceptance criteria so everyone knows what is expected. These should be signed off before work on that user story begins

• If what is delivered is not as expected, either the acceptance criteria were inadequate, or they were not delivered.

• To minimise the chance of tearing down and rebuilding, capture all stories in an Epic with acceptance criteria, before dev starts on that Epic.

*An user story is a very high-level definition of a single requirement, eg “as a user I need to see a spinner while waiting for the screen to refresh”

Epic

Story 1

Story 2

Story 3

Story 4

“Are project management tools being used effectively?”

• Every agile project will utilise a project management tool, eg JIRA or Pivotal Tracker

• In a good working relationship, the client will have access to the tracking tool

• Helps the client prioritise, check acceptance criteria, understand where problems may have arisen and monitor progress

• Ideally “points” [reflecting development burden] will have been allocated to each Epic so you can track how accurately the work involved was forecast and if you may over-run.

• If user stories are not grouped by Epic, consider carefully how you can track delivery of the Epic, or be sure that stories being developed will lead to its successful delivery.

• Access to the tracking tool also gives an insight into how comprehensively and/or far out the project has been planned

“Are we following the process for variation laid out in the contract?”

• With agile development it’s more likely that something will be delivered by mutual agreement that departs from what was originally envisaged, or mandated, in the contract

• i.e. you may agree to depart significantly from the contractual specification in certain areas.

• Make sure that change management processes outlined in the contract are followed. If the contract isn’t written yet then think very carefully how change can best be managed contractually

• At the very least, every significant variation should be documented and mutually agreed in writing.

• Avoids each party blaming the other if things go wrong.

“How are we protected if the relationship sours”

• Agile is probably more at risk than waterfall of experiencing project difficulties as the project will be less defined up front

• There may be scope creep or other pressures on the relationship

• Does your contract mandate a way of working? Can one party try and unilaterally change this?

• Agile is unlikely to deliver a successful outcome if both parties are not fully engaged throughout the project. The client doesn’t need to be embedded in the team, but does need to sign off user stories and acceptance criteria up front, not just functionality as it is delivered.

• If you are still drafting the contract, think about how you want to work up front and provide a mechanism for changing that by mutual agreement should it be necessary

Don’t lose sight of the end game.

Review

Iterate

Plan

Reprioritise