Agile Misconceptions - Part 1
Most people use the word 'Agile' to describe how their project's life-cycle is run. Seems like agile has become so prevalent in software development that not mentioning it makes project look very old-fashioned. Its use is similar to the word 'passionate' used by developers in their resume, as if they don't use it, they won't be considered a good developer.
Working in agile projects and projects thought to be agile over the years, I've experienced following misconceptions among business analysts, project managers, stakeholders and developers:
- Agile means constant change: One of the goals of using agile is to embrace change. However, it doesn't mean constant change is agile. I once came across a team member who said 'beauty of agile is we can change requirement anytime, we can do anything you request'. Well, yes and no. Yes, we can make changes to requirement but try not to once you've already drafted requirement, agreed on story points and developers have committed to it. When you put a task in backlog, it should have passed the business requirement analysis and there should be no confusion on whether its required or not. Also, a story should be complete (see INVEST) with proper acceptance criteria. What I've seen very often is, there is a task with title but no or little description, they're put into a sprint, developers start working it. When developers present a scenario, business expert or project manager have no answers. They instead have to send an email to product owners back and forth, which hampers developer productivity. So, agile does embrace change but make sure stories put into a sprint are well thought of and all tasks allocated in a sprint are do-able. It might be hard to get it right first time around but after few sprints, everything falls in place.
- Agile means no documentation: This is another very common phrase I hear. Agile principle says "working software over comprehensive documentation". It doesn't say No Documentation. Ultimate goal should be to ship a product that end users can use but to build one, we do need documents. Not a waterfall style documentation where business analysts and project managers spend months to complete, another couple of months to get approved and more time for technical team to understand what is there. On other words, most of the comprehensive documents from waterfall era focused a lot on implementation. It went into details on how a technical team is supposed to build the software instead of what the software's ultimate goal is. In agile, goal is to have a higher understanding of the business, why a product is being built, what should be built. How to build part should be left to developers because that's what they do. So, make sure there is a proper user story for each of the features. These should be broken down into smaller chunks of testable, estimate-able and specific stories. To make sure these are traceable, developers should have IDs of the stories or code (depends on what tool you use) in each code commit. This will make sure all stories are linked and you can trace them later if product owner asks why it was done or who changed requirement.
- Agile can't be used in old projects: Agile isn't a programming language or a technology stack. Whether you can use agile or not depends on your team's commitment to your project. If your team members are ready to change the way they work for better, then you can use Agile. Once you've made your decision, you may need some training on agile development and a ecosystem to succeed. Your management or product owners should be ready to engage more, business analysts should be ready to work hard on user story and developers should be ready to push code quickly. Old projects do present challenges, however they are all discipline related. Its just that people are used to do things they've been doing for a long time. To motivate changes in their discipline, ask higher level management to communicate it to all members. Apart from that, with right tools and guidance you should be on your way. Remember, you don't have to go by the book of agile. How agile is implemented in a software development house will be different than how it's implemented in a non-IT company's development team. For example, a software development house may have a continuous integration/ deployment with dedicated resources to push code every day to production. This may be definition of done for them but it might just be making sure code is committed and pushed to development environment for testing in a in-house development team. Just give it a go, and with time it'll get better. Don't get intimidated by the agile books and articles on perfect agile team. It's all about iterations.