September 28, 2020

Agilists

News for Agilists

Scrum isn’t meeting heavy — you just don’t get it. | by Davie Elliott | Serious Scrum | Jul, 2020


If we can agree to the above, then the next sections should hopefully convince you how essential each meeting in Scrum is, and how much value each event gives when building a product.

Recap of the Scrum Events

First, I want to do a recap of the events; who they’re for, what they’re for, and their timebox:

4 Scrum Events and Backlog Refinement

Let’s start with an easy one, the Sprint Retrospective

The Sprint Retrospective is for the Scrum Team to look back on the Sprint which has just finished, and identify improvements for the next Sprint. This isn’t just limited to the Development Team, this could be; how the events are run, that the Product Owner needs to supply more info on Product Backlog items, etc… Anything which means the team — as a whole — can improve their performance.

As a Scrum Master, regardless of what’s happening with the Sprint, with the Organisation, or the entire world — I will fight for the team to have a Retrospective.

If you are thinking “ we’ve hit the Sprint Goal, do we really need to do a Retrospective?”, or “do we really need a Retrospective, nothing went wrong?” then what you’re essentially saying is “we’re the best we’re ever going to be, we can’t possibly improve” or “I think my stuff went well, so I don’t need to improve”. I weep for you. In terms of maturity as a Scrum team, you’re really not there.

There will be times when you can’t think of a large improvement, but small improvements add up over time. There should never be a time when a team can’t think of a single improvement, no matter how small.

Also, I’d just like to point you to the Agile Manifesto:

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
– The Agile Manifesto

So, unless you have a Sprint Retrospective, you’re not Agile. End of.

Got my abs, now I don’t need to work out (Image source: https://medium.com/@Pareto8020rule/how-to-get-ripped-in-3-months-4926645ffbcf)

Next up, Sprint Planning

Sprint Planning is more than just shoving a bunch of Product Backlog Items into a Sprint Backlog. If this is all you’re doing in Sprint Planning, then I’m sorry, your Product Owner and Scrum Master need to level up. Also, how is saying “We’re going to do X, Y and Z” a plan exactly?

I’m going to take a trip to the Moon and mine Helium-3, please invest in my venture. What, you think I don’t have a plan? But I just told you my plan “I’m going to take a trip to Moon and mine Helium-3”. Oohhhh, you mean I haven’t said how I’m going to do this. Sorry, I thought just saying what I’m going to do was enough of a plan.

If you’re not breaking down those Product Backlog Items into work items, to say how you’re going to achieve the Sprint Goal, then I’m sorry, you’re not creating a plan.

I could have the brightest and most talented Development Team in the world, but until I see them create a plan in Sprint Planning, I’m sorry, I don’t have confidence they know what you’re doing.

Yeah, I’m not investing in your non-plan (image source: http://www.quickmeme.com/meme/3pbseb)

Sprint Goal

Secondly, if you don’t have a Sprint Goal, then you can’t create a plan on how you will achieve the Sprint Goal (Woah, a tautology). Not having a Sprint Goal is either pointing to the Product Owner needing more coaching or that the Scrum Master hasn’t managed to convince the Product Owner and Stakeholders why it’s important.

Why is the Sprint Goal important? Well, going back to my Moon mining example:

The what: I’m going to take a trip to the Moon and mine Helium-3

The how: I spoke to Elon, he’s happy to rent a fully fueled and piloted Falcon Heavy rocket for $3m, and it’s ready to launch on the 23rd. Caterpillar has a Helium-3 mining machine that they built as a prototype, and it can be attached to the rocket on the 23rd for another $5m.

All good to invest? What, you don’t know why I’m mining Helium-3, and how that will make a return from your investment? Sorry, I thought the plan was enough.

The Sprint Goal gives you the Why of the Sprint, what does the Product Owner want to get out of this Sprint, and how will it deliver value? Why should the company spend thousands on a Scrum Team beavering away for 2 weeks? What will they get in return?

The Sprint Goal is what gives the team focus — if there is something going on in the background (like an incident), or the business want to change direction, or there are non-Sprint Goal related items in the backlog — the team prioritise what they agreed as the Sprint Goal first.

Since we know the Sprint Goal tells us what value the customer will get at the end of the Sprint, I’ll just point you to this:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
– The Agile Manifesto

I’m not saying you’re not Agile if you don’t have a Sprint Goal… but it does align nicely with the first principle in the Agile Manifesto.

No Sprint Goal is like burning money (image source: https://medium.com/@craig_10243/coin-burning-for-dummies-baa3cd14f915)

Speaking of stakeholders, now let’s discuss the Sprint Review

The Sprint Review (in my experience) is a heavily misunderstood and underutilized event in Scrum. If I’m paying for something to be built, you’re damn straight I want to know; if you built it right, if it’s giving the amount of value I thought it would, and also why you’ve chosen the direction for the Scrum Team to build the product in.

If your stakeholders aren’t coming to your Sprint Reviews, then this usually points to these major flaws; your stakeholders don’t care, meaning your organization hasn’t fully adopted Agile, or the team is doing something which is making the stakeholders think the Sprint Review is pointless — like not building vertical slices of functionality.

If you’re doing everything you can to get your stakeholders to attend, and they don’t care… then I question not only if Scrum is the right framework for you, but if returning back to a waterfall methodology would be best. If stakeholders don’t care about what you’ve built, why would they care that you’ve built something in only 2 weeks instead of 2 years?

Side rant to people who say “Scrum doesn’t work”

Scrum works, it works really well; right now I’m the Scrum Master of 2 teams, and I have absolutely no reason to change frameworks. But Scrum doesn’t fit all organizations and all teams. Saying “Scrum doesn’t work”, just because your organization or team hasn’t adopted it properly, is like saying football doesn’t work, just because you can’t play football well.

Scrum is more about behaviors than it is about process.
— Scrum A Smart Travel Companion by Gunther Verheyen

Back on track

The Sprint Review is not just a demo.
The Sprint Review is not a meeting for the Product Owner and Stakeholders.
The Sprint Review is not a meeting for when you meet the Sprint Goal (or the entire Sprint Backlog, if you’re a beginner Scrum Team).

The Sprint Review is the time when Stakeholders can not only see what you’ve built but, also find out if you had any problems along the way that will delay them obtaining their value. It’s also an opportunity to demonstrate that the team knows exactly what it’s doing by explaining to the stakeholders why they chose what to build this Sprint, and why it’s chosen what to build next Sprint.

If you do actually care about what you’re building, you should relish the opportunity to hear what the people paying you to build the product, think of what you’re building. Again, if you don’t actually care about what you’re building and are just shoving features out the door, maybe Scrum isn’t the right framework for you, and again, maybe returning back to a waterfall methodology is the right way to go.

And lastly, it’s a perfect opportunity to be transparent with your Stakeholders, if you had issues or you didn’t hit the Sprint Goal, let them know! Not being fully transparent, or trying to hide things is potentially going to create mistrust between the stakeholders and the Scrum Team.

I’d also go as far to say if you don’t have something like the Sprint Review, you’re not Agile:

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
– The Agile Manifesto

and

Customer collaboration over contract negotiation
Responding to change over following a plan
– The Agile Manifesto

Who cares about the product? Just get it into production (Image source: http://polarsip-dv.ru/uploads/gallery/eco/2.jpg)

Now for my favorite, the Daily Scrum

Why is this my favorite? Because it should be a key event for the Development Team. I spend a lot of time coaching my teams on how to run an effective Daily Scrum.

Firstly, I have to stress this; the Daily Scrum is for the Development Team. It is their meeting, they should run it, they should be the attendees.

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
– The Scrum Guide

If the Development Team waits for the Scrum Master or Product Owner to turn up, or they decide not to run the meeting because these people aren’t in the office, then this is an anti-pattern.

Now, I’ve come across talented developers who say things like “I don’t care what you did yesterday, or what you’re doing today, therefore I don’t see the point in this meeting”.

Well, this meeting isn’t a status update.

The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work.
– The Scrum Guide

Also, if there are only two people in the Development Team, yeah you probably don’t need a Daily Scrum:

Fewer than three Development Team members decrease interaction and results in smaller productivity gains.
-The Scrum Guide

I coach my teams to look at the burndown chart, work out how much work they need to burn down to stay on the ideal line — and thus have a higher chance of meeting the Sprint Goal — then create a plan around that.

If you don’t think there is value in creating a daily plan on how the Development Team will progress towards achieving the Sprint Goal, then you either don’t care if the team succeeds or not, or you’re placing real faith that; everyone knows exactly what they’re doing, no one is going to step on anyone else’s toes, and there’s going to be no undiscovered work —and thus you don’t care if the team meet the Sprint Goal or not.

I don’t care what anyone else is doing, just let me code (Image source: https://www.bodylanguagesuccess.com/2012/07/nonverbal-communication-analysis-2055.html)

Oh, and I’ll just leave these here:

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective then tunes and adjusts
its behavior accordingly.

Individuals and interactions over processes and tools
– The Agile Manifesto

Not saying you’re not Agile, but the above lines up nicely with the Daily Scrum.

Lastly, Backlog Refinement — the only meeting, which isn’t a Scrum Event

I’m going to avoid ranting at; Planning Poker, User Story, and Story Point bashers here (suffice it to say, these are not part of Scrum — show me where it mentions any of these in the Scrum Guide). I’ll leave that for another time. If you don’t think you get anything out of Backlog Refinement — go ahead, don’t have it.

I’m sure it’s fun for the Development Team when the Sprint Planning is the first time they see Product Backlog items and have to design a system right then and there.

I’m sure it’s fun for the Development Team when the Product Owner pushes Product Backlog items onto them and expects them to be delivered in the Sprint without any understanding of the requirements.

I’m sure it’s fun for your Product Owner when he/she can’t give stakeholders an idea of when things will be delivered (or he/she makes dates up!)

I’m sure it’s fun for your stakeholders when you didn’t build what they asked for.

I’m also sure it’s fun when requirements start to balloon after the Sprint has started, and delivering the Sprint Goal is looking futile.

Tell me then that there’s no value in Backlog Refinement.

I imagine there are some teams that don’t need to have Backlog Refinement meetings (or very few), but they will be mature Scrum Teams, which have a really good understanding of the customer and/or the market, or the Product Owner and Development Team have a really good relationship, and Product Owner knows the exact amount of detail to put on the Product Backlog Items.

During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done.
-The Scrum Guide

As usual, I’ll just leave some Agile Manifesto advice:

Business people and developers must work
together daily throughout the project.
-The Agile Manifesto

Users changing requirements? Surely this never happens. (Image source: http://www.stupendous-stuff.com/humour/best-of-dilbert.php?comic=coders_everyday_nightmare)

Mic drop

Now tell me Scrum is too meeting heavy.

Mic drop! (Image source: https://www.youtube.com/watch?reload=9&v=Dp0Lk03cVvE)



Source link