Stop managing and start helping

Last week, I read an old blog post on As Chris Daily said, people need to “let go of the perception that they are in charge. In reality, you were never in charge, but you told everyone you were.” His words sat with me while I did my usual routine in trying to shepherd code from development to release. I paid attention to how much time I spent “micro-managing.” It was too much.

So, today I stepped back officially from my “managing” of the team. After only their second sprint it was obvious that they don’t need me to manage them; they manage themselves. I should be spending my time helping them get work done, not supervising or making their decisions.

Next week I’m going to be doing more of MY job (not theirs). My job is to coach. I am excited to coach with such a talented and devoted team.

Building cross functional teams

Scrum is a style of Agile software development that has become very popular. However, like its namesake in Rugby, the development methodology depends on the ideal that the team is at its greatest power when it moves ahead together as a unit: a scrum.

“Scrum relies on a self-organizing, cross-functional team. … The team is cross-functional so that everyone necessary to take a feature from idea to implementation is involved.” (Mountain Goat Software)

It’s a hard transition for some organizations to assemble a team that can operate in a scrum. If you are lucky, the management has already decided upon Scrum and is ready to assemble a cross-functional team. However, if that is not the case, it will be up to you, my fellow agilist, to advocate. The concept of Scrum is generally not enough to convince someone new to the ideals. More often than not, the first team includes only application developers. It takes time to get buy-in that the team really does need a database guy AND a solutions architect AND a QA person.

I’ve found the best way to bring everyone into alignment is to carefully warn about the possible side effects of not having a cross functional team, continue to work as hard as possible, and see how it goes. What seems to happen is that the team begins to feel the void where a function is missing. Let the team decide what it needs. I always recommend having the outcomes/goals of your retrospective posted and available for all, including the leadership of the company, to see. If one of the outcomes of the team’s discussions is the need for a more cross-functional team or an additional team member, use that information to bring it to the management’s attention.

Letting the team decide what it needs is important in all changes. Only the team knows what it needs and what it’s comfortable changing. The team will determine the right mix of functions to create the perfect cross-functional team.

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.