One cuckoo flew over the nest
Firstly, a disclaimer in the words of the inimitable Ken Kesey:
Take what you can use and let the rest go by.
Interestingly, when I googled this quote to ensure I was recalling it correctly, I found some other excellent quotes. Another that seems apropos:
You don’t plow under the corn because the seed was planted with a neighbor’s shovel.
If Dialog Driven Development is merely rounded corners to you, please continue to enjoy your square ones. This exploration is not aimed at gathering the true believers. I’m not the evangelist type. So, if you’re worried I’ll show up on your doorstep thumping my bible, rest assured I won’t. I’m an atheist.
That said, I think there is value in creating distinctions to better understand the terrain. Agile is a big umbrella. If the processes were formulaic, all we would need to worry about is a good algorithm.
Recently on a flight to DC to meet with a new client, I delved into a book Robby brought along: Agile Project Management with Scrum by Ken Schwaber, one of the co-founders of the Scrum method. Below are a few notes I jotted down on my index cards while reading the first 4 chapters and browsing the appendices. Since then I’ve browsed some of the other chapters but I haven’t finished the book.
advantages of Scrum
- emphasis on empirical process control
- iterations
- daily team meetings where each member presents what she did in the past 24 hours, what she’ll do in the next 24 hours, and any blockers
- frequent feedback loop
- clear separation of responsibility using the pigs and chickens metaphor to facilitate more effective decision making and reduce interference by chickens, which can bog down the process
- The three legs that hold up the implementation of empirical process control: 1) visibility - aspects that affect the outcome must be visible to those controlling the process; 2) inspection - these aspects must be inspected frequently enough to change course if necessary before too much has elapsed; and 3) adaptation - changing course when new information suggests it is necessary
- emphasis on having a vision, it must be a vision that is fairly resistant to change in order to guide the project, but able to change when required
”You can get through almost anything if you don’t try to impose rigid solutions before problems even arise, instead devising solutions as necessary when problems crop up.” (page 131)
drawbacks to Scrum
- specifying the product backlog - this suggests too much dictation and not enough collaboration. According to the book, the product owner specifies the backlog and prioritizes the items in it. The team meets to decide which items it can deliver in the next sprint. That process is two monologues not a dialogue.
- 30-day sprint is too long. I don’t think the feedback cycle is nearly as effective at this scale because we need feedback long before functionality is “deliverable”. More frequent testing is needed to refine features. Imagine getting a haircut where you tell the stylist what you want. She then takes you to a room with no mirrors and starts chopping away. When she’s done she takes you to another room to demo your new haircut. Fortunately, the difference between a bad haircut and a good one is about 2 weeks. The same is hardly true of software.
The process of software development requires a lot of educating of the people involved. The product backlog does not encourage thinking in this way. I dislike the sequential list where the only explicit organizing idea is priority. Where is the context and relation between what is being specified? And how does the process ensure that the product owner doesn’t fall back to specifying things like, “Dialog X needs a dropdown field to display Y”, or “Build a screen to display user stats”? If you haven’t had to deal with this, then I desperately want to come visit your universe. If you don’t know why this is the biggest ingredient in a recipe for disaster, just continue building software this way.
The way to challenge this is with true, effective dialogue. What that looks like varies a lot. But it’s not about particular artifacts. If you read Manley’s criticism of our rounded corners, he relates the necessity of educating product owners. If dialogue is at the center of your process, the product backlog could function as a passable way to document the evolving mutual understanding.
My favorite idiocy in software development is the crystal ball method. Everyone has a crystal ball on their desks from which they can conjure a precise, detailed, perfectly focused picture of any event at any point in the future. Of course, this is an absolute absurdity. But that doesn’t stop people from believing such feats are possible. The product backlog easily falls prey to this delusion.
A much more useful metaphor is based on the simple fact of vision that any sighted person can appreciate. From where I stand, there are a number of things in crisp focus. Beyond that, things are mostly distinguishable by shape and relationship. I’m seeing the forest. Beyond that, only the vaguest, broadest features are distinguishable. I see that mountain, but the dark areas juxtaposing the snow may be forest or exposed rock. I can’t tell.
Attempting to draw on this fact of vision to inform and structure dialogue about a recent project, we set up a wiki with a page to capture descriptions of the software’s behavior in terms of goals. We have three sections: 1) near term goals, 2) medium range goals, and 3) long range goals. These follow the rough divisions of visual clarity described above.
The process of transforming those goals into software features and determining their priority based on architectural constraints is not something a client can dictate. You don’t tell your architect how to construct your house, you describe what you want in it. The reason for that is simple: physics dictates what is a viable structure. In software, we have no appreciation for physics. Clients believe they can do anything. All the rusting hulks of failed software littering the desert notwithstanding.
The essential way to bring the analogue of physics to software development is mutual education mediated by effective dialogue. What that actually looks like needs a great deal of definition. If this is just rounded corners on existing work, please point us in the right direction.
7 Responses to “One cuckoo flew over the nest”
Sorry, comments are closed for this article.
August 6th, 2006 at 06:50 AM Just seems to me like a huge debate is going on and instead of just getting to work, people are endlessly debating how they will work. That's great to a point - after that, it becomes an end unto itself. The more people you have working in your company doing the same thing, the more the competition will enjoy it. Trust me, I work for a company that is too blind to figure this out and they are starting to pay the price.
August 6th, 2006 at 06:55 AM PS. Being an atheist doesn't stop you from taking notes on index cards and blogging about a particular way of working. Clearly you ARE emotionally invested in something. That's not necessarily good OR bad, unless it slows you down or prejuidices your thinking, but don't make the mistake atheists always make of thinking not believing in one thing makes them objective and not emotionally invested in everything else. That's called "hypocrisy," another word atheists are happy to throw around. I do see a lot of joy over process or reinventing the wheel in certain tech communities... the RoR community does have some of that about it. I think RoR is an exciting technology, but it's the platform I find useful, not all the self-congratulatory (IMO) theorizing. I personally don't care about any of that.
August 6th, 2006 at 11:35 AM Here's another quote for you: "The map is not the territory." -- Alfred Korzybski Reading Schwaber's book is a good start to learning the language of Scrum, but it isn't the same as actually practicing Scrum, day in, day out, through several iterations, across several products. > That process is two monologues not a dialogue. All I can talk about is my own experience, and that experience suggests that the cultivation of the backlog is in fact many dialogues. If the team is truly collaborative, then the product owners don't work in a vacuum. As I tell my teams at least once a week, an item in the backlog is just a reminder to have a conversation. Those items come from all over -- client demands, analyst findings, technical findings, crazy ideas, whatever. In the process of recording the details, they do come to the tech team to talk about the feasibility of the new story, about possible implementations, about risks and business benefits. In the end, though, the feature is the product owner's responsibility -- the business goals are theirs. That's not dictation. That's collaboration. > 30-day sprint is too long. Since Schwaber's books, general wisdom is that iteration stability is more important than the magic number 30. What's actually necessary is that the iteration pattern is sustainable and comparable across iterations, so that the team can better appraise what they can get done. We do 30-day iterations because they fit the natural cycle of our business. The ROR crowd is fond of asking "what have you shipped?" That goes for the "software" of your team as well as the software your team builds. I'm way happy if you guys find something that works for you. I just can't help but think that some of what I've read is coming from a mis-reading of the Scrum methodology. Come on over to the Scrum discussion group. We'd be glad to have a dialogue.
August 7th, 2006 at 01:28 PM When I was exposed to SCRUM on a gamedev project, the iteration planning meeting was a dialog, not simply a handoff. It wasn't as structured as say the XP planning game, but I do think it's vital for that to be a negotiation. The developers need to know the business worth of these items. The business owner needs to know the implimentation costs. Likewise, the introspection meeting at the end of an iteration was key. I've not read the book, but I'd be surprised and disappointed if it treated the beginning and ends of iterations without these collaborative meetings.
August 7th, 2006 at 01:34 PM One other thought I forgot to had: What about making the backlog explicitly temporary? Use it for the same purpose as in scrum: a way to defer change until specific points in time, so that the team can pursue a fixed goal in a fixed unit of time. Then use anything on the temporary backlog as fodder for planning the next iteration. Once that iteration is planned, throw the backlog away.
August 7th, 2006 at 03:17 PM The Scrum literature does go over the bookend planning and reflection meetings. How those meetings are structured is subject to the team's organization. One of our teams can finish sprint planning in an hour because their stories are pretty simple and easily estimated and the client wishes are clear. Another team takes most of a work day to get through planning, because the work involves so many different stakeholder concerns and technical consequences. One thing about the books -- they aren't bibles. The Scrum community's ongoing discussions are as relevant for practicioners as anything else. Scrum "works well" when it is helping the team deliver software, for whatever value of "well" is defined by the team and stakeholders. >Once that iteration is planned, throw the backlog away. In my experience, the product backlog is pretty fluid. It serves as a library of conversations had and conversations to have. (The sprint backlog is more focused on immediate actions.) Things get put in the backlog by team members and they either float to the top and are addressed by the team when appropriate or sink to the bottom and eventually get discarded when they are no longer relevant to the product. There's nothing wrong with having some writing around as group memory between iterations. Just today on one of our larger products one of the programmers dropped a set of stories into the product backlog. They represented a number of ideas he'd had about the product based on discussions the stakeholders had had with the team as a whole, with me, with him, etc. The client team member acting as the product owner came over to talk about a couple of them immediately. Others they wanted to think about, and still others they needed to go gather some additional information on. While the team is concentrating in the sprint on what's needed by the client "right now," that doesn't preclude longer-term planning and experimentation. Not everything that's dropped into the backlog is going to get implemented, but some of it will, and some things will cross-pollinate and become other things that get implemented. Like they teach you in art school: you can't be afraid to waste paper.
August 9th, 2006 at 06:24 PM Radar: I'm an atheist and I'm not always making the mistake that being so grants me immunity from emotional attachment. In fact, I _am_ emotionally attached to these ideas because they are highly relevant to everything I do daily in my job. My point was that an atheist will not be coming to your door with a bible attempting to convert you. Should you happen to drop by my blog and listen in, perhaps you'll take away something of value. :)