Avella | How to avoid implementing Lean Software Development in your company!
post-template-default,single,single-post,postid-17794,single-format-standard,cookies-not-set,ajax_fade,page_not_loaded,,qode-theme-ver-10.1,wpb-js-composer js-comp-ver-5.0.1,vc_responsive
Lean software development

How to avoid implementing Lean Software Development in your company!

In this day and age most companies either want to, or have already adopted Lean software
development – at least management think they have adopted it. But what lies behind this
concept of ‘Lean’? Continue reading and discover the six core principles and strategies and
how to avoid implementing them.

Eliminate waste

This principle requires that you don’t spend time developing unnecessary features for your

So how can your organization avoid eliminating waste? First you need to make sure the
developers don’t talk directly to people with domain knowledge. There needs to be a middle
man, preferably several layers of middle management, so that the requirements are not clearly
communicated to the developers and they have no clear understanding of ‘definition of done’.
This way the application will have to go through several unnecessary iterations due to
miscommunicated requirements.

Amplify learning

Give your developers time between projects. If you give your developers time to breathe and
analyze their previous work, they might learn something from their previous task. Some parts
of the project might be extracted and used in future projects.

This is one of the simplest to avoid. Just shred your development teams down to a skeleton
crew and give them more responsibility than they can handle, preferably across several
projects at once, forcing them to context switch continually. You should never allow your
developers to attend conventions, courses or take certifications, we don’t want them to receive
new impulses. Progress in this fashion and your developers will be prevented from learning
new technologies and techniques.

Decide as late as possible

The decision to implement a specific feature should be done as far into development as possible, the rasjonal being to push making a decision to a time when you have enough facts. Ensuring your teams does not implemented functionality that is ‘wrong’ or unnecessary.

Avoiding this principle is an inevitability. If you followed along with how to avoid
eliminating waste, you learned that you need to isolate your team from people with domain
knowledge. This will ensure that decisions have been made long before the requirements are
delivered to your developers, making sure they implement functionality that is both ‘wrong’
and unnecessary.

Deliver as fast as possible

In the current climate it is imperative for your organization to be able to identify a problem or
business case that will provide value and develop a solution as fast as possible.

Every project and initiative your organisation comes up with needs to be planned then vetted
and redrawn several times before your developers even know about it. This will ensure that
your plans and requirements will be implemented as slowly as possible, due to your
developers lack of knowledge of the problem and how the solution they are developing will
provide value.

Empower the team

Give your developers the autonomy to make decisions on their own without involving higher
management. Teams with more autonomy will spend less time communicating with
management and more time developing the solution.

You need to ensure that your developers are never involved the decision-making process. The
single point of contact should be the project manager. Use your developers as glorified
accountants. Tell them what to do and how to implement it. Developers should not worry
about decisions that are made at higher levels of the project. Actually, they should not have to
worry about anything other than their given task.

See the whole

A system is more than the sum of its parts. If your developers understand how the
organisation works, the different development teams will be better able to integrate their
systems with other parts of the organisation.

Isolating your teams is key. Under no circumstances should developers of one team talk to the
developers of another team, ensuring your developers have a singular focus; solving their
given task. This will prohibit your team from sharing knowledge with another team in the
organisation which may already have solved the same problem. There is always another
wheel to invent. There is no need to come up with an integration strategy before the
development phase, that is something you can do later.

Closing remarks

Some of my remarks made earlier in the article might be hyperbolic and obviously something you’re not doing. Maybe some parts of your organisation have embraced the ‘lean’ model while other parts have not. This is untimely. Every single part needs to embrace ‘lean’ and be a part of the decision-making process. Management’s role in the organisation is to facilitate an
environment where developers can do their work more efficiently, not to prohibit their work
by isolating them from other parts of the organisation. The point I’m trying to make here is
that if your organisation has a ‘tall’ hierarchy where decisions are mostly made at the top, and
your development teams work in a vacuum, you are probably not doing Lean Software
development and therefore doing more harm than good.