Agile Zone is brought to you in partnership with:

I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Becoming Agile: The One Change

07.26.2010
| 9942 views |
  • submit to reddit

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?

Tags:

Comments

Ivan Contramaestre replied on Mon, 2010/07/26 - 12:18pm

'But maybe the "what if" case will never happen.'

Actually, the "what if" will happen.  It may just not be the one you planned for. I.e. what if some of our assumptions are wrong, what if the company merges, what if the client changes direction (due to market reasons), what if the budget gets slashed (or doubles) and now the scope changes because of it... too many things (can't plan for them all)

One of the biggest appeals of Agile is the ability to change when the project changes with minimal risk.  Trying to plan all the possibilities for a software project will lead up to nothing if the business requirements change (due to unforeseen circumstances such as merges, acquisitions, legislations) or if the initial assumptions were incorect.  While the project is in-flight, the ability to meet change and embrace it to create a better piece of software is very valuable.

Planning can only get you so far; staying alert and smart to allow changes will take you the rest of the way.

 just my 2c

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.