Category Archives: lessons-learned

Interview with Tom Cagley re: Scaling Agile

I recently chatted with Tom Cagley on the Software Process and Measurement Podcast (SPaMCAST) about some of my experience helping scale operations at Halfaker using best practices from various business books (e.g. Good to Great), frameworks (e.g. CMMI), techniques (e.g. Agile Scrum), and tools (e.g. JIRA).  I really enjoyed our discussion on why I was excited to JIRA, a tool that is not very opinionated, so we could configure it in some specific ways for individual Halfaker departments and projects.

The SPaMCAST is a great resource for learning more from great thought leaders in the Agile, Process Improvement, and Software Engineering world. Check out the interview at:

And if you’re looking for a Podcast app recommendation, check out Castro for iPhone/iPad.  It has this great “Inbox” concept (works like an Agile backlog, where you can accept things into the backlog and then prioritize/re-prioritize them.


Are you Running in the Right Direction?

Early in my career, I was a leadership development conference (through Lockheed’s great Engineering Leadership Development Program), where we played a game called Gold of the Desert Kings  — it was a group game, in a big event space ballroom packed with engineers from all over the country.  I don’t remember the rules of the game, but I do remember that it was a powerful reminder of how important it is to plan before you start working.

It’s easy to say we should plan before we start doing work — people say things like that all the time:

  • Look before you leap
  • Measure twice, cut once
  • Cal Newport made this point on Ramit Sethi’s blog a while back
  • Agile Scrum “forces” people, every few weeks, to stop and assess where they’ve been (sprint demo), where they’re going (sprint planning), and how they could improve (sprint retrospective)

But while we talk about this often, most people often regress back to a tendency of “jumping in” under pressure, instead of taking a breath and investing the energy of actually building a plan.

At the individual level, people are very quick to start working, trying to “make progress” and “feel productive” without investing the time to validate that they’re working on the most valuable thing. When groups of people (teams) are involved, we’re even worse at this — not only does the team want to jump in to avoid the plan of group planning and not feeling productive, everyone wants everyone else on the team to be productive (busy) so they feel they’re not the only one working hard.  This creates this nasty culture where the team is trying to keep everyone busy (Instead, Goldratt’s The Goal teaches that we need to optimize the entire system, not at the individual person or machine level).

Yes the plan will change, but it’s not the first version of the plan is not the valuable part — it’s the exercise of pulling together all the different pieces of a project and thinking about them together that is valuable.

While making progress on some new task feels more rewarding and productive than building a plan, whether it’s an Agile backlog; a resource-leveled Microsoft Project file; and/or a few quick PowerPoint slides summarizing major activities, schedule, resources, and budget; INVEST the time to make a plan — make sure before you start sprinting in some direction that you’ve actually checked to see if that’s where you should be running.

Wait Time, or How Time Doesn’t Always Fly

A few years ago, we did a team building exercise at work which involved the group whiteboard_examplecollaborating on a vague project with no defined roles for any of us.  I think exercise was intended to show how different personality types could better collaborate, though I learned a very different lesson.

The group of about 15 people was given a vague task, and no leadership roles were assigned.  After what felt like roughly eternity happened, I jumped up to the whiteboard to start facilitating a discussion on how to tackle the challenge.  At the end of the exercise, the person leading the exercise asked me how long I felt like I waited before getting up.  I estimated something like 30 seconds.  I was quickly corrected that it was more like 3 seconds.  In the awkward (at least to me) silence of no one leading or coordinating, I jumped in to coordinate.  I regret not being more self-aware — I wish I could have let people who weren’t in leadership roles get to practice leading and facilitating.

My father, a career 6th grade school-teacher, always talked about the concept of Wait Time when I was growing up:

It can be extremely awkward when a teacher asks the class a question, and it’s met with nothing but crickets. Research has shown that in most classrooms, students are typically given less than one second to respond to a question, regardless of grade level. At the end of that second, some teachers break the silence by either expanding the question or providing the answer. Other teachers choose to cold call on a student for an answer, which typically results in a brief recall response or an embarrassed shrug.

This time period between the teacher’s question and the student response is called wait time…

The teaching concept of Wait Time talks about the need to allow enough time for people to think about a question and formulate an answer.  The concept of wait time should be applied both to letting someone answer and also ensuring that you don’t respond immediately, without thinking about what they said.  brian-regan

Brian Regan (a hilarious comedian) captured it well in his Me Monster bit, where people are trying to one-up each other, waiting for the other person’s lips to stop moving, so they can tell their story to impress everyone else.

Nobody likes the Me Monster, and nobody likes the person who can’t wait for a few seconds to hear what other people in the group think.