Project Management

Disciplined Agile

by , , , , , ,
#ChooseYourWoW | #ContinuousImprovement | #Kaizen | #ProcessImprovement | Adoption | agile | Agile certification | agile transformation | Analogy | Architecture | architecture | book | Business Agility | Certification | Choose your WoW | CMMI | Coaching | Collaboration | Compliancy | Configuration management | Construction phase | Context | Continuous Improvement | COVID-19 | Culture | culture | DAD | DAD discussions | DAD roles | Data Management | database | DevOps | Discipline | disciplined agile delivery | Documentation | DW/BI | Enterprise Agile | Enterprise Architecture | Enterprise Awareness | Essence | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Hybrid | Improvement | inception | Inception phase | Kanban | Large Teams | Lean | Lifecycle | lifecycle | Metrics | mindset | News | News and events | Non-Functional Requirements | non-functional requirements | Operations | Outsourcing | People | Philosophies | Planning | PMI | PMI and DA | Portfolio Management | Practices | Principle | Process | process improvement | Product Management | Product Owners | Program Management | Project Management | Promise | quality | Release Management | Requirements | requirements | Reuse Engineering | Risk management | RUP | Scaling | scaling | scaling agile | Scrum | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | Workflow | show all posts

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes

Recent Posts

Failure Bow: Choosing Between Life Cycles Flowchart Update

Evolving Disciplined Agile: Guidelines of the DA Mindset

Evolving Disciplined Agile: Promises of the DA Mindset

Evolving Disciplined Agile: Principles of the DA Mindset

Evolving Disciplined Agile: The DA Mindset

How Do You Coach an Agile DW/BI Team?

Agile2019 Agile DW/BI Coaching Workshop
The Agile DW/BI Coaching Workshop at #Agile2019

At the Agile 2019 conference in DC I facilitated a workshop with about 70 people where we explored the topic of how do you coach an agile data warehousing (DW)/business intelligence (BI) team. To do this we worked through four issues:

  1. What challenges do you face?
  2. What skills/knowledge does an agile DW/BI coach require?
  3. What strategies should you apply to engage with a DW/BI team?
  4. What are the qualities you should look for in an agile DW/BI coach?

The basic strategy was to introduce the issues to the class one at a time, then at their tables they would discuss the issue and write up to five ideas on sticky notes, then we’d share the ideas. Pictures of the flipcharts for each issue follow below. After the groups shared their ideas I then shared my thoughts with the class.

Issue #1: What Challenges Do You Face Coaching DW/BI Teams?

As you can see the class identified a lot of the classic issues that agile coaches face in general, such as trust issues, the teams being management-driven instead of self organizing, lack of agile skills within the team, cross-team dependencies, and being overwhelmed with work. Certainly there were DW/BI flavours of common problems, such as how to do vertical slices of DW/BI functionality and which lifecycle (agile, lean, CD, …) to follow. But there were also DW/BI specific issues, such as lack of access to data sources, knowing the actual data, and DW/BI architecture and design strategies. These DW/BI specific issues are where agile coaches tend to get hung up.

Agile DW/BI Coaching Challenges
Challenges commonly faced when coaching agile DW/BI teams (click to enlarge).

In my discussion of the challenges that we face when coaching agile DW/BI teams I shared my thoughts on the cultural impedance mismatch that exists between the agile and data communities. This mismatch makes it a bit more difficult to engage with data teams as opposed to application development teams. I also shared results of studies (2009, 2013,2016, 2018) around data quality challenges and practices – it is certainly common for teams to have to deal with technical debt, but data technical debt is both different in nature than code quality debt and the traditional data culture has led them down a very questionable (read dysfunctional) path regarding quality practices.

Issue #2: What Skills/Knowledge Does an Agile DW/BI Coach Require?

The second issue that we explored was what skills/knowledge does an agile DW/BI coach need. Once again the groups identified both classic agile coaching ideas as well as DW/BI specific ideas. Clearly you need coaching skills in order to coach a DW/BI team. But you also need to be knowledgeable about critical skills such as data modeling, data analysis, database testing, database refactoring, and others. You might not be an expert at these things, but you need to know of them and be able to guide the team in their adoption. You’ll also need to be able to speak intelligently about why some of the traditional strategies that they likely hold near and dear to their hearts (remember the cultural impedance mismatch) need to be abandoned for better, more effective strategies.

Agile DW/BI coaching skills
Skills/knowledge required of an agile DW/BI coach (click to enlarge).

In my discussion I overviewed the “agile database techniques stack,” a collection of agile strategies and practices for database development. The stack is:

As you can see, this list of techniques is fairly common from an agile point of view, albeit the corresponding data(base) versions of those techniques. The point is that the techniques exist that enable data professionals to work in an agile, and far more effective, manner. As a coach you will need to be aware of these strategies and be able to help your DW/BI team adopt them. And of course there are agile data management strategies that you need to be aware of as well.

Issue #3: What Strategies Should You Use To Engage Successfully With An Agile DW/BI Team?

The groups identified a collection of great strategies for engaging with DW/BI teams. Once again there were a lot of standard coaching strategies, a DW/BI team is still a group of people after all, but there was also a focus on strategies to address the DW/BI challenges identified earlier.

Agile DW/BI Coaching Strategies
Strategies to engage successfully with a DW/BI team (click to enlarge).

The discussion that followed the sharing of the stickies a very interesting point was brought up. I had earlier stated that my experience with coaching DW/BI teams was that it was different than coaching other types of teams, mostly because of the cultural impedance mismatch. A handful of agile DW/BI coaches in the audience disagreed with that, pointing out that the critical issue was gaining the trust and respect of the team at the start. This is true of any team, and certainly true of DW/BI teams. To do this you need to understand and appreciate the issues that they deal with and be able to show that you know how to guide them through addressing their issues. You might not be an expert in the techniques of the agile database technique stack, or other important agile data techniques, but you do know of them and can help the team learn them. So yes, engaging with an agile DW/BI team is no different on the surface, but it does require the coach to have different skills and knowledge than what your typical agile coach has.

Issues #4: What Are The Qualities You Should Look For In An Agile DW/BI Coach?

For this exercise I pretty much asked the groups to put together a list of qualities for a job ad for an Agile DW/BI coach. This is what they came up with.

Agile DW/BI Coach Qualities
Potential qualities of an agile DW/BI coach (click to enlarge).

Our Learnings

Here are our main learnings regarding coaching an agile DW/BI team:

  • You need fundamental agile coaching skills
  • You need to at least be aware of, but better yet experienced with, agile data and agile database development strategies
  • To effectively engage with a DW/BI team, you need to gain their trust and respect – to do that you need to show that you understand the challenges that they face and can help them to address them
  • To do so can be more challenging than with an application team due to the cultural impedance mismatch, the nature of data-oriented technical debt, and the lack of modern development skills within the data community – all of these challenges point to a greater than normal need for coaching on such teams
Posted by Scott Ambler on: August 24, 2019 07:35 AM | Permalink | Comments (0)

The Oath for an Agile Coach: Great Start, But We Need to do Better

Categories: Coaching

Coach

I recently ran into The Oath for an Agile Coach.  There are clearly some great ideas in the oath and it would be hard to argue that you wouldn’t want to adopt the advice contained within it.  So I won’t do that.  However, I do feel that there are some serious challenges surrounding the oath but that with a bit of hard work we could do better.

Some Great Ideas Here

Frankly, what’s not to like?  The oath promotes the idea that coaches should do no harm, that they’re guests, that they should respect learnings, that they value discretion, and many other wonderful philosophies.  Several of them are arguably a bit naive, for example:

  • First, do no harm. From one point of view the definition of an agile coach is to do harm – harm to the status quo, harm to the incumbent mindset, harm to the corporate politicians who rose to power building the current environment that the coach is there to help the organization improve.  You wouldn’t be much of a coach if you weren’t doing harm to the bad stuff in your organization.
  • I prevent dysfunction.  Really?  I’ve worked in many environments that are “target rich” when it comes to dysfunction.  I’m expected to help prevent all of these dysfunctions right away?  I’m supposed to prevent dysfunction that is beyond my current scope of influence?  Of course not.  I need to help the people that I’m working with to identify and prioritize their pains, then help them address these pains as and when it is appropriate to do so (if ever).  Clearly the advice in the oath is context sensitive and it isn’t meant to be taken literally.

It’s clear to me that a lot of smart people have put a lot of effort into the oath, that they’ve thought it through, and are honestly trying to make things better.  I also believe that this is a step in the right direction, although at the time of this writing there are some serious challenges surrounding it that can and should be addressed.

 

A Few Serious Challenges

First and foremost, we should give the authors of the oath the benefit of the doubt and assume that they aren’t doing the things I’m about to describe on purpose.  Although what I have to say is harsh, I honestly believe that the authors have their hearts in the right place but have not thought through the implications of what they’ve started.  So here goes.

The oath is deceptive and as a result possibly unethical.  The reason why I say this is that they claim to have based the coach’s oath on the The Hippocratic Oath (which I’m sure they’ve actually done).  The problem is that they’ve merely skimmed the surface of the Hippocratic Oath, lifting ideas such as “First, do no harm” (which the oath doesn’t actually say, that’s the Hollywood interpretation of it) without also adopting the context in which the Hippocratic Oath is taken.  This is important.  New medical practitioners, after years of training, are asked to take the oath, or something similar, by medical schools.  These schools are governed and the medical professionals themselves are governed.  Control mechanisms are in place to ensure that the people who take the oath know what they’re doing and work in a trustworthy manner.  Therein lies the rub – no such governance exists for agile coaching and I suspect the vast majority of agile coaches would chaff at the suggestion.

To see why this is an issue consider the following example.  I have no medical training or background, with the exception of taking a few first aid courses over the years.  Come to think of it, by agile standards I have more than enough medical training to be considered a Certified Surgery Master (CSM), so it’s all good. I have just now recited the Hippocratic Oath and have pledged to abide by it.  As a result I now feel that I am qualified to offer plastic surgery procedures as I’ve heard that this is a lucrative business to be in.  If you would like a face lift, liposuction, or augmentation of a body part please contact me to arrange a procedure.  You can trust me because I’ve recited the Hippocratic Oath and I’m a CSM.  What?  You’re not interested? I’ve pledged to do no harm, so you can trust me.

I think that you inherently know it would be a bad thing for me to perform plastic surgery on you.  I’m obviously not qualified.  Therein lies the rub.  I could easily advertise that I’ve pledged the oath, tell people about my CSM credentials, and make it sound like I’m qualified, particularly to people who don’t have much of a background in agile.  In fact, recently in Toronto, a 19-year old woman did something very similar to this and as you’d expect it didn’t work out well for the recipients of her surgery endeavours.

By claiming that the agile coach’s oath is based on the Hippocratic Oath the authors are taking advantage of something called “prestige association.”  The Hippocratic Oath is prestigious – the people who pledge it have to work very hard to be asked to pledge it and are subsequently held to its high standards throughout their careers.  By explicitly associating the agile coaching oath with the Hippocratic Oath the prestige of the latter is conferred to the former.  This is deceptive at best and unethical at worst.  I believe we can be better than this.

 

How We Can Do Better

It isn’t appropriate to complain about the Agile Coach’s Oath without also providing some possible ways to fix it.  Here are my initial thoughts:

  1. Avoid prestige association. The very first thing, and easiest thing, that could be done is to stop comparing this oath to the Hippocratic Oath.
  2. Define paths to becoming a great coach.  A straightforward, and relatively easy, way to add real value would be to put together a path, or more likely several paths, that people could follow to become a great coach.
  3. Help people to follow those paths. In short, build a respectable agile coaching guild that focuses on helping people over making money off of them.
  4. We need to respect ourselves. This is an observation for agilists in general, but particularly important for agile coaches.  At the present moment the Agile Coach’s Oath is yet another vapid agile band wagon for people to jump onto without having to do any real work.  As coaches we lament the large number of lame agile “certifications” that are little more than participation ribbons, so perhaps it’s time we choose to say enough is enough.  We know that effective coaching requires skill, knowledge, and experience that require years of hard effort to earn.  Just like the medical community requires years of education and training before extending the privilege of asking someone to take the Hippocratic Oath, we could choose to do something similar.  But first we’d need to respect ourselves enough to actually do that.

I believe the people who developed The Oath for an Agile Coach have good intentions.  They’ve gotten a great start on an interesting and potentially valuable idea. But, they need to follow through and make it something real if they really want this oath to be meaningful.  I hope they choose to build a vibrant community that does exactly that.  Time will tell.

 

Related Postings

Posted by Scott Ambler on: November 15, 2017 09:55 AM | Permalink | Comments (0)

The Agile Enterprise Coach

Coach

When your organization chooses to transition to more agile and lean ways of working you quickly discover that this effort needs to address all aspects of your organization, not just your solution delivery teams.  Many transformation efforts invest in agile team coaches, which is a very good thing to do, but will often shortchange other areas of coaching in the belief that they’ll figure it out on their own.  It may work out that way, but even when it does this is an expensive, slow, and error-prone approach.  In our experience it’s far better to get help from an experienced Enterprise Coach.

An Enterprise Coach coaches “beyond the team” to help senior managers and leaders to understand and adopt an agile and lean mindset.  As you will soon see, this requires a similar yet different skill set than what is required for team coaching. In this blog we work through three key concepts:

  1. The types of agile coaches
  2. Skills of an Enterprise Coach
  3. Supporting other coaches

Types of Agile Coaches

As you see in the following diagram we like to distinguish between several types of coaches:

  1. Team coach. As the name suggests, a Team Coach coaches solution delivery teams through improvement efforts. The focus is usually on improving the performance of individual teams. This is the most common type of coach, and our guess is that 95% or more of agile coaches fall into this category.
  2. Specialized coach. A “specialized coach” is someone who focuses on non-solution delivery aspects of your organization.  They are typically senior team coaches who have a deep background in one or more process blades.  For example, you may have a specialized coach focused on Enterprise Architecture and Reuse Engineering for example; or one that is focused on Finance, Portfolio Management, and Control; or one that is focused on Enterprise Architecture and Data Management.  The people who are working in non-solution delivery areas need coaching just like people on solution delivery teams do.  More on this in a future blog posting.
  3. Enterprise coach.  Sometimes called Transformation Coaches or Executive Coaches, these coaches work with senior and executive management to help them to understand new ways of working and organizing themselves.  Enterprise coaches will often focus on executive coaching, of which there are three types: IT executive coaching, business executive coaching and manager coaching.  All are equally vital to your agile transformation and continuous improvement efforts.  An area often ignored in coaching is the role of managers as agile leaders and coaches of your agile teams.  Executive Coaches can help guide managers from a style of “managing” to leadership.  Enterprise Coaches often find that they also need to take on the role of a Specialized Coach too. A key responsibility of an Enterprise Coach is to support the other coaches when they need help. The focus of this blog is on Enterprise Coaches.

Agile Communities of Excellence

 

Skills of An Enterprise Coach

The skills of an Enterprise Coach include:

  1. Coaching skills. First and foremost, enterprise coaches are coaches.  They require all the people, collaboration, and mentoring skills of other agile coaches.  They should have many years of hands-on coaching of individual agile and lean teams in many types of situations, from the simple to very complex.
  2. Domain knowledge. An enterprise coach must have knowledge of the domain that they are working in.  There are unique challenges in financial organizations that you don’t see in automotive companies, similarly pharmaceutical companies are different from retailers, and so on.  Yes, it is possible for Enterprise Coaches to quickly learn the fundamentals of a new domain, but you’ll find that in the beginning the executives that the Enterprise Coach is helping to learn agile will have to help them learn how the business runs.
  3. Understanding of how IT works. Enterprise Coaches need to understand how a Disciplined Agile IT (DAIT) department works so that they can coach IT executives effectively.  Enterprise Coaches help IT groups such as Enterprise Architecture or PMOs to understand how they need to adapt to effectively support Agile teams.
  4. Understanding of how to apply agility at the enterprise level.  Similarly, Enterprise Coaches should understand how a Disciplined Agile Enterprise (DAE) works.  Enterprise Coaches should be experiences with modern agile practices related to non-IT functions such as human resources (also called People Management or People Operations), finance, and control.  Coaches bring expertise on practices in these areas such as modern compensation and reward systems, agile budgeting, rolling wave planning, agile procurement, and agile marketing.
  5. Experience and knowledge of the various IT domains. A broad understanding of IT is critical, and better yet deep knowledge of several of the IT process blades so that someone in the Enterprise Coach role can guide any specialized coaches or step into that role themselves.  This is important because people working in areas such as Data Management, Release Management, or IT Governance often believe that they are “special” and agile can’t possibly apply to them (it’s only for programmers after all).  Without a good understanding of these areas an Enterprise Coach will struggle to help the IT leaders that they are coaching to counteract these arguments.
  6. Transformation and improvement coaching.  Enterprise Coaches should understand, and be experienced at, lean approaches to organizational transformation and improvement, often referred to as Organizational Change Management (OCM).   Traditional approaches to OCM will not work.
  7. Ability to support team and specialized coaches.  See below.

Supporting Other Coaches

Enterprise Coaches support other coaches in several important ways:

  1. Transformation/improvement visioning.  Enterprise Coaches help executives to understand modern agile and lean practices used by successful agile organziations and help to create a roadmap for moving from their current to target state.
  2. Organizational structural change.  Experienced coaches can help organizations to create organizational structure to be conducive to the evolution of high performance teams.  This would include design of cross-functional, stable teams aligned to value streams or lines of business (LOBs).  They can also help design workspaces for effective collaboration between team members, and help reduce the need for separate meeting rooms.
  3. Organizational coordination.  One of the most important things that an Enterprise Coach does is help team coaches to overcome challenges collaborating with other, not-so-agile teams.  The reality is that 96% of agile teams must collaborate with one or more teams or groups within their organization at some point, 96%!  Some of those teams may very well be struggling with working in an agile manner and may even be opposed to it.  These sorts of challenges are often beyond the remit of a team coach to address, so when they occur the team coach will often ask for help from an Enterprise Coach who does have the relationships with the right people to smooth over such problems.  Enterprise Coaches can also provide advice for effective collaboration strategies with vendors and offshore teams.
  4. Resources. Enterprise Coaches will sometimes help other coaches to obtain the resources – typically time and money – required to coach the teams that they’re working with.
  5. Communication.  The Enterprise Coach will actively share the overall vision of your improvement efforts, the current status, and any organizational challenges that you’re running into with the other members of the CoE.  They will of course be actively working with the people responsible for communicating this information to the rest of the organization as well.
  6. Coordination. Enterprise Coaches will often coordinate the efforts of the various team coaches in your organization to ensure that they’re working together effectively.
  7. Mentoring.  Enterprise Coaches, being senior, will often be coaching the team and specialist coaches (all the while learning themselves).

There is of course a lot more to agile coaching that what is covered in this short blog.  Our goal with this writing was to overview the role of Enterprise Coach and show how it fits into the overall scheme of things.

Posted by Scott Ambler on: October 04, 2017 08:19 AM | Permalink | Comments (0)

Agile Adoption and Team Productivity

A common question that people ask is how does the adoption of agile within a team affect its productivity?  The answer to this question will vary by team, but there are several common patterns that we’ve seen over time.  In this blog we explore:

  1. What does increased productivity mean to you?
  2. Agile adoption patterns
  3. What milestones to look out for as a team adopts agile
  4. What you can do to increase your chance of success
  5. How do you know productivity improved?
  6. Agile is about more than productivity improvement

What Does Increased Productivity Mean to You?

Productivity is defines various measures of the efficiency of production, and is calculated as

Value of Output divided by Cost of Input

The implication of this calculation is that there is flexibility in the way that we can increase the productivity of a team:

  • Produce the same output with less cost (i.e. with fewer people).
  • Create greater value with the same number of people.
  • Deliver value incrementally more often, thereby earning value sooner for a longer period of time (this is called decreasing the cost of delay)

Remember that context counts – each team will choose the most appropriate way for them to increase their productivity. Having said that, a common result of a team adopting agile is to incrementally deliver value more often.

Agile Adoption Patterns

The following diagram overviews three common patterns when it comes to productivity change when teams adopt agile.  You’ve likely seen simpler versions of this diagram elsewhere that only show the dark green line, but our experience is that’s only part of the story. You can see in all three cases that the adoption of agile results in an initial productivity loss on a team – this reflects the reality that with any type of change it will take time for a team to learn the new strategy, to identify how it fits into their environment, and to learn the new requisite skills and behaviours. Agile adoption productivity

The three patterns, from least desirable to most desirable, are:

  1. A failed agile adoption (red line). Teams fail to adopt agile for several reasons, usually because the team doesn’t want to adopt agile ways of working, the organization doesn’t properly support their adoption efforts, or the rest of the organization continues to drag them down with traditional ways of working.
  2. A successful agile adoption (green line). Luckily most teams succeed in their agile adoption efforts, and numerous studies have shown a wide range of benefits including faster time to delivery, increased quality, increased stakeholder satisfaction with the delivered solution, and improve team morale to name a few.  Every team is different, but overall on average adopting agile is a positive experience.  You’ll land on this curve when you treat agile adoption as a project, something you do for a few months to help make the team more effective, if you’re successful.
  3. A successful agile adoption evolving into continuous improvement (green dashed line). The most successful teams realize that process improvement isn’t a short-term project but instead is a long-term journey that you undertake.  This is reflected in the dashed line in the diagram below.  You typically start by following a transformation strategy with the team – you get them some initial training, some coaching, help them change their work environment and tooling to be more collaborative.  Then at some point an improvement mindset begins to take hold within the team, one of the fundamental aspects of agility.  The team reflects on a regular basis, identifying potential ways that they can improve and then they experiment with those strategies to see which ones work in practice for them. It’s at this point that they’ve shifted out of the transformation strategy into more of a continuous improvement strategy, which is what enables them to reach higher levels of productivity than what is typically achieved with just a transformation strategy.

What Are the Key Milestones to Look For?

There are three key milestone points on the successful paths that you should watch out for:

  1. Productivity trough (4-8 weeks). With anything new there is always a learning curve, and agile is no exception.  When a team begins to move towards agile their productivity will drop for several reasons: they will likely invest some time taking training, it will take people time to learn new techniques and adopt new ways of working, and it will take time for the team to determine how they will work together following these new agile strategies.  Your productivity levels tend to bottom out after four to eight weeks and then after that will start to improve.  The amount of time varies by team, depending on whether any team members have previous agile experience that they can leverage, how much team members want to change, how effective the training is, and whether you have the support of an experienced and effective coach.
  2. Productivity recovers (2-4 months).  For most teams, the ones who are successful at becoming agile, their productivity levels will recover back to the level they were before they started on their agile improvement journey, within two to four months of starting.  This amount of time depends on the same issues mentioned before.
  3. Improvement culture takes hold (3-6 months). This is the point where the improvement mindset really kicks in and the team starts to explicitly work together to improve the way that they work. This is a reflection that the team is actually “being agile” and not just doing agile ceremonies. Sadly not all teams reach this point and move up onto the dashed green line in the diagram above.  Whether they do so or not is primarily dependent on the willingness of team members to become agile, the quality of the coaching that they receive, and whether your organizational environment allows them to own their process.

How Can You Improve Your Chance of Success?

There are several strategies that you can employ to increase your chance of successfully adopting agile and shifting to a continuous improvement culture within your team:

  1. Invest in training. Get the team started on the right foot with training that not only goes into the fundamental concepts behind agile (“being agile” training) but also works through from beginning to end how agile works in practice (“doing agile” training).  Being agile training is incredibly easy to find, but good “doing agile” training that is comprehensive is much harder to find.  Luckily there are several very good Disciplined Agile training offerings that focus on how to “do agile” in enterprise-class settings.
  2. Hire an experienced coach. A good coach will help your team to avoid common learning pitfalls, and better yet quickly guide you through “learning experiences”, working through with you how to improve the way the team works. Hiring a coach can be a challenge because as we show in Why is it so hard to find qualified coaches? it is possible for anyone, and unfortunately they often do, to claim that they are an agile coach.  Effective coaches have deep experience in what they are coaching as well as skills in the act of coaching itself.  The majority of “agile coaches” tend to to be short on both of these things, and the few coaches that are qualified are in high demand.  There are several Certified Disciplined Agile Partners that you may want to reach out to for Certified Disciplined Agile Coaches (CDACs).
  3. Give the team an “organizational pass.” It’s incredibly difficult for a team to become agile when they are still surrounded by other groups that are actively working in a non-agile manner.  Agile teams need to collaborate with others to achieve their goals (in fact, the 2016 Agility at Scale study found that 96% of people indicated that their team needs to interact with at least one other team).  So, if you want to enable a team to become more agile and improve then you also need to motivate these other teams they rely on – such as the data team, the enterprise architects, and even the governance team – to be sufficiently flexible to work with the agile team in an agile manner.  In some cases the agile team may need to be “given a pass” from creating the mandated artifacts, or having to jump through the mandated “quality gates”, required by these teams.
  4. Help the teams that they collaborate with to become more agile.  The next step after giving an agile team an organizational pass it to recognize that this is an opportunity to experiment with improving other areas within your organization.  Help the enterprise architects to learn about agile and to try a few agile strategies themselves.  Similarly the data team can experiment with agile data management strategies and certainly your IT governance team can also take the opportunity to up their game as well.

How Do You Know That Your Productivity Actually Improved?

Although the chart above intuitively makes sense, how do you know that your productivity has actually increased?  To definitively answer this question you need to determine what productivity means to you, what the productivity level of the team currently is, and then continue to measure the level of productivity over time. This strategy tends to fall apart because few organizations know how they want to measure team productivity and fewer yet have actual measures in place. This of course is particularly vexing when senior management still requires you to prove that your productivity has increased as the result of your agile adoption efforts.  Luckily there are ways to measure the change in productivity even when you don’t know what the baseline productivity level currently is.  We’ll address this topic in a future blog.

Agile is About More Than Productivity Improvement

There are many benefits to agile, improving team productivity being just one of them. Potential benefits, some of which lead to greater productivity, include:

  • Improving the quality of the delivered solution
  • Improved stakeholder satisfaction
  • Greater adaptability to market changes
  • Increased team morale
  • Quicker time to market
  • Greater frequency of delivery
  • and many more
Posted by Scott Ambler on: June 08, 2017 11:24 AM | Permalink | Comments (0)

Why is it so hard to find qualified agile coaches?

Questioning peopleI 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: Certified Disciplined Agile Coaches (CDACs)
  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
  • Although we throw the term “software engineering” around a lot, there is no agreement around what it means or even if it’s an appropriate concept (the IEEE/ACM promotes one, but there are many others)
  • 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 for IT people 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

CoachCoaching 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 Agile Coaching Institute is a start for this although the program at International Coaching Federation (ICF) is far more 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.

Criteria for Effective Agile Coaches
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: Certified Disciplined Agile Coaches (CDACs)

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.  The following diagram summarizes our strategy for how practitioners must earn DA certifications.

Agile Practitioner CertificationsTo become a Certified Disciplined Agile Coach (CDAC) you need to have at least five years of experience in agile (which is verified by the Disciplined Agile Consortium (DAC)), plus evidence that you’ve already been sharing your skills and knowledge (we call this give back), plus you must be a Certified Disciplined Agile Practitioner (CDAP).  To become a CDAP you must have at least two years of proven agile experience (validated by DAC), have passed a comprehensive test of your agile knowledge, and already be a Certified Disciplined Agile Practitioner (CDA).  To be a CDA you must have passed a comprehensive test of your knowledge and skills.  So, this process of certification ensures that CDACs have comprehensive skills and knowledge in agile techniques, at least five years experiences in agile, and at least initial experience in coaching/teaching (the giveback component). Note: Not shown in the diagram above is Certified Disciplined Agile Instructor (CDAI), which you must be at least a CDAP and have proven ability to teach DA.

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 Certified Disciplined Agile Coach (CDAC) needs to have worked through a rigorous process to earn that qualification.  CDACs have proven knowledge, experience, and give back.  Why settle for less?

Related Reading

Posted by Scott Ambler on: April 30, 2017 11:36 AM | Permalink | Comments (0)
ADVERTISEMENTS

"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."

- Tom Robbins

ADVERTISEMENT

Sponsors