Announcing the first LeSS course in Hyderabad

Happy to announce the first LeSS course in Hyderabad. 

Certified LeSS practitioner: From Principles to Practices.

Here is the link to register 

Date: March 15th, 16th and 17th 2019

Are we running backwards agilists ?

There has been some discussions in the Systems Thinking community about the dilution of ideas. I see similar challenges in the agile world as well. The market is changing so fast that the companies are always trying to catch up.
This is exactly where the agility is needed.
Creating a nimble(agile) organisation in this complex environment is challenging and needs thinking. However, thinking is hard and needs time and energy. Moreover, the senior leaders in the organisation have short turn around time to produce results. They want best practices to be given rather than sit and discuss various options. In this whole process, the agility that needs to be handled from the complex domain, would be treated like a simple problem by applying the best practices approach. In addition, celebrity endorsed methods, practices with quick fixes are embraced rather than building something that suits the purpose of the organisation. I personally feel that, the current state of agile implementation is akin to hamster running on wheel. We think that by constantly changing frameworks and methods, we are making a good progress. Everyone is running fast, exhausted but staying wherever we are.. even worst.. sometimes I ask myself are we running backwards ? :-)
What do you think ?


Feel free to join the Linkedin Discussion here

System Kaizen over Point

One of the popular ways to "manage" queues in product development is to set up WIP (Work In Progress) limits and it has its benefits. However, we also need to be aware of the fact that, WIP limits are effective when it is done keeping the overall systemic improvement in context. If the organisation is siloed with a lot of interdependencies across the teams, then setting WIPs in individual siloed teams, could create unintended consequences, possibly creating a bigger queue somewhere else. System kaizen should be encouraged rather than the point and eliminating the queues is preferred than just managing it. We will be discussing some of these concepts during the upcoming LeSS course in Sydney on March 4th, 5th and 6th. Reach out to me for further details..

is Hierarchical organisational model bad ?

Most of us say that hierarchical organisations are bad and not suitable for product development/knowledge related work. At the same time, I have started believing that, it is not the hierarchy as such that is causing the havoc but it is the way the organisation is structured within the hierarchy. Product development environment is supposed to be collaborative and cross functional. When the org structure doesn't support the collaborative nature, it leads to sub-optimal results. One can still have a networked model structure or a holocratic structure, but if it doesn't support the collaboration and cross functionality, product development would fail. Question is.. is it the model(networked, hierarchical, etc) or the structure that is driving the behaviour the outcome ? Just to clarity, the structure includes the way the model is organised, HR policies, etc.

Certified LeSS Practitioner: From Principles to Practices Sydney 4th, 5th and 6th 2019

The registration for the upcoming LeSS course in Sydney has started... the early bird closes 24th Feb. Hurry as we have limited seats. Please find the course registration details below. Please reach out to me if you need further details

You can register for the course here

“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 

"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

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: bit.ly/Perth_LeSS Sydney: bit.ly/Sydney_LeSS Melbourne: bit.ly/Melbourne_LeSS #productdevelopment #training #systemsthinking #less #renttoown

 

  

 

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  

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 --> bit.ly/Perth_LeSS
Sydney: August 15th - 17th --> bit.ly/Sydney_LeSSbit.ly/Sydney_LeSS
Melbourne: August 29th - 31st --> bit.ly/Melbourne_LeSS


#LeSS #training #agile #scrum

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

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 --> bit.ly/Perth_LeSS
Sydney: August 15th - 17th --> bit.ly/Sydney_LeSS
Melbourne: August 29th - 31st --> bit.ly/Melbourne_LeSS
  
#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 

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

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 ?