Scott Ambler is the author of Disciplined Agile Delivery. We met Scott last year at Agile 2012. He has also spent time in South Africa. In fact, he proposed to his wife Dec 31st, 2004 while in South Africa. They will be married 8 years this October.
At Agile Africa there was a presentation on DAD which lead to some skeptical tweets. We decided to ask Scott if he’d be up for an interview to answer questions from some of the skeptics on twitter. You can either listen to the whole interview or read the extracts below. If you are just interested in a couple of questions, the transcript will tell you when in the recording those questions were asked. Thanks to everyone who contributed questions, and especially to Sheldon for the tweet that made this happen 🙂
Listen to the Interview
Read the Transcript
What is DAD and why should we care? [0:47]
DAD is a process decision framework, which is a bit different. I didn’t want to invent a new term like that, but I ended up having to. The basic idea is based on the observation that people make process, team structure and tooling decisions all the time, but they often don’t have the background to make those decisions.
Some of the common rhetoric in the agile community is that teams should figure out their own processes. That in general is pretty good advice but people often don’t know what their choices are. One of the ideas of DAD is to surface these options and give them some guidance to help them make these decisions.
Would you say DAD is a guide to selecting and adopting parts of your agile process, rather than an agile process itself? [6:02]
Yes, exactly, which is why we call it a process decision framework. DAD first came about when I was working at IBM, and my job was to help customers around the world to understand and scale agile and tailor it for unique situations. I got to see large numbers of teams, some which were doing well and others that were struggling. We started seeing common patterns, and we started seeing that there was a wide range of implementations, but that wasn’t really clear in the agile literature.
There was a lot of rhetoric around for example “the only way to manage requirements is a prioritised stack called a product backlog” in the agile community. Don’t get me wrong, it’s a great technique, but it’s certainly not the only way to manage requirements and it might not be the best way for everyone. To see several options, see http://www.agilemodeling.com/essays/prioritizedRequirements.htm
We noticed that even organisations that were doing well were spending a lot of time and effort figuring these things out because they had no guidance other than do it my way or sift through hundreds and thousands of techniques out there.
For someone new to agile how do you sift through all that and choose the right technique for your situation.
To prevent this obvious waste in the industry, we said
“Why don’t we capture some of this guidance”, and “Why don’t we capture some of the decision making process and help people make these important decisions”. That’s where DAD came about.
Another potential strange thing about DAD is that we are not prescriptive. We don’t even prescribe a lifecycle. We support several. For more on this , see http://disciplinedagiledelivery.wordpress.com/2012/12/20/a-full-agile-delivery-lifecycle/
Does it include Waterfall as a decision you could make? [11:19]
It does not, maybe it should. This reflects my prejudice against waterfall. If we were trying to be complete we should have. We do give advice about how to select between waterfall and lean and agile and others.
Dave West, who wrote the forward for our book, coined the term ‘Water-Scrum-Fall”. One of the reasons why I think we see “Water-Scrum-Fall” is that the agile community doesn’t give advice for the full lifecycle. It’s sort of left up in the air. Some organisations do very heavy upfront work, some sort of scrum in the middle and then do a heavy release. I mention this because it is in fact possible to tailor DAD to do Water-Scrum-Fall. Yes it’s allowed, but it’s not a very good idea.
Is there potential for people to pick Water-Scrum-Fall as an option and then claim to be agile because they used DAD? [13:25]
Well, yeah. My response to that would be to go review the process decisions you made, and discuss why these were good ideas for you, so we can start to have conversations.
Some people say DAD must be evil and bad because it allows people to make bad decisions. Those people probably would have made those decisions anyway.
I think we make it pretty hard to make those decisions but there are a few small cases where that makes sense.
One of the implications is that if you have 20 teams, they might have different flavours of their DAD process. This can be a challenge for people who need to interact with multiple teams.
Does DAD potentially give people too many options to make a decision? [17:43]
That is a big problem. So what we do is we suggest defaults. There is this overwhelming number of choices that you’ve got. If you don’t want to start making these choices right away, we give you a default. The default looks mostly like Scrum, if Scrum addressed the whole lifecycle and technical issues. If you don’t know where to start, start here.
Another nice side effect is making retrospectives more efficient. If you identify one or more challenges in a retrospective, you can look at what your options are to address that. See the discussion about taking a goal-driven approach at http://disciplinedagiledelivery.wordpress.com/2013/01/21/disciplined-agilists-take-a-goal-driven-approach/ to gain a better understanding.
If people have struggled to adopt Scrum, would it be different if they were using DAD? [20:33]
DAD presents a bigger picture; it looks at more issues. Scrum is a partial method; it doesn’t address technical issues. XP addresses technical issues, but neither of them addresses modelling and documentation other than some vague advice. None of them address database stuff and devops.
DAD amalgamates ideas from a large number of sources, so it saves you on that amalgamation effort. It also provides a full delivery cycle.
The organisations I’m working with now might have looked at Scrum or some other things and they go “Those guys don’t get it. They really don’t understand the enterprise and the issues I’m dealing with. I need better advice, and a bigger picture.” They don’t want something big and detailed and prescriptive. But they certainly don’t want something lightweight and hand waving. They need something middle of the road and this is something DAD’s bringing into the picture.
Why don’t we start taking some of the mystery out of agile and start helping? DAD will help get you going quicker.
Is DAD more applicable in larger organisations? [24:55]
It’s not really a team size or organisation size issue. Right now, I’m working with a team of about 30 developers. They aren’t a startup; they have been around 15-20 years. Because they’ve been around longer they realise they need to deal with all these other issues.
Even a start team doesn’t just start coding; there is a little bit of strategy going on, then there are iterations and then they deploy every so on. You can tailor DAD to be really lightweight.
I typically see DAD adopted by organisations that have been around 5 to 10 years; they are there to stay.
They have bigger things to do than just get something out the door quickly. They are looking at bigger issues.
Agile has a team focus; DAD has an enterprise focus.
That’s not the whole picture, unless you are a startup with only one team. We need to work together as an organisation, not just as single team.
How is DAD different to, or better than SAFe? [30:30]
I view SAFe like Scrum. Where Scrum prescribes a way to address certain aspects of IT so does SAFe, but with widely different scales. The focus of SAFe is for the most part on portfolio management at the enterprise level, with some advice on program management and release management.
It addresses what I would call enterprise level issues, which is good. Those are important issues. It doesn’t address all the enterprise issues. It doesn’t have much to say about architecture or strategic reuse or operations.
There are some pretty good practices in SAFe. The issue I have is that it does prescribe a single set of strategies. They have the release train, which is a great strategy, but it’s one of several strategies for co-ordinating releases of solutions. It describes a development lifecycle that is pretty strong Scrum but it has hardening sprints, which isn’t ideal. See http://disciplinedagiledelivery.wordpress.com/2013/07/12/coordinating-actitivies/ for a more robust discussion of coordinating activities.
Where SAFe basically prescribes, DAD instead says that’s one of several options and there are tradeoffs and there are better ways of working. For example, where SAFe recommends hardening sprints, DAD would instead say stabilise for a bit and get good at this hardening sprint stuff, but realise that there is still room for improvement and here are some strategies for doing so.
Our approach to scaling is getting a solid foundation in place first. Where Scrum and Kanban are a part of the picture. DAD provides end-to-end foundation from which to scale. Get good at the basic stuff first and then add complexity. DAD is a ground up, SAFe makes the assumption you have your act together at the delivery level.
Do you think people might see the default options of DAD as an excuse not to think? [36:58]
Yes, they could, but first of all they would have done it anyway. It makes it a lot harder because you’d have to have an entire team and probably an entire organisation that thinks the same way, and all settle on one choice and the never want to make a change.
What is more likely is that teams will start with the default, and then over time as they realise they can do better, they can go back to the decision trees (the process goal diagrams) to address a problem. But they would still have to have the get up and go to do that.
Why have you renamed the ScrumMaster to Team Lead? [38:45]
We want to remove the branding from some of the advice. The term ScrumMaster is not going over well in some organisations. ScrumMaster is not very descriptive. It’s got this goofy name issue. With team lead we are making it a little clearer that leadership is the way to go.
Is there a chance people will mis-understand and think that the team lead should tell people what to do? [40:14]
There is always opportunity for misunderstanding, so I would invite people to read the advice that we give.The term ScrumMaster is starting to tank in North America. Some of it is because of the questionable certification; some of it is because everyone is a ScrumMaster. 60% of people tell me they are ScrumMasters.
No matter what term you use, people are going to misintepret it, but ScrumMaster was not the way to go. ScrumMaster is in its heyday now, but that won’t be the case in 5 years.
Why did you add certification to DAD? Does it add value or just an additional revenue stream? [44:35]
I think both. It would be disingenuous to claim that it is not a revenue stream. I didn’t want to do certification. I’ve been outspoken about it for many years.
The reality is that a lot of people do expect some sort of certification. Unfortunately some of the agile certifications out there have really messed up the market. It’s really hard to sell courses that aren’t tied to earning some kind of certification. Without certification it’s hard to get your message out.
Our approach to certification is a bit different. My philosophy is that whatever the certification implies you have to put enough effort in to earn it. We talk about a yellow belt, green belt and black belt from martial arts.
The yellow belt says, “I’m a beginner, I’m learning”. That should be fairly easy to earn, so you write a test and show some knowledge. The belt doesn’t really say much. Other people will say you’re a “Master” or “Professional” after putting in that level of effort.
Green belt you have to have several years of experience and you have to pass a very hard test. Black belt you go before a board of other black belts, and you’ve got show not only deep experience but give back to the community. It’s hard; we really make you work for that. See http://disciplinedagileconsortium.org/ for more about certification.
What’s the correlation between the number people who get certified as yellow-belt and actual implementations of DAD? [48:55]
We aren’t tracking that. The challenge we’ve got now is that DAD is starting to spread so widely, with no feedback cycles to us. At the recent agile conference in Nashville I must have had over a dozen people from different organisations come up to me saying they are starting to adopt DAD. I said, “So have you taken a course or getting some help”. They said “No, no we’re figuring it out on our own, the book is good enough”. We don’t have this death grip on training that we see in other communities.
So you can get the certification without ever doing your training? [50:10]
Yes, exactly.
How did you come up with the name DAD? [50:20]
It was one of those long debates. We wanted the term delivery in the name; we weren’t that clear about having the word agile in the name. We wanted to distinguish, and one of the factors was this greater level of discipline. We’ve taken a bit of heat for that. Some people argue that agile is disciplined. But there are other aspects of disciple that are very clearly not in mainstream agile. We end the book with a detailed discussion of this, and will soon blog about it.
Does DAD encompass SEMAT and if so why? [52:50]
There are some ideas in SEMAT that DAD shares. There are some good ideas there, I’m in a wait and see mode on SEMAT.
Would you say DAD is people or process centric? [53:56]
It’s both. The focus in the DAD book is definitely on process stuff. That’s where most of the weakness is in the agile community right now. We promote people first, and all the usual agile advice. The focus of the book is on process, and purposefully so because that is where most agile efforts really run aground. People and culture issues are 80% or 90% of the agile adoption effort, but the other 10 to 20% of process and tools is absolutely critical as well.
As the agile manifesto says it’s not individuals and interactions period. It’s individuals and interactions over processes and tools.
Pingback: Agile Bullies
Comments are closed.