Disciplined Agile

We are often asked what makes a Disciplined Agile (DA) coach effective.  The features to look for in a DA coach include:

1. People skills.  First and foremost, effective DA coaches need solid people skills.  They need to be prepared to work with a wide range of people coming from different backgrounds, with different learning preferences, and with different learning goals.  As a result DA coaches need to be empathetic, patient, respectful, and open-minded.
2. Experience.  Good coaches understands the situation that you face, and more importantly understands how to guide you to tailor your strategy.  Effective coaches have many many data points from their experiences over the years, and as such they can recognize patterns quickly and provide appropriate advice to those their are coaching.  We’ve seen people who are very good agile coaches for small, co-located teams get into serious trouble the first time they need to deal with scaling factors such as large team size, geographic distribution, or regulatory compliance.   We’ve also seen good development team coaches flounder when they first start to address, in a meaningful way, the Agile IT issues faced by organizations applying agile across their entire IT department.  This is one of the reasons why we suggest that Transformation coaches be Certified Disciplined Agile Coaches (CDACs) as they need significant experience and knowledge to be successful.  The implication is that when you’re hiring a coach, make sure they’ve worked in environments similar to yours otherwise you run the risk of paying for their learning experiences.
3. Pragmatism.  As Mark Lines astutely pointed out a few months ago, DA is pragmatic agile.  Effective DA coaches are willing and able to work closely with the people that they’re coaching, providing practical advice that they follow themselves. They also like to have real-time measures that reveal how their team(s) are doing, enabling them to make fact-based suggestions to help their teams.
4. Knowledge.  It’s reasonable to expect a DA coach to be very knowledgeable about DA and agile in general.  Development team coaches are at least Certified Disciplined Agile Practitioners (CDAPs) and better yet CDACs.  To earn a CDAP you need to have at least two years agile experience, clearly a bare minimum for someone in a coaching role, and be able to pass a challenging test which explores their understanding of the DA toolkit.  CDACs need to have five or more years of experience and must pass a board-level interview.  These are meaningful certifications that people must work for to earn, and are a clear indication that holders of such certification have the requisite DA knowledge.   Transformation coaches, who coach an organization’s executive team through the process of transitioning to agile, should be CDACs.
5. Skill.  Development team coaches must be skilled in fundamental agile techniques such as regression testing,  continuous integration (CI), iteration/sprint planning, look-ahead modelling and planning, requirements envisioning, and many more.  A good team coach should also be skilled in “advanced” agile techniques such as test-driven development (TDD), behaviour driven development (BDD), and continuous deployment.  Transformation coaches should be skilled in organizational change management as well as the fundamentals of IT-level activities such as enterprise architecture, data management, operations, portfolio management, and others.
6. Leadership.  In addition to solid people skills, good coaches often need good leadership skills too as they need to be adept at convincing people to follow their advice.  Team coaches will often be Team Leads, or at least be working closely with the Team Lead, to help lead the team in making the “hard decisions” required to successfully learn the agile mindset.
7. Flexibility.  A fundamental concept of the DA toolkit is that you need to tailor it to meet the needs that you face.  The implication is that DA coaches need to be agile to go beyond the advice in prescriptive methods such as Scrum or SAFe.  Instead of working from a prescriptive playbook, DA coaches will leverage DA’s goal-driven strategy to help guide teams make process-oriented and organization-oriented choices that are right for them. In short, just because someone has several years of Scrum coaching you can’t count on them having the background to be a good DA coach because they may only understand Scrum strategies and not the full range of agile and lean strategies supported by the DA toolkit.

When it comes to organizing large or geographically distributed agile teams many people will tell you that there are two strategies, taking what is called a component team approach or taking a feature team approach.  Many people will tell you to take a feature team approach over a component team approach, but the fact is that both strategies has advantages and disadvantages and neither is right for all situations.  Furthermore, those are the only two strategies as you will soon see, although to be fair they are the most common two.

This article explores the four basic strategies for organizing agile teams.  We compare and contrast these four strategies in Table 1 below, in accordance to the “it depends” philosophy of the Disciplined Agile Delivery (DAD) framework.  Our goal is to make it clear that you have choices when organizing agile teams, and that you should understand the trade-offs that you are making with each choice.  You will also find that you want to combine strategies, and in fact most large agile programs that we’ve seen do in fact do this.  The four strategies are:

1. Component teams. With this approach each sub-team is responsible for one or more subsystems or modules, something that can be difficult if some of your team works alone from home, to reduce the amount of information sharing and collaboration required between disparate teams.  Because component teams are effectively organized around your architecture you will need to invest sufficient time up front to identify that architecture.
2. Feature teams. A feature team is responsible for implementing a functional requirement, such as a user story or use case, from end-to-end.  This is often referred to as implementing a vertical slice of the solution.  Sometimes a given feature team will focus on the requirements for a single line of business (LoB), such as brokerage or life insurance within a financial institution, enabling them to gain expertise in that LoB. Other times a feature team will take on requirements specific to a given application or system within your organization.
3. Functional teams. Some large teams will be organized by development function – there is an architecture team, a development team, a testing team, a deployment team, and so on.  Each team focuses on their specialized function and hands off their work to other functional teams.
4. Internal open source teams. Sometimes a component or subsystem will be developed via an open source method, even though all of the work is private to your organization.  Developers from other teams voluntarily work on the component to evolve it over time.  When Scott was at IBM he saw this strategy work in practice for several important components reused within several IBM products.  For some detailed thoughts on strategy, read Reuse Through Internal Open Source.

Table 1. Comparing the team organization approaches.

I recently wrote a detailed article summarizing my thoughts about Geographically Distributed Agile Teams.  The article addresses a series of questions that I suspect you’ll find interesting:

1. What does it mean to be geographically distributed?
2. Are agile teams geographically distributed in practice?
3. How does geographic distribution relate to other scaling factors?
4. What are the potential benefits of geographic distribution?
5. What are the risks associated with geographic distribution?
6. How do we address those risks?
7. How do we organize a geographically distributed agile team?
8. How does geographic distribution affect tooling?
9. Is geographic distribution a good idea?
10. Where do we start?
11. What other resources exist?

I hope you enjoy the article.  Feedback is always welcome.

We recently posted a new page titled Tool Support for DAD which you may find interesting.

At the end of July I spoke at the Agile 2014 conference in Orlando about what it means to be an agile enterprise.  Part way through that presentation I spoke about the differences between producing potentially shippable software, one of the mantras of the Scrum community, and potentially consumable solutions as promoted by DAD.  To do this I walked people through what I call the glass of water analogy.  Here’s how it went:

I had a glass of drinking water.  I took a sip from the glass to verify that the water was clean and the right temperature for drinking.  The water was very refreshing and was something that I thought others would enjoy.  It was my opinion that this glass of water was potentially shippable.  I took another sip and then offered the water to the audience, there was over 200 people in the room, yet nobody was willing to drink from my glass.  Shocking! I even singled someone out and tried to bully him into drinking my water (oops, I mean I aggressively marketed the wonderfulness of the water to him).  Still, nobody wanted to drink the water.   I took another sip and verified that it was in fact still refreshing.  It was clear to me that my glass of water was potentially shippable.  I could very easily have walked over to anyone in the room and they could easily have drunk from the glass.  But everyone chose not to.  It was potentially shippable from my point of view, but from the point of view of every single audience member it wasn’t consumable.  In a venue where drinks are easily available, not a single person was willing to drink from my water glass (I assume due to a fear of catching my cooties).  Had the venue been different, perhaps a desert with no other sources of drinkable liquids,  someone might have been interested.

The point is that creating potentially shippable software isn’t sufficient.  It needs to be something that people actually want to use, to consume.  It must be a true solution that adds real value for them given their current situation.  Cootie-laden water isn’t attractive when other drinks are readily available.  Similarly, software that is difficult to use compared to other options, that isn’t well supported as other options, or that doesn’t enhance the way that people want to work isn’t going to be very attractive either.

Disciplined agilists focus on producing potentially consumable solutions.  High-quality software is clearly part of this, but that software needs to be usable and something that people want to use.  It needs to be supported with sufficient documentation.  It needs to be supported with adequate hardware.  It may even be part of an overall change to the business process and even organizational structure of the people using that software.  

“Potentially shippable software” is a wonderful slogan, but we need to do a lot better than that.