It’s only recently I realised how much we tie ourselves in knots over process, and an obsession with adopting processes at a surface high-level, instead of properly analysing what is needed. Processes are generally treated as if it is not possible to integrate them into other methodologies. The classic case is the step-down approaches, which have long provided business with the milestone approach that makes them feel comfortable. Release or Sprint? How about a Release containing multiple Sprints?
Seriously, what is wrong with using Agile with milestones, if the business and/or client demand them? We can huff and puff about how important it is to follow Agile philosophy, but the world plain isn’t ready for 100% adoption, from senior management downwards. The wrong thing to do in software development is to pick only Agile or Waterfall and completely discard the other one for your project.
Given your circumstances and the previous considerations, you should be able to identify which you are going to pick as your main philosophy. But, there will be exceptions where it will be better suited to mix and match from both philosophies. For example, many Agile projects still require a lot of documentation so you may have to tweak your Agile process and introduce some Waterfall principles to generate the documentation. No matter if the project is considered an Agile or a Waterfall one, the main activities that are necessary to perform don’t change. What changes are “when” they are performed, and “how” they are performed. Development / QA can be iterative while being bookended by design and integration
I have learnt more by looking outside my field – after making the same mistakes as everyone else; assuming that software development is somehow special and doesn’t have look elsewhere to find successful ways of delivering projects. Whether in manufacturing, making music, or process of making a sitcom – I am seeing Agile in many other places. In industries where they don’t even use words to describe the process – it is simply about adopting the best way to get a job done. Agile can carry a much stronger punch and more transparency, when it’s principles are observed fully. In software development the biggest challenge is not making development more Agile, it’s making business process.
It is time that we realised that business and development processes do not have to be poles apart, and in fact there is much business can learn from development. Iterative development has many advantages over step-down approach(of which Waterfall is the most popular pariah), the key one being the ability to facilitate change in the development lifecycle. Decisions can be made and altered, as more is learned about the problem being solved, rather than guessing at the start. In this way the direction of development can be steered to ensure the system meets the needs of the users. The development process itself is also refined via evaluation. Integration of components is done during each iteration, which means integration problems are spotted earlier when they are more easily and cheaply solved.
Phases of product management disillusionment in waterfall development
Risks associated with the architecture of the system are also identified early on, and can be dealt with without major reworking of the product. Similarly, performance bottlenecks are spotted early and can be dealt with over several iterations. Bugs are found and dealt with in each iteration so the core parts of the system will have been tested thoroughly and repeatedly by the time the system is complete. This results in a robust architecture and high-quality product. Reuse is facilitated because it is easier to identify common functionality when encountering it during development iterations than in planning. Notice how many times risk management is dealt with in the above paragraphs. Just because the business world is struggling to adapt, it makes no sense to ignore Agile completely.
What is important to avoid is long iterations, otherwise you might as well stay step-down, for all the flexibility that will have. I would personally recommend 1-2 week iterations, as code can change a lot over a month, and developers could be working with wildly different versions, depending of the length of their task work. I am even tempted to say to go Lean(er), go for Iterative and Incremental, to keep development and requirements tightly bound, and minimise human error by adopting continuous integration (CI), by means of overnight build and test tools which run unit test suites and produce reports. This also maintains good practice of developers producing unit tests for their code. Waterfall intends to deliver a first version of a product, completed. That will be first time that the client will see the product is fully working version. Then ask yourself the question – what is stopping me from using Agile in development on a Waterfall managed project? The answer is – you.
Business world seem to love going on about transparency, but very few business approaches allow for it anyway – nonsensical. This isn’t new thinking – have a look at this article from IBM in 2009, and I am sure there are others even older. The biggest constriction will be how tight your milestone-obsessed ”Big Brother” is, regards recommended changes or deviations from requirements. But at the very least larger unforeseen issues can be highlighted to business far earlier than first complete Release. It is also worth remembering that step-down methodologies make development very expensive. Agile approach enables to react to any projects issue – be or code, or simply budget! Step down is success/failure route to a product – Agile enables failures to become lesson learnt to becoming improved product. It is long overdue that business needs to reassess how it gauges risk.
Don’t be cack-handed in your approach to implementing Agile practices. For example, using Scrum for project management on a refactoring project will make hard work of it, unless observing Incremental development practices (refactoring legacy projects notorious for nasty surprises). But for a new project, is far more appropriate – Waterscrum is in fact not the joke I first took it to be. What also can’t be underestimated is people. Agile promotes ideas around busy, happy cross-functional teams – these won’t magically happen by defining processes, some skilled management is needed. Ideally you would couple Agile development with Scrum or Kanban to project manage, but that is still a step too far for some companies.
Related posts:
