Programming Is Mostly Thinking
Pretend you have a really great programming day. You only have to attend a few meetings, have only a few off-topic conversations, don't get distracted or interrupted much, don't have to do a bunch of status or time reporting, and you put in a good six hours of serious programming [note: this RARELY happens in an 8-10 hour day]. I want to review your work in the morning, so I print out a diff of your day's work before going home. Sadly, overnight the version control system crashes and they have to recover from the previous day's backup. You have lost an entire day's work. If I give you the diff, how long will it take you to type the changes back into the code base and recover your six-hours' work? Programming is 11/12ths Thinking I've been touting this figure for some time now, and people keep asking me where the study is that produced such an odd number. Well, it's not pulled out of thin air and it's not the result of a thoro...
yep...pretty much sums it up.
ReplyDeleteKeep team on track ?
ReplyDeleteThat's an open invitation to a world of command and control.
In conversation, the SM who recommended "keep team on track" specifically was talking about cutting down on interruptions and yak shaving festivals by making information and people available to the team. There was no talk of "making them do their work."
ReplyDeleteIf all of these hit a Scrum Masters plate at once then it would be too much. I can see where all of them might happen at some time or the other.
ReplyDeleteSomtimes some of these can fall to other team members depending on the situation. SM can't be in more than one place at a time.
I think as times goes on for SM that sometimes they can get lulled into taking on more of these than they should.
Did no one suggest 'make themselves redundant in the shortest possible time' ? Should the real push be toward a self-determining team than is able to adapt and provide self-devised solutions for any circumstance ?
ReplyDeleteI'm with Anthony here, SMs mission must be "To disappear after team's skills improvement.", unless the company has decided to have a permanent SMs team, maybe because of a big employees rotation and therefore the team is not always the same. (http://tales-of-agile-adoption.blogspot.com/)
ReplyDelete