The bottleneck of false import

I have only been at my current organization one year, but somehow I am already the definitive source for information. I am no technical expert, but find myself making technical decisions. I care so much about getting the job done (both well and on time) that I weigh in on technical decisions just to expedite.
Here’s the problem: with every new system and each project, more information is in my head and I become even more relied upon. But I am still one person with only so many waking hours, two ears, one mouth, and one tired brain. I have become a bottleneck without meaning to. No matter how much I decide or how many people rely on me to “be in charge,” projects aren’t getting done better or faster.
The solution: use all the knowledge I have of Scrum development and being an agile coach to forge a new path.
Turns out moving from the guy who knows everything to the agile coach ain’t easy. At this point, it’s equally changing my internal behavior as much as teaching others to adjust to my new external behavior.
I turned a meeting that was “standup” by name into a real scrum stand up. We answered the three questions, we tried to move conversations into follow ups; it was beautiful. Not perfect but beautiful.
Here’s how we did it: I acted as the Scrum Master. I told everyone the rules and enforced them. I tried to assist by recording the blockers so the speaker felt he could safely move on to the next person and his blocker would soon be addressed. The team did the rest. For now, I’ll setup the follow up meetings. One change at a time. Tomorrow we’ll do it again and hopefully it will be easier. By next week, I will try to have encouraged everyone enough that they setup the meetings and resolve their own blockers as a team.

Development Tools

Developers do the work. It’s just the truth. I can coach and teach but I don’t make the product go. It’s a frustrating a rewarding thing to be the coach. But it also means that I have the responsibility to get the team whatever they need to get the job done. Today I want to talk about tools.

My developers often complain that their computers are slow. When I have confronted the people in a position to change this, they make sure everyone’s anemic machine has 8GB of RAM and a few gigs of empty storage and declare the problem solved. But I sit with the developers while they work. They spend, literally an hour a day waiting. They wait for code to compile, they wait for IIS to start, they wait for programs to stop crashing, for solutions to close and open. In general, the machines waste their time and the developers know this. Almost every developer I know has a great system at home. It’s his baby and what he will measure his work machine against. When the work machine fails this comparison miserably, the developer understands that the company doesn’t appreciate and value his skills and time as much as he does.

If we consider for a moment that each person on a team of 20 developers is billing us roughly $150/hr, then each day we spend at a minimum of $3,000 paying them to wait and get frustrated. This figure is typical back-of-the-napkin math and is lacking detail a specificity, but in general it’s accurate.


What can $3,000 buy? A pretty great workstation that would stop the waiting for one person. So, in 20 days, you could “break even” on buying the whole team new machines to cut the wait time. This seems like a no-brainer. Not only would productivity go up, but the team will understand that they are important and investing in them is something that the company does willingly and  frequently. You want your dentist to have the best tools when he works on your mouth; I want my developers to have the best tools when they work on my projects. As I said above, they are the ones who do the work. They are the heart and soul of the IT department and should be treated with the import they deserve.

Let’s do this

I am starting this blog to keep a record of my wins, losses, trials, and joys as I work at the art of agile coaching. I have been worked in agile in many forms (but mostly scrum) as a developer, quality assurer, development manager, project manager, and product owner. I respect and enjoy the art of continuous improvement. The next step in my journey is to codify my learnings and take my coaching to the next level. I have been focusing on teaching agile and scrum to all those I work with in order to improve output, attitude, quality, and overall satisfaction in the software development lifecycle.

The goal of this blog is to share my experiences with the agile community. I hope to find others on the same path and use our combined knowledge to better the practice of agile. I hope to provide others with the inspiration to keep going, knowing someone else is having the same setbacks and wins. I look forward to collaboration and receiving suggestions and comments from others.

Let’s do this…