The scrum master role is important because the person helps the team work according to the principles of scrum and to constantly improve their working methods. The scrum master organises the scrum events, such as sprint planning, sprint review and retrospective. The scrum master may be able to do their work on the side while using much of their time contributing to the team deliverables. Regardless if you choose scrum or not, someone needs to help the team to improve their process.

Warning signs:

• The team has trouble understanding and following the agile framework.
• The team gets assignments under the table and from multiple sources. Team members are unable to concentrate on sprint work agreed with the product owner.
• Team members are dissatisfied with their deliverables.

Each team members feel allowed to voice their viewpoint on requirements, stories, work estimates and working methods. For the scrum master, this is quite easy to measure. There shouldn't be anybody who's opinion is more important then other's, so make sure everybody is able to bring their experience to the table equally.

Warning signs:

• Some team members always remain quiet during scrum events.
• A team member voices their opinions but consistently lose the argument.
• One or more team members act like the prima ballerina and overrule everybody else's opinions.

The difference here is between influence and power. The team needs to be empowered to make the decisions on how to organise their own work. In practice, many professional scrum masters and product owners have a strong influence on the team’s working methods, but the goal must be to no longer need that influence. The best impact you get from individuals who work together as a self-sufficient, empowered team. Since the team and its members want to look good, they will do an even better job when you don’t manage them. Most professionals can manage themselves, but they do need leadership.

Warning signs:

• Improvements in working methods are always initiated by the scrum master or the product owner and never by individual team members.
• Team could never go through a scrum event if the scrum master is absent.

If the users already have a process you are providing tools for, the interviews are crucial. By involving team members you can provide them with first hand knowledge and a good understanding of user needs. Daily interaction with business people and users allows the team to make corrections early. Finally, getting feedback after the story is done provides both metrics and guidance which can result in increased customer happiness.

Warning signs:

• Many stories end up back on the following sprints.
• There is no sprint review, where the deliverables are presented to stakeholders.
• There is no feedback for each delivered story.
• Quality of deliverables does not improve.

Maintain a product backlog in value order and forget about priority levels such as "must have" and "nice to have". Team members will eventually get confused about what to work on next. When you know your customer's pain, a professional team can create loads of value. They can either change the colors and layouts of the buttons, or they can add a feature which saves the user 10 minutes per day. Which one would be easier to sell?

Warning signs:

• Stakeholders give no feedback or consistently negative feedback during the sprint review.
• It is not clear for the team members what to work on next.
• Sales is not increasing.

The team needs to improve its working methods consistently. By having a routine where the retrospective follows each and every sprint, the team can take small steps towards an incrementally better process, which suits their individuality and their organisational environment. However, it is extremely important to start with the schoolbook scrum, which has been developed by a group of experienced software professionals. After seeing which parts need adjusting, you can take baby steps towards the team's preferences. This is possible only after the team understands the basic mechanisms of scrum on a deeper level.

Warning signs:

• Same problems repeat sprint after sprint.
• Quality of deliverables does not improve.
• The team has impediments which are not solved.

In software, automation is beyond everybody's reach. By using automated tools for testing and deploying software takes some effort but pays itself back by freeing up resources for development of new functionality. Cloud deployments are easy to automate and CI pipelines can run your existing tests. Software design should include steps which improve the testability of more complex sections of code. The team should aim for high quality in everything they do.

Warning signs:

• New bugs appear contantly and are only noticed after delivery.
• Previously working functionality breaks.

Getting the whole organisation to work in the agile way is extremely rare. You can start with a few teams and empower them to make their own decisions. Make sure the product owner understands the strategic goals of your company and is 100% dedicated to writing stories and explaining them to the team. Select the smartest, and verbally talented, communicative people for the first agile teams. Give them space to work without other outside influence than the product owner. I call this the "agile bubble" or the "internal startup" and it's something you can try in any type of organisation. When the teams get experience, have them share their experience the rest of the organisation.

Warning signs:

• The whole organisation knows the word "agile" but doesn't seem to know what to do next.

This is one of the key differences between scrum and waterfall project management. You can still agree with the team on different lengths for sprints, as long as you stick to it during the sprint. When the team always sticks to the planned schedule, there will be some stories done at the end of the sprint, and they are releasable at the planned time. If some stories are not finished, the product owner can always decide to continue them in the following sprint.

Warning signs:

• Sprint schedule changes during sprint. This always indicates a problem with commitment or with the release process stability.

Aim for the lean way of working, which is what agile was originally built on. You need to know who you are delivering to and why do they need your deliverable, i.e. what do they use it for. Only then you can produce it to their needs. Otherwise, you risk wasting your valuable resources.

Warning signs:

• There is no feedback for each and every document written by the team. Iterative improvements have not been made in most of the documents.

By showing interest towards the solution and not the schedule, you bring out the creativity in people without creating stress. This cultivates a solution-oriented mindset within the team. Let’s say your customer asks you: ”If you need to choose, would you prefer to 1) make us happy or 2) deliver on time.” Which would you choose? You may feel that schedule is the highest virtue in this world, but think about which approach will help your business survive and grow.

Warning signs:

• Team members feel schedule pressure from outside the team. This has a negative influence on team morale, quality and efficiency.
• Work estimates are not available.
• There is no visibility to a preliminary scope of the next sprint.