What is an Agile Team Restart? The first time I heard of the concept was in the Lyssa Adkins' book, "Coaching Agile Teams." This could be triggered by the start of a new product, a new team member, or a request from the team.

Some of the restarts I've witnessed have included an intro game, a working agreement, a definition of done, and a definition of ready. Adkins' book focuses mostly on a restart as a chance to team better...to get to know your fellow teammates, and define what you value as a team. What does the team want to be known for?

In the last couple of years, I've been using Modern Agile to coach the organization, the management, and the teams. It's worked so well, that it wasn't even a choice to us Modern Agile to do a team reset...the only question was "How?." (Learn more about Modern Agile at http://www.modernagile.com/)

I came up with a few ideas, perhaps you'll come up with more. Let me know, and I will add them in - with credit to you, of course. 

Make Safety a Prerequisite:  Personal Journey Map - I draw my own journey line, and use it as an example. I include ups as well as downs, career-related events as well as personal events (children, buying a house, etc.). I give them 5-7 minutes to complete the map, and then we go around the room and listen to everyone talk about their own personal journey. Questions are definitely allowed. This helps the team to become closer, and learn about similarities as well as differences. The most recent time I played this, everyone on the team had started out in a different career than they ended up in. Other teams found that they had all moved around a lot as children, or all liked chess.
​
Deliver Value Continuously:  Scrum in 10 Minutes - I walked through the Scrum cycle, asking team members how they had done it in the past - what worked, what didn't. By the end of the cycle, we had a good idea where to start. At the first retro, we discussed what was decided and how that was working out, and made a few tweaks. 

Make People Awesome: Is/Is Not - This is a good way to delve into specific practices, like code reviews, mobbing, and production support. The idea is to have the team write post-its for those things that they are - positive or negative (a team with 100% code coverage, a team that is flexible, a team that starts stand-up late) and things they are not (a team that doesn't argue, doesn't shoot Nerf guns, doesn't miss an Innovation Day). The discussion forms around how they actually want to be, or not! 

Experiment and Learn Rapidly:  Apollo 13 - This is, in my opinion, one of the most Agile movie scenes ever. They have to do an impossible thing, with only the tools they have. They experiment a lot, and come up with something that no one person could have figured out on their own, and work with their business partners (astronauts) to get value out of it. Grab a bag of stuff - any stuff. Take some index cards and write various problems on them (stranded on a desert island, have to get across town in a very short period of time, need to organize a party in 30 minutes, etc.) and only use the things in the bag. You can also use index cards for the "stuff" - maybe they only have $12 cash, three pickle jars, a mouse pad, and a fishing pole...or something. Use your imagination, and they will use theirs. 


​

​ 

One of the principles of Modern Agile is, "Deliver Value Continuously." The question that typically comes next is: "How do I know if I am doing that?" For quantifiable tasks, it's fairly easy. If you are a chicken, it's easy enough to measure the number of eggs produced, and the quality and size of those eggs. If you're not a chicken, it's a bit harder. 

One of the things that I do is keep a Value Journal. It's very simple. Grab any kind of notebook. Each day, write a list of things you did: meetings, significant conversations, classes, videos, working on a blog post.

At the end of the day, circle the two most valuable things you did, and the two least valuable things. They don't have to be super-valuable or real wastes of time...it's just relative to the other things you did today.

​Ask yourself these questions:

What made the most valuable items valuable? 
How can I apply that to other situations?
Why were the least valuable items not valuable? 
Could I have helped to make them valuable? 
Would it be more valuable to (cancel the meeting, do more research, have the right people in the room, etc.)?

Then look at your schedule for tomorrow and see if you can apply anything you just learned. 

A Value Journal is a quick way to make small improvements that have a large impact. Don't spend a lot of time on it, and don't overthink. 

I love SyFy's Shark Week, and counted down the days until the premiere "Sharknado 5 - Global Swarming." Of course, I couldn't resist creating a retrospective...no...a SHARKTROSPECTIVE!
​
Supplies

1. Printouts of a handful of your favorite shark movie posters (as seen to the right).
2. Post-Its, or better, 20 cutouts of sharks.
3. Sticky notes and pens, of course!
4. Tape

Setup

1. Tape the shark posters to a white board or large sheet of paper, spaced out.
2. Create your own titles for each shark poster. For instance, because "Sharknado" is so awesome, I labeled that one, "What Went Well."  The label on "Sharktopus vs. Whalewolf" reflected the mashup of the title characters: "Integration Points." Use your creativity and knowledge of the team to put significant labels on each shark poster. 

Activity
1. Hand each team member a handful of shark cutout (or Post-Its) and have them write a subject on each one: something that went well, something that revolved around integration points, etc. 
2. Tape each shark cut-out to the appropriate shark poster, grouping as needed.
3. Discuss, dot vote, or prioritize the items until one or two clear action items come out of the retrospective. 
4. Write the action items on shark cutouts, and hang them in the team area as reminders. 

This is a great read for Agile Coaches who are always being asked about metrics: 

Metrics Don't Create Value - People Do
​

 
This fun retrospective is based on a popular 80s video game. There's an element of chance, a little skill, and lots of opportunity for celebrating successes and identifying team improvement points. 

Supplies: 

1. Make the DIY Tetris Game from Handmade Charlotte. I used a glue stick to back it with cardstock, but that is not necessary. 
2. Sticky notes and pens, of course!
3. A pouch, envelope, basket - anything to put the pieces in so that they can be drawn out randomly.



Setup: 
1. On a white board or other display, put up the following categories: 

• Green
• Yellow
• Red
• Orange
• Blue 
• Aqua

Activity:

1. The first team member closes their eyes and chooses a piece at random, then places it on the board. Based on the color of the playing piece, the team member writes on a sticky note and places it on the board using the following categories. Feel free to change them to make them more applicable to your team.:

Green: Things that went well
Yellow: Things that were good, but could have been better
Red: Road blocks
Orange: Things that were fun
Blue: Things we did to help others
Aqua: Things others did to help us

If a team member can't think of any one item to go in the category that matched their piece, they can choose to put two items in any of the other categories. 

2. Each subsequent person draws a piece, and places it on the grid, fitting in with the other pieces. 

3. When no more pieces can be fit in, the focus turns to the board. Each team member can vote for up to three board items that they think are the top priority for the team to address.

4. Discuss based on the priorities, and identify any actionable items.  
​

Background: The Three Wise Monkeys originated, by some accounts, in Nikko Japan on the temple Tosho-gu. They are named Mizaru (See No Evil), Kikazaru (Hear No Evil), and Iwazaru (Speak No Evil). They often refer to turning a blind eye to current happenings, but also a nod to clean living. Representations of the monkeys are sprinkled all over the world’s culture in various ways: statues, t-shirts, travel souvenirs, and Christmas ornaments, sometimes with the addition of a fourth monkey, “Have No Fun.” There is even a wine whose label features the monkeys and the name “Pinot Evil.” Mahatma Gandhi's one exception to his lifestyle of non-possession was a small statue of the Three Wise Monkeys.

Supplies:

Sticky notes
Pens
Three Monkey graphic cut in three

Activity:

1. Tape each monkey to the wall, whiteboard, or large piece of paper.
2. Create a columns that labels each monkey. You can use “Saw, Heard, Said,” or “External, Internal, Action,” or anything else that seems appropriate to you.
3. Create rows for “Went Well,” “Didn’t Go Well,” “What We Can Do Better.”
4. Hand out sticky notes and pens and ask participants to write anything of note in the sprint that they can think of to fit in the grid.
5. Group sticky notes and discuss successes and potential improvements.

Choose one as an action item to work on during the next sprint. Hang it in the team area along with the appropriate monkey.

Download the file for directions and monkey graphic.

​The Kübler-Ross model, or the five stages of grief, describes a series of emotions experienced by survivors of the death of a loved one. The model was first introduced by Swiss psychiatrist Elisabeth Kübler-Ross in her 1969 book, On Death and Dying. Kübler-Ross later expanded the scope to include any significant loss or change, such as a personal relationship, job loss, even substance abuse.

While many teams and team members embrace the change from waterfall to agile and look forward to a better way of working, many struggle with the loss of the comfortable way they've been working up until now. As an agile coach, it's imperative that we understand that those people may appear to be fighting the transformation and they may be called "set in their ways" or "late adopters," but their feelings and actions are normal.  

Here are the symptoms of each stage of Agile transformation grief and some ways to coach them: 

1. Denial - In this stage, an individual or team may believe that the organization's commitment to agile transformation is a passing fad or another management tactic that will soon blow over. They may say, "our team is different - Agile won't work for us" or "it's just another word for micromanagement." They cling to the false reality that they can just put their heads down, and the transformation won't happen to them. They think perhaps leaders will forget about them, and go on with the transformation in another part of the company. 

In the case of denial, the coach needs to be fair, but firm. Encourage those in denial to talk about how their team is different, and in what way it "won't work." Listen carefully, and offer positive reinforcement for behaviors that already align with agile principles. Address any myths quickly. Remember that each team is different, and help them to learn practices that celebrate and use that difference to deliver valuable software quickly. 

2. Anger - As the newness and excitement of an Agile transformation wears off, even the most positive team members will experience some low-level anger from time to time. These feelings in an Agile transformation can be directed at many targets - the most frequent of which is toward at Agile Coach or Scrum Master themselves. You may hear team members say things like, "there are too many meetings!" or "why do I have to stand up? This is dumb!" or "leave me alone, I just want to code!" 

Teams that are maturing may have feelings of indignation as they feel their Agile Coach or Scrum Master pulling away, and helping other teams or parts of the organization. While a team is usually proud that they are becoming more advanced Agile practitioners, the bond that one feels with a teacher, mentor, or coach is close. You may be getting conflicting messages from the teams like, "We can do it ourselves" followed by, "You're not spending enough time with us." 

As a Coach, remember that these is normal, not wrong. Despite being directed at you, they are often not about you specifically. The key thing to remember is not to argue, as that will increase the level of angst...but ask one simple question: "Why, specifically, do you feel this way?" To the exclamation about too many meetings, the resulting conversation may reveal that there aren't "too many" meetings, but they might be at inconvenient times. Perhaps the facilitation of the meetings need some work in order to make them more valuable. Perhaps there are too many for that team, and there are better ways of handling various meeting activities. 

3. Bargaining - You've probably already seen the bargaining stage in action. First, it's important to understand the concept of Shu-ha-ri. From Wikipedia, the words of Aikido master Endō Seishirō: 

"It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws."

Teams enter the bargaining state right around the time they start moving from Shu to Ha. Teams want to change the way they do things, they question management, and they start noticing how other teams operate. The trick to coaching them through it is to keep them asking themselves why they do things - and why they want to change. A team may want to give up doing the daily scrum because they find them boring, or they may want to give up the daily scrum because they mob all day and are constantly sharing information about their progress and impediments. The Agile Coach can remind them to examine why they are changing, and help them experiment with change so they can move quickly, always being careful not to guide the change.

4. Bleakness  - As a team starts to explore more options on how to work, and some team members push harder for their own directions while others are content with the choices made so far. You'll see a lot of frustration, angst, and unhappiness as they try to find their way. This is the "teenager" stage of a team, where they want a lot more autonomy, but feel outside forces keeping them from being truly innovative. Symptoms of this bleakness are teams that find no value in stand-ups or retrospectives at all. They might stop pairing and mobbing, and start working in silos. They could abandon the things that were making them great, and become more low key. The first instinct of an Agile Coach would be to make retros more fun, or try to get them back into their groove, when what they really need is support for whatever autonomy and innovation they want to try. At this point, the Coach must look in the mirror and see if they are the blocker - perhaps you are still facilitating their meetings, or reminding them of Agile principles. Step back. Let them do retrospectives themselves, then support whatever it is that comes out of them. Increase your trust, and decrease your touch. 

5. Acceptance - When everyone reaches this state: management - Agile Coaches, Scrum Masters, Product Owners, and the Dev Team - you'll see some great symptoms of a healthy team. They don't even talk about the "old days" of waterfall, except to compare how easy/fast/better things are now. They don't complain about how things are without proposing a way they can fix it. Their retrospectives are absent of blame, and have valuable outcomes. On the other hand, they might even decide to skip a retrospective if they are constantly inspecting and adapting during their regular work day. Team discussions are customer centric, and they enjoy getting any kind of feedback from the people and teams that they are serving. It's time for the Agile Coach to take on more of a passive role, and move on to newer teams. 
​

This question comes up quite a bit with growing Agile teams. Most start out as Scrum, since it's easy to implement quickly, but eventually feel the natural growing pains of a team that has attacked all of the easy impediments, and can't figure out why problems are still nagging them. According to Version One's The 10th Annual State of Agile Report, 58% of respondents said that they practice Scrum in their organizations, and only 5% indicated that they practice Kanban. However, 25% practice some kind of Scrum/Kanban/XP hybrid. The question typically comes from a team who is struggling with Scrum, and has heard that Kanban will solve all of their problems.

There are many reasons that teams switch from Scrum to Kanban. Some make perfect sense, and some don't. Even when the reason isn't completely sensible, moving to Kanban can still be a positive change.

Common reasons why teams switch from Scrum to Kanban. Teams may have multiple reasons or, seemingly, no reason. 

1. They are bored. 
2. The team is consistently finishing sprint work before the end of the sprint and pulling in more work.
3. They are primarily a production support team.
4. They are having problems with management, product owners, and other team members that they can't figure out how to solve.
5. They have a separate Tester or Business Analyst who does not do development work.
6. Their formal sprint planning meetings are very quick, as the stories are ready for development and the sprint work has been discussed ahead of time.  
7. They are working very closely with their business partners and reviewing sprint work with them immediately.
8. They are releasing often, if not continuously. 
9. They are talking about retrospective items outside of a formal retrospective, and solving the issues or setting up the experiments whenever needed.

​The first question to ask the team is: "What is the problem we are trying to solve?" The second is, "Is this the best way to solve the problem?" If so, or even if the team can't come to a conclusion, there's no harm in the team try Kanban for a short time to see if it's a good fit. Tools like Jira can run a Scrum board and a Kanban board over the same project, so switching back and forth is easy.

Being able to change frameworks, practices, and processes is a big step in a team becoming truly autonomous. 

Last night, I was fortunate enough to attend a session with Dave Thomas, one of the original creators of the Agile Manifesto, er, "Manifesto for Agile Software Development Principles."

Four years ago, when I first became part of an agile team, we had very deliberate scrum retrospectives every sprint. We were new to agile and scrum, so we had a lot (A LOT) to work on, and a lot of new-found autonomy to stretch. Years later, when the original teams became autonomous to the point where they could facilitate their own retros, it was a breakthrough in autonomy.

There are a lot of things good about team-led retrospectives. The teams were used to hashing things out and coming up with action items, so they didn't need anyone to prompt them. Team members know right where the weak spots are, and don't have to use crafty measures to get there - they walk right in and go for the elephant in the room. Since many of the teams rotate the responsibility, they each participated heavily in retros facilitated by other, since they want others to participate heavily when it's their turn.

There are also several watch-outs for team-led retrospectives. While teams know about the elephants in the room, they are often too close to see the little elephants lurking in the corners. In addition, development led retros usually end up focusing on development and technical issues and only touch the surface of team and relationship related issues.

When you add in factors like time crunches, reluctance of teams to "play games," and just a plain boredom with retrospectives in general, I saw a need for a compact, flexible, effective way for teams to pick up a retro idea and run with it....get the action items on the table, then move on.

Rapid Retros is just that kind of kit. Stay tuned for further developments!