Simon Kneafsey

At a recent Scrum.org Professional Scrum Master II class, I asked the group to write down some learnings from the class that may help other Scrum Masters. One statement that came up has stuck in my mind ever since: “Don’t be a comfortable Scrum Master.” – Unknown Scrum.org Professional Scrum Master II Attendee.

TheScrumMaster.co.uk has created The Simple Guide To Scrum – 1 Pager. A condensed and visual representation of Scrum on 1 page.

Scrum is hard. To be more specific, learning Scrum is easy, using Scrum to develop complex products is hard.

Here are some simple examples of Product Goals, Sprint Goals and the relationship between them.

One of the most common questions I receive via the Contact Us page on TheScrumMaster.co.uk is – How can I get my first job as a Scrum Master?

At a recent class, a new Scrum Master asked me for a simple example of a Definition of Done. This post captures my answer to them and I hope it will help simplify this concept for you.

According to the Scrum Guide, the purpose of the Daily Scrum “is to inspect progress toward the Sprint Goal” and “adapt the Sprint Backlog as necessary” and “it is held at the same time and place every working day of the Sprint.” So what is the best time to hold the event each day?

At a recent course, one of my students asked me to share what Scrum “looked like” for me at TheScrumMaster.co.uk. This post is my response to that question. This describes my current process which has evolved via inspection and adaptation over 5 years.

At a recent course, one of my attendees talked about his use of a "to delete" status for items in his Product Backlog. Where items had been in his Product Backlog for more than 3 months he tagged them as "to delete". He would then review this sub list with stakeholders as part of the ongoing Product Backlog Refinement process. After some discussion the items were either deleted/archived or the tag was removed. With new Product Backlog Items (PBI's) being added all the time, he wanted to encourage his stakeholders to remove PBI's if they had been around for awhile but had never been deemed valuable enough to work on. It was likely these would never be implemented as there would always be something more important to do. This reminded me of an important point - Good Product Owners Deleted Product Backlog Items. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:....Ensuring that the Product Backlog is visible, transparent, and clear to all - The Scrum Guide In many organisations, the rate of new Product Backlog Items being generated far exceeds the Development Team's capacity to convert them into increments of working software. As a Product Backlog grows over time, so does the time required to refine it. Much time can be spent discussing this huge number of PBI's. Time is money, and as many of these PBI's will never be implemented this introduces significant waste into the Product development process. As part of Product Backlog Refinement, good Product Owners will proactively aim to keep the Product Backlog as small (in terms of numbers of features) as is possible to reduce this waste. Even if not deleted, items should be archived to remove them from the Product Backlog. This will help eliminate waste and allow more time to be spent focussing on the features that will be implemented. Focus is a Scrum value and this technique is one way Product Owners can bring greater focus to the Product Backlog.

Over the past 10 years I have worked with many organisations and helped them to use Scrum to create innovative and sometimes market leading Products. I have seen a lot of Scrum during this time, much of it done well, but some of it done badly. Here are the 5 common anti patterns that I see with teams learning to use Scrum and improve what they do. If your team is exhibiting these characteristics beware! Take action or you may soon be visited by the "fail whale". Not Producing A "Done" Increment By The End Of A Sprint A key part of Scrum is developing the discipline to create a truly "done" increment by the end of each Sprint. By "done" we mean some potentially releasable software with valuable new features for your users or customers. Many teams introduce Scrum, but retain their waterfall mindset and defer important activities, such as testing for later Sprints. The result is that quality suffers immediately, undone work accumulates and we queue up mounting problems for later. Eventually the Product becomes full of partially complete features, all of which need to be revisited and fixed and completed at a later time. Transparency suffers and you fail to build trust with your stakeholders and predictability for your project. The likely outcome is that you will miss any deadline that has been set and there will be a death march to fix a mountain of issues before your first release. Lack of Product Backlog Refinement Many teams I have worked with initially struggled to successfully complete Sprint Planning. They would plan the work for the current Sprint but then be unable to complete it by the end of the time box for the Sprint. There are many reasons this can occur, but the most common (and easily resolved) is a lack of definition in their Product Backlog. Product Backlog items were not clearly defined (or "ready") coming into the Sprint, with the result that the Development Team did not know enough about them to be able to effectively plan how to deliver them and how much time would be required to do so. The answer to this is to spend additional time on Product Backlog Refinement to add enough detail to upcoming high priority Product Backlog Items. Although the Product Owner is responsible for the Product Backlog, this should be an activity for the whole Scrum team in every Sprint. The entire Scrum Team must collaborate to solve this issue which will often be vital to allow further progress to be made. Scrum Master As The Development Team Manager The Scrum Master may be new to the role and retain their command and control management style. The Development Team may be uncomfortable or unfamiliar with the concept of self organisation and so look to the Scrum Master as a manager who will provide answers and make decisions for them. Either way the team fails to self organise. The result is that the Development Team loses the potential to benefit from their collective wisdom. The solutions they come up with only be as good as the abilities, knowledge and experience of the Scrum Master. Motivation usually remains low, coordination of work is driven by the Scrum Master and productivity will be severely restricted. The Scrum Master will be a bottleneck to the performance and success of the Development Team. No Cross Functional Teams The organisation puts together a team, introduces Scrum and starts a project. However the Development Team only contains the people available to the organisation at that time. There are vital skills missing from the team. Yes, the team can learn and develop these skills but where there are fundamental gaps right from the start they will be faced with an uphill challenge. Progress is still expected immediately and the team do their best, but usually the result will be significant amounts of undone work and technical debt which must be repaid at some time in the future, and before the Product can launch. Expect delays, big delays! Lack Of Agility From Fixing Scope, Budget And Timeline The organisation wants to be Agile and introduces Scrum as a step along the path, but still launches projects with fixed scope, budget and timelines. Yes, Scrum can still help in this environment, but the potential for agility will be low. Valuable improvements to the Product will be identified in Sprint Reviews but will have to deferred in favour of completing the originally agreed scope. Much of this initial scope will be lower value, but the plan and expectations are in place and cannot be changed. The Development Team learns that initial estimates were not perfect (surprise, surprise - this is difficult to predict complex software development after all) but no scope reduction is possible and no additional or resources or time can be added. The team is pressured to complete the work as initially planned. They will do their best, but what will happen is that quality will be compromised and the target date will still inevitably be missed. Pressure and stress will increase as time goes on and actually the team will end up far less productive over all. The project will complete late and result in a lower value, lower quality Product being created. How Not To Fail These types of scenarios will occur on many projects. The secret to solving them is to use the inspection, adaptation and transparency that comes with Scrum to highlight and fix these dysfunctions as they are identified. If the organisation is serious and committed to becoming Agile, then this is the only way to be more successful. Scrum challenges us to change the things we have always done (that did not work well). This is often difficult, but is essential if we are to improve, which is what it is ultimately all about. The alternative is to use Scrum, ignore the problems it highlights and then for projects to continue to struggle as they always did. Scrum brings no easy answers, but does show us the difficult problems we face and challenge us to address them.