Metrics Don't Create Value - People Do
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.
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.
1. On a white board or other display, put up the following categories:
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.
Three Monkey graphic cut in three
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!
I attended my second Agile Gravy conference on September 29, 2016. This year, I was a presenter along with my partner in crime, Maggie. We were fortunate to have been chosen, as I understand a lot of speakers were turned down.
Keynote speaker: The keynote was the amazing Thiagi, of The Thiagi Group. The format was very free form, with a display of post-its on the screen containing topic suggestions, and Thiagi picking people at random out of the audience to choose a topic off the board or one of their own. There were a lot of nuggets of wisdom, including "It's failure only if you fail to learn from it." Prior to Thiagi's keynote, he sat at our table and we were able to share some jokes.
Agile Training: From Mundane to Mindblowing: This was the session I did with my cohort, Maggie. We have been working on this for a while, and it all came together so well. We had 57 people (standing room only) and everyone was engaged. We started off with a round of Ultimate Rock-Paper-Scissors, told our Monsanto training story, answered a whole bunch of questions, played Maggie's draw-guess game, and answered more questions. During the rock-paper-scissors, we were warned about the noise - everyone was having such a great time. It went extremely well, and we are basking in the memory of every moment!
Taming the Chaos: Bringing Agile to the Business with Little or No Process: I went to this one because, to me, "business" means customers. I wanted to know how to bring agile to customers. It was, in reality, "business" meaning a small business, probably IT. I was about ready to leave when Tom pulled out the Modern Agile wheel, and started talking about each section...however, he did it in an old PowerPoint, bullet point, lecture format which wasn't very modern. If we want people to understand something new, we have to present it in a new way. Everyone was excited about it and took photos and wrote down the initial info, but after a fashion, many left the room and I don't think they did so with a mind full of Modern Agile. I do think that Tom is an experienced and knowledgeable coach, and he believes in Modern Agile. The only feedback I have is to look at how you are presenting material, and see if it matches the material itself.
Truth, Transparency and Trust: John Sextro is a likable guy, and I can't think of anyone who wouldn't trust him, and feel comfortable around him to be open and transparent. So, he already had the audience on board. Many were still skeptical about how they could instill trust in their organization, but I hope they found a few things to help them bridge the gap just a little bit. John also went headlong into Modern Agile, but by helping the audience to understand the concepts first, and then giving them the link to find out more, which was a much more effective way to communicate that message.
Zombie Kanban Game:: I am not sure I learned anything new about Kanban, but I had a heck of a good time. I collaborated with three people that I didn't know, and we had about 30 story cards with tasks ranging from doing a Rubik's Cube to getting the team names of all of the other teams. We blew up balloons, then popped them, used yard to establish trade routes, and built a tower with marshmallows and skewers. It was a great way to show some Kanban-like collaboration and dependencies. Awesome game - very clever!
Closing Keynote & Remarks: Mike Cottemeyer, CEO & Founder, Leading Agile LLC spoke to me directly, or at least it seemed like it, about organizational transformation.. It was so applicable to my current job that I was mesmerized. He made very good points about being transparent to executives about what an agile transformation really is -- and that alone was worth the price of admission.
Overall: Great time, awesome networking, good food, well run. Can't wait for next year!
“A coach is someone who can give correction without causing resentment.”
― John Wooden
“I have a rule on my team: When we talk to one another, we look each other right in the eye, because I think it's tough to lie to somebody. You give respect to somebody.“ ― Mike Krzyzewski
“The interesting thing about coaching is that you have to trouble the comfortable, and comfort the troubled” – Ric Charlesworth
“Coaches have to watch for what they don’t want to see and listen to what they don’t want to hear” – John Madden
“Victory or defeat is not determined at the moment of crisis, but rather in the long and unspectacular period of preparation” – Anonymous
“Failure is never quite as frightening as regret” – Anonymous
“Nothing great was ever achieved without enthusiasm.” -- Bobby Knight – Henry David Thoreau
“You can motivate by fear, and you can motivate by reward. But both those methods are only temporary. The only lasting thing is self-motivation.” – Homer Rice
“My responsibility is leadership, and the minute I get negative, that is going to have an influence on my team.” – Don Shula
It was a normal Monday morning, not much to speak of. I walked into the building and greeted the security officer: "How was your weekend?" "Too short!" A shared laugh, and I was on my way upstairs to catch a conference call, a couple of daily stand-ups, and a coaching circle gathering. When nobody showed up to the circle, I decided to watch a video that a fellow coach pointed me to. He hadn't even watched it yet, but the topic looked interesting: Modern Agile.
For the next 40 minutes, I was mesmerized as Joshua Kerievsky, CEO of Industrial Logic, gave his Agile2016 keynote on his invention, Modern Agile. For months, I'd been tortured by the idea that somehow, some way, Scrum and the Agile Principles could be leaned down, but just couldn't put my finger on how. Little did I know, Kerievsky had it all worked out before I even started wondering.
Below is the Modern Agile spinner. No side is destined to remain on top, no side has precedence. He compared scrum and the agile manifesto/principles to an old laptop that looks just like mine (ouch!), and said it was time to put those old thoughts in in an agile senior home ("the food is great!"). I agree.
I immediately redesigned my Scrum/Agile Basics training around the four easy ideas above. No more will I walk through all twelve principles, explaining each on in detail to confused new hires. In the spirit of one of the discarded principles, the art of the work not done includes not having to make a "cheat sheet" for students so they can remember them. I'll post more as I used Modern Agile to lean my own processes, teams, and training. Stay tuned! This is just day one!
I'm an Agile Coach and Scrum Master in St. Louis, MO. I also do improv theater and stand-up comedy around town.