The Retrospective

The Sprint Retro is a key part of any scrum team which is looking to improve its process and adapt its ways of working to continuously improve. As with any adaption the key is transparency, the the more information the team can gather throughout the sprint around impediments or challenges they’ve faced the better. Personally I like to create a retrospective board at the start of a Sprint so team members can add their thoughts to the board as the sprint evolves rather than looking back (which always favours things which happen in the last few days).

The main challenge with the Retrospective is to avoid it turning into a moaning or helpless session. From The Scrum Guide:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Guide 2020

Scrum Masters use a wide variety of techniques to support gathering information about the sprint including anyonmous submissions, “What Went Well vs What Didn’t Go Well”, and often scenarios involving rockets or icebergs. However, it’s important to remember that the Retrospective is a working session to give the team some concrete actions on what they can do to increase either Quality or Effectiveness (or, ideally both). While having a good rant about something which went wrong or something which impeded them can be therapeutic unless an action is taken to lean from that then neither objective should be met.

Teams must look at how to improve and adapt to challenges, not just moan about what got in their way.

This kind of adaption is not easy. It requires teams to look honestly at what’s happened and see what they could have done different, this kind of self assessment takes real courage and for the team to have a real growth mindset. It’s the delicate role of a Scrum Master to balance between criticising what the team should have done and coaching them to look for alternative strategies of what could be done in the future.

Its easy to say that a Sprint Goal failed because X in the infrastructure team. It’s much harder to reflect on what the team could have done to prevent that issue arising. It requires taking acountability and to avoid casting other people as villains.

In earlier versions of The Scrum Guide the team were required to add at least one action to the next Sprint Backlog, however it is now recommended to be properly alongside other work.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Scrum Guide 2020

The Sprint Retrospective requires the three pillars of empirism to be effective however this time they must be focused inward, at what the team could change or could have done differently. It also requires the Scrum Values to be first and foremost in everyone’s mind. Impediments can come from within the team as often as outside it and we rely on our courage and respect to get us through those tough conversations.

Please feel free to post in the comments below of any retropectives which have worked really wel for you in the past, it would be great to read about them.

The Sprint Review

The Sprint Review is an invaluable session to demo progress, engage stakeholders, and discuss what to do next. However, in my experience mist teams don’t take full advantage of the session.

The Scrum Guide says

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

The Scrum Guide 2020

In other words the review is a chance to take a step back and look at the increments which have been completed during the sprint, consider the product goal, and decide the next short term objective.

This should be done in full view of stakeholders, the more transparency the better because this is how we avoid waste and poor quality.

Sharing work with clients and stakeholders is daunting but it’s far better than building the wrong thing.

Personally I’m always worried when I hear teams ask “Do we have anything to demo?”. This often implies to me that they think of the Sprint Review as a presentation of progress rather than a working and planning session. Furthermore, a scrum team should aim to release at least one increment, no matter how small each and every sprint so keep an eye out for these warning signs.

The Scrum Guide reminds us that:

The Sprint Review should never be considered a gate to releasing value.

The Scrum Guide 2020

It is far better to think of the Sprint Review as an opportunity to recap what has recently been completed (if not deployed) and a chance to engage with stakeholders on what should be done next.

Daily Scrum

Last week we talked about the Sprint Planning session, today I’m going to move on to one of my favourite scrum events. The Daily Scrum.

The fifteen minutes each day where the team catch up are some of hte most powerful, but also some of the most woefully misunderstood of all the scrum events.

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Scrum Guide 2020

In other words the entire purpose of those 15 minutes is to review the team’s progress against the Sprint Goal and ensure that they are still on track. They should consider progress, any new information they’ve discovered, and any risks they’ve found and discuss if any change of strategy is required to hit the Sprint Goal.

The Daily Scrum is about verifying progress against the Sprint Goal. Photo by cottonbro on Pexels.com

The Scrum Guide also says

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

The Scrum Guide 2020

However, more than in almost any other event I see zombie scrum going on in Daily Scrums. In team after team, company after company I see teams standing up around a screen answering the dreaded three questions “What Did I Do Yesterday?”, “What Am I Doing Today?” and “Do I have any Impedements?” (by the way – 99% of the time people apparently don’t).

While there’s nothing wrong with this approach there’s something seriously amiss if the team do not circle back to address the main point of the meeting. Given the raw data we’ve captured from the team on their progress and their blockers do we still believe we are capable of meeting the Sprint Goal? Has something someone has said put that in jeopardy and what can the team do adapt.

The Daily Scrum is the daily iteration of the inspect and adapt pillars of empiriscm (which only works if there is a feeling of safety in the team which creates transparency). Instead of simply waiting for their turn to write the three questions developers should be listening to each other’s answers and looking for indication that the team may not meet it’s objectives.

Don’t be afraid to mix up the Daily Scrum format, but do be very nervous if you’re not discussing the Sprint Goal in each and every meeting!

Sprint Planning

Last week we talked about the Sprint. This week we’re going to kick off with Sprint Planning. The Scrum Guide defines Sprint Planning as

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

The Scrum Guide 2020

It recommends you do this by answering three questions. How is this sprint valuable? What can be done this sprint? How will the work get done?

In my experience most scrum teams by estimating Product Backlog Items, or PBIs (often called User Stories) and estimating how much work they can deliver by looking at their historical velocities.

This, in my opinion is wrong.

When teams do this it’s very easy for them to let the work drive the goals instead of the other way around. Rather than identifying what they want to achieve and working out how to deliver it they look at lots of granular pieces of work and cram as many into the sprint as possible, often losing synergy and coherence in the future.

It is always better for a team to look at what they want to achieve and what the various people can do to make that happen than to try and assign particular tasks to each person. This sometimes means that people’s capacity isn’t 100% utilised. But that time is infested in collaborating, learning, paying down tech debt, and supporting their team mates who are on the critical path. Far better than having everyone so stressed by an arbitrary deadline because some random user story was included in a sprint.

Working out what to include, or not include in a sprint is never easy

A team should always identify the next step forward for their product, the one which would yield the most value and plan the work required to meet that goal. They can use estimates to assess whether a particular plan for doing it is feasible. They shouldn’t focus on trying to fill up a quota of story points from estimates of varying accuracy.

It’s the PBIs which are planned to meet the sprint goal which we will use to verify our progress in the Daily Scrum sessions. This will be the subject of next week’s post so make sure you’re following the blog if you want to read it!

The Sprint

I am currently studying with a view to attempting my PSM-III, if I stand any chance of passing I need to go back to basics to make sure I have a rock solid understanding of the fundamentals. With that in mind for the next few weeks I’m going to go back to core scrum and share my views on some of the fundamentals.

You can’t get a lot more fundamental than the sprint. The scrum guide defines a sprint as

Sprints are the heartbeat of Scrum, where ideas are turned into value.

The Scrum Guide 2020

In scrum we plan work in timeboxes, usually 2-4 weeks. By working to a much shorter planning horizon we can gain a lot of confidence as we go by reviewing progress frequently and adapt as required as the project goes along.

It is not a release schedule!

Many teams I have worked with attempt to set their deployment schedule with their end of sprint. These should be entirely coupled, DevOps has lots of good ideas about how and when to deploy. Deployments should be done as required throughout the sprint.

The sprint is about setting a goal and a timebox to achieve it. By having a consistent length of sprint we can gain confidence in the amount of work which can be delivered by looking at how much has been achieved in previous sprints. This is the purpose of velocity and estimation (a useful tool, if not a scrum process).

During the sprint:

● No changes are made that would endanger the Sprint Goal;

● Quality does not decrease;

● The Product Backlog is refined as needed; and,

● Scope may be clarified and renegotiated with the Product Owner as more is learned.

The Scrum Guide 2020

In other words the team should focus on the objective of the sprint (the sprint goal) and not get distracted and put it in jeopardy in favour of other work.

Quality should be at least as high at the end of the sprint as it is at the beginning, one or more increments of work should be completed should be produced and all should meet the Definition of Done. If it isn’t “Done” then it shouldn’t be included and may be picked up in the next sprint. Testing phases and hardening sprints are categorically not scrum. Each price of work should be a high quality, done, potentially shippable increment.

Refinement of upcoming work and investigation of planned work continued as time goes on. Remember a sprint goal can be achieved even if the method and approach is refined as the sprint goes on.

So how long should a sprint be? This comes down to the development team in question. Generally a more work can be done in a longer sprint, however there’s more risk that something will arise which would invalidate the sprint goal. For this reason sprints should not be longer than one month.

Finally, if at any point the sprint goal becomes invalid the Product Owner may cancel the sprint. This could be for a number of reasons. The priority of work may have changed dramatically due to customer needs or the discovery of a bug (shorter sprints help prevent the waste of cancellation here). Or, the team may discover as they progress that the goal is impossible or not as valuable as originally believed. We’re in the business of doing effective work. If we discover that work isn’t going to be valuable our job is to avoid waste and move onto something which would be.

There’s probably a lot more I could add but hopefully it’s a good introduction. Do follow along for the rest of the series, next week will be Sprint Planning!

Two “Magic Rules” for Achieving Great Things

Ok, I lie – but it got your attention.

This week I want to talk about the two most important rules you can follow if you want to deliver great work and hit goals. Regardless of whether they’re software projects, books you want to write, or exams you want to pass. They are utterly underwhelming…

Rule 1: Start doing it

Rule 2: Keep doing it until you finish

There you go, I told you they were underwhelming!

However, I want to go a little deeper (otherwise this would be a very short post).

Failure to start is one of the biggest reasons people don’t do things. How many times have you planned to do something one evening only to get home and fail to do it? The reason (according to James Clear in his book Atomic Habits) is because it takes energy and effort to start doing things. Far too often our brains follow a pre-programmed pattern to avoid decision fatigue. Do you want to go running tonight or watch television? What do you need to do to start running? You’ll need to get changed, then you’ll need to find your trainers, then you’ll need to actually do the running… oh, and then there’s the shower. But the TV remote is just there.

In his book James describes ways to reduce the friction required to take on these individual habits and actions and make them easier to do day to day. I do this myself. I want to listen to audiobooks each day, so I leave my headphones by the side of my bed so they’re the first thing I pick up each morning. If you want to go for a run after work then put your kit on your bed before you leave in the morning – or even better put it on before you leave the office so it’ll actually be more effort not to go for a run than it will be to just get out the door!

Photo by mentatdgt on Pexels.com

Once you’ve got started that’s a huge step forward. But a single run doesn’t make you fit. A thousand words doesn’t make a book. So how do you keep that momentum going day after day to make progress until the work is done?

The first step is to understand what “Done” is. Is there a done? If it’s about fitness then you may be looking for a particular weight or time, but you may also be looking to maintain. If you’re building a product you may be looking for a number of active users. Just like in product management and software development we should always be clear about what we want to accomplish before we set off. We can evolve that view, but it helps to act as a beacon.

This leads directly into the motivation question. If we understand our objective we can track our progress towards it. Visibly seeing our progress towards a concrete goal is a very powerful motivational tool (as well as the other benefits of transparency and adaptibility). Burn up charts for your personal goals may seem like overkill, but they’re really not.

Here’s my burn up chart for my reading goal (you can see I actually made the goal far more ambitious because I was doing so well).

You can see I’m doing something similar with my cloud computing exams. This one isn’t going so well, and what am I going to do about it? Revalidate the goal, recalculate the effort and expectations, and then really myself. As with all things agile create transparency, inspect, and adapt.

I know this post started a little tongue in cheek but hopefully it helps and has provided some valuable tools to meet your own goals. Don’t forget, start… and then continue until you are done!

A Talk about Goals

I was recently lucky enough to give a talk about Goals at the Hainton’s Community Group (currently online). Rather than doing a blog post this week I thought you’d enjoy this.

.A huge thank you to Tom and the team at Hainton as well as the participants for coming along and listening to me. It was really exciting to hear what people had planned and how they were getting on.

What goals are you planning? Drop me a message or comment below!

What I’ve Learned Since Writing Code Black

Last year I finished wirint Code Black and published it on LeanPub. It wasn’t an easy challenge, although I enjoy wiriting I’ve never written a technical book before and had never really self published anything.

This week I wanted to share some of the lessons learned since writing the book which I took into my current project Donuts and Dragons.

Lesson 1 – You’re going to sell a lot fewer copies than you think you are! I had plans of the book becoming a runaway best seller, and to be honest I’ve genuinely been overwhelmed by the positive feedback I’ve recieved (even some suggestions I should enter it into competitions). However, I’m still working as a Dev Manager and have no plans of retiring and living off the royalties just yet.

Lesson 2 – Scheduling a “writing day” doesn’t work. Firstly, it’s too much to expect yourself to write for 8 hours straight. Second, if something cancels that day then you’ve lost a lot of potential words. The best way to write is to a schedule. When writing D&D I set myself a goal of about 500 words every week day. The book doesn’t appear overnight, it appears incrementally and inevitably.

Lesson 3 – Plan what you’re going to write. Maybe this comes down to personal style? Or maybe it’s because both of my books are trying to teach rather than just entertain but I would have got completely lost if I hadn’t had my trusty outline. Procrastination occurs most often when you don’t know what you’re going to write, having a plan – even a high level one makes it easier to hit that word goal.

Lesson 4 – Be proud of what you’ve done. When I first released Code Black I found myself belittling it. When someone said “Adam’s written a book” I’d say something like “Yeah, but it’s only a self publish.” or “Yeah, but it’s not sold many copies.” Don’t put yourself down, you wrote a book. That’s amazing, it’s something millions of people want to do but few ever actually succeed. Don’t you dare undermine what you’ve done.

Lesson 5 – You’ll want to write another one. Writing a book is a lot like doing a marathon. At the time you’ll swear blind that you never want to do it again. Then your mind starts ticking and you starting having those ideas and before you know it you’ll be developing characters and outlines again. Why not!? You’re an author now!

Oh, and something a lot of people ask me what has been my proudest moment since publishing it? That one easy – when Gene Kim bought a copy!

There’s a certain irony that the characters in my book read The Phoenix Project, I do hope he smiled at that.

Have you written a book? Tech or otherwise – please share it with me, I love to read what other people have done!

Radical Candor Book Review

Radical Candor, by Kim Scott is a book I’ve been aware of for a while but haven’t actually got around to reading.

I was expecting lots of information about giving feedback but I was pleasantly surprised that there was a lot more in there than that.

Scott discusses that to be great leaders and team members we must both care personally and challenge directly. Without these two qualities we fall into one of three other quadrants.

Feedback & Radical Candor | Our Simple Approach To Guidance

People who care but don’t challenge fall into Ruinous Empathy. These are the people who won’t tell a friend that they’re unzipped because they’re afraid of the conversation. They’d rather let their friend continue to embaress themselves rather than push themselves out of their comfort zone.

People who don’t care personally are split into one of two categories. If they do challenge but don’t do it with someone elses best interests at heart then they display obnoxious agression. Or, simply put are just jerks. If they don’t challenge then they see what they could do to improve and don’t do anything to help them. This is manimulative insincerity.

Scott teaches us that we must always strive to give direct feedback to people we work with because we care about their success and their feelings. She also discusses lots of ways to do that.

I’d been expecting much of this content before I started the book but what delighted me was the actionable advice on how to go about this. I want you to read (or listen) to the book so I won’t give it all away here (plus, you know, plagurism). Suffice it to say that if you do now feel you should give feedback there are lots of tips in there to help.

But this is just for managers right?

Wrong!

Kim discusses that everyone should feel they can give feedback. Peer feedback is one of the most valuable thing we can give, it shows we care about our colleagues.

So, would I recommend it. Absolutely – go and have a read. Stop being ruinously empathetic today and start supporting your friends and colleagues directly!

Waltzing With Bears Book Review

I recently read Waltzing With Bears by Tom DeMarco and Timothy Lister, these are the same guys who wrote Peopleware so I was curious to give it a read as I found Peopleware useful, if a little dry.

Buy Waltzing with Bears by Tom DeMarco With Free Delivery | wordery.com

Waltzing with Bears is all about managing software risk. Specifically the risk that something will not be delivered on time. The example the pair give early in the book is an airport which couldn’t open because the software to operate the baggage carousel wasn’t working. A late software delivery had huge financial impact.

In the book the authors talk about different ways to identify, represent, and manage risk. Like their other book Peopleware Waltzing with Bears is very comprehensive walk through of software risk covering a lot of the basics as well as some really interesting topics such as how to show delivery dates in a graph format to show the earliest possible, most likely, and worst case delivery dates. Thereby giving far more context than a best guess (which as we all know has a bad habit of being communicated to clients and becoming a deadline).

The authors made a very nice point about the bold being the ones who start projects early, not the ones who set ambitious deadlines and expect people to hit them.

However, I couldn’t help feeling like the authors were missing a big piece. The entire book (which I admit isn’t a long one) is based around delivery date risk. There’s no mention of many of the other risks which software teams face including usability, tech debt, and the ever present security risks. I would have liked to have seen more (well, any) pages dedicated to risks which aren’t about the due date. I felt like we were given a comprehensive introduction, but at the expnense of a breadth of knowledge of how to manage other risks.

Overall a good book which is well worth a read to anyone getting started in project planning and wants to understand how to manage the risk deliveries will run late. However, only a 4* read for me.

What do you think? Have you read Waltzing with Bears? Post your comments below!