Context impacts the outcome

My exercise/work-out regime pretty much trends like a stock market. Many times, it goes down for weeks, and I have to pull myself back up to hit the gym again. I think it is a balancing act combined with the commitment to keep myself fit.

Recently I was reading an article about the impact of exercise on the mind. It seems that running, swimming and similar activities help in elevating the mood levels by releasing a chemical called "Serotonin."

However, if one is forced to do exercise, the brain gets into a stressful mode, and the effects are reversed. The author here gives a good analogy to this context by saying 

the difference between running because you're hunting something, and running because it's hunting you.

Why am I talking about exercise here... It is not about exercise; it's more about the how context impacts the outcome. 

In the Agile world, thousands of teams across the globe spend countless hours in daily scrum, retrospectives, etc. The question is, are you doing these rituals because you are interested in it or is it because someone is forcing you to do it? 

Even though the daily scrum, retro rituals might remain the same, the outcome would be different depending on the context, Isn't it?

Is this the end of Samsung ?

Last week, I was returning to Melbourne from the Sydney trip. While the flight was about to depart the terminal, the captain made a safety announcement about the Samsung Galaxy Note seven being banned on the airplane due to it's fire risk.

The announcement triggered my own bad memories with Samsung in the recent past in addition to inspiring me to jot down a few lines for this post.

I bought a Samsung Smart TV couple of years ago, and within a year, it started flickering, and I had to approach the customer care for help. Since it was under warranty, they promptly took it away, fixed it. However, it was a bit of frustration to see a brand new TV having technical issues in a short span of time.

In another instance, one of my friends who bought Samsung cell phone faced similar challenges with its quality in a short span of time.

A couple of months ago, there was a major recall of Samsung top loading washing machines that used to blow up. It seems the electrical wires used were substandard.

The issue with Samsung and its devices catching fire is becoming a norm. It is also important to note that, the issue is not just with one product but with most of their popular ones. 

Large and globally reputed organizations should have their highest priority on quality in addition to delivering features to the customers. The incidents seen with Samsung products show a deeper problem with its quality control and management. Even though, it is easier to brush it aside saying, these problems can be fixed to have more quality control in place, but I beg to defer. 

In the last 20 years of working with large companies, I have observed that there are certain areas in the system which are like cancers. No matter what one does, it keeps coming back and difficult to get it rid of certain issues.

After seeing so many examples of this fire issue with Samsung, I have started believing that, their system has some cancerous issue as well, which could bring the company down, if not now but tomorrow. 

Do you think Samsung can fix this or do they have a deeper problem ?

Image courtesy:

http://www.motherpedia.com.au/images/directoryimages/69507/samsung_flaming_machine_-_cover_-_motherpedia__large.png

http://money.cnn.com/2016/09/02/technology/samsung-galaxy-note-7-recall/

Descale organisation and reduce compleixty

The common question in the IT organisations of large enterprises is,

"which is the best scaling framework available in the market for us to use? "

Most of the time, when someone asks this question, they are saying, we are doing large programs of work, and it is out of control. Is there a solution to bring it "under control"?

I believe that we should avoid doing multi-year pronged, large programs of work. There are various reasons for this, poor/forced estimation to satisfy the stakeholders to fit into timelines, hand-offs, bottlenecks due to dependencies and in addition to the multi-layered Tayloristic management structure.

Each of the above issues, in turn, pushes the organisations away from agility rather than embracing it.

One of the studies has found that the large IT programs have delivered 56% less value than predicted.

Every step in the large IT programs delivery is riddled with land-mines of complexity. Trying to find a scaling framework to help the organisations walk through these mazes of land-mines with Tayloristic bureaucratic structure is a wrong question to ask.

Instead, one should be asking,

How can we simplify the organisation, reduce complexity and be Agile?

This is where the Large-Scale Scrum (LeSS) framework comes into the picture. LeSS recommends organisations to avoid doing large, multi-site programs. However, if you are already doing it, then LeSS helps in reducing the complexity, descale the organisations while delivering the program.

Finding a scaling solution that suits existing Tayloristic management structure is more like putting a band-aid. It's short term thinking. The long term thinking is to remove the root-causes of the problem that is hurting organisations in addition to delivering the highest value to the customers, maintaining agility.

Courage and agility

I keep hearing the need for "Growth Mindset," "Collaboration," "Empathy," etc. while describing the characteristics of agile teams. However, I rarely see someone highlighting the need for the "courage to speak up" in agile teams.

Every day, I see that

• teams in the discovery workshop know that their estimates are cooked up, but they don't speak up to avoid upsetting the stakeholders
• The leaders know that their teams are not on the right track, but they don't speak up as the teams could screw them during the 360-degree feedback survey
• The teams know that their leaders are micro-managers, but they don't speak up to avoid getting screwed during performance appraisal
• The product owners know that the requirements are not vetted with the end customers, but they don't speak up as it is not tied to their bonuses
• The line managers know that the other departments are causing bottlenecks in delivery, but they don't speak up to avoid pissing off their colleagues
• The offshore teams cannot hear the conversations during their daily scrum over the video conferencing equipment, but they don't speak up to protect themselves from embarrassments
• The onshore teams know that the offshore teams have not understood the user stories, but they don't speak up to avoid hurting their partners

I could keep writing this for another 2 pages. But the bottom line is, courage to speak up and courage to take action is very critical to succeed in agile teams but no one "speaks about it". Isn't it ? 

No matter, how good the teams are in doing their "bubble retrospectives" or setting up colourful Kanban walls, missing out on the courage aspect could derail their Agile initiatives. The courage to speak is the key to open the secret chamber of agility.

P.S: My next Certified LeSS practitioner course in Sydney scheduled March 26th-28th. Seats are getting filled pretty fast and avail early bird discount. Register here.

Tips while setting the targets

I used to work with a large consulting firm before, and it was a tradition to review the status reports of all the deliveries with the "account manager" every two weeks. 

The delivery leads were grilled during the review process on various targets including the Planned vs. actual Velocities and estimations. A happy face at the end of the meeting would imply someone has met their target numbers. 

 The intent of this post is not to discuss the review meetings but more about the "targets." The managers are so obsessed with the numbers that they have forgotten to think about the process, knowledge and wastes in the system. You might be wondering where did this disease of "Management by numbers" started.

Based on my research, it was Alfred Sloan who introduced the phrase "management by numbers."  During his initial days at GM, he couldn't get the hang of the different departments making profits. So, he introduced this cost accounting method by setting the targets. 

During Alfred's tenure, promotion and demotion based entirely on meeting his targets. I can imagine a meeting with Sloan would be similar to the "Status Review" meeting shared before. Even though Sloan's method of setting and verifying the target worked to an extent, it created appalling behavior in the system. 

To achieve the targets, the managers/employees started short circuiting the process, sacrificing the quality and mostly gaming the system. Since Sloan was very clear that managers are only responsible for numbers and need not understand the operations, none of the managers looked under the hood to see what was happening. 

I also believe that "Management by numbers" lead to the existing hierarchical structure as each layer wanted something to protect themselves from the upper layers. Of course, "Tayloristic" thinking has made this structure even worse.  

Even though I am critiquing the concept of "targets," it is not the targets which are bad, but the "bad targets" which creates the sub-optimisation in the system. 

There are a couple of tips to remember while working with the targets:

1. Targets should be set keeping the systems' capability in mind. For ex: if the system doesn't have the ability, then setting a higher target pushes the system more towards gaming. 
2.  It should be co-created with the actors in the system 
3. The targets should enable the system to remove the waste and continuously improve by gaining more knowledge. 
4. Avoid the targets based on "yesterday's weather." It is quite possible that system from yesterday might be carrying too much waste. Setting a future target based on yesterday is like encouraging the system to carry the waste with no continuous improvement. One should be cautious about this. 

Before I end this post, let me ask you this, do you targets at work? What are some of the targets that you are currently working towards ?

The Five relationships for the Product Owner - LeSS

Recently I spoke at the LeSS meet up in Melbourne about the importance and the rationale for the Product Owners(POs) to maintain 5 key relationships.

I was happy with the turnout and the quality of questions that came up during the session. I used the following graphics exploring the the 5 relationships.

Most people already know that PO is accountable for the ROI and the importance of, maintaining the relationship between the stakeholders, customers, and the team. But the importance of managing the relationship between the customers and the team is highlighted in LeSS.

LeSS highlights the difference between prioritization and clarification. One of the LeSS rules is, PO prioritizes the requirements, but clarification is done as much as possible directly between the customers/users and the teams. 

Following graphics represents the above rule:

It is important to remember a few points about the clarifications vs. prioritisation perspective:

• PO is not absolving the complete responsibilities of clarification. Depending on what adds the most value to the teams, PO makes the call whether to get the customers involved or to answer himself/herself with preference to the former.
• PO facilitates the conversation to ensure that teams and customers are thinking in the right direction as per the organizational/customer priorities and ROI. 
• My experience has been that customer involvement would be more during the initial days of the product development as compared to later stages assuming teams have gained maturity. Of course, its based on the context. Having customers/users working directly with the team is always valuable. 

Was Fredrick Taylor a bad man ?

Many times we demonize Taylorism to such an extent that people start believing Taylor was a bad man. 

If we look back into the history, Taylor did introduce the separation of thinking vs. doing, introduced the concept of labor productivity through constant monitoring and efficiency improvement practices. However, these practices worked well in the 1900s due to the prevailing context at that time. 

• Back in the 1900s, the world literacy rate was barely 25% 
• Those days, only 6% Americans graduated, but today it is close to 90% 
• The major tech that was invented was a toggle switch

We need to consider the situation during Taylor's period; he had a big responsibility at hand. I don't think he was in a position to hand over the job of planning and designing bridges (so called Thinking job) to the less literate people. As the less literate people were migrating to the city in search of the job, he wanted to keep them productive by assigning them the "doing jobs." 

Fast forward to 2017; the context is entirely different. 

• The world literacy rate is more than 85%
• More than 80% of Americans graduated last year
• Every day a new invention is transforming lives of people

Bottomline is, the context has changed drastically since the last 100 years, and it is foolishness to apply the best practices of the 1900s in 2017. Some of the Taylorstic ideas that we are still following include:

• Managers are responsible for planning and making high-level decisions. The developers and rest of the crew are responsible for executing the plan.
• Encourage specialization in only one area as though the individual had learning disability (for ex: BAs are supposed to only Analysis and not testing) 
• Individual productivity measurements. 

With so much of progress in science and technology, why are we still following the age old management practices? Could we have done better if we abandoned Scientific management 30 years ago? 

Before I conclude, the question is, Is Fredrick Taylor, a bad man? Or should we hold ourselves accountable for borrowing the best practices from the 1900s in managing 2017 work?

LeSS is Scrum

Large-Scale Scrum(LeSS) is not improved or customized Scrum. LeSS is Scrum. The values, principles and practices associated with the empirical process control which is applied to one team Scrum are used for scaling or should we say de-scaling purposes.

If you know Scrum well, then LeSS would be a cake-walk from "understanding" perspective. However, implementation takes a bit of experience. 

One of the fundamental tenets of LeSS is to stop thinking about "Scaling" work rather start focussing on "descaling" the complexity associated with the organization. 

Descaling complexity in an organisation involves removal of wastes, identification of bottlenecks, creating a learning culture, reduction of queues and removing the hierarchies associated with Taylorism. 

It is not sufficient to know how to do daily Scrum or Sprint retrospectives; it is all about getting deeper insights into Systems Thinking, Queuing theory and Lean Thinking. As one can see in the picture below, the ten principles lay the sound basis to descaling the complexity in the organization.

Need for TQC with Toyota Production System (TPS)

Toyota has become a synonym for quality, and one would find "Lean" related activities borrowed from the TPS all over the place. 

However, one needs to be cautious while adopting TPS just because you want to improve the quality. 

One of the key TPS tools to enhance the quality is "Stop and Fix." As soon as any worker sees a defect, one would stop the line, get everyone involved, fix it before the root-cause analysis. Of course, this is a no-brainer to support how TPS could help to improve the quality.

Here is the primary challenge, for a worker to "see the defect," he/she needs to be trained to identify all sorts of defects. However, Toyota also has admitted that not all of their workers have the ability to catch defects and so, they have implemented TQC in place.

IT organizations trying to adopt the TPS ideas to improve quality should ensure that they have some system in place enabling the employees to identify the defects, without which TPS will be another toolkit. 

Toyota never had plans to create TPS

Toyota Production Systems (TPS) is something that is referred across IT organizations to prove that they are doing something valuable. Nowadays, If you say, you know TPS that means something, isn't it?

Do you know that TPS has never been a planned goal of Toyota? It was an accidental discovery of various ideas as seen by an outsider.

Taiichi Ohno is the most famous name associated with TPS. However, I feel it would be an injustice to TPS if we leave out rest of the employees who worked with him in making it a reality, for eg: Kikuo Suzumura.

A bunch of ideas that took birth in different parts of Toyota, whether it is the pull system or the kanban, all made a difference to the production line and made Toyota famous. This, in turn, attracted many outsiders to collate these ideas to call it TPS. 

You might question, how did they come up with these ideas ?. These thoughts came up mostly because of Toyota's culture of passion for continuous improvement and respect for people. 

Every organization can create their version of TPS provided they have the same underlying forces as Toyota did. 

Which framework is better LeSS or SAFe ?

Pretty much in every meet up I do, or in the LeSS training, one of the audience will have this question 

which framework is good or better?

Even though I had answered such questions in the past, now I feel that

it is totally a wrong question to ask. 

You might want to know, what is the problem with the question?

My answer would be, before asking the above question "good or better framework," one needs to ask, what is needed for our organization to maintain agility while delivering the highest value to our customers. Once you get some answers, then work backswords to identify a framework that fulfill the needs. 

I have googled around and read several comparisons. All of them are comparing the features. For example, one framework is based on Scrum, but the other on XP. One talks about managers and the other as optional. Do you think, reading such tabular comparison helps you to answer your question about agility and delivering value to the customers? I believe, it won't. 

I had shared in my previous articles that, no matter which framework you adopt, it is guaranteed that you will have some outcome. The question is, does this outcome help your organization with agility and delivering value to the customers. Until and unless you practically implement the framework as per the book, one will never know if it works for them or not.

Based on my experience and empirical observation, it is very rare to see large organisations following the rules of the frameworks. As soon as they hit a hurdle with implementation, instead of trying to fix the culture or leadership, they tweak the rules of the framework to suit their context, thus reducing the effectiveness of the framework.

Tell me how many companies in the world are following Scrum by the book ? when I posed this question in my meet up yesterday,

the answer was unanimous: 0%

No matter what how many hours you spend n comparing the frameworks, you would still end up choosing that confirms your biases. You will only look at things that confirm your thinking. That's why I suggest you to stop asking the question which is better but asks

What should I do keep agility and deliver value to the customers ?. 

But don't get me wrong. Some framework is needed to begin the journey, especially for companies at SHU level. Companies at HA or RI level would be comfortable in inventing on their own. But even for SHU level companies, their questions should be focussed towards what is our end goal? How can we be agile? How can we satisfy the customers? 

Birth of LeSS

Many people ask me, how long have you been practicing Large-Scale Scrum(LeSS)? I invariably end up telling this story. 

LeSS framework is not something that is conceived overnight. The experiments that lead to the birth of LeSS started back in 2004-2005. I used to work with Valtech India, and we used to apply mostly iterative and incremental development practices.

I distinctly remember the news about the arrival of Craig Larman, the Chief Scientist of Valtech to our newly built office and coach us. We had moved into this new building of Valtech which had the traditional cubicle structure with distinct separation of cabins for the managers. 

One of the earliest experiments that were initiated was to change the physical structure from cubicles to open space with teams sitting together. Also, managers were encouraged to sit with the teams to participate in process improvement (Gemba Kaizen).

To bring visibility, transparency and improve technical excellence we had setup the red-green screen, a centralized continuous integration server using Cruise control. I had captured some of the experiments and published as an article back in 2006. You can check it out here.

An open space session gathering ideas to improve agility was conducted with more than 200 people, and it is as fresh in my mind as though it happened last week. Other experiments to encourage learning and education included: setting up a library, book reading clubs, the introduction of Causal loop modeling as part of the retrospective.

Nearly 600 experiments were conducted as Craig truly follows the empirical process control through inspection, adaptation cycles. These experiments have been well articulated in the two books mentioned below:

It is also important for me to mention that Craig and Bas were working and trying out various ideas at Nokia Siemens network with large teams. 

In summary, we could say that ideas that lead to the birth of LeSS started decades ago. Probably LeSS could be the only scaling framework that has been built on top of 100s of "published" experiments and in a truly empirical fashion.

If you are keen to learn more and in-depth about the experiments and Large-Scale Framework, please register for upcoming Certified LeSS Practitioner courses.

• Sydney Course: March 26th - 28th 2018 
• Melbourne Course: April 11th - 13th 2018
• Brisbane Course: May 21st - 23rd 2018

Top-down or Bottom-up adoption strategy for LeSS adoption

Adopting a new framework, process, methodology or an idea into a large enterprise requires a strategy. A decade ago, while participating in large-scale agile deliveries, I saw quite a bit of success, and I attributed that to the support from the senior management. 

I was so impressed with the success that, I authored an article about the importance of top-down agile adoption strategy. That is, a strategy that is not only endorsed but has complete support from the CxO or chairman of the company. 

Fast forward, I have realized that top-down strategy is insufficient. I saw two problems going solely with this approach:

1. Any endorsement or support from the top management is taken as a "command" by the rest of the enterprise in a hierarchical org setting. No one at the bottom of the pyramid dares to question, and adoption becomes a tick in the box to please the top management.

During the initial years of my career, while working at the bottom of the pyramid as a developer, I used to look up and used to feel that the CxOs as the most influential people. I used to question many times, why are they struggling to make a simple decision. 

2. However, when I had the opportunity to be a Vice President during my tenure with one of the Big 4 consulting firms, I realized that everyone is equally powerless :-). 

So, it is futile to believe that getting a CxO to endorse a strategy does not mean that everyone will accept the idea with a whole heart. 

If top-down does not work all the time means, should we say bottom-up approach works? 

As we know, a developer or someone at the bottom of the hierarchy could get inspired by an idea, however, it is quite challenging to go through the mazes uphill to get the necessary support in big enterprises.

Keeping the above constraints in mind, Manns and Rising explain,

It is not top-down or bottom-up, but participative at all levels—aligned through a common understanding of a system. 

If you are keen to learn more adoption specifically from the LeSS perspective, please join me in my upcoming trainings, the details are as below:

Sydney Course: March 26th - 28th 2018 

Melbourne Course: April 11th - 13th 2018

Brisbane Course: May 21st - 23rd 2018