devopsy.kinsta.cloud

Tag: retrospective

DevOps 2023: The View From the Rearview Mirror

How can this be? Here we are, right before Christmas, and it will be a new year before we know it. Time to put 2023 in our rearview mirrors. I, for one, say, good riddance. I’m sorry, but 2023 will not go down as a great year for me, and I think it was a tough year for many of our friends in the tech world, too. In fact, to quote Queen Elizabeth (who we lost in 2022), for me, 2023 was in many ways an annus horribilis.

I say that because 2023 saw the sometimes-savage impact of the cycles of the market up close. For the first time in a long time, many of our friends and colleagues were the victims of layoffs. In fact, according to Crunchbase, over 191,000 U.S.-based tech workers were the victims of layoffs. That doesn’t include non-U.S.-based workers, which could easily drive that number to over a quarter of a million. That is on the heels of 2022, when about half that number of workers were laid off. So, in the last two years we have seen 350,000 or so tech workers laid off. For many of these folks, finding their next gig was not as easy as it was in the past. There weren’t recruiters breaking down their doors with interview opportunities. Employers became more selective and demanding. If you are looking for a job that is 100% remote so you can work from wherever, that gets much harder. Employers want employees in the office again. Probably every one of you reading this was either laid off at some point in the last two years or you know someone who was. But it wasn’t just the layoffs. The very foundation of our tech infrastructure suffered seismic shocks, too.

For many of us, the Silicon Valley Bank failure in March was a splash of cold water in the face that signaled business as usual was no longer going to be business as usual. I have been in tech for 30+ years, and for much of that time, SVB was a mainstay of venture-backed startups. Most of the venture-backed companies I helped found were customers. If they could fail, who and what else was suspect? We soon found out what else was not as rock solid as we had led ourselves to believe. The entire VC ecosystem that the tech world relied upon was shaken to its core. With the unprecedented rapid rise in interest rates by the Fed, the underlying business fundamentals of the tech VC market were broken. Who would take a risk investing in non-profitable startups when you could get tax-free bonds that paid as much, guaranteed? We actually saw VC funds close up shop, not raise new funds and cut back. This resulted in over 3,200 venture-backed companies failing in 2023. For those companies who held on, many received the message from their boards that they shouldn’t expect to raise more money at “up valuations” until sometime in 2024 or beyond. They should hold on to their cash. It seems reasonable, but you know, with VCs, there are always two sides (or more) to the coin.

These companies are usually not profitable. They burn money every month. When they cut, they do so first with marketing and sales, and generally, their growth slows. Slow growth makes it difficult to raise funds at an increased valuation. So, it becomes a death spiral. They aren’t growing enough to raise money at a decent valuation, but they are being told to shut down the marketing spend. It’s a Catch-22.

In addition to all the macroeconomic news, 2023 was also a year where war seemed to be breaking out everywhere. I am reminded of the old saying, “War is not healthy for children and other living things.” It isn’t great for tech either, as it turns out. Especially when those war zones are also in places that support thriving tech economies.

So, besides macroeconomic slumps and wars, what else can we say about 2023? In terms of DevOps, we saw a year where DevOps seemed to move from front-and-center to blending in. I think most organizations today are using some sort of CI/CD process in terms of developing and deploying software. Many of the fundamentals of DevOps have seeped into the very fabric of our IT infrastructure. Some may see this as “the death of DevOps;” heck, even Gene Kim is renaming DOES into something else. But as I will explain in my next article, the rumors of DevOps’ demise have been greatly exaggerated. To the contrary, DevOps is beginning to see its promise fulfilled. You will have to read my next blog to get more of my views on this topic.

But 2023 (like all black clouds) also had a silver lining. As Dustin Hoffman in The Graduate said (sort of), I have two words for you: AI. With all due respect to Taylor Swift, my Person of the Year was not really a person at all. I would say it’s AI. You could not swing a golf club around tech people in 2023 without hitting AI in the head. AI has the potential to be a civilization-changing technology. On par with the internet itself, the cellphone and the like, AI could change the lives of everyone. This is as opposed to technologies like the cloud or methodologies like DevOps that were technology-market-changing. AI is attracting literally billions of dollars in investments and is moving forward at warp speed, in spite of those who say it should slow down. It promises to invade and disrupt every corner of IT as well as one business vertical after the next. A perusal of our Techstrong.ai site will give you all you need to know. The impact of AI on DevOps is just starting to be understood. Operationalizing AI for IT will be a major theme for us here at Techstrong in the year ahead, so stay tuned.

While 2023 has been a difficult year in tech, the great thing about cycles is they cycle through. What went down will come up. We are already starting to see signs of an uptick. I am personally optimistic that 2024 will be a great year for the tech world and I pray for the world in general with fewer wars, less death and less sickness. How about more peace, more commerce, more goodwill, better health and, of course, more DevOps?

Happy holidays and happy new year to all of our Techstrong community!

December 22, 2023
How to Solve Any Problem in 3 Steps Using the Zombie Retrospective
Facing challenges is an inevitable part of life, but how we deal with them can make a big difference. When problems show up, it’s important to focus on the things that unite us—it’s better to have a common enemy than fight internally. Experience in complex software development has taught me that it’s crucial to stop, think and act at regular intervals.

The feedback loop is the concept on which the agile mindset is built. Instead of having a project that is one year long, we divide the project into smaller mini-projects of two to four weeks. As the saying goes: There is only one way to eat an elephant–one bite at a time.

To inspect and adapt quickly, I recommend a time frame of just two weeks. During these two-week sprints, the team must work hard to achieve the goal. At the end of each two-week period, the team meets to inspect progress and creates a plan for improvements during the next sprint.

The purpose of the retrospective is to:
- Inspect how the last sprint went with regards to people, relationships, process and tools.
- Identify and order the major items that went well and potential improvements.
- Create a plan for implementing improvements to the way the team performs its work.
(Source: Scrum Guide).

These retrospectives can be general or they can be focused on one issue that occurred during a sprint. Sometimes a retrospective is about de-escalating or resolving conflict and tension. If the sprint didn’t go as planned, the facilitator needs to be cautious about how they run the retrospective. They need to keep in mind how they say certain things, because team members might already have low spirits coming into the meeting.

I stay away from using harsh judgments, blaming specific members or showing my frustration. The goal is to create positive energy for the retrospective. Facilitators should motivate the team to have fun while they participate in the retrospective. I like to have high energy, be positive and try to get the others on the same boat.

As a scrum master myself, I was shocked to find out that only 81% of scrum masters hold retrospective meetings. The retrospective is an essential part of any given sprint and provides valuable information on how to improve.

Preparation

Before the retrospective meeting, I think about the format and tools. If you work in a distributed team, like me, a digital whiteboard is recommended. Using the digital whiteboard, we can have a retrospective no matter where we are in the world.

Here is my process for a zombie retrospective meeting. It’s divided into three steps: check-in, input and output.

Figure 1: Zombie Retrospective board.

Step 1: The Check-In (15 Minutes)

The check-in stage is kind of an ice-breaker. It should be fast, like the starter before the main dish—which in this case would be the deeper and more constructive discussion. Check-ins are treated as an exercise at the beginning of the retrospective to gather information on the just-completed sprint. One nice starter for more in-depth discussion is the happiness index: a quick way to check-in with the team and to see how everybody experienced the last sprint.

I ask the question: “On a scale of 1 to 5, specify how happy are you with the last sprint? No.5 is super-happy, and 1 is totally unhappy. Put the sticky note with one keyword next to the number on the whiteboard.”

Figure 2: Icon made by Freepik from www.flaticon.com

The Scale Is:

5 = Super-happy! Don’t want to change anything!

4 = Pretty happy, but there are some things that need to be fixed.

3 = I can live with this, but there are many things that need to be fixed.

2 = Not feeling so good about this right now.

1 = Totally unhappy, I want out.

I give the team three minutes to five minutes to gather the input, then we discuss the issues. It’s a perfect moment to turn the problem into opportunity. You can use solution-focused questions, such as:
- What needs to be done to raise your happiness index?”
- Let’s imagine we have an ideal world, what would it look like?
- How would you like to have it?
Example:

The team members identified that they are moderately happy because they spend a huge amount of time preparing for the release. The work is boring and repetitive. I then turn the problem upside down and ask how we would like to have it. The team then starts with something they want.

Goal: As a team we want to have automatic regression tests, so that we can have faster releases and use our time for value-added work.

Next, we define action items that will help us achieve the goal—we plan to invest time and implement the automated tests. The product owner will be responsible for managing the product backlog in a way that we would achieve the goal within six months.

The scrum master needs to keep in mind which team members are more open to sharing their opinion and those who are more reserved. Shy employees may have lots of great input, but if they don’t feel comfortable sharing it, they will simply sit back and listen. It’s up to the scrum master to understand the team well and know which team members may need an extra push to be more vocal, to collect the input from the colleagues that are more reserved. The first step is to create an inclusive workplace with a team culture of trust, openness and transparency. You want to reach a point where everyone feels like they’re really a part of the team, and know how their efforts contribute to the team’s success. It’s important to remember the importance of tone of voice and body language and the positive influence this can generate.

Step 2: Team Input (45 Minutes)

There are plenty of techniques to collect input from the team during the retrospective. When I prepare the whiteboard for a retrospective, I look into the different techniques and choose the one that I believe is most fitting for the current context. When we face prevalent problems and challenges, I particularly like the zombie retrospective.

Figure 3: “The Zombie Retrospective” by Agata Matynia. Image representing the zombie retrospective used to support the team input stage. This tool helps teams to visualize problems as part of the journey to aid creative solutions.

With this poster, I explain the following to the team: When a virus turns the human race into bloodthirsty mutants, we need to save ourselves from the zombie attack. We need to think clearly, so our discussion would be split into three groups.
1. The zombies in the illustration represent the problems that we have.
2. The blocked chair represents the actions we can take to stop the problems affecting us.
3. The last place is our hiding place. The TNT explosives, gun and hand grenade represent the team strengths.
Once the team has finished contributing their input, we then go through every idea on a case-by-case basis and discuss it. This stage should take a maximum of 45 minutes.

Following discussion, we then move on to the final stage of the retrospective. This step takes all the input and turns them into concrete, measurable goals with action items, responsible people and clear timelines.

Step 3: Team Output (15 Minutes)

The output stage outlines the goals the team would like to achieve the actions they will take, who will do it and when. The tasks are handed out to the team, and the scrum master needs to delegate people to specific areas with deadlines to ensure that things get done. Otherwise, everyone will agree that something needs to be done, but nothing will be changed.

I use the following format to achieve this:
- Goal: The end result the team wants to achieve.
- Actions: The action points that need to be done to achieve the goal.
- Who: The owner of the goal.
- When: The specific date.
Example:

Goal: As a developer team member, I want to gather analytics on how the mobile app is used so that it can focus on things that matter.

Action point: Deciding what information to gather and who will do it.

Who: Anna is the owner of this topic.

When: In the next sprint.

The retrospective at the end of a sprint should never be left out. It allows for the continuous improvement of people, relationships, process and tools. It makes the team great.

Optional Step: Inspect and Adapt the Retrospective in the Plus/Delta Format (10 Minutes)

From time to time, it is a good idea to evaluate the retrospective meeting. The goal is to be able to learn from the current retrospective to do it better next time. For this, I recommend using a quick, simple technique such as Plus/Delta to make improvements.

In this final step, the team identifies the strengths of the retrospective and what changes can be made for the next one. I ask the team to use the sticky notes to share their thoughts.

Plus: What can the team change or add to bring more value to the retrospective? How we can repeat it?

Delta: Is there anything that we should change in terms of how we run the retrospective as a team?

[Place for sticky notes]

[Place for sticky notes]

Action Points

Source: https://leanconstruction.org/media/learning_laboratory/Plus_Delta/Plus-Delta.pdf

The answers to these questions can give scrum masters valuable feedback on how to bring the team together, solve problems more efficiently and make the best use of the time spent in the retrospective. Up until this point, team members have only been discussing the previous sprint, so giving them some time to reflect on the meeting itself sometimes helps them unwind.

More Ideas to Spice Up Your Next Retrospective

The retrospective meeting is a great opportunity to inspect and adapt. If, like me, you would like to run it every two weeks, you will have about 26 of these meetings in a year. The zombie retrospective is great, but you should avoid using the same approach every time. Get as creative as you like—there are many variations and possibilities worth exploring.

For check-in, I also like to utilize pain scales, a common communication tool used in a variety of medical contexts and settings. Trust me, it also works perfectly in business. Try the LEGO pain assessment tool as a starter.

For the input stage you could use:
- The hot-air balloon
- The speed car
- The starfish
- The ship retrospective
Remember: Having fun is exactly what gets team members more interested!

— Michal Serkieza
June 21, 2019
5 Team Skills That Make DevOps a Success
When starting their DevOps journey, your team will discover it needs to develop some new skills. Most likely the team is good at typing code and solving issues, but what about the soft skills?

Many teams have to learn how to deal with issues themselves—as self-supporting teams, there is no longer a manager who will help them out and tell them what to do.

During the Phoenix Project DevOps business simulation, the majority of teams discover collaboration and communication are skills they lack. I am often surprised how few people can really facilitate standups, retrospectives, Andon-sessions and other communication methods.

Here are the five team skills that participants recognize as core skills they learn (or could learn) during the simulation.

The Standup

The standup is a very powerful way to share knowledge about certain issues. The team will stand together for a short time and discuss an issue that blocks the flow, needs clarification or needs to be high priority. So, who should initiate this standup and who should lead it? I’ve noticed a lot of participants find it very difficult to manage this standup initally, but after a few times the team discovers the key elements of a successful standup:
- Chose a facilitator. Someone who is leading this session. It doesn’t matter who (it doesn’t have to be a manager).
- Share the focus: What are we going to talk about?
- Keep it short (time is ticking).
- Make sure we all understand the outcome.
- The importance of listening and engagement.
Facilitating a Retrospective Session

DevOps is also about continuous learning and experimenting. One of the important steps in this process is retrospective. This activity explores the past round of work and reviews what went OK and what needs to be improved. Again, during the simulations I discovered that not many participants know how to execute this activity. After being shown the right example, the team often can perform this activity themselves. This is what teams learned during the simulation:
- Someone from the team must facilitate this process.
- Make sure the improvement is supported and understood by the whole team.
- Test the improvement before to applying it.
- Record the discoveries—this becomes part of the visual management system and part of the team backlog of improvement needs.
- This team skill is one of the skills that more than one team member should be able to execute.
Managing the KanBan

During a project, teams sometimes will have standup moments to discuss the work visualized on their KanBan. Work will move from backlog to doing and done, and new priorities will change the order of work. During the simulation participants will take the lead in this process, but some don’t find this easy. After the sessions they discover:
- Use standups to discuss the changes on the KanBan, make sure the team is fully involved when moving notes around.
- Challenge participants to share their thoughts. Saying “yes” doesn’t always mean “yes.”
- Errors are made, but that doesn’t mean somebody has failed and should be punished. Keep the session safe and open.
- The KanBan is a form of visual management system (VMS). The VMS is not the goal—it is an instrument and must help the team to visualize flow, limit work in progress, drive productivity through an awareness of what people are working on and continuously improve the process.
- Make sure at the end of the session, all participants know what’s agreed.
Managing an ‘Andon’ Session

‘Andon’ is a very powerful instrument to explore a situation that stopped the flow. As soon as the flow stops, someone “pulls the rope” and the team “swarms around” to investigate the error and try to continue the flow as quickly as possible. This session should be led by a team member; it doesn’t matter who. During this session, the team discovers the following learning:
- Make sure the session is short and focused on fixing this blockage and restarting the flow.
- Make sure we are not blaming each other; it should be about exploring what stopped the flow, fixing it and agreeing how to prevent it from happening again.
- Make sure the whole teams swarms around and participates.
- Create a safe environment.
Collaboration

Doing the work is not always easy. Sometimes we don’t know what to do. Sometimes we need help, and sometimes we are not happy with the actions of a team member. This is what collaboration is all about.

One of the first aspects of collaboration is helping each other. But, this is not always effective. Sometimes it’s even disruptive or we just take some work from somebody else if we think he is too busy. Here’s what participants learned about collaboration during the simulation:
- We have to avoid “compensational behavior.” This is about taking other people’s work with the intention to help the other. Sometimes this person doesn’t know you took the work and he or she does it again, creating unnecessary double work.
- Collaboration is about shared goals and shared processes. We should all know what we are doing and how.
- It’s also about clear roles and responsibilities. If you know what your colleague is doing, you know what you have to do. And the other way around.
- You must have an open team culture in which it is also safe to say you don’t know and to ask for help.
- Collaboration is fun, and it gives energy if we as a team achieves something.
Conclusion

I have visited many global DevOps conferences in the previous years and have listened to numerous speakers declaring, “It’s all about people.” And they were right. Unfortunately, the audience often did not get many useful answers.

A high-performing collaborative team needs team players who know how to deal with the collaboration and communication issues themselves without needing management intervention.

Teams will have to go through the stages made famous by Bruce Wayne Tuckman (Forming, Storming, Norming, Performing and Adjourning) to become an effective, collaborative team.

Continuous learning is a key success factor and a critical competency for any DevOps team. Why not start this learning journey in a safe and challenging environment?

A simulation such as the Phoenix Project is a very powerful instrument to teach teams how to collaborate and become high-performing. The environment is safe and feels like the real work environment. Participating in this simulation with an actual team allows you to capture and agree on actions to takeaway. Outcomes can easily be transferred to day-to-day work.

I wish you a lot of soft skills.

About the Author / Jan Schilt

Jan Schilt is owner of GamingWorks. His background is Human Resource Development (MSc). Within GamingWorks he is responsible for Business Simulation design, Facilitation and Train the Trainer. He is also an expert in developing learning activities related to organizational change. He builds all the simulations and has delivered more than 300 workshops worldwide.
May 19, 2017
Don’t Cancel the Retrospective
Not too long ago, I noticed a lot of teams rescheduling or cancelling retrospectives. Sometimes it was because key people were going to be out of office. Sometimes it was because a major deliverable was due and everyone was crazy stressed. Sometimes it was because the project wasn’t as far along as they thought it would be, and they wanted to wait for more data. In each case, the retrospective was cancelled only because of something deemed completely logical and understandable.

But it bothered me a lot.

I turned to the internet to back me up—to give me some context as to why retros never should be moved or cancelled that I could then send out triumphantly to our teams—but instead I found a dearth of thinking on retro cadence and scheduling. Denied the collective wisdom of the internet, I was forced to look inward to better understand why these scheduling changes bothered me so much. Is it just that I’m a compulsive rule follower who can’t handle change? That’s always a possibility worth examining. Were there things I wanted out of these retrospectives and was annoyed to have delayed? Not exactly, since I wasn’t actually participating in any of them, but that was a bit closer to the reason.

As a manager, one of the things I read over and over is to never cancel a one-on-one meeting with a direct report. If you have to reschedule, it should be as close as possible to the original time. Rescheduling and cancelling one-on-ones is a sign to your reports that spending time with them is not important to you, and should be avoided if you actually respect your colleagues.

The retrospective feels the same way to me. The person who reschedules it is probably a product manager or a tech lead, dutifully reviewing the schedule for the team and realizing there might be a problem. He or she invariably sends a message to the effect of, “Hey guys, this seems like a really bad time—anyone mind if we move it to next week?”

Which of you would raise your hand and say it’s not OK? I’m a pretty forceful person, and I’m not sure I would. It’s a tall order to demand the time of the whole team.

So, what’s the big deal about retrospectives anyway? Are we all beholden to the Agile Manifesto, following the pattern just because it says to? I really hope not, and I can say from my experience some of the best innovations on my team have come from retros. To me, a retrospective is like a one-on-one for the whole team, and can serve the same purpose.

These are my favorite things about the retrospective format:
- Enforced thinking time. We all spend our days running at top speed, and taking 15 minutes at the start of a meeting just to think about a topic is incredibly valuable. Taking time before the meeting would be even more impactful, but, baby steps.
- Individual contributions. The format encourages every single member to contribute to the discussion. The mix of written and verbal discussion affords avenues for people with different communication styles to all have their feedback heard.
- Venting. In the same way that sometimes a one-on-one needs to be a blow-off-steam session, group venting in a retro can be cathartic—and much healthier than silent stewing.
- Pulse-taking. Teams are most healthy when every member has things to say, positive or negative, and is willing to discuss them out loud with the group.
While it’s helpful to understand why retrospectives are so vital for the health of your team, it still doesn’t explain why it’s such a big deal to reschedule. Well, maybe it isn’t. You are not likely to get great thoughtful ideas out of people who are stressed out and are staring at their laptops the entire time. On the other hand, if it happens a lot, it can send a message that the team doesn’t value retrospecting (and probably also is oversubscribed).

I found that just reminding teams that retrospectives are a first-class calendar system was enough to effect positive change. When push came to shove, my team wasn’t deprioritizing retros, but we realized that we were actually just in a format rut, so we decided to try the sailboat retrospective. Pro tip: It’s more fun if you add pirates.

About the Author/ Cat Miller

Cat Miller is senior software engineer at Flatiron Health. She received her Bachelor of Science degree in Mathematics and Master of Engineering degree in Computer Science, both from MIT. Connect with her on LinkedIn.
November 23, 2016