Agile tells us to the do the simplest thing that could possibly work for the things that we need right now. Why do we do the simplest thing? The answer: Because it is cost effective, especially because the future is unsure. For example, when the business does have something similar, are we sure they’re not going to want it to do something more that will need more work done? Or perhaps the cost of making something “general” could be better spent on more immediate priorities, because if it never gets used, the cost of building (not to mention maintaining) the general infrastructure is wasted.
So what if your business tells you that they want something for now, but make it general, so if they want to do something like it (but not exactly like it) they can reuse the infrastructure to do it again? Even if the business or the analyst is driving this requirement, it reeks of having a bad smell, and is probably driven by a Fear of Waiting. To me this could mean one of several things:
- Release Cycles are not often enough – Waterfall projects typical schedule a release for anything between 3 months up to a year or more. If requirements do not get in, it is a very long time until they are revisited. Agile addresses this with the Release Often principle that emphasises more requirements prioritisation over requirements identification and freezing.
- Too many competing priorities – With smaller release cycles providing more restrictive timelines, the next issue is working out what can be fit into that release cycle. Businesses typically have many competing priorities, with waterfall models trying to fit all of those priorities in (leading to bigger release cycles). Agile attempts to get people to prioritise what is most important to them right now.
- Not Enough Bandwidth – The amount of business value that can be delivered is a function of the fixed time that can be available and the amount of work that can be produced by available resources. I am specific amount the amount of work produced instead of simple the number of people because it is not simply about the number of developers available (read the Mythical Man Month if you want to learn more). Typical waterfall methods rely on judgement (estimates that become promises) to give a guide as to how much can be provided. Agile provides better metrics in the form of a historical moving average of points (e.g. storycard points) per iteration that indicate a better guide as to what can be delivered.
So what can we do to alleviate this fear? Agile has many values and two key ones that spring to mind is around visibility and communication. Visibility is about making people aware of issues (in this case, a fear) and to try to work out what the real motivation is (especially if it is not a real business need). Communication is about making the process transparent and how it is (or can be helping if it is not) to alleviate those concerns.
Hi Pat, How have you been?
I’ve just been reading through all your posts on Agile development, and I’m very impressed! I’m starting to look into this methodology as it seems that Agile processes could solve a lot of problems that my team is facing with development atm (ie, projects ridiculously over time (poorly estimated to start with), specifications never complete and requirements still changing during the deployment phase, frustrated business users because IT never deliver anything, no concept of testing, etc, etc).
I’m very interested in trying to implement these processes in what I do, but need to find more information on 1) how to manage projects run under Agile processes and 2) how to actually do it :-). I was wondering if you could recommend some first level books on the subject that you may have found useful and if you have any suggestions for transforming a development environment that has no process or procedure around development to start with (I know its shocking, I hate it) into an environment that can use Agile processes to start to deliver better value to the business more efficiently?
-Amanda
Hey Amanda,
Things have been well. Thanks for your comment and positive feedback.
There are many places to start with agile, although it may seem overwhelming. I really liked Jason Yip’s post as a simpler way of describing agile.
If you want to go with some background reading, there are a few published books, the most well knowns ones to start with are probably the white book (XP Explained), Agile Software Development with Scrum, or even Crystal Clear (more a meta-methodology). These books definitely help with giving you a guideline, but it is always easiest to start implementing foundation principles of agile where you can see them most accepted by your oragnisation. Start introducing unit testing, constant refactoring, continuous integration, continuous user acceptance and small iterations for feedback to be fed in for process refinemnent).
On the other hand (*company hat on*), if you can convince your company it needs some advice, we have a loads of people who can show how well it can run and how much more business value it can deliver (*company hat off*) ;-).