If you aren't an educated and/or experienced tech person, a lot of question marks may pop up in your mind while looking at these two terms: Lean and Agile. Even if you are technically proficient, you may wonder what the difference between these two really is. No worries, we are here to help you.
Both Lean and Agile are methodologies.
They are represented by sets of principles that used in order to guide the process of development (in this case, software development).
Although usually described as two completely different approaches, by the end of this post, you will notice that they are actually complementary and that one doesn’t exclude the other.
Lean
We will dare to say that Lean, generally speaking, has the process in its focus. The methodology behind Lean software development comes from Lean manufacturing. Here, it’s all about reducing any kind of a waste. By eliminating all that is unnecessary, the value is added, and value is what the customer is paying for.
Constant learning is a part of any process, and learning means improving. Without this, there is no quality, which is the final goal.
Also, people are important, because without a good team, how can you deliver a high-quality product? In order to have a smoothly running workflow, every member of the team should do what they can do best, and the work should be distributed evenly. The work is done more efficiently and quickly when everyone is doing their job, without unnecessary tasks (this can be tricky, because in our era, changes happen quickly, and something that was considered unnecessary yesterday, may tomorrow be crucial for the project).
There is a systematic, overall look at the work process when it comes to Lean methodology.
Agile
We will again be courageous enough to say that, generally speaking, in the focus of Agile is the product. Agile software development methodology is based on the Agile Manifesto. Four main values are in the center of the manifesto, and we quote them here:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.”
Communication among team members, both managers, and developers, is as important as the collaboration with the customer. A quality final product means a satisfied customer, and that is the goal.
From interaction, one is enabled to get a feedback. The feedback is attained after each cycle of the process (the working process can be seen as a compilation of smaller projects). This is crucial in order to make any necessary changes along the way, and in order to deliver the product in the short period of time possible.
Lean & Agile
These two methodologies are best described as complementary. Through quality work organization and quality team, a product of high quality is made, which makes a satisfied customer. The suggestion is that you should apply both of these methodologies. Collaboration between team members, listening to your customer’s needs, improvement and implementation of changes when necessary, elimination of any kind of waste in order to achieve high-quality and deliver the product without any unnecessary delays.
We hope that, after reading this post, you have managed to get a grasp of what both the terms Lean and Agile mean, and how they are applied in the process of software development. Our goal was to highlight the main points and deliver it in a way which is the easiest to read. However, there is definitely a lot more about these methodologies out there, and if interested, we strongly encourage you to dive into it and widen your knowledge.
Originally published at Kolosek blog.
Top comments (2)
That’s a good high level analysis you put together there. Recently I saw a few twitter posts on whether or not Scrum and SAFe are truly Agile or not. Your article puts a nice angle on that discussion: Scrum (a implemented by many, not necessarily as intended) and SAFe even more add a lot of ‘rituals’ to the way of working: standup, cross team standup, refinement sessions, retrospectives etc. The way a lot of organisations implement this could be considered Waste in Lean. Thanks for helping me remember that.
I'm glad it helped you :)