Louis-Philippe Carignan

With the launch of the Kanban Guide for Scrum teams in 2018, its 4 flow metrics have gained more popularity amongst the Scrum community.

The Old Farmer’s Almanac is the oldest continuously published periodical in North America. It was first published in 1792 by Robert B. Thomas who wanted an almanac “to be useful with a pleasant degree of humor. Many long-time Almanac followers claim that its forecasts are 80% to 85% accurate. 

The emergence of the Kanban Guide for Scrum teams has given new metrics and practices to Development Teams on how they can augment their Sprint Backlog to manage their work.

This is a post explaining how to do throughput-driven sprint planning using throughput and Service Level Expectation (SLE).

If there is one trend that has surpassed Agile in our profession over the last five years, I would say DevOps would be a good culprit. As we’ve seen an explosion of tools to implement CI/CD in our Scrum teams, we’ve also seen some of our Agile practices being challenged by this new reality.

I’ve been teaching the class Professional Scrum with Kanban (PSK) for the last year now and I strongly believe parts of its content will send some of our current practices and books to the Agile museum.

The Professional Scrum with Kanban (PSK) course has now been out for more than 6 months at Scrum.org. As one of the first few trainers who wanted to teach this course when it came out, I find it is a great way to combine the Scrum framework with Kanban as a strategy to deliver value to your customer.

DevOps is all over the place nowadays. The toolset is exploding. Companies are offering a large variety of products to suit the needs of customers. Looking at Google Trends, the keyword devops has doubled in popularity in the last two years. Acting as an Agile coach, I’ve been steadily working with DevOps teams for the last year where I’ve seen some downsides of being DevOps. Sorting through other blog articles, I didn’t find a lot of content on two downsides that I’ve witnessed with my teams. I thought I would share this experience to give readers another perspective to DevOps. What is DevOps for us? That’s a good question and it varies a lot depending on what you read. If only the founders of the term would have captured their definition in a manifesto (wink to Agile). For the rest of this article, our DevOps teams follow the mantra “You build it. You run it.”. They support the system they code. They are responsible for the entire lifecycle of the code. Once they start writing it, they know they will also debug it when it breaks in production. Developer fatigue While it is a thrilling experience to know that thousands of people are using your system, it is not as thrilling to get woken up in the middle of the night to handle a system failure. While the reader could say we should build more stability into our system to avoid this problem, this isn’t an overnight fix in our thriving startup that is ramping up more than 30 new hires in the last year months. Developers make mistakes like anybody else and these cause bugs in production. In the meantime, our DevOps teams have to share call rotation as well as having a backup in case our first response team member is running into an issue. We’ve had people going out for a bike ride on a sunny Sunday morning turning back to their laptops as they had to debug code that had failed in production. We’ve even had in our interview process candidates asking how we handled call rotation as we presented our teams as DevOps. User fatigue It is great to have a continuous deployment train that can automatically push new features in production. It is not so great to read customer feedback telling us they are exhausted with learning new features every other month. Who would have thought! We were so happy to push features, automate our deployment process to speed up things that we completely forgot about the customer at the end of the production line. I define User fatigue as customers who can’t keep up with new features. Features roll out just to frequently for a user to discover and adapt them to their current ways of working with the software. It might be hard for software developers to understand this as we are always in the gist of it. Think about field technicians or customer service representative that have a different relationship with software. Their main focus is not the piece of software we are passionately working on so their level of interest on new features isn't as high as our desire to deploy new features as soon as they are build. I have experienced first-hand this user fatigue through the numerous releases of Visual Studio Code (VS Code). As I sometimes write a bit of code, I can open up the tool a few times per month. In the first few months back in early 2017, I was excited to get an indicator telling me a new version was available. I would read the long and descriptive readme file to discover how the tool improved. Two years later, I don’t really bother reading the file. There’s always a ton of new features. Animated gifs are there to speed up my learning. But I’m just to busy to take the time. Conclusion While I cannot neglect the tremendous value that the DevOps tooling brings to our profession, I would say that a well-educated decision about how you want to operate your DevOps teams is necessary. Before jumping on the DevOps bandwagon, I would advise that your team ask itself the following questions to tackle some of the downsides of DevOps: How will we respond to system failures in production when they occur outside office hours? What are our delays to acknowledge this system failure? Do we let our customers know? Do we have a procedure to find the root cause of the system failure to avoid the problem from happing again in production? Do we set an ETA on those post-mortems to force us to learn from system failures? Do we have beta users who are more willing than others to opt-in to the frequent release of new features?

I have an important favor to ask to Scrum practitioners who are asking their team to commit themselves to their sprint backlog at sprint planning.

According to the Scrum guide, sprint retrospectives are "an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint." In my early career as a Scrum Master, I used to follow this definition quite stricly. Time was taken to look for our problems and create improvement plans. Unfortunately, as I advanced in my role, I learned that people would get tired of always looking for ways to improve. Trying to dig deeper into problems, sometimes organisational, sometimes professional, would drag the team motivation down. On the other hand, just being told that they were good seemed to give better results. Surprisingly, it brought ideas as the mood of the meeting was positive. People felt good about themselves and worked toward getting better. I've also found that positive retrospectives were better when they are started with an activity to launch conversations. Simply starting a positive retrospective by saying we will praise each other felt kind of awkward. To initiate these conversations, I have found that the niko-niko calendar and the mood board were good instruments to articulate positive conversations. The niko-niko calendar is a very well documented tool where you follow the mood of the team. Bernd Schiffer has a great post explaining it. It basically consists of tracking the team's feeling at every day of the iteration with smiley faces. If you did not set in place such a tool, the mood board can be an alternative. The mood board is basically a graph where the X axis is the timeline of the project while the Y axis is the level of happiness. As this is a very scientific tool, notice how the top level of happiness is a big smiley face. In the picture above, notice how each line is of a different colour. As I had multiple team members, and whom got on board at different moments of the project (removing other team members), we used a color for each person and the line would start at a different place for each person. I then asked people to recall positive events around this artifact. In my example, we were in a slump around iterations 5 and 6. While we could have complained about what was going wrong around that time, the objective was to talk about positive interactions. So we started talking about how we got out of this slump. And praises started surfacing. John (the green line) underlined how the arrival of Martin #2 (the purple line) helped the project. And things just flowed for a while ... postitively. There were no tangible action plan out of this meeting. Just good vibes because of our appreciation of each other. And sometimes, team moral is the thing to knock on during a retrospective.