The goal of this post is to make some clarifications and dispel common misconceptions about Agile Development. It seems that all teams, companies, and organizations today are claiming to be agile. But are they really? I’ve seen a few cases recently where teams and organizations believe that they are agile, but actually they aren’t. I’ve also worked with people refusing to use agile methodologies because of previous bad experiences, and I wonder if they had actually been using Agile methodologies or perhaps they just thought they were. It seems that the old Code and Fix is frequently confused with Agile.
If you and your team are supposed to be working in an Agile way and things are quite chaotic, I encourage you to read the items I mention below. It’s possible that if they apply to you, your team is not actually doing Agile correctly.
#1: You Don’t Write Unit Tests
Agile teams build their product in an incremental way, feature by feature. With every iteration, the teams adds new features to the product. One of the keys to Agile Development is that the product itself has to be always in a shippable state. This means that all the features that used to work before, must still be working after the team has added the new features of the iteration. This adds transparency to the whole development process, since now everyone knows what the state of the product is and what it can and cannot do.
The most efficient way to ensure that changes to the code haven’t broken existing features is by having a quality test suite that runs as often as possible. This is especially true when multiple developers and teams work on the same codebase.
#2: You Don’t Refactor
If there is one thing that slows us down, increases the number of defects in our product and creates uncertainty is bad code. Bad code and unsuitable design makes planning for and adding new features more difficult and unpredictable, which is something that affects the whole company and not just the development team. For these reasons, agile teams avoid bad code and keep the quality of the code as high as possible.
Refactoring is one of the main tools that we have as developers to keep our code clean. The idea is to do refactoring on an ongoing basis, along with implementing the new features. Each new feature may include a refactoring step, in which you make the necessary changes to make it easier to add the new feature and keep the quality of the code high.
#3: Your Team is Not Self-Organized
This is actually mentioned in one of the principles of the Agile Manifesto. It might also seem a bit counter-intuitive if you’ve never done it before. So, what does a self-organized team look like? Among other things, in a self-organizing team, its members are responsible for estimating how long each feature development will take, deciding who should implement each feature and deciding which of the most important new features will be implemented in the upcoming iteration.
If you think about it, it makes complete sense. Who is most qualified for estimating how long it will take to implement new features. Clearly, the people who know the system best and will be responsible for the implementation.
#4: Your Team is Not Full-Stack
Depending on the product you’re making, there will be features that will require people with different skill-sets to work on them: Front-end Developers, Back-end Developers, DBAs, Graphic Designers, etc. Now, if teams in your company have been formed according to skill-set (e.g. you have a team of DBAs, a team of frontend developers, etc…), such features will need to be passed between teams. As you can probably imagagine, the whole coordination process between different teams could make planning, completing and taking responsibility for new features very difficult.
A better way is to create teams based on the skill-set that typical features will require. For example, you can have or be part of a team that is composed of a Graphic Designer, a Front-end Developer, a Back-end Developer and a DBA. If the team has all the necessary skills and knowledge to complete a new feature, the team can estimate, implement and take full ownership of the feature development from start to finish.
#5: Your Next Release is Months Away
One of the advantages of Agile Development is that the product is always ready to ship. With every iteration, new features have been added and the product can potentially be shipped. This is particularly true for cloud-based solutions.
Another big advantage of Agile Development is that by building the product feature by feature, we can concentrate efforts in creating concrete features that the business actually needs and not in laying the foundations for potential future features that may or may not be required. This is particularly important for new projects, since the development team is able to deliver a basic working product with a basic set of features very early on.
#6: You Don’t do Retrospectives After Each Iteration
I think that retrospectives after each iteration, in which the team discusses what worked well and what needs to improve, are one of the best ways to make sure that the team is working as efficiently as possible. Things won’t always go smoothly from the beginning, some processes will work for a specific team and organization and some won’t. If we want to maintain what worked and fix what didn’t work so well in previous iterations, what better way than for the members of the team to talk about it and come up with their own action points?
Do any of the signs above apply to you? Once you start using agile methodologies and see how they improve the whole development process and your day-to-day experience in the office, you won’t want to go back to whatever is that you were doing before.