Disciplined Agile Applied

One of the seven principles behind the Disciplined Agile (DA) toolkit is Choice is Good. Let’s assume for a minute that your organization has multiple teams working in a range of situations, which in fact is the norm for all but the smallest of companies. How do you define a process that applies to each and every situation that covers the range of issues faced by each team? How do you keep it up to date as each team learns and evolves their approach? The answer is that you can’t, documenting such a process is exponentially expensive. But does that mean you need to inflict the same, prescriptive process on everyone? When you do that you’ll inflict process dissonance on your teams, decreasing their ability to be effective and increasing the chance that they invest resources in making it look as if they’re following the process when in reality they’re not. Or, does this mean that you just have a “process free-for-all” and tell all your teams to figure it out on their own? Although this can work it tends to be very expensive and time consuming in practice – even with coaching each team is forced to invent or discover the practices and strategies that have been around for years, sometimes decades. Luckily, the Disciplined Agile toolkit provides a better way.

Different contexts require different strategies – teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. This is why the DA toolkit presents people with choices through the application of process goal diagrams, see the figure below for an example of options for addressing changing stakeholder needs throughout solution delivery. The rounded rectangle indicates the name of the process goal, as in this case, or the process blade/area.  The square rectangles indicate process decision points, issues that you need to consider in your way of working (WoW).  The lists to the right of the process decision points are options, typically practices or strategies that your team may choose to adopt.  When there is an arrow beside the list that is an indication that the strategies towards the top of the list are generally more effective than the strategies towards the bottom of the list.  When a strategy is bolded it is an indication that it is a likely choice for a team that is new to agile, that is addressing a fairly straightforward problem, and that is near located (working on the same floor of a single building).  If that's not your situation then you may find you need to make other choices. Please read Disciplined Agilists Take a Goal-Driven Approach for more information on DA’s goal-driven strategy.

Figure. The goal diagram for Addressing Changing Stakeholder Needs.

The idea of goal diagrams is to make important decision points explicit, such as when to accept changes, and then present teams with their options and the tradeoffs surrounding those options. This enables teams to make better process choices given the situation that they face. To make these choices, teams need to know:what each option is, the tradeoffs associated with each one, and in what situations the option is and isn’t applicable. DA takes a similar, goal/choice-driven approach to IT process areas such as Data Management and Reuse Engineering as well as enterprise process areas such as Enterprise Architecture and People Management (often called Human Resources or Talent Management).

This choice-driven strategy is a middle way. At one extreme you have prescriptive methods, which have their place, such as Scrum and SAFe which tell you the one way to do things. Regardless of what the detractors of these methods will tell you these prescriptive strategies do in fact work quite well in some situations, and as long as you find yourself in that situation they’ll work well for you. However, if you’re not in the situation where a prescriptive method fits then it will likely do more harm than good. At the other extreme are experimental methods such as Spotify that tell you to experiment and learn as you go. This works well in practice but can be very expensive and time consuming and can lead to significant inconsistencies between teams which hampers your overall organizational process. Spotify had the luxury of evolving their process within the context of a product company, common architecture, no technical debt, and a culture that they could grow rather than change.  DA sits between these two extremes – by taking this process goal driven approach it provides process commonality between teams that is required at the organizational level yet provides teams with the flexibility required to tailor and evolve their internal processes to address the context of the situation that they face. Teams can choose from known strategies the likely options to then experiment with, increasing the chance that they find something that works for them in practice. At a minimum, it at least makes it clear that they have choices, that there is more than the one way described by the prescriptive methods.

There is a catchy phrase in the agile world called “fail fast” or better yet “learn fast.” As described earlier leadership should encourage experimentation early in the interest of learning and improving as quickly as possible. However, we would suggest that by referencing the proven strategies in Disciplined Agile you will make better choices for your context, speeding up the learning process and failing less.  We have developed a technique called Guided Continuous Improvement (GCI) that describes how to do this very thing.  I will blog about GCI in future postings and we will soon have PMI-certified workshops that teach GCI.

One of the seven principles behind Disciplined Agile (DA) is Pragmatism. People are often surprised when we suggest that mainstream methods such as Scrum and Extreme Programming (XP) are prescriptive. But they are indeed.  Scrum prescribes a daily stand-up meeting (Scrum) no longer than fifteen minutes to which all team members must attend, that teams must have a retrospective at the end of each iteration (Sprint), and that team size should not be more than nine people.  These are all great ideas, but they don't apply to all situations.  Similarly, Extreme Programming mandates pair programming (two people sharing one keyboard) and Test-Driven Development (TDD). 

We are not suggesting that prescription is a bad thing, we’re merely stating that it does exist.  Many agile purists are quite fanatical about following specific methods strictly.  In fact, we have met many who say that to “do agile right” you need to have 5-9 people in a room, with the business (Product Owner) present at all times.  The team should not be disturbed by people outside the team, and should be 100% dedicated to the project.  However, in many established enterprises such ideal conditions rarely exist.  The reality is that we have to deal with many suboptimal situations, such as distributed teams, large team sizes, outsourcing, multiple team coordination, and part-time availability of stakeholders.

The DA toolkit recognizes these realities and rather than saying “we can’t be agile” in these situations we instead say “let’s be as effective as we can be.” Instead of prescribing “best practices” DA instead provides strategies for maximizing the benefits of agile despite certain necessary compromises being made. As such, DA is pragmatic, not purist in its guidance – DA provides guardrails helping you to make better process choices, not strict rules that may not even be applicable given the context that you face.

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

One of the seven principles behind Disciplined Agile (DA) is Be Awesome.  Who doesn’t want to be awesome? Who doesn’t want to be part of an awesome team doing awesome things while working for an awesome organization? We all want these things. Recently Josh Kerievsky has popularized the concept that Modern Agile teams make people awesome, and of course it isn’t much of a leap that we want awesome teams and awesome organizations too. Similarly, in their work on Lean Software Development the Poppendiecks observe that sustainable advantage is gained from engaged, thinking people. Helping people to be awesome is important because, as Richard Branson of the Virgin Group says, “Take care of your employees and they’ll take care of your business.”

There are several things that you as an individual can do to be awesome:

• Act in such a way that you earn the respect and trust of your colleagues – be reliable, be honest, be open, and treat them with respect.
• Willingly collaborate with others. Share information with them when asked, even if it is a work in progress. Offer help when it’s needed and just as important reach out for help yourself.
• Be an active learner. Seek to master your craft, always being on the lookout for opportunities to experiment and learn. Go beyond your specialty and learn about the broader software process and business environment. By becoming a T-skilled “generalizing specialist” you will be able to better appreciate where others are coming from and thereby interact with them more effectively.

Awesome teams are built around motivated individuals who are given the environment and support required to fulfill their objectives. A 2015 study at Google found that successful teams provide psychological safety for team members, that team members are able to depend on one another, there is structure and clarity around roles and responsibilities, and people are doing work that is both meaningful and impactful to them. Awesome teams have a very good working relationship with their stakeholders, collaborating with them to ensure that what they do is what the stakeholders actually need. Finally, awesome teams are whole – they are cross functional, having the skills, resources, and authority required to be successful and team members themselves tend to be cross-functional generalizing specialists.

Awesome teams also choose to build quality in from the very beginning. Lean tells us that your process should not allow defects to occur in the first place, but when this isn’t possible (yet) you should work in such a way that you do a bit of work, validate it, fix any issues that you find, and then iterate. The Agile Manifesto is clear that continuous attention to technical excellence and good design enhances agility.

As a leader, you can enable your staff to be awesome individuals working on awesome teams through providing them with the authority and resources required for them to do their jobs, by building a safe culture and environment (see next principle), and by motivating them to excel. As Dan Pink points out, people are motivated by being provided with the autonomy to do their work, having opportunities to master their craft, and to do something that has purpose. What would you rather have, staff who are motivated or demotivated?

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

One of the seven principles behind Disciplined Agile (DA) is Delight Customers. For a value stream to succeed the delight of your customers must be your key priority. In 2001 the writers of the Agile Manifesto told us that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software," which is clearly a good start.  Disciplined agilists, however, prefer the lean philosophy that to succeed it isn’t sufficient to simply satisfy the customer but instead we must regularly delight them if we wish to keep them as a customer.

We delight our customers when our products and services surpass their needs and expectations. Consider the last time you checked into a hotel. If you’re lucky there was no line, your room was available, and there was nothing wrong with it when you got there. You were likely satisfied with the service but that’s about it. Now imagine that you were greeted by name by the concierge when you arrived, that your favorite snack was waiting for you in the room, and that you received a complimentary upgrade to a room with a magnificent view – all without asking. This would be more than satisfying and would very likely delight you. Although the upgrade won’t happen every time you check in, it’s a nice touch when it does and you’re likely to stick with that hotel chain because they treat you well.

Successful organizations offer great products and services that delight their customers. Systems design tells us to build with the customer in mind, to work with them closely, to build in small increments and then seek feedback, so that we better understand what will actually delight them. As disciplined agilists we embrace change because we know that our stakeholders will change their minds as they learn what they truly want as the solution evolves.

Based on the great comments and questions that I've received about this blog posting (thank you!) I thought I would clarify a few points:

1. There's a cost to delight customers. Delightful offerings (products or services) are usually more costly to provide and to develop.
2. There's a cost to not do this. If you don't delight your customers someone else will.  It's much less expensive to keep a good customer than it is to attract a new one.
3. Focus on return, not cost. Effective organizations know that when it comes to financial issues it's about the return on investment that you're able to generate, rather than the overall cost to do so.  X costs $1 and generates $1.10 in revenue.  Y costs $2 and generates $2.50 in revenue.  Z costs $3 and generates $2.60 in revenue.  Assuming all other issues (risk, morale, ...) are equal, which is the better offering for your organization?  
4. Know your customers. At the individual level we are delighted by different things.  Being greeted by first name at the hotel, or even being greeted at all, may be delightful for some people and spectacularly annoying for others.  As another DA principle advises, context counts.
5. You want to target your efforts. It's really about delighting the customers that you care about and do so in a way that they actually value.  Consider the hotel example.  It's probably more important to them to delight an existing "gold" customer in a manner that they value than it is to delight someone who is staying at this hotel for the first time.  It's likely more important for them to try to delight a customer who is "gold" at another chain, hoping to lure them to this chain, than someone who is not a frequent hotel user.  
6. You need to vary the way that you delight a customer. If you delight people the same way over and over, it sets their expectations highly. If the hotel described above was to provide that level of service to me every time I checked in that would be great, but it would soon stop delighting me because I would come to expect it.  

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

What does it mean to be disciplined? To be disciplined is to do the things that you know are good for you, things that usually require hard work and perseverance. It requires discipline to regularly delight your customers. It takes discipline for teams to become awesome. It requires discipline for leaders to ensure that their people have a safe environment to work in. It takes discipline to recognize that you need to tailor your approach for the context that you face, and to evolve your approach as the situation evolves. It takes discipline to recognize that you are part of a larger organization, that you should do what’s best for the enterprise and not just what’s convenient for you. It requires discipline to evolve and optimize your overall workflow, and it requires discipline to realize that you have many choices regarding how you work and organize yourselves, so you should choose accordingly.

The seven primary principles behind the Disciplined Agile (DA) toolkit are:

1. Delight Customers. We delight our customers when our products and services not only fulfill their needs and expectations but surpass them.
2. Be Awesome. Awesome teams are built around motivated individuals who are given the environment and support required to fulfill their objectives.
3. Pragmatism. Let’s be as effective as we can be, and that may mean we go beyond being just agile.
4. Context Counts. Every person, every team, and every organization is unique.  Let’s find and evolve an effective strategy given the situation we actually face.
5. Choice is Good. Different contexts require different strategies. Teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. Having process options to choose from, and understanding the trade-offs of those options, enables you to home in on better options sooner.
6. Optimize Flow. Your organization is a complex adaptive system (CAS) of interacting teams and groups that individually evolve continuously and affect each other as they do. To succeed you must ensure that these teams are well aligned, remained well aligned, and better yet improve their alignment over time.
7. Enterprise Awareness. When people are enterprise aware they are motivated to consider the overall needs of their organization, to ensure that what they’re doing contributes positively to the goals of the organization and not just to the sub-optimal goals of their team.

These principles are complementary to the values and principles captured by the Disciplined Agile Manifesto, an update to the Agile Manifesto for Software Development that extended it to reflect the realities faced by modern enterprises.  The seven principles above have evolved out of the DA Manifesto and have been influenced by both Joshua Kerievsky’s Modern Agile principles and Alistair Cockburn’s Heart of Agile.  

In future blog postings I will explore each value in greater detail.  Stay tuned!