Skip to main content

Takeaways from Our First Lean Coffee

I've noticed over the past several months that the team’s Monday morning weekly kick-off meeting was becoming more and more ineffectual. It originally began with the idea of getting team members interested and involved in the projects and tasks their team mates were working on, allowing the opportunity to meet, provide input and insight, and take a break from their own projects. What it degenerated into was a high-level review of Friday’s weekly report. It wasn't quite as bad as some of those daily stand-ups I've attended where team members point at the board and mumble “Yesterday I worked on that. Today I will work on this. No obstacles.” However, it was certainly getting close. We would occasionally find the rare nugget of information that wasn't reported on Friday, but it was certainly failing to meet its initial charter. It had been my idea, and I had the responsibility to either make it work or cancel it.

I had spoken with the team a few weeks ago, asking if they wanted to cancel the meeting, citing a lack of ROI and better use of their time, yet each one voted to keep it going. I gave it a little more time, noticing that they still really weren't that into it. I kept going back to the juxtaposition of the vote to continue holding the meeting and the apparent lack of engagement and effective communication in the meeting. That, to me, signaled that the team really wanted to communicate, but the outlet provided by the meeting wasn't the proper outlet for that. But what was? What was lacking in this meeting?

I tried to think of other, more productive uses of everyone’s time. I toyed with the idea of making the Monday morning rounds to their desks to talk about their projects, taking up only as much of their individual time as needed. That sounded like a pretty good use of everyone’s time, and would allow me to get the information I was after, but it didn't allow them to interact or perceive new ideas. I kept trying to think of other ways to get engagement from the team, but was unable to identify any viable solutions. Until CAST2013.

I was watching the twitter feed during CAST2013, and started seeing tweet after tweet about the Lean Coffee. Lean Coffee? Really? I didn't recall ever having heard about Lean Coffee before, so I did a little research and quickly became intrigued. Lean coffee sounded simple. It sounded relevant. I asked peers if they had any experience with holding a Lean Coffee, and received some very favorable responses.

Last week was the last time we held our status meeting. I canceled the meeting in Outlook and scheduled the Lean Coffee for the same time slot and place, providing a link to leancoffe.org and a YouTube video that talked about the mechanics while showing a Lean Coffee in progress. I was expecting a slow start with a smattering of topics provided as the team figured out how everything worked without an agenda, what we were going to talk about, even what we could talk about.

This week, we started our Lean Coffee. This week, the results were truly outstanding. The team was engaged, they provided excellent topics, they discussed each topic excitedly (often voting to continue the discussion), and they voluntarily extended the meeting an additional thirty minutes to address additional topics. When we finally concluded the meeting, we had resolved several topics, identified three longer-term action items to be addressed outside of the Lean Coffee, modified the board to better address the longer-term action items, and everyone left that meeting still talking excitedly, including me.

I knew that the Lean Coffee had hit on something, but I was unsure about what, exactly, that was. Later, after I had time to pause and reflect on our first Lean Coffee, I realized that there were several factors that made our move to Lean Coffee a success.

Although I had made the connection between the vote to continue the Monday meeting and the continued ineffectiveness of the meeting to address its charter, I had not understood what the relationship was. Ultimately, the meeting was not valuable to the team because it did not address their needs and concerns; most meetings do not address the needs of the attendees, they address the needs of the meeting organizer. So, there we were, every Monday, using up valuable time, including a portion of the limited face-time they have with me, their manager, and I was not addressing their needs and concerns, I was addressing mine and what I thought theirs were. So, the team’s perception has been that the meeting was neither relevant nor timely to them.

A second takeaway was that the best way to get the team engaged in a meeting is to have them help generate the meeting’s agenda. The team was eager to discuss new concepts and thoughts on improving our test efforts when they were provided in context of their concerns and the issues they were currently facing because they were both pertinent and timely. Helping to create the meetings agenda also gives the team a sense of ownership in the meeting and therefore responsible for the success of the meeting. It also demonstrates that management not only values their involvement and their contributions to improving our testing efforts, but is actively pursuing their input. That, to me, is truly vital. Even a good self-organizing team doesn't want to be self-organizing in isolation. They welcome and seek out management’s involvement throughout the organizational process.


These insights were just from our first Lean Coffee, and I’m very excited to see what happens next. I've already seen one team lead propose changing the team’s weekly meeting to a Lean Coffee, and another has proposed using a Lean Coffee format to present a portion of our seven year strategic plan to our management team. That’s what I call engagement!

Comments

Popular posts from this blog

Takeaways from the Continuous Automated Testing Tutorial at CAST2014

I had the opportunity to attend Noah Sussman's tutorial on Continuous Automated Testing last week as part of CAST2014. It was a great tutorial, with most of the morning spent on the theory and concepts behind continuous automated testing, and the afternoon spent with some hands-on exercises. I think that Noah really understands the problems associated with test automation in an agile environment, and the solutions that he presented in his tutorial show the true depth of his understanding of, and insight into, those problems. Here are some of the main highlights and takeaways that I got from his tutorial at CAST2014. Key Concepts Design Tools – QA and testing are design tools, and the purpose of software testing is to design systems that are deterministic Efficiency-to-Thoroughness-Trade-Offs – (ETTO) We do not always pick the best option, we pick the one that best meets the immediate needs Ironies of automation – Automation makes things more complex and, while tools can make...

Let’s Continue to Drive Software Testing Education Forward

It’s Time to Embrace the Student Who Learns Differently Last in a series. In my last two posts I’ve written about enhancing the student and instructor experience in the AST’s BBST courses by focusing on updating the Fieldstones and making BBST courses more accessible by identifying some of the more common obstacles to BBST participation, and then working collectively to find ways to lower or remove those obstacles. In this post, I want to discuss the third and final area I would like to concentrate on if elected to the Board of Directors: researching and establishing alternate approaches to teaching that better suit different learning styles. As members of the AST, we have access to some of the best information and training available in the field of software testing. The AST hosts the Conference of the Association for Software Testing (CAST) each year, providing full-day tutorials, keynotes, and track sessions. They also offer four separate BBST courses:  Foundations, ...

Book Review - The Shape of Actions: What Humans and Machines Can Do

If you’re a tester and you’ve been around social media, attended a conference, watched a webinar, read blog posts, or watched videos of other testers speaking on YouTube, you may have heard at least one mention of polimorphic and/or mimeomorphic actions. But what does it mean when someone says that an action is polimorphic or mimeomorphic? Where do these ideas come from, and why, as testers, do we care? The concepts of polimorphic and mimeomorphic actions come from the book The Shape of Actions: What Humans and Machines Can Do, by Harry Collins and Martin Kusch. In the book the authors develop a new theory about what they call the shape of actions. I’ve attempted to cover the highlights and general topics of discussion, or at least what I found most interesting, from each chapter in the summary below. Chapter 1 – Humans and Machines In Chapter 1, Collins and Kusch introduce the reader to their theory which basically states that humans can do three things – they can do polimorp...