Becoming Agile: The One Change
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
For some of us, taking an Agile approach to software development is easy. But for others, particularly companies who are established in a waterfall based approach to software development, embracing agile can be much more difficult. Anders Ramsay recently blogged about Agile UX and The One Change That Changes Everything, which gives some really useful advice on how to start your journey down the agile road.
What I really like about the article is that it emphasises that one simple change can trigger the agile mindset. According to Anders, that one change is "Just Enough Design Up Front", in contrast to Big Design Up Front.
For a lot of readers, this change in mentality might be obvious, or might be something that you've been doing for years: iterative development. But in practice, is this really the truth? Doing some level of design up-front makes a lot of sense, whether that's user interface design, or code design. I think that what happens all too frequently is that we add too much to the design. Too much time is focussed on questions like "What if the app needs to do this", rather than just getting the app to perform it's core functionality, and build on the design from there. The Big Design Upfront approach is appealling because we believe we're insulating ourselves from big refactors down the road. But maybe the "what if" case will never happen.
I really like the approach that Anders puts forward. It encourages more communication at design time thoughout the entire team. A big picture design is put together so that a system view is available to the team early on. The detailed design gets elaborated on throughtout the development process.
I'm sure there are many companies who have had success with non-Agile approaches. For those companies, unless agile can provide significant improvements in productivity, there's probably no reason to fix something that isn't broken.
For those who have successfully adopted the agile approach, what was the one change that changed everything in how you develop software?