One of the key concepts of the Scrum methodology is the Team (I'm not the one adding the capital T; this is how it is actually referred to in the Scrum literature). In Scrum, the Team is self organizing, which means that management is not supposed to tell the people what to do. Instead, management just makes sure the Team has everything it needs to get the work done, removing roadblocks and isolating the team from outside pressure.
I agree with that in principle and this is how I work with my own team. But I can only do this because I have a homogeneous team of talented people where everyone is a team player and works well together. The problem is that Scrum doesn't have tools for when politics, vanity and other human characteristics come in the way. And this is because the Scrum Master (stupid name) is constrained by this 'self organizing' principle in Scrum. Sometimes you just have to make a decision and exert your authority.
Team playing is important. But if you trace a parallel to sports, you usually don't see a successful team with if you don't have a talented and strong coach. I'm not claiming I'm such a person myself but I don't buy the argument that a team doesn't need a leader.
Posts
Transactional Hardware on x86
2 days ago
6 comentários:
Agile processes aren't the only ones that emphasize the importance of the team's ability to organize itself. You should have a look at the Team Software Process (TSP) (http://www.sei.cmu.edu/tsp/) as a non-agile way of doing things that's also team-centric. Actually, I don't believe they are antithetical to one another, but TSP is none other than an adaptation of CMM Level 5 brought down to the granularity of a single team (there's also PSP - CMM Level 5 for a single person!).
I read about it some days ago in another blog and the main things that you mention here are very similar
Scrum and Scrum Master are stupid words anyway...This is a funny idea invented by someone to satisfy 'managers' who don't ABC of what the team is doing and who have never written a 'Hello World' in their lives.
Software development is not like assembling hardware. The progress is never linear. It is quantum based.. Scrum meetings expects the progress to be linear...
It's just a morning exercise. For many ingenious people this morning sessions destroys the whole day!
I worked in a project once, where the leader called for a meeting (not Scrum) every Monday at 9.00 .. And it spoiled the morning, the day and in most cases the whole week. I had to tell him to chnage the meeting time to afternoon! This was a better compromise.
I can't possibly imagine how a 15-minute meeting could ruin your whole day. Much less that doing in the afternoon would somehow magically fix the problem. Either it's because you go to bed at 5am every "night", or it's because you're doing it wrong...
The trick in Scrum definition is that is does not actually define/describe the extent to which the team should be self managing. It is obvious that there cant be a team fully self driven, the customer requirements will need to be the bible for every act of the team. That itself means you have some guidance how the team should behave. I agree with the concerns you raised. It is important that the organization actually have software engineering practices in place (that will actually ensure teams are guided) before practicing Scrum. I wrte about this couple of month ago on my blog too. That post can be found at http://blog.hasith.net/2009/12/when-to-scrum.html.
Totally agree with Anonymous June 28, 2010 3:35 AM: these stupid morning meetings just kill me too.
To be more precise, the daily scrum meetings (stand-ups) make me feel like some naughty schoolboy who is inspected by the teacher every morning. "Have you done your work and behaved nicely yesterday?"
(No, I had a headache yesterday and didn't produce many lines of code at all - is that ok?).
Whatever happened to management by walk-and-talk? A good manager and a nice team talks to each other and the work just flows anyway.
I think there are too many managers and project theoreticians in IT now, instead of programmers who actually do things instead of debate about methodology.
Post a Comment