Posts Tagged ‘Waterfall’

Who says you can’t be big and agile?

Lou Gerstner of IBM famously said “who says elephants can’t dance?”  Can big organisations act in an agile way? Do they have to throw everything (traditional methodologies) out and start again?  To be agile do you have to go completely Agile and use all Agile methodologies.? Most companies according to research seem to be adopting a hybrid approach. The term Water-Scrum-Fall has been coined by Forrester to describe waterfall processes at beginning and end and Agile (Scrum) in the middle.  It recognizes how many firms blend an approach of writing most requirements up front, using time-boxed sprints to code, and then falling back on traditional big-bang deployments.  Sure there are some companies that are fully agile and Agile but there are some that are fully waterfall but can still adapt sufficiently to their environment. Why? Because they have different problems to solve.

Different customers  require different approaches

Agile methodologies tend to be better in smaller and innovative environments. Waterfall are still best for very large scale project coordination and where features must be delivered at a certain time e.g a datacentre move.

• Management need a business case. A new product development  requires investment and a return on that investment within a specific time. Management require a business case and a plan and a commitment to deliver. Sufficient planning and detail is required on what will be delivered and when.
• Operations require predictability. They require new features at a specific time in a way that can be launched without causing outages, or downtime on critical services.
• Complex projects need co-ordination and formal communication. In complex projects with multiple teams they will be dependent on each other to deliver specif items with specific features at a specific time.
• Customers have their own preferences. They may or may have the time to be giving constant feedback
• Are the requirements stable and known, or unstable and unknown?
• Do critical and expensive resources require to be scheduled?
• Development teams can only predict so much. The only risk free prediction is when it is delivered. Documenting the future may kill the future.

There is no one size fits all. The trick is to apply the right approach in context, according to the needs of business leaders and recognizing the pace that the organization can successfully absorb new ideas and new methods and if they are right for the problem in hand.

But approach is only a part of a successful solution

Regardless of approach the following parameters will have a large impact on the success or failure of a project.  If there is no management sponsorship then a major project will fail. If the business objectives are not clear then it will fail. The amount of information available upfront may dictate approach. Little information upfront may dictate  an agile approach…but it will probably also mean that only a little money is approved and that approval will be required after every increment. A company that is dominating its market and is deciding to spend some of its cash pile on entering a new market is in a much different position than a company that is a follower in the market and is trying to deliver a large customer contract.

It is more important to be agile than to be religious about Agile methodologies.

Parameters derived from my own research and experience. Used the Chaos Manifesto 2013 for some input. (There are questions over the details of their research but some of the macro stuff seems ok)