Disciplined Agile

Not a week goes by where we are not asked to contrast DAD to SAFe.  In this short blog I would like to point out some things to consider as you decide whether to implement SAFe, DAD, or both.  First of all, a review of some quick facts about DAD:

• DAD is a process decision framework, not a methodology.  It is a hybrid of leading agile and lean methods with guidance on how to make better choices when applying strategies for the situation that you find yourself in.  DAD can be summed up as “pragmatic agile“, giving you the flexibility to adapt your approach for your unique context.
• DAD is not a scaling framework per se.  Indeed it can be equally effective on one small team as it is for agile at scale.  However mastering the DAD fundamentals of agile and lean in the enterprise dramatically increases your probability of sustainable success at scale.
• Unlike other frameworks, DAD supports four lifecycles:  Agile/Scrum, Lean, Continuous Delivery, and Exploratory/Lean Startup.  Most if not all large organizations will find each of these lifecycles to be necessary in some situations.

SAFe provides a largely prescriptive approach to decomposing large initiatives into smaller streams of work which can be implemented by a number of teams in parallel with periodic integrations of their work and delivery to stakeholders.  SAFe does fill a need as our industry had been lacking such a pattern for scaling these large initiatives.  In our opinion, it is suitable for situations for large agile teams (say 100+) and are working on a cohesive product ideally based upon a shared architecture.  The teams should also be very competent and can be depended on to reliably deliver functionality on a common cadence with the other teams in their release train.  SAFe is definitely not a good fit for teams new to agile.

In the last few weeks I reached out to a couple of our customers at very large organizations to find out in their words why they selected DAD over SAFe.  In the first company, although they had been doing some agile in pockets over the last eight or so years, they were lacking consistency in their approach and struggling to achieve the promised benefits of agile.  They initially chose to rollout SAFe.  However, after training 120+ practitioners they stopped the training and chose to pivot to DAD.  They realized that SAFe was a poor fit for their organization for the following reasons:

• The level of disruption required to roll out SAFe across the organization was not palatable
• The investment in training and the overhead associated with running the SAFe program would be too high
• SAFe would not be applicable to all types of projects so they would need another framework anyway.

In the second example, we spoke with a Fortune 100 company that is farther along in their agile journey with many highly advanced agile teams.  Their agile community of practice has over 1,700 members and they use many flavours of agile and lean.  They made a choice to go with DAD across the company rather than SAFe.  They do use SAFe in one area of business that has a large yet highly cohesive development team working on a common product.  But beyond this line of business they have a vast array of projects, technologies, and skill sets.  They chose DAD for the following reasons:

• Enterprise practicality
• A choice of four lifecycles supporting all flavors of agile yet having some consistency that a toolkit provides
• Built-in, lightweight agile governance
• Most of their development teams are geographically dispersed which would make SAFe impractical
• Support for projects using more traditional approaches (Note: In the majority of large enterprises agile teams need to collaborate with traditional teams)

We of course understand DAD’s value proposition but it is particularly useful to hear it from real customers.  While we are pleased that SAFe has given us a pattern for scaling agile initiatives albeit in a largely rigid and prescriptive fashion, we encourage you to consider the following points before rolling it out aggressively across your organization:

• Do you really need to have large projects?  A large organization does not necessarily equate to large development teams.  In fact you should try to reduce the size of your projects and product teams whenever possible to reduce overall risk.  In short, your first approach should be to “descale” to whatever degree possible because large projects typically fail.
• DAD provides the foundation for scaling.  Without a solid base of enterprise agile capability it will be difficult to successfully adopt scaling frameworks such as SAFe or LeSS.  If you’re still struggling to succeed consistently on small agile teams, what makes you think you can succeed on large agile teams?
• Agile governance built in.  Your sponsors don’t care what agile “religion” you follow.  They would however like to see consistent views on the health and status of your projects regardless of the implementation approach.  DAD provides guidance on lightweight governance in a consistent fashion.
• DAD is pragmatic agile.  The framework provides rich and flexible guidance for the vast array of situations that your organization faces.  DAD does this through its process goal driven approach.  Choice is good.
• One process does not fit all.  Beware the hype.  There is no silver-bullet process.  Even if you find a place to utilize SAFe, you will need other approaches.  So beware of hitting all projects with the SAFe sledgehammer.  It simply doesn’t fit in many if not most situations.

In a nutshell, our recommendation is to adopt DAD to support the diversity of people, processes, and technologies found in any large organization.  Then apply the SAFe scaling pattern if and when it makes sense.  Not the other way around.

In an upcoming article we will be describing how you could apply DAD to help you be more successful in your SAFe implementations.

This blog posting has been replaced by:

• Enterprise Architecture Workflow - Internal
• Enterprise Architecture Workflow - External

This blog posting has been replaced by Enterprise Architecture Practices.

This blog posting has been replaced by Enterprise Architecture Team Structures.

Organizations face an increasingly competitive marketplace.  To be competitive, organizations must be able to react to environmental changes and bring new offerings to market quickly.  This requires an adaptive approach to IT, which in turn requires a flexible and malleable approach to enterprise architecture.  To succeed in this new organizational climate enterprise architects require a new mindset, and new ways of working, that reflect the realities that they now face.

In this blog posting we describe a disciplined agile mindset for enterprise architects.  The following terms describe this mindset:

• Collaborative.  First and foremost, disciplined agile enterprise architects (EAs) collaborate closely with their stakeholders.  These stakeholders include business executives, IT executives, IT operations staff, and of course IT solution delivery teams.  Disciplined agile EAs will spend the majority of their time working with stakeholders.
• Learning oriented.  Every day, disciplined agile EAs strive to learn more about the people they are working with, about the business, about the business environment, about the technology and its application, and about the process they are following.
• Sharing. Disciplined agile EAs, and disciplined agilists in general, constantly look for opportunities to share their skills and knowledge with others.  An important part of their job is to help those around them to get better.
• Business focused.  Disciplined agile EAs must have an understanding and appreciation of the business and the way that it operates to effectively interact with, and support, business leaders.
• Multidisciplinary.  Enterprise architects will often start their architecture career as a solution architect, or a data architect, or a business architect, or some other architecture specialty.  Although these are good starting points, enterprise architects need to consider a wider range of issues than those focused on by each of these specialties.  Just as enterprise architecture frameworks such as TOGAF, Zachman, DODAF and others all take a multi-view approach, disciplined agile EAs must have the skills, or be in the process of gaining them, to address a wide range of views.
• Evolutionary. Disciplined agile EAs work in an evolutionary manner.  As you see in the following diagram, when your enterprise architecture team is first formed it may invest a bit of time to perform some initial architecture envisioning.  The team should come to an agreement around their overall vision and get some of the fundamentals captured.  Then the EAs will work with business stakeholders to understand and guide their vision for their lines of business, in particular how they can leverage technology more effectively to provide greater value to the organization.  The EAs will also work closely with IT delivery teams, often taking on the role of architecture owner on the team, so as to help guide and coach the team in architectural skills and concepts. The EAs will also meet on a regular basis, perhaps weekly for a couple of hours, to share what they’ve learned amongst themselves to evolve the architecture assets based on their learnings.  More on this evolutionary approach in a future blog posting.

• Practical.  Disciplined agile EAs are not afraid to get their hands dirty, which is why they will work collaboratively with their stakeholders.  They recognize that for developers, who are important stakeholders of their enterprise architecture efforts, that the proof is in the code.  As a result disciplined agile EAs will produce working code examples as the primary component of their reference architectures.  They realize that developers are much more likely to work with (and then copy) high-quality working code than they are to read a detailed white paper or detailed model extolling the virtues of some architectural concept.
• Pragmatic. Disciplined agile EAs know when to trade-off short and long-term gains and more importantly can help guide their stakeholders through these decisions while coaching them on the implications of what they’re doing.
• Improvement oriented.  Disciplined agile EAs are always looking for ways to streamline the processes that they run into.
• Reuse.  Disciplined agile EAs promote a reuse mindset with both their business stakeholders and with IT delivery teams.  To achieve reuse on a large scale within your organization there needs to be a guiding vision, and that vision is provided by your enterprise architects.  More on this in coming blog postings.
• Technical debt savvy.  Disciplined agile EAs should be a driving force within your organization for addressing technical debt.  They will guide and coach IT delivery teams on both avoiding new debt and on removing old debt.  In parallel they will work with business leaders to understand the implications of technical debt and help guide them in supporting IT delivery teams in addressing it.
• Technical.  And finally yes, disciplined agile EAs must have a technical background so that they understand the implications of the technologies in use (either now or in the future) within their organization.  As noted earlier, a critical strategy for keeping their technical skills fresh is to collaborate with IT delivery teams on a regular basis.

All the features on this list should sound like common sense – that’s because they are.  It’s probable that you’ve worked with enterprise architects in the past whose mindset exhibited many of these features, but did they exhibit all of them?  Likely not.  No matter how good you are, there is always room for improvement.

Related Readings

• The Enterprise Architecture Process Blade
• Agile Enterprise Architecture 101
• Agile Enterprise Architecture Team Structures
• Disciplined Agile Enterprise Architecture: A Goal-Driven Approach
• Disciplined Agile Enterprise Architecture: Workflow
• DevOps Strategies: Enterprise Architecture