Modified by ScottAmbler
The following diagram summarizes a safe and proven strategy for scaling agile delivery strategies at the team level. There are three features of this strategy:
- Basic agile and lean methods. At the base are methods such as Scrum, Extreme Programming (XP), Agile Modeling, Kanban, Agile Data, and many others. These methods are the source of practices, principles, and strategies that are the bricks from which a team will build its process.
- Disciplined Agile Delivery (DAD). Building on mainstream methods is the DAD process decision framework, providing an end-to-end approach for agile software delivery. DAD provides the process mortar required to combine the process bricks, effectively doing the “heavy lifting” to describe how all of these great agile strategies fit together.
- Agility at scale. Teams operating at scale apply DAD in a context driven manner to address the scaling factors that they face. These teams may be large, they may be geographically distributed in some way, they may face compliance constraints, they may be addressing a complex domain or technical environment, or they may be organizationally distributed in some manner. And usually combinations thereof. Without the solid foundation provided by DAD, agility at scale is incredibly difficult to achieve.
To scale agile successfully you must be able to tailor your approach to reflect the context that you face. To do this you must understand what your process and organizational structure options are and what tradeoffs each of those options has. Unless you’re a process expert, this can be challenging. This is where DAD’s process goal strategy comes in. Instead of prescribing a single way to do things, as we see in methods such as Scrum and SAFe, DAD instead captures your options in terms of process goals and guides you through making the decisions that best address the situation that you find yourself in. An example of a process goal diagram, in this case for the Inception phase goal Explore Initial Scope, is shown below.
The critical thing is that with a goal-driven approach it becomes much easier to understand how to scale agile. Depending on the context of the situation that a team finds itself in you will address each goal differently. The strategy for a small, co-located team facing a fairly straightforward situation in a non-regulatory environment works well for that team, the same strategy prescribed to a team in a different situation would put that team at risk of failure. Instead of prescribing a single way of working that is optimized for a specific situation we need to instead allow, and better yet enable, teams to adopt strategies that reflect the context of the situation that they face.
We’ve found that four of the twenty-two process goals seem to take about 80% of the tailoring impact. These goals are:
- Explore Initial Scope. This is sometimes referred to as initially populating the backlog in the Scrum community, but there is far more to it than just doing that. This is an important goal for several reasons. First, your team needs to have at least a high level understanding of what they’re trying to achieve, they just don’t start coding. Second, in the vast majority of organizations IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost. Having an understanding of the scope of your effort is important input into answering those sorts of questions.
- Identify Initial Technical Strategy. This is sometimes referred to as initial architecture envisioning or simply initial architecture modeling. You want to address this process goal for several reasons . First, the team should think through, at least at a high level, their architecture so as to identify a viable strategy for moving forward into Construction. A little bit of up-front thinking can increase your effectiveness as a team by getting you going in a good direction early in the lifecycle. It can also help to avoid injection of unnecessary technical debt as a result. Second, the team should strive to identify the existing organizational assets, such as web services, frameworks, or legacy data sources that they can potentially leverage while producing the new solution desired by their stakeholders. By doing this you increase the chance of reuse, thereby avoiding adding technical debt into your organizational ecosystem, and more importantly you reduce the time and cost of delivering a new solution as the result of reuse. You will do this by working with your organization’s enterprise architects, if you have any. This is an aspect of DAD’s philosophy of working in an enterprise aware manner.
- Move Closer to a Deployable Release. This Construction phase process goal is important for three reasons. First, it encompasses the packaging aspects of solution development (other important development aspects are addressed by its sister goal Produce a Potentially Consumable Solution). This includes artifact/asset management options such as version control and configuration management as well as your team’s deployment strategy. Second, it provides deployment planning options, from not planning at all (yikes!) to planning late in the lifecycle to the more DevOps-friendly strategies of continuous planning and active stakeholder participation. Third, this goal covers critical validation and verification (V&V) strategies, many of which push testing and quality assurance “left in the lifecycle” so that they’re performed earlier and thereby reducing the average cost of fixing any defects.
- Coordinate Activities. Although it is nice to believe that all of the coordination required by an agile team can be handled with a 15 minute stand up meeting every day the truth is far from that. This process goal addresses strategies for coordinating the work within a team, coordinating with other development teams (if needed), coordinating with IT groups such as your Enterprise Architects or data management group, and coordinating between subteams a programme or portfolio.
For a more detailed discussion of how these four process goals are the key to scaling your agile software delivery process, please refer to the whitepaper Scaling Agile Software Development: Disciplined Agile Delivery at Scale.
On Twitter one of the people that I follow recently tweeted in jest "I am waste". He had been tweeting about the problem that people will often pay consultants for their advice yet will not follow that advice once it's been provided (yet will often still keep paying for more advice). Perhaps in this situation his efforts were a waste, or perhaps the real issue was that the customer had a long learning process and hadn't yet come to the point where they were willing to act on the advice, we may never know. But I have to think that there are other situations where this person isn't a waste, regardless of his claims.
This got me thinking that something is a waste in one context yet in another context may be quite valuable. Or, as the old saying goes, one man's trash is another man's treasure.
For example, consider the following simple value stream:
[Activity A: 10 min] [Wait time: 20 min] [Activity B: 10 min]
Without considering the context, the wait time of 20 min represents 50% waste in the overall process that we should try to eliminate.
What if that wait time provides people with a much needed rest? With time to contemplate? With time to destress? Eliminating that wait time, or even reducing it, could result a degradation of performance. In this case, one person's waste (the wait time) is another person's treasure (rest time). The implication is that we need to work closely with the people intimately involved in a process if we're to help them to improve it.
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.
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.
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.
A few days later someone asked a series of questions that I thought would make an interesting blog posting, so here goes:How much of IBM's projects (in percentage) are agile at the moment?
I don’t have exact numbers, but I believe that 90%+ of our teams in SWG are applying agile techniques in practical ways that make sense for their projects. The primary goal is to be effective – in frequent releases, higher quality, and happy customers – not just agile. By the way, there is roughly 30,000 developers in SWG.Can all of IBM's projects work with an agile methodology?
It’s certainly possible, but it may not always make sense. Products that are in maintenance mode with few bugs or feature requirements may not benefit as much from agile practices -- those teams will likely continue to do whatever it is that they have been doing. Having said that, it's still highly desirable to apply agile techniques on maintenance projects.
Also, agile methods can be harder to use on some projects than others, for example, around hardware development. As a general rule, I believe that the majority of software projects can benefit from agile techniques. The primary determinant of whether a team can adopt agile techniques is culture and skill – not team size, the domain, or the degree of geographic distribution. That notion surprises many people who think that large agile teams
or geographically distributed agile teams
can’t succeed in adopting agile practices.Are agile projects sub-parts of large waterfall projects?
In some cases, that may happen. I’m sure it’s also true in reverse. We see many customers who are migrating from waterfall projects to a more agile way of doing things, and they often start this migration with smaller sub-projects. At IBM, we have tens of thousands of developers worldwide on hundreds of teams, so we have examples of pretty much any combination of agile, iterative, and traditional practices that you can imagine. There’s definitely not one size that fits all, which is a key aspect of the Disciplined Agile Delivery (DAD)
process framework.What do you think the impact of these numbers will be on the PM community?
The IBM PM community is embracing agile. And the reality is that a majority of development organizations around the world are moving to agile now as well (as much as 80% in some of the recent studies I’ve seen). I look forward to the increased adoption of agile methods by the PM community in general. The fact that PMI now offers an Agile Certified Practitioner training program certainly underscores the fact that agile practices are being adopted widely in the mainstream which is a great thing to see.
On Nov 16 2011, Kim Werner, Agile Coach from ATSC and Liz Parnell, Solution Design Manager from Blue Cross Blue Shield of North Carolina (BCBSNC), gave a webcast
sharing their experiences regarding how BCBSNC adopted a few Agile techniques, with the help of some good coaching, and adopted some IBM Rational Jazz tools
(Rational Team Concert and Rational Requirements Composer) to reduce time to market and lower development costs. BCBCNC works in the highly-regulated healthcare industry, so faced a few interesting constraints when adopting agile.
During the second week of August the Agile 2011 conference was held in Salt Lake City (SLC). As you likely know the Agile Manifesto was formulated 10 years ago in SLC so it was apropos to hold it there. There was some excitement around the 10 year anniversary of the manifesto, with a panel session with the 17 authors of it. Sadly there seemed to be little excitement around the efforts of the 10th anniversay agile workshop
in February which proposed a potential path forward for the agile community. I found the conference to be an evolutionary improvement over the conferences of the past few years, which is a very good thing because the focus since 2008 has moved beyond the "cool" new programming techniques to include the issues that enterprises face.
Starting at the Agile 2008 conference I've seen an uptick in interest in what I would consider some of the more mature topics in agile development, although I'm unfortunately still seeing significant confusion out there too, in part due to over-exuberence of people new to agile. For example, there's people still asking about basic issues about agile architecture
and agile database
techniques, although I was really happy to see more coherent discussions around scaling agile
. My own presentation about the Agile Scaling Model
was well attended and I suspect I opened a few people's eyes regarding the realities that we face (yes, there's a lot more to it than holding a "scrum of scrums", yeesh). We have a long way to go until people really start to understand scaling issues, but we're clearly on the path to getting there.
The conference show floor was interesting, with a wide range of vendors offering services and products focused on agile and lean. One thing that I noticed was many vendors had large monitors showing off their ability to support lean task boards, which for the most part they all looked the same. At the IBM booth we were showing off some of the Jazz tools
, in particular Rational Team Concert (RTC)
. For a long time now we've been giving away fully functional, with no time limit, licenses of RTC for teams of up to 10 people. Something worth checking out.
The Agile 201x conferences hosted by the Agile Alliance are always a good investment of your time and money, and Agile 2011 was no exception. See you at Agile 2012 in the great state of Texas!
I recently recorded an audio podcast
about Collaborative Development and Operations (DevOps) and how it relates to Disciplined Agile Delivery (DAD)
. The podcast is 17 minutes long and covers a range of topics including:
- What are the challenges typically faced by Disciplined Agile Development teams as they begin to transition their working solutions into production?
- How best could this gap between Development and Operations be closed so that they worked collaboratively rather than in silos?
- If this DevOps gap was decreased or even closed, what would the measurable value be to Agile projects and their business stakeholders?
On a related note, IBM's Collaborative Development and Operations
landing page has some great resources if you're interested in how to implement.
I recently did the voice over for our Rational.Everyware Agility@Scale whiteboard video
, which is a bit less than 4 minutes in length. As I narrate a whiteboard sketch evolves, sometimes using sticky-notes and index cards, to help explain what I'm talking about.
In the video, I describe:
- The history of agile
- Some of the challenges surrounding traditional development
- Some of the basics of agile, such as increased collaboration with stakeholders and on delivery of consumable solutions
- The benefits of agile, including increased quality, time to value, stakeholder satisfaction, and ROI
- Domains where agile is being applied successfully
- What IBM agility@scale is all about
- How some of the scaling factors change the way that you'll work and approach tooling
- Rational Team Concert (RTC), what it is and why you'd be interested in it
- Benefits that customers are seeing with RTC
- How you can download a fully-functional version of RTC for a team of up to 10, with no time limit, free of charge
So, it's basically a cool marketing video for a bunch of free stuff.