Individual outcome can be accountable and not the emergent behavior

Something that I am thinking about... In a predictable, closed system, nailing down the accountability of an agent is feasible. However, in a complex adaptive system, the outcome is due to the interaction of many agents. The individual agents are accountable for their own actions but not emergent behavior or outcome. Large organisations are complex systems, however, the processes and policies are created with an assumption of predictability and individual accountability which are tied to the outcome. When the individuals KPIs and salary are tied to the outcome of a system with complex emergent behavior, individuals start demanding more control so that the outcome can be predictable. This, in turn, creates more stress on the system.

Newsletter 37: Why Sprint 0 is a cardinal sin

Interesting Articles Why using Sprint 0 is a cardinal sin for all Scrum Masters A Scrum Master using Sprint 0 is just as strange as an astronaut believing the world is flat. Scrum Masters should know better! Unfortunately, there still are many Scrum Masters who start their new teams with Sprint 0. In this article I will try to persuade you there is no convincing reason to use Sprint 0. So let’s start by figuring out why Scrum Masters introduce the concept of Sprint 0 to their team. What is Sprint 0? There is no official definition of Sprint 0, as it is not part of Scrum.   Sprint 0 conflicts with the core of Scrum Imagine you would strip Scrum of everything to reach the core of what Scrum is about. You would remove all the roles, events, artifacts and rules of Scrum to reduce it to its absolute essence. Scrum boiled down to a single sentence for a software development context would be: Deliver a working product every Sprint Sprint 0 clashes with the Empiricism of Scrum The foundation of Scrum is empiricism. Empiricism asserts that knowledge comes from experience and you should make decisions based on what is known. By doing you will learn more. You may use this learning to do better than you did before. By starting with Sprint 0, you have no product increment to inspect at the end of the Sprint. Therefore, your team will not run into the challenges involved with doing a real Sprint. Sprint 0 results in reduced transparency: you will not encounter the real obstacles involved with doing Scrum. This leads to worse inspection and less adaptation. You can read the rest of the article here     Look at Capability, not Title. Ever since Scrum became widely adopted in the early 2000’s, discussions have arisen whether the Scrum Team consists of programmers, designers, or other titles specific to the needed skills. Should they be called out by title, or is this a cross-functional team? With the arrival of Dev/Ops, a surge of opinion pushed that Developer team should be replaced with Delivery team, especially for non-software development (like marketing). Yet, from a Scrum user’s (Product Owner?) point of view they are everyone and anyone necessary to research, develop, deliver, and sustain the increment. This has unearthed strong opinions. Unfortunately, they don't converge on a single word or phrase. A Developer is on the Scrum Team … we have listened to discussions about where this leaves the architect, tester, infrastructure setup, and other non-programmers required to “create”  a “Done” increment. Read the complete article here.   To read the rest of the articles and posts... You can subscribe to the newsletter here

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