Disciplined Agile

I was hoping to come up with a pithy, short answer to this question but the only thing that I can come up with is “people.”  The not-so-pithy answer is that there is no sort of agreement around what it means to be a “qualified agile coach”, the people hiring coaches aren’t thinking things through in many cases, and the agile community suffers from a myriad of integrity challenges when it comes to professionalism. In this blog I work through the following ideas:

1. Why is there a dearth of qualified agile coaches?
2. Sports coaches as an example
3. What should we expect from agile coaches?
4. Our solution: Agile Coaching-Focused Certifications
5. Parting thoughts

Why is There A Dearth of Qualified Agile Coaches?

Let’s answer this in two parts: Why is there a dearth of agile coaches and why are there so many unqualified coaches available?  The first question is very easy to answer.  The demand for agile coaches far outstrips the supply.  The adoption rate for agile has been growing steadily since 2001, hence the growing demand.  As you’ll see later in this blog, it takes years to grow good coaches.  As a result there is little hope for the supply to catch up with demand any time soon.

The second question, why are there so many unqualified coaches available, is easy but uncomfortable to answer.  In general we have systemic challenges in the IT industry and in many ways we’ve managed to exacerbate these problems within the agile community. Some of the challenges within the IT community include:

• A person is just as likely to be a self taught programmer, and more likely in fact, than they are to have a computer science or engineering degree
• There is no sort of apprenticeship culture in this industry
• Few people have a personal goal of mastery, and few organizations support the gaining of mastery amongst their staff
• There is a shortage of talented people, so It is very easy to find and retain employment regardless of your level of talent, and the market is still growing
• No country has a licensing body for software professionals that is commonly required by organizations, unlike other professions such as doctors, lawyers, engineers, architects, and many more
• Many people in the IT community believe this normal for a professional, or if they do perceive a problem they are (rightfully) overwhelmed with the challenge of addressing it
• Colleges and universities are endemically years behind the quickly changing IT industry (there are a handful of schools that work closely with industry, so it’s getting better)

Then we have the agile community, with its various certification training scams.  You can become a certified master after staying awake during a two-day workshop and passing an online test that almost nobody fails.  To put this into context, a Starbucks barista, the kid who pours your morning coffee, get’s three days of training before being let loose on customers.  Yet it somehow makes sense that someone with 50% less training becomes the lead of a software development team?  Really?  Another example: Someone can become a scaling program consultant after attending a four-day workshop, and worse yet are now “qualified” to teach a two-day workshop to others so as to impart their vast agile scaling knowledge upon them.  Amazingly, because of the demand by companies desperate to hire agile-skilled people, the demand for these “designations” is incredible (shameful would be a more appropriate word).

In practice many agile designations are little more than “participation ribbons”, yet most organizations take them seriously often either because they don’t realize how trivial they are to earn or because they’ve given up expecting any better from agilists.  Is it any surprise that it’s hard to find qualified coaches when we’ve watered things down so much?

Sports Coaches as an Example

Coaching is very common in sports and with the exception of “pick up” games few sports teams are without a coach.  In fact, serious sports teams tend to have several coaches, typically lead by a head coach. In professional sports coaches are paid significant salaries, sometimes millions of dollars a year, as coaching is perceived to be a critical success factor.  It makes sense to look at sports coaching works to see how agile coaching might work.

Most sports coaches are former players.  They’ve typically played for years, and sometimes decades, having been coached themselves all along the way.  They’ll often start off as children, in Canada it’s common for kids to start learning to skate and play hockey at the age of two, being coached and drilled in basic skills and knowledge for years.  They also gain practical experience playing games.  Most kids drop out eventually, although many still play their sport (be it hockey, football, cricket, baseball, …) well into middle age.  And some decide to stay in the sport, but make the shift from being a player into being a coach.

The transition to becoming a sports coach generally isn’t easy.  There are three common strategies for this:

1. Formal training.  One path is to go to university, get a teaching degree, and become a gym teacher at a middle school or high school and begin coaching children.  These coaches tend to coach a wide range of sports, although in some cases you’ll often see a coach specialize on a single sport, such as high school football or hockey, because that’s what their passion was a child (and often because they hope to move up the ranks at eventually, see point #3 below).
2. Informal apprenticing.  Another path is to apprentice, asking your existing coach to allow you opportunities to coach others under their guidance.  When I trained in karate this was very common, with senior students helping to teach less senior students.  My daughter is currently learning to skate and they follow a similar pattern with senior skating coaches (adults) being helped by assistants (typically teenagers who have been skating for many years) to coach and teach the younger children.  Helping to teach or coach others is recognized as an important part of your own learning process.
3. Formal apprenticing.  Because of the money involved professional sports teams tend to take a more formal approach to coaching.  They will often expect coaches either come up through the coaching ranks – start as a high school coach, then become a college-level coach, then finally a professional coach – or to come up through the professional sports ranks – when your star players are past their peak they sometimes move into coaching roles.  Each time you move up to a new level of coaching, say from high school football to college football, you often start as an assistant coach to first prove yourself.  The head coach at each level recognizes that it’s their responsibility to grow more coaches, so they impart their skills and knowledge on to the junior coaches.

So, what are some important observations we can make out of all of this?  First, sports coaches have deep skills and experience at the sports that they are coaching.  Second, we expect this of them.  Would you pay to have your child to be given skating lessons by a “Certified Skating Master” who had two days of training in the “skating mindset” and how to facilitate a handful of skating meetings?  Of course you wouldn’t.  Instead you’d want someone who had been skating for years, and better yet may have even been a competitor at some point in the past.  Third, it takes years of apprenticing or training to become a good sports coach, not just several days in a certification workshop.

What Should We Expect From Agile Coaches?

Here is what we’ve found to be the critical success factors for agile coaches:

1. They should have years of agile experience, not days of training.  If someone doesn’t have years of experience in something, and more importantly years of varied experience, then why they heck would you hire them as a coach?
2. They should have coaching skills and experience.  Being experienced in agile isn’t enough.  Apprenticing under another good agile coach is a great way to get coaching skill as is getting training in agile coaching (the program at International Coaching Federation (ICF) is very thorough).  The need for experience is a bit of a catch-22 of course – you need to already be an agile coach to be qualified to be an agile coach.  But, if someone has no previous coaching experience then at best I’d put them into a junior coaching role under the guidance of an experienced coach.  This provides them with the opportunity to gain the requisite experience and to prove themselves in practice.
3. They should have robust agile skills and knowledge.  Years of agile experience is a good start, but better yet is a range of experience at all aspects of the lifecycle in which they are coaching.  It’s reasonable to expect a delivery team coach to understand all aspects of agile solution delivery so that they can coach the entire team in the skills they need to succeed.  Furthermore, it’s reasonable to expect an Agile IT coach to have experience in the full agile IT lifecycle, including areas such as Enterprise Architecture, Data Management, Portfolio Management, and many others.
4. They should have experience in a similar context.  Ideally they should have skills in a similar context to what you currently face – someone who only has small team coaching experience will struggle to coach a large programme, someone who only has only coached in startup companies will struggle in a large financial institution, someone who has only coached co-located teams will struggle with globally distributed teams.  Context counts.

All four of these factors are equally important.  Any “coach” who is deficient in one or more of these areas still has some work to do.  Nobody is perfect of course, given the rates that agile coaches demand it’s reasonable to expect these people to be qualified.

Our Solution: Agile Coaching Focused Certifications

A fair question to ask is how do we deal with this in the Disciplined Agile (DA) space. We believe that it’s critical to your success to have qualified coaches so we’ve built a principled certification program based on the martial arts philosophy of Shu-Ha-Ri.  Certifications must be earned and that takes time.  PMI offers three certifications that teach Agile coaching skills and knowledge:

1. Disciplined Agile Senior Scrum Master (DASSM). This certification addresses fundamental people and collaboration skills that are critical for anyone in a senior team position, including coaches, team leads, and architects.  More importantly it teaches how to lead agile teams in their process improvement efforts, including both software and non-software teams. Anyone hoping to become an agile team coach or team improvement coach should be interested in this certification. DASSM should be particularly attractive to anyone who is a Scrum or SAFe Coach, which have become commodities these days, as it teaches you how to lead improvements that go far beyond what you learn as a method-specific coach.
2. Disciplined Agile Coach (DAC). This certification is aimed at anyone wanting to become a senior agile coach.  DAC focuses on how to coach across disparate teams. What we mean by this is that we teach how to approach a problem where the team you are currently coaching needs to negotiate a new WoW with another team that is very different than their own. For example, how can you help your team work more effectively with your organization's procurement team, which has a different outlook, priorities, and WoW than your team?  DAC also teams how to coach non-software teams.
3. Disciplined Agile Value Stream Consultant (DAVSC). This certification focuses on how to define and evolve value streams within your organization.  Value streams are how you provide products and services to your customers. This certification is aimed at people wanting to become enterprise agile coaches or value stream coaches.

Parting Thoughts

It isn’t easy to find qualified agile coaches, but then again it isn’t impossible either. Our hope is that this blog has provided you with some insight into what you should be looking for in a good agile coach.  Anyone can put a shingle up and say that they’re an “agile coach”, but anyone who wants to say that they are a Disciplined Agile certified coach needs to have worked through a rigorous process to earn that qualification.  DASSMs, DACs, and DAVSCs have proven knowledge, experience, and give back.  Why settle for less?

Related Reading

• Disciplined Agile Certification
• The Principles Behind Disciplined Agile Certification
• The Limits of Certification

There are several values that are key to your success when transforming to a leaner, more agile approach to Data Management. Taking a cue from the Disciplined Agile Manifesto, we’ve captured these values in the form of X over Y. While both X and Y are important, X proves to be far more important than Y in practice. These values are:

1. Evolution over definition. The ability to safely and quickly evolve an existing data source, either to extend it to support new functionality or to fix quality issues with it, is absolutely paramount in today’s hyper-competitive environment. Yes, having defined data models and metadata describing them is also important, but nowhere near as important as being able to react to new business opportunities. Luckily agile database techniques, long proven in practice, exist that enable the safe evolution of production data stores.
2. Holistic organization over Data Management. Earlier we said that data is the lifeblood of your organization. Yes, blood is important but so is your skeleton, your muscles, your organs, and many other body parts. We need to optimize the whole organizational body, not just the “data blood.” Traditional Data Management approaches often run aground because they locally optimize for data concerns, whereas a DA approach to Data Management recognizes that we must optimize the overall whole. This implies that sometimes we may need to sub-optimize our strategy from a data point of view, for the sake of organizational level optimization.
3. Sufficiency over perfection. Data sources, like many other IT assets, need to be good enough for the task at hand. The old saw “perfect is the enemy of good” clearly applies in the data realm – too much time has been lost, and opportunities squandered, while development teams were forced to wait on Data Management teams to create (near) perfect models before being allowed to move forward. Traditional data professionals mistakenly assume that production databases are difficult to evolve and as a result strive to get their designs right the first time so as to avoid very painful database changes in the future. The Agile Data method has of course shown this assumption to be wrong, that it is very straightforward and desirable to evolve production databases. A side effect of this revelation is that we no longer need to strive for perfect, detailed models up front. Instead we can do just enough up-front thinking to get going in the right direction and then evolve our implementation (including data sources) over time as our understanding of our stakeholder needs evolve.
4. Collaboration over documentation. We’ve known for decades that the most effective way to communicate information is face-to-face around a shared sketching environment, and that the least effective is to provide detailed documentation to people. The implication is that we need to refocus our efforts to be more collaborative in nature. As data professionals we need to get actively involved with solution delivery teams: to share our knowledge and skills with those teams, and to enable them to become more effective in working with data. Yes, we will still need to develop and sustain data-related artifacts, but those artifacts should be lightweight and better yet executable in nature.
5. Cross-functional people over specialized staff. Agilists have come to realize that people are more effective when they are cross-functional (also known as T-skilled or generalizing specialists). Although specialists are very skilled in a narrow aspect of the overall process, the problem is that you need a lot of specialists to perform anything of value and as a result the overall workflow tends to be error prone, slow, and expensive. The other extreme would be to be a generalist, someone who knows a little bit about all aspects of the overall process. But, the challenge with these people is that although they’re good at collaborating with others they don’t actually have the skills to produce concrete value. We need the best of both worlds – a generalizing specialist with one or more specialties so that they can add value AND a general knowledge so that they can collaborate effectively with others and streamline the overall effort.
6. Automation over manual processes. The only way that we can respond quickly to marketplace opportunities is to automate as much of the bureaucracy as we possibly can. Instead of creating detailed models and documents and then reviewing potential changes against them we capture our detailed specifications in the form of executable tests. This is quickly becoming the norm for specifying both the requirements and designs of code, and the same test-driven techniques are now being applied to data sources. Continuous integration (CI) and continuous deployment (CD) are also being applied to data sources, contributing to improving overall data quality and decreasing the time to safely deploy database updates into production.

As you can see, we’re not talking about your grandfather’s approach to Data Management. Organizations are now shifting from the slow and documentation-heavy bureaucratic strategies of traditional Data Management towards the collaborative, streamlined, and quality-driven agile/lean strategies that focus on enabling others rather than controlling them.

Recommended Reading

• To read more, we have a detailed article overviewing a Disciplined Agile approach to Data Management
• Need training in agile skills for DW/BI?  Consider the workshop Disciplined Agile Data Warehousing(DW)/Business Intelligence (BI).

The quick answer is of course “Yes”.  ??

A couple of years ago we caused a bit of confusion when we expanded the scope of Disciplined Agile Delivery (DAD) to address the activities of an information technology (IT) department.  When we did this we realized that the scope of the toolkit and the name no longer matched, so we decided to rebrand to be simply the “Disciplined Agile (DA)” toolkit.  Having said that, sometimes it makes sense to say DAD and sometime DA depending on what you’re focusing on at the time.

The Scope of Disciplined Agile (DA)

As you can see in the following diagram, which depicts the scope of the DA toolkit, it’s clear why there has been some confusion because DA covers a lot of ground.

Let’s explore each aspect depicted in the diagram:

1. Disciplined Agile Delivery (DAD).  DAD addresses all aspects of solution delivery from beginning to end, in a streamlined manner.  This includes initial modelling and planning, forming the team, securing funding, continuous architecture, continuous testing, continuous development, and governance all the way through the lifecycle.  The framework includes support for multiple delivery lifecycles, including but not limited to a agile lifecycle based on Scrum, a lean lifecycle based on Kanban, and a modern agile lifecycle for continuous delivery.
2. Disciplined DevOps.  Disciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.
3. Disciplined Agile IT (DAIT).  As the name suggests DAIT addresses how to apply agile and lean strategies to all aspects of IT.  This includes IT-level activities such as enterprise architecture, data management, portfolio management, IT governance, and other capabilities.
4. Disciplined Agile Enterprise.  A Disciplined Agile Enterprise is able to anticipate and respond swiftly to changes in the marketplace.  It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces.  Such organizations require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.

Some History

The first “1.0 release” was the original Disciplined Agile Delivery book in June of 2012.  As the title suggests the focus was on DAD, although it laid the groundwork for Disciplined DevOps in that it baked in the development side of DevOps right into DAD.  In 2015 we began publishing our work in both Disciplined DevOps and Disciplined Agile IT (DAIT) and renamed the toolkit to Disciplined Agile (DA) to reflect this expanded scope. Since 2017 we have begun to flesh out Disciplined Agile Enterprise strategies and will soon begin the share them here on this site.

For the want of a whiteboard the vision was lost,

For the want of a new vision the release was lost,

For the want of a new release the product was lost,

For the want of a new product the customer was lost,

For the want of a new customer the company was lost,

And all for the want of a whiteboard.

With a nod to Benjamin Franklin.

The quick answer is no, that’s an incredibly bad idea.

We ran a study in February 2017, the 2017 Agile Governance survey, to explore the issues around governance of agile teams. This study found that the majority of agile teams were in fact being governed in some way, that some agile teams were being governed in an agile or lightweight manner and some agile teams in a traditional manner.  See the blog Are Agile Teams Being Governed? for a summary of those results.

The study also examined the effect of governance on agile teams, exploring the perceived effect of the organization’s governance strategy on team productivity, on the quality delivered, on IT investment, and on team morale.  It also explored how heavy the governance strategy was perceived to be and how well it was focused on the delivery of business value. The following figure summarizes the results of these questions.

Here are our conclusions given these results:

1. Agile governance helps agile teams. There is a clear co-relation between an agile approach to governing agile teams and positive results such as improving productivity, increasing quality, spending your investment in IT wisely, and improved team morale. This is what we believe the goal to be, to help the people being governed to be more effective and successful.
2. Traditional governance hinders agile teams.  There is a clear co-relation between traditional approaches to governing agile teams and reduced team productivity, reduced quality of output, wasting IT investment, and decreased team morale.  We believe that these results are the exact opposite of what you hope to achieve with your governance strategy.
3. Agile teams should be governed in an agile manner.  This follows directly from the previous two conclusions.  It should come as no surprise that your governance strategy should be well-aligned with what it is being governed.
4. Traditional governance strategies likely hinders traditional teams too.  We didn’t look into this issue directly, but our experience has been that traditional governance tends to be more of a hindrance than a help to traditional teams as well.

When we work with organizations to help them to adopt agile ways of working, we often find that they are running into several common challenges when it comes to IT governance:

1. They have both agile teams and traditional software teams.  This is because it’s a multi-modal world: You will have some teams taking a traditional approach, some an agile approach, some take a lean approach, and some are even skilled enough for continuous delivery.  Each team will follow the lifecycle that makes the most sense for them, and as a result each team should be governed by the approach that best suits the way that they are working.  To do anything different would be to hinder the teams, and that isn’t what good governance should be about.
2. There is a desire for a single approach to governing software teams. This makes sense on the surface because it would simplify your overall governance strategy, thereby making things easier for the people doing the governing.  But, as we’ve learned, this results in negative effects in practice.  Your governance strategy must be flexible enough to support the range of teams being governed.
3. The governance team is struggling to understand agile.  Your executives and middle management need education and coaching in agile and lean just like the people on your software team do.  It is naive to expect your governance people to devise a governance strategy for agile when they don’t really understand the implications of agile to begin with.

For agile to succeed in your organization the way that you approach IT must evolve to enable and support it, and this includes your governance strategy.  Reach out to us if you would like some help in addressing this important issue.

Related Reading

• Lean IT Governance
• Governing Agile Teams