Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

The Disciplined Agile Enterprise (DAE) Layer

Disciplined Agile (DA)'s Value Streams Layer

The Disciplined DevOps Layer

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

#NoFrameworks: How We Can Take Agile Back

Categories: Process, Tool kit

#NoFrameworks

At the XP2019 conference in Montreal I had the privilege of giving the opening keynote.  The title of my keynote was “#NoFrameworks: How We Can Take Agile Back” and if you click on the link you can access my slides on SlideShare.net.  My keynote worked through the following topics:

  1. A mea culpa where I walked through my work in method and frameworks over the past two decades.
  2. What is a framework?
  3. What problems do we have with process frameworks/methods?
  4. Why are frameworks so popular?
  5. Some industry stats on how effective frameworks are in practice
  6. What actually works in practice?
  7. How we can take agile back?

During my keynote Ankur Saini created a sketch note and as you can see below he’s been kind enough to share it with us.  This blog explores the key ideas captured in the sketch (click on it to enlarge).

XP2019 Keynote sketch

There are a collection of points about frameworks, most of which question the value of frameworks:

  1. Leadership often adopts a framework because others are doing it. I hate to say it, but we often see agile frameworks, in particular SAFe, get adopted simply because other organizations are doing it. There seems to be less concern about whether the framework is a good fit, or even if it solves a problem the organization actually has, compared with whether others have adopted it (so therefore it must be a good idea).  In short, adoption of the framework often does more harm than good.
  2. Developers like frameworks because of the easy certifications. What’s not to like about becoming a certified master after taking a two-day workshop, or a program consultant after a four day workshop? Back in the distant past (the 1980s) I had to go to school for four years just to get a job as a junior programmer.  But, if you adopt an agile method or framework, you can become certified in it in just a few days of training!  In short, the frameworks enable people to present themselves as more qualified than they actually are, and motivate them to think that they know more than they do, which more often than not leads to trouble later on.
  3. Vendors like frameworks because it’s easy to support a single way of working (WoW).  Most tool vendors like well-defined, popular methods/frameworks because it makes it clear to them what functionality they should implement.  Prescriptive frameworks are particularly attractive because the tool vendor only has to implement a single way of working (WoW), reducing their development effort.  Cha-ching!
  4. Consultants like frameworks because they’re easy to learn.  Prescriptive frameworks supported by certifications that you “earn” in just a few short days enable consultants with little experience in agile to present themselves are experts and even expensive coaches to the unwary and gullible.  Cha-ching!  And consulting organizations can swiftly build up an army of such consultants quickly in order to staff huge teams at their clients.  Cha-ching cha-ching!
  5. Frameworks put you in method prison.  As Ivar Jacobson warns us about, we quickly find ourselves in method prison with prescriptive agile methods and frameworks that give you a limited way of doing things.  You’re often told that they’re flexible and can be tailored to meet your needs, but then they leave that very hard work up to you. The problem with this is that when organizations hit the limits of what the framework addresses, and the knowledge of their “certified experts,” that they either become disillusioned with agile or they find themselves on the very expensive path of extending the framework on their own.
  6. Are frameworks right for you? I asked several questions to get people to realize the challenges surrounding frameworks.  These questions included: What if the rules (of the framework) don’t apply to your situation?  What if the situation changes?  What if the framework solves a problem that you don’t actually have? What if the framework solves the problem and you find yourself in a new situation? For methods/frameworks that tell you that you can tailor them, what do you do if you don’t know what the available options (practices/techniques) are?  What if you don’t know how to compare the options?
  7. Are you joining a cult? When I was putting the keynote together I went looking for possible definitions of frameworks.  I noticed that they were suspiciously close to the definition of a cult.
  8. Frameworks are not silver bullets. Regardless of the marketing promises, or more often than not the perceptions left by marketing promises, there are no easy answers to your process and culture-related problems.  It takes hard work to improve your WoW, you don’t just “install” a new method/framework and in a few short months you’re agile. In short, the purveyors of methods and frameworks often set very unrealistic expectations.
  9. There is no best practice that applies to all situations. Every practice is contextual in nature, there are no “best practices” that apply in all situations.  Similarly, many of the “bad practices” that agile purists rail against (but hey, it’s not a cult) do in fact make sense in some situations (yes, there are often better practices available).  Sadly, many people are of the mindset “just tell me the best practices I need to adopt” and the frameworks/methods cater to that very attitude.  People willing put themselves into method prison.
  10. Focus on the apex predators. A common question that we ask executives when we’re working with them to help adopt new WoW in their organizations is “Who keeps you up at night?  What organizations are you afraid of competing against?”  It’s been years since a banker, for example, has told us that they’re afraid of other banks.  We often hear that they’re afraid of having to compete against Amazon, Google, or fintechs.  They’re afraid of these organizations because they’re hyper-competitive “apex predators.”  We then ask them how these organizations became apex predators, whether the executive believes they adopted an “agile scaling” framework like SAFe, LeSS, or Nexus to do so.  When the executive says no, of course not, that’s when we can have an intelligent conversation about process improvement. In short, if the scary competitors, the apex predators, aren’t adopting these frameworks it should give you reason to pause.
  11. Learn and improve through experimentation. In case study after case study after case study you learn that apex predators, the hyper competitive organizations that everyone respects and fears became so through continuous process improvement via small changes.  This is often called a kaizen loop.  You can speed up process improvement via a technique we call guided continuous improvement (GCI). Doesn’t it make more sense to act in a similar way that the apex predators act?
  12. Improvement is a journey, not a project. An important lesson that we can take from the apex predators is that they all have learned that process improvement is a long-term journey, one that never ends.  Many of them may have started this journey with an improvement project, but the successful ones all learned that this was only just a good start.
  13. You can only go to war with the army that you have.  You have likely staffed up your organization in a manner that reflects “the old rules” or your old way of working.  Part of improving your way of working (WoW) is investing in your staff to help them gain a new mindset and new skills. You need to help turn the people that you have into the people that you need.
  14. No need for reinventing the wheel. Although every person, every team, and every organization is unique that doesn’t mean that you need to develop your own WoW from scratch.  There are thousands of great techniques out there that have been implemented by thousands (if not more) of teams around the world. You can also learn and apply these techniques too, combining them in a unique manner to address your unique situation.  Yes, you may stumble onto a completely new technique at some point.  Great, please share that with us.  But 99.99% of the time you’ll be following techniques that others have followed before you. Have the humility to recognize this and actively choose to learn from the experiences of others rather than take the long and expensive path of figuring out everything on your own. The DA toolkit can help with this.

To summarize, there are many very good reasons to question the value of “agile scaling frameworks.”  We can do better.  We must do better.

XP2019 Keynote

As you can see in the picture above I made several suggestions for taking agile back:

  1. Respect yourself. The first step to addressing the meaningless certifications within the agile community is for people to push back against them. If you’re going to get certified in something then make sure that it’s a certification that you earn, not buy. It takes years to become proficient at something, not days of training.
  2. Go back to fundamentals. A fundamental concept from the early days of agile was that we would work to learn and improve over time.  This is what the lean strategy of kaizen loops are all about and certainly what GCI is all about.
  3. Be humble. The problems and challenges that you face today have been solved by many people who have come before you.  We can choose to learn from these people, to adopt and extend their strategies.
  4. Be agnostic. We can learn a lot from the various frameworks and methods (and other sources of information) that are out there. Treat them all with respect, and take what you can from each. Spend a bit of time with the Disciplined Agile (DA) toolkit and you’ll quickly discover that we’ve already done a lot of that hard work for you.
  5. #NoBestPractices. As I pointed out above, all practices are contextual in nature – they have advantages, they have disadvantages, they work well in some situations and poorly in others.  Our latest book, Choose Your WoW!, puts hundreds of agile and lean techniques into context, enabling you to identify strategies that are likely to work for you in the context that you face.
  6. Start where you are. Whatever you’re doing today – be it following a traditional approach, or a Scrum-based one, or one based on SAFe, or something else – that’s where you’re starting from.  Adopt GCI to begin improving from base, and you’ll soon find that you’re working your way out of method prison to a much better future.
  7. Observe, think, experiment. We need to observe what situation we’re in, think critically about what we face and about how we can improve, and then experiment with new WoW to see what works for us in our context.
  8. Optimize the whole. We need to get better at looking at the bigger picture.  For developers we need to look beyond programming to DevOps, to IT, and to the business as a whole.  For business people, because everyone organization is a software organization now, we need to invest time to understand how IT works. We need to streamline at least our overall value stream that we’re part of and better yet our organization as a whole.

The message that I left the conference attendees was this: Start where you are, do the best that you can in the situation that you find yourself in, and always strive to learn and get better. Becoming agile doesn’t have to be hard.

Posted by Scott Ambler on: May 28, 2019 01:40 PM | Permalink | Comments (0)

Choosing Your Initial Way of Working (WoW)

Small number of choices

A fundamental philosophy of agile is that teams should be allowed to own their process, to choose their way of working (WoW). In Disciplined Agile (DA) we take it one step further with the idea that teams should not only be allowed to choose their WoW, they should be supported and enabled in doing so.  In other words, let’s help teams to be awesome.

Figure 1 depicts the workflow for how a team can choose and then evolve their WoW. The workflow shows four key activities that a team will iteratively work through as they need. In this blog we focus on initially choosing your team’s WoW.

Figure 1. The workflow for choosing and evolving your WoW (click to enlarge).

Tailoring and Evolving Your WoW

When adopting your initial WoW, the first thing to do is to identify whether you team is allowed to choose its WoW or whether one has been chosen for them. Let’s start by exploring how you would proceed if you’re allowed to choose your own WoW.

Tailoring Your Initial WoW

When a team is allowed to choose its own WoW the first step is to select the appropriate lifecycle given the situation faced by the team. Lifecycles, in some ways, are “methods” in that they show the high-level workflow for a team. They are the glue that combines detailed techniques/practices into a coherent whole (more on this below). Disciplined Agile Delivery (DAD) supports several lifecycles:

  1. Agile. A Scrum-based project lifecycle.
  2. Lean. A Kanban-based project lifecycle.
  3. Continuous Delivery: Agile. A Scrum-based lifecycle for long-standing product teams.
  4. Continuous Delivery: Lean. A Kanban-based lifecycle for long-standing product teams.
  5. Exploratory. An experimentation-based lifecycle, based on Lean Startup, for exploring marketplace needs.
  6. Program. A lifecycle for a large “team of teams.”

Although the focus of DA is on agile and lean ways of working, DA recognizes that in some cases you may still decide to adopt a waterfall/serial lifecycle. DA doesn’t explicitly support waterfall, but as you can see in Figure 2 we do recognize that in very low-risk situations a traditional approach makes sense.

Figure 2. A flowchart summarizing how to choose a lifecycle (click to enlarge).

Selecting an agile lifecycle

Your lifecycle will of course evolve, either incrementally via normal evolution of your WoW or because your team explicitly decides to adopt a different one (once they’ve learned more about themselves as a team).

Once your team has chosen an initial lifecycle, the next is to select the detailed techniques that you’re going to follow as a team.  This is typically done as a series of process tailoring workshops where the team works through the appropriate goal diagrams to identify how they want to work together.  Figure 3 depicts the goal diagram for Secure Funding, you can see how it walks you through the decision points that you need to consider and potential techniques for addressing those decision points. Don’t worry, if you’re not familiar with all of the options they are described in the book Choose Your WoW!, with a description and the trade-offs associated with each technique summarized in tables. Knowing your options, and the trade-offs associated with them, enables your team to make better process decisions (which in turn leads to better process outcomes). This is something we call guided continuous improvement.

Figure 3. The Secure Funding process goal (click to enlarge).

Secure Funding process goal

In theory it’s possible to do a single “big bang” process tailoring workshop when a team is in initially formed, but we’ve found that leads to process bloat because the team has to guess at too many things all at once.  Unless you’re in a regulatory environment requiring defined process descriptions up front, it’s usually better to tailor your WoW in stages on an as-needed basis.

Adopt Existing Method or Framework

In some organizations teams are still not allowed to choose their WoW.  This may happen for several reasons:

  • The organization is new to agile.
  • Your organizational leadership wants every team to follow the same process (this is a spectacularly bad idea because context counts). This is often because they don’t understand that you can have a consistent governance process without inflicting the same process on all the teams.
  • You’ve hired coaches that only know one method or framework.
  • Leadership still has a command-and-control culture or they don’t trust your team to do this (either because you don’t have the experience required on your team or because you’re not using something like the DA toolkit yet).
  • You’re in a regulatory environment (e.g. medical device development) and don’t realize that you can choose and evolve your WoW in any way that you like, as long as you remain compliant and document what you do (yes, that’s annoying).

The problem with forcing a team to follow an existing method or framework, no matter how popular it is, is that it rarely fits the situation faced by the team. It might be a great method, but it’s the wrong one for the team – context counts, every team is unique and faces a unique situation, so should be allowed to choose and evolve their own WoW to enable them to be as effective as they can be. Think of it like this: If a team is competent enough to build a solution for their stakeholders, surely they must also be competent enough (perhaps given a bit of help) to choose their own WoW?

Regardless of whether you were allowed to choose your initial WoW or had one forced upon your team, this is only a start. Your team will still want to evolve your WoW as you learn and as your situation evolves. More on this in our next blog.

MORE INFORMATION


For more information about how your agile team can choose and evolve its way of work, we recommend our book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. If you want to succeed at enterprise agile you need choices, not prescriptions.

Posted by Scott Ambler on: February 06, 2019 08:19 AM | Permalink | Comments (0)

Continuous Improvement Through Experimentation

Run an experiment

A fundamental philosophy of agile is that teams should own their own process, or as we like to say in Disciplined Agile (DA) teams should choose their way of working (WoW).  Of course this is easier said than done in practice. The challenge is that every team is unique and faces a unique situation – in other words, context counts. Furthermore, there are no “best practices,” rather, every practice has tradeoffs and works well in some situations and poorly in others. Worse yet, you really don’t know how well a technique will work for you until you actually try it out in your environment.  Given all of this, how can a team choose its WoW?

Since the 1980s the lean community has shown that an effective way to evolve your process is to do so as a series of small incremental improvements, a strategy called kaizen.  Numerous organizations have taken this approach over the years, and virtually every single DevOps success story is based on a multi-year kaizen-based continuous improvement strategy. Figure 1 depicts the workflow of implementing a single improvement, with Deming’s Plan-Do-Study-Act (PDSA) loop on the right-hand side to indicate the iterative nature of the overall process.

Figure 1. Running an experiment to evolve your WoW (click to enlarge).

Experiment to evolve your WoW

Let’s explore each step one at a time:

  1. Plan: Identify a potential improvement. The team identifies a technique, either a practice or strategy, that they believe will work for them. This may be something someone on the team has done before, something they’ve read about, or even an idea that they’ve identified on their own.  An important consideration is to try a technique where it is “safe to fail” at it – you shouldn’t be putting your team at risk by experimenting with a new WoW.  If an experiment is deemed to risky to try, attempt to  break it down into a series of smaller experiments that are less risky. It is also critical to identify the criteria against which you’re going to assess the effectiveness of the technique.  Ideally most of the criteria is quantifiable in nature, although don’t ignore qualitative measures too.
  2. Do: Try out the new WoW (experiment). The team needs to see how well the technique works for them in their environment.  Do they have the skills to perform the technique? How well does it work given their technology platform?  How well does it work given their organization and team culture? The team needs to give the experiment sufficient time to determine how well it works in practice. This could several anywhere from several days to several months, although in most cases several weeks is sufficient.
  3. Study: Assess effectiveness. After you’ve run the experiment you should assess how well it worked for you. This assessment should be against the criteria that you agreed to at the beginning.
  4. Act: Adopt or abandon the new WoW.  Sometimes you’ll find that a new technique works incredibly well for you, and other times you’ll experience the other extreme and discover that a technique is an abysmal failure for you.  But in most cases there will be some aspects of the technique that work well for you and other aspects that do not (an indication that maybe you need to consider running a new experiment to identify a solution). Our advice is to adopt what works well for you and to abandon or better yet improve upon what doesn’t.
  5. Act: Share learnings with others. DA teams are enterprise aware, recognizing that they are only one of many teams within your organization. So, when a team learns something about a technique the implication is that they should share it with others.  Strategies for doing so are addressed by the Evolve WoW process goal.

Figure 2 shows how your team’s effectiveness improves over time with a continuous improvement approach.  When you experiment with a new technique and it works out well for your team then your team effectiveness improves.  When an experiment “fails” your team effectiveness dips for a bit – the technique didn’t work well in your situation – but then you end the experiment and go back to your previous way of working (your team’s level of effectiveness goes back to where it was).

Figure 2. Experiment to evolve your WoW (click to enlarge).

Experiment to evolve WoW

When you keep at it, when you adopt a kaizen mindset, your team effectiveness increases over time as we see in Figure 3. The figure also shows that when you first adopt a continuous improvement strategy that your team effectiveness drops at first because you’re learning how to follow the continuous improvement process of Figure 1.  In many ways you begin this improvement journey by experimenting with this experimentation-based strategy.

Figure 3. Continuous improvement over time (click to enlarge).

Continuous improvement curve

Some organizations struggle with the idea of experimentation, likely because they still believe in the idea of “best practices” and often because they’re looking for an easy answer. They’re afraid to experiment because they might “fail,” not realizing that a failed experiment teaches you what doesn’t work for your team given your current situation. Running small, “safe to fail” experiments is absolutely critical for improving your WoW.

Where this blog overviewed the strategy of Continuous Improvement, in the next blog in this series we will see how better decisions lead to better outcomes via Guided Continuous Improvement.  Stay tuned!

More Information

For more information about choosing and evolving your WoW, we humbly suggest that you consider reading our book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. If you want to succeed at enterprise agile you need choices, not prescriptions.

Posted by Scott Ambler on: January 22, 2019 11:19 AM | Permalink | Comments (0)

Disciplined Agile and SEMAT

Categories: Process

Collaboration

I’m happy to announce that the Disciplined Agile Consortium (DAC) is now working with SEMAT. SEMAT, Software Engineering Method and Theory, is an international community of people, companies, and universities.  Led by Ivar Jacobson, SEMAT is working together to create a common ground, or kernel, for software engineering.  As you may know I am one of the original signatories who first indicated their support for the SEMAT effort and am currently a member of the SEMAT advisory board.

So why are we working with SEMAT?  We hope to gain several benefits:

  1. Share DA concepts more widely.  We intend to work together to essentialize some of the key concepts that are unique within the Disciplined Agile (DA) toolkit.  This will help to get our leading-edge material into the hands of more people.
  2. Leverage essentialized practices.  The SEMAT community has already captured, what they refer to as essentialization of, a wide variety of great practices such as TDD, continuous integration, coordination meetings, and so on.  Our approach in DA is to put such practices into context but not to go into detail describing them (instead we reference existing descriptions).  So, SEMAT provides DA with a great source of existing material to reference.
  3. Collaborate with the SEMAT community.  There are many practitioners, trainers, and researchers within the SEMAT community and it’s always a great idea to work with smart people!
  4. Enable our customers.  A big advantage with SEMAT is that they’ve published, and continue to publish, a lot of great process material.  This is exactly the type of material that organizations need to support the learning activities of their staff as well as their own process definition efforts.

Of course it is still early days and there is a lot to do.  Please stay tuned here for further updates!

Recommended Reading

Posted by Scott Ambler on: December 13, 2017 06:43 PM | Permalink | Comments (0)

Process Tailoring Workshops Help Increase Agile Team Productivity

Tailor

I recently wrote a detailed article about process tailoring workshops.  In a process tailoring workshop a coach or team lead walks the team through important aspects of the delivery process and the team discusses how they’re going to work together. This typically includes choosing a lifecycle, walking through the process goals one at a time and addressing the decision points of each one, and discussing roles and responsibilities.

There are several reasons why you want to tailor your team’s process:

  1. Every team is unique and faces a unique situation.
  2. You want to have a common vision as to how you’re going to work together.
  3. You want to streamline how you work together.
  4. You may actually need to document your process.

The article covers the following topics in detail:

  1. Why process tailoring?
  2. When do you run process tailoring workshops?
  3. The risks associated with process tailoring workshops
  4. Planning a process tailoring workshop
  5. What should you tailor?
  6. Running a process tailoring workshop
  7. Documenting the results

I hope you find it useful.

 

Posted by Scott Ambler on: October 12, 2016 05:25 PM | Permalink | Comments (0)
ADVERTISEMENTS

"I only hope that we never lose sight of one thing - that it was all started by a mouse."

- Walt Disney

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events