A few weeks ago, I was explaining some of the concepts behind Dialogue-Driven Development to Michael Buffington and when I said that we were working to create patterns of Dialogue... his immediate thoughts were on code. I don’t remember the exactly how he worded it.. but he basically thought we were working on a parsing tool for grabbing requirements out of emails, messages, etc. I quickly explained that d3 had nothing to do with actual code and was merely a practice that we as developers and consultants are using to think about our interaction with clients, users, and amongst ourselves.
Just last night, I was chatting with a friend of mine about d3… (names changed to protect the guilty)
context: Harry works in a development team1 of about ten people and Paul is one of his “team”mates.
Harry: i guess it prevents discussion domination me: yeah, that happens as it is sometimes Harry: and ensures equal contribution Harry: paul does that and he's not very polite about it either and will often raise his voice and speak over you which is crazy kindergarten stuff me: hah Harry: need a talking stick!
This happens all too often amongst ourselves. While we’re striving to improve our client interaction… we often overlook our own internal struggles to achieve healthy collaboration. It takes discipline by every individual in a collaborative environment to really think together.
So, how does d3 address this? Well, it’s our goal that through mindful dialogue, we can cultivate healthier collaboration in all of our professional (and personal) relationships.
I would also like to point out a few common misconceptions about d3.
- d3 is not a methodology… nor a replacement for Scrum or XP. d3 is a thoughtful practice that focuses on the collaboration between a group of individuals, whether they be clients, developers, managers, or users.
- d3 is not a Silver Bullet, but it can be used as effective ammunition.
- d3 is not something you learn in a weekend, but you might be able to find a good book on Dialogue and have a new perspective on how you communicate with others.
Dialogue-Driven Development is about being in the conversation as it is happening… and really listening.
The next time that you’re getting ready to interact with your teammates, ask yourself:
- Am I contributing something meaningful?
- Am I listening to others well?
- Is everybody contributing an equal share of information?
If you’re quiet, try to speak up more. If you talk too much, be mindful of how much you may dominate a conversation. If you’re not participating at all.. why are you there?
1 You’ll be happy to know that Harry also gave his two-weeks notice yesterday.
6 comments Latest by MSM Thu, 10 Aug 2006 01:40:48 GMT
First, a quick update from our sponsors…
Brian and I talked yesterday and agreed to stop referring to Dialogue-Driven Development as DDD. We’ll leave that for the Domain-Driven Design fans. From now one, the short version for Dialogue-Driven Development will be d3.
MSM posted an email in regards to d3 on a Scrum development mailing list. He writes, “While I believe there’s room for plenty of Agile methodologies in the world and wouldn’t want to discourage the development of DDD if it helps them get their software written, I would hate to see Scrum described inaccurately, especially in a well-oiled meme propagation machine like the Rails community.” (link)
Michael D. Ivey responded with, “That being said…as someone who has gotten 100% into Rails development, I find myself using Scrum less. At least, on the surface, official Scrum. Rails makes meW^WWlets me be so productive that we are basically having 1 day sprints.
What’s interesting here is that we have a someone who is working with Ruby on Rails and finds himself using Scrum less because the environment is much different. This is exactly why Brian and I started seeking out something even more lightweight. We’re not aiming to replace other methodologies, but to structure our own that focuses on dialogue. With Rails, we’re finding that the amount of collaboration and dialogue with clients has both increased and improved tremendously.
Ivey also goes on to say, “I believe, having done Scrum well, and having done the ””Rails experience,”” that what Robby and …. the other guy …. are describing with ””Dialogue Driven Development”” is exactly what happens when you start with Scrum or something Scrummy, add a hyper-productive programming language and framework, mixin a very active and interactive customer, and then just start running at a comfortable pace and see when you get somewhere cool.
Perhaps Michael is right… and of course, this is open for discussion. :-)
Brian and I are spending a good deal of time thinking and talking about this stuff. We want to outline a new pattern that changes how requirements are gathered and documented through dialogue. It’s apparent that as we read different peoples comments on our articles that the general consensus is to interpret the Product Backlog pattern described in the books on Scrum in a way that works best for your team. The approach outlined in Agile Software Development with Scrum doesn’t work for us.
What’s your pattern? Share your story…
1 comment Latest by Sammy Mon, 07 Aug 2006 11:41:08 GMT
A few months ago, I posted an article titled, Trawling for Requirements, which was just before the Argon Express left for our trip to Chicago for RailsConf 2006. I’ve been kicking around some ideas with Brian ever since that afternoon on how there just seemed to be a big void in software development arena. It’s always felt that so many of the software development methodologies are designed to get developers to find a better way to work for and with clients. It’s our goal to outline a pattern that simplifies this process, not just for ourselves, but also our clients.
With each new project that our team starts, we are given an opportunity to improve on our evolving pattern for communicating with clients to better understand their goals. If there is one thing that we’ve seen help this process, it is consistent dialogue. When good collaboration exists through meaningful dialogue, confidence increases in not only the client. As developers, we are able to be confident that we understand their goals. This should generate better results.
“You are not writing requirements to serve as a contract with your client. Rather, you are writing them to ensure that both of you share the same and demonstrably correct, understanding of what is needed. Do not ask the client to sign off on the requirements; instead, ask the client to sign on to them and make them a collaborative effort.”
—Suzanne and James Robertson, Mastering the Requirements Process, 2nd Ed.
In Mastering the Requirements Process, the authors list the following as being key to identifying the project goal.
- Purpose: What should the project do?
- Advantage: What business advantage does it provide?
- Measurement: How do you measure the advantage?
- Reasonable: Given what you understand about the constraints, is it possible for the product to achieve the business advantage?
- Feasible: Given what you have learned from the blastoff, is it possible to build a product to achieve the measure?
- Achievable: Does the organization have (or can it acquire) the skills to build the product and operate it once built?
At first glance, I would agree that these are good questions to find answers for with your client.
Requirements, Not Solutions
Many clients come to us with a list of solutions (features) that describe implementation. This has been one of our concerns with the Product Backlog as it doesn’t discourage feature lists. Take a moment to read Goal Oriented Requirements, which gives you a few bullets to think about when interacting with your client when extracting requirements.
Take a moment to read Brian’s thoughts on the product backlog.
In Mastering the Requirements Process, the authors give two examples to show the difference between a solution and a requirement.
The product shall display pictures of goods for the customer to click on.
The product shall enable the customer to select the goods he wishes to order.
When requirements are defined in this form, it allows for further dialogue about multiple implementations.
For example, we’re working on a project where the product shall enable the users to send messages to a central system. We’ve defined a few specific implementations (email, text message, web form) and know that as new technologies emerge, the same requirement will still apply. It’s important to remember that we are gathering requirements not solutions and from there… we can collaborate with the client to design a solution that fits the requirements. Before we attempt to do solve the problem, we must ask that the requirement is aligned with the project goal.
We want our clients to assimilate our development methodologies quickly and naturally, which is what Dialogue-Driven Development aims to help achieve—namely through communication, something we humans do rather well. By lowering the learning curve and accelerating the integration of clients into our process, we can focus a greater sum of our collective energy on the needs of the client, the purpose of the project, and the goals of it’s users.
Although, perhaps we have it all wrong when trying to make software and the development process simpler as Paul Kedrosky suggested. ;-)
Our clients don’t just want simplicity. They deserve it!
4 comments Latest by Reagan Wed, 31 May 2006 04:29:40 GMT
In a previous post, I outlined how the PLANET ARGON team handles their communication of day-to-day work with the daily stand-up. Several people posted comments about similar processes and some suggestions were made to keep them from getting too stagnant. I wanted to highlight a few of those comments.
Aslak Hellesoy suggests, “Use a token – a rubber ball or something – for each person giving status. Only the person holding the token is allowed to talk.”
Florian Weber said, “Everybody standing up makes meetings go faster and more focus…”
However, not everybody is convinced…
Doug said, “I hate meetings, why on Earth would you punish your employees on a daily basis?”
Perhaps Doug has worked in environments that encourage too many bad meetings. A client recently said, “meetings are expensive” when we agreed to not have too many meetings throughout the project. Less meetings that are well-focused are much more valuable and productive. :-)
The one that caught my attention was the comment made by Aslak Hellesoy… he goes on to say, _“When a speaker is done, throw the token to a random person instead of just handing it to the left or right. This forces everyone to stay more alert, as noone knows who’s next.”
This got me thinking about how we had made it a ritual to stand in similar positions and I would start off the meeting. The team wasn’t too keen on throwing a ball around the room as we often hold coffee in our hand… so I came up with the following solution…. which reunites us with our little friends, the index cards!
Basically, all I did was take a stack of index cards and write a number on each one. Then at 9:15am PST, we all walk into the meeting room and take one. Whoever got #1 goes first and we work our way up from there. We’ve done this three times so far and most of the team seems cool with it. I’ll keep you posted as we solidify our approach to The Daily Stand-up.
...and of course… this comment also reaffirmed our decisions to do daily stand-ups…
Kevin Rutherford said, “Cool. And by “inventing” the idea yourselves, I guess you have much greater buy-in too?”
12 comments Latest by Scott Berkun Tue, 22 Aug 2006 03:17:19 GMT
I’ll admit it. I’ve never read a book that outlines that SCRUM process in detail but do have a copy of The Art of Project Management by Scott Berkun. In chapter ten, Berkun points out the purpose of having meetings as well as the annoyances that surround them. Over the past six months, we have toyed around with a few different approaches to holding meetings. There was a short period of time where we really weren’t sure what the best way to get company-wide information to everyone without boring them to death once a month or week.
A few months ago we tried something totally crazy… daily meetings! It caught on rather well.
There is one rule though, nobody can sit down. :-)
We hold a meeting every day at the same time and do not make any exceptions. Well, I will admit that we’ve missed two or three in the past several months but overall, we’re very good at keeping to the schedule.
So, how does this process work?
Each morning, I spend about 15 minutes preparing for a 10 minute meeting… which also is how I build my list for the day. This list appears on an index card as I keep it with me throughout the whole day. I also keep the previous and next days card with me so that I can make sure that things that didn’t get done yesterday get done today or tomorrow. Some of these tasks end up on BaseCamp or just get checked off as I complete the task.
Each morning at 9:15 AM PST (now you know where we are when we aren’t working or on IRC), we meet in our conference room and stand in something that looks similar to a circle. I wait until everybody finds their way into the conference room and then say, “Good morning!” I then do go over the following things (and use my index cards to keep me on topic)...
- What did I do yesterday (or Friday/weekend)?
- What will I do today?
Then the person who decided to stand next to me follows and we do this around the room… I think the order this morning was:
This is a good time to also bring up any thing that might be useful for everyone to hear… such as, “we got a new development contract signed yesterday!” or “client x will be on-site at 1:30 PM.” Along with this, we’re able to ask questions about other peoples work and act as a sanity check. Why the stand up? Nobody likes to just stand around for too long… when you stand up you avoid getting too comfortable and people are more likely to stay on topic and focused.
The meetings typically last 10-15 minutes and if you’re not doing something like this with your team… how do you cope on a daily basis?