Heather McLean

The Discipline of Agile (followed from a post on Mr. Appelo’s blog) made me pause and think. Mr. Ambler’s article does an excellent job of breaking down agile into some key disciplines:

1. Regular Delivery
2. Quality
3. Active Stakeholder Involvement
4. Scale
5. Teamwork

I was thinking, though, that the list was far too specific. Some of these things are results of similar disciplines—for instance, Active Stakeholder Involvement and Teamwork are both principles of good communication. Others are esoteric, such as Scale.

I decided to reorganize these disciplines a bit and change them around, hopefully making them more broadly applicable to agile processes. Below are what I believe to be the disciplines of an effective agile/lean project.¹ Read the rest of this entry »

One of my teammates shared this little story with us last night, so I thought it would be worth it to pass it on.

Ready, Fire, Aim is a play on Ready, Aim, Fire, a phrase commonly used in conjunction with firearms. Since firearms are used extensively by the military, the first counter story I want to share comes from the US military.

General Norman Schwarzkopf commanded US forces in the Persian Gulf during Operation Desert Shield and Operation Desert Storm. He is credited with taking advantage of technology advancements in weaponry to aide his success during the Gulf War. One such advancement involved putting soldiers on top of buildings in Iraq. These soldiers would remain hidden during daylight hours. At night missiles would be fired from several miles away. After the missiles had been fired, the soldiers on the rooftops would use lasers to guide (aim) them to their targets—truly a Ready, Fire, Aim operation.

A Scrum team is similar to the soldiers on the buildings, constantly guiding their projects to the desired targets.

I just exited a productive mini-meeting about improving estimation of hours and story points for our off-shore teams. One team in particular is struggling, and we got together to brainstorm some ideas on how to help.

I came up with a couple of suggestions that we’re going to try:

• Get the team to think in relative terms. One of the problems is that when the team comes to the table to estimate stories, they start pointing things randomly and in isolation from one another. In other words, a 3-point story might not match a 3-point story in the previous sprint in complexity, or even with another story in the same sprint. As an exercise, when the team is estimating, we will stop and ask them, “So how does this story relate in complexity to this story over here that you gave the same number of points?” Hopefully it will get them to stop and think about it long enough to reassure us that the points are consistent.
• Get the team to sort user stories by difficulty prior to sprint planning. This will hopefully also increase teamwork. The idea here is that prior to the actual sprint planning, the team will get a list of stories that the product owner is thinking about including in the sprint. Then they can, on their own time, work out the list in order from least complex to most complex to implement. Theoretically, by the time they get to sprint planning, they should already know which stories should be estimated higher than others.

We’re not sure how exactly this will work out, but at this point we’re willing to try anything to improve the team’s ability to plan and estimate.

Trying to catch up with some more of my “backlog”…

This one is from early December. Joel Spolsky wrote an article for Inc.com titled How Hard Could It Be?: My Style of Servant Leadership. It’s short and to the point, and I think every manager or manager-to-be should read it and heed his words.

In particular, I identified with a couple of passages:

In our company, management’s job is to get things out of the way so that all the great people we’ve hired can get work done. … Our company was built on the idea of hiring smart and productive people and then clearing the decks.

This is something I’m really striving for in my leadership capacities. Especially coming from an expert background, sometimes it’s difficult to let go and allow your team to thrive. Sometimes I feel an impulse to jump in and do the work myself, but I have to remind myself that my team is made up of experts for a reason. I should trust in those experts and let them do their jobs… and I will stand back and remove all the white noise that gets in their ways.

I still contend with the problem from my own superiors that sometimes I am not trusted for my expertise. This is very frustrating for an intelligent and productive software engineer (or any other expert)… why would you hire a supposed expert in his field if you’re just going to tell him how to do his job? Experts want the ability to thrive in the work environment and build good products without interference. They will quickly grow bored with implementing someone else’s ideas.

Not long ago, we had a management trainee who sat around waiting for us to give him a formal title and promotion so he could “get stuff done.” Problem was, he had never managed to win enough respect or influence from the development team to actually do things.

At the same time, you must be willing to wade into the thick of things and build a rapport with your team. Someone who demands respect simply because of his or her position is only going to get it grudgingly.

This is where I strive to help my team grow. I’m not opposed to pair programming with my team members when they get stuck, or offering up ideas to improve the overall architecture, or even just dealing with annoying stuff for them.

Commanding subordinates and leading a team are two very different things. Leading by example is even a step ahead of that.