Simplicity at work – I h’ve always wondered what does this mean to me, to my team and to my organization. In my quest to know more, I asked this to many Agile Coaches and enthusiasts on various groups.
In this post, I like to share what I understood and gathered from my interaction with these people: Steve Ash, Charles Bradley, Lynn Shrewsbury, Ruud Rietveld, Philip Ledgerwood, John Hebley, Jeff McKenna, George Dinwiddie, Adam Sroka, Michael James, Matt Anderson and Cass Dalton.
[pullquote]Simplicity is the ultimate sophistication. ~ Leonardo da Vinci[/pullquote]
Decluttering is a consequence of Simplicity. Simplicity leads to:
- Decluttering of products.
- Decluttering of your mind. Not being manipulative – being honest, open and trustworthy.
- Decluttering your workspace, working in open spaces.
[pullquote]Scrum philosophy of working in small teams, small sprints, small stories imbibe simplicity thinking – Thoughtful reduction.[/pullquote]
The desirability of simplicity is sometimes expressed as the KISS Principle.
- Do today only what you absolutely need to do today. No ‘future-proofing’. No ‘gold-plating’.
- Achieve Just Barely Good Enough (JBGE). JBGE is actually the most effective possible.
Thanks to Scott Ambler for sharing this term JBGE. You could read more about this in my earlier post Agility is About Identifying and Achieving “Good Enough”
There is a point in time when any additional effort put into work product will increase its cost without increasing its value. If not zero, the increase in value may be insignificant compared with the increase in cost. This is the point to stop! (Achieving JBGE).
It’s easy to continue developing a product beyond some point. A Standish Group survey in 2009 stated that over 70% of functionality is never or rarely used. Not doing that work is a great opportunity to do more valuable work.
[pullquote]The simplest way to achieve simplicity is through thoughtful reduction. Thoughtful reduction is increasing the amount of work not done. Inspecting closely to remove waste in the process and product.[/pullquote]
Few Agile thinking and practices that come to my mind are:
- Test Driven Development follows simplicity. You right just enough code to pass your tests. By defining the measure of success first and then coding to that (and only to that), you eliminate a lot of unnecessary work.
- Building working software just enough to get feedback.
- Writing just enough documentation to serve a need.
- Use of story cards (As a customer, I want to do something, so that I can get some value). You don’t do anything unless the value can be clearly stated.
- Using simple task boards to measure progress.
- Backlog refinement: Product Owner decluttering backlog to identify features that will make his product successful. Check my earlier post Scrum Product Owner Has to Kiss Lot of Frogs to Find a Prince
- Having only 3 roles in Scrum (Team, ScrumMaster and Product Owner) on a team is simplicity.
- Thoughtful reduction of hierarchy within the organization is a step towards simplicity.
[pullquote]Simplicity facilitates creating product with minimum functionality that is easy to use and has simple user interfaces and to achieve Minimum Viable Product (MVP)[/pullquote]
XP-term ‘YAGNI’ (‘You Aren’t Gonna Need It’) defines simplicity. Teams want to create more than what is asked for, because, we are going to need it further down the road. But the road can go in a different direction soon, and then all the work is wasted. Hence better do it simple now and only embellish when it is actually needed.
- Keeping design simple eliminates the need for supporting documentation.
- Simple design approach reduces unnecessary work done upfront.
- Doing refactoring now keeps code and design simple and easy to change with less effort.
In software development, teams often add work that can be easily avoided as they are not adding any value. Work such as:
- Delivering features that nobody asked for.
- Gold plating things that are already shippable.
When organizations are building software, they do certain things that are necessary in the scheme of things. But, these tasks demand time and effort that could be put to better use. Not to say that these should be skipped altogether. But, there’s definitely a way to achieve the same purpose in an easier way. What are those tasks? Let’s list them below:
- Requirement documents are not necessary to understand the requirements.
- Design documents are not necessary to design software.
- Estimating is not necessary for producing software.
- Documenting test cases are not necessary for testing.
None of the above themselves contribute to the final product. Like I said, they serve a purpose in your organization even though they do not directly lead to working software. Consider their purpose, and consider other ways to achieve the same purpose with less time and effort. Else, you’ll end up with a pile of ‘actual work’ not done.
There is a tendency within developers to design the generic, scalable framework first, before having more than one real example to implement that uses the framework. You never really know what generality you really need until you have several data points. The leaner/agile solution would be to write the first implementation in the simple way just to get the product in front of people. Once you have a need for a second or third case, then this will have a much better idea of how much of your generic framework is really generic and how much of what you would have written into the framework was either unneeded fluff or actually specific to the first implementation. In this case, the simplicity allows you to not to over-engineer the software.
In one of the group conversation, Charles Bradley shared a link from his blog. Check this to find what Ron Jeffries and Chet Hendrickson have to say about Simplicity.
Please share your story of how did you and your organization applied simplicity principle.
what’s your understanding of “the work not done”?
– what does “not done” mean?
– what are “the work” here? (those work that are ‘not necessary’ as you mentioned? but then how to judge?)
this principle is the hardest to translate or understand properly.
Xu Yi,
Let me share few examples. Product Backlog has 300 stories. Not everything is important. Judging each item to see if it adds value. If not don’t do it(Work not done). Hence maximizing work not done is ruthless prioritizing as per business value. A feature is good enough to ship, but you end up doing some more work which is not necessary in the context. Don’t add any bells and whistles(Work not required/done). You can extrapolate this to other aspects of the project too.
Evaluate, if you need architecture documents or is there any other way of achieving same goal. Let me share an example here. On one project, instead teams spending time to write 50-100 pages of document to explain system architecture, I asked the team to video record the architecture with one of the system architect actually explaining the complete architecture. Here once again you saved your effort/time by not working on something(work not done) which could have taken more time and instead you chose to do it a different way to achieve same goal.
Matured teams don’t to estimation at all. Team is good enough in breaking stories to equal sizes and hence they track progress with number of completed stories. They are saving estimation time. Maximizing work not done.
Instead of expressing UI in detailed Visio diagrams, some teams prefer to just use diagrams on paper to convey.
So by trying to keep things simple and evaluating your work on value it adds at current state, you avoid lot of upfront work. I hope this helps.
I am currently learning Agile in my online course and came across one of the 12 Principles behind the Agile Manifesto..
10. Simplicity—the art of maximizing the amount of work not done—is essential.
I too could not grasp the concept as Xu Yi and now I understand “Not everything is important. Judging each item to see if it adds value. If not don’t do it(Work not done).” and that time for bells and whistles actually take away from a potential value added to another part of the development. Thank you Mr.Shiralige for this post.
Thanks Carlos. Agree. Identifying bells whistles within a big feature is a skill. Splitting such feature in stories help in identifying bells and whistles. Because very feature you build has more valuable and less valuable part into it. De-prioritising less valuable is simplicity.
Avie
I don’t think that “Just Barely Good Enough” is a good term to use. I understand that the key is defining “Good Enough”. And the point is not to make things that don’t add any real value past that point. But “Just Barely Good Enough” sounds like I deliver a pile of garbage with which the customer can achieve his goal, but he will hate me more and more everytime he uses the product.
Furthermore, I have a question about TDD. You mention TDD as an example of KISS. But doesn’t TDD require you to do a lot of work upfront from which you will only later reap the benifits (maintainability). I think this is relevant because TDD and Unittests are often skipped in the name of KISS. How can you justify TDD and Unittests under KISS.
@Matthijs,
I see good enough has some cultural angle too. I see it as not doing any gold plating of features that are Done/Shippable(this is good enough). It is not an excuse to delivery something of low quality.
TDD and unit testing gives benefits in short as well as in long term. Having robust unit tests and good coverage will help you in continuous integration. You will get the feedback of your build as soon as you commit. If you have good unit tests written, then there are less chances of breaking a build. If you follow TDD, then you right just enough code to pass the tests. You don’t add any fluff code. It helps in keeping code base small and simple to change and easy to debug.
I’m a little late to the game, here, but a friend just pointed this blog post out to me (thanks for the cite, BTW, Avienaash).
The primary benefit of TDD, in my opinion, is not maintainability, but rather an efficient design process. By defining what my code is supposed to do, and then coding strictly to those parameters, I don’t introduce things like unnecessary layers of abstraction, classes and methods that won’t be used, etc. I also avoid the ambiguity of whether or not I’m “done.”
Very nice article pointing out that simplifying tasks in software development process can definitely increase productivity, happiness and quality. The problem is that the human mind tends to think in a more complicated way, assuming that a more complicated solution is always a better / more sophisticated one and this is not restricted to software development. The same happens to our everyday lives.. From my experience “keep it simple” is one of the most difficult factors in the agile mindset, and if someone or a team achieves to adopt it then the results are going to be impressive!!
@Avienaash, I just realized today that you indeed have this article on “Simplicity – The Art of Maximizing the work Not Done”. This is one unclear principle for me since I started my Agile journey/practise about 3 years. In fact I sent you an email recently requesting for clarity or a post on this principle and I accidently found this article of yours today. Thank you very much. This gives good explanation and clarity. I would save this for future reference 🙂
Hi, appreciate the lucid explanation, keep it up !
One trivial correction – collaboration is spelt wrongly on the header, please correct !
Many thanks to Avienaash Shiralige for such a lucid explanation of what Simplcity means!
Glad you liked it.