In the promotion of agile practices, there has been much discussion of how big-design up front is antithetical to effective delivery of business value–because it focuses too much on theoretical musings on what people need and how we might solution that rather than explorative prototyping of incremental business value; in other words, it can lead to analysis paralysis.
Before you start some work, always ask yourself three questions: ‘Why am I doing it’? ‘What might the results be’? and ‘Will I be successful’? Only when you think deeply and find satisfactory answers to these questions, go ahead.Chanakya (370–283 BCE), Indian teacher, philosopher and royal advisor.
Discussion of agile pratices typically focuses on development–saying that open communication between stakeholders and developers leads to the most productive results–that does work, so is good as far as it goes as a principle, however this raises more questions:
A growing number of reports indicate that too many resources and too much funding gets invested in projects that do not contribute towards their organisation’s strategic goals. With the transition of agile practices into the mainstream, this has become a growing trend, as the focus can too easily be on what the individual product owner ‘feels’ is right.
This is a failure of adequate planning and governance, rather than a problem inherent in agile practices themselves, so in this article I wanted to explore why it makes sense to invest more rather than less in up front assessment of initiatives.
Once projects and teams get into delivery mode, then everything espoused by the developer-centric agile methodologies is appropriate.
The great thing about agile practices is that there is a regular cadence, or heart beat, to work being released and inspected. This gives the team and the owner the opportunity to ask the question if they should still continue, if they will deliver more value than the costs, or if they have reached the tipping point of enough value and can safely stop (with the option of starting again at some point).
Contrary to most traditional views of agile practices, there is more oversight and more discipline involved on agile projects, because this governance check point is effectively built into the team delivery process.
However, before delivery mode, it is important for an organisation to determine why it should be in business, what vision and strategy it has, where it needs to be going, what the gap is in-between, and the steps it needs to take to fill that gap. This requires strong strategic thinking and enterprise analysis–although it doesn’t have to take 6 months (as many organisations do).
Once there is a strong sense of direction and objectives, then any new product concept or business improvement initiative can be tested against that. If it fits the strategy, or even if it doesn’t but it’s a direction in which the organisation is interested, then it’s worth considering setting some money, people, and time aside to deliver something.
On new systems, especially web-based ones, it might be safe to just jump into delivery and let the solution evolve as you progressively work through; however on many systems, especially those with interfaces to back-end systems, those based on legacy platforms, or those that will affect thousands of people, it still pays to take a moment to consider the impact, to consider the building blocks, and confirm the direction.
In conclusion, then, thinking up front is not the same as big design up front, it’s just enough architecture versus just in case (i.e. everything you can think of before you start); and sometimes the last responsible moment to do something is right at the beginning.