Barry Overeem

This week I had the privilege to facilitate the Zombie Scrum workshop with Christiaan Verwijs. Together with Johannes Schartau, Christiaan created the Zombie Scrum workshop with the goal to call attention to the alarming condition of Scrum in many organisations. In the article "The Rise of Zombie Scrum" Johannes and Christiaan provide an comprehensive description of the symptoms, causes, and treatment of Zombie Scrum. In this blog post I'll share the highlights of the original article and offer my own perspective on the causes and treatment of Zombie Scrum. Knowing what causes Zombie Scrum might help prevent a further outbreak of this terrible evolution What is Zombie Scrum? At first sight, Zombie Scrum seems to be normal Scrum. But it lacks a beating heart. The Scrum teams do all the Scrum events but a potential releasable increment is rarely the result of a Sprint. The team also don't have any intention to improve their situation. Actually nobody cares about this team. The stakeholders have forgotten the existence of this team long time ago. Zombie Scrum is Scrum, but without the beating heart of working software. The Symptoms of Zombie Scrum Symptom #1: No beating heart Zombie Scrum Teams may be going through the Scrum-motions, but there is hardly any working software (or none at all). Completed functionality is often treated as a ‘nice-to-have’, and can be finished in any other sprint. The lack of a beating heart is also apparent in a very limited and unambitious definition of what ‘done’ means, and no drive to extend it. In healthy Scrum teams understand that having a continuous stream of ‘done’ software is not a nice-to-have, but an essential goal of Scrum. Zombie Scrum approaches this differently. Who cares about working software, gathering feedback and generating insights? Symptom #2: No (desire for) contact with the outside world Scrum zombies prefer to hide away from people and keep to their familiar surroundings. They neither care what’s upstream nor what’s downstream in the value chain. The product failed to meet customer expectations? I’m only here to code! Zombie Scrum teams see themselves as a cog in the wheel, unable and unwilling to change anything and have a real impact. Symptom #3: No emotional response to success or failure The lack of contact with the outside world often leads to this symptom, but it can also manifest itself independently of the other symptoms. Like a lifeless body, Zombie Scrum teams show no response to a failed or successful Sprint. Where other teams curse or rejoice, they simply keep their empty stare of numb resignation. Team morale is very low. Items from the Sprint Backlog get carried over to the next Sprint without question. Because why not? There’s always a next Sprint and the iterations are artificial anyway! Symptom #4: No drive to improve In Zombie Scrum there’s no joy, and certainly no drive for improvement. And nobody really seems to care. And can you blame the team? The Product Owner is hardly ever present during the Sprint Review or the Sprint Planning. Teams are highly unstable, as members continuously get loaned out to other teams in need of their (specialised) skills. And there’s no actual Scrum Master present to help the team grow. Some of the bottlenecks may be real, while others may be imagined. But the bottom-line here is the lack of control a team experiences over their own success, and this easily translates into boring retrospectives, a lot of complaining (moaning). And certainly no desire to improve. The Causes of Zombie Scrum Cause #1: A bit too homegrown, or ‘Cargo Cult Scrum’ Homegrown Scrum is great. That is; teams and organisations that start working with Scrum without the help of (expensive) external trainers and coaches. Some of the best Scrum Teams started out like this. But Scrum can be a bit too home-grown. Like when a team decides that they’re doing Scrum because they have a bi-weekly ‘Daily Scrum’, or when a team adjusts the sprint length based on what needs to be done (instead of the other way around). This partial adoption of Scrum is often unintentional. But by adopting only a part of Scrum, the actual benefits are lost, and the team will likely struggle. Cause #2: No Urgency We often witness a lack of urgency in Scrum Teams, usually caused by a lack of urgency in the rest of the organisation. One of the potential underlying causes is that there’s no real understanding of value. If working software is the beating heart of Scrum, then value is its lifeblood. Due to the fogginess regarding value, mediocre Scrum Teams often have a hard time coming up with clear goals. Without goals there’s simply no reason for urgency. And that in turn causes Zombie Scrum, as shared goals are the glue for any team and provide them with purpose and motivation. Cause #3: Competing Values Zombie Scrum is essentially the result of a systemic mismatch with Agile values. We know that the business lingo is strong with this one, but the point we’re trying to make is that Healthy Scrum easily decays into Zombie Scrum when people in the organisation hold beliefs about software development that collide with what drives Agile software development. To give you some examples: Zombie Scrum considers the purpose of Scrum a process that must be followed (for its own sake). Instead of understanding that Scrum allows us to ‘fail fast’ because of a steady stream of working software; Zombie Scrum considers working software a nice-to-have; we’re not going live at the end of a sprint anyways. In healthy Scrum working software is essential; even if we don’t go live at the end of a sprint, we learn most from it; Zombie Scrum teams experience no sense of urgency. There’s always a next sprint. Sprints are artificial time-boxes. In healthy Scrum teams however, a sprint is the longest allowed period between feedback opportunities. Cause #4: Scrum Cherry Picking At first sight "Scrum cherry picking" might seem the same as "cargo cult Scrum". The difference however is that with Scrum cherry picking the partial adoption of Scrum is done on deliberately. Doing Scrum by the book was too difficult. It caused too much pain within the organisation. Therefore some changes to the already lightweight Scrum Framework were "necessary": Allowing the tester to fulfil the Scrum Master role 4 hours per week. Sharing the weekly status report with the management shouldn't take more time; Extending the Sprint with a couple of days to ensure a “done” Sprint; Ending the Sprint Planning without a shared commitment on the Sprint plan and its goals; Cancelling the Sprint Review because “there’s is nothing to demonstrate”; Cancelling the Sprint Retrospective because “we don’t have enough time to improve”; Considering Backlog Refinement as a "meeting" that includes only the Product Owner and the “Lead Developer”. Cause #5: Contracts Implying "We Don't Trust You!" Truly value-driven organisation also embraces value-driven contracts. These are contracts that have a foundation build on transparency and trust. Such a contract stimulates effective partnerships and invites collaboration. A value-driven contract supports adapting new insights and processing gained knowledge. It encourages acting on necessary changes and lessons learned. A value-driven contract is lightweight and only contains the necessary agreements and constraints. A value-driven contract embraces the Agile mindset. In reality however, agreeing upon an Agile, value-driven contract is difficult. When the customer has a great idea, enthusiasm is high and possibilities are endless. We only have to agree upon the contract… The difficulty with contracts is that it’s all about trust. If there’s enough mutual trust in each other’s capabilities, setting up a contract probably won’t be too difficult. But often the customer and supplier haven’t worked together before, therefore it lacks a proven foundation of trust. The customer wants guarantees around budget, time, quality and scope. A decent change control process is lacking. After some tough negotiations the development team starts but doesn’t truly collaborate with the customer and is just mechanically building what’s written in outdated requirements. A suboptimal product, build in atmosphere of Zombie-Scrum, will be the result and the relationship and trust is damaged deeply. Cause #6: The Smell of the Place In organisations, it's all about the context. This has a huge impact on the behaviour of employees and largely determines the risk of Zombie Scrum. In the video "The Smell of the Place" professor Sumantra Ghoshal offers four examples of smells in organisations. The ones on the left describe "downtown Calcutta in mid summer", on the right is "Fontainebleau in spring". In addition, I'll share some smells that I have interpreted and experienced in organisations. Constraint versus Stretch Compliance versus Discipline Control versus Support Contract versus Trust Project versus Product Planning versus Prognoses Commitment versus Forecast Resources versus People If the context of an organisation has lot's of smells that resemble with "downtown Calcutta in mid summer"; chances are Zombie-Scrum will occur. Therefore focus on the opposite of every smell and create "Fontainebleau in spring" in your organisation! Treating Zombie Scrum So suppose you’re dealing with an infestation of Zombie Scrum. How do you deal with this? After countless experiments, we have come up with a few potential antidotes that might help: Treatment #1: Become a Zombie-whisperer You might not expect much out of a bunch of zombies, but simply talking to them may work wonders. Zombie Scrum Teams are rarely happy with their predicament. So a good start is to talk about their situation, and identify potential causes and solutions. It also helps to talk about values and beliefs, and (when necessary) educate on the purposes of Scrum and the underlying values. We would like to emphasise strongly that Zombie Scrum is not a team-problem. Zombie Scrum is a manifestation of the disconnect between organisational values and Scrum values. The role of management cannot be understated here; they have to support and communicate the key values of Healthy Scrum in everything they do. Treatment #2: Introduce Healthy Scrum into the population Another way to combat Zombie Scrum is by introducing people into the population that can show and explain how Healthy Scrum works, and communicate the right values. Teams and organisations suffering from Zombie Scrum often feel that things aren’t working as well as they should, but unaware as to what’s causing this. There are many ways to do this. Take teams and management on a Scrum-safari in other companies, and show them how Scrum works there. Or hire employees with Scrum-experience that can show how things are done. It can also help to bring in Agile coaches to help teams and management understand Scrum better, as long as their focus remains on helping the organisation take care of things themselves as soon as possible. Treatment #3: Shake things up (don’t continue the stumble) You can shake things up by changing the way the team interacts within the Scrum framework, for example: Zombie Scrum teams often benefit from a shortened Sprint length. Instead of three to four week iterations decrease the length to two weeks or even just one. Focus the Sprint Planning on answering the question what type of impact the team would like to achieve within the upcoming Sprint. Start the Daily Scrum by reviewing the Sprint Goal and asking what achievements the team has made towards reaching that goal. Use the roadmap to provide context for the insights from the Review meeting. And for heaven’s sake, invite some real customers or stakeholders! Use the Retrospective not to drag out the same old problems but to dream big. A transformational approach might be better suited than an incremental one. Whatever you do, keep in mind that you can’t always save everybody. Some people are zombies by choice and the disease has already spread too far. Treatment #4: Involve the broader Scrum Community You are not alone in your fight against Zombie Scrum. With the ever increasing adoption of Scrum, there is also an increasingly large community. Benefit from the community by asking help from people with more experience. Visit local Agile or Scrum Meetups, use forums (like the one at Scrum.org) or Facebook to ask for help or invite fellow Scrum Masters or Agile Coaches to drop by. Or send an email to bloggers like us; we’re happy to help! Treatment #5: Dare to Embrace Agile Contracting Principles Start small. Even when a customer has a huge budget for his project, first agree upon doing only one Sprint. After you’ve created and estimated the product vision and Product Backlog together, only do the first Sprint with the goal of delivering the first ‘done’, valuable and potentially releasable increment. Perform a Sprint Review and Sprint Retrospective and decide if there’s enough mutual trust to start another Sprint. Sell/Buy the Entire Scrum Team. Fixed Scrum Teams that have been working together for a longer period, have experienced up’s & down’s and know there velocity are worth gold. A common pitfall is to separate this ‘golden team’ when a new project arrives. Don’t do this. Keep the team together at all costs. The customers gets the entire team, including tester, analist, designer, Scrum Master, developers etc. Sell/Buy Sprints. When working with fixed teams that know their velocity, it’s also easier to sell sprints for this team. Of course velocity is something for the team, will take 3 -5 Sprints to discover and can vary with every product they build. However, a fixed, experienced team knows what they are capable of, can estimate a Product Backlog and give a range of how much Sprints the realisation will probably take, for example: between 5 – 7 Sprints. Because the team is fixed they also know what the costs per sprint are, for example 40.000,-. This means the necessary budget for this project will be between 200.000,- and 280.000,- During every Sprint Review, the Scrum Team and stakeholders can discuss the desired features that should be developed the upcoming Sprint. They can discuss how much value the will get taking the cost per Sprint into account. By selling Sprints the advantage for the customer is the possibility of early termination of the contract. When the cost of continuing the project is higher than the additional value received, there is the possibility of just not buying any more Sprints. Treatment #6: Setup a Smell-o-Meter Changing people’s behaviour is not about changing people, but changing the context which they are in: the smell of the place. - Prof. Goshal Make the smell of an organisation "transparent" by setting up a smell-o-meter. My former colleague Wouter van der Meer wrote an excellent blog post about this idea. By offering transparency about the smells everyone experiences in an organisation you can act on it. An increase of negative smells might result in Zombie Scrum. Therefore everyone should continuously be aware of bad smalls and act on them immediately. This will ensure an organisational context that can resist Zombie Scrum to occur. Closing In this blog post I've shared the highlights of Zombie Scrum as described by Christiaan Verwijs and Johannes Schartau. In addition to their original article I've added some causes and treatments. Hopefully this decreases the chances of a further Zombie-Scrum outbreak! If you've got any other ideas on how to deal with Zombie-Scrum, please share them! If you want us to help your organisation prevent or fight Zombie-Scrum: just contact Christiaan, Johannes or myself. We provide coaching, training and workshops to deal with this alarming outbreak of Zombie Scrum. Not all is lost, but we must be brave and act courageous!

When Scrum is introduced in a company, most of the time, the development team embraces it with lots of enthusiasm. Scrum embodies self-organizing, autonomous, multidisciplinary teams that acknowledges individual qualities and reinforces the strengths of the team as a whole. Who doesn't want to be part of a Scrum team? Quite often however, after the Scrum honeymoon period, I start to hear comments like: "Since the introduction of Scrum, all I do is attend meetings. I didn't become a developer to attend meetings all day long." "With Scrum I hoped we would get a team culture, but instead it feels more like a meeting culture." "I thought Scrum meetings we're time boxed, but for example our daily Scrum takes at least 30 minutes and afterwards we still don't have a solid plan as a team." The Scrum Guide states the prescribed Scrum events (they are explicitly not called meetings) are used to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed, such that every event has a maximum duration. The prescribed time-boxes based on a sprint of 1 month are: Daily Scrum: 15 minutes Sprint Planning: max 8 hours Sprint Review: max 4 hours Sprint Retrospective: max 3 hours Product Backlog refinement: on average 10% of the capacity of the Development Team Considering these time-boxes, Scrum doesn't seem a framework that should result in a meeting culture. So what is it, this feeling often does arise? [caption id="attachment_22645" align="aligncenter" width="648"] Collaborative, fun and energising Scrum Events at Schiphol![/caption] Reasons I can think of: Scrum events aren't kept to their prescribed time-box. More time than prescribed in the Scrum Guide shouldn't be necessary. But I've seen daily Scrum's that last for 45 minutes... Scrum events lack a clear structure. If a clear structure and agenda is missing, it's difficult to respect the time-box and achieve the desired outcome. The team isn't properly prepared. Every Scrum event requires a decent preparation by the team. To me, this isn't only a characteristic of a true professional, but also an indication of respect towards your team members. Meetings not defined in Scrum aren't minimized. Most likely, the team has to attend other meetings besides the regular Scrum events. For example: company wide presentations, knowledge sharing sessions or a meeting with a customer. This is sometimes insuperable, but it should be limited as much as possible. Meetings aren't fit into the schedule of a developer. For most managers, attending meetings all day long is their presumed job. They are used to go from one meeting to another. For a developer this is different. Doing some programming requires a high amount of focus and concentration. Having lots of meetings during the day (and it doesn't matter if these last only a few minutes) prevents a developer to become really productive. Task switching is one of the largest causes of waste in productivity. How to prevent Scrum to be characterised as "meeting heavy"? Possible solution are: Scrum events aren't meetings but opportunities for a conversation. Tobias Mayer describes this perfectly in his book 'The Peoples Scrum': "Scrum is centered on people, and people have conversations. There are conversations to plan, align, and to reflect. We have these conversations at the appropriate times, and for the appropriate durations in order to inform our work. If we don't have these conversations, we won't know what we are doing (planning), we won't know where we are going (alignment), and we'll keep repeating the same mistakes (reflection)." Stick to the prescribed time-box. Take for example the daily Scrum; I think this event exceeds its time-box the most often. While the daily Scrum in particular is an event that you only learn to do well when you respect the time-box of 15 minutes. Longer shouldn't be necessary to synchronize as a team and create a plan for the upcoming day. Sticking to the time-box, although the goal of the meeting hasn't been achieved, forces to team to find a solution for the next time. If you don't stick to the time-box, there isn't a sense of urgency to fix it. Prepare the schedule for the Scrum events upfront and ensure the goal is clear. Communicate the agenda early; this gives every team member the opportunity to prepare him-/herself properly. Also clarify what kind of preparation you expect from the team, given the goal of the session. If someone has to demo a feature during the sprint review, communicate this as soon as possible and reserve some time during the sprint. A nice tool to help the team understand the purpose and expected outcome of the Scrum events is provided by Crisp with the Agile Meeting Cube. Don't consider Backlog Refinement as a meeting. The Scrum Guide describes Backlog Refinement as the act of adding detail, estimates and order to items in the Product Backlog. Backlog Refinement isn't a formal component of the Scrum framework but an ongoing process to improve the Product Backlog. It shouldn't be considered as a meeting but an activity to collaborate as a team with the goal of reviewing and revising Product Backlog Items. The advise is to spend on average 10% of the capacity of the Development Team to refinement, the way it is done isn't prescribed and is up to the team. Use "Do Not Disturb" time slots. During these time slots the Development Team doesn't have any meetings and will only get disturbed (by someone outside the team) when it's really urgent. Sure, this shouldn't interfere with the intention of collaboration and transparent communication that the team wants to achieve, but a healthy balance with the aim on achieving the necessary focus should be a reasonable goal. Ensure the fun factor is present. The Scrum events or other non-Scrum meetings don't have to be boring, tedious and energy draining. My intention is always to foster fun, energy, interaction and collaboration in every session. Tricks to enable this are not using a beamer with lots of PowerPoint slides, put the chairs in a circle and minimize the use of laptops. And again: don't consider meetings as a ceremony with all the 'smells' attached, but as an opportunity to collaborate, learn and have fun! Create a sprint calendar. Providing transparency by creating a sprint calendar that contains all the Scrum events and other meetings can be very valuable. It gives the team the insight on what they can expect during a sprint and helps with creating a sprint- en daily plan. Sometimes the team feels they have got lots of meetings, the sprint calendar transfers the feeling into facts. Based on these facts the team can decide if the feeling is justified and sometimes has to change. Embrace meetings with the customer. Considering the Agile mindset, customer collaboration is a vital part of successful product development. Their shouldn't be a cold customer-supplier relationship, but a partnership where the customer is part a the team, with the desire to create astonishing products. Meetings with the customer therefore should be seen as an opportunity to understand the 'why' and 'what' of the product and increase the chance of building the right product. To me, Scrum doesn't equal a meeting heavy culture. I can however understand the arguments people often use to address this comparison. In this blog post I offer some solutions to prevent a meeting culture, or put differently, prevent the feeling of Scrum as meeting culture enabler. If you have got any other tips, tricks or experiences, I would like to hear them!

At Amsterdam Airport Schiphol we're using an Agile approach to realise a large digital program. This program includes 5 value streams with multiple teams. Due the increasing scale of the program some challenges arise. For example: How to organise a Sprint Review with an increasing amount of teams and stakeholders and preserve a valuable outcome? In this blog post I'll describe the challenges and experiments we might try to deal with them. Some of these experiments are ideas proposed by Preeti Gholap. She answered my question I posted on LinkedIn some time ago. Thanks Preeti! The Theory The purpose of the Sprint Review is to gather feedback on the delivered product and evaluate the collaboration. The Sprint Review should be used for a demonstration and inspection of the developed increment. It’s the best opportunity to adapt the product backlog if needed and release the increment to production if the Product Owner finds it useful enough.  It’s the ideal moment for a joint reflection and to decide how to proceed to optimise value. The Bright Side Earlier on I wrote an optimistic article about the Sprint Review at Schiphol. The article "5 Characteristics of a Great Sprint Review" offers five examples of what is going well: Stakeholders are difficult to recognise. For sure they are present, but they blend themselves between the Scrum Teams making it one big collaborating group of people. Every Developer Participates. Yes! Every developer was there. Most of them holding sticky notes on which they wrote down the feedback they received on their product. Feedback. Feedback. Feedback. In short, the Sprint Review was one big feedback party. Every Scrum Team provided demonstrations on several devices. Everyone could actually use the product and share experiences and lessons learned. A Tailor Made Sprint Review. A great Sprint Review has a tailor made format. Sometimes using different market stalls for every team is the best format, sometimes a central demonstration & discussion works best. A great Scrum Team continuously searches for the ideal format to gather feedback. Beer & Bitterballen. The follow-up of the Sprint Review is of course the Retrospective. The ideal opportunity to process the Sprint Review and discuss possible improvements combined with beer & bitterballen. The Dark Side The increasing scale of the program however has impact on the Sprint Review. Due the increasing amount of participants some pitfalls start to appear, for example... The Sprint Review becomes a Demo. It's not a feedback party anymore but a demo-festival. To be honest, it was already called a "demo", but it had all the characteristics of a Sprint Review. There was a focus on gathering feedback and collaboration. However, nowadays the large amount of one-sided demo's starts to exceed the opportunity of gathering in-depth feedback. Stakeholder abundance. Is it possible to have too many stakeholders at the Sprint Review? Ideally, no. But it can become an issue when the amount of irregular visitors makes its imprint on the session. These "one-time" visitors expect an explanation of the project/product as a whole, not necessarily an update about the previous Sprint. This is not only time consuming, but it also doesn't add any value for the Scrum Team, who wants detailled feedback on their previous Sprint. Developers are not participating anymore. As a consequence of the lacking feedback, not every member of the Scrum Team attents the Sprint Review anymore. The Scrum Master and Product Owner start acting as the ambassadors of the Scrum Team. They are becoming the hub between the stakeholders and the Development Team. The valuable dialogues between the stakeholders and the Development Team are diminishing. Ideas for Experiments 1. Organise a monthly demo besides the bi-weekly Sprint Review For sure the demo is valuable. But it has a different goal compared to the Sprint Review. The primary goal of the Sprint Review is gathering feedback. The goal of the demo is creating alignment between everyone involved or interested. Organising a monthly demo with a focus on alignment and a regular smaller bi-weekly Sprint Review (maybe per value stream) with a focus on gathering detailed feedback might be a good solution. 2. Organise "small circle" and " large circle" 2-part Sprint Reviews A solution suggested by Preeti Gholap I started this when I was coaching 6 teams that needed to do a joint demo, in a  situation when we only had limited face-to-face access to stakeholders (who had to fly in from several countries). Each team uses the first part of Sprint Review (say 40 minutes for a 2 week sprint worth of stories) to get detailed feedback from their own “small circle” of mandated users/accepters – this is a small group of 4-6 people with whom the team and Product Owner works with closely for both Backlog and user story level refinement and acceptance. (full cycle engagement, thus). The feedback we’re looking for here is: “is this usable?”, “does it meet all the acceptance criteria, functional, non functional, for the users and for operations/run?" Then the teams proceed to the joint demo- the “ large circle” where each team presents a summary of the increment and its value (thus not the details per story) to the other teams and management/wider stakeholders.  The feedback asked for is at the level of: is this valuable, and contributing to the whole? Are we going in the right direction? Are there upcoming dependencies etc. The "small circle" has intense contact with its own Scrum team throughout the Sprint- via phone, webex, Jira etc, and also face-to-face at the Sprint Review. The "large circle" has face-to-face contact with all the Scrum Teams in the product program every 6 weeks. This has worked quite well for us. 3. Continuous-flow acceptance decoupled from Sprint Reviews Another solution suggested by Preeti Gholap This is a way I learnt from a team I currently coach, who are working on a complex COTS app, and were doing this even before “officially becoming Agile”. This team ensures they get detailed feedback and acceptance on a per story basis  “as soon as it’s done”. Since entering the Scrum/Agile coaching program at the company we work at currently, they have been learning to make stories smaller, more vertical etc,  and consequently they are getting good at getting valuable stories to "done"  every few days. Meaning, they are in the lovely position of having acceptance on a per story basis several times during the Sprint. And this even without any kind of automation. They are able to do this in part because their end-users are close at hand, and their Product Owner trusts that team and end-users can collaborate nicely without her (the Product Owner) needing to preside over a "demo". (The main reason they can do this, is they have always embraced Getting Things Done and face-to-face collaboration). I actually have a hard time convincing this team to do a Sprint Review (“whats the point? the work is accepted already”). But neither they nor the organisation is quite ready for a Kanban/continuous flow way of working. Slowly, they are seeing that a short Sprint Review is still handy for the reasons beyond feedback on the Sprint result. For example engaging with wider stakeholders concerns, for visibility and appreciation for the team members themselves, and the “feed-forward”- reconfirming the roadmap with stakeholders holding diverse agenda's. So, this technique of decoupling detailed feedback from the Sprint Review could also help your scaled teams. Closing In this blog post I've shared the challenges we currently face within Amsterdam Airport Schiphol with the Sprint Review. How to organise a Sprint Review with an increasing amount of teams and stakeholders and preserve a valuable outcome? Thanks to the ideas suggested by Preety Gholap I've described some experiments we might try to deal with them. If you've got any other suggestions that might be useful to experiment with: please share them! It's highly appreciated!

This year I was in the lucky circumstance to be part of some awesome (Scrum) teams. It certainly wasn't all "Scrum by the book" but I've learned a tremendous amount of lessons and generated lots of values insights. As always, some things turned out to be a success, other things failed miserably. This blog post contains a mixture my failures and successes using the Scrum Framework as a starting point. The first part of every paragraph briefly describes the most common failures I've experienced; the latter the successes I've already achieved this year or hope to achieve in 2017. Wouldn't it be great if in 2017... The Scrum Team isn't a group without any synergy at all but forms a solid, stable and reliable team moving forward as one, having fun with each other and continuously challenging, supporting and engaging one other to do improve on daily basis. The Scrum Master isn't a clerk, puppet master or project manager in disguise but someone who becomes acknowledged for its diversity being a servant leader, facilitator, coach, manager, mentor, teacher, impediment remover and powerful change agent. The Product Owner isn't a scribe or proxy without any mandate but someone acting as the entrepreneur for the product proudly representing the customers voice, truly understanding its intentions and goals and is able to outstrip its expectations. Customer delight as the ultimate goal! The Development Team isn't bunch of reluctant individuals without a common goal but is a strong team pursuing technical excellence, is in direct contact with the customer, acting cross-functional, updating the Scrum board themselves, managing their own team composition, having time for innovation, fixing dependencies with other teams themselves and delivering a potentially releasable, valuable product each sprint. The Scrum Values are not a dusty poster on the wall but the values Commitment, Respect, Openness, Focus, and Courage give the Scrum Team a solid foundation and direction for their work, behaviour and endeavours The Product Backlog isn't an endless incoherent list of work hidden in some digital tool but an ordered shared backlog taking priority, value, dependencies, risk and the amount of learning into account. The Sprint Backlog isn't the sum of all the unfinished work of the previous Sprints, but a forecast visualising all the work necessary to meet the Sprint Goal. The Increment isn't a functional or technical document lacking any business value but it's an increment of the product that generates feedback, insights and learning which helps building the right product. The Scrum Events are not considered as mandatory meetings but as opportunities for conversations, discovery and collaboration The Sprint isn't an artificial time-box or everlasting "Sprint 0" without any business value but is considered a powerful instrument that offers focus, rhythm and predictability by ensuring inspection and adaptation of progress toward a Sprint Goal. The Sprint Planning isn't a tedious full day session with a poorly refined Product Backlog but an opportunity to create an engaging Sprint plan with clear goals the entire Scrum team commits to. The Daily Scrum isn't a status-update towards the Scrum Master focusing on minor activities instead of actual achieved results but an energising inspection of the progress made towards the Sprint Goal resulting in a fresh committed daily plan. The Sprint Review isn't considered as a "demo" in which the results are shown to the Product Owner, but is used to gather feedback on the delivered product and evaluate the collaboration. It’s the ideal moment for a joint reflection and to decide how to proceed to optimise value. The Sprint Retrospective isn't cancelled because "there's nothing to improve" or "we don't have time to discuss improvements", but is an opportunity to inspect collaboration, engineering practices and the Definition of Done resulting in actionable and committed improvements or shared working agreements. Backlog Refinement isn't considered as a too expensive "meeting" but seen as a necessary ongoing process to improve the Product Backlog. It's an activity to collaborate as a team with the goal of reviewing and revising Product Backlog Items ensuring a high quality Product Backlog. The Sprint Goal isn't the usual "just realise the Sprint Backlog" but is used as an instrument to test assumptions, address risks or deliver features The Definition of Done isn't a document defined by the Quality Assurance department the Scrum Team must comply to, but a practice for the Development Team to create common understanding about "quality" and helps the team assess when work on the product Increment is complete. A Definition of Ready isn't necessary because frequent refinement of the backlog already creates a flow of Product Backlog Item readiness. Closing This blog post contains my year of Scrum in a nutshell. Using the parts of the Scrum framework as a starting point, I've shared some of my failures and successes. Of course "failure" might sound dramatic, but for example Product Owners without any mandate or Scrum Masters considered the team's clerk did cause me some headaches. Luckily it did result in lots of learning and insights. Can't wait to apply them in 2017! What are your successes or failures using Scrum this year?

Recently I got asked what I consider the most common challenges with Agile projects. These are projects that have such a high rate of uncertainty and complexity on how and what to build, an Agile approach is necessary. Although my gut feeling immediately provided an answer, I gave myself some more time to think about the question. However, this week my initial thoughts proved to be correct. Without any doubt! The Agile Manifesto In my role as an Agile Coach, the Agile Manifesto acts as guidance. The 4 values and 12 underlying principles support me exploring options to daily issues, challenges and questions. I've read many books about Agile software- and product development, but the original manifesto remains my primary source to think about Agile related questions. What We All Agree Upon I've worked in quite a few different organizations. Without exception, every organization wants what the Agile Manifesto values. Of course it should be about collaboration, teamwork and open communication. Sure, working software or a working product is what it should be all about. Without doubt everyone wants a fruitful partnership with their customers. And yes, we all understand that we live in a VUCA world. A world with a high rate of volatility, uncertainty, complexity, and ambiguity. In such a world organizations need to respond to change quickly to become or remain successful. But... We do need to respect current processes and tooling, this is simply necessary considering the legislation. We do need to write proper documentation. The more complex the product, the more time we should spend on determining how to build it, and of course we should write down all our thoughts (guesses and assumptions). We do need a contract that protects us when it gets tough. Even better: let's describe the desired result in the contract in as much detail as possible. At least that won't cause any misunderstandings. We do need a plan. Where would we be without a plan? Although it's quite difficult to predict what's going to happen upcoming year, we do need a detailed plan that eases the minds of our stakeholders. Even better: let's create the plan upfront and give it to the supplier. The only thing that the supplier has to do is execute the plan. How difficult can it be? The Big Misunderstanding There is nothing wrong with processes, tooling, documentation, contracts and plans. But they should all enable the left side of the Agile Manifesto! Not the other way around! Processes and tools are valuable. But they should enable the collaboration, interactions and dialogues of all the individuals involved. There's nothing wrong with documentation. But don't write everything down for the sake of documentation. In the end it's all about working software or working products. Only working software will help you to validate if you're building the right product right. Contracts are important. They can offer everyone clarity and guidelines on what to expect from each other. But don't expect a great collaboration with your customer when the contract says "we don't trust you!" Plans can be useful. But in the end it's all about the conversations we have with each other to create common understanding about the desired results. Remember: "Planning is everything, plans are nothing." - Field Marshal Helmuth Graf von Moltke. The #1 Challenge With Agile Projects Every organization wants to be Agile. Every organization wants the necessary agility to deal with the increasing rate of volatility, uncertainty, complexity, and ambiguity. The Agile Manifesto offers 4 values and 12 principles to support organizations build software/products in such a complex environment. Many organizations acknowledges these values and principles. However, ensuring the right sight of the Agile Manifesto truly enables and strengthens the left side is the #1 challenge with Agile projects. It's a challenge organizations must deal with, otherwise projects with a high rate of complexity and unpredictability are bound to fail! Closing I do want to close this blog post with a positive note. Although the struggle with the values of the Agile Manifesto is a common challenge, organizations do accept more often that change is necessary and inevitable. Doing some Agile practices mechanically isn't enough. Agile projects will only become successful when the values and principles are truly embraced and put into practice. What do you consider the #1 challenge with Agile projects? 

Because there's no easy way in telling you this, I'll just share it straight away... Next week I'll be setting up a Jira environment for the product teams I'm coaching... Yes... Jira! The issue & project tracking system for software teams created by Atlassian. It's pretty easy to find negative quotes or memes about Jira. Below is the result of a few minutes searching the internet... "Jira, where user stories die..." "Jira isn't just an information refrigerator, it's an information crisper: cold, out of sight, and only noticed when turned rotten." "Jira, the word that strikes fear into the soul of a developer." Only a couple of months ago I proudly tweeted about a team I coached. They suggested to stop using Jira because they preferred their physical Scrum board and backlog over a digital tool. It was a joyful moment and I considered myself an awesome coach. However, next week, for a different program I will be setting up Jira again... But why??? Isn't the first value of the Agile Manifesto "Individuals & Interactions over Processes & Tools"? So why am I - an Agile Coach who takes his profession seriously - support using a tool such as Jira? (or any other tool that tracks things no one looks at). Well... the honest answer is... I don't have any alternatives... Life Was Great! My previous team that stopped using Jira was located on the same location. We've had our own team space. The Product Backlog and roadmap were visualized on a wall where everyone could see it. A physical whiteboard was used to track our Scrum Sprints. Every morning we huddled together for our Daily Scrum. During the day the tasks - written down on post-it's - would flow across the Scrum board. Transparency was all over the place, it was one big "inspect & adapt party". Life was great! A Common Misunderstanding So why use Jira? Well... the program I'm currently coaching consists of multiple teams working across different locations (in different countries)...A physical Product Backlog therefore isn't a viable alternative. The Product Backlog needs to be shared in a location that everyone can continuously access. That location will be Jira... Let's go back to the Agile Manifesto. Yes, the first value is "Individuals & Interactions over Processes & Tools". A common misunderstanding is the manifesto states that processes and tooling are evil. They are not. Processes and tooling are fine, but they should enable teamwork, collaboration and offer transparency. Processes and tools should encourage interaction between individuals. A physical Scrum board is a great tool that supports these elements. It visualizes the product- and sprint backlog, offers transparency about the progress and invites everyone to share possible impediments, improvements and success! Pitfalls of Using Jira Some pitfalls of using a digital Scrum board with the Product- and Sprint Backlog are: The Product Backlog becomes way too large to manage; Communication is done via the tool instead of face2face; The Jira workflow dictates the teams way of working; The Sprint Backlog is updated in such a way nobody notices any progress; Energy drops, the euphoric moment of a "done" item isn't celebrated anymore. Overall, transparency decreases and the inspection and adaptation that ignites improvement becomes more difficult. Transparency, inspection and adaptation form the core of Scrum. You don't want a process or tool that blocks the heart of Scrum. It's asking for problems! A Necessary Evil? But, as mentioned before, sometimes a digital tool might be necessary when working with distributed teams. Therefore I am going to support the configuration of Jira next week. To end this blog post a bit positive: at least I'm aware of the pitfalls... And I do have some ideas on how to make the best out of this situation. For example, using a large touch screen to visualize the backlog. Whenever the status of an item changes, encourage the team to update the status via the touch screen. It's almost like using a physical Scrum board. Let's just find a way of working that copes with the mentioned pitfalls in the best possible manner. Closing Do you recognize my struggle? Ideas on how to deal with them are more than welcome! Just sharing your experiences is also highly appreciated!

This week I got a question from a colleague about the Scrum Retrospective. She's Scrum Master of a team that for sure has room for improvement. But somehow, during the Retrospective nobody is really challenging each other and the burning issues aren't discussed. Therefore the Retrospective often results in defining only small improvements. So the question I want to discuss in this blog post is: How to spice up your Retrospective? I'll share some formats that helped me with this question. If you've got any other ideas: sharing them is appreciated! Please note: the ideas with an asterisk have a description taken from the Retromat book by Corinna Baldauf. 1. The Feedback Game The feedback game gives you an insight on your own personality and can be used to start an in depth conversation about each other’s attitude and behaviour. By using 140 cards with different characteristics you’ll be able to find an answer on questions like: What are my qualities? How do others perceive me? What are qualities that I want/need to improve? You can use the game for teambuilding, appraisals, coaching and counseling, career planning, development and personal strengths. I’ve used it for giving and receiving feedback within the Scrum teams I’ve coached. The game helped in creating a clear image of how a person sees him-/herself and how someone else perceives that person. It also clarifies how well a team can assess qualities of other team members. I’ve noticed the team found it quite difficult to assess each other and this resulted in some nice conversations. In this blog post you'll find a more detailed description. 2. Discuss the Team's Purpose A purpose is the reason for which something is done or created or for which something exists. A clear, inspiring and ambitious purpose will invite the team to continuously improve themselves. Without a purpose, the team is at risk to become Scrum zombies that only "mechanically" attent the Retrospective. 3. The Constellation Game* Place a sphere in the middle of free space and gather the team around it. The sphere represents the center of agreement. Move toward the center if you agree and outwards if you don't. Read out statements like: I feel I can talk openly in this Retrospective I am happy with the quality of our code I feel I'm part of the best team ever Afterwards, ask which constellations were surprising 4. Why Retrospectives?* Go back to the roots and start the Retrospective by asking "Why are we having Retrospectives?". Write down all answers and then post them for everyone to see. You might be surprised. 5. Expectations* Each team member gets a sheet of paper that's blank on the lower half and has 2 sections in the top half: What my team mates can expect from me What I expect from my team mates Participants fill out the top half for themselves. Afterwards they pass their paper to the left and review the sheet they got. In the lower half they write what they personally expect from the author, sign it and pass it on. After a full round, review and discuss expectations. 6. Writing the Unspeakable* Are there unspoken taboos holding back the team? Stress confidentiality. Announce the activity as silent and that all "evidence" will be destroyed afterwards. Hand each participant a sheet of paper to write down the biggest unspoken taboo in the company or team. When everyone's done, they pass their paper to their left neighbours. The neighbours read them and may add comments. Papers are passed on until they return to their authors for a last review. Then all pages are ceremoniously shredded. Use with caution! 7. Remember the Future* Introduce this scenario: "Imagine you could time travel to the end of the next iteration. You learn that it was the best, most productive iteration yet! How do your future selves describe it? What do you see and hear?" Give the team a little time to imagine this and jot down some keywords. Then let everyone describe their vision of a perfect iteration. Follow up with "What changes did we implement that resulted in such a productive and satisfying future?" Write down the answers on cards for the next phase. 8. Circle of Influence & Concern* Prepare a flip chart with 3 concentric circles, each big enough to put stickies in. Label them from inner to outer circle: Team controls - direct action Team influences - persuasive action System - response action Sort your insights from last phase into the circles. In pairs, the participants write down possible actions - preferably addressing issues in their circle of influence. They post their actions next to the respective issue. Agree on which plans to try, e.g. by each participant distributing 3 votes. 9. Follow Through* Let everyone draw an emoticon of their current mood on a sticky note. Then draw a scale on a flip chart, labeled "Probability we'll implement our action items". Mark "0%" on the left and "100%" on the right. Ask everyone to place their sticky according to their level of confidence in their follow through as a team. Discuss interesting results such as low probability or bad mood. 10. Choose a Different Location Choosing a different location for the Retrospective might do wonders. Leave the office for once. Choose for example a coffee bar, public park or even a boat as the location. A completely different environment really helps the team with brainstorming and defining out-of-the-box ideas. 11. Ask Someone Else to Facilitate the Retrospective Although the Scrum Master should support the team to continuously improve themselves, this doesn't automatically mean (s)he always the Retrospectives facilitator. I've got good experiences with asking other team members to think of Retrospective formats and host the session. It prevents the Retrospective to become the "Scrum Master Show" and gives you the opportunity to act more as a team member from within. Closing In this blog post I've shared some ideas on how to spice up the Retrospective. For sure there are lots of other formats that can be used. For example by using team assessments/checklists or creating a team manifesto. But because my favourite number is 11, I've only shared 11 ideas... If you've got any other ideas that worked really well: please share them!

Recently I published the whitepaper "The 8 Stances of a Scrum Master". It describes the Scrum Master as a servant leader, coach, facilitator, teacher, mentor, manager, impediment remover and change agent. The whitepaper contains my personal experiences as a Scrum Master and includes my most important findings while researching the 8 different stances by studying books, articles and videos. Currently I'm working as a Scrum Master for Amsterdam Airport Schiphol. Together with my fellow Scrum Masters we help each other improve fulfilling the role. Also we want to offer new Scrum Masters guidance and a structured approach in getting up-to-speed. Consider it a mentorship between Scrum Masters. Ideas for Using the Assessment The white paper with the 8 Scrum Masters stances can be used to offer Scrum Masters an approach to improve themselves: Read, or even better, study the white paper Assess yourself or each other using the "Assessment - 8 Stances of a Scrum Master" Determine your goal for the upcoming period Decide what your actionable next steps are for the upcoming week Plan a (bi-)weekly meetup with other Scrum Masters to challenge and support each other The assessment is a very lightweight tool. Maybe "assessment" isn't the right name because it doesn't have a comprehensive list of statements or questions. Just study the white paper and use your gut feeling and feedback from other Scrum Masters or team members to determine the score. My Next Steps The upcoming period I'll offer ideas on how to improve yourself as a Scrum Master taking into account one of the 8 stances. For example: What are practices you can try becoming a better facilitator? What are books you can read to learn more about coaching? What are ideas that can help you improve your teaching skills? As you might have noticed I'm using an incremental and iterative approach. First write a blog post for every stance. Merge it into a white paper. Create a lightweight assessment. Add practices, books and other ideas per stance. And maybe... just maybe combine everything into a book :-) Closing Of course I'm always curious about your ideas. Is this lightweight assessment useful for you? Would you consider it valuable when I add practices, books, and other ideas to improve yourself as a Scrum Master? Any other suggestions to take this to the next level? As always, feedback is appreciated!

According to the Scrum Guide, the Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant‐leader for the Scrum Team. He (or she) helps those outside the team understand which of their interactions with the team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand the spirit of Scrum. The Scrum Master Acts as a... Servant Leader whose focus is on the needs of the team members and those they serve (the customer), with the goal of achieving results in line with the organization’s values, principles, and business objectives. Facilitator by setting the stage and providing clear boundaries in which the team can collaborate. Coach coaching the individual with a focus on mindset and behavior, the team in continuous improvement and the organization in truly collaborating with the Scrum Team. Manager responsible for managing impediments, eliminating waste, managing the process, managing the team’s health, managing the boundaries of self‐organization, and managing the culture. Mentor that transfers agile knowledge and experience to the team. Teacher to ensure Scrum and other relevant methods are understood and enacted. Impediment Remover solving blocking issues to the team’s progress, taking into account the self‐organizing capabilities of the Development Team. Change Agent to enable a culture in which Scrum Teams can flourish. The white paper "The 8 Stances of a Scrum Master" contains my personal experiences acting as a Scrum Master. Besides these experiences, I’ve added my most important findings while researching the 8 different stances studying books, articles and videos. You can download the whitepaper here. I hope you enjoy the result! Learn More You can learn more about Agile & Scrum by: Attending a Professional Scrum training, powered by Scrum.org. Check this page for my upcoming courses. Exploring my Scrum toolkit with lots of articles, books, checklists, presentations, tools and videos I recommend.

On July 7th the Scrum community gathered in Amsterdam (The Netherlands) for the 5th edition of Scrum Day Europe. This years theme was 'the next iteration'. Therefore we looked back to see what Scrum brought us the last 20 years, but also looked forward into the future of Scrum. Naturally, the evaluation was done via a retrospective. The goal was to generate insights and define improvements for the Scrum framework from the Scrum community. Every participant contributed and provided input; thereby it proved to be a true community event! The 5 Retrospective Questions During the day we asked everyone to answer 5 questions: What has proven to be the strength of Scrum the past 20 years? What should be the focus of Scrum the upcoming 20 years? What of Scrum frustrated you the most so far? What connects you to Scrum? What is a small improvement that could be added to Scrum? In a series of blog posts I'll share the answers we've received on these questions. This final blog post will be about what the participants of Scrum Day Europe considered a small improvement to the Scrum Framework. I'll share the outcome of the Retrospective and my personal opinion. Of course I'm also interested in your point of view! The Suggested Small Improvements According to the participants, possible small improvements to the Scrum framework are: Adding the Definition of Ready to the Scrum Guide Adding an appendix to Scrum Guide with “what to do when…" Providing a Scrum starterskit for new colleagues Creating an EBM presentation for management/organization Offering practices to improve soft skills Creating an experiment canvas > hypothesis driven Introducing a strategy clock Humanizing the workplace Setting up a Definition of Fun Creating official profiles of all the roles based on ICT competency standards The Definition of Ready Out of all the suggestions made by the participants I would like to focus on the suggestion of adding the Definition of Ready to the Scrum Guide. It's a question I get during every Professional Scrum Training: "Why isn't the Definition of Ready described in the Scrum Guide?" First, let's clarify what is meant with the Definition of Ready. While the Definition of Done is used to assess when work is complete on the product Increment, the Definition of Ready is used to assess if Product Backlog Items (PBI's) are "ready for Sprint". Often the acronym "INVEST" is used as a checklist. PBI's are ready for Sprint when they are independent, negotiable, valuable, estimable, small and testable. Although such a checklist can be a useful instrument to improve the quality of PBI's, I'm not a big fan of the Definition of Ready. Quite often it becomes a contract - instead of a guideline - between the Development Team and the Product Owner. Only PBI's that meet the entire checklist will be selected for the Sprint Backlog. Basically the Development Team is using a sequential, phase-gate mindset which only increases unnecessary process overhead. Luckily the Scrum Guide offers a great alternative for the Definition of Ready: backlog refinement. Backlog refinement is the act of adding detail, estimates and order to items in the Product Backlog. Scrum uses backlog refinement as an activity to improve and clarify the Product Backlog. Backlog refinement is an ongoing process, therefore it's not restricted to an event but considered an activity. As a rough guideline, the Development Team spends 10% of their capacity on backlog refinement. A good practice is to have at least two sprints of PBI's ready for Sprint (clear, feasible, testable). To use Pacman as an example: when Pacman can’t ‘eat’ enough PBI’s anymore because they aren’t small enough, backlog refinement is necessary. Just enough, just in time. Everything with the goal to feed Pacman delicious 'ready' PBI's. Instead of using the Definition of Ready as a sequential, phase-gate checklist I prefer the activity of Backlog Refinement. Frequent refinement of the backlog creates a flow of Product Backlog Item readiness. Although it might seem a contradiction; I do support using a checklist that clarifies 'readiness' during backlog refinement. Mainly because during refinement such a checklist isn't used with a phase-gate mindset but purely to improve the quality of the Product Backlog. It's a small but important difference. So why isn't the Definition of Ready described in the Scrum Guide? Because it is. However not as a checklist but as an activity: backlog refinement. Closing This is the 4th blog post about the Scrum Day Europe 2016 Retrospective. In the first blog post I've described the strength of Scrum. The second blog post was about the desired focus of Scrum. The third blog post described the frustrations people experienced with Scrum so far. The fourth blog post offered examples of what it is that connects people to Scrum. This final blog post contains my view the Definition of Ready as a possible improvement to the Scrum framework. What is your experience with using a Definition of Ready? Do you think it should be explicitly described in the Scrum Guide?