Louis-Philippe Carignan

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.

In his book Good to Great, author Jim Collins asks the reader: Do you have a "to do" list? Do you also have a "stop doing" list? He goes on by saying: Those who built the good-to-great companies, however, made as much use of "stop doing" lists as "to do" lists. They displayed a remarkable discipline to unplung all sorts of extraneous junk. With this in mind, I've decided to create my own personal "stop doing" list. With all those annual reviews, comments from previous clients or teams that I've coached, I have enough material to build it. To remind me often about things I have to stop doing, I've put it in front of my computer screen at work. As a Scrum Master, it's always good to walk the talk. When I work with teams to find things they should stop doing, my own personal list demonstrate how I apply this technique to myself. If it's good for me, could it be useful for them? Uneccessary question from readers: Did you ask your step-mom to provide more themes on this list?

When reading the role of the Scrum Master in the Scrum guide, one of the core competencies is to facilitate meetings. While in a meeting, a Scrum Master might want to visualize what the team is thinking or expressing. Or he might want to enhance the collaboration through an activity. Colored Post-It, markers, tape and planning poker cards are some of the things found in the Scrum Master toolbox. Just like powerful questions and active listening are tools a Scrum Master can use improve the effectiveness of a meeting, he also needs some physical material to synthesize or visualize what people are saying. To make this possible, I used to carry this material around in a small cardboard box. Overtime, it wore down into pieces. As I have consulting gigs at different customers, it was not practical to carry around from one office to the other. I ended up using one of those reusable bag I picked up at Agile conferences. While it was better than the box, it was always a pain to search the bag for a marker or a bunch of Post-It. I’ve (finally) found a great container to carry my stuff around: the tackle box. It’s cheap. It’s robust (for an office environment). It doesn't break appart after a week. It has sections to separate your stuff. It can attract a conversation when you are seen as the dangerous Agile consultant. You quickly get identified as the guy who puts stuff on walls in a meeting. I would recommend it to anyone who has to carry stuff around and have been in the same situation I've described above. For those living in Canada and like the idea, Canadian Tire sells the Plano tackle box for $14,99

A team that I work with decided one day to improve the general mood in the team. A member of the team (David) bought the Snakes & Ladders board game for the team. By playing the game, his goal was to counter pessimism that was generally flowing within the team. As negative remarks about the project plagued the team, David wanted to end this. This was his way of doing it. As the goal of Snakes & Ladders is to be the first to reach the end of the board, the team added a few rules of their own. Team members choose their own pawn (notice Caillou, R2D2 Tintin rocket to the Moon). Each day, every member of the team has to role the dice in order to know how many steps he moves his pawn. If during that day, this team member would show pessimism, he would move backward by rolling the dice again. He could move backward as many times as he was being pessimistic about the project. On the other hand, he could only move forward once on each day. To confirm a person was being pessimistic, two other team members had to validate the remark. Sarcasms were also considered pessimistic remarks while negative news (Ex: build break, tests failed) were considered facts and not negative remarks. On the other hand, complaining about these negative facts was considered pessimistic, hence rolling a backward move on the board. Honestly, the rules fitted on an entire page while the other side of the page had rules on how to change the rules. Who won? The team obviously! Ok, it’s the technical lead of the team who won but chasing away pessimism was the real win in this team.

I have found that coaching managers is a different approach than with Scrum teams. While you are (most of the time) involved directly with the Scrum Team as a Scrum Master, managers are less accessible. They have other meetings, which you are not invited to. They might not visualize their work like you would do with a Scrum Team, making it more difficult to follow what they are doing. Your work relationship is weaker than with the Scrum team. Sometimes, they even hired you directly to help their Scrum teams only to realize that the impediments all point in their direction. It’s not always easy to show areas of improvement to the person who is paying your salary. So how do you coach them? If you can’t follow them all day, or your contract didn’t state that you were going to help them too, how do you make sure they improve their stance as a manager along the way? One way that I found is through monkeys. Coach versus consultant While I was attending one of Lyssa Adkins class about coaching Agile teams, Lyssa explained the difference between a consultant and a coach. For her, our customer has a problem represented with a coffee cup that he holds in his hand. A consultant will take the cup away as a sign that he solves the problem of the customer. This is good in some situations. Let’s say the customer doesn’t have the expertise to build a web site. The problem, building a web site, is removed from the hands of the customer. A consultant (or company) will take the problem away from him and solve it because it has the expertise. On the other hand, a coach will ask the customer to keep the coffee cup in his hand. It’s a problem the customer must solve by himself, not by handing it off to someone else (or to simply put the cup on a table and walk away). In other words, the coach will question the customer about how he can solve his problem. Compared to the consultant, the coach never takes the problem. He leaves it in the hands of the customer. Let’s say a manager must have a difficult conversation with an employee regarding his performance, the coach will make him think about different approaches the manager can take to solve his problem. The coach won’t have the difficult conversation with the employee. It is the manager’s responsibility to do so. Back to our monkeys While the customer is holding the cup, he discovers his own action plan to solve the problem at hand. Most of his action plan will be assigned to himself. As managers are good at delegating, they might be tempted to delegate this problem to someone else (Ex: the coach). As a coach, you have to remind the manager about how he must resolve by himself the problem at hand. The manager has to assign to himself a todo, a call-to-action. To illustrate this comically, I often use the analogy of monkeys. “You have to take this little monkey on your shoulder Mr. Manager”. If the manager didn’t take care of his monkey, I can initiate a conversation with “Did you lost your monkey?” to remind him of the task at hand. To have a stronger impact with the monkey metaphor, I actually have little monkeys. Bought for a couple of dollars at a Dollar store, they patiently wait in my drawer. If a manager has agreed on an action plan where he has some tasks to do, I give him a monkey. It reminds him about the difficult task at hand. It brings humour to the situation while making a point. At my workplace, you can actually see the office peppered with monkey dolls on desks. People teased each other "Oh, Louis gave you a monkey." or "What's your monkey about?". To close the loop, I ask the person to bring back the monkey once his task is done. It's a great way to gather feedback at the same time. As it forces him to bring back the doll, I can easily do a follow up. I've come to realize that this trick is effective in situations where people do not want to take their responsabilities. If I work with people who have a strong sense of ownership, I won’t bring in the monkey trick. I’ll focus on something else. In one team, the team had a strong sense of ownership but they didn’t collaborate on tasks. I used another trick, the washing line trick. But that’s another post all to itself. Until then, I encourage you to try out the monkey trick if you find yourself in the situation I explained above. Let me know if it had a positive impact in your work environment.