Modified by ScottAmbler
On April 25, 2013 I gave a webcast for the Global Rational User Community entitled Disciplined Agile Delivery: Going beyond Scrum . During the webcast a large number of questions were asked but unfortunately I couldn’t get to all of them. So I’ve taken the opportunity to write up the answers in this blog posting.
Fequently asked questions. Many of the questions are addressed in the DAD FAQ.
DAD elevator pitch - I will be starting work in a couple of weeks for a company that has just started its Agile journey this year by implementing Scrum. What would Scott put in an elevator chat as to why they should be moving towards DAD. The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable. There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD is a non-proprietary, freely available framework. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users. It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you. The article Introduction to Disciplined Agile Delivery provides a more detailed description.
The book: Could you please repeat the name of the book that Scott is talking about? The book is Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise published by IBM Press, June 2012. The Disciplined Agile Delivery (DAD) website and the Disciplined Agile Consortium website are also good DAD resources.
The Surveys: Where is the data published about geographic distribution and effectiveness? All of my survey data, the original questions as asked, and my analysis can be downloaded free of charge from my IT Surveys page. If you ever see a request from me to fill out a survey, please take a few minutes and do so. I think you'll agree that my surveys page is in fact a very useful resource, so please contribute when you can.
Project success criteria: Where would a goal of defining success criteria fall? In the DAD book we describe how the success criteria for the project should be initially identified during Inception. Success criteria, like other things, could evolve throughout the project. You might find the IT Process Success Surveys to be of interest as several of them explored what success criteria projects actually have. Interestingly, its rarely “on time, on budget, to specification”.
Transitioning to DAD: How would you typically phase a DAD implementation, let's say in a project pilot where they haven't been exposed yet to Agile? Same question, any variance if the development team has already started Scrum? This is a fairly complex question to answer. The short story is that you need to invest some time to understand what your strengths and weaknesses are so that you can identify what you need to focus on. You will then likely need to pilot strategies/techniques which are new to your organization before rolling them out widely. You may also need to invest in training and coaching/mentoring depending on your needs. My company, Scott Ambler + Associates, offers these sorts of services and more for organizations interesting in adopting disciplined agile strategies.
Skills: I am aware that ideally developer should also be able to test but in reality theses are usually separate roles. Is it in line with your beliefs\suggestions? Many organizations that are new to agile still have roles that reflect their existing strategy. Non-agile approaches often have people in specific roles such as programmer, tester, designer, and so on. In DAD we promote a different set of agile roles that reflect agile thinking. The implication is that you’re going to have to help individuals transition over to the new way of thinking, something we cover in Chapter 4 of the DAD book. You might also find Mark Lines' blog, No role in DAD for an Analyst? to provide some insights into issues surrounding the transition from traditional to agile roles.
Teaming: What happens with the Product Owner and the Architecture Owner don’t Agree? See my blog What Happens When People Don’t Agree
Skillsets: Different people of the team have different skills, experience, and time horizons. We can't all be generalists, can we? There are several agile roles in DAD, each of which have different rights, responsibilities, and skillsets. So we’re not promoting the idea that everyone have the same skillset. However, we do promote the philosophy that people should strive to be T-skilled generalizing specialists so as to improve their productivity.
Teaming: What are your thoughts on team cohesion? Teams will gel over time. Being co-located helps. Having people who are dedicated 100% to the team helps. Building a team of people who want to be there helps. Self organization helps.
Tool support: Is there an RMC plug-in for DAD + Is there any software behind DAD... or some software that supports it... such as Jazz (RTC) for Agile/Scrum? Yes, IBM Rational does in fact have an RMC plug in for DAD. There is also a template for Microsoft TFS from RDA Corp, Software Development Expert’s Practices Advisor supports DAD comprehensively, and I’m currently working with MethodPark to do so too. Stay tuned to the Disciplined Agile Delivery website for information about tool support.
Governance: Regarding enterprise governance and enterprise IT, how do you start taking a culture that imposes common-process, common-tools, central (often outsourced) IT services, and heavyweight stage/gate across all organizations, and get that evolving toward a (still enterprise aware) lean/agile approach? This is a hard one. I’m often called into organizations to help with this very issue. The challenge is that you need to have a deep understanding of IT governance techniques as well as how to govern agile teams. Governance is something we discussed in detail in the DAD book as well as on the DAD site, see Adopting Agile Governance Requires Discipline.
Executable specifications: TDD was mentioned, can you comment on Behavior Driven Development (BDD) and any impact on this lifecycle? BDD is a slight nuance to acceptance test-driven development (ATDD). BDD/ATDD and TDD are both potential practices that you might choose to follow on a DAD team. I’ve written a fair bit about agile testing and quality strategies and about TDD in detail.
Architecture: When does the first version of architecture gets established and what would require to establish it? You typically start thinking about architecture early in a DAD project during Inception following a practice called architecture envisioning. I’ve also written a fair bit about agile architecture techniques and the potential misconceptions about agile architecture that you may find interesting.
Travel plans: Will you be coming to South Africa at some point? The good news is that Mark Lines, my co-author, will be in South Africa the week of May 20 in Joburg and the following week in Capetown. Contact us for details. I hope to be visiting SA later this year but exact dates haven’t been set yet. So, please stay tuned on Twitter at @scottwambler for further announcements.
Other travel plans: If you'd like me to speak at a local event, including corporate conferences or training events, please contact me.
It's been awhile since I've posted anything here, but that will soon change. I'm excited about some ideas that I have for upcoming blog postings around disciplined agile architecture and what it means to take a disciplined approach to agile solution delivery. Organizations around the world are finding that Disciplined Agile Delivery
(DAD) provides a solid foundation from which to scale agile, and I'm going to continue sharing my observations and experiences about scaling DAD here in this blog.
As many of you may know I left IBM in June 2012, after a six-year stint as Chief Methodologist for IT within IBM Rational, to form Scott Ambler + Associates
with Mark Lines. Mark is my co-author on the IBM Press book Disciplined Agile Delivery
, a topic I've written about extensively in this blog over the years. Since I left IBM I've remained in contact with several key people within Rational and have started working with them on several fronts. For example Walker Royce, Alan Brown, and myself are co-authoring a paper about scaling agile which we hope will be accepted at a prestigious academic conference in 2013. I'm also working with IBM Rational at the upcoming Agile Development Conference East
in Orlando, November 4-9. Both Mark and I will be presenting on DAD and Rational will have a booth and be throwing a party on Wednesday night which I'm looking forward to. Rational has thrown some pretty good conference parties in the past and I'm guessing that they will do so this time too. Hope to see you there.
In short, stay tuned as there's some exciting stuff coming your way soon.
The Disciplined Agile Consortium
recently launched a certification programme for practitioners of Disciplined Agile Delivery (DAD)
. There are three practitioner certifications
- Disciplined Agile Yellow Belt. This beginner certification indicates to colleagues and employers that you are eager to learn Disciplined Agile Delivery (DAD) strategies that enable you to increase your skills and abilities as a software professional.
- Disciplined Agile Green Belt. This intermediate certification indicates that you are experienced at DAD and are on your way to becoming a generalizing specialist. You have the potential to be a “junior coach” under the guidance of a senior coach (someone who is likely a Disciplined Agile Black Belt).
- Disciplined Agile Black Belt. This expert certification indicates that you are a trusted expert with significant proficiency at DAD. You can coach other people in disciplined agile strategies and advise organizations in the adoption and tailoring of the DAD framework.
Differentiate yourself in the marketplace. Certification in Disciplined Agile Delivery (DAD) means something to clients and employers because it needs to be earned. Certification in DAD tells the marketplace you understand how to deliver an agile solution from end-to-end with experience in enterprise-class development.
As an aside, the Disciplined Agile Consortium is proud to have IBM Rational's Richard Knaster and Carson Holmes the president of the Global Rational User Group (GRUG) on our board of advisors.
When you’re inside, safe in the warmth of your home watching snow fall on your driveway outside, all snowflakes look the same. But, when you look at a snowflake up close, particularly when you do so under a microscope, you quickly discover that all snowflakes are in fact unique.
It’s the same with IT projects.
When you look at them from afar, particularly
from a very high level, they all look the same.
However, when you look at them up close, you quickly discover that they too
The agile scaling factors
, which are really just general scaling factors applicable to all types of IT
project regardless of paradigm, help to make this very clear.
For example, when it comes to team size some teams
are small, less than ten people perhaps, some are medium sized, and some are very
large (with hundreds of people).
comes to distribution some teams are co-located in the same room, some teams
have team members in different cubicles in the same building, some have people
working in different buildings, and some even have people working in different
Many agile teams work in
regulatory environments, in fact the July 2009 DDJ State of the IT Union survey reports that one third of agile teams must
comply to industry regulations, although clearly many agile teams do not have
this as a concern. That’s only three
scaling factors. The point is that a
small, co-located team working in a non-regulatory environment will work much
differently than a fifty-person team working in three different locations,
which in turn works differently than a two hundred person team in the same
building working in a regulatory situation.
Different teams, facing different scaling issues will work in different
ways – unique snowflakes from a process point of view.
Just like there are 5Ps of marketing, there are also “5 Ps” of IT:
- People. People and the way they work together have a greater effect on the outcomes of a project than the processes they’re following or the products (tools and technologies) that they’re using. People issues include having visible executive sponsorship, building an environment of trust, empowering staff, focusing on leadership as well as management, recognizing that the primary gating factor when improving processes is people’s ability to absorb change, and promoting a cross-discipline strategy at both the team and individual levels.
- Principles/philosophies. We’ve found both internally within IBM as well as with many of our customers that there is a need to define a common set of principles to provide a consistent foundation to enable effective teamwork and continuous process improvement. These principles help to guide people’s decisions when their processes and practices don’t directly address the situation which they find themselves in.
- Practices/patterns. A practice is a self-contained, deployable component of a process. You might find the IBM Practices interesting.
- Products. This includes the technologies – such as databases, application servers, networks, and client platforms – and tools such as integrated development environments, testing tools, and project planning tools used to create solutions for stakeholders.
- Processes. The previous 4Ps do not exist in a vacuum, we need some sort of glue to help piece all of this together. Minimally this glue is a lifecycle although more often than not it is a full process or method.
My experience is that to be successful at software process improvement (SPI)
across your entire IT department that you must address these 5Ps. How you address each issue, and to what extent, will vary based on your situation.
My January 2010 DDJ Agile Update, Tragic Mistakes When Adopting Test Driven Development (TDD)
, is now online. In the article I summarize what I consider to be common, and tragic, mistakes that I'm seeing organizations make when they attempt to adopt TDD.
These mistakes include:
The article also goes into potential benefits of TDD as well as potential challenges that you're face when adopting it.
Timo Tenhunen has recently published his master's thesis, Challenges in Scaling Agile Software Development
, and has been kind enough to make it available online. I suspect you'll find it to be an interesting read.
I'm often asked by customers for case studies of successful agile adoptions or agile projects in general. This is definitely a valid request, and yes, such case studies exist. But I'm often concerned that the people making these requests don't appreciate the implications of what they're asking for. My concerns with case studies are:
- The juicy information is rarely included. The information that you really want to find out, such as what went wrong and why it went wrong, is rarely discussed. If problems, oops I mean "challenges", are discussed at all they're typically glossed over in favor of focusing in on the positives. Although many people want to write up the juicy bits this information is invariably edited out through the company's vetting process. In short, my advice is to take case studies with a grain of salt.
- Some case studies are more fiction than fact. Although this isn't a problem with IBM case studies due to the governance efforts of my good friends in IBM's legal department (we love you folks, really) it can be an issue with some case studies.
- The case study may no longer be true today. Stuff happens. Perhaps the case study was mostly true at the time it was written, but now that time has passed problems have appeared that weren't apparent earlier, thus the effort wasn't as nearly as successful as it was written up. For example, a few years ago I ran into the manager of a team that I had read about in one case study, only to find out that once the study was published the key team members left the company to become consultants in that subject area. Having lost these people, who were all very highly skilled, his system proved to be unmaintainable by the rest of his staff who weren't so highly skilled and had to be rewritten. Over time the success story turned into an abject failure.
- Waiting for case studies puts you in the position of follower. For every case study that gets written, dozens, if not hundreds of similar efforts didn't get written up. Writing case studies is hard, takes time, and the writer seldom gets much benefit from doing so. The lag time between the project completing and the case study being published can be many, many months and sometimes years. The implication is that by the time you wait for several case studies that are similar to your situation you've pretty much lost all opportunity for competitive advantage and are now merely trying to catch up to the organizations who are clearly ahead of you (the writers of the case studies).
- What has the requester given back to the community? I often hear people lament that there isn't enough case studies, or isn't something close enough to their situation. Yet, when I ask them how many case studies they've written and the answer is usually none. If you want to get you also need to give. ;-)
So, next time you think you need a case study before making a decision, recognize that you may be paying a fairly high opportunity cost for information that is questionable at best.Further reading:
At Agile 2009 in August Sue McKinney, VP of Development Transformation with IBM Software Group, was interviewed by DZone's Nitin Bharti about IBM's experiences adopting agile techniques. There are over 25,000 developers within IBM Software Group alone. Follow the link to the interview
to view it online (there is also a text transcript posted there. There's some great insights into the realities of scaling agile in large teams, in distributed agile development, and in particular how to transform a large organization's development staff.
Modified by ScottAmbler
I recently ran into an interesting issue at a customer organization. This customer is in the process of transitioning to Disciplined Agile Delivery (DAD) and part of that effort is to train, mentor, and coach their people in these new ideas and techniques. The challenge is that some of "their people" are full time employees (FTEs) and some are contractors/consultants. When we were planning an upcoming DAD workshop with them, part of the planning effort was to identify who should get that training, which we're delivering in a just-in-time (JIT) basis on a team-by-team basis. The only people invited to take the training were FTEs because the customer has a policy of not training contractors. I pushed back a bit on this, but they were adamant about not training contractors because their view was that contractors should either have the skills required to do their jobs or be willing to get those skills on their own time. Fair enough, but from an agile team building point of view this isn't ideal.
This situation got me thinking a bit. One issue is that not all contractors are the same. Some are short term contractors that are brought in for a specific purpose, they're paid well, and then they move on. Other contractors stay much longer, sometimes months or even years, and as a result gain deeper knowledge and understanding of your business. For these longer term contractors it seems to me that there is little difference between them and FTEs, perhaps only in the way that they're remunerated. Some countries such as the United States now have laws in place limiting how long someone is allowed to remain a contractor because these similarities lead to interesting legal questions around extending benefits to them.
Another issue is that if you intend to build teams from both FTEs and contractors, it behooves you to ensure that these people get similar training, coaching and mentoring to streamline the transition effort.
Here's the logic I would suggest to address the issue of whether or not to train a contractor:
Is the contractor going to be assigned to a key project/product for the organization? If not, don't train them.
Are they someone you want to keep long term? If not, don't train them and consider not putting them on the new agile team at all.
Does the contractor work for a large service provider? If yes, ask the service provider to cover the costs of training.
Is the contractor an independent or working for a smaller service provider? If yes, include the person in the training if there's room but don't pay their wage during the training period (so you effectively share the investment/cost of training).
As always, let the context of the situation drive your strategy.