Pages

Sunday, July 26, 2020

Newsletter #50: Is it time to ditch Definition of Ready ?

Welcome to newsletter 50.  
 
 



 
Interesting Articles
 
“It's time to ditch Definition of Ready ?"

It is a bit of a controversial article and I have my own views. However, the author seems to share his vows through this article around Definition of Ready. 

As a Product Owner, I needed help from another team. My request was quite simple: to send a file they were already producing over SFTP to a third-party. I added an item to their Product Backlog with all the bells and whistles: title, description, business value and acceptance criteria.
The ticket was refined and planned for the next Sprint. The team contacted me and told me everything was clear. They asked if I could provide the SFTP credentials of the third-party.
I immediately asked the third-party to provide us credentials to the different environments. Unfortunately, the third-party did not respond before the Sprint started.
When I was checking my e-mail in the office on Monday morning, I found out my Backlog Item was removed from the Sprint. I would need to wait another two weeks.
When I asked why they removed it, they answered the ticket did not meet their Definition of Ready and was removed from the Sprint as a result.
Two main arguments are commonly used to support the use of a Definition of Ready:
  1. Making clear to stakeholders what we need from them in order to make Backlog Items clear.
  2. Preventing Backlog Items from being unclear before the team starts working on them.

1. Scrum already prescribes what makes a Backlog Item “Ready” for Sprint Planning

Willem-Jan Ageling pointed out to me that Scrum already prescribes what makes a Backlog Item “Ready”.
Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. — Scrum Guide
In the Scrum Guide it is explicitly stated what makes a Product Backlog Item “Ready”. If the Development Team believes it fits in a Sprint, then it’s ready to be worked on.

2. Product Backlog Items in Scrum already contain enough information to get started

A Product Backlog Item should possess the following information according to the Scrum Guide:
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”. — Scrum Guide

3. Sometimes just a title may be enough to start working on something

Imagine your Sprint has started and someone from the Development Team notices a big production issue. She discusses it with the team and quickly adds a Backlog Item to the Sprint with just a title. She starts working on it immediately and clarifies the description as more information becomes available about the underlying problem.

4. It’s already up to the Development Team to change the Sprint Backlog during a Sprint

You don’t need a Definition of Ready to stop messy and unclear Backlog Items from being added to the Sprint.
Imagine a Sprint has started and somebody wants your team to work on something during the Sprint that is too vague. You don’t need a Definition of Ready to prevent this from happening.
The relevant passage from the Scrum Guide:
Only the Development Team can change its Sprint Backlog during a Sprint. — Scrum Guide

5. Definition of Ready conflicts with Agile way of working

Let’s take a look at the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
With these sentences in mind that capture the essence of Agile, how does a Definition of Ready fit in?

Read the rest of the article here
 

 

"What comes after Scrum? - Ken Schwaber"

Scrum is not the be-all and end-all process for software and product development. As many of you have noticed, it is barely a process, only a framework. You have to provide all the development, management, product management, and people practices.
So, what does Scrum provide? It provides a labeled- environment within which complex development can be successfully managed (where the unknown is greater than the known). Scrum provides containers that allow teams to focus on one aspect of a complex problem  at a time. The containers are short-time boxes so that risk can be managed.
Scrum can be replaced or superseded by anything that also supports its underlying principles:
1. Self-organization – people doing complex work are much more effective organizing themselves and the work than someone who isn’t doing the work.
2. Bottom-up intelligence – figuring out how to do work is a management activity best performed by the people doing the work, since the work is unpredictable, with many twists and turns.
3. Empiricism – it is hard to plan what you don’t know, so we instead see what has been accomplished, and then figure out what to do next. We do this frequently to control risk and determine the best path to our goal.
4. Transparency – we periodically have to know what is actually happening to make effective empirical decisions.
As stated in bible of process control (“Process Dynamics, Modeling, and Control”, Ogunnaike and Ray, Oxford University Press, 1994) , there is no bad process. However, sometimes processes are applied to inappropriate situations. Scrum is an empirical process built on lean principles. It is most appropriate for optimizing complex work.
I welcome anyone who comes up with the next great process, one that does all of the above even better than Scrum. I’m still waiting.

Read the original article here
 

 
Large-Scale Scrum(LeSS)

My recent webinar about  5 unique Things about Large-Scale Scrum 

Check out this  youtube link

 

 

HOW TO AVOID WRITING NEW LEGACY CODE


(Excerpts from Practices of Scaling Lean and Agile  By Larman and Vodde)
 
“We promised this release to our key customer, and the only acceptable commitment from R&D is the first of February,” said an angry email sent by a director to the management of the product group we were coaching. We read it in disbelief and wondered about the only acceptable commitment. We decided to ignore the email—for now— and get back to normal work—coaching a developer in refactoring a legacy component that was hacked together last release to meet that deadline.
Many companies are stuck in a vicious cycle of forced promises and See unrealistic commitments. In today’s time-to-market era, customers force’ them to promise too much. “If you cannot deliver by the end of the year, we will buy from your competitor who will make that promise.”

Sales people or executives could respond by being transparent and by working toward a mutual beneficial long-term relationship (customer collaboration), but instead they check whether the contractual penalty for being late is tolerable (contract negotiation) and reply, “Yes, no problem, we can do it!” After which the same cycle starts within the organization. The executive orders the head of R&D to “do it” and “make it happen” because “it is a customer promise.”


The promise travels through the organizational hierarchy to the developer, who cannot pass it on any further.

How does the developer react? Charles Lecht [Lecht67] already warned us over 40 years ago: The developer will “feel the obligation to respond out of respect, fear or misguided loyalty” and reluctantly commit to the deadline. The developer opens his secret toolbox and does everything possible to make the short-term deadline by using tools such as hardcoding, copy-paste-modify programming, skipping testing, working overtime, and other quality-destroying shortcuts [Schwaber07a]. Nobody notices the use of these ‘tools,’ and so the deadline is made. Management rewards developers for their hard work and applauds their “great teamwork” and “fighting spirit.”

These quality-destroying shortcuts result in bad legacy code, which slows down the development and the organization falls behind its competition. A predictable scenario unfolds. They need to reclaim the market and therefore make new promises, starting the vicious cycle all over again. The technical debt—the legacy code—makes development go slower. The learning debt—lack of renewal in developer skills—compounds this slowdown.
 

 
If you like this newsletter, please share it with your friends. You can subscribe to the newsletter here
 

 
Upcoming Events
 
Look forward to public courses in Brisbane, Melbourne, Sydney, Perth and India in 2020.  Possibly expanding to other countries.


I have started online training for Certified LeSS Basics.  I recently completed a few and would be announcing a few more soon. Keep an eye on this newsletter.


Many might not know that I also offer Certified LeSS Executive trainingThis is specifically for senior leaders who might be interested in learning the intricacies of management and structure to influence the culture. 


Please reach out:  venky at agileworld.com.au for further details.
 


About Empirical Coach

If you are interested in Agile coaching, mentoring and training services, please reach out to me (venky@agileworld.com.au). We have a team of passionate coaches collaboratively working together and could help.


Our team has deep expertise in Agile, Lean, Systems Thinking and Complexity science. We look at challenges from different angles and apply tools from various schools of thoughts. This is different from the cookie-cutter approaches you see around.  We are proud to be different.


I have been deeply involved in many of the initial experiments that lead to the birth of LeSS, one of the countable number of people globally.  

Blog | LinkedIn | Twitter 

Wednesday, July 15, 2020

Newsletter #49: “Special Forces” Innovation: How DARPA Attacks Problems

Interesting Articles
“Special Forces” Innovation: How DARPA Attacks Problems

Over the past 50 years, the Pentagon’s Defense Advanced Research Projects Agency (DARPA) has produced an unparalleled number of breakthroughs. Arguably, it has the longest-standing, most consistent track record of radical invention in history.

Its innovations include the internet; RISC computing; global positioning satellites; stealth technology; unmanned aerial vehicles, or “drones”; and micro-electro-mechanical systems (MEMS), which are now used in everything from air bags to ink-jet printers to video games like the Wii.

Though the U.S. military was the original customer for DARPA’s applications, the agency’s advances have played a central role in creating a host of multibillion-dollar industries.
The DARPA model has three elements:

Ambitious goals.

The agency’s projects are designed to harness science and engineering advances to solve real-world problems or create new opportunities. At Defense, GPS was an example of the former and stealth technology of the latter. The problems must be sufficiently challenging that they cannot be solved without pushing or catalyzing the science. The presence of an urgent need for an application creates focus and inspires greater genius.

Temporary project teams.

DARPA brings together world-class experts from industry and academia to work on projects of relatively short duration. Team members are organized and led by fixed-term technical managers, who themselves are accomplished in their fields and possess exceptional leadership skills. These projects are not open-ended research programs. Their intensity, sharp focus, and finite time frame make them attractive to the highest-caliber talent, and the nature of the challenge inspires unusual levels of collaboration. In other words, the projects get great people to tackle great problems with other great people.

Independence.

By charter, DARPA has autonomy in selecting and running projects. Such independence allows the organization to move fast and take bold risks and helps it persuade the best and brightest to join.

The work in Pasteur’s Quadrant doesn’t exist on road maps. It results in discoveries that upset the current trajectory and can destroy an existing business. Expecting the research organization executing against the road map to simultaneously deliver breakthrough innovations that challenge the road map is unrealistic. Instead, companies should create a small, dedicated independent organization to work in Pasteur’s Quadrant. They should take to heart the lesson that the U.S. government learned from the launch of Sputnik: The best way to prevent surprise is to create it. And if you don’t create the surprise, someone else will.

It is a pretty lengthy article filled with a lot of good info.. 

Read the rest of the article here


"THE CLOTHESLINE PARADOX"


TIM O'REILLY is the founder and CEO of O'Reilly Media, Inc., a leading computer book publisher. O'Reilly Media also hosts conferences on technology topics, including the O'Reilly Open Source Convention, the Strata series of conferences on big data, and Tools of Change for Publishing. O'Reilly Media's Maker Media unit publishes Make Magazine and operates Maker Faire, the world's largest gathering of DIY hardware enthusiasts and entrepreneurs. O'Reilly AlphaTech Ventures is a leading early-stage venture capital firm.

I've been thinking a lot lately about a piece I read in Stuart Brand's, CoEvolution Quarterly back in 1975. It's called the "Clothesline Paradox." The author, Steve Baer, was talking about alternative energy.


The thesis is simple: You put your clothes in the dryer, and the energy you use gets measured and counted. You hang your clothes on the clothesline, and it "disappears" from the economy. It struck me that there are a lot of things that we're dealing with on the Internet that are subject to the Clothesline Paradox. Value is created, but it's not measured and counted. It's captured somewhere else in the economy.

Wednesday, June 24, 2020

Newsletter # 48: List of popular books


Interesting Articles
35 Tools for Brainstorming and meeting

This post provides a comprehensive list of 35 tools for brainstorming and meetings.  I liked the way they categorise them and show the evaluation criteria.

I have copied few of them here..

Our Top Recommended Tools for Online Brainstorming and Decision Making in Meetings

After all that, here are the products that stood out from the crowd. We recommend adding one of these to your online meeting toolkit.

#1 GroupMap or Stormz

We loved the ease of use, attractive design, clarity of the process, and excellent reporting provided by our top recommendaitons.
Both GroupMap and Stormz offer a free trial and a monthly subscription option. Occasional users probably won't experience big differences between these platforms. Both are easy to use and generate really useful results. Lucid Meetings customers should consider Stormz, using our integration to ensure the results from your brainstorming session get stored with your other meeting records.
Powernoodle and MeetingSphere are also excellent choices, especially for enterprises and organizations seeking a product that will support a rich virtual facilitation practice over time. Many of the professional facilitators certified by the IAF swear by MeetingSphere.

#2 Google DocsMicrosoft Word Live, or Etherpad

Brainstorming in a co-edited document worked better than we expected, and starting with a product everyone already knows how to use eradicated the learning curve. These are also the only viable option for those of you with accessibility requirements. Finally, free is a very good price!
That said, these products were harder to use with large groups, as participants quickly get concerned about writing over each other's contributions. Importantly, these products do nothing to support your process, so all of the organization and facilitation is entirely up to you.
Free collaborative editors are our top-pick for small teams or traditional facilitators who need to prioritize easy technology instead of high-volume replies or any decision reporting support.

#3 IdeaFlip or Jamboard

Recommended with reservations.
These products support our test process and offer a good alternative to development teams. But they lack the flexibility, power and finesse of our top choices, and didn't provide the reports we were looking for.

#4 Mural or Miro

Recommended for designers and others managing work visually.
Mural and Miro fully support our process as part of a larger, deluxe visual management platform. Neither platform is free nor lightweight, but both can be an excellent choice for teams who benefit from visual collaboration both during and outside of meetings.
In 2020, Mural is our top pick for online design thinking and visual facilitation.

Check out the rest of the tools here


List of Good Books 

Came across this post which I found has some good list of books. Hope you like it...


 



Large-Scale Scrum(LeSS)

My recent webinar about  5 unique Things about Large-Scale Scrum 

Check out this  youtube link





Check out rest of the newsletter here








Sunday, May 17, 2020

Newsletter #47: Toyota Production System: An emergent system


Read this complete newsletter here


Interesting Articles
 
Toyota Production System: An emergent system

Recently, a short post on LinkedIn about Toyota Production System attracted netizens attention. Here is the actual post

During the earlier days, neither Taiichi Ohno or Shigeo Shingo or for that matter, anyone in Toyota had a vision of Toyota Production System.

As and when they came across challenges, they addressed by applying a set of rules and principles to create a flow and continuously improve.

More importantly, Taaichi Ohno focused on changing the underlying thinking of employees rather than purely building the product. This aspect of building employee's thinking seems to be the key differentiator between Ohno and Honda.

When you look around in organisations, there is more focus on processes, frameworks rather than actually uplifting employees ability to think.



Thought would elaborate this a bit more for the readers of this newsletter.   Fundamentally, the Toyota Production System (TPS) was not a designed system. It was an emergent system.  Neither Ohno nor other leaders at Toyota sat in an Air-conditioned room and drew it on the whiteboard.  Various tools and techniques emerged while trying to solve the problem. It is not the tools that are important, but the thinking that leads to the creation of the tools.

Even though the lean house distils into 2 pillars, respect for people and the continuous improvement, I still believe this is in retrospect.  Personally, I believe that Ohno and others were keenly focused on being at the "Gemba", ensuring that the value is delivered to the customers, teaching the employees to think rather than a specialist knowing everything, respecting the people by helping them on the ground rather than reviewing the reports.

Toyota faced several challenges both good and bad. The second world war pretty much gutted them. The survival made them to come up with practices to find a way to be productive with limited resources. The Korean war, created a good problem as they had more orders. They decided to be productive without hiring more people. The constraints of the war and economies of scale enabled the leaders in the organisation to be innovative.

I don't know if people know this, Toyota in-fact used to have a month-long batch cycle. Leaders called out the in-efficiency associated with the accumulated inventories and the variable queues. So, during each stage and in every different factory, the ideas emerged. It is the culture and the thinking that encouraged the people to think independently lead to the birth of the TPS. This was an emergent idea rather than a designed idea.

The introduction of the ideas was incremental rather than big-bang. The kanban system started only in a small group and within one assembly line. When it worked well, then it was introduced to others as they had dependencies as part of the manufacturing. 

Coming back to the modern world, in the 21st century, most of the western world has no dearth for money nor any constraints. This is not giving enough challenge for the organisations to make employees think.  If they want something, they buy a tool or a process or a framework in the market. As long as the organisations don't enable people to think, there will never be another Toyota Production System.


Further reading: The dagger and gift: Impact of Korean war on Japan

The origin of Lean Production
 

 
Interesting article: Why Managers Holding People Accountable Is A Waste Of Time, And What To Do Instead 

Link to the original article

Key snippets from the above article

How often do you hear yourself or someone else complain that this person or that person isn’t “being held accountable?” Or find yourself mustering up the gumption to “hold that person accountable?” It’s really a fool’s errand. At the end of the day, personal accountability is the only real accountability. So that means you can’t really hold other people accountable.

Own your role as a manager. When you take on the role and responsibility of being a manager of others, you have to own what happens on your watch. When a manager points the finger at their employees, they instantly lose credibility with their leadership and their team.

Help people face the reality of the outcomes they are producing. Instead of trying to hold employees accountable, focus on helping them deal with the reality that they are creating. Avoid the lectures that start with a list of “shoulds.” You should do this and you should do that only makes the person feel nagged or lectured. It rarely leads to higher levels of accountability.

Make it safe to surface issues early and often. As a manager, it’s critical to make sure people feel safe to discuss and learn from mistakes. Most issues get blown way out of proportion or are allowed to fester for so long the damage is irrevocable.

 

 
Interesting article: Transforming from Projects to Products

Link to the original article

Key snippets from the above article
 

Agile Transformation is about moving from Management to Leadership

Peter Drucker is an inspiration here, traditionally we put so much effort into getting things right, to be more efficient, or to do this, by that deadline, that we forgot to ask if what we are  doing is bringing value. We put all our emphasis on measuring and monitoring effort, or efficiency, rather than assessing if we are achieving our goal.
If you are considering an Agile Transformation it is likely that you have discovered that efforts to 'manage' projects are leading to the wrong results and the focus needs to move from a focus on effort to a focus on value. To set a direction and 'lead' the way in product development.  Try to stop measuring output and to start measuring outcomes.
 

Upcoming Events
 
Look forward to public courses in Brisbane, Melbourne, Sydney, Perth and India in 2020.  Possibly expanding to other countries.


I have started online training for Certified LeSS Basics.   If you or your friends are keen, feel free to reach out to me or check this link


Many might not know that I also offer Certified LeSS Executive trainingThis is specifically for senior leaders who might be interested in learning the intricacies of management and structure to influence the culture. 


Please reach out:  venky at agileworld.com.au for further details.
 


About Empirical Coach

If you are interested in Agile coaching, mentoring and training services, please reach out to me (venky@agileworld.com.au). We have a team of passionate coaches collaboratively working together and could help.


Our team has deep expertise in Agile, Lean, Systems Thinking and Complexity science. We look at challenges from different angles and apply tools from various schools of thoughts. This is different from the cookie-cutter approaches you see around.  We are proud to be different.


I have been deeply involved in many of the initial experiments that lead to the birth of LeSS, one of the countable number of people globally.  

Blog | LinkedIn | Twitter 



Tuesday, May 05, 2020

Newsletter #46: Myth of Servant Leadership

Interesting Articles
 
Systems Thinking in the context of COVID
 
Everyone seems to be impacted due to COVID in someways or the other.  Whatever is happening around will have a deep and long-lasting impact on societies, technologies and the economy.

We could see many large companies struggling to survive and potentially could go bankrupt. At the same time, I am also hearing the government rescuing the economy in different ways. It is a piece of good news and a great gesture by the governments to jump in to save many drowning companies, it is also important to see if it is not "shifting the burden".

If you have read Senge's Fifth Discipline, you would have read about "Shifting the burden" Archetype. It usually begins with a problem symptom and someone attempts to rescue it.  This, in turn, gives an immediate relief however, it won't address the root cause of the problem. The problem stays hidden. The survivor is re-inforced with the belief that rescuer is always there to protect. This keeps weakening the system until it reaches point of no return.

Applicability in the typical product development scenario 

Here is a wonderful snippet from Senge

“Crisis heroism”: When a crisis (such as delays in a product launch) hits, the “crisis” manager is given enormous flexibility to “do whatever it takes” to get the product out. Ordinary roadblocks and formalities are swept aside. All this comprises the upper, symptom-correcting loop: the product is launched on time, and the crisis manager is touted as the hero of the day.

Meanwhile, several people have suggested the more fundamental solution of the bottom loop: redesigning the entire project management system, and rethinking the ordinary roadblocks and formalities. But this strategy would take longer, and less attention is given to it, so it has less effect on the problem symptom.”

“Most cases of “crisis heroism” include an addictive side effect: People see that if they want to be recognized for an accomplishment, they’ll have to be “heroes,” too. Gradually, the company becomes addicted to “heroically” creating crises at the expense of making fundamental long-term changes.”


Now coming back to the current COVID situation, if the government and the organisations jump into rescue everything without thinking through, they are just shifting the problem and creating an addictive behaviour which is harmful to the economy in the long run.


Further reading: https://blog.iseesystems.com/systems-thinking/shifting-the-burden/
 

 
Interesting article: Myth of Servant Leadership 

https://www.academia.edu/14264417/The_Myth_of_Servant_Leadership

Key snippets from the above article

Servant Leadership (S-L)

According to Larry Spears, a chief advocate of S-L who is responsible for marketing Greenleaf s ideas, the concept of S-L came to Greenleaf upon reading Hermann Hesse's short novel.  Journey to the East.

Hesse's story is an account of a mythical journey by a group of people on a spiritual quest where the recognition of the true leader of the group takes place as a result of his acts of service and self-sacrifice for the benefit of the whole group. As Spears tells it, upon reading this story, it seemed suddenly clear to Greenleaf that a great leader is first experienced as a servant to others, and this simple fact is central to his or her greatness . . . true leadership emerges from those whose primary motivation is a deep desire to help others(3).

Accordingly, for those who adopt its basic tenets, it means developing an overall attitude toward leadership that entails putting the needs of the company and employees first. It means seeing yourself foremost as a steward (Block) of the organization's mission and goals and then acting as a leader to help others coUaborativelyachieve those goals. Since its language explicitly promotes an approach to leadership that is essentially altruistic and idealistic, many proponents think it signals a turn toward the spiritual search in contemporary managerial practices 


The argument against S-L seems to be as follows:

The term servant connotes a subjugation of an existential subject that is dependent upon the presence of a master for his/her social location and organizational life. The term servant thus represents a state of submission, complete with various degrees of oppressive ramifications and power imbalances.

"To - serve" means to be self-sacrificing. The act of serving thus makes the organizational member subject to the whims and/or dictates of a higher order of discursive structures. To counteract this negative connotation of the term servant, Greenleaf paired it with the term leader, which entails and authorizes its opposite-the masterful position. The word servant thus inhibits whatever negative connotation leader evokes and conversely(Forward 145-165). From a semiotic point of view, the terms are mutually constraining, rhetorically. When organizational leaders attempt to implement this fluctuating logic within everyday organizational practices, it produces corresponding shifts in the discursive rules of the game 


Read rest of the newsletter here



If you like this newsletter, please share it with your friends. You can subscribe to the newsletter here
 

 
Upcoming Events
 
Look forward to public courses in Brisbane, Melbourne, Sydney, Perth and India in 2020.  Possibly expanding to other countries.


I have started online training for Certified LeSS Basics.   If you or your friends are keen, feel free to reach out to me.


Many might not know that I also offer Certified LeSS Executive trainingThis is specifically for senior leaders who might be interested in learning the intricacies of management and structure to influence the culture. 


Please reach out:  venky at agileworld.com.au for further details.
 


A bit about Empirical Coach

If you are interested in Agile coaching, mentoring and training services, please reach out to me (venky@agileworld.com.au). We have a team of passionate coaches collaboratively working together and could help.


Our team has deep expertise in Agile, Lean, Systems Thinking and Complexity science. We look at challenges from different angles and apply tools from various schools of thoughts. This is different from the cookie-cutter approaches you see around.  We are proud to be different.


I have been deeply involved in many of the initial experiments that lead to the birth of LeSS, one of the countable number of people globally.  

Blog | LinkedIn | Twitter 



Sunday, March 15, 2020

Newsletter #45 : Role of a Scrum Master in LeSS

Lean/TPS

Toyota Production System: Respect for People
 
As many might already aware, Toyota Production System was not a planned design. It was created in response to the need to survive the world war and to improve the profitability in a low demand environment.  The variable demand created a lot of waste due to unavailability of tools, skills and methods.

In the whole process of elimination of wastes, focus on quality lead to the discovery of ideas like JIT and in-turn kanban. However, Toyota also realised that without respect for people, things will fall apart.

So, if you are interested in applying the ideas from Toyota Production system, Kanban, WIP limits, etc form the tools part and their foundation lies in the respect for people.
As per the book "Scaling Lean and Agile Development" 

Broadly, the global or system goal of lean thinking at Toyota is to go from “concept to cash”  or “order to cash” as fast as possible at a sustainable pace— to quickly deliver things of value (to the customer and society) in shorter and shorter cycle times of all processes, while still achieving highest quality and morale levels. Toyota strives to reduce cycle times, but not through cutting corners, reducing quality, or at an unsustainable or unsafe pace; rather, by relentless continuous improvement, that requires a company culture of meaningful respect for people in which people feel they have the personal safety to challenge and change the status quo.

In the product development frameworks like Scrum, LeSS the respect for people is created through Servant leadership and Self-Management principles.

Continuous improvement and Respect for people are the two pillars of the Toyota house. Continuous improvement culture cannot survive without respecting the people. Respecting the people doesn't mean get along without causing any friction and not about following the orders. It is about treating people as whole and complete rather than a transactional relationship. Respect for people is to create an environment for people to use their complete mental ability to succeed, learn and grow.

My observation in organisations has been to use words like Kaizen(continuous improvement) but without any focus on respect for people.


Further reading: https://less.works/less/principles/lean-thinking.html
 

 
Interesting article: Why Net Promoter Score(NPS) is past it's prime 

https://www.strategy-business.com/blog/Why-Net-Promoter-Score-is-past-its-prime?gko=dc66a

Key snippets from the above article

The Net Promoter Score (NPS), which has long been used to measure the loyalty of firms’ customers, is under fire for becoming the false god of corporate America. In a searing article, the Wall Street Journal last week labeled NPS “a dubious metric” — one that is routinely cited by CEOs in earning calls and that somehow, magically, never declines.
There are at least three big reasons why.
1. NPS misses the employee connection. NPS says nothing about employee experience. What good is a figure that shows how many customers would recommend your company versus how many are unhappy if your employees — your prime ambassadors to customers — are unhappy themselves? If you’ve ever encountered a surly store associate or a hostile customer-service rep (and I know you have), you intuitively get the connection between customer experience (CX) and employee experience (EX).

2. NPS is obsolete because so much has changed. Since the introduction of NPS, customers’ expectations have soared and companies’ access to information about them has increased dramatically. Today, consumers expect next-day delivery of online purchases — with tracking and free returns. They use social media to publicize their favorite companies and brands, and excoriate those that deliver bad experiences.
3. NPS is a backward-looking “point in time” metric. Today, we have the tools to run dynamic, “living” metrics that spin up virtuous circles of benefits and keep them spinning.


Read the complete article here

 
Interesting article: Why great employees leave great cultures?

https://hbr.org/2018/05/why-great-employees-leave-great-cultures

Key snippets from the above article

Culture is often referred to as “the way things are done around here.” But to be useful, we need to get more specific than that. I’ve been working in HR for over twenty years, and the best companies I’ve worked with have recognized that there are three elements to a culture: behaviors, systems, and practices, all guided by an overarching set of values. A great culture is what you get when all three of these are aligned, and line up with the organization’s espoused values. When gaps start to appear, that’s when you start to see problems — and see great employees leave.
These gaps can take many forms. A company might espouse “work-life balance” but not offer paid parental leave or expect people to stay late consistently every night (a behaviors-system gap). You might espouse being a learning organization that develops people, but then not give people the time to actually take classes or learn on the job (system-behaviors gap). Maybe your company tells people to be consensus-builders, but promotes people who are solely authoritative decision makers (behavior-practices gap).
Gaps like these are never solved by turning culture over to a Chief Culture Officer or pulling together culture committees.
 
How, then, do we repair a flagging culture? A place to start is by reviewing the behaviors, systems, and practices in place in your company.

Behaviors

A common culture-building practice is the creation of value statements. But the real test is how leaders behave; how they enact these values, or don’t. People watch everything leaders do. If leaders are not exhibiting the behaviors that reflect the values, the values are meaningless.

Systems

Every process that is created, every system installed, every technology that is used, every structure that is designed, every job title that is given will reinforce or dilute the culture.
 

Practices

Practices include everything from company events, running meetings, feedback processes, to how decisions are made.
Do you have repeatable decision-making processes in place? Are meeting participants expected to be collaborative and consensus-driven, or is some conflict OK? What should managers talk about in performance reviews?
Practices need to change as the company changes — as it grows, reorganizes, or faces new threats. Once-useful practices can quickly become stale, meaningless, or even counter-productive. If the original intent of an off-site retreat was to help teams bond, what needs to shift now that the company has tripled in size?

Read the complete article here
 

 
Systems Thinking

A system is made of two or more parts. As we know a system is a continuum that is each system is hidden within a larger system and also, hides smaller systems. The idea of the system itself is based on our mental model. Most of the organisational system that we tend to address are made of both humans and technical interfaces.

Meadows and many thought leaders say the system is defined by the boundary we draw. However, the boundary is mostly a virtual boundary we draw to focus on a particular problem.  The boundary itself is challengeable as it is influenced by our mental model of the world.

When we tend to address the problems in the organisational systems, we tend to believe we know the answers or solutions. However, we forget that our solution is based on a certain mental model of the organisation.  Then the question is, how do you validate your mental models?  The best way is to expose it to the outside world and get it validated. This is where the culture of transparency and safety comes into the picture. I call this a foundation of everything at work. 
Our ability to achieve the results we truly desire is typically eroded when we hold thoughts and feelings that:
  • Our beliefs are the truth
  • The truth is obvious
  • Our beliefs are based on real data
  • The data we select are the real data
In my LeSS trainings, I use the Causal Loop modelling(Systems Modelling) as a way to expose the mental models of individuals to get it validated. Of course, there are various other tools that could be used.   It is important to ensure that models are exposed and shared with each other while making the decisions. In fact, many of the organisational visioning and discovery exercises are supposed to be the platform to share the mental models. However, these exercises fail miserably when there is no safety net and still run top-down.

Ladder of inference is another tool..

Below is excerpt from this wonderful article about mental models

The ladder of inference is a tool, first developed by Chris Argyris, that provides a structured way for us to reason as to why we don’t usually remember where our deepest attitudes or deep-seated behaviours came from.  These may include fear of the unknown or of something new.  Fear of trusting persons.  Fear of believing someone other than themselves would look out for their best interests.  The data is long lost to memory, after years of inferential leap.  Before long, we come to think of our longstanding assumptions as data, but we are several steps removed from data.

The Ladder of Inference describes the automatic thinking process that we all go through, usually without even realizing it, to get from a fact to a decision or action. The thinking stages can be seen as rungs on a ladder
Using the Ladder of Inference
You can’t live your life without adding meaning or drawing conclusions. It would be an inefficient, tedious way to live. But you can improve your communications through reflection, and by using the ladder of inference in three ways:
 Becoming more aware of your own thinking and reasoning (reflection);
 Making your thinking and reasoning more visible to others (advocacy);
 Inquiring into others’ thinking and reasoning (inquiry).


Fascinating quote 

We don’t see things as they are, we see them as we are. – Anais Nin
 

 
Large-Scale Scrum(LeSS)

Role of a Scrum Master in LeSS
 
Scrum Masters are responsible for a well-working LeSS adoption. Their focus is on the Teams, Product Owner, organization, and development practices. A Scrum Master doesn’t only focus on a team but also on the overall organizational system.
A Scrum Master is a dedicated full-time role. One Scrum Master can serve 1–3 teams.
The initial focus of a Scrum Master towards the team(s) is high, but it should decline over time. When the teams are formed, the Scrum Master spends a lot of effort educating and coaching the team(s) in self- management, inter-team coordination, and increased shared responsibility. Over time, the team(s) rely less on their Scrum Master as they take on all responsibility by themselves.
The maturing of teams is one reason many Scrum adoptions opt for part-time Scrum Masters. But in LeSS, the Scrum Master isn’t a part-time role. When the Scrum Master’s first Team has matured, then she may take up another team—in fact, up to three. Being a Scrum Master for multiple teams automatically shifts focus to the bigger picture of the organization and the Product Owner.
 
LeSS recommends the following five tools for Scrum Master
 
  • Question  As a Scrum Master, you act as a mirror to everyone to help them reflect and improve.
  • Educate  As a master of Scrum, you have a deep understanding of Scrum and need to help the team understand why Scrum is the way it is.
  • Facilitate  Show the teams how to do LeSS events, and have productive conversations by facilitating them.
  • Actively do nothing   You need to create space for people to take responsibility. 
  • Interrupt   Teams need to learn by themselves but when things do get out of hand, then you interrupt to avoid irrevocable damage.

Ref: Large-Scale Scrum

 
If you like this newsletter, please share it with your friends. You can subscribe to the newsletter here
 

 
Upcoming Events
 
Look forward to public courses in Brisbane, Melbourne, Sydney, Perth and India in 2020.  Possibly expanding to other countries.


Many might not know that I also offer Certified LeSS Executive trainingThis is specifically for senior leaders who might be interested in learning the intricacies of management and structure to influence the culture. 


Please reach out:  venky at agileworld.com.au for further details.
 


Sunday, March 01, 2020

Newsletter #44: Lean, Systems Thinking and Other articles


Interesting Articles
 
Lean

Push or Pull: Origins and further details

If you have heard about Lean, you would have heard about the Pull system. Taiichi Ohno is considered as the father of the "Pull" system. The story goes, Ohno got influenced with the American Supermarkets, where the customer pulls the needs and in-turn signalling the order creation.

Since the kanban system was also originated at Toyota, and so, it became a synonym for the pull system. However, the concept of Pull system itself is much broader than kanban. Kanban system has it's own limitations.

The Pull system needs to be studied in a broader perspective.

Taking the original idea of a superstore, customers pulling the items from the aisles signals the procurement. This in-turn signals the production of the new items.  This signalling (kanban) mechanism, controls how many items need to be to released in the next batch. This control of production is nothing but the WIP limit.  WIP plays a crucial role in controlling the variability, thus increasing the predictability.

However, in the Push system, the products are manufactured out depending on the demands seen in the past. Accuracy of the prediction controls the manfucaturing.  Push system cannot handle the variability well unless a large buffer is kept aside or a system to improve the accuracy of predictability is created, which is challenging in a complex system.

Further reading: https://blog.trestlescs.com/what-is-pull-planning

https://edgeperspectives.typepad.com/edge_perspectives/2005/10/from_push_to_pu.html
 

T-shaped skills and one-piece flow

One-piece flow goal is achieved when the work flows like water from one end of the system until it's delivered.  In large organisations, one-piece flow is difficult but not impossible.  The major challenge in creating the flow is variability.  There are many reasons for variabilities, and one important reason is the individual capacity.

One of the ways, Toyota tackled this challenge the flow issue is by creating generalised specialists. If someone has obstacles, the others in the queue can step-in and help to remove the roadblock.  However, when this idea was introduced at Toyota, there was a d

At Toyota, when a new idea hits a roadblock, it is the leaders and managers, who will lead by example by joining the team. 

In most organisations, the lean initiatives fail as they copy only the tactical practices rather than the cultural aspects like leaders as teachers.
 

Systems Thinking

Systems Thinking and its uses

 
It is essential to understand the distinction between System and Systems Thinking. As per Meadows  A system* is an interconnected set of elements that is coherently organized in a way that achieves something. If you look at that definition closely for a minute, you can see that a system must consist of three kinds of things: elements, interconnections, and a function or purpose.

Based on the above definition, Systems Thinking is about understanding the elements, interconnectedness to achieve the purpose. If you want to call yourself as a Systems Thinker, probably this is the best place to start to focus while understanding the system.

In a complex system, it isn't straightforward to understand the elements and relatedness without being part of the system. This is one of the reasons that, a real systems thinker, is one who knows how to get the elements involved in deciphering the system (assuming we are dealing with socio-technical or social systems like organisations, societies, etc.) while solving the problems. 

How can Systems thinking help organisations:

1. It enables the people to focus on the interconnectedness and itself impact on the emergent behaviour
2. Any recurring problem is a symptom of a systemic problem that is hidden beneath the surface
3. Looking at long term cause-effect analysis and strategies 
4. Improving Collaboration increased shared language
5. Continuous improvement, respect for each other and being humble as there are no experts on a system
6. Avoid jumping into conclusions and getter deeper understanding of the unintended consequences 

When elements are not understood or identified, any improvement leads to local optimisation or unintended consequences. From the practical application point of view, when you are trying to solve a specific issue at work, one needs to consciously include the people who like the idea and who have differing opinions as well. 
 
Will try to write more and practical applications of Systems Thinking (ST) in the future newsletters...


You can read rest of the articles here and subscribe to my newsletter using this link




Tuesday, February 04, 2020

Newsletter #43 : Taiichi Ohno and the Chalk Circle

Interesting Articles

Taiichi Ohno and the Chalk Circle

In “The Toyota Way ” and “The Toyota Way Fieldbook” Jeffry Liker describes “standing in the chalk circle.”

This, of course, is a reference to a legendary exercise where Taiichi Ohno would stand a manager in a chalk circle drawn on the shop floor. His direction would be simple: “Watch.”

Several hours later, Ohno would return and ask “What do you see?”

Usually, Ohno had spotted something earlier and wanted the manager to learn to see it. So if the reply to “What do you see?” was something other than what Ohno had already seen, his response would be “Watch some more.”

This would continue until the manager saw the same problem Ohno had seen.

Sources:
http://theleanthinker.com/2007/07/09/the-chalk-circle/

https://www.allaboutlean.com/chalk-circle/



Just-in-time:  The Story, the misconceptions and the real story 


How was it born?
This was slightly more than ten years after World War II, and Japan was still struggling to develop from the depth of post-war poverty. During that time, Japan regularly sent their managers and engineers to the United States to learn whatever they could from American manufacturers. The CEO of Toyota Motor Corporation, Kiichiro Toyoda, had travelled to America to tour around the Ford’s factory before the war, and was especially eager to learn from the American automotive industry. He returned to Japan with an understanding of conveyor-fed lines, a key element to Ford’s mass production system. He intended to implement the new technology on his own automobile factories.
However, Toyota faced some challenging obstacles. Factories in Japan had less floor space than American counterparts, so he could not simply copy Ford’s layouts. Another problem was the supply of raw materials. Although the entire world suffered from the Great Depression of the 1930s, Japan was far worse off than the United States.
Kiichiro therefore adapted Ford’s methods of supplying the manufacturing lines. Rather than stockpiling huge quantities of materials, Toyoda provided each manufacturing process with small amounts, often saying just ahead of the production schedule. The practice of providing small, frequently replenished quantities to a factory process is the predecessor of “Just-in-time-manufacturing”.

However,  JIT will not work, if there are no materials available as and when needed.  This is where the Kanban system was developed to address the issues that could cripple JIT.

However, Various companies  somehow termed  JIT  into Zero Inventory system(ZIPS)

Robert Hall, one of the first American Authors popularising ZIPS was not intended to say that you can run a production system by zero inventories.  Neither Ohno mentioned it as well.   The intent was more to encourage people for continuous improvement.


Ohno clearly articulated that
Kanban is a tool for realizing just-in-time. For this tool to work fairly well, the production process must be managed to flow as much as possible. This is really the basic condition. Other important conditions are leveling production as much as possible and always working in accordance with standard work methods.

Trying to do Kanban without any context of JIT or the continuous improvement is as good as doing any random things with a Japanese name.




Local Optimisation problems 
“Everyone is doing their best yet overall systems throughput is degrading. How can that be?” This is the paradox of local optimization—when a person or departmental decision maker optimizes for the local view or self-interest. The party making the decision frequently believes they are making the best decision, but because ‘best’ is a local optimization, in fact, it sub-optimizes overall system throughput. This is a result of “silo mentality,” misunderstanding, fear, limited information, delayed feedback, ignorance, careerism, avarice, and other common organizational learning disorders.
In lean thinking and agile methods, the focus is on global systems goals: Deliver value fast with high quality and morale—global optimization. Try to consider decisions in light of this goal. To develop and “optimize the whole” culture, challenge all decisions and policies with the question:
Does this decision or policy focus on delivering value to the external customer fast, or does it focus on the interests of a department, person, internal policy/practice, or rare case?
In Scrum, the Product Owner is responsible for choosing high-value goals that could lead to potentially shippable product (at the end of the iteration) and that maximize return on investment and delight the customer, while maintaining a sustainable pace and high engineering quality. That explicit Scrum goal is meant to orient the system toward global rather than local optimization.



Speaking at Scrum Australia 2020 about the LeSS ideas that confront organisations

Looks like I have been selected to be one of the speakers for the Scrum Australia 2020 conference.

Here is the gist of my thinking for the conference:

Large-Scale Scrum is based on several thought-provoking concepts and ideas, that challenge the existing organisational status quo. However, these challenges sometimes are met with resistance from organisations, who resist adopting the ideas from LeSS. During this session, you will learn various ideas suggested by LeSS, and why organisations resist them.
During the last several years of coaching and consulting, Venky realised several ideas from LeSS inherently challenged the status quo of current organisational design and thinking. During this talk, he would like to share his interesting findings.
Some ideas that he found profoundly challenging the current system include:
1. Owning vs Renting the idea
2. Systems Thinking over linear thinking
3. Product Definition vs projects/programs
4. Managers as teachers vs Traditional management thinking
5. Role of a PO in connecting the teams with customers
6. Decentralised coordination techniques  vs centralised meetings

Let me know if I need to cover any other ideas under this title.


LeSS : Feature Teams
Feature teams are not a new or ‘agile’ idea; they have been applied to large software development for decades. They are a refinement of cross-functional teams, a well-researched proven practice to speed and improve development. The term and practise was popularized at Microsoft in the 1980s and discussed in Microsoft Secrets [CS95]. Jim McCarthy [McCarthy95], the former development lead of Visual C++, described feature teams:
Feature teams are about empowerment, accountability, identity, consensus and balance...
Empowerment—While it would be difficult to entrust one functional group or a single functional hierarchy, such as Development, for instance, with virtually absolute control over a particular technology area, it’s a good idea to do that with a balanced multi-disciplinary team. The frontline experts are the people who know more than anyone else about their area, and it seems dumb not to find a way to let them have control over their area.
Accountability—... If a balanced group of people are mutually accountable for all the aspects of design, development, debug- ging, QA, shipping, and so on, they will devise ways to share critical observations with one another. Because they are accountable, if they perceive it, they own it. They must pass the perception to the rest of the team.
Identity—... With cross-functional feature teams, individuals gradually begin to identify with a part of the product rather than with a narrow specialized skill.
Consensus—Consensus is the atmosphere of a feature team. Since the point of identification is the feature rather than the function, and since the accountability for the feature is mutual, a certain degree of openness is safe, even necessary. I have observed teams reorganizing themselves, creating visions, reallocating resources, changing schedules, all without sticky conflict.
Balance—Balance on a feature team is about diverse skill sets, diverse assignments, and diverse points of view.

A common misunderstanding is that each feature team member must know everything about the code base, or be a generalist. Not so. Rather, the team is composed of specialists in various software component areas and disciplines (such as database or testing). Only collectively do they have—or can learn—sufficient knowledge to complete an end-to-end customer feature. Through close collaboration, they coordinate all feature tasks, while also—an important point— learning new skills from each other, and from extra-team experts. In this way, the members are generalizing specialists, a theme in agile methods [KS93, Ambler03], and we reduce the waste of underutilized people (working only in one narrow speciality), a theme in lean thinking. 



If you like this newsletter, please share it with your friends. You can subscribe to the newsletter here



Upcoming Events

Look forward to public courses in Brisbane, Melbourne, Sydney, Perth and India in 2020.  Possibly expanding to other countries.


Many might not know that I also offer Certified LeSS Executive trainingThis is specifically for senior leaders who might be interested in learning the intricacies of management and structure to influence the culture. 


Please reach out:  venky at agileworld.com.au for further details.