Newsletter #35 : Energy Investment Model

Join Mailing List by clicking here

Interesting Articles

Catapult: The fun way of doing a retrospective

The Catapult activity is great for planning and preparing for an upcoming challenge. With a simple metaphor, this activity guides the participants to look at the challenge from three perspectives: the person facing the challenge, the challenge itself, and the organization people engage in to overcome the challenge.

Running the activity

1. Draw the catapult, with the person flying and the mountain ahead.
2. Ask the participants to write notes for each of the three areas
   • The catapult: notes related to the organization preparing people to overcome the challenge,
   • Person flying: notes related to the person facing the challenge
   • The mountain: the challenge itself.
3. Conversation about the notes. Consider guiding the conversation by connecting related notes from the three areas.

Read the rest of the article here

 

---

 

"Energy Investment Model" for team building and employee engagement
 

Came across Energy Investment Model created by Don Tosti and Fred Nickols.  I am yet to use this model and have posted it on LinkedIn to hear more from others. Possibly, I will post the details if I hear anything interesting in the next post.

Employee engagement is hot and for good reason. The payoffs are significant. But we think there’s an aspect of employee engagement that has not received the attention it deserves; namely, that in terms of engagement, employees fall into four basic communities: Players, Spectators, Cynics and Deadwood.

Players. These are the people you want. They couple a positive attitude with high levels of effort. They are the ones who make things happen, who take the initiative and who see things through to the finish. They are both competent and caring about their work, their company and their co-workers. The primary task in relation to this community is retaining them as players.

Spectators. These are good souls; their heart is in the right place and so is their attitude. They, too, are competent and caring but they rarely take the initiative, choosing instead to expend minimal amounts of energy. The turnaround task here is getting them to release what are essentially large amounts of energy reserves.

Cynics. These are the folks who, except for their attitude, would be players. They have high energy levels and are usually competent but, for various reasons, have become disillusioned and cynical about the workplace in which they find themselves. Owing to their competence and high energy levels, they can be especially troublesome and problematic. Yet, if their attitude could be turned around, they could make significant contributions to the organization.

Deadwood. These people have the deadly combination of a bad attitude and low energy expenditures. They often do little more than take up space and occupy slots on the organization chart. Turning them around is the most difficult turnaround task of all because both attitude and energy expenditures must be raised.


Read the complete article here.
 

---

There are no best practices while solving complex challenges 

If you have attended one of my LeSS courses, we discuss about different types of problems and the ways to solve each type. Complex and complicated problems cannot be solved through best practices.

Most of the product development activities fall under complex and complicated and thus best practices are futile.

Here are some snippets about this topic from the book "Practices of Scaling Lean and Agile". 

In Managing the Design Factory, a similar point is made:

...the idea of best practices is a seductive but dangerous trap. ... The great danger in “best practices” is that the practice can get disconnected from its intent and its context and may acquire a ritual significance that is unrelated to its original purpose. [Reinertsen97]

Since so-called best practices are ‘best,’ they also inhibit a “challenge everything” culture and continuous improvement—a pillar of lean thinking. Why would people challenge ‘best’? Mary Poppendieck, co- author of Lean Software Development, reiterates this point and draws the historical connection from best practices to Taylorism:

Frederick Winslow Taylor wrote “The Principles of Scientific Management” in 1911. In it, he proposed that manufacturing should be broken down into very small steps, and then industrial engineers should determine the ‘one best way’ to do each step. This ushered in the era of mass production, with ‘experts’ telling workers the ‘one best way’ to do their jobs. The Toyota Production System is founded on the principles of the Scientific Method, instead of Scientific Management. The idea is that no matter how good a process is, it can always be improved and that the workers doing the job are the best people to figure out how to do it better... Moreover, even where a practice does apply, it can and should always be improved upon. 

There are no best practices—only adequate practices in context.

 

---

Upcoming LeSS courses and Events

Recently  Perth Certified LeSS Practitioner course has been announced.  The registrations have started.. and appreciate if you could spread the word around.

Date: October 21st, 22nd and 23rd.

City: Perth

Link to register: https://www.eventbrite.com.au/e/certified-less-practitioner-principles-to-practices-tickets-71526055357

 

 

---

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 

Join Mailing List by clicking here

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.