Perfectionism vs. Incremental development

IMG_0290First of all, this is a very tricky topic. Even though, perfectionism doesn’t contradict incremental development and incremental development doesn’t contradict perfectionism, these terms aren’t best friends for now. Perfectionism tends to focus on details while incremental development addresses optimizing value and taking right direction. Incremental development is supported by agile mindset. Perfectionism in this paper is mitigated to a mindset of a desire to develop perfect solution.  

Perfection in agile environment

The idea of incremental development in software industry is delivering components of the expected solution as opposed to the delivering a complete solution in one go. The way of delivering these components is dominated by iterative approach. However, how do we know that the components delivered in timeboxes compose a perfect solution? Getting the final and complete product would be easier to evaluate. In the beginning of an agile project we don’t know the exact form of a final result. The details emerge during project lifecycle. Perfectionists are out of their comfort zone in agile projects, though. Components developed for certain stage can be complete or in an interim state. These can deliver vertical or horizontal cross-sections of a final product. There are different forms of interim solutions. These are usually models or prototypes. However, can a prototype be perfect? For some cases it will be perfect while for others won’t be. Prototype will be considered as a perfect solution when it fulfills all the requirements for certain stage. For example, if the expectation is providing valid tax computation regardless of the solution design, security and performance then the prototype can be considered as a perfect one. In case, when we think about production ready solution, the prototype is far away from being perfect. Business people violate agile development and promote perfectionism by expecting wide-scoped results delivered after long timeboxes and neglecting giving early feedback. They are focus on the final result. Developers tend to implement functional or non-functional requirements not intended for a given iteration. In result, the iteration’s scope is extended into unplanned items. In a proper agile process both business people and developers have to develop agile mindset and a have common understanding about a way toward the final perfect result.

Today’s computer software industry faces very complex business requirements with the tendency to be chaotic. The requirements complexity is transferred then to development process. We won’t get perfect software product without a perfect software development process first. We cannot expect perfect result without perfect way to get into it. Considering “The end justifies the means”, we say it’s a short-term and naïve way. “The means” should be perfect as well i.e. allowing organize work respecting long-term people involvement and performance.

Incremental Development prerequisites

If we agree that perfectionism is a mindset of a desire to develop perfect solution, we can define the following list of MUSTS for an agile product development process. Some of the points address product while others address development process. The list contains general assumptions addressing particularly contradictions to the traditional perfectionism issues faced in agile environment.

  • Imagination
  • Technical excellence
  • Domain knowledge
  • Agile mindset
  • Continuous Integration & Continuous Delivery
  • Working in timeboxes
  • Functionalities prioritization and MVP mindset
  • Let’s discuss the prerequisites.

According to Albert Einstein: „Imagination is more important than knowledge. For knowledge is limited to all we now know and understand, while imagination embraces the entire world, and all there ever will be to know and understand”[1].If we can imagine a result, we can also avoid additional costs. It doesn’t always make sense to finish our work. If we’re working on a PoC achieving certain state that we’re pretty sure what will be a result or an impact then we have the opportunity to share that with stakeholders. We can take further action before we decide to finish and polish the final perfect thing. All the forms of prototypes require much more imagination than final product does. Moreover, final product usually should be as simple as possible. It requires limited imagination and effort from final users. It’s easier said than done. Imagination in fact is more important than knowledge but still requires appropriate skills, experience, dedication and intuition.

Technical excellence is when we have appropriate skills and approach to master product and process. It points to the whole development lifecycle, not only design and development.

Domain knowledge is a prerequisite to understand the purpose of the product including various contexts and circumstances.

Agile is about maximizing value in time. It’s about continuous inspection and adaptation. There is the Manifesto for Agile Software Development[2].

Continuous Integration & Continuous Delivery and Working in timeboxes are parts of agile mindset.

MVP – minimum viable product – is a product with just enough features to satisfy early customers, and to provide feedback for future product development[3]. Similar term - Minimum usable subset[4] - requirements which the project guarantees to deliver. Expected business result assumes delivery of a perfect solution. The perfection won’t be achieved by delivering only the SHOULDS.

Incremental development benefits

  • Early feedback
  • Cost saving
  • Opportunity to develop a valuable solution
  • Works properly for many software projects

Incremental development limitations

  • Not suitable for every project
  • Requires respecting all the prerequisites

Summary

Perfectionism isn’t about getting it all and now in the final form. It’s more about ability to imagine the final solution and delivering intermediate states during project lifecycle and organize development process bearing in mind both product and people.

References

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>