"The pressure of delivering should never outweigh the pressure of delivering the right solution."
In Agile Development the company as a whole is often tripped up by the undue pressures put on the Product Team. Stakeholders always wants more than can be delivered in a given time frame, they want it yesterday, but they also expect it to be strategic. Yes, essentially they want it Cheap, Fast and Good.
In the "Agile delivery" scenarios that often evolve around Agile Development shops, a pressure-cooker style product management approach begins to take shape by default. The Product Team optimizes by beginning to boil down the deliverable expectations to the exact solution that was described by the stakeholders. This allows them to remain with their head above water and allows everyone quick wins that verify that indeed "Agile is working".
In this common scenario however, the product team is subconsciously never really allowed to plan for the future. Not taking enough time with the stakeholders (and leadership) to understand what they want vs. what they ask for begins a sort of solutioneering life-cycle. This does in general satiate the documented need and gives everyone immediate reasons to celebrate; but a lot of knowledge and opportunity is lost in the process. This is usually not noticed until much later; many Sprints into the Agile delivery process. At this time the company usually begins to stagnate with products that are in the wider market seen as un-remarkable. What defines truly remarkable I will save for a future topic. (Hint: it's not about spending big bucks with a design agency.)
Effort vs. Real Cost
As Feature Requests are boiled down into User Stories that minimize the perceived necessary Effort (note: in-sprint development hours ≠ real cost over time), the deliverables are usually too customized to properly be reusable and have any long term benefit. Plus the User Experience is probably handled by just sticking it somewhere on the existing screens, or asking a UX person where they should put it. In many cases, if you assume they'll be able to magically fix your User Experience at this point, you may not want to know where they think you should "put it". Though a good UX practitioner will hopefully have engaged with you long before. |
| The pressure of delivering should never outweigh the pressure of delivering the right solution. |
Over time, this just piles up in an unrecognizable mess, at least to the person who started the company with the goal of changing the way things are done.
If you don't plan ahead (something that is often shorted by merely "trusting the Agile method" too much) and you don't allow development to ever re-factor something (a foundation of Agile Development that is often skipped due to the pressure of too many short-sighted Feature Requests, aka. solutioneering), then you are really just creating really tiny waterfalls.
In true Agile fashion, you could just let each development cycle handle deciding whether you found the right solution; or you could adopt a more agile approach within Product Management as well and delivering more thought through User Stories to Development. These stories would already have considered the future, at least in terms of validating the proposed solution.
That doesn’t mean that first delivering the Minimum Viable Product and staying Agile doesn’t still hold true. Delivering the Right Solution is still helped by the more nimble Agile approach. The point really, is that Agile Development is not an excuse for passing on Unvalidated Ideas to development. Development has enough things to juggle and figure out. Help them understand where you are collectively headed and help them understand how things are best formulated for the most flexible application (within scope of the long term direction). This puts you in charge of the direction instead of reacting to yesterday's needs.Build towards your vision every day, starting now.
Don't put the right solution off by sentencing it to the prison of the unreachable 'tomorrow'. Make sure you’ll get the pieces you really want, not just what you need in order to make it through the day. If you act like a burned out also-ran, you're more likely to become one.Plan intelligently. Empower your developers with the information you filtered out. They will still pass things back into the sprint for adjustment, but you're less likely to throw away an entire pie, when all it needs is a little more time in the oven.
