Simon Kneafsey

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.

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. The first Scrum Master, we'll call him him Joe (as that was his name), was a born technologist. He loved writing code and developing complex software Products. He was the Senior Developer prior to his team adopting Scrum. The organisation had strict budgets and could not (or would not) afford to recruit a Scrum Master. The Development Team needed someone to take on the role, and initially there were no volunteers. After some discussion, Joe stepped up to fill the void. He agreed to take on the Scrum Master role, whilst remaining part of the Development Team and continuing to be hands on at creating software. [Development Teams] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality - The Scrum Guide Joe loved writing code and wanted to spend as much time as he could doing this. This could have been a recipe for disaster if he neglected his Scrum Master duties in favour of his other work. Instead it led him to become a true facilitator of self organisation for his team, and a highly effective Scrum Master. Rather than falling into the trap that many novice Scrum Masters find themselves in, where they interpret the "remove impediments" part of the role too literally and feel they need to be the one to solve every problem that is raised, Joe found another way. Joe wanted the Development Team to learn to solve their own problems as fast as possible. He was motivated to foster an environment of true self organisation within the Development Team so they were not over reliant upon him so he could spend as much time as possible writing code. This was a significant cultural change for the organisation. Up to the point where Scrum was introduced, Developers raised issues to Project Managers who were then responsible for finding solutions. The team wasn't used to being challenged to find solutions to their own problems. They needed help to get comfortable doing this. Joe was patient and worked tirelessly to make this happen. He resisted the urge to present the team with his own ready made solutions. He knew if he did this they would continue to look to him for answers. They would also be less likely to effectively implement solutions that had been pushed on them by someone "more experienced". Over time, the Development Team learnt to become self organising. They became more productive as they found solutions to the problems they faced faster. They no longer had to wait for someone else to step in and find an answer for them. They became skilled at using their collective intelligence to solve complex problems. They still called on Joe as the Scrum Master when they needed him, and he always put his Scrum Master responsibilities first when called. Joe helped them when issues were too tough or were out of their area of influence. As Joe was not overwhelmed by the volume of issues that came his way, he could dedicate time to deal with the truly important stuff and ensure that they were resolved promptly. The result was that the Development Team learnt to self organise and got better and more efficient at producing software. The Development team felt a greater sense of ownership of their work, and enjoyed the additional autonomy to get things done. Joe was happy as he had coached himself out of a large part of his day to day activities as a Scrum Master, and was free to do what he loved - write and test code as part of the Development Team and create valuable and innovative products for the organisation. When he was called on as a Scrum Master, he enjoyed the additional responsibility and variety that the role offered. He was highly effective as a Scrum Master as he enjoyed a high level of respect from his colleagues in the Development Team as he was "one of them" and could "walk the walk" and well as "talk the talk". In my next post I will tell you about Laurence, an altogether different, but still highly effective Scrum Master.

Yes, of course it is! Scrum is a framework to help teams and organisations on their path to agility, but it is by no means the only way to be agile. Back before I knew about Scrum, I worked on projects that were agile. Back then we didn’t really know what agility was all about, but that didn’t mean that it sometimes didn’t occur naturally. We just didn't make a conscious effort to be agile, as most organisations do nowadays. One project that I worked on many years ago did not use Scrum, yet was very agile. The project was to build a large and very well known newspaper website in the UK. It was characterised by a few key factors which I will explain to highlight our level of (unaware) agility. Small Is Best - Time, Scope and Team The project was deliberately kept small, both in terms of scope and the number of people involved. Despite it being a potentially large project, the time scale was very short and we had to deliver a new product within a fixed 3 month deadline. To do this the business rightly realised we had to strictly limit the scope of work and focus on the most important things first in case we ran out of time. Scope was fixed and relatively small and was kept this way to give us a hope of success. We had only 3 Developers on the project and 1 Product Manager from the business working closely with us on a daily basis. Resources were fixed and would not change throughout the initial delivery phase. We had to make do with what we had. Clear Requirements We had very little in the way of written requirements. There just wasn't time for this. Instead we had 1 person (our Product Manager) representing the needs of the business and the future users of the product. They sat with us Developers and were on hand every day to speak to us and answer any questions we had as we were working. Responding to change over following a plan - Manifesto for Agile Software Development Regular Planning We did very little in the way of formal planning, but every Monday morning we would all meet and discuss what we hoped to achieve by the end of the week. Our Product Manager would attend and remind us what the most important things were. We would work on those and complete them first. As a small Development Team we sat together and spoke about what we were doing and how we could help each other. We did this all day every day. It came naturally as we had been working together for many years and had got used to doing this over many previous projects. Regular Reviews Customer collaboration over contract negotiation - Manifesto for Agile Software Development At the end of every week we would get together informally and show off what we had done. Our Product Manager liked seeing what we had been working on throughout the week all working together in one place. There were no surprises for her as she saw what we were all doing each day whenever we had a question or wanted some clarification over something. As and when things were done during the week we showed her what was ready and sought her feedback. This close contact meant that we were always delivering what the Product Owner needed and didn’t risk going off at a tangent, wasting time creating the wrong thing. Regular Improvement We didn't hold formal retrospectives, but whenever someone found a way to do something better we talked and shared. Whenever someone had a problem we also talked and sought help. We never really stopped talking and sometimes it was a wonder we ever got any code written!. But this information sharing was very useful. On one occasion I was about to start a 1 week piece of work. On checking in with the Developer sat next to me over coffee, I discovered something similar had been created on another project. I was able to reuse it and saved myself 4 days of pointless wasted work. Talking was good! A Cross Functional Self Organising Team All the Developers in the team were of a similar level of experience and were classed only as 'Developers' by the organisation. There was no hierarchy in the team. There was no one else around to tell us how to do things, as no one else knew how to do it. Our manager was busy working on another critical project and had no time free to help us. Individuals and interactions over processes and tools - Manifesto for Agile Software Development As there were so few of us we were all expected to do any and all tasks required to produce the finished software. This included business analysis, architecture, writing code, creating environments, managing the database, testing in all its forms and release activities to put the software into production. We were the very definition of a cross functional, self organising team before we even knew what such a thing was. Quality Is Key There were no dedicated testers. The organisation believed it couldn't afford them. As a result, we were all responsible for the quality of what we produced. We also knew we would have to deal with the consequences of any problem code going into production, as we also had to support the site once it was live. There was no support team to pick up the issues that we created and there never would be one. As a result, we created very few live issues, and where they did occur we fixed them as a priority so we could be free to continue developing new features, rather than supporting a failing production system. Regular Releases Working software over comprehensive documentation - Manifesto for Agile Software Development With no dedicated release team we had to put our own work into production. We did this daily until the site went live and because of this we got really good at doing releases. As a result, even once the site was launched we continued to release at least a few times each week, which kept our Product Manager happy as she could get new functionality as soon as it was ready. It also helped us as it meant we didn't have to deal with the complexity of branching strategies and integration became a small and trivial task. So Did We Need Scrum? Looking back I now realise that this all looks a lot like Scrum, albeit without the formalities. Without meaning to we stumbled across the secret to successful software product development. So did we need Scrum? In this case we did well and were agile without it. However many other projects at the same organisation were not so successful and the failure rate was still high. The organisation would have benefited from Scrum at this point as it would have led some of the other Development Teams to some of the solutions we had found naturally. The organisation did go on to implement Scrum throughout a few years later. For my team, it seemed easy. We were already doing most of it without having the formal rules in place. The addition of Scrum just made sure we formalised what we already did, picked up a few new tricks (Definition of Done and a more empowered Product Owner) and made sure we didn't forget some of the really important stuff we were already doing. For the other Development Teams it made a huge impact quickly and enabled the organisation to produce many more market leading products and scale their development efforts successfully.