Scrum is like life: surface appearances can be deceiving…
A few days ago, I took my car for its routine annual inspection. I was confident everything was working perfectly – it started fine, there were no strange noises, no problems while driving, you get the picture, it all seemed fine. However, the inspection told a different story: small but important faults that, if left unattended, would lead to big problems: a breakdown or, even worse, an accident.
It’s human nature to focus on what’s wrong, and not to worry too much about the things that appear to be working well (that’s how car mechanics make their money!) But overriding that human nature and looking beneath the surface can enable us to nip problems in the bud and prevent a disaster later.
It’s the same with working with Scrum. There are so many tiny but important details that it’s easy for something to be quietly going wrong ‘under the hood’ and it only shows up later as a big (possibly expensive) problem.
So, in the spirit of the annual vehicle inspection, we recommend you audit how Scrum is working for you. There’s always room for improvement and the following is our ‘mechanic’s checklist’.
Inspect and adapt
The main philosophy of Agile is “inspect and adapt”, so we decided to review Scrum at XSolve using the checklist in Jacek Wieczorek’s book Labirynty Scruma [Eng. “Scrum Labyrinths”]. The book is not your typical reading concerning Scrum theory. It contains a description of various situations occurring in the daily project life of Scrum teams. The subjects covered refer to all Scrum roles, artifacts, and meetings. Each chapter includes information about the most common mistakes and traps in a given domain. The consequences of wrong behaviors and possible solutions are also outlined. The book does not provide universal solutions because these do not exist in such a complex product development environment. What it does do is tell you exactly where to find any problems.
We audited everyone, including the development teams and the Scrum Masters. Some of the questions were quite simple and didn’t need much thought, others evoked a lot of discussion and reflection among the team members. You can check out the full list of Scrum Audit Questions here.
After the audit, each team concentrated on analyzing the negative aspects, their causes, and their possible solutions.
Below you will find the five most common problems thrown up by our audit, and our suggested solutions.
Common problem: too little help for new clients and employers when it comes to understanding Scrum.
In my opinion, this is the most important Scrum role. A good Scrum Master can lead even a fresh team in the right direction and bring out the best business performance from the Product Owner.
The Scrum Guide highlights some of Scrum Master’s responsibilities:
• Helping employees and stakeholders understand and enact Scrum and empirical product development,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
The fulfillment of these points is crucial for the agile functioning of a company and influencing people’s mindset.
• Onboarding for new employees should provide an extended Scrum workshop and share in more detail our in-house Scrum experience, as well as sample solutions (e.g. Scrum case studies from previous commercial projects).
• Begin evangelizing Scrum to the client at the prospect stage, demonstrating the benefits of Agile with case studies and everyday work examples.
• Remember the client’s learning process is a continuous one: keep identifying weak points and then resolve them together.
Common problem: Product Owner doesn’t present the vision and business value to the development team.
Product Owner is highly influential role and the PO should express his or her vision clearly to the whole development team. The PO’s decisions should be based on a knowledge of the market, user feedback, and the development team’s input. If the team doesn’t understand the business value of the project, they cannot draw on their experience from previous projects; they can only keep working as in the past on tasks whose goal is unclear. If the team members know both the “what” and the “why” of the project, they feel more motivated and responsible for the product and they’re likely to come up with more efficient solutions.
• Making the client aware of how the lack of a clear vision and business value affects the team’s performance.
• Planning clear releases based on user needs and metrics.
• Monitoring the work in progress, being open to making changes and refinements.
Common problem: not using the many useful available metrics, resulting in guiding the team only by intuition.
Development and business metrics are there to be used. Important project decisions be grounded in solid data lead to better-planned sprints and product versions. At XSolve, we use Jira in our everyday work, which provides an ample set of ready metrics. Apart from standard reports, such as Burndown Chart, Velocity Chart, or Version Report, we recommend both the Time Tracking Report, which allows the team to verify the accuracy of their estimates and to improve their future planning, and the Average Age Report, which shows if the backlog is appropriately updated.
• Deciding, together with the team and the client, which metrics are the most necessary.
• Planning the addition of one metric per month, adding it to sprint/release reports.
• Showing product metrics and their impact on the business value.
Reviews conducted without Stakeholders or Observers
Common problem: only the Product Owner, Scrum Master and Development Team take part in the review meetings
Failing to include stakeholders during review meetings can result in several problems, such as lack of knowledge of product development, and delayed fulfilment of the business goals. If the Product Owner who works daily with the Development Team doesn’t pass on information to all stakeholders, the likely results is a product which does not fulfil the needs of end users and product investors. This is equally important for the development team as the inclusion of stakeholders allows them to gather feedback and verify if the product is going in the right direction. Additionally, opening up your review meetings to other development teams (not normally involved in the product) allows for new, fresh perspectives and can often help to resolve problems that occur during the development of a complex web product.
• Invite stakeholders to reviews, in person or via the Product Owner (make sure that the date and time are suitable for everyone).
• Let everyone know the value of taking part in a review meeting – explain the benefits to both the stakeholders and the development team.
• Introduce “open door” reviews and invite other teams to join in and find out more about the increments.
Of course, I haven’t described every tiny problem that our Scrum audit uncovered, only the most important five. But everything that arose during the ‘inspection’ process was of value, often prompting interesting debates and discussions with fresh perspectives being explored.
But ultimately, the real practical benefit of any audit process lies in what you do with the information it provides. I can say that after introducing the changes and solutions listed above, we immediately began to see positive results, enhancements to our Scrum projects and results. I really can’t recommend enough that you run an audit like this in your company.
Courtesy of Jacek Wieczorek, we’re publishing the complete list of questions we felt were worth asking during the audit. Take a close look at your Scrum teams and respond honestly to the questions listed below. The process can difficult and uncomfortable, sometimes even a little unpleasant, but it will surely help your organization to develop and improve the way you work and the quality of your project outputs.