Heather McLean

The next meeting of the Fort Worth APLN is on June 11, 2009 at 6:30 PM. From the summary:

Based upon last month’s speakers topic ‘Speed bumps – Challenges on the road to Agility’, we thought we would pull three Bumps and discuss in small groups.

The selected bumps will be:

• Team Organization
• Story Points and Velocity
• Sprint Planning

As usual, if you want more information, contact Charles Seaman at fortworthapln@gmail.com.

I’d like to take a moment to talk about a style of management I call the “just deal with it” approach. It’s an all-too-common situation that happens in highly structured organizations, and the really sad part is that it is self-defeating for the people who are perpetrating it. The scenario plays out something like this:

1. Executive Management sets goals for the month, quarter, year, whichever and communicates them to Vice Executive Management.
2. Vice Executive Management wraps those goals up with additional goals of their own and communicates them to Management.
3. Management now has goals that it had no say in developing but must somehow meet with the resources/time at hand. Those goals are communicated to Implementation.
4. Implementation (developers, business analysts, quality assurance, etc.) receive a set of goals that seemingly come out of nowhere and have no relationship to the reality of what they will have to implement.

Do you see the fatal pattern here? Communication and goal-setting goes one way… from the top down. It’s a “trickle-down” form of setting commitments. This results in a multitude of consequences:

• Management and Implementation are frustrated by the lack of involvement in setting their own commitments and deadlines.
• Execute and Vice Executive Management are frustrated by deadlines that constantly slip or bring less-than-promised deliveries.
• The only motivation for Management and Implementation to meet goals is to avoid pressure from the higher levels.
• Implementation has two choices: miss deadlines/under-deliver or burn out trying to “crunch.”
• No one feels like communicating with each other because everyone sees everyone else as “the problem.” This is often the part where the sentiment of “just deal with it” crops up, as everyone from the top down is expected to deal with what rolled downhill rather than fix the problem.

It’s a cyclical beast; as soon as one set of goals are missed, a new set is sent down the pipes. The upper levels take a fire-and-forget approach, and then they are left wondering why that approach didn’t work. If you tell a subordinate to do something, they should just do it, right? I don’t mean to be overly critical of upper management, but keep in mind that this is a post about management techniques; I’m going to pick on those who earned it. To be fair, however, this doesn’t happen because the goal-setters are inhuman monsters who want to drive their subordinates to madness (well, I would hope, at least). It happens because there is a fundamental misunderstanding of how to properly set company- and department-wide goals, especially with regards to product development.

The most important thing to remember is that the goals you are setting are not just your goals. Mr. CIO is not the only one who will work on them, so he should not be the only one who determines what they are and when they will be delivered. I’m not advocating that you include junior developers in board meetings, but it is important that the lower levels of management and the implementers are involved at some point in the process. Go to your subordinates and say, “Hey, this is what I want to accomplish. How do we do that and how long do you think it’ll take?” This will build goodwill and will also open your eyes to a whole new level of complexities that you may not have seen before.

Most upper management takes the first step, presenting the goals for evaluation to their direct reports. This is good, but at some point you have to reach the lowest levels. The people at the bottom are the ones who will be building your products, so they are the most likely to know all the intricacies of making your goals happen. You may not realize at surface analysis that adding a single button to an extant dialog is actually 3 weeks of work instead of 3 days because of mitigating circumstances and quirks of the platform. To be fair, it’s not your job to know those things; thus, you need your product teams to help you out.

Also, if your implementers are involved, a miraculous thing happens… they begin to care. It’s very easy to blow off deadlines and such that are deemed “unreasonable” and handed down from the top. But if a developer tells you that something is going to take 5 days to complete, suddenly the onus is on him to meet his commitment, and he’s more likely to put in extra effort if that deadline slips.

There is a win-win scenario to this situation, and it nets you two very important results: more accurate/realistic deadlines, and a workforce that will actually put forth genuine effort to keep those commitments. It just requires you to literally turn your thinking upside down.

Our previous set of status meetings failed to be productive. They lasted at least an hour every day, often more than that. They were unfocused, and often crossed so many topics that no one really remembered what happened after they left the room. Eventually, they just kind of petered out… no one really wanted to attend them anymore, as they were obviously unproductive. The period that followed was almost as bad–no daily status, but at least people had more time to do actual work. Tasks were slipping through the cracks and overall communication declined.

So I was happy to step in with an alternative solution: a Scrum-like daily status meeting. I don’t make people stand-up, and we’re time-boxed to 30 minutes instead of 15, but otherwise the principles are the same. At each meeting the attendees are required to come prepared to answer the usual triumvirate of questions:

• What did you accomplish yesterday?
• What are your goals for today?
• What issues are affecting your ability to meet those goals?

I’m pleased to say that even after only one week, the system has proven effective. People don’t mind attending since it’s short and focused. We stick to the agenda above; we’re not quite used to the format yet, so some side discussions occur in the middle of the meeting, but we’re getting better. Now everyone knows what everyone else is doing, and communication is improving. We’re catching issues much faster since the team is aware of what is going on before it happens.

I won’t claim daily status is a panacea, but it’s working for us with remarkable results.