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
Daniel Gagnon
Valentin Mocanu
Joshua Barnes
Michael Richardson
Klaus Boedker
Kashmir Birk
Mike Griffiths

Recent Posts

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

PMI and Disciplined Agile at Agile20Reflect

The Disciplined Agile Foundation Layer

Disciplined Agile Foundation Layer

The Disciplined Agile (DA) tool kit is organized into four layers: Foundation, Disciplined DevOps, Value Streams, Disciplined Agile Enterprise (DAE).  This blog focuses on the Foundation layer, the purpose of which is to provide the underpinnings of the DA tool kit.  The foundation layer itself is organized into four distinct topics:

  1. The DA mindset
  2. Fundamental concepts
  3. People
  4. Choosing your WoW

 

The DA Mindset

The Disciplined Agile (DA) mindset is captured in the form of principles, promises, and guidelines. Disciplined agilists believe in the DA principles, so we promise to adopt these behaviours and follow these guidelines when doing so. There is a purpose for each aspect of the mindset:

  • Principles. The principles provide a philosophical foundation for business agility. They are based on both lean and flow concepts.
  • Promises. The promises are agreements that we make with our fellow teammates, our stakeholders, and other people within our organization whom we interact with. The promises define a collection of disciplined behaviours that enable us to collaborate effectively and professionally.
  • Guidelines. These guidelines help us to be more effective in our way of working (WoW) and in improving our WoW over time.

The Disciplined Agile Mindset

 

Fundamental Concepts

Disciplined Agile (DA) is a hybrid in that it adopts ideas and strategies from a wide range of sources. DA encompasses three categories of fundamental concepts:

  1. Agile. Agile is both a mindset and a skillset. As a mindset Agile is the manner in how you look at your environment; it is the desire to collaborate with and to learn from others; and it is the willingness to share your skills and knowledge with others.  As a skillset Agile varies based on the domain in which you operate.  For example, an agile skillset for a marketing professional may include experimental strategies such as minimum viable products (MVPs) and marketplace sensing strategies, whereas an agile skillset for a software professional may include test-driven development (TDD) and chaos engineering techniques. Agility is the ready ability to move with quick and easy grace to respond to changes in your operating environment.  
  2. Lean.  Lean produces value for customers quickly through a focus on reducing delays and eliminating waste which results in increased quality and lower cost. Lean philosophies and strategies infuse DA, and in fact much of the DA mindset reflects lean thinking. This includes ideas such as optimizing flow, making all work and workflow visible, keeping workloads within capacity, and attending to relationships throughout the value stream to name a few. 
  3. Serial. DA adopts great ideas from serial - often referred to as traditional, waterfall, or even predictive - ways of working (WoW). There are many strategies and concepts from the past which are critical to our success in the future, and DA chooses to leverage them where they make sense. For example, DA's project-oriented lifecycles have explicit, named phases which are clearly serial in nature. DA recognizes that inception efforts, sometimes called  project initiation or simply initiation activities, such as initial planning, initial scoping, and initial design can be critical to your success.  These efforts are very different than the construction/realization efforts that happen after this, and different yet again than the transition/delivery efforts that then follow, and different again than the operational efforts that bring actual realized value to your customers.

 

People

The people portion of the Foundation layer addresses two key aspects of agility:

  1. Roles (and responsibilities). The DA tool kit captures a wide range of roles that people may fill.  This includes common agile roles such as Team Lead/Senior Scrum Master, Product Owner, Architecture Owner, and others.  It also includes function-specific roles such as Program Manager, Financial Specialist, Governor, Security Engineer, Sales Manager, and many others.  All of these roles have associated responsibilities, and of course there are common rights and responsibilities that everyone has.
  2. Teams. Every team is unique and faces a unique situation.  As a result, DA supports several team structures which your teams can adopt and evolve to meet their needs.  There are suggested structures for small, medium, and large (program) teams.  There are team structures that support geographic distribution.  There are team structures that support learning teams such as communities of practice (COPs)/guilds and centres of excellence (CoEs), and structures that support common services teams.

 

Choosing Your WoW

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?

While working with organizations to help them to learn how to improve their WoW, we’ve developed a technique that we call guided continuous improvement (GCI). GCI extends the kaizen-based continuous improvement approach, where teams improve their WoW via small incremental changes, to use proven guidance to help teams identify techniques that are more likely to work in their context. This increases the percentage of successful experiments and thereby increases your overall rate of process improvement.

Posted by Scott Ambler on: July 29, 2020 12:06 PM | Permalink | Comments (6)

Lean Thinking Provides a Philosophical Foundation for Scaling Agile

Categories: Lean, mindset, scaling

Little ideas add up

Lean thinking is important for scaling agile in several ways:

  1. Lean provides an explanation for why many of the agile practices work.  For example, Agile Modeling’s practices of light weight, initial requirements envisioning followed by iteration modeling and just-in-time (JIT) model storming work because they defer commitment to the last most responsible moment.  These practices also help to eliminate waste because you’re only modeling what needs to be built at the point in time that it needs to be built.
  2. Lean offers insight into strategies for improving your software process.  Lean principles such as optimizing the whole and delivering quickly motivate you to look beyond your existing specialized processes to explore how everything fits together and to streamline it.  Identifying and understanding the sources of waste in your IT processes can motivate you to improve the way that you work and thereby eliminate the waste.  The lean principle of building quality in
  3. Lean thinking provides a philosophical foundation for scaling agile approaches.  No methodology, process, procedure, or framework is ever complete.  Nor can they be because you can always capture more detail for a wider range of situations.  Because of this incompleteness you need a collection of higher-level principles or philosophies to guide people when their process/procedure/… proves to be incomplete for the situation that they face.  Lean thinking has proven to be a very good source of such philosophies, as do other sources (Steven Covey’s principles come to mind, as does the work of Peter Senge).
  4. Lean provides techniques for identifying waste.  Value stream mapping, a technique common within the lean community whereby you model a process and then identify how much time is spent on value-added work versus wait time, helps calculate overall time efficiency of what you’re doing.  Value stream maps are a straightforward way to illuminate your IT processes, providing insight into where significant problems exist.  I’ve created value stream maps with several customers around the world where we analyzed their existing processes which some of their more traditional staff believed worked well only to discover they had efficiency ratings of 20-30%.  You can’t fix problems that you are blind to.
Posted by Scott Ambler on: July 10, 2016 09:19 AM | Permalink | Comments (0)

The Principles of Lean Software Development

Categories: Lean, Philosophies

Principles - canstockphoto18364473 small

In Implementing Lean Software Development, Mary and Tom Poppendieck show how the seven principles of lean manufacturing can be applied to optimize the whole IT value stream. These principles are:

  1. Eliminate waste. Lean thinking advocates regard any activity that does not directly add value to the finished product as waste. The three biggest sources of waste in software development are the addition of unrequired features, project churn and crossing organizational boundaries (particularly between stakeholders and development teams). To reduce waste it is critical that development teams be allowed to self organize and operate in a manner that reflects the work they’re trying to accomplish. Walker Royce argues that the primary benefit of modern iterative/agile techniques is the reduction of scrap and rework late in the lifecycle.
  2. Build in quality.  Your process should not allow defects to occur in the first place, but when this isn’t possible 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.  Inspecting after the fact, and queuing up defects to be fixed at some time in the future, isn’t as effective.  Agile practices which build quality into your process include test driven development (TDD) and non-solo development practices such as pair programming and modeling with others.
  3. Create knowledge.  Planning is useful, but learning is essential. You want to promote strategies, such as iterative development, that help teams discover what stakeholders really want and act on that knowledge. It’s also important for a team to regularly reflect on what they’re doing and then act to improve their approach.
  4. Defer commitment.  It’s not necessary to start software development by defining a complete specification, and in fact that appears to be a questionable strategy at best. You can support the business effectively through flexible architectures that are change tolerant and by scheduling irreversible decisions to the last possible moment. Frequently, deferring commitment to the last most responsible moment requires the ability to closely couple end-to-end business scenarios to capabilities developed in multiple applications by multiple projects.
  5. Deliver quickly.  It is possible to deliver high-quality systems quickly. By limiting the work of a team to its capacity, which is reflected by the team’s velocity (this is the number of “points” of functionality which a team delivers each iteration), you can establish a reliable and repeatable flow of work. An effective organization doesn’t demand teams do more than they are capable of, but instead asks them to self-organize and determine what they can accomplish. Constraining these teams to delivering potentially shippable solutions on a regular basis motivates them to stay focused on continuously adding value.
  6. Respect people. The Poppendiecks also observe that sustainable advantage is gained from engaged, thinking people. The implication is that you need a lean approach to IT governance that focuses on motivating and enabling IT teams—not on controlling them.
  7. Optimize the whole.  If you want to be effective at a solution you must look at the bigger picture. You need to understand the high-level business processes that individual projects support—processes that often cross multiple systems. You need to manage programs of interrelated systems so you can deliver a complete product to your stakeholders. Measurements should address how well you’re delivering business value, because that is the sole reason for your IT department.
Posted by Scott Ambler on: July 05, 2016 04:44 PM | Permalink | Comments (0)

The Lean Governance Mindset

Categories: governance, Lean, mindset

Mindset

The mindset required to govern IT in a lean or agile manner is very different than the traditional mindset. In this blog we review the key aspects of a lean governance mindset. These aspects are:

  1. Lead by example. People take their cues from their leadership teams. If your governance strategy is streamlined and light weight then whatever it governs will inevitably become streamlined and light weight. Conversely, an onerous and heavy governance strategy will lead to onerous and heavy strategies by those being governed.
  2. Be a servant leader. The primary function of governance people should be to prevent roadblocks, and if not to get rid of them as soon as they arise. You should strive to get teams the resources that they need and then get out of the way. Wait a minute, isn’t that the job of the Team Lead in Disciplined Agile (DA)? Yes, but who do you think that they work with to actually get that done?
  3. Motivation over management. IT professionals are intellectual workers, and intellectual workers generally don’t respond well to being told what to do. But they can be motivated, and once motivated will actively work on what they’ve been motivated to do. So motivate them to do the “right thing”. One way to do this is to communicate very clearly what your organization is trying to achieve. Another way to motivate people is to ask tough questions such as: What value is there in doing that? What can we do to increase value? How can we eliminate waste in what we’re doing? and What will we learn by doing that?
  4. Enablement over audit. Psychology shows that people, when given the choice, will usually take the easy path. This tells us that if we want people to do something, or to work in a given manner, then if we make it very easy to do so then they likely will. For example, if you want developers to follow common coding conventions then provide easy to understand and straightforward guidelines. Better yet, provide code analysis tools that they can include in the continuous integration (CI) tooling that provides feedback that they can act on. The traditional approach would be to rely on code inspections or code audits to ensure that conventions were being followed. This approach is not only onerous, and thus less likely to be followed, it has a long feedback cycle which means that any feedback resulting from the audit will be much more expensive to act on (on average) than the code analysis tool which has a very short feedback cycle. Yes, you may need to run the occasional audit, particularly when you’re working in a regulatory environment, but you should do so only as a last resort.
  5. Communicate clearly, honestly, and in a timely manner. Effective governors communicate what the priorities of your organization are and what is expected of people. It is crucial to set realistic expectations in an open, honest, consistent, and continuous manner.
  6. Streamline collaboration. Governors should help teams collaborate effectively with others. This not only helps them to achieve their goals but also supports enterprise awareness.
  7. Trust but verify. Agile is based on trust, but to ensure that the right thing is happening within your organization there needs to be verification of that. Governors can do this by monitoring teams via several strategies. These strategies include asking people what’s going on, automated metrics (via team dashboards), looking at information captured by information radiators, attending team demos, and as a last resort asking teams to produce status reports to address questions that can’t be answered via automated metrics.
  8. Focus on mitigating risk, not just reviewing documents. A primary goal of your governance strategy should be to mitigate risk. Sadly, many governance strategies have fallen into the bureaucratic trap of relying on documentation reviews to provide insight into what a team is doing. For example, your “architecture quality gate” might be based on the review and acceptance of an architecture model or document, the idea being that if some knowledgeable people assess the content of the document they will be able to determine whether the described architecture strategy will work. Unfortunately this isn’t the case. We’re sure you’ve seen several IT project teams who had a well-documented architecture, which was reviewed and signed off on, yet the technologies didn’t work well in practice, or perhaps they didn’t perform well, or perhaps they didn’t even integrate easily. The only thing that the review and acceptance of a document tells you is that a document was created, reviewed, and accepted.
  9. Learn continuously. Good governors learn as much as they can about what they’re governing so that they can make better decisions and can make effective suggestions to the people being governed.
  10. Consider both the long and short term. Governance must balance short-term needs with the long-term strategy of growing and enhancing your organization.
  11. Be a great host. People who have fun at work, who enjoy what they do, are much more productive than people who don’t. In this respect being an effective governor is like being a good host at a party – as host it’s your job to see that everyone has a good time and gets along well with each other, and to swiftly deal with any problems that arise.

Having a lean governance mindset, as described above, helps you to increase your effectiveness at governance. In the next blog we will describe what IT governance encompasses.

Posted by Scott Ambler on: May 14, 2016 04:05 PM | Permalink | Comments (0)
ADVERTISEMENTS

Where lipstick is concerned, the important thing is not color, but to accept God's final word on where your lips end.

- Jerry Seinfeld