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 | estimation | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Improvement | inception | Inception phase | Large Teams | layer | 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 | serial | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | velocity | 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
Kashmir Birk

Recent Posts

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

The Four Layers of the Disciplined Agile Tool Kit

The Disciplined Agile Foundation Layer

The Team Lead Role: Different Types of Teams Need Different Types of Leaders

Disciplined Agile is a Hybrid

#NoFrameworks: How We Can Take Agile Back

Categories: Process, Toolkit

#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)

Is it Disciplined Agile Delivery (DAD) or Disciplined Agile (DA)?

Categories: Scaling, Toolkit

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

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

The Scope of Disciplined Agile (DA)

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

Scope of Disciplined Agile

Let’s explore each aspect depicted in the diagram:

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

Some History

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

Posted by Scott Ambler on: April 18, 2017 05:52 AM | Permalink | Comments (0)
ADVERTISEMENTS

"He who asks is a fool for five minutes, but he who does not ask remains a fool forever."

- Chinese Proverb