Who am I?

I’m an Agilist, a former software engineer, a gamer, an improviser, a podcaster emeritus, and a wine lover. Learn more.

Currently Consuming
  • The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
    The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
    by Eric Ries
  • The Talent Code: Greatness Isn't Born. It's Grown. Here's How.
    The Talent Code: Greatness Isn't Born. It's Grown. Here's How.
    by Daniel Coyle
  • Alexander Hamilton
    Alexander Hamilton
    by Ron Chernow

Paul Tevis

Entries in lean & agile (23)

Monday
Jan032011

Link Roundup For 3 January 2011

I've been on a programming nerdery kick recently. Here are some links to articles loosely around the themes of Test-Driven Development and Refactoring.

Sunday
Jan022011

In French, It's Trente-Cinq

Thirty-Five is a collaboration technique1 I learned from Lyssa Adkins at Agile 2010. She mentioned it in one of the sessions she was leading and didn't have time to include it but said she'd teach it in an Open Jam if anyone was interested. About a dozen of us were, so later in the week we got together and learned it.

After the conference was over, I flew from Orlando to Lausanne, Switzerland, where the Swiss and California parts of our new Scrum team were meeting for the first time. Parts of the California group had used Scrum before, but the Swiss folks were completely new to it. We were going to be there for a week and half, and we wanted to learn as much as possible in our time together. We knew the best way to learn Scrum is by doing it, so we decided to accelerate the process by doing very short cycles. That is, we decided to do two four-day Sprints so that the team could see the entire cycle twice while we where there. In addition getting people familiar with the ideas, artifacts, and rituals of the process, it would give us the opportunity to fix problems while we will still altogether. This meant that our retrospectives, particularly the first one, were going to need to do some heavy lifting.

I had been the Scrum Master for parts of the team on an earlier project, and we had had trouble with retrospectives, particularly when deciding what do to do.2 I knew there was even more potential for problems with a just-forming group that had no prior experience with retrospectives. I also knew that it was critical to identify targeted responses to problems and to demonstrate the potential of the process. Finally, I knew that there were several strong personalities in the group (some of whom held positions of authority) who could easily take over any discussion, whether they realized they were doing it or not.3

So when we got to the point in our retrospective were we needed to suggest potential actions to deal with the problems we'd identified, I used Thirty-Five. I asked everyone to write on an index card one specific thing we should do in the next sprint to make us a better team. They wrote their sentences, I explained the rules of the game, and I turned them loose.

During the closing of our retrospective, I asked for feedback. How did it go? What did people think? There were two clear answers: (1) "That was really useful," and (2) "That was really fun!" In the following four days we tackled the three items that Thirty-Five had told us were the best suggestions. After half of us went home to California and we found ourselves working as a distributed team, the way we had worked together laid the foundation for everything else we've done since. Six months later, I can see that our new, more collaborative, more productive way of working started with those eight days together in Lausanne.




1 Or really, a game.

2 I've had a lot of success with the Open-Gather Data-Generate Insights-Decide What To Do-Close model from Agile Retrospectives.

3 One of them was me.

Saturday
Jan012011

The Team Has The Answers

At Agile 2010, I had the good fortune to take part in several workshops with Lyssa Adkins. Her session on “Using Silent Work Techniques To Get Astonishing Results” helped me connect the improv and Agile parts of my brain. The Thirty-Five technique1 she taught us in a Open Jam paid immediate dividends when I used it in our retrospectives in Switzerland. Her insights in Gil Broza and David Spann’s workshop on “The Curious, Present, and Empathetic Agile Coach” made me aware of the kinds of skills I want to develop. So I was happy that by early December I was able to clear my decks enough to read her book.

Coaching Agile Teams: A Guide for Scrum Masters, Agile Coaches, and Project Managers in Transition has at its core a simple idea: “Take it to the team.” Like all simple and powerful ideas, it’s harder to do, especially when it requires overcoming existing habits and instincts. While I don’t have decades of experience as a command-and-control-style project manager, I still do things that get in the way of the team’s self-organization. Thankfully, the first section of the book deals with exactly this, pointing out that coaching starts with you; in order to master coaching, you first have to master yourself.

The core of the book is part two, which deals with what Lyssa has identified as the six skills sets Agile coaches need to develop in order to be successful: coaching-mentoring, facilitating, teaching, problem solving, conflict navigating, and collaboration conducting. Each of these chapters looks at the Agile coach from a different angle, examining what skills from related disciplines we can borrow to help our teams get more for themselves. Mixed in with this is a healthy dose of Scrum knowledge, ranging from observations on purposes of the Scrum meetings to advice on avoiding confusion about (and conflict between) the Product Owner, Agile Manager, and Agile Coach roles. As such, the chapters on facilitating and teaching make up one of the best resources I’ve seen for Scrum Masters, regardless of whether they consider themselves coaches. My favorite chapter focuses on the coach as “collaboration conductor.”2 The principles for fostering a collaborative environment presented here are clearly the tip of a fascinating iceberg, and the cited references are quickly climbing my “to read” list.3

The final section looks at the coaching trajectory, helping to assess where along it you are. Included are six first-person accounts of how current agile coaches got to where they are now, starting from very different places.4 The most useful chapter for me dealt with diagnosing common coaching failure modes and pointing out what success can look like. Agile coaching, like Agile itself, is a journey rather than a destination. Coaching Agile Teams is an excellent map of the terrain.




1 Which I recently discovered is a Thiagi invention.

2 Which should surprise no one who knows me.

3 Notably Artful Making, Teamwork Is An Individual Skill, Radical Collaboration, and Collaboration Explained.

4 One of them started from a place very much like my current situation, which certainly piqued my interest.

Page 1 ... 1 2 3 4 5