7 Best Agile Practices You Are Better Off Not Following
The Agile development consists of different methods and practices that are very useful: splitting the projects into small packages to avoid risk and accelerate delivery; time-boxing to get the team focused on the tasks; considering only the working software as a measure of progress; using number of developed functions (items) to evaluate the team performance; working closely and permanently with the clients; and continuous Integration / continuous Delivery to ensure that code is staying stable and running.
However, there are other some situations and best practices that can be avoided in some cases: if you omit some of them, no negative issues will happen to your team and the project will still succeed. And there are some practices that you can totally abandon.
1. Programming in Pairs
Programming in pairs has several advantages: information sharing and increased code quality through permanent, non-formal code reviews since developers work together. There are obvious situations when to pair developers, and sometimes developers and testers, together: e.g. if you’re designing solution for a hard-design problem; or on a problem that you’ve never seen before and a developer (who has worked on it) can help you; or when you’re faced with troubleshooting a high-pressure problem; or testing a difficult part of the system; or when a new person joins the team and needs to learn about the code and coding practices.
The paired programming brings improvements to code quality over single programming, but you can get the same improvements of the code quality, if you rely on information sharing advantages, through code reviews, and the cost would be lower.
2. Test-Driven Development
If your project needs a faster development pace, your team will need more efficient testing approach. Using the Test-driven development (TDD), you can accomplish regularly writing tests – and also, you will have to write a failing test before you write the code. Thus, you will get a good set of working automated tests which provide a high level of coverage and regression protection.
Test-driven development is a tool that provides the developers to test their code. It is also proven itself as a design technique that leads to better quality code and a simpler, cleaner design. However TDD does not permanently improve the design quality. It seems to reduce code complexity and improve reuse; however it also negatively affects the coupling and cohesion.
3. Daily Meetings
If your team is quite new and everyone needs to get to know each other and more time to understand what the project is about; or if the team is working under urgent (pressure) conditions trying to resolve some issue or to meet a deadline under pressure, then holding the regular meetings of entire team, will be inevitable and valuable. But the situations when all stand up or sit down and what they end up talking about in a meeting – should be up to you.
When your team has been composed together for a while and they know each other and know the project they are working on, and if developers update regularly the cards on a task board (or a Kanban board) and the status in the system as they finish tasks, and if they are aware enough to ask for help when they need it – then you don’t need them all stand up in a room every morning.
4. Appearing Design
The development process in increments is fine, and if you keep the design simple – it is a good practice, but trying to define an ad-hoc architecture is stupid and unnecessary. There is a reason that almost nobody actually uses emergent design: it won’t work.
Today, developers do not understand the scope of the system metaphor, or how it will be used; or how to choose a right metaphor and change it if something goes wrong (when would you know if it goes wrong).
Agile development methods have improved the development process and provide tools to approach many different software development problems – excluding the design and the architecture.
5. Common Code Ownership
Putting all developers to work on the entire code is not always practical (since not every team member has the required knowledge, or expertise to work on every problem), so the collective code manipulation can have negative effects on code quality.
You should approach the entire code where it is sensible, but you should realize that not everybody can (or should) work on every part of the system.
6. Depending on a Product Owner
Having a single person as the Product Owner, as the unique voice of the customer and the “only man to blame” when the project fails, will not fit, and will put the team and the project (and eventually the business) at risk. This approach is wrong and dangerous in designing a product or in managing the development project, and it can cause more problems than it would solve.
Team leaders and members have realized this and they try to bypass the Product Owner idea because they have to. To be successful, the team needs real and uninterrupted customer involvement at multiple levels, and they should take responsibility themselves for making sure that they get what they need, rather than relying on one person to do it all.
7. Requirements Specification as Stories
The process in which the requirement specification is written as user stories in 2 lines (on cards), when the requirements are too short on purpose (so that the developer has to explain to someone what’s really needed), and insisting that they should all be in the same template form – is childish and not necessary.
In some cases it will be better to use a test case, or a detailed use-case scenario (or a wire frame, or any other type of model), because someone who knows the tasks list – has already determined the details for you. So you should choose the format and level of details that would work best in your environment.