Disciplined Agile

The Disciplined Agile (DA) tool kit is organized into four layers, overviewed in Figure 1.  These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE).  This blog focuses on the Disciplined DevOps layer.

Figure 1. The layers of the DA tool kit.

How is "Disciplined DevOps" different from normal/mainstream DevOps? Mainstream DevOps is the streamlining of software development, information technology (IT) operations, and support.  This strategy is often depicted as an infinite loop as you see in Figure 2.  Disciplined DevOps is an enterprise-ready approach that extends mainstream DevOps to include critical activities around security, data management, release management, and business operations.  The high-level workflow for Disciplined DevOps is depicted in Figure 3. 

Figure 2. The classic DevOps workflow.

Figure 3. The workflow of Disciplined DevOps.

Let's explore the components of Disciplined DevOps.  The hexes in Figure 3 represent process blades, sometimes called process areas. A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner.  Process blades also address functional roles specific to that domain as well as extensions to the DA mindset specific to that domain. The process blades of Disciplined DevOps are:

1. Disciplined Agile Delivery (DAD)
2. Security
3. Data Management
4. Release Management
5. Support
6. IT Operations
7. Business Operations (from the Value Streams layer)

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) is a people-first, learning-oriented hybrid approach to solution delivery. DAD teams focus on the creation of a new, or evolution of an existing, consumable solution for their customers.  A solution may include any combination of software, physical assets (e.g. hardware), documentation, changes to the supported business process, and changes to the organizational structure(s) of the people involved. A solution is consumable when it is usable, desirable, and functional. DAD enables a flexible way of working (WoW), supporting several lifecycles in a manner that is tactically scalable.

Security

The Security process blade focuses on how to protect your organization from both information/virtual and physical threats. This includes procedures for security governance, identity and access management, security policy management, incident response, and vulnerability management. As you would expect these policies will affect your organization’s strategies around change management, disaster recovery and business continuity, solution delivery, and vendor management. For security to be effective it has to be a fundamental aspect of your organizational culture.

Data Management

Data management is the development, execution and supervision of plans, policies, programs and practices that control, protect, deliver and enhance the value of data and information assets. DA promotes a pragmatic, streamlined approach to data management that fits into the rest of your organizational processes – we need to optimize the entire workflow, not sub-optimize our data management strategy. Disciplined agile data management does this in an evolutionary and collaborative manner, via concrete data management strategies that provide the right data at the right time to the right people.

Release Management

The release management process blade encompasses planning, coordinating, and verifying the deployment of solutions into production. Release management requires collaboration by the team(s) producing the solutions and the people responsible for your organization’s operational environment(s). In the case of organizations with a “you build it, you run it” DevOps mindset these people may be one in the same, although even in these situations you will often find a group of people responsible for governing the overall release management effort. In a true DevOps environment release management is fully automated for the intangible aspects (e.g. software and supporting documentation), and perhaps even some physical aspects, of your solution.

Support

Support focuses on helping customers/end users to work with the solutions produced by your delivery teams. Ideally your solutions should be designed so well that people don’t need anyone to help them but unfortunately it doesn’t always work out that way. So in many ways your support strategy is your “last line of defense” in your efforts to Delight Customers. Support goes by many names, including help desk, customer support, and customer care.

IT Operations

The primary aim of IT operations is to run a trustworthy IT ecosystem. From the point of view of your customers, you want to do such a good job that they don’t even notice IT. For older organizations this can be a challenge due to the existence of hundreds, if not thousands, of legacy systems that have been deployed over the decades. You may face daunting technical debt in these systems – poor quality data, overly complex or poorly written source code, systems with inadequate automated regression tests (if any), different versions of the same system, several systems offering similar functionality, numerous technology platforms, systems and technologies for which you have insufficient expertise, and more.

Business Operations

Business operations is one of the process blades of the value stream layer, although as you see in Figure 3 it is a critical component of the Disciplined DevOps workflow. Business operations focuses on the activities required to provide services to customers and to support your products. The implementation of business operations will vary by value stream, in a bank retail account services is implemented in a very different manner than brokerage services for example. Business operations includes help desk and support services (integrated in with IT support where appropriate) as well as any technical sales support activities such as training, product installation, and product customization. As you can imagine close collaboration with both your Sales and Marketing efforts is required to successfully Delight Customers.

Why Energy Enhancement is Important

“Your energy introduces you before you even speak” – I strongly believe in this famous quote and I am writing this article to enhance the positive energy level of every agile team, irrespective of their agile maturity level and experience.

If your Enterprise is not very mature in Disciplined Agile (DA) implementation, then you need to work with a CDAC to increase this maturity. I’m not focusing on those aspects of DA implementation in this article. You can get that knowledge from the DA website, blog, any CDAC or many great books written by Scott Ambler and Mark Lines.

I’m a certified Reiki Master Teacher and Disciplined Agile Coach & Instructor (CDAC & CDAI), who has been coaching and training agile teams, plus successfully healing people (in person or located thousands of miles away) by my Reiki knowledge. I’ve identified some basic Reiki practices which every agile practitioner can follow to increase their own positive energy level.

No prior Reiki or Energy Healing knowledge is required to follow these time-tested practices and you can even measure the increase in this positive energy by Pendulum Dowsing, if you are interested in collecting the evidence.

Background of Energy Healing and Reiki

With the advancements of quantum physics, evidence supporting the concept that matter is made up of layers of energy came to light. For centuries, indigenous cultures have been positively influencing the body’s health by working with its energy fields, and many traditions around the world speak about how it can be used in medical practices.

It was first observed by the eastern healers who identified seven Chakras and twelve major Meridians, or pathways of energy, in the body. They enhance the flow of energy to improve the health of the physical body. This is called Energy Healing.

The word Reiki is made of two Japanese words – “Rei” which means “Universal” and “Ki” which is “Life Force Energy”. Reiki flows through all living things. It utilizes the Ki to strengthen and help others using a lot of hand techniques and specific symbols which channel the energy of the universe to heal the body, mind and spirit.

With this background information, let’s explore some simple practices to enhance the positive Energy Level of your agile teams:

Meditation on Five Reiki Principles (10-15 Minutes Daily)

The following five Reiki principles are guidelines that everyone can live by, to promote a healthy, loving way of living.

1. Just for today, I will let go of worry

Worry causes stress which is a major issue in our daily lives. So, for a day try to stop worrying. It will make your life peaceful which in turn, will also bring peace to others. Lowering down stress will also enhance your physical health. Just for today trust in the universal life force and it will help you in fixing your problems!

2. Just for today, I will let go of anger

If a typical morning for you involves getting bug reports from the testers or high priority production tickets from the users, you probably default to anger. Why not just take a deep breath, relax and let it go? What will you achieve by remaining angry and increasing your own blood pressure? Nothing. All that you’ll end up with is an elevated heart rate (and more stress!) which is not good for your well-being.

3. Just for today, I will be grateful

We are always asking for more and only seeing what we don’t have. Let’s try for one day to be grateful for what we do have — like a job, a car, a roof over your head, good health, a family and your DA team that supports you. If you are grateful for what you have, you will attract more good. The law of attraction states that like attracts like and lack attracts lack, so stay positive and be grateful for what you have.

4. Just for today, I will do my work honestly

Doing your work honestly brings more purpose and meaning into your life. When you do your work honestly and with purpose, at the end of the day you’ll feel good about yourself and more fulfilled about your work. Just remember the following quote of quality guru Dr. W. Edwards Deming – “Quality is pride of workmanship.”

5. Just for today, I will be kind to every living thing

What you give out, you receive back multifold. Be nice, loving and caring to everyone, even if it’s not your favorite person in the world. We all deserve love and kindness. At the end of the day we will feel better about ourselves for bringing some light and love into someone else’s day, even if it’s just for a moment.

Please note, all these principles start with “Just for today” phrase because our life is agile and every new day can be treated as a new iteration. You don’t need to plan your whole life today in Waterfall style. Just meditate on these principles and live one iteration (day) at a time. You will be much happier at the end of the day, I promise.

Forgiveness Prayer (10-15 Minutes in Every Retrospective Meeting)

Every team can spend 10-15 minutes in every Retrospective meeting to chant and meditate on the following forgiveness prayer:

• I am a divine soul.
• I invoke all powers within.
• All including myself, please forgive me and all connected to me, for creating any negative energy, anytime & in any life, knowingly or unknowingly.
• I forgive & seek divine forgiveness for all including myself, that have anytime & in any life, created any negative energy, for me & all connected to me, knowingly or unknowingly.
• I am perpetually Healed, Protected & Guided.
• I willingly forgive, forget and heal to effortlessly give and receive love only.
• I am so happy and grateful now.
• Every day in every way I am getting better and better.

Affirmation Slips (10-15 Minutes in Every Iteration Planning Meeting or as Needed)

An affirmation is a simple, positive phrase that is meant to change our habit, belief, behavior, approach, emotion, feeling or opinion. For many people, it’s a great tool of healing and improving life. After all, it’s a tool of working with your inner self.

How to make affirmation slips? Keep it as simple as possible. No need to be formal and go for fancy words or big-big affirmations. You can note down this wish on a piece of paper in clear words or use any simple affirmation related to your wish.

Hold this slip between your palms and meditate for 5-10 minutes with the intention to manifest it for your highest good.

To understand and explain affirmations better, here are two simple examples.

I, YOUR NAME, write perfect code and delight our customers!

I, YOUR NAME, catch every bug in testing and enhance the reliability of our software!

Using this affirmation properly will establish a new opinion in your mind. And because our opinions create our reality (have you read/watched The Secret?), then with a bit of healing, you will be able to do your job perfectly and with pleasure.

How to write affirmations? Well, there are few “rules” and some “guidelines”. First, the affirmation must be a positive phrase. So don’t use “no”, “never”, “not” and things like that. Always try to make sure that your affirmation sounds positive. Next, write affirmations for yourself, not for others.

These are the basics of writing affirmation. You can also listen to a recorded affirmation or recite the affirmation, because it works, as well.

My experiments with various DA teams have convinced me that these Energy Healing practices will work for your DA team as well. Even if you are not sure about the outcome or don’t know how to measure this enhanced positive energy by a Pendulum Dowser, I suggest you run it as an experiment for 2-3 iterations and observe the difference.

Do share your experiences with me after conducting this experiment.

May the force be with you!

– Written by Dr. Sanjay Saxena, Ph.D., CDAC, CDAI, SPC4, PgMP, Reiki Master Teacher ([email protected])

One of the key philosophies of the Disciplined Agile (DA) toolkit is that it presents software development teams with choices and guides them through making the right choices given the situation they face.  In other words, it helps them to truly own their process.  Part of doing so is to choose the software delivery lifecycle (SDLC) that is the best fit for their context.  In this blog posting we overview the DAD Exploratory lifecycle which is based in part on Lean Startup strategies.

This lifecycle can be applied in two ways:

1. As a replacement of the Inception phase of other lifecycles.  In the Inception phase we invest a short yet sufficient amount of time and effort to validate that the initiative being considered makes sense and to gain agreement on the stakeholders’ vision.  In a situation where the actual need and value of what is being proposed is in question this approach is a very good way to determine the true market need before scaling up the initiative and moving into the Construction phase.
2. As the implementation approach in the Construction phase.  After applying the Exploratory approach to validate your vision, a decision needs to be made regarding which of the four DAD lifecycles to apply as we move into Construction. For instance, you may choose to use DAD’s Scrum-based basic agile lifecycle if there is sufficient confidence from the learnings in the Inception phase regarding the viability of the vision.  However, if there remains some uncertainty regarding the feature set to be delivered it may make more sense to continue using the Exploratory lifecycle to build out the product in Construction.

The following diagram overviews the DAD Exploratory lifecycle.  This lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.  As a result they need to quickly explore what the market wants via a series of quick learning experiments.

Now let’s describe how the Exploratory lifecycle works.  There are six activities to this lifecycle:

1. Envision.  Your team will explore the idea and identify a potential implementation strategy for implementing it.  This could be as simple as getting a few people together in a room to model storm both the business vision and your technical options on whiteboard and paper.  You want to do just enough thinking to identify a viable hypothesis for what your customers actually want.  This hypothesis needs to be testable, which implies that you need to identify how you are going to measure the effectiveness of the new functionality that you produce.
2. Build a little.  Your team should invest just enough effort to build a solution that tests the hypothesis.  In lean parlance you want to build what’s known as a minimally viable product (MVP).  The amount of effort will vary, from several days to several weeks – your goal is to make something available very quickly so that you can test your hypothesis.
3. Deploy.  Once your current solution is ready it is deployed into an environment where you can test your hypothesis. This deployment may be to a subset of your customers, in many ways what used to be called an “alpha” or “beta” release, so that you can determine whether the solution is of interest to them.
4. Observe & measure.  Once the solution is available in production you want to determine what aspects of it, if any, are of interest to your user base.  To do this you will need to instrument your solution so that it logs data regarding important events within it.  For example, you may decide to record when a screen/page is accessed, when a sale occurs, when certain business functions are invoked, and so on.  The idea is that you want to understand which functionality end users find useful, which functionality leads to customer retention, which functionality leads to greater sales, … whatever is important to you.  Generation of this data enables you to monitor, to observe and measure, how well the new functionality is received by your user base.  This in turn allows you to make a fact-based go-forward decision.  If the functionality is well received then you may choose to continue with the existing strategy and add more functionality.  Or your strategy may be so successful that you decide that you’re ready to productize the development of this solution. If the functionality wasn’t well received your team might choose to pivot and continue in another direction or even give up completely.
5. Cancel.  Sometimes you discover that the product idea isn’t going to work out after all.  In fact, this is particularly common in research and development (R&D) environments as well as start ups.  The advantage is that if an idea is going to fail, then it is better that you learn that it’s a failure quickly so that you can devote your energies into other strategies.
6. Productize.  After several iterations of building a little, deploying, and then observing & measuring that you’ve identifying a product that will be successful in the marketplace (or in the case of internal application development successful with your user base).  As described above, although you may choose to continue following this lifecycle, a common decision is for the team to adopt one of the other DAD lifecycles – such as the Scrum-based agile lifecycle, the Kanban-based Lean lifecycle, or the Continuous Delivery lifecycle – and effectively treat the time they spent following this lifecycle as their Inception phase.

To summarize, the DAD process framework takes a flexible, non-prescriptive approach to software-based solution delivery.  As a result of this philosophy DAD supports several development lifecycles, one of which is the Lean-Startup-based Exploratory lifecycle described in this posting.  This lifecycle is typically followed in situations where you are unsure of what your user base wants, and sometimes even when you are unsure of who your user base (your customers) will even be.

This post is a follow-up to Comparing DAD to the Rational Unified Process (RUP) – Part 1.  In that post I described in some detail why Disciplined Agile Delivery (DAD) is not “Agile RUP”.  DAD is quite different in both approach and content.  There are however some very good principles that the Unified Process (UP) incorporates that are not part of mainstream agile methods.  This post describes what parts of the UP made it into the DA toolkit.

DAD suggests a full delivery lifecycle approach similar to RUP.  DAD recognizes that despite some agile rhetoric projects do indeed go through specific phases.  RUP explicitly has four phases for Inception, Elaboration, Construction, and Transition.  For reasons that I described in the last post, DAD does not include an explicit Elaboration phase.  However the milestone for Elaboration is still in DAD which I will describe shortly.  As the DAD basic lifecycle diagram shows, DAD has three of the four RUP phases.

• The Inception phase.  An important aspect  of DAD is its explicit inclusion of an Inception phase where project initiation activities occur.  As Scott Ambler says in one of his posts “Although phase tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project.  While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than the general perception (the 2009 Agile Project Initiation survey  found the average agile team spends 3.9 weeks in Inception)”.  So in DAD’s Inception phase (usually one iteration) we do some very lightweight visioning activities to properly frame the project.  The milestone for this phase is to obtain “Stakeholder consensus” on how to proceed.  In the book we describe various strategies to get through the Inception phase as quickly as possible, what needs to be done, and how to get stakeholders consensus.
• The Construction phase.  This phase can be viewed as a set of iterations (Sprints in Scrum parlance) to build increments of the solution.  Within each iteration the team applies a hybrid of practices from Scrum, XP, Agile modeling, Agile data, and other methods to deliver the solution.  DAD recommends a risk-value approach of prioritizing work in the early iterations which draws from the RUP principle of mitigating risk as early as possible in the project by proving the architecture with a working solution.  We therefore balance delivering high-value work with delivering work related to mitigating these architectural risks.  Ideally we deliver stories/features in the early iteration that deliver functionality related to both high business value and risk mitigation (hence DAD’s “risk-value” lifecycle). It is worthwhile to have a checkpoint at the end of the early iterations to verify that indeed our technical risks have been addressed.  DAD has an explicit milestone for this called “Proven architecture”.  This is similar to the RUP Elaboration milestone without risking the confusion that the Elaboration phase often caused for RUP implementations.  All agile methods seek to deliver value into the hands of the stakeholders as quickly as possible.  In many if not most large enterprises it is difficult to actually deliver new increments of the solution at the end of each iteration.  DAD therefore recognizes this reality and assumes that in most cases there will be a number of iterations of Construction before the solution is actually deployed to the customer.  As we make clear in the book, although this is the classic DAD pattern, you should strive to be able to release your solution on a much more frequent basis in the spirit of  achieving the goal of “continuous delivery”.  The milestone for the end of Construction is that we have “Sufficient functionality” to deploy to the stakeholders.  This is the same milestone as the RUP’s Construction milestone.  During the Construction phase it may make sense to periodically review the progress of the project against the vision agreed to in Inception and potentially adjust course.  These optional milestones in DAD are referred to as “Project viability”.
• The Transition phase.  DAD recognizes that for sophisticated enterprise agile projects often deploying the solution to the stakeholders is not a trivial exercise.  To account for this reality DAD incorporates the RUP Transition phase which is usually one short iteration.  As DAD teams, as well as the enterprise overall streamline their deployment processes this phase should become shorter and ideally disappear over time as continuous deployment becomes possible.  RUP’s Transition milestone is achieved when the customer is satisfied and self-sufficient.  DAD changes this to “Delighted stakeholders”.  This is similar to lean’s delighted customers but we recognize that in an enterprise there are more stakeholders to delight than just customers, such as production support for instance.  One aspect of RUP’s Transition phase is that it is not clear on when during the phase deployments actually take place.  Clearly stakeholders aren’t delighted and satisfied the day the solution goes “live”.  There is usually a period of stabilization, tuning, training etc. before the stakeholders are completely happy.  So DAD has a mid-Transition milestone called “Production ready”.  Some people formalize this as a “go/no go” decision.

So in summary, DAD frames an agile project within the context of an end-to-end risk-value lifecycle with specific milestones to ensure that the project is progressing appropriately.  These checkpoints give specific opportunities to change course, adapt, and progress into the next phases of the project.  While the lifecycle is similar to that of RUP, as described in Part 1 of this post it is important to realize that the actual work performed within the iterations is quite different and far more agile than a typical RUP project.

Last week I was discussing DAD with a new client and he asked me “Is DAD just an Agile version of RUP?”  In a word, no.  DAD is a toolkit composed of a hybrid of methods and practices as shown in the diagram.  It includes the best of Scrum, Extreme Programming (XP), Agile data and modeling, and yes, the Unified Process (UP).  DAD also includes additional content such as agile governance that is not present in any of these methods.  As the diagram indicates, probably the method that adds most to DAD is XP, not the UP.
The Rational Unified Process (RUP) started as a small manageable process framework targeted specifically for building software within the context of an iterative lifecycle.  However over time, Rational (and subsequently IBM) added additional guidance and artifacts to extend the applicability of RUP to all sorts of projects, such as package implementation, maintenance projects, technology specific guidance (J2EE, .Net etc.), systems engineering and may other project types.  It became unwieldy and hard to understand and apply successfully.  In fact it is frequently misused (with the Elaboration phase often being treated as a big requirements upfront (BRUF) phase as an example).  This misuse has been described by Julian Holmes as RINO (RUP in name only).  To be clear, RUP properly applied in the right circumstances can be very effective.  Unfortunately though, that often does not happen.  One of the issues with applying the RUP framework to different types of projects is that it is described as a “Use case-driven” approach.  Specifying requirements as use cases, and then creating component-based architecture from these use case realizations is fundamental to RUP.  This presents challenges for maintenance projects or package implementations where it may not make sense to produce use cases at all.

DAD does not prescribe a use case-driven approach, or insist that OOAD be rigorously applied to build out services/components.  A use case-driven approach is a potential practice to apply but there is a danger that this could lead to an exhaustive requirements specification which is not particularly agile.  We would prefer to use a user story-driven approach if that makes sense within the context of your project.  User stories might not be the right choice either.  Perhaps you are in a regulatory environment that demands a traditional software requirements specification (SRS).  The key point is that you will have to adapt to the situation that you find yourself in.  This is why we prioritize the team’s work with a work item list comprised of work items, rather than Scrum’s backlog comprised of user stories.  Using a work item list allows us the flexibility to put any type of work onto our backlog, extending the applicability of DAD to many types of projects beyond those for which RUP or Scrum would be ideally suited.

DAD is goal-driven, not artifact-driven.  It does not prescribe practices or specific artifacts.  Rather, it suggests alternative strategies than can be applied at certain parts of the lifecycle with the pros and cons for each, but which ones you choose is up to you.

In my next post I will describe which aspects of the Unified Process did make it into DAD and why.