Opinions, thoughts, and ideas on leadership, management, software development, and people development.

Tag: Lean

The Difference Between Systems Thinking and Reductionist Thinking In Software Development

In software development, having a Systems Thinking approach means that you start from an event or a part of a system and tries to determine its connections or relationships to other parts or events.

A Reductionist Thinking is when you break down a problem or task at hand into its simplest parts in order to understand better what the problem is about.

An example of how these two ways of thinking can be applied is described below.

Reductionist Thinking Can Help You Build The Right Solutions.

Let’s say you want to solve a particular customer problem. Based on what you know about both your customer and the problem you’ll try to come up with an idea or hypothesis for a solution. What happens is that usually the idea or hypothesis is too big to be easily and quickly implemented on your product and tested. That’s when applying reductionist thinking might help you.

In order to both reduce risk and speed up delivery, modern product and software development approaches recommend breaking the necessary work into several small deliverables.

Because you broke a large chunk of work into smaller functional parts, now you can implement and integrate them into your product within a short period of time, 1-2 weeks preferably. Also, you’ll be able to built incrementally and deliver continuously.

Animation starting from a vision of the earth and then slowly zooming into the earth to a point where a small and specific part of a city is displayed
From a big perspective into a reductionist perspective

Once that happens, you can sense customers’ response and better understand if what you’re offering as a solution is, in reality, the one that will solve your customers’ problems.

Systems Thinking Can Help You Streamline Your Product Development Process

When thinking about the way you develop your product or the way your team develops software, oftentimes you can benefit from looking at this issue with systems thinking perspective.

That means starting from the premise that your team is a sub-system of a greater system that usually goes beyond your company and in order to understand this system you’ll have to pull back your lens and look at the whole context instead of a single part.

Start With a Map

One might say: Well, I’m just a developer, I don’t care about the product, marketing, etc. It’s not wrong to think like that If you want to limit your impact to your team. However, if you understand and think about the whole value stream and solve issues with a systemic perspective, analyzing the inputs, how you process them, and the outputs, you might achieve better results and higher impact.

One way to understand better the systems is to use Value Stream Mapping techniques (VSM). But, if you don't want to complicate things at the beginning, just use a basic flow diagram to identify which are the system's components,… Click To Tweet

Derive Actions Based On Your Mapping

From this mapping, you can figure out optimizations that will yield more effective optimizations and higher impacts. We commonly refer to these optimizations as global optimizations. The contrary would be a local optimization, which might have a positive effect on a particular sub-system but won’t help the whole system to perform better.

Adding to that, there’s the idea that in a system, how fast you can go is limited by your slowest sub-system or resource. No matter how optimized a part of your systems is if the rest of it is not optimized as well you’ll just be constrained by these slowest parts.

Best Way to Change A System

It’s not easy to change systems due to its complex nature. Some time ago I’ve attended a training with Mary and Tom Poppendieck about lean software development. During the training, Mary said something that stuck into my mind:

“You don’t change complex systems with big-bang changes. The way you change complex systems is through small changes and sensing system’s reactions after each change”.

mary poppendieck

Mary’s statement resonates with me and that might be one of the reasons most transformation initiatives fail. So, the way to go when it comes to change a system is to apply small changes to it, and not big-bang changes, otherwise, the back-pressure will be high.

To Learn more: 6 characteristics of complex systems and how they relate to modern software development

The video below presents a nice introduction to Systems Thinking.

Introduction to Systems Thinking by BEE Environmental Communication

In summary, use systems thinking to understand your system. Apply small and continuous changes, measure how the systems react, repeat that continuously.

To Learn More

If you want to learn more about this topic I recommend the following books.

Good books about Systems Thinking

The Fifth Discipline, by Peter M. Senge
The Fifth Discipline, by Peter M. Senge
Thinking in Systems, by Donella Meadows
Thinking in Systems, by Donella Meadows
An Introduction To General Systems Thinking, by Gerald M. Weinberg
An Introduction To General Systems Thinking, by Gerald M. Weinberg

Deming’s 14 principles and Agile Software Development: A perfect match?

I read an article that drew my attention; the article was about W. Edwards Deming’s 14 key principles for management.

Honestly, I don’t remember to have read Deming’s principles in the past, although I knew his work from my studies on Toyota’s Production System. So, I can say that this was the first time that I actually sat and read his set of principles.

Deming wrote them in the middle 80’s; according to The W. Edwards Deming Institute[2] the 14 points were first presented in his book Out of the Crisis, published in 1986.

Out of The Crisis – by W. Edwards Deming

One can suppose that the principles are not applicable in today’s business world. However, they surprised me regarding how up to date this list of principles are comparing to what we have nowadays in terms of modern software development practices and principles.

While reading the principles I was able to immediately connect each one of them to what we — people that study, teach, and coach agile and lean inside organisations — understand as key principles to achieve business agility.

I decided then to share these thoughts that I had by writing this article that aims to inspect if one can really compare Deming’s principles to lean / agile values and principles. Below you’ll find the comparison.

Deming’s 14 principles of management

1 — Create constancy of purpose

The word “Purpose” promptly called my attention because it became very popular among agilists not due to Deming’s work but due to Daniel Pink’s book “Drive”.

Drive- by Daniel Pink

This particular word, together with Mastery and Autonomy became a mantra in the agile community and is repeated over and over in almost every lean/agile talk out there. Although the word is the same, I do think that they have different meanings, especially because in Deming’s definition the word “purpose” is preceded by the word “constancy”.

I did my research and found that essentially, “constancy” means a state of being constant or unchanging or a steadfastness of mind under duress. That helped me to understand that “constancy of purpose”, in other words, means the act of being resilient and loyal to a certain principle and take this purpose into consideration in every decision that is made.

Look at how Deming formulated the principle in his book:

“Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs. [2]”

From that, I can conclude that what Deming meant is that an organisation must have a vision that will serve as a purpose and everyone inside this organisation should take that vision into account when deciding on something. Also, this concept relates to the idea of having a long-term vision and to see the organisation as a system where everyone ideally should be involved into the process of making this system better over time guided by the purpose.

From agile and lean I can remember immediately two ideas that resemble a lot this first principle; the first one is the idea that every agile organisation must have a clear vision and strategy. the second is that an organisation that wants to become agile must commit to the agile values and principles and make them the basis for every decision related to process improvement or even sometimes business decisions.

I do believe that these two ideas fit perfectly with Deming’s first principle. Don’t you think?

2 — Adopt a new philosophy

We all know that traditional management has been thoroughly reviewed and adapted over the years in order to fit into our current business age. Command and control, for instance, has proved to not be the most appropriated approach to deal with the current generation of workers. Management has moved from old management styles like this towards a more collaborative and co-operative style where responsibilities are shared and everyone is accountable for good or bad results.

This new approach is what most people, including me, believe that makes more sense today for the large majority of business out there. Almost everything nowadays is complex, full of uncertainty and in constant change. That’s the reason we must adapt fast to this new — well, not so new — scenario.

The agile and lean movement is what I do consider as the new “philosophy”. In a fast changing environment, nothing more reasonable to develop the ability to respond faster. But this ability comes with a price. It’s a radical change for many businesses, especially those well established and funded under a traditional philosophy. Some companies successfully achieve the transition, others just give up and other stays in between, with a reasonably good process and reasonably good results.

Something I learned and that connects perfectly with this principle is that any agile transformation must start by teaching the new philosophy and later adopting the process. I’m always 100% sure that if people don’t understand and stick with the purpose, the principles, the benefits won’t come as expected and the journey will be much harder than expected.

If you read until here, thank you!

Unfortunately, as you saw above, writing about the 14 principles is something that will require some time from me. I’m willing to invest this time if there is someone willing to read more 🙂 So, if you’d like to read more, please like this article and sign-up above as a sign that you want to read more.

Remaining principles to be compared:

3 — Cease dependence on inspection to achieve quality

4 — Minimise total cost

5 — Improve constantly and forever the system of production and service

6 — Institute training on the job

7 — Institute leadership

8 — Drive out fear

9 — Break down barriers between departments

10 — Eliminate slogans and exhortations

11 — Eliminate metrics that rob the pride of workmanship

12 — Remove barriers that prevent people to be proud of workmanship

13 — Institute a vigorous program of education and self-improvement

14 — Put everybody in the company to work to accomplish the transformation

Sources, so far:

[1] http://www.heartoftheart.org/?p=3810

[2] https://deming.org/management-system/fourteenpoints

[3] https://www.merriam-webster.com/dictionary/constancy

3 Statements That Don’t Leave My Mind

Recently I’ve read some statements that keep coming to my mind at least once a week maybe more.

1 – Make it work, Make it write, Make it fast

I’m a big fond of the concept of “Right first time” but lately I’ve seen so many time being wasted trying to figure out what would be the “Right” thing to do. Many unnecessary conflicts, concerns, non-validated assumptions, etc. This made me think more often about extreme interpretations or even shallow interpretations of such concepts that when not fully understood or discussed could lead to inefficiencies everywhere.

When I have such thoughts I remember of this concept that says: Make it work, make it right, make it fast! I don’t remember exactly when I’ve heard it for the first time but I’m sure, unless my brain is tricking me, that I’ve heard it during some research about game development (which is something I kept coming back to from time-to-time) and it was related to Blizzard, one of the big players in the game industry.

Later, after some additional research, I discovered that this term is actually attributed to Kent Back and it was part of the UnixWay for a long time.

You can read more about it here: http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Anyway, the whole idea is that when solving a problem in an iterative way you should consider to first make something that works, even if it’s not the right perfect solution. Ship it and learn from the feedback you’ll get in order to go to the second step, make it right. After rounds of improvement based on feedback then you’ll have to at some point make it fast. That will be the last step. That’s at least the intepretation that makes more sense to me.

I just feel that many times this simple and pragmatic approach will bring much more value than trying to use a sophisticated one just because everybody else is doing. But that’s just a feeling. I don’t have any data or experiment that can prove that, so maybe in the future, I can experiment with this approach and see what happens.

2 – The tiniest thing shipped is better than the best thing planned

This was something I’ve read on a blog post published by Amy Hoy on how to overcome procrastination.

You can read it here: https://stackingthebricks.com/how-to-overcome-procrastination/

This statement resonates with me because it sounds very responsive and lean, which is something I like. Also, it has a connection with the first idea as well, I believe. Living in the world of ideas and planning is super comfortable and can make you feel in control of things, but the truth is that the time will pass and all you’ll get is pure fantasy.

I spend so many hours planning stuff. I do that every day as part of my job, and I do that every day as part of my personal development. I try to make it as lean and efficient as possible. However, my feeling is that last year I tried to have the “best thing” planned instead of just shipping stuff to the real world, even if it was something small. Although I shipped, for instance, an email plugin for JIRA named Issue Events Mailer, a crap todo list style bookmark app, and another small attempts into the real world, I just have the feeling I could have done more if I had this “mantra” in my mind every time I questioned myself if what I was doing was of any value.

3 – A good plan is worth its weight in (future) gold

This one came from the same article mentioned above and also resonates with me because I learned that no plan survives contact with enemy

Also, I learned during these years of professional contact with lean and agile methodologies how bad too much planning can be. I’m not saying that plans should not exist, but we have to understand how much effort we should put on them before actually putting it in practice. At some point more planning is pure waste of time and energy that could be used for other valuable actions or tasks.

In the past things were so expensive that a well-thought plan was mandatory. The cost of repairing an error was too big. This is still true for some industries or fields of knowledge nowadays but for the great majority of software-based projects, for instance, I see these practice of thorough planning not optimal. Today is cheaper to quickly iterate, ship something, learn from it and use the feedback as input for a new iteration. That’s the base of lean and agile product and software development. Very quick cycles of plan-do-check-act. This makes me think that often just having alignment and shared understanding around the problem we’re trying to solve will be enough to a team or a person to start developing something and especially delivering something that can be used and criticized – in a constructive way – early and often.

Yes, I might have generalized things a little bit. Reality might be not as sweet as I’m painting above, but in general I believe that this principle and the previous ones should be taken more into consideration when we do or plan our plans.

© 2019 jcfausto

Theme by Anders NorenUp ↑