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

Category: Agile

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

What Is A Feature Lead?

There’s a lot of resources explaining more in details many roles in IT, but one in particular I think it’s not well defined or explained. The Feature Lead.

I have an overall idea of what this role should do and which behaviors or skills people on this role will have to develop or show in order to make the most out of it and really create an impact.

In order to share these thoughts I’m drafting an e-book that will bring a more detailed perspective on this subject. See below an excerpt of the first chapter.

What is a Feature Lead?

The Feature Lead is a role – a set of responsibilities – that can be deployed inside software development teams as a mean to empower people to take ownership and make decisions regarding the development of new features, creating a more fertile environment for growing self-managed teams as well as a culture of experimentation and learning.

The feature lead is the equivalent of a product owner on the technical side of things. That means that the Feature Lead will be responsible for taking care of all the technical issues that involves the development and especially the delivery of a new feature end-to-end.

Did you know?

The definition of what a “feature” is, as we know it nowadays in software development, was described by Peter Toad in 1997 in his process for software engineering called The Coad Method, that later evolved to become the Feature Driven Development process. The core of the Coad process was an artifact, created during the analysis phase, called “a feature”. It was similar to a requirement, except by the fact that it was written using a domain language which the project sponsors could understand. The main concept is that a “feature” should be written in a way that the sponsor could agree that the feature had meaning and was required in the system [1]. Doesn’t this sound like an old relative of User Stories?

Key points:

  • It’s a role and not a job title.
  • A feature lead is responsible for feature delivery.

Did you like it? See below the outline of the e-book:

3 Voices You Should Have Inside Your Team

This article is not about the Scrum Master, Product Owner, and Dev Team. Curious? I’ll explain what I mean.

If I ask you to propose a way to organize a team that allows the team to be as independent as possible and is also capable of enabling self-management. Which approach would you suggest?

I have the feeling that suggesting Scrum as an approach for this particular situation came to your mind. Although Scrum is a very good framework to introduce the agile way of doing work it doesn’t perform very well when it comes to helping your team to be agile. It tells you what, but it doesn’t tells you how.

I’ve seen recently many teams moving away from this standard way of setting up agile teams to a more tailored solution that takes into account the company’s culture, regulations, the type of industry. I believe that agile coaches or change agents with a certain experience have acquired sufficient knowledge to create or suggest a tailored solution that will fit better the organization’s needs.

Following a generic recipe, which is essentially what frameworks are, is not your only option when it comes to enabling an agile mindset and structure. Instead, you can think and use these generic tools as a reference, cherry picking or adapting what is there according to your environment’s needs.

For instance, you should take some time to analyze and understand where are the bottlenecks, communication ruptures, etc. Understand first the environment you’re in and after think of a solution that will survive on such conditions.

Different perspectives are what you need in order to create different experiments that will allow you to really leverage agile practices inside your teams in order to get better results. I’ve thought a lot lately about many agile related learned concepts that aren’t making much more sense anymore considering the different scenarios I saw. Contexts and people changed and I believe this is one of the reasons why I’m having such thoughts and feeling.

Having the abovementioned in mind, I’d like to share a different perspective to take into consideration when trying to build an agile team. Forget about which framework you’ll use, just make sure you have three voices inside your team.

The Three Voices

If you’re serious about autonomy and self-organisation and you really want a team that “is” and not just “do” agile than pay attention to these voices.

A team without one of these three voices will not be balanced and will most likely depend on external people that speak one of the missing voices. Still, even having all the voices, there’s no guarantee that the team will be able to self-organize because voices are just one part of the equation that results in autonomous and self-organizing teams. However, having the voices will increase your odds of success.

1 – Voice of Viability

Who takes care to check if what’s demanded is viable or not?

This voice is responsible to say to the team what are the market and business needs and what are the potential solutions to fulfill these needs.

A rough example: A company that produces software designed to manage cargo ship construction, will not likely decide to add smiles to the app’s chat because that’s not what the market is demanding. It’s not a viable solution for that particular business.

2 – Voice of Desirability

Who takes care of checking if a solution is desired?

This voice inside the team will be responsible for saying if something is being desired or not but customers. In order to do that, this voice has to understand the customer world.

It’s not very hard to imagine some viable solutions, but which ones will custorems be more willing to buy? Which ones have higher changes to succeed? These are questions that the voice of desirability is reponsible to answer.

3 – Voice of Feasibility

Who takes care of checking if what’s is viable and desired also feasible?

This is the most technical of the three voices. Usually the people that will transform the idea into something concrete – that can be consumed by users – are the ones that can express this voice and say if something is feasible or not from the technical perspective.

Make use you have these three voices inside your team, and your problem regarding autonomy and self-organization will be half-solved or at least will have higher changes of being solved.


If you ensure that your teams have these three voices inside and those voices can talk to each other frequently and in synergy, you’ll be able to build the framework you need for your team and organisation.

What’s Wrong With Cross-Functional Teams – Part I

What’s the best structure for software development teams? How should I structure my team? Should I use the Spotify Model? Which other options do I have?

The questions above and many others come to the minds of people who need to structure a new team or want to restructure an existing one. Most people in this situation believe that the simplest way to do that is to follow a recipe. That’s what we have been seeing currently in the market. For instance, the “Spotify Model” is often mentioned as a recipe for structuring a cross-functional team that works.

Although fantastic, the ideas contained in the approach shared by Henrik aren’t suitable for all cases. In order to achieve success, you’ll have to have the same ingredients – context – that Henrik had. Otherwise, you’ll have hard times implementing some of the ideas.

Read this – No, I didn’t invent the Spotify model – to understand what I’m talking about.

Some time ago I did reflect on how we usually structure cross-functional software development teams. I did the analysis based on two perspectives:

  1. Conway’s Law
  2. Flow of Value

Conway’s Law

Conway’s law says that “organizations which design systems are constrained to produce designs which are copies of the communication structure of these organizations”

According to Wikipedia:

The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult.

Learn more here:  Conway’s Law – Wikipedia

Flow of Value

I’ve heard a lot, and probably you as well, that Kanban is used as a tool to establish a flow and manage it. This flow isn’t about JIRA tickets. Instead, it is means flow of value, whatever your business definition of value is.

As a principle, everything we try to optimize should be favourable to improve the flow of value and not only favourable to speed or throughput. This means not all improvements are related to speed. Some might even slow down your current speed, but that’s totally acceptable if the flow of value will be improved. We know as well from Systems Thinking that local optimizations, such as focusing only on increasing throughput – are not the best way to optimize a system, especially a complex one.

There’s a fantastic book called Principles of Product Development Flow, which is not fun to read I have to say, that is super insightful and highly recommended for those who want to know more about what flow really means.

The Principle

The two ideas aforementioned helped me to formulate a principle to guide my analysis.

Cross-functional team’s structure should have Flow of Value as a principle and fight Conway’s law to avoid knowledge segmentation and enable the creation of a learning organisation. Click to tweet

The Question

Based on the principle above, I decided to explore the following question during this analysis:

How should cross-functional teams be structured to allow for a flow of value and to fight against Conway’s law?

I’ll continue the analysis in the next parts of this article. Sign-up below to know the answer and suggestions on how to improve your cross-functional team setup.

How To Get Fast Feedback During Retrospectives

There are many ways one can use to get feedback after a meeting or retrospective. One of the best and easy ways to do that is to offer a feedback wall, column, space, window, door, whatever. All you have to do is to find a place where people can leave their feedback about the meeting you facilitated by sticking post-it notes on that place. I did that many times and it was very useful.

Facilitators want to provide effective meetings for their audiences. Getting feedback at the end of each session is a great way to achieve that. Also, it will help you to improve as a facilitator over time.

During my career, I facilitated many meetings. I’m not claiming to be an expert on this subject, but I learned one technique or two over these years. One of these tools is called Feedback Wall, a great way to get fast feedback from your audience at the end of your sessions. It will give you a good perspective if you met people’s expectations or not.

When closing a meeting, I usually like to ask people to offer their feedback before leaving the room. I also say that offering their feedback is optional but it’s of a great value for me as a facilitator because I can identify if I met people’s expectations or not. This is a technique I use often during retrospectives, reviews, talks, training, but not during quick meetings or catch-ups.

The feedback wall method will give you a good perspective on the overall mood of the crowd at the end of the meeting. If the meeting was a retrospective, for instance, a good mood could indicate that people left the meeting with some good expectations in terms of what comes next, actions, improvements, etc. If the mood was not great it could indicate that the outcome was not effective and people didn’t see the meeting as something valuable for them.

In general, you’ll have to do your own interpretation of the results since all you’ll have is hand-drawn smile faces. If you want to get more insights on how your facilitation went, you can also ask people to write one word or two that describe their feelings at the moment on the post-it note. I’d suggest you think in advance what you’d like to inspect in terms of feedback from the attendees, this always helped me to structure the feedback in a way that would be more useful for me as a facilitator.

The only issue I see with this method is that it will not give you a qualitative perspective. Since you want to be fast, you cannot ask people to write long texts or to think about many questions. Also, you have to do your own interpretation and figure out by yourself any improvement action. Still, I believe that most of the times, if you’ll not have enough time or you didn’t prepare in advance, this is a great method to at least get some feedback from your meetings.

Decentralized Decision-Making

“Everything you do for the group is one less thing they know they can do for themselves”

Chris Corrigan: The Tao of Holding Space

This Sunday I was reviewing some notes and found one where I captured the quote above.

When reading the quote I remembered a chat I had with a former colleague last Friday where we talked about something related to the quote:

How to act more as a facilitator instead of a decision maker even if you are in a position or have a title that implies that you’re the one in charge of making final decisions.

My colleague told me a story about a meeting he had with one of his teams about how to improve collaboration. While listening to the story, I noticed that the team didn’t have a clear idea of what types of decisions they could make. Questions such as “Can we make this types of decision?” was a clear evidence of that.

Imaginary limitations can hinder the ability to achieve a decentralized decision-making environment. My colleague’s team had so many imaginary limitations in their heads that they’re not seeing which types of decisions they could make. Someone else was deciding for them because they didn’t know they could do it themselves. They thought their bosses were the ones in charge to make decisions.

After listening to the story, I shared my thoughts.

You create more damage than benefit when you decide for someone else or a team. The benefit is that you help to keep things moving and avoid paralysis. Things move faster and towards the direction you want. It looks good at first sight. But if you look at what you’re taking from them you’ll see the big damages you’re creating. You’re preventing them to have a saying on commitments that they’ll have to make. You’re taking from them the opportunity to decide and learn from mistakes. And, you’re hindering their opportunities to improve their decision-making abilities.

I’m not saying you’ll never have to decide on something and that everything can be a team decision. There are for sure certain types of decisions that you will not be able to delegate. Having a clear decision-making framework in place at moments like this would be handy.

Nicolai Foss and Peter Klein argue in the article “Why Managers Still Matter” that “In today’s knowledge-based economy, managerial authority is supposedly in decline. But there is still a strong need for someone to define and implement the organizational rules of the game.”

Source: https://hbr.org/2017/12/when-to-decentralize-decision-making-and-when-not-to

There are many ways to let clear the “rules of the game” and create a decision-making framework. The one I always refer as a good example is the Delegation Board by Management 3.0.

Centralized decision making makes things very slow and bureaucratic. It doesn’t scale and doesn’t allow for self-management inside teams. The establishment of a clear decision-making process will create the necessary conditions to achieve decentralization and increase people’s autonomy. Speaking of self-management, I’d like to share this quote below:

Self-management is self-management of decisions! if there’s no change in who makes decisions and how decisions are made, there’s no self-management of anything and therefore no lasting transformation of anything at tall. And all gains are temporary.

Daniel Mezick.

If you want to create a learning organization you have to provide the right environment for that. Making decisions for others all the time and assuming they don’t have enough capacity to that that is not a good way to establish such conditions and an indicator that the level of trust is very low amongst peers.

When you decide on behalf of other you take from this person the chance to learn because the decision-making process is also a learning process. To make a decision one have to understand variables, explore topics you didn’t know before, have a better of how the business work. This thought process helps people to increase their frame of reference and making better decisions over time. Also, they’ll get a better of how their decisions contribute to the organization’s results.

The level of commitment to the decision is also affected. When you make a decision, it’s your commitment not other’s people commitment. If the team make a decision, it’s their commitment.

Sometimes we have to “learn to hold space”. We have to learn how to be patient and how to prompt discussions that will help people to realize what they have to. Some might argue that this takes much more time when compared to telling people what to do. You can do this for a while, but when you turn our attention to your people, all you’ll see is demotivation, low morale, bad mood. Everything we don’t want to have inside our teams and organizations.

When Scrum Becomes Toxic

Scrum is without any doubt the most known Agile framework nowadays. It became very popular as the easiest way to introduce Agile to organisations and especially, as an easy and efficient tool to start an Agile transition inside organizations. I had my first contact with Scrum in 2009 and it was exactly in this context: as a way to start a transition from a traditional model of software development to an Agile one.

The danger of this approach relies on how people are being taught about the framework and its origins, which I think didn’t change too much in this 9 years. It’s common to see in Scrum training an introduction to the Agile Values and Principles, that were written down and published in 2001 in the Manifesto for Agile Software Development. During the training, many correlations will be made between the Agile values and principles and Scrum practices and ceremonies as a way to justify the framework, its practices and structures, and make people believe that Scrum is the silver bullet they need.

What most people don’t realise is that Scrum is indeed a good agile management framework as it can provide a very good way to organise teams, structure roles that are needed to have a more customer-focused development approach, organize backlogs, support decision making, estimations, continuous improvement, etc. It’s fantastic on that matter, but it lacks severely one of the key components of Agile: Technical Practices.

There’s no Agile without Technical Practices. A team cannot achieve agility if they just use Agile frameworks as a means to improve how the work is managed. This is an illusion and will over time create demotivation and make people believe that Agile does not work. Yes, it does not work, and will never work, if you believe that it’s just about management practices.

There is no agile without technical practices

I saw many big fans of Scrum over my career, and just a few really understood how it could help the organization to become better. It took me some years to really understand how Scrum could help organisations, when it’s applicable and when it’s time to move from Scrum to something else more appropriate. It’s hard to think this way when people that teach you don’t have such vision and just follow or repeat the same lessons that they’ve learned during their certification course. That’s I’d highly recommend you to be very careful when choosing any training on Agile. Do some research and figure out if the person giving the training has actual experience instead of just theoretical experience. That’s important because some theories are beautiful, but they don’t quite work very well on the battlefield, and this you only learn if you have fought one this battles.

Getting back to the point of this article, the Technical Practices, the best way I see nowadays for any organization to become better at Technical Practices, apart from recruiting the right people, is to use eXtreme Programming practices, that somehow were forgotten after Scrum took over the market with its promises and the modern DevOps practices as well. Those two combined with any other Agile framework are the real recipe for creating the right culture that will generate the conditions to move organizations from low to high performance over time.

It won’t happen in days, weeks, or months, maybe it’ll take your organization years to become a high performer, but from my experience, and the experience of many other people much more experienced than me that’s the best way we know at the moment on how to enable business agility inside organizations and transform them into high performers.

© 2019 jcfausto

Theme by Anders NorenUp ↑