Tuesday, June 19, 2018

“Kanban is not a software development lifecycle methodology or an approach to project management. It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process.”
“We’ve come to recognize that Kanban is giving permission in the market to create a tailored process optimized to a specific context.
Kanban is giving people permission to think for themselves. It is giving people permission to be different: different from the team across the floor, on the next floor, in the next building, and at a neighbouring firm.” – David Anderson
#kanban, #softwaredevelopment #projectmanagement 

Monday, June 18, 2018

"If you want to adapt new behaviours, your mindset needs to be congruent with those behaviours. If your mindset doesn’t support the new behaviours, ultimately your mindset will trump your behaviour and you won’t be able to get the results or sustain the change you want."

- Roger Schwarz

Friday, June 15, 2018

One won't become a systems thinker by reading System thinking books. I remember Craig Larman handing me Peter Senge's book during my Valtech days in 2004. This was as part of the reading list during the initial days of LeSS related experimentation. Even though, I read it many times, it all started making sense, when we introduced the ideas around "Multi team Product Backlog Refinement", and "Having shared visual spaces", etc.   These small ideas which were created to enable the teams to get the wholistic view of the product, helped me in connecting the dots with the knowledge from the various theories. I found it very helpful approach to practice and get your hands dirty from the things you have learned either through the book or training.  LeSS also recommends to "Own" an idea rather than "Rent" it.  If you are keen to learn more about how to own an idea rather than renting it, and also, the difference it could make to your product  development,  please register for my upcoming LeSS courses in Perth, Melbourne or Sydney: Perth: Sydney: Melbourne: #productdevelopment #training #systemsthinking #less #renttoown


Thursday, June 14, 2018


In the 1940s and '50s, when automation was increasingly applied, many began to worry that it would make people in general, and managers in particular, obsolete. If machines could replace people's minds as well as their muscles, what would ultimately be left for people to do? This concern was based on the incorrect assumption that there is a finite number of problems to which the human mind can be applied.  The problems that can confront human minds are unlimited. No matter how many are solved, an infinite number will always remain to be solved.  -  Ackoff  #SystemsThinking,#Ackoff,#LeSS,#management,#Thinking

In the book, "Competing against time" the authors found that reducing lead times to customers by three-fourths resulted in a firm moving to a growth rate that was two to four times the industry growth rate.  #lean  #less #agileleadership #leadtimereduction  

Monday, June 11, 2018

Register for "Certified LeSS Practitioner: From Principles to Practices" courses in Perth, Sydney and Melbourne.

Click on the link below to register:
Perth: August 1st - 3rd -->
Sydney: August 15th - 17th -->
Melbourne: August 29th - 31st -->

#LeSS #training #agile #scrum

Wednesday, June 06, 2018

Poor management can easily destroy collaboration by rewarding people for behavior that optimizes for their function at the expense of customer outcomes or wider organizational goals. Examples of this include rewarding developers for features that are “dev complete” but not production ready, or rewarding testers for the number of bugs they find.  In general, rewarding people for output rather than system-level outcomes leads to dysfunction, and in any case monetary rewards or bonuses have been demonstrated to reduce performance in the con- text of knowledge work

 - Jez Humble  

#optimization #features #testers #bonus #output #less

Monday, June 04, 2018

Certified LeSS Practitioner: From Principles to Practices 

Register for "Certified LeSS Practitioner: From Principles to Practices" courses in Perth, Sydney and Melbourne.

Click on the link below to register:

Perth: August 1st - 3rd -->
Sydney: August 15th - 17th -->
Melbourne: August 29th - 31st -->
#LeSS #training #agile #scrum


Another great nugget by Ken Rubin 

"Many product development organizations focus more on eliminating the waste of idle workers than on the waste of idle work. For example, in traditional thinking, if I hire you to be a tester, I expect you to spend 100% of your time testing. If you spend less than 100% of your time testing, I incur waste (you’re idle when you could be testing).  
To avoid this problem, I will find you more testing work to do—perhaps by assigning you to multiple projects—to get your utilization up to 100%. Unfortunately, this approach reduces one form of waste (idle-worker waste) while simultaneously increasing another form of waste (idle-work waste). And, most of the time, the cost of the idle work is far greater than the cost of an idle worker."  #waste #productdevelopment #less #testers #utilization #idle 

Tuesday, May 29, 2018

If you missed the tweet from Kent Beck :-).  

Thursday, February 01, 2018

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:

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?