Last year I wrote a short article explaining what Agile development was about and how some people generally miss the point and assume that to be Agile you have to follow something like Scrum. This article pointed out that Scrum was merely a project management tool for helping you to be agile. With this in mind, there are still a lot of misconceptions about what it is to be Agile, so I thought I would list down some of the ones that I have heard and counter argument them.
Agile is ad-hoc, with no process control
To be properly agile you need to adhere to the agile manifesto, but following the manifesto doesn’t mean you are using a defined process. The manifesto describes a set of ideals. There are various different processes and project management templates that you can apply to your projects to help you become agile. Extreme Programming (XP) and Scrum are the most popular.
When you try to implement the manifesto items you generally need to apply a lot of common sense and pragmatism to get to your goal, but if you want to wrap a more formal process around the ‘How’ of agile as opposed to the ‘Why’, then you would apply something like Scrum, which gives you more formal processes like epics, stories, iterations, stand-ups, demo’s, retrospectives , test driven development, pair programming etc.
Agile is faster and/or cheaper
Running an agile team doesn’t mean you will finish a project quicker or for less money. It isn’t a direct money saver in that respect. What being agile about is delivering value to the business sooner. You head towards working versions of software quicker. At the end of each development iteration you are supposed to have working software to demo to the business. It may not have all their requirements in place but what is there will work. This means rethinking about how you plan your work load in each iteration. Instead delivering horizontal slices, like for example, the Data access Layer this iteration and the User Interface next iteration, you think in vertical segments. This means you deliver defined pieces of functionality in an iteration that may encompass work on the User Interface and Data Access Layer. It’s a mind shift change that I have seen teams struggle with if they are used to working horizontally, but when they finally ‘Get It’, the efficiency of a team is increased remarkably.
Being Agile is also about being able to respond to change, embrace it even. Requirements change, businesses can change part way through a delivery. I have worked with teams that treat this as a real negative thing. If you want to be agile, you need to expect and welcome these things. The tools and processes of Scrum, for example, are designed to help you react to these changes in a more efficient manner.
Agile teams do not plan their work or write documentation
Being Agile is not an excuse to avoid appropriate planning or writing documentation. Agile is an on-demand, or Just-In-Time, approach that encourages continuous planning and documentation, but only when needed for specific Customer Requirements. This allows Customers and Teams to determine if the planning, or document, adds value to the process or product. It creates an opportunity to emphasise valuable documents, and eliminate anything that isn’t useful.
Depending on what type of company you work for, formal documentation may not be something you can avoid. For example if you work in a very heavily regulated environment, then lots of upfront documentation may be needed for evidence, and submission to regulatory bodies. If this is the case, then the delivery team will need to take this documentation into account. I personally prefer to work with large diagrams instead of lots of text. If you can, get these diagrams printed on on A3 paper and then put them all over the walls so you have something to refer to in stand-ups.
With the planning side of this, you still need to do it. At the beginning of each iteration, you should be having planning sessions where you allocate user stories for that iteration. The amount of stories you allocate will be based on the estimates given and the velocity of the previous iteration.
An Agile project never ends
This might be true in some situations. You should continue to work on a project while the Customer continues to get business value, and that value is worth more than the cost of developing it. Most projects, in any industry, have a point of diminishing returns. This is the ideal time for an Agile project to end. This decision should come from the business though, for it is them that you are delivering value.
Agile only works for small organisations
Agile works for projects, teams and organisations of any size, not just small projects. This doesn’t mean it will necessarily work for all organisations, but size is rarely a factor. Large and complex projects and organisations are often excellent candidates for Agile transformation, where it is difficult, or impossible, to know all your Customer’s Requirements in advance.
Following an Agile methodology like Scrum doesn’t always work in all circumstances though. I have recently (at the time of writing) worked with a team delivering pretty well defined, but very tight time-scales regulatory and compliance projects. Due to what was involved the team and the business came to the decision together that using Scrum would not be suitable in this circumstance, where as for a new product that is in development, Scrum and more Agile ideals are being adopted.
Without upfront planning, Agile is wasteful
This assumes that your Customer knows the detail of all of their Requirements in advance. If this is true, then by all means, undertake comprehensive upfront planning. However, in reality this is rare, and usually leads to the greater ‘waste’ of having undertaken design and development work that was ultimately unnecessary. Agile Business Management encourages minimal upfront planning, ensuring everyone is working towards the same goal, and reduces the risk of miscommunication.
Agile is not the solution to all your problems.
Agile is a change in approach and culture that comes with its own set of benefits and issues. If you are working in a well established team that has not been following any Agile process, then changing them over to it will not be an instant thing. You need to do it slowly and make sure everyone has a say in the decision making process otherwise you may hit resistance from team members who fear change, which is a normal human characteristic. Convincing your team isn’t the biggest hurdle though. Your biggest challenge is making sure your leadership team understand and want to adopt an Agile way of working. Once you have achieved this, then the rest of the adoption just takes a little time and patience as everyone adjusts.