Agile is Commando Culture, not Commando Gear

Very few large organizations in the world today have been able to understand and harvest Agile to their competitive advantage.

They more often end up chasing the blind Agile Rat Race, with the "me too" slogan, retrofitting it into fighting terrorists with traffic constables in commando gear supervised by bureaucrats.

Building the right ecosystem, culture and work environment that can enable build true Agile Capability is the most difficult proposition.

When I say a true Agile Capability, it should be capable of producing results that resemble value innovation from the likes of products from Apple and a work culture/ work environment for people as in the likes of Google.

Agile is "Commando Culture", not "Commando Gear".

Agile Transition Roadmap for larger Organizations

We need newer Agile Vehicles to enable larger organizations effectively migrate to Agile, incrementally and iteratively.

I have had similar experiences when trying to help larger organizations transition to Agile. I had found that the primary lacunae that surfaces first in the teams is their inability to build software in the incremental and iterative mode using the right engineering practices like Incremental Architecture, Evolving Design, TDD, Continuous Integration, Automated Testing and Continuous Refactoring.

This has nothing to do with Agile, but is a core prerequisite competency to get into the IID mode of software development that agile methodologies mandate.

Here is the sequential road-map that worked for me with many large customers helping them migrate to Agile:

First Destination for the Agile Vehicle:

Get teams build competencies in IID Engineering Practices as mentioned above. This is the preliminary ab-initio "Shu" stage competency needed for everyone trying to build software in the IID mode. Their management style can continue to be formal and traditional at this stage.

Second Destination for the Agile Vehicle:

Once the IID engineering competency is achieved by the organization, introduce the concepts of Critical Chain Project Management (CCPM) to enable them understand how to shrink cycle times and work towards continuous improvements using TOC. Their management style slowly migrates to a systems approach to continuous improvement. Cutter had a few years ago, published my experience report on this.

Third Destination for the Agile Vehicle:

The teams now understand how to handle complexities, individual capabilities and unpredictabilities in the way we build software. They also understand the vagaries of estimation and adaptive planning. They are now ready to be introduced to shifting their business focus from focusing on efficiency(costs) to focusing on Value (customer).

Introduction to Lean Values and Principles here makes perfect sense and the Lean Engineering Concepts now get integrated into their way of working. Organization now focuses on how to anticipate, understand meet and exceed Customer (user) Value Expectations (and perceptions). Their organizational business policies change for the better.

Fourth Destination for the Agile Vehicle:

The organization is now introduced to the concept of Performance Management in the Knowledge Industry. The "Y" Theory for people management. We enable organizations flatten their hierarchies, invert their pyramid structure, restructure their way of working in teams rather than individual roles to finally result in the entire organization working through coordinated and empowered clusters of self-organizing cross functional teams with reward systems promoting collective ownership in teams. This makes the productivity and profitability of the organization visible and tangible.

Fifth Destination for the Agile Vehicle:

The organization now is ready for embracing the true Values and Principles of Agile. Their Business Policies now are oriented towards collaboration (not contract). Their Planning and Execution now are oriented towards being Adaptive. Their People are now enjoying working in Teams with collective ownership. They now need to understand how to leverage this further by focusing on Mutual Trust, Transparency in their relationships with their customers and how to actively collaborate with customers iteratively to accelerate co-creation of Value.

They should now be in their "Ha" stage of learning. Over time, with consistent innovation and improvement, the organizations can now aim to mature to the "Ri" stage.

This done, to my mind, is Agile Accomplished.

Clarifying the "FScrum" Rationale

In a hierachial organizational context, when people are told to do things in a particular way, they do it that way but usually do not like it. This seriously erodes their commitment, motivation and belief in the way they do what they do, as they have not internalized "why" they do what they do, that way.

Let me try and explain: When I was an officer in the Indian Air Force, we were all forced to have a crew cut (very short hair). We used to loathe short hair cuts and would always defy by not having hair cuts during our long holidays. After I left the service, back in civilian life for the last 2 decades, I always have a crew cut by choice. I find long hair is very troublesome to maintain. This happens, as now, I truly believe that sporting a short hair cut is more comfortable, more hygienic, more presentable and very easy to maintain.

Over time coaching and training software professioanls, I found that when they are told to do something that seem illogical, they question it. This questioning and subsequent analysis and understanding leads to more clarity in their learning. Just as we show them the right things to do and clarify its rationale, we should also illustrate what may be the wrong things to do and clarify those rationale too. This accelerates right learning.

My rationale for discussing FScrum as a controversial concept here was to generate an interest to understand "how not to do Scrum" and consequently create a realization in them as to "how it is done right" and "why is it so". I am just playing the "devil's advocate" to accomplish my goals of ensuring that everyone practising Scrum understand its rationale right and practice Scrum in its true spirit to be able to harness the best of the benefits out of it.

Cheers.

When can Scrum take credit for Success

I have seen many contexts in software development that are not congenial for IID and that higher value can be generated faster, cheaper and better, by doing it right the first time, in such contexts. Retrofitting Scrum in such contexts, with BUFD, in an incremental but non iterative mode, sometimes did improve the way teams did things right the first

time, though they implemented Scrum upside down.

I am not trying to be antithetical to Scrum, but am trying to identify and discover new options to generate value that are clearly outside the contexts of Scrum, based on patterns in value generated by Teams implementing Scrum upside down in traditional waterfall environments.

I have no where said that it is a pattern of Scrum, but have clearly debated that this is a useful pattern of anti-Scrum. FScrum, is and will be an anti-Scrum pattern, so everyone knows that this is NOT Scrum, but still has a potential to enhance Value in contexts outside of Scrum identified contexts.

How do we know whether Scrum is working or an upside down implementation of Scrum is working ?

We could easily verify and validate if improvements in an organization can be credited to Scrum.

Here is a simple way of doing it. In any organization that claims improvement with using Scrum, we can verify and validate if the following had occurred in the way they did their work:

1. There were small teams ( 5-9 members) who were fully empowered, self-organzing and cross-functional (SO-CF). The Teams were supported by the Management through Servant Leadership.

2. The SO-CF Teams demonstrated that through iterative "inspect and adapt" practices, they accomplished empirical learning with feedback and demonstrated improvements in their iteration deliverables, successively improving with each iteration.

3. Customers provided regular feedback on the deliverables made by the team at the end of each iteration and found that with successive iterations, the teams had developed a capability to anticipate, understand, meet and exceed their expectations, and improved their capability do so, with each successive iteration.

4. The Product Owner and the Team together, co-created mutual Value and harnessed change to enahance Value. There was a high degree of collaboration, communications, interactions and a high degree of mutual trust between the Product Owner and the Team.

5. That there was complete mutual trust and transparancey between the vendor organization and the customer organization, between the vendor management and the SO-CF Teams, and within the team members. All activities, practices and policies which the three stakeholders adopted in their mutual relationships and transactions, through the duration of the project till the end, confirms this.

5. Teams ability to deliver Value to Customers improved successively with each iteration due to the ability of the teams to continuously learn and improve through "inspecting and adapting" their way of doing things based on empirical feedback and learning

6. That the work started when requirements was not fully clear and without a BDUF, the cutomers and developers worked together evolving and changing scope over successive iterations, based on their learning and feedback, in a manner that both the teams and customers were learning new things, adding and modifying scope all the way that reflected their learnings and got a product in the end that fully met their expectations.

7. At the end of the Scrum project, The Customers were delighted, The Team was delighted and the Mangement was delighted since they made good profits too.

8. And that in this whole project start to finish, Scrum Roles, Artefacts and Ceremonies were practiced exactly as in the book, without any ScrumButs, and in the right spirit of Scrum Principles and Practices as published.

If this evidence can be found, I will surely agree that the credit of its success should go to Scrum. If even one of these were not true in the context, I would surely not pass the credit to Scrum and will investigate to find out what else contributed to their success.

SCRUM should be GOAL driven

We have a great saying "Systems should be Customer driven, Customers should not be System driven" . Similarly I feel that any approach or strategy we embrace should be appropriate and effective to accomplish a clear set of "GOALS" (or objective) for a given endeavour in a given context.

Our "GOALS" in different project situations can be different and we need to ADAPT our approaches to accomplish the GOALS most efficiently and effectively in that context.

Imperative therefore that before we choose to adopt SCRUM, we should know why we are doing so, what we are trying to accomplish, and how this will help us accomplish our GOALS.

If my GOALS in one project context is to increase efficiency only (less cost, less time), I should be able to ADAPT my Scrum Practices to that context to enable me accomplish my GOALS in that context.

If my GOALS in another project situation is to deliver VALUE to my customers by harnessing the "Change" and "Uncertainty" to the customer's competitive advantage, I should be able to ADAPT my Scrum Practices to that context to enable me accomplish my those GOALS in that context.

Simply adopting a strategy or an approach like SCRUM, without understanding why we should do that, may be meaningless and counterproductive. I now am more confident, and more convinced that we should be able to ADAPT Scrum Practices to different situations differently.

Therefore it becomes relevant to explore how SCRUM can benefit those who have only "EFFICIENCY" (reducing cost and time without compromising quality and scope) as their GOALS in their "waterfall" projects and "waterfall" organizations. With a few modifications in SCRUM Principles, it can work for them to accomplish their GOALS without changing the 3 Roles, 3 Artifacts, 3 Ceremonies and the core practices prescribed in SCRUM.

I am at it again, the FScrum will be a critical need for such teams, working in such contexts.

Agile, Shuhari and Commandoes

Guys operating in a Ri stage are like trained and experienced commandos. Commando training in the martial arts, plus orientation on a different Value System and Collaborative Team Work. In a given endeavor and its context, they need to manage both the "outputs" and the "outcomes" appropriately.

Scrum only talks about managing the outcomes. Without understanding how to manage the outputs, achieving outcomes would remain a mere passion. I was greatly inspired by a statement of Tom Peters in his book "Thriving on Chaos". He said "Most Quality Programs fail for two reasons : they have Passion without Systems or Systems without Passion". Now we can see this in real within the practice of Agile Software Development or in the rote implementations of heavy processes in so called L5 organizations.

I have been delivering free short-duration (2hrs) Tech Talks on Agile to larger software organizations in the recent past and have covered about 20 organizations so far and am to cover another 20 in the next couple of months. One participant asked me : if this is true, how do we do Agile ? I said, I would not know your organization context but you could do the following:

1. Identify guys in your organization who are potential commando material. Create an inventory list of such people. All in your organization may not fit to be commandoes. It requires an EQ, Team Play and being a good learner with a willingness to be honest, mature, committed and transparent.

2. Once you have identified such people, begin to train them in the software engineering skills needed to build software incrementally and iteratively. The ones I referred in my earlier post. Give them an orientation on the agile value system of collaboration, team work and customer value focus. This may be equivalent to the Shu stage. At the end of this training and orientation, identify now who qualify and who do not qualify to go further.

3. Now only those who qualified and passed the Shu stage, can be put on Agile Projects. This engagement will be for them to experience the Ha stage. Coach them as they do their job if required, to ensure that they now know how to apply their learning into real situations. You could disqualify members at this stage too if you find that they may not be suitable for Agile for one reason or the other.

4. When they successfully deliver value consistently in different project situations, they can be selected, groomed and used as Coaches, where they get a chance to work at the Ri stage with other Agile Teams either in their Ha stage or use them as trainers to train fresh intakes for the Shu stage.

This is how we train Pilots in the Indian Air Force (I am an ex-IAF officer from the Air Defence Stream). And this is how Army trains and maintains a group of Commandoes who during a war can work as soldiers but during a situation like 26/11, can work as commandoes, working towards a given goal, empirically and iteratively in an empowered self-organizing cross-functional team mode, strictly and clearly within a set of value system meant for them, which is different from the army way of process orientation.

Here too please note that out of 100 soldiers in the army, only a few qualify for getting trained as commandos and fewer still qualify to get posted to a commando unit for one term.

This is what I am trying to incorporate into my FScrum hypothesis.

Shuhari and Scrum

A discussion at agileindia forum on this topic was so enlightening, I felt it should be recorded here too for the benefit of all others not on this forum.

In the context of our discussions on this "Scrum for Waterfall" I had said :

......I am only pained when I see people embrace Agile without knowing what they are trying to achieve by doing so and practice it more as a "ceremony" . In such cases they are not able to understand the imperatives, implications and consequences of Agile......

To which one of the learned members in the forum responded:

http://en.wikipedia.org/wiki/Shuhari

..... I believe some of it is caused by a Shu level person heading a 'Ri' level operation. I hope an organization that is about to embrace agile employs a Ri level person or at least learn from and have one to guide at all times. It isn't bad in the initial stages of adoption to practice it as a ceremony as long as it is guided by someone who understands the implications.

Here is what I responded to his post which I wish to preserve here for others to read.

.......Your post on "Shuhari" has been a real eye opener for me in understanding why people doing Agile upside down, do it that way. I surely would like to pass this credit to you for sharing your views on it that has truly enhanced my wisdom... if I have any :)

I have seen many Western Agile Evangelists comparing Martial Arts to Agile and try to cut-copy-paste their approaches into the way we learn to do Agile.

Here is my 2 cents on it.

When you become a student of any martial-art, you first undergo a highly rigorous training on the basic Values, Principles and Practices of the martial art under a teacher, who is more seen as a tyrant. In such schools, students learn under the direct supervision of a teacher, for several hours a day, for several years, to master their learning of it. These schools more look like concentration camps. (Shu )

Once the teacher feels that you have learnt the art correctly, you are allowed now to practice the martial art, you graduate and you now leave the teacher and go on your own to apply your learning in real-time scenarios. You use your learning in a manner that suits the context of its use, strictly within its value system, and you start empirically evolving your own strategies and approaches to overcome your enemy in different situations and contexts. (Ha)

After years of such practice and success, your learning and approaches become your reflexes and now these competencies can be used naturally. This highest stage of mastery is also called "Unconscious Competence" and your skills are naturally ingrained in your action, reactions and deeds. (Ri).

Now my question to you is:

Where have the agile developers gone through the Shu, and Ha stages before they think they are operating in a Ri stage of maturity. ( My answer to this would be: The two day CSM course under a CST is the Shu stage, After becoming a CSM, you first failed agile project is your Ha stage, therefore now in your next Agile Project you think you are operating in a Ri stage, so you need a Ri level coach. I agree. But I cannot run my company on this basis and still satisfy my customers and make profits consistently.

Similarly guys who pass a Black-Belt certification examination in Six Sigma feel that they are now in the Ri stage.(Sorry..they are no where near it)

A lot of guys have become "Agile Evangelists" and preach/teach Agile and Scrum without ever having written one line of code. Ask them to teach you "Incremental Architecture", "Evolving Design", "Test Driven Development", "Refactoring" (refactoring of architecture, design, code and tests) and "Continuous Integration" principles first before they talk Agile or Scrum to you. Most of them will run away or disappear instantly.

How do you expect to learn to do Agile anyway at the Shu and Ha stages from them and expect to operate at a "Ri" stage with your eyes, ears closed and standing on one leg on the tip of a pole.

Spend some time and introspect on what I am trying to say here, and we may have some ray of hope for Agile to survive in the near term at least.