Going through Good to Great again, and was struck by Jim Collin's statement that the best companies hire self-disciplined people who don't need to be managed, and the leadership manages the system, not the people.
One of Scrum's principles is that the teams are self-managing. But I can see now that that principle depends on having the right people on the team – disciplined people. Just because I'm running scrum doesn't mean that someone on the team who wasn't previously self-managing or disciplined suddenly becomes disciplined. The opportunity is there for them, and hopefully peers around them to model after, but the brutal facts might be that there are team members who will never become self-managing, self-disciplined. Perhaps the team manages these people off their team, but if the team and process doesn't gel immediately (average of several sprints before typically gelled and consistent), then it is likely the ScrumMaster may be the first to deal with whether a person is right for the team.
2 comments:
Scott, on one level, I could not agree with you more, but on another, I felt I should point out that Scrum makes self-management easier through the transparency provided by the Daily Stand-ups and Burndown charts. Some team members may not be disciplined as you mentioned, and some may be really good at hiding the fact that they are not disciplined. However, Scrum will shine a spotlight on those folks. The team will then prompt them to become more disciplined. If this pressure from the team is too much, they will likely seek employment elsewhere. But in the end, you have that solid Scrum team you need.
Thanks for the comment, HLArledge. I would rather see the team address the issue (via peer pressure or other ways) because the team is who really set the bar for performance, rather than some mandate from on high. Part of my thought of the ScrumMaster addressing was based on timeframe (how long does one wait?), Good to Great's recommendation ("First Who, Then What" - it's better for all to get the wrong person off the bus promptly) and one of the classic mistakes from Steve McConnel's Rapid Application Development. Interestingly, though, when I re-read it, I found that he appears to be saying the team deals with the problem employee just as much as management. Quote below:
#3: Uncontrolled problem employees.Failure to deal with problem personnel also threatens development speed. This is a common problem and has been well understood at least since Gerald Weinberg published Psychology of Computer Programming in 1971. Failure to take action to deal with a problem employee is the most common complaint that team members have about their leaders (Larson and LaFasto 1989). In Case Study 3-1, the team knew that Chip was a bad apple, but the team lead didn't do anything about it. The result--redoing all of Chip's work--was predictable"
Regards, Scott
Post a Comment