4 reasons why you are bored by Scrum events (and how to get over it)

Door Patrick Verheij

“Great teams never bore anyone”. That should be a guiding principle for any team that strives to be great. Nevertheless, I still meet way too many so called “agile” teams where team members are bored.\r\n\r\nThey are bored by the Scrum events: Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective. Most people are especially bored by the so called “refinement meeting”.\r\n\r\nWhy? Well, I’ll show you four reasons which I observe in practice. Plus I’ll tell you what you can do to initiate the cessation of boredom :-)\r\n\r\nLet’s go!\r\n\r\n1. Your team isn’t delivering enough value\r\n\r\nMost people want to get shit done. They want to contribute. They crave to deliver value and be valuable. They wish to feel worthy. But alas, they don’t. Not in your team. They feel mostly useless. And perhaps you feel the same.\r\n\r\nScrum events are not producing any value in itself. Not customer value that is. So you get bored because these events don’t contribute to your desire to feel valuable. Or better: to feel busy. It just doesn’t feel like real work. After a while even the Retrospective events become boring because valuable learnings don’t translate to more customer value.\r\n\r\nSo now you wish the Scrum events to be as short as possible and get back to work quickly. Even though that work may not be very valuable in itself, at least it gives you the feeling of being busy. And that feels valuable because you trick yourself into believing that being busy equals being valuable. Now you get shit done! That feels great!\r\n\r\nTrying to make the Scrum events less boring isn’t the point here. That would just mask the real problem. The real problem here is that your team isn’t focusing on creating value. Fix that problem now! Fix it by planning to create working software. Invest in a decent definition of done and then get real work done. Commit to creating value NOW instead of just getting pieces of the cake done and then hope it will all work automagically after a couple of months.\r\n\r\nSounds too cumbersome? Then reconsider your wish to become agile and just hope your organization doesn’t go down while you work there.\r\n\r\n2. Your Scrum events aren’t facilitated very well\r\n\r\nThis one would be the least of your problems: if your team focuses on being valuable, you will plough through the muddy events anyway and get results. Alas, you probably don’t.\r\n\r\nThat’s why you need someone who asks some decent questions:\r\n

    \r\n

  • During a Sprint Planning event: What change do we wish to create this sprint? What would be our sprint goal? Which risks should be address because they prevent us from creating value? Does everything on our backlog translate to value? What story do we wish to tell our stakeholders after this sprint is done?
  • \r\n

  • During a Daily Scrum event: Are we still gradually building a potentially shippable increment? What did we learn yesterday that can help us improve today? What changes do we need to make to our plan right now to meet our sprint goal? Can we do more than expected without compromise?
  • \r\n

  • During a Sprint Review event: What difference did we make? Did we deliver value for money? Does whatever we delivered meet your expectations, dear stakeholder? How does this result help you? What is lacking? Shall we keep following our roadmap or do we need change our path? What benefits should we deliver next?
  • \r\n

  • During a Retrospective event: What gave us most energy last sprint? Have we been honest to each other? What do we need to stop doing to be much more effective? Why haven’t we still fixed this impediment and what will we do about it right now?
  • \r\n

\r\nIf such questions would be asked, would you then still be bored?\r\n\r\n3. You attend many other events outside the Scrum events\r\n\r\nSo we “do Scrum”. We do some planning, fill the Sprint Backlog, beautify the Planning Board with lots of colourful tasks, start the sprint aaand…immediately lose focus.\r\n\r\nWe work on stuff on the Sprint Backlog of course. But not everything on the Sprint Backlog has any relation to our Sprint Goal (if we even have any). And then some work is not even on the Planning Board (if we even have one that is fully transparent and available all the time).\r\n\r\nMany people in Scrum teams still work on all kinds of different “side projects”. These side projects require our attendance. Usually that means “meetings”. Plenty of them. We attend them reluctantly, but nevertheless we do. And then we get bored. So bored that we get bored of any meetings, including our own Scrum Events.\r\n\r\nSometimes we aren’t working on side projects but are still required to engage in boring meetings. This often has to do with “dependencies”. Because we depend on other people and other people depend on us, we need not only to wait a lot but often also (again) attend meetings to align and to report.\r\n\r\nThere is no easy solution to this problem. You can try to eliminate the meetings by discovering better ways to align and report. Your better bet would be to gradually or abruptly eliminate all side projects and most dependencies. Working towards becoming autonomous as a team, that is. But that’s called an “agile transformation” these days, which is not an easy thing.\r\n\r\n4. Your team values doing tasks over creating value\r\n\r\nWe revisit value creation in this fourth and final reason why you get bored of your Scrum events. Your team isn’t delivering enough value, but now there’s a reason why: you value tasks over outcome.\r\n\r\nI see many so called “agile” teams consist of a bunch of specialists who hardly collaborate, Oh yes, they are all on the same team. And oh yes, they usually all attend the Scrum events. But that’s about it.\r\n\r\nThese “teams” are often nothing more than a bunch of people sitting together and looking at the same Planning Board. Each team member has their own tasks. In most cases, the User Stories are written in such a way that they can be fully done and delivered by a single person. These are so called “design stories”, “UX stories”, “dev stories”, and often even “Ops stories”. .\r\n\r\nSo now any Sprint Planning event will be boring because nobody really cares about each other’s stories and Planning Poker becomes a guessing game resulting in a Sprint Plan which is pure fiction. Daily Scrums don’t make sense because everybody is just there for their own sake. And refinement? Well, usually I see the IT guys sit together refining their stuff and the rest of the team does their part on a different occasion. When somebody forces them to sit together, energy levels are dropping fast. For a good reason of course.\r\n\r\nFor any solutions to this problem, I revert to the solutions I gave earlier considering value creation. You really should start creating requirements (User Stores if you wish) that express potential value instead of just chunking up work. This should help people understand the bigger picture of wat the team is trying to accomplish. Hopefully they will then get more interested in other work than just their own because they are now forced to collaborate to get anything done.\r\n\r\nFinal thoughts\r\n\r\nIf you read this and you think “geez, isn’t this the stuff teams suffered from 10 years ago?” then I salute you. Congratulations for being in a great team!\r\n\r\nIf not, I hope my ramblings help you get some change going. Because you need it if you want to keep bragging that you are “agile”.\r\n\r\nEnjoy!

Patrick Verheij

06 59 443 447

Andere posts

Klik hier