Managing Product Development

Esther and I were teaching a Behind Closed Doors tutorial at Better Software yesterday. One of the participants was a program manager. He couldn’t see the value of the standup meetings the Scrum teams used every day. “They talk to each other all the time–why do they need the standup? I can’t see the value.”

That’s because the standup has little or no value for a program manager. The value is all for the team. The standup is where the team recommits to each other–every day. The standup is where the team can build burnup or burndown charts (with virtually no overhead). The standup provides the team, not just the Scrum Master, with early warning signs the project is stalled (e.g. if someone consistently misses deliverable dates, or if related features were mis-sized).

The standup is too granular a level for the program manager. (Especially if the program manager really is managing several interconnected projects or several releases.) I asked the program manager if he received the data he needed from the team–and he did. He wanted to save the team the less than 15 minutes a day they spent on their Scrum. I suggested he stop going to the standups altogether. Less than 15 minutes a day is a small price to pay for receiving early-early warning signs of project problems.

If you’re attending standups, and you’re not part of the product development team–the people developing the product– are you receiving any information you really need? If you stopped attending, what would happen to the project? (Hint: it might go faster, because no one will be inhibited by your attendance. The team will discover problems earlier and fix them earlier.)

Labels: meeting, project team, Scrum

A number of my clients and colleagues are struggling with the problem of bringing people into their organizations. In Hiring the Best …, I recommend the buddy system for bring people on. I wrote a little article, How2 Create a Buddy (Informal Mentoring) Program.

But maybe you didn’t know that, or can’t figure out how to make the buddy system work. That was the case in a recent conversation I had with a colleague. He’s working for an organization that has a heavy emphasis on finishing the product that brings in revenue. They have no unit tests, no smoke tests, no automated regression tests. They’ve hired a bunch of new people to work on the next release, but all the experienced people are on the old product, finishing the release to generate revenue. He said, “No one has time to spare for the new people.”

So, to spare people from interruptions, he’d thought of a technical idea: develop a static code analysis tool, and derive a functional spec from the code. I suppose that’s possible, but I have doubts as to how that will actually work. In my experience, people need to talk to other people. Reverse engineering small pieces of code is ok, but not large pieces.

Using the Rule of Three (need three alternatives), I suggested he had other alternatives rather than just a technical solution. He could ask people to pair with each other, so that they learn as they develop. (Even if the new people were pairing, they’d be better off. The best was to pair an experienced developer with a new developer.) He’d get technical review along with people learning all the pieces the system (the project management alternative). He could still ask people to buddy with each other, but limit the buddying to one person each week with one other person (the management solution).

I don’t know what he’s decided to do, but I hope he considers more than the technical solution. In this organization, having people work alone is not helping. The more people work together, the more likely they will be able to release something.

Labels: buddy, project team, rule of three