- 1.Agile development for custom web and mobile applications
- 2.Why agile development makes sense for your business
- 3.Why scoping is pointless for agile development projects
- 4.What does an agile development project look like?
- 5.The role of a product owner in agile development
A question we often get asked when clients approach us at Flicker Leap to develop applications for them is, “How much will the project cost and how long will it take?” This is a fair, but loaded question. I’d like to take you through why I think it is scoping is pointless for development projects, especially when it comes to agile development.
In the first post of this series, I discussed some of the consistent issues faced by waterfall development projects. They were mainly around understating the full requirements for the project without understanding every roadblock and without any real data on the needs of customers. There are some exceptions to that, but these exceptions are very rare and also don’t always cover the needs of a perfect scope. Here’s a quick recap:
- No one really knows the full extent of their system’s requirements.
- Business owners often don’t have an in-depth understanding of technical specifications.
- Similar to the above, business owners are often biased by technical jargon they have come across.
- Most importantly, end customers are often not included in the scoping process, which means that actual users have not been included in a product they’ll ultimately use.
These problems are faced daily by development teams who are still building projects using the waterfall approach. Sometimes the development team wins by getting the project done within scope, but most of the time projects go over time and cost forecasts by large margins.
I find it easier to remind myself all the time about why exactly I am doing what I’m doing. I mean, it’s easy to get caught up in exciting innovation and cool technology, but we are doing one of two things:
- We’re trying to solve a pain point for customers, or
- We’re trying to solve a pain point for our employees.
Now, we can get around the issues mentioned above by doing a lengthy discovery phase, which entails days of investigation and interviews with various stakeholders. These generally cost a lot of money and also don’t solve the issue of not being able to pivot to undiscovered needs and changes in a business climate (read the first post to get a clear picture of how this looks).
In agile development, we definitely don’t want to waste time on lengthy discovery phases of entire projects. Don’t get me wrong, discovery is important and it should be done on every user story – this is critical to successfully understanding what exactly is needed. However, the important objective of agile development is getting data that will help us define exactly what we need to do next to deliver more value to the user of the application.
Something I have always believed is to build fast and update fast. This allows us to quickly deliver value on a consistent basis, which is critical to successful projects. This is why scoping development projects, especially in agile development, is a waste of time and money.
Get in touch if you have an app or web idea that you would like to get developed using the agile methodology.