 |
| photo credit: flikr dcwriterdawn |
In his book Slack, Tom DeMarco makes the point is that you can't be creative when you are overworked or overburdened. Stress kills innovation as does busyness. To be creative, your mind needs to feel free and unallocated, uncluttered even.
In a waterfall shop, slack abounds. There's the project fuzzy front end where some are idle. There's the test and fix or stabilization cycle at the end of the project where some folks are slammed, and others are trying to not look as idle as they are. And there are times in the middle where this person or that one doesn't have enough work to do. Or maybe they are blocked. If you can put that slack time to good use improving the product, the work environment, your skills, or your process, then good for you.
The problem with Scrum and eXtreme Programming in particular and with iterative development in general is that they wring all the slack out of an organization. There is no unaccounted for time on a Scrum team. You must deliver value in every story. Every sprint must deliver valuable working software. You must help your teammates finish their work for the sprint if they get in a bind. Or add another small story to the sprint if possible. "If ya ain't working on the sprint backlog, ya ain't getting paid!" Little slack leads to little time to look around leads to little improvement.
Thankfully, we have a solution.
We have more than one, in fact. Let me first tell you about the solution that this article is not about. You can introduce slack into your organization with regular slack time. There are numerous well known examples of companies that do things like Fed-Ex days, time set aside for self-directed work, not allocated to Prioritized Product Backlog Items. Dan Pink recently endorsed this approach. As an aside, I like what Dan has t o say about what motivates knowledge workers.
But there's another solution to the lack of slack that we should entertain first. In fact, you are less likely to do the FedEx day if you aren't first doing the following. But to introduce this I must first point out something that Scrum says about managers. Scrum doesn't say a whole lot about managers, but it does say at least this: mangers must stop assigning tasks. Too bad that many managers get their power and sense of self-worth from this activity. Deciding how to get the work done in Scrum is left up to the self-organizing cross-functional team. The people who can best decide how the work should be done are those closest to the work.
Just to be clear, managers in Scrum and eXtreme Programming should not:
- make assignments
- hand out work
- direct people or tell them what to do
- make the hiring decision solo
- SW architecture (in my opinion - debatable)
- do work
- be an individual contributor
- be a hero
Well, gosh, then shat should a manager do? Well, I'll tell ya! You could manage more people. You can still step in when the team needs help (but not too quickly). You are still an agent of the company, handling legal stuff, signing off on expenditures, etc. You can still manage risks, especially if you are a skilled Project Manager.
But you could also do something else.
Be the Slack.
Move up to a higher level of value to the organization. Be the slack that has been wrung out of the team. Here are some specific suggestions:
- Keep an eye on the system, looking for improvements
- Ensure cross-training is happening (not by making assignments, but making the team handle it)
- Understand the dynamics of the organization
- Understand how value is created
- Protect the team from interference
- Make the organization effective; learn to look at it as a system
- Support the team
- Clear roadblocks
- Provide good facilities -- fight the facilities police (better: teach facilities how value is created and how better facilities helps you guys create value)
- Ditto with more powerful computers, sufficient build machines and test machines (the people on the team are far more expensive than a PC)
- Use Derby's 13 essential questions for managers or the book on this topic she is working on
- Read Deming
- Watch interpersonal interaction -- watch when one team member pulls back, withdraws in a brainstorm (for example)
- Help the team learn TDD by making room for them to learn (time - remove the schedule pressure while they learn)
- Understand the capacity of the team (also a team and scrummaster job)
- Think through policies, procedures and reward/review systems and improve them (what messages do they send?)
- Understand what motivates knowledge workers (see the previous reference to Pink) and let creating that kind of environment be an imperative
I contend that we should focus on continuous improvement of process, of people's skills and knowledge, with a strong focus on empowerment and self-organization. And work on open, honest feedback. You'll have better results if you do all that and just completely scrap the individual annual review.* I love quoting Drucker here: ""the average person takes 6 months recovering from a performance review."
I've really straying off the point of the article there. Let me bring it back together by saying you can't do a good job with this other higher value stuff if you are down in the weeds assigning tasks to people. Delegate more. In fact, delegate everything, freeing yourself up to be the ultimate in valuable slack.
----------------------------------------------------------------
* Not sure if that sentence is in my words or whether I've co-opted someone else's way of saying that. I think I've read a similar sentiment in either Management 3.0 or in Coaching Agile Teams. I don't think I've plagiarized there, but will gladly give due credit if I have.
WordPress.com
