Whip Your Backlog into Shape!

Remember the band Devo and those red hats they wore during the music video for “Whip It?” Me too. Devo and those red hats came to mind recently while I was preparing to deliver a Scrum training.

It was Saturday night, and like most people, I was reading the Scrum Guide. I was thinking about a different way to explain Product Backlog items. In the past, I’d used the acronym DOVE, but it just didn’t “spark joy” for me. For those of you who don’t spend your Saturday evenings reading the Scrum Guide, it states that “Product Backlog items have the attributes of a description, order, estimate, and value.”

I shuffled the letters around and landed on DEVO. Hmm… interesting, I thought. The hamster got on the wheel and it all started to come together. DEVO, I thought… those guys wore the red hats that were bigger at the bottom and smaller at the top.

It reminded me of the classic image you see in all Scrum trainings when you’re learning about the Product Backlog. The one that shows the big blocks at the bottom and the smaller blocks at the top. It’s a fine image, but it doesn’t have a theme song… WHIP IT!

So there you have it. Here is a new way to think of and explain the Product Backlog and its items. The items tend to be larger at the bottom and get smaller at the top, just like the Devo hats. And Product Backlog items should have the attributes of:

D escription

E stimate

V alue

O rder

Now, on Saturday nights, I won’t just read the Scrum Guide. I’ll read it while listening to Devo… Whip it! Whip it good!

The Agile Alphabet, Part 2

In my last article, I started an agile alphabet of terms commonly used when working with agile teams. This article finishes the alphabet.

N is for neuroscience

Neuroscience seeks to understand the human brain and how it functions, including how we learn. If we can better understand how humans learn, we can adapt our approaches to training, communicating, providing feedback, and all sorts of other interactions, which can help us more effectively deliver new concepts, build high-performing teams, and develop more empathy for one another.

O is for OpenSpace

OpenSpace Agility is a meeting format that invites participants to gather for a discussion, create agendas, and choose what topics to spend their time and energy discussing. It encourages emergence and self-organization of ideas, and it’s often used at agile conferences.

P is for personal care

How often do you put others’ needs before your own? How often do you feel burned out and continue to behave in a way that adds fuel to the fire, leading to more burnout? Personal care is the idea that in order to help and support others, you must help and support yourself first.

Q is for quality

Quality is often overlooked and undervalued on agile teams. We trade short-term “wins” for long-term instability. We take shortcuts to hit a deadline and end up having a codebase that is fragile, unmanageable, and fraught with technical debt. We need to change the conversation to focus on quality and the idea that sometimes, we need to go slow in order to go fast.

R is for Radical Candor

Radical Candor is a framework for giving feedback based on a graph with “Care personally” and “Challenge directly” as its axes. This creates the quadrants of Ruinous Empathy, when you care but don’t challenge, giving praise or criticism that isn’t constructive; Manipulative Insincerity, when you neither care nor challenge, giving unclear praise or criticism; Obnoxious Aggression, when you challenge but don’t care, giving praise or criticism unkindly; and, finally, the ideal Radical Candor: saying what you think while still caring about the person receiving the feedback. We should seek to provide Radical Candor in order to communicate effectively.

S is for Scrum

I have always been a proponent of Scrum, but over the past couple of years I have seen teams overlook the basics of Scrum and believe they are more mature than they actually are. I often hear people provide excuses for why the manager needs to tell the team what to do, or why the ScrumMaster should be an enforcer for hitting the deadline, or why we only need to do retrospectives once per quarter because “everything is fine.” It can be really hard to practice Scrum because of ingrained behaviors or organizational constraints, but Scrum has been proven to be very effective, so if we can focus on overcoming those challenges, we will be able to increase the delivery of customer value.

T is for Training from the Back of the Room

This is a training technique where participants learn using the four C’s: connections, where participants try to connect with the topic based on what they think they know; concepts, where participants receive direct instruction from the presenter about the topic; concrete practice, where participants do exercises or discuss topics to get a more thorough understanding of the material; and conclusions, where participants summarize what they have learned and how they will put the learnings into action, proving that they have absorbed the material.

U is for users

Too often teams and organizations get caught up in the details about process or the constraints of software tools and forget about the users. Users are who we build products for, so let’s try to get as close to them as possible, shorten feedback loops, and understand what would delight them.

V is for value

I’ve had a lot of different work streams lately that have made it difficult to focus, so I’ve been thinking a lot about being lean and eliminating waste. When you’re short on time and have a lot of competing priorities, making sure to focus on items that are adding value is crucial. If it’s not adding value, should we be doing it?

W is for WAIT

I learned about this acronym at an Organization and Relationship Systems Coaching class. It stands for Why Am I Talking? It’s great for those of us—like me—who could improve their listening skills. If I truly want to hear what another person is saying so that I can be fully present and understand, instead of just thinking about what I’m going to say next, I need to WAIT.

X is for XP

X is for XP, because what else starts with X? But seriously, more agile teams should focus on Extreme Programming and bringing more technical practices back into the agile world. I believe that more teams could benefit from pair programming, coding standards, continuous integration, and test-driven development.

Y is for “Yes, and …”

Years ago in an improv class with the famed Second City group, I learned the “Yes, and” communication technique. Simply saying “no” is a great way to kill an idea or shut someone down. A close second to that is “Yes, but.” Even if you disagree with something, you can use “Yes, and” to object but keep the conversation going. It’s a helpful tool in keeping discussions alive and building on ideas.

Z is for Zen

In the past couple of years, I have been much more focused on meditation and inner calmness as a way to focus. It helps block out distractions, and I become more in tune with my goals and priorities, take my mind off my hectic schedule, and recenter.

What words would you use in your agile alphabet?

The Agile Alphabet, Part 1

I have a young daughter, so the alphabet is a big part of my life. I thought it would be fun to create an alphabet with some agile terms that have been on my mind lately. Here is the agile alphabet from A to M.

A is for agile mindset

Agile is not something you buy and install. It’s a mindset: a way of thinking, a way of being, and, usually, a pretty big cultural shift. Holding a daily scrum and transitioning project managers to ScrumMasters does not “make you agile.” You have to live the agile values and principles.

B is for business agility

It seems like a buzzword these days, but business agility is important and can lead to high-performing organizations. Spreading the agile mindset throughout the entire organization can help different departments work better together. Agility enables the organization to adapt to change, become more innovative, and better satisfy customers.

C is for clean language

Clean language is a way of communicating based on not making assumptions; you respond to what was actually said by using the same words to eliminate bias or misinterpretation, instead of going on what you interpreted. It’s an interesting and useful way to frame conversations.

D is for define

When I think of the word define, I think of clarity. Defining what “ready” and “done” mean provide teams with clarity around what should be built. Defining a vision provides clarity for where a company is headed or gives a team an understanding of what the long-term goal is. Defining roles adds clarity about expectations and responsibilities.

E is for emergence

Emergence is allowing ideas to come naturally instead of forcing things. This is something I struggle with at times because I like to plan and can become impatient. But when ideas or solutions do emerge, it can harvest long-lasting results because people tend to be more connected and buy into them more, as opposed to when they are simply told to do something. Emergence requires high levels of trust in individuals, the system, and the team.

F is for feedback

Giving and receiving feedback is critical to improving ourselves, our teams, and our organizations and products. Yet, so often, we become defensive and don’t enter conversations with an open mind. How can we put bias and judgment aside and welcome feedback as a gift? And how can we provide feedback in a way that is constructive, not harmful?

G is for gemba walk

Gemba is a Japanese term meaning “the real place,” so a gemba walk refers to going to where the real work happens and observing it firsthand. If we are trying to optimize the system, we would not make assumptions about how the system flows. We would go to the various places where the work happens, observe, and talk to those doing the work.

H is for healing

I have seen far too much division and divisiveness in the agile community—friendships destroyed, manipulation, untruths, and egos gone wild. It’s unfortunate, and hopefully through communication and understanding, we can bring some much-needed healing to the community.

I is for intent

Piggybacking on healing is intent—specifically, positive intent. Wouldn’t it be great if we could have a mindset where we assume positive intent during interactions with others? How could that change the conversation, or the way we interact in that conversation? How would it change the direction and outcome of that conversation?

J is for Jerry and jamming

This refers to Jerry Weinberg and David Hussman (of DevJam), two industry giants who recently passed away. Both had a huge impact on the agile world. I did not know either of them personally, but I have studied their works, learned a lot from them, and heard many stories from people who knew them. To me, this is a reminder to have interesting conversations, learn from people in as many ways as you can, and be curious about life.

K is for kaizen

Kaizen is a Japanese term for improvement. Focusing on continuous improvement is one of the most important things teams can do. Within Scrum, there are events that provide opportunities to inspect and adapt at different levels. I have worked with colleagues to create a continuous improvement board and kaizen meetings at the organizational level, and as an individual, I have a backlog of items to help myself grow as a coach and trainer.

L is for liberating structures

Liberating structures are a group of immersive, collaborative activities and exercises that can be used as alternative ways to facilitate meetings and conversations. They break away from the typical styles such as presentations, status reports, or brainstorming in order to decentralize control and be more inclusive toward empowering those involved.

M is for “Maybe I’m the problem”

When having a conflict or disagreement, I try to take a strong look at whether I’m the problem. It’s easy to jump to conclusions and assume that we are right and the other person is wrong and that they need to change their position. But when we take a step back and consider that the problem may lie within, it helps us see another point of view and builds empathy for those we engage with. Try to consider that you may be the problem before you dig your heels in too far.

The second half of the alphabet is coming in the next article. What agile terms resonate with you and your journey?

Agile Coaching Summit and Open Space

Eyes wide open and overflowing with learning.

That is how I felt after I walked away from my first multi-day Open Space event – the 2014 Agile Coach Camp in Indianapolis. I had never experienced an “unconference,” so it was very cool to see how everything emerged organically. The attendees themselves created the agenda each day and a lot of “hallway” conversations took place. The event embodied empowerment and I have since attended at least one Open Space event each year.

Which brings me to 2018. I would like to share an Open Space event that my friend and colleague – Emilio Perez – and I are hosting: The Agile Coaching Summit in Chicago. Friday 10/19 will be an evening networking event and the Open Space will be Saturday 10/20 and Sunday 10/21.

If you’ve never experienced Open Space, here is a quick rundown on how it works…

There is a grid – called the marketplace – with one axis listing locations (Room A, Room B, The Couches, etc) and the other axis listing time slots (10:00 – 10:50, 11 – 11:50, etc). For each cell in the grid, there is a blank space.

This is where you come in. If there is a burning topic on your mind that you’d like to share, a challenge you are facing at work or a question you’d like to discuss…simply write that topic on a sheet of paper, announce it to the group and place it somewhere on the grid (For example… Topic: “Should a Scrum Master participate in the retrospective?” // Time: 10:00am – 10:50am // Location: Room B). That means if people want to talk or learn about whether Scrum Masters should participate in a retrospective, they could go to Room B at 10:00am.

There is also the Law of Two Feet (or Personal Mobility). This means that if you are not learning or contributing or finding value at a session, you are encouraged to find a place where you can learn or contribute or find value.

There is more to Open Space than the Law of Two Feet and the marketplace, but it is inherently simple and relies on self-organization. The open format brings a lot of passion and engagement because the attendees themselves create the agenda that interests them the most.

So whether it’s your first Open Space or you are a veteran, please join us… and bring your topics!

Get your ticket: https://www.eventbrite.com/e/agile-coaching-summit-2018-chicago-tickets-47829034931

Applying Agile to Life: Taking Retrospectives outside the Workplace

Summary: 

A lot of what agile teams do can be used effectively outside software development teams, and even outside the typical business organization. For instance, retrospectives and the practice of talking about what went well, what you should keep doing, and what can be improved can be applied anywhere—even to families. Read on to learn how to bring continuous improvement into your daily life.

I regularly tell people that I view agility as a mindset rather than frameworks, practices, ceremonies, or roles. Consequently, I believe that a lot of what agile teams do can be used effectively outside software development, and even outside the typical business organization.

My company’s agile practices group facilitates retrospectives not just with development teams, but also with the people team, UX research, customer delivery and implementation, and recruiting, just to name a few departments.

With that in mind, I recently had an idea to try something new. Over the New Year’s Eve weekend, my wife, daughter, and I spent a few days with my parents and my brother’s family (wife, son, and daughter). On day one, I asked my family members what they thought about having a retrospective at the end of our time together. Because most of them didn’t know what a retrospective was, I briefly explained the concept, purpose, and execution. Everyone was on board with trying it out.

The idea had come to me after hosting family members at my house for a weekend earlier in the year. As someone who is always thinking about continuous improvement, I had noticed a few things that could have made the weekend better for us all. My wife and I had a quick retrospective and shared ideas about what we liked and what could have been done differently, like me helping more with the dishes. It made me realize how beneficial a retrospective could be outside my work context, which convinced me to try it out at the next opportunity.

On the last day of New Year’s Eve weekend, I gathered everyone together in the family room. The group of eight ranged in age from seven to sixty-four. I started by asking who had taken part in a retrospective before. My brother, who is a fellow agile coach, and my wife had, but it was interesting to find out that my eleven-year-old nephew had participated in one at school, too. I then explained at a high level the purpose of retrospectives—how we would collect the data, the discussions we would have to dig deeper into topics, and what we would try to achieve as an output.

Next, I created two columns on cabinet doors by placing stickies up high with the words “What went well?” on one and “What could be improved?” on the other. Earlier in the day I had populated some stickies with my thoughts about the weekend, so I put them on the cabinet as examples to ensure everyone had a shared understanding of what to do. I gave some brief context to each of my stickies, asked if anyone had questions, and then put ten minutes on the timer to allow people to capture their ideas on their stickies.

After time was up, everyone added their stickies to the cabinet doors and gave a brief explanation of their thoughts. Occasionally someone would ask for clarification. As the stickies were placed on the cabinets, we grouped similar themes so we could easily tell what were hot topics to dive into.

We had some great discussions. At times it was funny and other times it got a bit emotional. There were some valuable insights and recommendations. People volunteered to take on actions and captured them on sticky notes so they could remember to follow up.

There were some great improvements we suggested:

  • We found that some people want to get out of the house more, so a couple of us took on action items to investigate activities for next year (museums, shopping, go to a movie, etc.)
  • My nephew said he didn’t want to go to an Italian restaurant again for New Year’s Eve dinner because we’ve done that two years in a row. He also said that the long table at dinner wasn’t great for communication because it was hard for people at the ends to talk to one another. So next year we’ll be eating at a round table not in an Italian restaurant
  • Some were not interested in the same old board games, so one person took the action to review the game cabinet, and others will bring games from their houses
  • Multiple people thought it was too cold outside, so we are considering going to Mexico next year!
  • My niece even said the toilet paper feels like sandpaper and they need to have softer toilet paper. Someone else who lives in the house agreed! Despite living in the same house and using the same toilet paper, they had never discussed it

When I originally proposed the idea, I wasn’t sure what to expect; it seemed like it might be a bit silly. But everyone was engaged and had fun with the retrospective, and we came away with some great action items for improving our times together— and our next gathering will be better because of it.

This real-world example just demonstrates the universal power of retrospectives. How have you incorporated agility into your life outside the workplace?

This article was published at AgileConnection.com on 5/23/2018.

Using Sprints for Agile Coaching

I recently stepped into a new role where I am now responsible for moving high-level, organization-wide initiatives forward. At the same time, I was trying to increase engagement within the Agile Practices group of agile coaches and ScrumMasters. I wasn’t sure of the best way to get the work done, but I had an idea: Why not use the same agile process we ask our development teams to use?

We could form a team, create a backlog, estimate how much work we could get done in a sprint, do the work, show off the work, get feedback, and then talk about how we could improve. It wasn’t exactly an original idea, but I thought it could be an interesting approach.

I started by identifying the first area of focus, which turned out to be improving the ScrumMaster hiring process. After learning more about the current process and discussing with others, it seemed like clarity could be added around expectations while making the new process more experiential and focusing on involving the right people.

I was looking to form a team to make this process better, and fortunately, four agile coaches with very different styles said they would be interested in helping. Three of them confirmed that they would be able to put in some effort over the next two weeks, although we ended up changing the sprint length to one week.

Regarding the sprint length, we discussed and decided that because this was a side project, a shorter sprint length would help us focus and not procrastinate. For all of us, this was not our primary responsibility, but we agreed that we could spend time working on it. “After all,” someone said, “hiring is the most important decision we can make.”

Acting as the product owner, I wrote user stories about getting a shared understanding between product and engineering expectations, minimum requirements for potential candidates, various hands-on exercises, and several others. After adding acceptance criteria, I shared the stories with the agile coaches team for review before our first sprint planning meeting.

In sprint planning, we reviewed the stories, discussed them, edited and added to them, reprioritized, and wrote new stories. The feedback from the other coaches was extremely helpful, and the stories and backlog were in better shape because of it. Collaborating to get a shared understanding of the work was beneficial, and the conversations we had gave us a whole new perspective on what we were trying to achieve. Each person brought a unique view for what they thought was important and what could be done to get the most value out of the interview process.

Next, we estimated how many stories we thought we could complete, then discussed how we would get the work done. Even though we weren’t coding anything or dealing with legacy systems, we knew that unforeseen obstacles would come up, so we took that into account. Considering there were four team members and the work was relatively new to all of us, we decided to pair on our stories throughout the week.

During the week, each pair found a couple of times to collaborate and work through their stories. It was fun and energizing to bounce ideas off each other and consider new ways to approach problems, while knowing that we were creating a structure that would benefit all of us in the long run. Having great coworkers would benefit our Agile Practices group, our teams, and the organization, so keeping that in mind was motivation to focus on being creative but also pragmatic.

Near the end of the week we got back together and showed each other what we had accomplished. There was some feedback and discussion, and everyone was happy with the progress that was made. We updated the backlog to reflect the feedback and found that some of the stories were no longer relevant, so we removed them. Shortly after, we reconvened to have a quick retrospective, where we discussed some insights into how we could improve the process. We noted a couple of action items and even changed a story in the backlog based on the retrospective discussion.

We still had some work to do, so the following week we met to refine the stories. We continued the process until we were happy with the new ScrumMaster hiring process.

Overall, the agile coaches group thought it was a nice way to organize the work that was being done, keep people focused, and deliver value. It also gave us an appreciation for the way we encourage our teams to work. Discussing the work to be done as a group, building in short iterations, getting feedback, and looking for ways to improve are not just practices for development teams—it is an effective way to achieve any goal.

We followed through with improving the process, and eventually we hired a talented ScrumMaster. That person has done a great job of supporting their teams and contributing to the larger Agile Practices group. We even had a retrospective about the new process that they experienced and discovered even more ways to improve.

The learning never ends, so of course, we continue to iterate.

This article was published at AgileConnection.com on 11/8/2017.

Code Health Kaizen

For the last year, teams within an organization I have been working with have been taking team health surveys on a monthly basis. The survey invites teams to evaluate themselves on categories such as backlog health, continuous improvement, collaboration, and the release process.

Typically, the survey data is used in team retrospectives to focus on what is going well and what can be improved, as well as to view trends. A number of people have asked how we could use the data to tackle organization-wide issues that affect all teams. After some thought, I decided to engage a group of interested individuals to discuss how we could focus on one issue and improve.

The issue of code health was chosen for a few reasons:

  • It consistently ranked in the bottom five categories in team surveys
  • Code health is something that engineers have control over and can improve
  • Leadership does not need to be involved in improvements, making them easier to adopt

We decided to schedule time for an open discussion and invited anyone who wanted to attend. I planned for the event by having a loose structure and some ideas but made sure to leave space for the participants to help set the agenda.

Brainstorming and Planning Actions

We held a one-hour discussion over lunch in order to minimize conflicts. About fifty people attended, which made the meeting standing room only.

I facilitated the discussion, and we started by talking about what everyone in the room wanted to get out of the session. After discussing goals, we documented them on a whiteboard wall.

Next, the group developed an agenda, which was also written on the wall. I wanted to be able to come back to the agenda generated by the group to show that this meeting was for them.

After creating the agenda, wehad a brief discussion about what it means to have good code health. The group had strong opinions—some ideas piggybacked on others, and some led to disagreements, but one thing was sure: we could have had a great discussion for hours. 

Next, we used the Circles and Soup innovation game for retrospective analysis to identify what issues were in our control, what we could influence, and what we had to live with. People wrote ideas on sticky notes and grouped them, and then we talked about some of the higher-level themes.

Some of the back-and-forth discussion that followed led to ideas for actions, and a few people felt passionate and motivated enough to volunteer to own those actions. Others pointed out that code health should start at the team level, not with organizational initiatives, which was a fair point.

Near the end of the session, I asked the group what comes next. As in any retrospective, you don’t want a complaining session—you want to identify measurable actions to be worked on in an effort to make improvements. One engineer spoke up and said that we should get together again in a month to check in on our progress. I offered to own that action.

Before closing the session, I went back to the list of goals the group had come up with to see if we’d addressed everything. We didn’t get to all the items, but we did get through five of six.

Overall, the discussion went well, and it felt great to have several actions and specific owners for them. It was also nice knowing that people wanted to get back together and follow up. Despite differing viewpoints, this topic had sparked a great deal of interest.

Turning Ideas into Outcomes

There was a buzz about code health after the session, and it didn’t take long for people to start taking action. One group led a charge to roll out a new testing framework to all teams. An engineer started working to standardize the README files in all repositories. Another engineer contacted me about starting a book club for continuing education. Another group formed, calling themselves Engineering Education, with the goal of spreading engineering knowledge throughout the company and offering a forum for learning. There was an organic, bottom-up movement unfolding, and it was great to see.

During the original code health discussion, there was skepticism about how much leadership actually bought into the importance of code health. I knew from discussions with leadership that it was very important. I also knew from previous initiatives that bottom-up efforts can be strengthened by top-down support, so I worked with leadership to craft a message that demonstrated their support for healthy code.

After a couple of weeks, it was clear that the Engineering Education group was gaining steam. They had a Slack channel and weekly meetings. They organized tech talks with strong attendance and powerful discussions. They created a team spotlight, where a member of the Engineering Education group would interview a product development team and the information was sent out in an email. The content included a picture of the team, team member names, what they worked on, applications supported, languages and frameworks used, some challenges they faced, approaches to improving code quality, and what they could help other teams with.

When I attended an Engineering Education meeting,I was happy to see considerable attendance. The group had a backlog of items they went through, providing updates. Discussions followed about what could be done to move items forward and about new ideas.

After the month had passed, we had the follow-up session to discuss the progress of code health initiatives. It was decided that the Engineering Education group would lead the way. All the other initiatives had grouped under that umbrella, and it was a natural way for everyone to keep a pulse on what was happening and how to get involved.

Maintaining Momentum

The next steps for the group include promoting themselves (via word of mouth, internal newsletters, digital signage, and posters), getting involved with new hire orientation, and possibly creating courses for the company’s continuing education program.

I really enjoyed watching the different groups and initiatives form and then ultimately come together in solidarity. To me, it demonstrated what can happen when people are passionate and have the autonomy to be self-directed. The team health survey simply provided data and insights. But those insights led to a conversation that motivated and empowered people to share, learn, and improve themselves, their teams, and the organization.

This article was published at AgileConnection.com on 8/9/2017.