Disciplined Agile

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

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.

As you can see from the above diagram, the primary roles of Disciplined Agile (DA) teams are similar to those of Scrum.  In Scrum, the product owner decides what will be built and in what order.  In DA we recognize that architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk.  As a result, DA explicitly includes Agile Modeling’s role of architecture owner. The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.  The person in the role of team lead will often also be in the role of architecture owner, assuming they have the skills and capacity to fill both.  This isn’t always the case, particularly at scale, but it is very common for smaller agile teams.

The responsibilities of the architecture owner include:

• Guiding the creation and evolution of the architecture of the solution that the team is working on.  Note that the architecture owner is not solely responsible for the architecture, but that they lead the technical discussions.
• Mentoring and coaching other team members in architecture practices and issues.
• Working closely with the Enterprise Architecture team, and often being a member of it, to understand and evolve the architectural direction and standards of your organization.
• Ensuring that the team adheres to the architectural direction and standards of your organization.
• Understanding existing enterprise assets such as frameworks, patterns, subsystems and ensuring that the team uses them where appropriate.
• Ensuring that the solution will be easy to support by encouraging good design and refactoring to minimize technical debt.
• Ensuring that the solution is integrated and tested on a regular basis, ideally via the practice of continuous integration(CI).
• Having the final say regarding technical decisions, but they try to avoid dictating the architectural direction in favor of a collaborative, team-based approach. The architecture owner should work very closely with the team lead to identify and determine strategies to mitigate key project technical risks.
• Leads the initial architecture envisioning effort at the beginning of the project and supports the initial requirements envisioning effort (particularly when it comes to understanding and evolving the non-functional requirements for the solution).

One of the key reasons for having this role in DA is that the architecture owner, like the product owner, has a say in work items that are added and prioritized in the work item list (backlog in Scrum parlance).  While business value is certainly a prime determinant of priorities, completing work related to mitigating technical risks is also important.  Additionally, in DA the aim is to deliver consumable solutions, not just working software.  As such, sometimes it is necessary to add work items that are technical in nature, for example related to error logging/monitoring.  Or perhaps work items need to be added to improve the continuous integration and deployment processes.

We have found that the concept of having both product and architecture owners ensures that the solution addresses both functional and quality requirements such as usability and supportability adequately.  In fact, on my current project, I worked with the product and architecture owners to negotiate their priorities such that the iteration underway includes not only a selection of high priority stories, but also a set of technical work items related to hardening the solution in preparation for entering the Transition phase of delivering the solution to the stakeholders.  Without a specific role of architecture owner, it can be difficult to escalate important technical work into the work item list.  As a result it is often done subversively without the knowledge of the product owner which is not a healthy practice, or worse it never gets done resulting in a poor quality solution.

Scott has written a good article that describes the architecture owner role in more depth.  You can view it here.

Why does DAD not have an explicit role for an Analyst?  Without question classically trained analysts bring much needed soft skills and a structured approach to requirements elicitation and negotiation which may not be present in the other roles such as a product owner or a developer.  However, having these skills alone is not enough in an agile and lean world.

Unfortunately, professional organizations tend to encourage us to seek specialization and certifications over being cross-functional team members, which will be far more effective and valuable in the future.  This is not to say that these organizations do not deliver value in developing and maintaining standards of professional conduct and capability.  Attaining certifications (that require some degree of commitment and experience beyond a 2-day workshop) demonstrate commitment to a professional specialty.  This is admirable but I would suggest that this base of knowledge is just the start of being an effective team member on an agile project.  We should look outside our area of specialty to learn all we can about other aspects of software development.

It is my belief that in the near future, analysts will need to be competent testers if they intend to prosper in their profession.  An increasingly important skill is the ability to write requirements as executable tests.  My advice to analysts is to learn as much as you can about agile testing and seek opportunities to write your requirements as tests wherever possible.

For Business Analysts that are not interested in moving more toward the testing end of the spectrum there is another way to go.  Analysts can be good Product Owners, representing the customer on the project and by managing the scope and priorities.  In this role they can use their elicitation and facilitation skills to gain a clear understanding of what the customer needs (vs. wants).

Another potential career path is for the BA to move more into the area of traditional management consulting.  Often it is the business process that needs to be fixed, and this is where traditional Business Analysis skills will always be needed.

In my opinion, one career path for analysts is going the way of the dinosaur though.  And unfortunately this career path is often the status quo.  Traditional projects expect Business Analysts to document business processes and requirements in batch up-front in a linear, waterfall fashion.  They then must obtain sign-offs before actually proceeding with implementing any of the requirements.  Subsequent changes to those requirements are discouraged, unless through a formal, time consuming and wasteful Change Request process.  This model clearly is flawed, and eventually most companies will change their approach.  High ceremony and bureaucratic organizations such as government will be the slowest to adapt, but private companies in a competitive environment will adapt their requirements capture approach to a more agile alternative or risk being left behind by their competitors that will be more “agile” in adapting both their business processes and the solutions that support them.

Yesterday Mark and I double teamed on a webcast overviewing DAD to a university class.  After the webcast we got the following question:

I am wondering if it would make sense to entirely eliminate the word “phase” from DAD’s vocabulary. What about simply talking about different types of iteration? For instance, inception could become something like “pre-construction iterations”, construction could become “construction iterations”, and transition “transitions iterations”…  That may be a bit cumbersome, but the word phase does scare people away.

Yes, the word phase might scare some people away.  We’ve thought long and hard about the terminology that we use and were also a bit worried about the word “phase” at first.  For some reason phase has become one of those dirty words in the agile community, along with other words such as governance or documentation.  The primary concern seems to be that phase implies a serial approach, something many agilists believe to be foul and evil.  Yet the reality is that projects do in fact proceed in a serial manner.  There are some project initiation activities at the start.  Then there are construction iterations/sprints one after the other in yes, a serial manner.  Then there is an effort to deploy/release your solution into production.  This is clearly “serial in the large”.

But, why the term phase?  Why not iteration?  Or season for that matter season (Gary Evans has a very coherent argument for that term)?  Because phase is accurate (albeit an agile swear word).  In the various IT surveys that I’ve run over the years I’ve found that the average agile team spends about 4.5 weeks performing initiation efforts, has construction iterations that are about 2 weeks in length, and takes an average of roughly 4 weeks to release their solution into production.  So perhaps these initiation and release efforts could each be thought of as two iterations (on average, your mileage may vary) but they really aren’t iterations in their own right usually.  Maybe they’re different length iterations?  There are several ways of thinking about it, but notice how the application of the term iteration doesn’t really make perfect sense.  Then we have numbering issues.  Is the initiation effort iteration/sprint 0?  If it’s two iterations would they be -1 and 0?  Sigh.

One thing that we have done which some may feel to be radical is we’ve chosen to adopt phase names from Unified Process (UP) – Inception, Construction, and Transition.  We could have made up different names, such as Initiation, Development, and Release respectively.  Or adopted Start Up, Construction, and Hardening (yuck, there’s more to Transition than hardening and frankly I would consider a late “hardening” effort to be a clear sign you’ve likely got a process problem you need to deal with).  And I have no doubt that there are many other options for each phase name.  Whatever names we choose someone isn’t going to be happy, and why not give a bit of a nod to a proven software development framework such as UP?

Another interesting thought is that by having named phases it makes it clearer where potential governance points in the lifecycle are.  In the diagram below you can see how several of the suggested light-weight milestones – Stakeholder vision, Sufficient functionality, and Delighted stakeholders – corresponds to the end of a phase.  Or perhaps more accurately, fulfilling the milestone is an indication that your team is moving from one phase to the next.

In the end, I think we’re pretty clear that when you tailor DAD that you can use whatever terminology you like.  In fact one financial institution that adopted an early version of the DAD basic lifecycle, the one based on Scrum, reworked the diagram to use Scrum terminology.  I think it’s a bit goofy but it works for them.

The term phase might in fact scare a few people away.  But, it’s hard to imagine that anyone that concerned about what something is named will be flexible enough to be successful at DAD anyway.