Releasing the Brakes

front brake

One challenge of working within a large organization is that there are lots of people with control of the brakes and few people protecting the champions who are trying to affect change. I realize there is a need for occasional braking, but too much pressure on the brakes could lead to a very slow moving organization and will eventually suffocate out the innovators.

How do you fix this? I think it is a trust issue. I think the book Five Dysfunctions of a Team agrees with this. Perhaps my next book should be The SPEED of Trust.

Right now, I’m applying principles of the Dysfunctions book to facilitate better trust between myself and colleagues, and between the members of my team. It forces me to be brutally honest about things, to speak up, and to allow myself to be vulnerable.

Does anyone have any experience in this arena?

Photo by gabork


Photo By: Jim Lange

Earlier this month, Ryan Money gave a keynote address talking about some challenges he sees in working within a large corporation vs a start-up. Having come from the start-up world, I could relate with some of the frustrations he has also experienced while moving into big corporations. One of the challenges he talked about was Ownership, which I believe is a huge factor in the success of an organization.

Within a large organization, it is easy to get caught up in our own silos with tunnel vision on the things that we work on. We work tirelessly to empty the queue of work that is given to us individually or as a team, but we rarely step back to think of how our work integrates with the rest of the organization.

It is easy to look at things that are wrong that are “not my job” and do nothing about it. Today, I almost passed up reporting a typo on a survey thinking “that’s not my job”, but I decided to take some responsibility for our products (all of them) and took a screenshot and forwarded it to the people who could fix it.

I manage a few people that do a great job of taking ownership of things. I’m grateful to work with those people.

Agile 2011 Takeaways

Big Wave Surfer

It’s been a great week at the Agile 2011 Conference. I’ve attended a lot of really good sessions, a few awesome sessions, and luckily only a couple of “meh” presentations. I feel like my mind has been expanded greatly and I’m very excited to come back to the office with some of the new things that I’ve learned.

Here are some of my key takeaways:

Self-Organizing Teams

The team decides how they will work together, they set rules, and work together in ways that will help the team succeed. Managers empower, facilitate, communicate the “big picture”, set vision and goals, and remove impediments.

Focus on Strengths

By focusing on the strengths of the teams, the team members can use their skills to the best of their abilities. This can be done by letting the team members pick their own tasks and share their strengths or abilities with others. By focusing on individual strengths and working on building those strengths, the individuals will grow faster than by focusing on weaknesses.

People Are Motivated by Autonomy, Purpose, and Mastery

When an employee is compensated fairly, autonomy, purpose, and mastery become much greater motivators than $$$. Money motivations are actually detrimental to knowledge workers. They begin focusing on the wrong things and their work is lower quality. By giving knowledge workers the ability to master skills, have the autonomy to determine their course, and a higher purpose, employees will be motivated to build great things.

Daily Scrums Can Be More Effective

Daily scrums can be more effective by setting the context at the beginning of the stand-up. For example, including things like 1) who will be out of the office during the week 2) stories that must be completed that week 3) days left of the sprint

Kanban + Scrum for Maintenance Teams

For maintenance engineering teams, putting Kanban together with Scrum Sprints can be a very effective method of work. My team has constantly faced challenges of Customer Crisis disrupting our sprints and making it difficult to accurately commit to work that will be completed during the sprint. Making the sprints smaller can help because you can more easily commit to what you will complete during the week. If crisis items need to take priority, that is fine and because you are limiting your WIP (work in progress) through Kanban, you can still keep a focused flow of work that continuously delivers working software/systems.

Pairing or Swarming

Pairing or Swarming can help a team become more productive and produce higher quality work. Pairing is basically pair programming, where one person drives the computer and the other person navigates. This allows the person behind the keyboard to use his L-mode of his brain, while it opens up the other to be more creative, see the bigger picture, and use the R-mode of the brain. Swarming is essentially putting multiple people on a difficult task to push it through to completion.

Limit WIP

Setting a limit on the number of stories that can be in the WIP (work in progress) can facilitate pairing or swarming. For example, if you have 6 members of the team and you only allow 3 stories to be “In Progress”, it encourages team members to pair up to get a story done so that another story can go “In Progress”

Beware of Tool Traps

We often trap ourselves into a closed mindset by relying too much on our tools and processes. This can be very much like monkey traps, where a monkey reaches his hand through a small hole in a box to grab a banana. With his hand gripping the banana, his hand no longer fits back through the hole. The monkey could go free by simply letting go of the banana, but will stay trapped because of a refusal to let go. Which of our tools and processes are like the banana?


“Lean” is something that I should be learning more about. It basically takes the principles of lean manufacturing (Toyota) and applies principles to their companies. Some of the main principles of Lean include: reducing waste, becoming disciplined people, and minimizing work in progress.

Agile on Non-IT Projects

Agile principles and tools can help non-IT teams become more effective and to deliver value to their organization more quickly, and with higher quality. We looked at several case studies where law offices, insurance companies, construction jobs, and manufacturing plants adopted Agile methods and saw a strategic improvement in the way they delivered their products. The ironic thing is that much of Agile came from manufacturing, so the use case essentially brought best manufacturing practices back to another manufacturing company from a software perspective.

Office Design Matters

Office space can be optimized to better facilitate Agile practices. Private offices and cubicle walls can be detrimental to the efficiency of an Agile team. Open areas for pair programming, whiteboard spaces, and walls for post-its can help a team collaborate more easily. A radical change in office space cannot successfully be mandated from the top down. It has to be something that the team decides would be useful. Many teams that make the transition, while skeptical at first, find it to be very effective.

Agile Games to Teach Principles

Games can be a very effective way to teach principles to a team. Games can be invented from simple craft materials. An effective model for game invention is: 1) identify the problem to be addressed 2) Identify 2-3 Agile principles that would address the problems 3) build the game and Keep it Simple Sir 4) test the game 5) Prepare retrospective questions to facilitate learning.

Story Mapping

Story Mapping gives dimension to user desires for changing the world. By simply using different colored post-it notes, your team can quickly map out User Tasks, User Activities, Stories, and Release Features. Business people and developers alike can easily reference areas of the Story Map because of its simple organization.

All in all, it has been a great conference. For those who attended this event, what gems did you come away with?

Photo by thelastminute (PhotographyIcon)

Leadership Mistake


I recently sat in a meeting with some of my reports and another manager. One of my team members said something that according to the other manager wasn’t accurate and raised the tension in the room. The inaccurate information likely came from me, but not in exactly the way I said it. I ended up defending my own communications (potentially sliding the blame for misinterpretation to the team member) instead of taking full responsibility for the bad communication myself. After the meeting I realized I had made a mistake. I’m writing this as a reminder to myself that I should take the heat for my team in situations like these.

(Photo used under Creative Commons by Flickr user: kalexanderson)


Focus: A simplicity manifesto in the Age of DistractionAs a manager, I have often found myself at the end of the day having not accomplished anything except having responded to emails. This has felt really frustrating because there are other things that my team and my boss expect me to do.

I’ve recently discovered a FREE e-book called Focus which has some very useful tips on how to avoid the above scenario.

Some of the the insights that I’ve gleaned from this book so far include:

  • It’s okay to turn off your email, chat clients, etc. — my responses don’t need to be as real-time as I think they do.
  • A lot of my fears around recourse if I don’t respond to e-mail immediately are unfounded.
  • Distractions are okay, as long as they are planned.
  • The need to stay connected with the constant streams of communication (E-Mail, Facebook, Twitter, etc.) is an addiction.
  • There are tools that I can install on my computer to help me avoid distractions during focus times.
  • Disconnecting and truly being “home” after work will really help me live a more fulfilling life. I have already found this to be true.
  • I get more done if I focus on one thing at a time, rather than hop between the constant streams of interruptions.

I’m about half-way through Focus. I’ll likely be posting more on this as I find more interesting things in the book.

Manage Process, Lead People

I’ve recently become a manager, which has brought with it a lot of new responsibilities and challenges. I didn’t aspire for the position and I had mixed feelings of letting go of my other responsibilities, but ultimately I welcomed the opportunity.

One thing that has helped me in my new role is the concept of managing process and leading people. Over the past year or so, Brian Corrales and I had been helping the team transition into an Agile software/project management style. We’ve been using Scrum to help us manage backlogs of stories to be completed, track our progress, stay transparent with stakeholders, and deliver early and often.

Our version of Scrum looks a bit different than in other parts of the organization, but it has come from iterative team retrospective. At the end of each sprint, we reevaluate what went well, what didn’t go well, and what we’d like to try during the next sprint to improve. A lot of the “Try” categories have evolved around the processes that we’ve put in place to implement Scrum on our team: for opening up communication, delivering more consistently, estimating better, etc.

At this point, I feel like I have an okay handle on managing process. There are still processes that I’m hoping to improve, such as the way we test and document our products, etc. but those will come gradually over time as we continue to put emphasis on those things and work them more tightly into our team culture.

I’m looking for ways to improve my leadership on the team. I feel like the team is responsive to me, my requests, and guidance, but I’m looking for ways to improve this. I’ve been trying to hold good one-on-ones with my team members, which I believe has been extremely helpful, but I’m continuing to look for more guidance/help.