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

We are excited to announce that the inaugural DA Day virtual conference is taking place May 15th.  Call for presentations is open until April 2nd.  We are looking for short 15 minute presentations on a variety of topics. If you would like to speak on a different topic please feel free to submit it anyway as we may adjust the topics based upon the submissions received.  Share your experiences with the community regarding how DA has benefited your organization.  Get your submission in today!

Attending is an excellent way to attain all of your annual professional development credits in one day.   We will also be providing a sneak peak into a new Disciplined Agile tool to make DA easier to use and learn which will be available to members in good standing.  We are very excited about this application and we think that you are going to love it.

So join us! It promises to be a fun and informative day.

More information here…

Mark & Scott

The Lean Enterprise genie has been out of the bottle for some time now, but for most organizations he’s still a long way from granting three wishes

The Lean Enterprise … Enterprise Agility … DevOps 2.0 …  BizDevOps … the list of monikers and descriptors for this concept is becoming a lengthy one, but there’s no denying that lean and agile concepts and practices are now mainstream, and pushing to break out of their former boundaries within software development.

Reflecting on this, I came across a very apt description (in, of all things, a conflict simulation design blog) of what seems to be happening in this realm of late:

“Most new ideas, however fresh or spontaneous they may appear at first glance, usually represent an evolutionary synthesis of previous ideas; in other words, when it comes to most things, history really is “preamble”.¹

The idea of bringing business, development and operations people to the same table to act as a tripartite coalition from the very start of product development has been gaining exponential momentum of late. As far as ideas go, it is not an entirely new one of course. Encouraging collaboration from the get-go has long been a hallmark of Agile approaches – in development for example, George Dinwiddie is believed to have coined the term “the three amigos” around 2009² to describe the interplay of developers, testers and business analysts / product owners from an Acceptance Test Driven Development (ATDD) perspective. However, other than describing a tripartite arrangement, the 3 amigos analogy differs from the most recent crop of expressions in that contrarily to say, BizDevOps, it only actually plays on two of the required three planes.

Another oddity that struck me is that one of the first high visibility discussions that I can remember describing the interplay of business, technology and operations actually framed the debate in terms of an antipattern: to wit, a July 2011 Forrester whitepaper which coined the expression “Water-Scrum-Fall”³ as a way of describing the very lack of cross-enterprise collaboration which bedevilled most organizations’ agile efforts.

The need for systems thinking

Unsurprisingly, a silo mentality is the biggest single impediment to achieving true Enterprise agility. Everyone involved in the creation and delivery of business solutions needs to collaborate across the breadth and depth of the organizational structure. Team-level agility in the delivery space alone will not deliver on the promise of the Lean enterprise; nor is DevOps enough. Business, IT and operations all need to break out of their silos and embrace systems thinking.

In both my practice and my teaching, I constantly strive to come up with metaphors that can convey the underlying meaning of concepts in ways that overcome resistance by reframing the issue at hand in a very different manner than what people may be used to. I would now like to share a metaphor that I have recently been using which has shown a lot of promise in terms of getting everyone thinking in terms of the whole system when it comes to the concept of the lean enterprise.

As discussed above, the system in question can be simplified as having three planes:

This however is merely … a triangle, and does nothing to convey the importance of intense collaboration. We need something more evocative.

Something with three parts, yet an indivisible whole. There is actually quite simple that we can use to convey this:

That’s right. True Enterprise agility is neither a sprint, nor a marathon … it’s a Triathlon.

What makes this metaphor work is simply this:

Although a triathlon is made up of three events, it is performed by a single athlete who must excel at all three to win. In this case, the “athlete” is not an individual nor a team, but the whole enterprise.

So, if our organization is reaching a point where it is proficient in delivery, there isn’t much more to be gained by continuing to concentrate all of our improvement efforts in IT alone – the Business side of things must be brought into the game as a full partner. The same goes for operations – even careful, collaborative prioritization backed up by competent delivery will not win the day if ready solutions must then linger for months in pre-production environments. Nothing ground-breaking here, just a fresh way of looking at the issue … no serious triathlete would sign up for the Ironman in Hawaii knowing that she faced daunting challenges in terms of her swimming, or was a less than competitive cyclist. The same must go for our “lean” enterprises. Until we can let go of the silo mentality and learn to act as a single “athlete”, we will continue to be bound by the shallows⁴ of Water-Scrum-Fail.

Endnotes

1. http://mapandcounters.blogspot.ca/2012/04/roads-from-smolensk-spi-dunnigan-and.html
2. http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/
3. Available at https://www.forrester.com/report/WaterScrumFall+Is+The+Reality+Of+Agile+For+Most+Organizations+Today/-/E-RES60109
4. Shakespeare of course. Julius Caesar, Act 4, Scene 3.

Is your organization concerned with the cost and time required to adopt agile strategies?  Are you just starting out with agile and hoping to improve your chances of success by learning from the experiences of those who have gone before you?  Are you part way into your agile transformation but struggling to figure out how it all fits together?  If you answered yes to any of these questions please read on.

In this blog posting we discuss what it means to “right size” your software process to meet the needs of the unique situation that your team finds itself in.  We discuss two common anti-patterns: starting with a process framework that is much too large for your needs and starting with one that is far too small for your needs.  We argue that it’s much better to avoid these extremes and instead take a middle-ground approach by starting with a toolkit that is much closer to your actual needs.

Extreme #1: Large process repository

The first process right-sizing anti-pattern is to start with a large process repository, the classic example being IBM’s Rational Unified Process (RUP).  Although RUP is much maligned within the agile community the fact is that if you were to examine it with an open mind that there are many very good ideas promoted by RUP.  Be that as it may. The basic strategy with RUP is that you need to tailor down the process, often dramatically, to meet the unique needs of the situation your team finds itself in.  To do this requires significant process expertise, time, and money.

In practice, however, many organizations ran aground with RUP when they tailored it to be something similar to the waterfall-style processes from yesteryear that they were familiar with.  This is often referred to as RUPifall.  Another common mistake was to say to themselves “wow, there’s a lot of great ideas here, we need to do them all” and as a result they would create a process that was far too heavy to meet their needs.  In either case the problem was that they often didn’t have the process expertise required to right-size their process.  We also see this with organizations starting from frameworks such as ITIL, COBIT, and CMMI so this clearly isn’t just a RUP problem.

Extreme #2: Small methodology

At the other extreme is the right-sizing anti-pattern of starting with a small methodology, the classic example in this case being Scrum.  Although there is significant support for Scrum within the agile community, or at least among people who are new to agile, we’ve been seeing for a long time now that organizations are also running into trouble with this approach too.  With Scrum the idea is that you add in the techniques that Scrum doesn’t address to right-size your process.  Because Scrum proves to be only a very small part of the overall picture, to do this requires significant process expertise, time, and money.

In practice organizations run aground with Scrum because they don’t have the process expertise to expand it to meet their needs.  One only has to count the number of “How does X fit into Scrum?” conversations occurring in agile discussion forums online, or at user group meetings or conferences, to see that this is true.  Step back for a moment and ask yourself how much time and effort has your organization invested in trying to adopt Scrum.  Could it not have been more streamlined?

A few years ago Forrester Research discovered that the majority of organizations “doing Scrum” had actually tailored it into what they called Water-Scrum-Fall (others call this Scrumifall).  As we describe in Going Beyond Scrum this occurs for several reasons.  First, Scrum doesn’t address the full delivery lifecycle, instead choosing to focus on the construction portion of it.  As a result organizations tend to stick with what they know, a heavy project initiation phase and a heavy solution deployment phase.  Second, Scrum only addresses only a small portion of what you need and explicitly leaves technical issues up to you.  These issues include topics such testing, programming, architecture, governance, documentation, deployment and many others.  As a result teams are left to piece together a process strategy that works for them, at the very same time that they’re struggling to understand the fundamentals of agile and lean software development.  They rarely have the process expertise to do that and as a result end up having to hire hordes of expensive Scrum coaches, few of whom seem to understand the enterprise-class realities that your teams actually face.  This is a risky and expensive proposition indeed.

The Effective Middle Ground

Both of these anti-patterns represent extremes: start with something large and cut it down to size, or start with something small and build it up to meet your needs.  Why not start with something much closer to what you actually need?  Doesn’t that make a lot more sense?  Why do you need to do all this process work?  Because someone wants to sell you tooling?  Because someone else wants to sell you expensive coaching and questionable certification strategies?  Isn’t it time to consider a more pragmatic strategy?

The Disciplined Agile (DA) toolkit is a more effective middle ground.  It addresses the full delivery lifecycle, as does RUP (but not Scrum), and even gives you several choices from which to select.  Sometimes a Scrum-based lifecycle is appropriate, sometimes a Lean lifecycle is, other times a continuous delivery lifecycle is best, and sometimes an exploratory “lean start up” lifecycle is.  Different teams, different situations.  DAD starts with a lightweight approach, as does Scrum but not RUP, helping you to avoid the bloatware of RUP and filling in the numerous blanks left by Scrum.  DAD also gives you lightweight tailoring advice in the form of process goal diagrams, in many ways a cross between mind-maps and decision trees, that make your process choices explicit.  The RUP process tailoring advice, if you bother to read it at all, is rather heavy handed and the Scrum tailoring advice boils down to “you’re smart, you can figure it out and if your run into trouble hire a coach.”  Isn’t it time to abandon the extremes?

This middle ground strategy isn’t without its faults.  A challenge with DAD is that it explicitly reveals that agile software development, or as we prefer to say agile solution delivery, is complex.  This is particularly true in enterprise-class situations where teams are often facing combinations of scaling factors such as larger team size, geographic distribution, and regulatory constraints.  DAD makes it explicit that teams need to invest a bit of time up front to perform initial scoping, initial architectural modeling, and initial planning (all in a lightweight manner of course).  This sort of pragmatic thinking can be inconvenient for less-experienced developers who just want to jump in and start coding.  Because DAD promotes the philosophy of enterprise awareness it purposely bakes in strategies for governance, DevOps, and working with IT-level groups such as your enterprise architects and data management team to name a few.  This can also prove to be inconvenient for developers who want to narrowly focus on doing what’s convenient for their team as opposed to what’s best for their organization.

In Summary

The following infographic summarizes the main points in this blog posting.

We hope that you’ve found this blog posting enlightening.  Even if you are well along the way of your Scrum adoption, or of evolving your RUP-based approach, you can still benefit from switching over to DAD.  Scrum teams will find that it addresses many of the issues that you’re still struggling with, and RUP teams will find that it shows how to work in a far more lightweight manner.  Organizations will find that it provides a much better foundation from which to scale agile strategies.

Along with the new look and feel we have a new email digest to keep everyone in the community up to date with the latest posts and comments.

Come and be part of the community. Learn about the new and exciting ideas being discussed and share your ideas. Sharing and collaborating makes everyone stronger!!

Please invite your Agile colleagues to join and be part of the community.