Seven Principles of Lean Software Development - Respect People

September 4, 2008 by Przemysław Bielicki

Picture courtesy of Elvire.R.@flickr

Software organizations have surprisingly more problems managing people than managing soulless machines. People are also surprised when they ask me what my job is all about and I tell them that I work with people most of the time. "But you are a software engineer - isn't your job about working with computers?". "You're partially right because I work in a team and program a computer using programming language to do what you want to do is much easier than >>program<< my colleagues to work with me to reach our team's goals" - I tell them.

Working in a team means not only solving technical problems, designing stuff and make decisions together. One of the most important factor that makes teams successful is Respect.

In this post I will try to explain "Respect People" principle from "Implementing Lean Software Development - from Concept to Cash" book.

Group or Team?

Do you work in a group or a team? If you can see your work environment objectively you will know whether your colleagues are eager to work and solve technical problems in your project or rather they are told what to do by the manager. If you are told what to do i.e. your team lead decides what you should work on next (or even tell you how to work) you work in a group.
On the other hand if you meet often and regularly with your team and everybody is eager to work and offers help to each other it means that you work in a team.

Teams Thrive on Pride, Commitment, Trust and Applause
What is the difference between a group and a team? As the title of this paragraph says, teams thrive on pride. It means that teams are proud of what they do and how they do.
Teams thrive on commitment i.e. team members love to be committed to some work - they are eager to work (commit) and do it with pleasure.
Teams thrive on trust i.e. team members trust each other and know that if they have problems they can count on colleagues - they will never be left alone with their problems.
Last but no least, teams thrive on applause i.e. they want to know that they are doing useful software and that they bring value to the organization they work for.
Teams have commons goal(s) and they pursue it together. Team members respect each other and create great places to work for everybody.

Group is just a couple of individuals
What about a group? Well, a group means that there are some engineers who basically work for the same project and they do not mutually commit to accomplish project goals. They work separately and from time to time merge the effects of their work.
BTW- example: I noticed that some of the new engineers in my company are just left alone after the first couple of hours when they arrive. Senior guys who should show them everything just give them hundreds of pages of documentation hoping they will find something useful in there and wait until they say they are ready to get some assignments. This is not a team!

If you feel you work in a group and would like to work in a team there is a remedy for you or your managers.

Steps to achieve the goal

Here are three steps authors of this great book recommend implementing in every lean organization.

Train team leaders/supervisors
Give team leaders the training, the guidance and some free space to implement lean thinking in their environment. Do not impose anything - they know better how to implement it in the areas of their responsibility.

Move responsibility and decision making to the lowest possible level
Teams should deliver value under the guidance but they should not be driven by leaders or managers. Let your people think and decide on their own - they know better how to implement difficult algorithms and apply stat-of-the-art software frameworks. Leader's role is very important here - they should be team's enablers and facilitators.

Foster pride in workmanship
Remove impeding practices like individual rewards (foster team rewards, instead), careless workspaces and work practices (no testing, no coding style, merging big pieces of code, etc.), robot-like jobs, etc. You should encourage passionate involvement of your team members to what they do. Let your people decide what and how to do in order to meet goals, don't depreciate and disregard people's estimates (yes, it is sometimes so difficult to implement it) - and remember that they are only estimates. This will have a more sustained positive impact by far than individual incentives and bonuses.

That's it! I know it's a bit shallow and I may missed some points but it is anyway a good starting point for you to apply "Respect People" principle. I hope I explained it in a way you are able to apply it straight away. If you would like to know more and to read some more sophisticated examples go to "Implementing Lean Software Development - from Concept to Cash" book.

PS. Remember to respect not only people at work but all the people - this will definitely pay off (even if it will not pay off you should respect everyone).

PPS. Other articles in this series can be found here:

1. Deliver Fast
2. Optimize the Whole
3. Defer Commitment
4. Build Quality In
5. Create Knowledge
6. Eliminate Waste

Permalink