Anyone who has been involved in software development for large enterprises should know, that Change Requests (CRs) during project execution are inevitable. And thus, delay and cost overrun is also inevitable.
Enterprises can outsource this risk to a vendor, but some large enterprises have their own in-house IT department who build these custom software products.
Both external vendors and in-house IT quietly dislike the Waterfall model…
A total of 9 months later, the product is finished. Phew!
This happens *A LOT* with software development projects.
You’d be either lying or too young if this never happens to you
Now deployment after the product is finished.
Large enterprises have various tools and Standard Operating Procedures to follow.
• Have we gain authorization from external regulator to launch this?
• Have we perform vulnerability assessment test?
• Have we got the 10 signatures we need to deploy?
In the end, the product launches almost a year after the conception of the idea.
What if this is a groundbreaking innovation that can change the competitive landscape, and another competitor has launched similar product 3 months early??
Enter Agile Development for the Enterprise.
• If a business user has an idea today, the product development can be started tomorrow.
• The idea and the product are refined as the development goes along.
• Changes are embraced, instead of disliked.
• Minimum Viable Product is discussed together, what to launch first to customers.
• After the MVP launches, improvements can be deployed frequently.
We all love the idea of being able to operate like a professional startup, where they deploy hundreds of times a day to production.
But not only traditional enterprises do not have the engineering capability of LinkedIn or Facebook, but also it is not suitable for them. The way to achieve this, is by finding something in the middle between the agile extreme and the discipline of waterfall model that traditional enterprises are used to:
As you can see from the diagram above, it is the same as waterfall BUT on a 2-week sprint timeline.
If you’d like a complete team structure it can be as below.
And the two-week sprints are divided as follows:
We have used this model for over 2 years and it works. Any suggestions? Ideas? I’m open to feedback 🙂