I recently started a new project.  It took a while to get it going, in fact it took 4 project kickoff meetings before we finally got it moving at all. This was for a set of bug fix releases,  not a whole lot of new functionality. In theory, it should have just do the book keeping, introduce the team, schedule stand up times and start the first sprint the next day. So what happened?

Basically, listening happened. I don’t mean listening in the sense of being able to repeat what someone said, parrot back why they thought a a feature was important. I mean active listening in the sense of everyone really communicating and understanding the problem and how the other people were viewing the problem. The reason it took multiple attempts at a kickoff meeting was that we would talk, there would be some research to be done, a week would go by and the cycle would begin again.

In our rush to be “agile” we frequently forget that solving the business problem is the most important thing.  It’s not a function of how many sprints you do, how many stories are completed in a sprint, how many points per day or any other metric other than: how happy are we making the customer? By taking several weeks talking and listening with the business owners, scope changed pretty radically, and there was a lot more investment from both the business and technical people in the project.

There were a couple of side effects of taking the additional time to talk about getting this project started. The first is the kind of “well, duh” effect; after actively listening people are better connected to the other stakeholders and the team has better communication than prior project teams. The second and to my mind more interesting effect is that in spite of a lot of distractions where most of the project team is getting pulled onto other work, the first sprint is on track to deliver 100% of the sprint commitments.  As a testament to that, I got an email from one of the business stakeholders saying that this was the first time in five years of working on this product that she felt that she had been listened to, and that her concerns were actually being addressed.

Active listening is a skill, one that as technical people we tend to discount. First, because it’s hard; you have to pay attention and be a participant. I’m not sure if it’s a failing in the technology space, but we tend to have an arrogance about problem solving. The approaches that we as technologists come up with are geared in a lot of ways towards maximizing the metrics; getting stories completed, etc. We tend to not want to focus on making sure that we’re picking the right stories to work on.

I think part of this is the institutionalized division of labor on agile projects.  The technical people implement the stories, and the business people write and prioritize the stories. That shouldn’t necessarily be the case. Writing the stories should be a collaborative effort for the team.  By taking 4 weeks to come up with what the right things to work on were, we changed stories significantly. The changes had two effects: first was that everyone understood the stories and second was that everyone was more committed than normal in seeing the success of the sprint.

So, the experiment in active listening was a success, even if it took and extra three weeks to get the project going.

Advertisement