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

A Year in Review

The following post came to mind as I was writing my year-end self-evaluation, and provides a brief glimpse of where I started the year and how I got to where I am today.  This year has been filled with diverse challenges, including ongoing employee issues, the continued mindset of "get it out the door", another reorg of the IT department, and the real possibility of the commoditization of testing within IT. However, as is often the case, challenge spurs innovation. In preparing for working on the team's seven-year strategic plan, I stepped back from the day-to-day operations of my team, and took a critical look at the work we were doing and the services we performed. What I saw was that the testing services we were providing for the company were, in many cases, nearly indistinguishable from the testing services provided by alternative sourcing strategies, with the primary differentiator being cost, not quality. Seeing the threat of the commoditization of testing

Mission Statement, Definition of Software Testing, and Goals of Software Testing

Why I blog? What’s the difference between a good tester and a great tester? I think the main thing is the ability to think for yourself and to be able to incorporate your experiences as a tester back into the context of your testing practices.  I think that if you look at the software testing community and pay attention to who has good ideas and who does not, you’ll find that the vast majority of people with good ideas emphasize their experience, what they have learned from it, and how they incorporate that back into their testing. Writing about my thoughts and experiences in software testing provides an opportunity for me to take a critical look at what I thought about a subject, assess it in the context of experience and information gained since I first came to think that way, and then update or reaffirm my thoughts on the subject. It also allows me to share my thoughts, experiences, successes and failures with others, creating an additional feedback loop. That, to me, is one