The importance of the team and man-management

Posted on June 4th, 2008 in Agile, Management by siddharta || 2 Comments

If you have been even half alive in India over the past month you would definitely have seen the IPL. I think one thing that the IPL proved was the importance of the team and man-management. It’s not the rock stars that matter, but the team that plays best together. Throughout I was thinking about the agile philosophy of valuing the team over individuals. Check out this fantastic interview with Darren Berry, director of coaching at Rajasthan Royals where he talks about their management style:

Continue reading ‘The importance of the team and man-management’ »

What matters more, people or process?

Posted on April 20th, 2008 in Management, Methodology, organisation by siddharta || 1 Comment

One of the best posts I have seen in a while. Cory Fox on what matters more, people or process:

It’s a good question. I saw good code at places with crappy practices. And I saw crappy code at places with good practices.

But in almost all of the places, I saw code that was on par with the motivation of the teams in place. In other words, teams that were excited about what they were doing, and kept up with trends, etc, often had code they were proud of. Teams that liked their job, but basically were just there had code that worked and had issues, but they didn’t mind. And teams that were just in a crappy place had code that was crappy.

Meeting Facilitation for Agile Teams

Posted on August 28th, 2007 in Agile, Management, Meeting, organisation by siddharta || 7 Comments

One of the more important aspects of general management is facilitating meetings. It’s rather surprising how boring most meetings are. Given the frequency of occurrence you would have thought that people would have gotten pretty good at it. But no, most meetings are dull, boring and go on for far too long.

The ability to have good meetings becomes even more important when doing agile software development, because there is a lot more emphasis on social interaction when compared to traditional processes. Indeed, one of the core skills of being a good Scrum Master, Coach or Project Manager in an agile setting is to be a good facilitator. Almost all agile processes have a meeting to plan the iteration (eg. Sprint Planning meeting in Scrum), a daily standup meeting and a closing iteration retrospective or reflection meeting. Key to the success of agile is the ability to keep these meetings short, interesting and productive and thats where the facilitation skill of the Scrum Master or Project Manager comes into the picture.

As a result, I’m always on the lookout for good, interesting articles and books on meeting facilitation. Here are some ideas, click the link name to go to the original article.

Continue reading ‘Meeting Facilitation for Agile Teams’ »

There is no “non-business” side

Posted on August 9th, 2007 in Management by siddharta || 5 Comments

In an organisation you often hear about the “business side” and the “technical side.” The business side includes roles like management and business analysts, while the technical side includes development and testing. The terminology of the “business side” and “technology side” is the worst possible thing that can happen in a company because it deepens the divide between managers and developers and ends up creating an us vs them situation. [More about that here: Managers and developers: Are you two teams or one?]

As someone said in an email discussion, there is no “non-business” side. Everyone working in a company is on the business side in some form or the other. Developers are on the business side by developing products that help the business. Managers are on the business side too. Don’t get fooled into thinking that only a small group of people are on the business side. Everyone is on the business side — and if not everyone should be.

Does your company have a “non-business” side?

Is estimation at your company like this?

Posted on July 11th, 2007 in Management by siddharta || 6 Comments

I was discussing estimation of software projects, when it hit me that in many unfortunate organizations, estimates are not about reality, but about politics. Really, how often have you seen a discussion like this –

Manager: How long will the whole thing take?
Dev: Depends on the requirements and if they change. We’ll estimate on a 2 week basis. That way we can keep the plan close to reality and also adjust easily if requirements change.
Manager: We need to give the board a date
Dev: We can go through the requirements, but the final date will be very uncertain at this point
Manager: Doesn’t matter, lets just fix a date

<do some estimation and come up with some date>

Manager: We cant have that date, the board wants to have it done by the end of the year. Lets just cut the estimate to fit it in.
Dev: :-(

<after one week>

Client: We’ve had some project changes here, so use this new requirements document
Manager: Sure.
Dev: We need to restimate all over again
Manager: Lets not, I’ve already committed the date to the board. I’m sure you guys can do it.

<at the end of the year>

Manager: So are we done?
Dev: No, we are about 40% there
Manager: What?? Your estimating sucks. What do I tell the board now? That you screwed up?

Amazing isn’t it? We’ve all been in situations where managers are more interested that the date be something that makes them look good than they are in having the date be realistic. If that is the aim of the estimate, then who can complain when the estimates are missed?

Next Entries »