October 30, 2015 // By Ryan Hanisco
Working in the consulting field, I get the privilege of seeing a wide array of applications and the business challenges that customers face. This means getting a lot of system walk-throughs and having candid discussions about the product lifecycle challenges they are facing. Sometimes these are an opportunity for a customer to show off how they have solved a particularly complicated problem and built a process to evolve the solution with the business. Usually this is not the case. Usually, something has gone wrong – not out of neglect or lack of ability, but out of organic growth that wasn’t planned and started out bad from the beginning.
In these situations, we’ll walk through the application talking about technical debt, bloat, a lack of unit tests, scalability issues, a need for test automation, bug regression, and general fragility. This is what every company dreads: a mission-critical system that isn’t keeping up with the organization’s rate of change, but that no one wants to change because even looking at it always results in server crashes and down time. As soon as the boss walks out of the room, the architect wants to confide that this was a proof of concept (PoC) that was rolled into production and evolved into critical infrastructure over the years.
Yikes.
This leads us to an interesting cross road. Agile wants to identify an implement a minimum viable product (MVP) as quickly as possible and move that in to production so that the business can begin to reap the benefits early and begin accumulating ROI while the next sprints add new features and refine the implementation. It is tempting to think that a PoC is a first step toward MVP and should just be the baseline to which more features are added as you chase a production-ready release. I mean, if the PoC looks successful, why not use that? It should be cheaper in the long run right?
Going into a PoC with this attitude dilutes the value of the PoC and making this decision after the fact hurts your MVP. One of the core tenets of Agile is that you want to fail early with the least impact. This is what the PoC is for. You are trying to prove out a single concept or architectural principle. This means doing the bare minimum needed to show whether the path will bear fruit or should be abandoned. You drop enterprise architecture, documentation, good coding practices, security planning, enterprise scalability, TDD, etc. just to show that the idea is worth incorporating into the final solution. Fail fast with the minimum effort needed to evaluate the concept in test.
The crafty PM might suggest that you build the PoC, but with the same rigor and planning that would go into the final solution, so that if the concept works out, you can just add to it to get to the final solution. This is basically gambling. If the PoC works out, then you are ahead, but your bet had better be right. More often, this approach will slow the team down as they are afraid to do any PoC as they’ll not want to waste the team capacity unless they’re sure it’ll pan out, cutting the creativity and risk-taking from the team. This leads to slower velocity, slower reaction to change, and stifled innovation. This isn’t what agile is about; it puts the waterfall metrics on the team and sets them up to fail.
Lastly, there is often a communication gap in these scenarios. The team will work in that barebones, ghost-ship mode to prove something out – It’s just a PoC, right? But if they are successful, they will be forced to roll that into production and build on top of it. No one is willing to say, “If we build it to be production ready, we'll clearly have invested too much effort in a PoC.” They are afraid the project leadership will blame them for poor coding or a lack of attention to engineering principals. If they develop a PoC and the leadership sees it as development for MVP, nobody wins.
The solution is better communication. A PoC should be minimum investment in time and resources to prove a point and validate a technical path. Once it is validated, the path ahead should be easier, the uncertainty is greatly reduced. NOW, the team can move forward with a new implementation built to enterprise standards. In the long run this reduces costs, reaches MVP quickly, and avoids having expensive conversations with a consultant five years from now.
To learn more about the challenges that can be faced when adopting Agile and the steps to take to overcome them, read the exclusive Forrester report, “Leverage Agile to Meet Customer Demands and Software Quality Needs.” If you’d like to speak to Magenic directly, email us or call us at 877-277-1044.