Many people have the idea that moving to agile methodologies from traditional waterfall will bring chaos where decisions change by the minute and no one knows what is going on.  Infact, it’s quite the opposite – if done correctly.

We have more useful governance using Agile approaches than we had wasteful using Waterfall.

Based on our experience, successful adoption of Agile can be achieved and here are things to consider.

Prep The People

The first success factor of adopting Agile is getting your team onboard.  If your people aren’t prepared to put their doubts to one side then you will be doomed to fail.  Making the mindset change can be very difficult for experienced professionals, but it can be done.

Give all of your team the right training from day one.  Make sure they understand :

• The responsibilities and expectations of every role within the team including Product Owner, Scrum Master, Engineering team members and understand who the stakeholders are.
• Have everyone speaking the same language.  Make sure terminology is clearly defined and understood.
• Be clear about the agile ceremonies including sprint planning, retrospectives, stand ups, show and tells, estimation exercises etc.  Ensure everyone knows the part they play in the ceremonies.
• Add a backlog item to each sprint for ‘Team Training’ so time is allocated to give the team the chance to develop new skills as they go depending on the learnings from each sprint.

What’s Your Problem?

Have a clear business outcome to solve and break it down into specific achievable problem statements.

Break down the Problem Statement so you have a good idea of how you will solve the problem – this will help define and develop your backlog epics and user stories.

An Epic is a large block of work that has a common objective.  It could be a feature, request or requirement.

If there are more than 5 user stories for the same project area then you should have an Epic defined and link the user stories to the Epic.

A User Story is a short and simple description of a feature told from the perspective of the person who desires the new feature…

As a <type of user>, I want <a goal> so that <a reason>.

User Stories can be sized and estimated.  A Story Point value should be assigned to each user story based on it’s complexity and size, so the team can gauge what work will fit within a sprint. For example, a team might be able to clear 50 story points per sprint and if you know the story points allocated to each user story the team will be able to effectively plan the content for that sprint.

Work with your stakeholders to develop your team ‘Definition of Done’ and know what your success factors are.

A Definition of Done is a shared understanding of what it means for work to be complete and can cover either the release, a product increment or a user story.

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.  (Scrum Guide)

Keep your Definition of Done on your scrum board so everyone has a visible reminder of what you are trying to do.  Also, be prepared for the Definition of Done to evolve throughout the life of your project.  Review this as part of the sprint retrospective ceremony.

Your product backlog items will be “Ready” to be included in sprint planning.  The Definition of Ready is linked to having  good user stories that are actionable and understanding what it means for them to be “Done”.  Sometimes it’s not possible to have all of the information up front for user stories to be deemed as “Ready”, but it will give you a good chance to have a successful sprint.

Think About Your Framework

Once you’ve decided to adopt Agile, it doesn’t stop there.  The next question should be what type of Agile framework should you use for the best fit for what you are trying to deliver.

Kanban, Scrum, SAFe, Nexus, Pragmatic Agile are all good options, but don’t all fit with every scenario.  Pick the best framework for your team and project.

Scrum is very good if you have an end vision to achieve and know what you will be committing to at the end of a sprint.  It recognises that things change and product requirements, technology and risk can be volatile based on what the team learns throughout the project.  Scrum allows the teams to respond to change and be self organised without losing focus on the outcome.

SAFe, Nexus or other scalable frameworks support large delivery of enterprise size software and systems.  It allows for the collaboration, alignment and synchronisation of multiple agile teams.  It views deliveries from different layers including portfolio, programme and individual teams.  It takes advantage of continuous delivery pipelines or an Agile release train.

Kanban allows you to tackle fluid requests and a continuous flow of work.  Understanding the availability capacity of work within the teams is key so as not to overload the team so they become unproductive.  Balancing demand and capacity by setting work in progress limits is the key to making Kanban effective.  Keeping the workflow moving and avoiding bottlenecks is also one of the main focuses within Kanban.

Almost all agile frameworks are well complimented with dev ops, automation and tooling as well as bringing built in quality throughout the project by having multi skilled scrum teams doing pair programming, test driving development and automated testing.

Tooling and Metrics

There is a world of Agile tooling available to teams today and identifying the best one for your delivery should be a priority for any Agile team.

Often the tooling is dependent on the framework that you choose e.g. Kanban frameworks are well suited to using ‘To Do list’ type tooling like Trello or Teams Boards.

More scrum focused deliveries are a good fit for VSTS and Jira where you can take advantage of the metrics around story points, burn down and velocity.

There are some good retrospective tools freely available including Retrium, goReflect etc. which help to document what was learned in the sprint.

Comparing Agile metrics with Waterfall metrics on time, quality, productivity are often one of the best ways to prove to management that moving to Agile has delivered improvements.  However, metrics alone shouldn’t be used by management to come to conclusions on the effectiveness and success of the team.  Metrics need to have context!

The most common metrics used in Agile are …

• Velocity – this is the amount of story points that were moved to Done during the sprint.  Velocity usually improves as teams progress through sprints and as it matures can help with estimating the amount of work (story points) that can be delivered by a team.
• Burndown – shows how quickly the team are burning through the user stories.  It shows the total effort against the amount of work delivered.
• Recidivism – is the ratio of user stories that come back to development.  This might be due to quality failure or changing requirements.
• First-time Pass Rate – is the % of test cases that pass the first time they are run.  Using test automation should help with regression testing of old features to make sure they have not broke with the latest changes.
• Defect Count By Sprint – is the number of defects identified during the sprint.
• Defect Count by Story Points – This is less binary than the defects by sprint count as it looks at the ratio of defects to story points in a sprint.  With sprints that don’t have many story points just counting defects would not give a true reflection on the quality of the delivery.
• Story Completion Ratio – This is the number of stories completed in a sprint compared the number of stories that were planned.
• Story Count Completion Ratio – Looks at what story points were delivered compared to the estimate.
• Blocked Items Count and % – These can be used to understand the number of stories that are blocked and the %.

A Good Product Owner

The Product Owner is the most important role to ensure a successful delivery – FACT.

 The Product Owner is responsible for maximising the value of the product resulting from the work of the scrum team – Scrum Guide 

The most basic definition of a Product Owner is “someone who knows stuff and is empowered to make a decision”.

The Product Owner should fully understand the business and the problem the team are working to fix.   This allows them to make good decisions for the benefit of the project.   They are the link between the client and the scrum team.  They understand the priorities and are involved and available to the team to support, plan, clarify and decide.  A good product owner is involved in sprint planning, reviews and retrospectives.  They can where possible be part of the stand ups too.

Don’t underestimate the value of a good Product Owner.  They can be the critical success factor of an Agile delivery.  If you don’t have a Product Owner who is knowledgeable, empowered and willing and able to spend quality time with the team, the risk of not achieving a successful delivery is increased.

If you haven’t got a good Product Owner – Get One !

Stand Up and Don’t Stand Still

It’s a fact that you spend a lot of time on your feet with Agile.

It isn’t just the daily stand ups that get you up and about, you need to get out of your seat and talk to people.  Collaboration and transparency need to be active in Agile teams.  If you have a blame free culture where your team are not afraid to fail, but take it as a learning opportunity then collaboration and transparency will become part of the team’s DNA.  Don’t stew over a problem on your own, share it with your team and you can collectively overcome the problem.  The sooner you share, the sooner it’s fixed.

Don’t forget to share with the stakeholders too.  There’s nothing worse than waiting until the end of the sprint to let them know that things aren’t going well.  Bring them into the problem – they would rather help fix it than not meet their goal.

Use the sprint retrospective process to reflect on what went well, what didn’t go so well and what you can improve going forward.  The retrospective is an opportunity to discuss  things without blame, criticism or accusation.  These are and should be very positive.  Take it as a team building opportunity.  Think wider than just the sprint.  What improvements can be introduced to the way of working, comms, tooling, collaboration, mentoring, training…  It is a time for the team to collectively improve.

Take The Plunge

Don’t be scared to move to Agile.  Things won’t be perfect, but you have the power to continuously fix things and make them better.   Agile gives you the power to be flexible, but still have a solid framework to support and govern a delivery.  Once you are working in an effective Agile way, it just seems like common sense and you’ll ask yourself why you didn’t take the plunge sooner.