Embracing planning assumptions as more real than what people and products are actually delivering — from Jim Highsmith.
It’s like driving into a river because your GPS tells you to.
Note: Jim Highsmith’s challenge of the CHAOS study and defining success as on time, on budget, and as originally specified.
Sweet and simple. http://weblogs.media.mit.edu/SIMPLICITY/archives/000456.html
These are candid shots from this week’s Sprint review (full size image).
One of our team, Wendy, often works from home. We use webcams, skype, community document formats and remote access. She even has her own build bunny.
As you can see, we’ve developed the habit of giving Wendy a view of the action however absurd or precarious it looks.
Remoting does limit beneficial cross-talk among the pairs (osmotic communication) but word within the team is that pairing goes well. After some practice, we’re also getting the hang of the structured group conversations such as standup, sprint review and planning.
We have a strong, established bond with Wendy and the team is really pulling to make it work. She also comes into the office at least once a week which keeps us close. All and all, it’s about the easiest remote worker scenario I can think of.
The biggest downside is simply that we miss her.
I laughed out loud when I saw Ken Schwaber titled a passage of his book, The Enterprise and Scrum
, “Just Do It”.
Ken describes how a customer can sacrifice quality and sustainable pace in the short term but pay it back at a premium, “$4 to remediate every $1 drop in quality.”
Clearly there are pressing bugs, misses and serendipitous opportunities. There are times to inject work into a sprint backlog. There are even times to “stop the line” and reset a sprint.
But when you manage a self-directed team, “just do it” — and I’ve heard that very phrase — is bullshit.
Just characterizes another person’s work as easy. It is the people performing work that need to estimate it. They are on the hook to execute and are incented to think critically in detail about what they are taking on. The worker grasps the actual effort better than the executive.
Do characterizes the work as physical action. Software development is problem solving and abstract modeling, i.e. knowledge work. “I’m typing as fast as I can?!” Even industrial lean practice relies on workers engaging beyond the boundaries of the immediate task to improve the product and the process of manufacture.
It characterizes the work as a single, clearly defined task. Again, the person doing the work determines whether they clearly understand assignment. Otherwise, you’re not admitting to any ambiguity of language, hidden complexity, or potential misunderstandings.
Just do it is a one way directive that splits responsibility from authority, i.e. YOU just do it. It signals a leader is not willing to do their part to remove obstacles for their team.
Just do it hides inefficiency under a veneer of necessity. Is it a surprise that “just do it” finds companionship with “just the way things are done” and “just the nature of the business”?
All this to say “just do it” in knowledge work is bullshit
. The value lies not in the truth or falsity of the statement but the effect it has on the hearer. It dismisses workers’ concerns and excuses management from accountability.
Moving from bulls to birds, if self-directed teams are the goose that lays golden eggs, “just do it” is a pellet blast in the ole’ egg layer.
It’s a privilege to be granted authority in another person’s company.
It’s easy to criticize. It’s hard to raise capital and make payroll.
I have never been an entrepreneur. My passion is to build teams. To be of service. To make things better.
I’m that second generation that feeds off founding vision and hopes to sustain an organization.
This has been a good week.
I am a cautious optimist. Success is far from inevitable. Actually, all this represents is an opportunity to start the really hard work.
Still some moments, especially ones years in the making, need to be savored.