Taking a Break

After some consideration I’ve decided to take a break from blogging. I’ve really enjoyed writing the articles and posts I’ve published over the last couple of years. However I’ve been finding it increasingly difficult to come up with new and interesting posts week on week. I’d much rather post quality content more periodically than dull and boring posts over and over again.

I’m currently working on a Donuts and Dragons short story not to mention some more scrum learning and exams. I’ll post updates as I have them.

However, if you’d like to get in touch just drop me a message on Twitter or as a comment, more than happy to continue help and support the scrum and devops communities.

Time to give blogging a bit of a rest for a while!

Five Books to Revisit

I’ve probably mentioned before that I try to read or listen to The Phoenix Project each year. Each time I pick up different things and, although rather dated now, I believe it’s still one of the most important books in our industry.

This year I’ve decided to take things a little further and run over five key revision books and listen to them back to back. My greatest hits if you like of what I feel are the cornerstones for current software development without digging into the actual code. In no particular order my books are:

The Phoenix Project

As I mentioned above TPP is one of the most important books of recent years for our industry, it’s a great introduction into devops and the idea of system thinking and should be required reading for anyone in a software development role. Lets skip over the bit where they consipire to conceal a huge customer data breach from the auditors.

The Unicorn Project

The Unicorn Project came out much more recently and tells The Phoenix Project from the perspective of Maxine, the developer who caused the payroll failure which kicked off the story. The Unicorn Project talks about the value of paying down technical debt, decoupling systems, and architecting for sustainability. It evangelises functional programming a little too much for my liking and Eric calls everyone “sensei” but it’s a very valuable and enjoyable read.

Accelerate

Ok, The Phoenix Project and The Unicorn Project are fun stories about DevOps. This is data and proof. Nicole Forsgren is a PhD, research is her day job and she was the driving force proof between The State of DevOps reports for years. In this book they delve into industry best practices and categorically prove that they lead to not only better development team satisfaction and performance but better business performance.

Accelerate: The Science of Lean Software and Devops: Building and Scaling  High Performing Technology Organizations: Amazon.co.uk: Nicole Forsgren,  Jez Humble: 9781942788331: Books

Rolling Rocks Downhill

You’re going to be surpised by this one but I REALLY like Rolling Rocks Downhill by Clarke Ching. It talks about many of the similar ideas of the previous three books on my list but goes into much more detail around the financial benefits and priortising options of working in an agile manner. It’s also actually really funny, I find myself chucking all the way through – something which is very rare in a technical book!

Drive

I wanted to go for something different for book number five. There were some VERY strong contenders including Team Topologies, Radical Candor, and The Lean Startup. I also can’t really list my own books… so I finally settled on Drive.

If you’ve not read any of Dan Pink’s books before they’re worth a look. He typically looks at a particular psychology idea (in this case motivation) and discusses it in nice accessible language. He’s very good at translating scientific research into business and layman’s terms.

In Drive he discusses many of the key elements which are required to keep employees motivated and happy and, shockingly many of those same aspects line up with the research conducted by Nicole Forsgren and advocated by Erik in Gene Kim’s books.

Drive: The Surprising Truth About What Motivates Us eBook : Pink, Daniel  H.: Amazon.co.uk: Books

What do you think to my five revision books? What have I missed which I really must read next? I’d love to hear in the comments below or on Twitter.

Book Review Hyperfocus

I recently listened to the audiobook Hyperfocus by Chris Bailey it was an interesting read. One I’d recommend if you’re interested in minimising distractions and focusing entirely on single tasks.

Hyperfocus: How to Be More Productive in a World of Distraction:  Amazon.co.uk: Bailey, Prof Chris: 9780525522232: Books

The book talks a lot about minimising distractions. Muting mobile phone notifications, only checking email periodically and all the other stuff you’d expect in a book about productivity.

What I liked though was the discussion around intention for attention. By sitting down and defining what we intend then we can single task on that and ensure it’s delivered. Giving 100% of our attention to whatever we’re intending to focus on. If that’s watching a television programme with a loved one then do that, if it’s reading a book then do that. It’s only be defining the intention of our attention that we’ll ensure we’re effective in what we’re doing. Obviously this isn’t as easy as it sounds and Chris Bailey gives lots of suggestions of how to achieve this.

The other thing he focuses on is scattered attention. Hyperfocus is ideal for when we are mono-tasking on a particular task, but he discusses the benefits of letting out mind wander to capture random thoughts (he calls these unclosed loops, a phrase coined from Getting Things Done I believe) and to find to solutions to problems. Bailey argues that it’s only by creating space for our mind to wander and capturning those wanderings we can unlock the power of scatter focus.

Overall the book was a really interesting lesson, probably not up there in my top 3 productivity books of all time but a few interesting ideas and worth a read if you’re into that kind of thing.

Have you read Hyperfocus? What did you think of it?

Goals for 2022 and a Review of 2021

If you’ve been following this blog for a while you’ll know by now that as well as Scrum I’m a huge fan of goals, personal development and productivity. I mentioned recently that I don’t believe in annual goals. However, I do feel that it’s important to look back on what we achieved through the last year and what’s coming up.

I did something similar last year and gave myself the following goals for the year:

  • Read 21 Books – currently sat on 103
  • Write 52 Blog Posts – So far I’ve posted every week (plus a few more for the junior developer series I wrote)
  • Pass my PSM1 – Actually I’ve passed my PSM-I, PSM-II, PSM-III, PSD-I, and SPS
  • Finish my new book – Done, published Donuts and Dragons which is for sale on LeanPub
  • Finish painting my Stark and Lannister armies! – Done, also painted my Imperial Knights and Salamanders

In addition I’ve also passed the AZ-900 exam as well as AWS Cloud Practitioner, AWS Solution Architect Associate, and AWS Security Speciality.

It’s hard to pinpoint the highlights. Most likely passing the PSM-III exam, a really tough exam and something I’m extremely proud of doing.

As for low points. I had a really tough Q4 and it would have been really easy to give up. However I used the scrum techniques of inspection and adaption to identify the issue and prioritised passing the final AWS exam to get myself over the line. We’ve also had some tough months as a family which no doubt impacted caused the wobble.

I’ve mentioned before that I’m not planning on setting goals for 2022, instead I’m going to focus on Q1. I have a few overarching themes of AWS and Scrum which I intend to follow but would also like to spend some more time writing (and a few key work projects to deliver). When you are setting your own quarterly goals I would strongly encourage you to look at your key strategic goals and look at what the next steps are towards them. In my case (as you’ve probably noticed Cloud and Scrum feature very highly).

For Q1 2022 I plan to:

  • Read 20 Books
  • Paint Word Bearers, Raven Guard, and Tully Cavalry
  • Write my new Donuts and Dragons short story
  • Pass AWS Machine Learning Exam
  • Take Scrum.org Product Owner exam
  • Take Scrum.org Kanban for Scrum exam
  • Create and Deliver specific Scrum training course for colleagues at work

A nice balance of professional development and relaxation tasks with some work goals thrown in. Some of these are very ambitious but I’d rather try and fail than assume I can’t do it!

What are your New Year’s goals? Are you working over a 3 month planning period or over the full 12 months? Drop a comment below or let me know on Twitter.

Happy New Year!

How Should a Scrum Team Handle Holidays?

The holiday season is upon us and rather than doing another post about my goals or new years resolutions I thought it’d be interesting to look at how a Scrum Team should handle the challenges of having so many people off at once.

What should a Scrum Team do if a large proportion of the team are on holiday at once? Photo by Andrea Piacquadio on Pexels.com

There are two sensible approaches towards Scrum over holidays when a significant proportion of the team are taking holidays. The first is to stop sprinting and resume in the new year. The team won’t set any Sprint Goals and anyone who is working will “make themselves useful” through tacking tech debt, process, or L&D type work. It’s passable… but I don’t like it.

The second option is to look at what exactly Scrum provides us with. Firstly, Scrum states that the next Sprint begins as soon as the previous one expires. There is no concept of breaking sprints in the Scrum Guide and the expectation is that a team will continue to run sprints from the day they’re formed (or adopt Scrum) until they’re either dispanded (or select another framework).

Instead we should look for an achievable Sprint Goal with at least one potentially shippable Increment which meets the Defintion of Done. This should be agreed by the entire team (or at least everyone who’s available). Therefore, rather than abandoning Sprints or Scrum altogether over the holiday seasons the team should look at what is achievable in the limited amount of capacity which will be available. Even if the goal is to fix a single typo then that is acceptable. As long as there is a single team member working at all then there should be a feasible Sprint Goal, the trick becomes looking at what’s realistic and possible during that time.

Do not be tempted to compromise. Whatever the increment should be it must meet the team’s Defintion of Done. Don’t “develop but not test” or “code but not merge”. Look for a single, simple improvement to the product which can be delivered in that time. Even if it’s only a simple bug fix.

With that suggestion I’ll leave you as I’ve got family stuff to do. This post is due to go out on Monday so if you celebrate Christmas I hope you’ve enjoyed it and if it’s your New Year coming up then I wish you all the best for it.

Thanks for reading and see you in 2022!

Why Your New Year’s Goal is a REALLY Bad Idea

Given my previous posts about goals and ability to pivot when things go awry you may be surprised by the title of this post. I’ve been setting annual goals for my direct reports for years (as has most managers across the world). Every year we look at what we want to achieve and then set key people goals to achieve them. More and more I’m coming to believe that they don’t work.

At the start of the year I posted the following goals that I’d set myself:

  • Read 21 Books
  • Write 52 Blog Posts
  • Pass my PSM1
  • Finish my new book
  • Finish painting my Stark and Lannister armies!

So where did I get to with two weeks to go?

  • Read 21 Books – currently sat on 100 books
  • Write 52 Blog Posts – So far I’ve posted every week (plus a few more for the junior developer series I wrote)
  • Pass my PSM1 – Actually I’ve passed my PSM-I, PSM-II, PSM-III, PSD-I, and SPS
  • Finish my new book – Done, published Donuts and Dragons which is for sale on LeanPub
  • Finish painting my Stark and Lannister armies! – Done, also painted my Imperial Knights and am putting the finishing touches to my Salamanders

So why if I’ve met all of these goals do I believe they’re a bad idea?

What is the problem with annual goals? Photo by Andres Ayrton on Pexels.com

In order to deliver these I broke each of these down into quarterly goals. Looking at where I was and where the next steps were, this allowed me to adapt more readily if I was ahead of behind. It also allowed me to introduce new goals (such as the Azure and AWS exams I’ve been doing).

I’ve also massively exceeded three of the five goals I set myself. I had no idea at the start of the year that I could read 100 books (even with Audible’s help). I set what I thought was an ambitious goal and then smashed it. The same happened with the scrum.org exams.

When you set goals over such a long timeframe you either complete them very quickly, they become irrelevant, or you want to bring in something new. With 2022 starting soon, or I suppose more relevantly Q1 this is a brilliant opportunity to look at we want to achieve.

In Scrum we have a Product Goal which is a long term vision which we then break down into incremental Sprint Goals. I’d recommend you to do the same. Draw up around five long term goals, they don’t need to have a completion date but they’re something you would like to achieve in the future. Next, look at what you are going to do between January and March to move yourself towards them (spoiler alert – you can do a LOT in 90 days). Then, when you get to the end of March take a look at the progress you’ve made and plan the next steps. Consider using Personal KPIs and Swimlanes to ensure you’ve got time and focus to deliver them.

A picture of some Imperial Knights… because they’re cool!

This has been my strategy for the last 6 months or so and it’s worked really well for me. In January I’m going to suggest it to some of my direct reports and see if they can come up with strong quarterly goals rather than daunting 12 months ones.

I have one final thought, if we’re working to a 3 monthly calendar now instead of an annual one. Do the quarters (Jan – March, April – June, July – September, and October – December) really make the best sense or do seasons work better? What are your Winter goals? What are you going to deliver this summer? I see some real opportunities here to tie your accomplishments into the weather and daylight hours instead of some artificial business calendar. I haven’t tried it yet but I’ll let you know the results if I do.

What are your goals for the next 3 months? Do you agree with my suggestion to ignore annual goals altogether?

When Personal Goals Don’t Go To Plan

As you may know if you’ve been following my blog for a while I’m a big fan of personal goals. Although I’ve ammended my process along the way (I no longer set a goal longer than 3 months) I still believe in this and start each quarter consolidating what I want to achieve over the next three months. I’ve found this method to be incredibly successful and it’s really helped me achieve things this year I didn’t believe was possible.

However, the best laid plans don’t always go as we’d wish and for a number of reasons Q4 has been very difficult. Goals create transparency (remember I am a scrum coach after all), and they allow reflection. I want to share my experience publicly in the hope it helps other people following a similar goal setting methodology.

What do we do when we set ambitious goals but the universe conspires against you? Photo by Nathan Cowley on Pexels.com

In October I published my Q4 goals. For context this is what they were and this is where I’m up to (wth about 3 weeks to go):

  • Take 2021 Book Count to 100 – I’m currently listening to book 100
  • Pass AWS Security Specialist Exam – Booked for the 17th of December
  • Take  SPS ExamPassed!
  • Build a Lean Coffee Website – Not started
  • Publish a Short Story with the Donuts and Dragons Team – Not started
  • Paint my Lannister army of A Song of Ice and Fire miniatures – Done!
  • Paint my Warhammer 40k Salamanders – In progress (the primer on the last tank is drying as I type this)
  • Finish the core pages of the CKD Site – Not done
  • Pages Get Weight Down to 215lbs (really this time) – Nope, shall we say stress eating and takeaways have taken over?
  • To hit a financial goal I’ve set myself – Had a large unexpected financial expense

So a real mixed bag. There are a few unexpected curveballs (such as the financial one) however many of these are because I’ve lose nearly a month due to a very very tough few weeks. We’re still going through this so frankly who knows what’s going to happen between now and the end of the month.

But wait a minute… Isn’t the whole point of Scrum to be able to inspect and adapt when circumstances change!?

I conduct weekly reviews and have been monitoring my progress against these goals (yes, I have a burn up chart for most of them). I knew which ones were at risk and I knew which ones I’d failed completely.

This tracking creates transparency, the weekly review creates an opportunity for inspection and adaption much like a Scrum Team’s Sprint Review. I had the choice of sticking my fingers into my ears and mumbling to myself and then throwing up my hands at the end of Q4 saying there was nothing I could do. But these are my personal goals – there isn’t really many more important things to achieve (current crisis aside).

So what did I do?

Firstly the following goals can go:

  • Build a Lean Coffee Website
  • Publish a Short Story with the Donuts and Dragons Team
  • Finish the core pages of the CKD Site

These are represent a large investment of time for relatively low return. They’re either speculative (the LeanCoffee site) or promotional (a free short story to publicise Donuts and Dragons). I can still choose to do any of these things in the future (I would really like to write that story and finish my CKD site). But they don’t have to be done right now. What is time limited and very important is the AWS exam.

So I’ve adapted. By not splitting my focus over those additional three goals (which seemed perfectly realistic two months ago) I’ve maximised my chances of delivering the most important one. The AWS Security Exam. That gives me more time and focus towards it and (hopefully) increases my chances of passing. Now I just have to see what happens next week!

Anyway – that’s what I do when my personal goals don’t go quite to plan and how I create transparency, inspect, and adapt when required. Not just with my Scrum Teams but in my personal life.

Managing Dependencies Between Teams

When scaling Scrum the most important aspect to manage is the dependencies. Team should be working towards a combined goal which will be produced as an integrated increment at the end of the Sprint. This is not easy, as almost any broken down work will result in dependencies between the multiple teams.

It is so important to manage this that Nexus actually creates a team (called the Nexus Integration Team) who’s primary responsibility is the managing of dependencies to create this incremented increment.

There’s nothing more frustraiting than needing to get to work but being blocked by another team. Photo by Burst on Pexels.com

When managing dependencies there is a priority of severity.

  1. Another team in the same Sprint
  2. Same team in the same Sprint
  3. Another team in an earlier Sprint
  4. Same team in an earlier Sprint

Starting from the top (anohter team in the same Sprint) and working down these are the order in which a dependency will give you a really bad day. Obviously waiting for another team to complete something in the same sprint as you has far more potential to go wrong than your own team needing to complete something in this sprint to be able to work on something in the next.

Scrum.org has a great article on this which discusses how to track and manage dependencies. My personal advice:

  • List out the dependencies for every piece of work, you can’t manage what you can’t identify
  • Eliminate where possible (ideally in advance), manage where not
  • Use a Nexus Daily Scrum (slightly different to the more commonly known Scrum of Scrums) to highlight cross team impedements and ensure they are resolved as soon as possible
  • Use a visible board to track dependencies and impediments as well as work.

Hopefully this helps. Remember, each of your scrum teams should be producting a single integrated increment at the end of each sprint and aiming towards the same Product Goal. If that’s the case then identifying and resolving problems between the team will be much easier because everyone is working towards the same vision.

What are your experiences of scaling scrum? How did you manage dependencies between teams?

Advice for Taking the PSM-I Exam

One of the most common questions I see on scrum forums is people looking for advice before they take the PSM-I exam. Why not? It’s a widely respected Scrum Master exam at a very reasonable price! I’ve previously written about the format of the exam. In this post I’m going to give my advice on how to pass it.

How would I advise you practice for the PSM-I exam?

Your first resource should be The Scrum Guide 2020 (assuming you’re not reading this in the future after a new Scrum Guide has been produced, in which case use that one!

Second, consider going on a course. Personally I have not attended a PSM-I course however I have only heard excellent things about them. How better to prepare for an exam than to get formal trainer from one of their highly qualified trainers? I believe the courses also include the cost of an exam entry.

You should also take the Scrum Open Assesment. Lots! Take that practice exam over and over again until you can reliably get 90% (or ideally 100%). Seriously, these questions are some of the best resources you can get to practice real PSM-I questions. Scrum.org also provides some suggested reading and a learning path which has some great content in there if you’ve got any weaker areas you want to address.

Personally I wouldn’t purchase practice tests or courses from Udemy or other suppliers. I’ve used some of these in the past and have to admit, I don’t really believe they’re worth it as they’re not that representative and you don’t really very much about the person who created them. Also, why would you need them when scrum.org provide such good practice questions anyway?

I’d be amiss if I didn’t at least mention my book… although in more seriousness. Donuts and Dragons is designed to give a friendly introduction to scrum, and show the events and principles in actions. It is not designed as a study guide.

Preperation for the exam is key. You’ve got an hour to answer 80 questions and you need to get 85% of them right in order to pass. As with all exams try and be well rested, don’t go into it under time pressure or with something else on your mind. Take your time, read the questions carefully, and you should have plenty of time to check your answers before you submit.

I really hope this helps! Please let me know in the comments below if it does. If you’ve got any other suggestions then please feel free to add it below.

Where’s the Transparency for a Retrospective?

I was teaching a Scrum course the other day and we had a really interesting discussion around the Transparency, Inspection, Adaption pillars of empiricism and how the Scrum Events were build around them.

A Daily Scrum is an opportunity to inspect and adapt their plan to hit the Sprint Goal. The Sprint Review is the place to inspect and adapt against the Product Goal. The Retrospective is where we inspect and adapt the team’s processes and tools in order to continue to increase quality and effectiveness.

Many articles and posts have been written about ways to improve the transpancy of work. We use tools like burn ups, burn downs, values like openness, and the three question format to Daily Scrums to drive this transparency at every level but do we stop and consider how we create the transparency needed to inspect and adapt in a retrospective?

How do we create transparency for discussions in a retrospective? Photo by Daria Shevtsova on Pexels.com

Lets start with the obvious stuff. In order to improve the team’s quality and effectiveness we need the team members to be willing to share what makes their lives difficult on a day to day basis. This could be a process, tool, or maybe a knowledge gap. This often requires courage, and requires a supportive team to encourage these issues to be surfaced and worked on. The team also need to feel supported by management, after all people won’t raise issues if they don’t feel they will be looked at or addressed.

We can also use data. Value Stream maps can be extremely helpful to understand where waste exists and how processes can be tweaked to improve.

Customer and stakeholder feedback can be analysed to understand where quality issues arise and what improvements can be made to a team’s testing processes to reduce these issues in production. If there is a support team tickets can be analysed and the time spend resolving these tickets looked at. We want our applications to be as supportable as possible and we want anyone manning a client service desk on our behalf to have all the tools they need to support our customers.

Finally, I’d also recommend opening the retrospective board at the start of the sprint, rather than just before the meeting. This allows team members to add issues as the sprint goes on, maybe even in Daily Scrum. This will prevent us giving undue weighting to issues which arose towards the end of the Sprint which are fresh in everyone’s mind.

If we truly want to inspect and adapt our team’s processes in retrospective events we need to ensure we create enough transparency in our work and product to be able to properly inspect it. What techniques have you found to draw out conversations for retrospectives? How do you ensure you’ve got enough information available to inspect effectively?