Lessons Learnt for Agile Development Business Transformation (Part 2)

By Gustav Coleske – Mendix Consultant & Lead Scrum Master.

My first blog touched on the differences between the traditional waterfall approach and agile rapid application development. Now it’s time to explain the next steps in the transformation process.

Identifying The MVP VS. Blueprinting and Functional/Technical Specifications:

What is an MVP?  To quote Eric Reiss in his article on “Startup Lessons learnt”- “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about clients with the least effort.” This is known as the MVP – Minimal Viable Product.

Identifying a product that is ideal for the Agile approach tends to be a bit of a problem for clients using the Waterfall approach.  Clients using the Waterfall approach tend to want a product with all bells and whistles that cater for all their requirements at the end of the build and test phase (near the end of the project).

Which projects are typical of the Waterfall approach and which projects are good for using the Agile approach?

Writing a complex payroll for a company is typically not a project undertaken using Agile as this cannot be implemented in stages.  There are simply too many complex rules that cannot be implemented and the product should be a final version catering for all these rules.  Writing an application that allows a new joiner of a company to upload eligibility to work documents, which are uploaded to the company’s HCM system, on the other hand is an ideal candidate for this.  It’s a function that can be implemented quickly and can evolve to include additional functionality for new joiners, which can be implemented in subsequent phases.

Sometimes project stakeholders can lose focus of the outcomes of the MVP.  Once the MVP is identified, it is important to focus the product team on what should be achieved to resolve this business problem.

Agile Requirements Gathering:

With the Waterfall approach, requirements are fixed and very expensive to change the further the project progresses.  This works well if clients know exactly what they want, developers know exactly how to build it and things don’t change along the way.

Unfortunately this is true in very few cases.  The reality is that clients discover what they want, developers discover how to build it and many things change along the way.  Agile caters for this by allowing changes to be reprioritised in every sprint.  Changes to user stories in the backlog are allowed at any time.  During the sprint planning session clients decide what they want to include in the next iteration (whether this is existing or new stories in the backlog) and what to include in a development sprint.  Priorities of user stories may change and the Agile approach allows for this.


For the right type of project, comparing the time taken to capture user stories and sprint planning with the typical time it takes to run workshops, blueprinting and writing of functional and technical specifications for waterfall, the Agile approach is markedly faster.

How about you? If you’ve tried agile development let us know your thoughts. Or if you’ve only experienced waterfall how come? Just leave a comment below.

If you would like to discuss the projects undertaken by our clients please get in touch. Alternatively, download our free e-book on how digital applications can drive business performance. 

One thought on “Lessons Learnt for Agile Development Business Transformation (Part 2)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s