Simon Kneafsey

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.

The most common question I am asked at my courses is - what makes a good Scrum Master? I always answer this question with a story from my own experience working with Scrum Masters (good and bad) over the years. The 2 best Scrum Masters I ever had the pleasure of working with had a lot in common. They were both excellent servant leaders who fostered self organisation, supported the Development Team and Product Owner and guided their organisations on the path to agility. However, they did this in different ways and came from very different backgrounds. In my earlier post, I talked about Joe, a born technologist who became a master of enabling self organisation with his Development Team. The second Scrum Master, let's call him Laurence, was relatively young with only 2 years experience in IT. I worked alongside Laurence for a few months and was impressed with his skills as a coach and facilitator. He was far more effective than many highly experienced Scrum Masters I had worked with over the years. One day I asked him how he had got so good so quickly, and this is what he told me. Laurence had studied Drama at university and was a talented actor. Unable to find enough acting work to support himself after graduating from University, he took a job in IT as a software tester. He did this for awhile but didn't feel he was really suited to it. Then a project he was working on introduced Scrum, and a talented Scrum Master was brought on board to guide the transition. Over many months Laurence watched and learnt from this Scrum Master. He used his skills as a trained actor to observe and learn the behaviour and characteristics that made this Scrum Master effective. He "learnt" the role of the Scrum Master, just as he would as an actor learning any other role. When this initial project was successful, the organisation looked for volunteers to be the Scrum Master for a new Scrum Team. Laurence volunteered and was given the role. Whilst still unsure of all the details of what to do, he "acted" the role of the Scrum Master as he had learned previously. He surprised himself and his team when he quickly found an affinity for the role and helped his team to develop a market leading product in a very short period of time. The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality - The Scrum Guide Laurence's strength was in his abilities as a coach and facilitator. When the Development Team approached him with an issue or impediment, rather then trying to solve it for them, he opened and facilitated discussions with the team and helped them find their own solutions. He was better as a coach than almost anyone I had ever seen. He went on to explain a further secret to his success. He knew he didn't have the best answers! Laurence had only 2 years IT experience at this stage which was far less than those he was working with. As such he didn't feel qualified to provide the Development Team with ready made answers. He had no choice but to help the team to find their own solutions. He wanted to be useful to them in this process so quickly learnt to ask the right questions and encourage the team to be open, confront the issue, explore options and then decide and fix on a course of action. He also encouraged frequent inspection and adaption to ensure the selected option was helping as planned. If a solution wasn't turning out to have the desired effect he would raise this to the team and challenge them to find another way forward. As Laurence didn't have the answers the Development Team wanted, he became adept at helping the team find their own solutions. The Development Team appreciated the role he played in facilitating these sometimes difficult discussions and helping them to benefit from their collective intelligence. They recognised that without his efforts they would have often selected a sub optimal solution, wasted significant time or ignored important issues all together. Laurence served as the conscience of the team. kept them focussed on finding the best solutions and challenged them to keep doing this. Laurence is a great example of how a Scrum Master can succeed without a strong technical background. Whilst technical skills can help in the role, they can sometimes get in the way of the Scrum Master being an enabler of self organisation for the Scrum Team.