Agile Best Practices
What persuades me to write this blog is the question which I face every now and then, that is, what are the best practices of Agile or Scrum methodology? Though I respect the curiosity and enthusiasm of learning best practices of Agile but at the same time I would suggest to first know the principles and manifesto of Agile. By knowing the Agile principles well, teams would in-evidently or evidently not only adopt but also come-up with the best agile practices for the team.
In reality there are so many Agile best practices that you might need several pages to cover them all, but based on my experience I can write down a few which I witnessed to be used by many successful agile teams. It does not concur that these are the only Agile practices that Agile teams should adopt to be successful. It only suggests that following are a few important best practices which if implemented correctly may help team to be successful.
1. Creating Effective User Stories using INVEST
In one of my earlier blog I mentioned what are user stories and how those need to be created using INVEST acronym. If you have any difficulty in writing a user story, this blog may help you to write effective user stories. Writing user story by using INVEST acronym is considered one of the Agile best practices because of the each letter provide following benefits to the team.
- Independent: It assures that each user story is independent business requirement. Since there is no direct dependency involved in implementing the user story, a team is free to choose any user story to implement in any order.
- Negotiable: In agile stories are just like wishes. This is something customer wants to have, but it does not mean that it can be developed easily. Developers get the chance to discuss user stories with the product owner. That discussion is what help teams to understand the requirement in detail and it also gives some insight to the product owner regarding complexity involve in developing the user stories. That discussion may also lead to a better and easier solution for same wish.
- Valuable: It should be clear from the story that it produces value for the customer. When development team to understand the value a user story is adding for the customer, it becomes easier for them to prioritize and test the user story.
- Estimable: User stories should be written in a way that team could easily break it into tasks. When divided into tasks team can easily estimate the time it will take to complete a user story. Following is an example of bad user story that is not estimable and need to be further divided into smaller user stories
A Bad User Story: <As an owner, I want to have a portal, so I could sell my product online>
- Small: It gives team a chance to have discussion on the user story and divide them into smaller user stories and join them with another existing user stories if needed. Usually user stories are of maximum 40 hours of work, user stories bigger than that should be considered to be divided into smaller user stories.
- Testable: The INVEST criteria make it obligatory for the author of user story to write the test and acceptance criteria of the requirement, which removes ambiguity for the developer pertaining functionality of the feature.
2. Daily Stand-up Meeting
The Daily Stand up meeting is a way to let team members know the overall progress of the project, after the standup meeting every team member is aware of the work being performed and impediments faced by other team members. Just in 15 minutes whole team come to the same page in terms of progress of the project. It also provides a platform where team huddle before start of the day and if needed offer help to other team members to resolve each other’s issues. Usually scrum-master knows the technical strengths of different team members and should assist them to coordinate and collaborate with each other.
3. Assigning Spike
Agile supports and recommends time-bound iterative development. Before start of iteration, the team has fixed and prioritized user stories to work on. Teams don’t always have the knowledge of implementing every user story or task, sometimes team have to explore to find out the best solution for the problem or requirement in hand. In such cases some time is reserved for the team to research and find an effective and sound solution, which is also called a Spike.
More often than others spikes are used to find an architectural solution of the system. Not assigning enough Spike time can have severe implications. I have seen teams who selected the technological solution in haste, without performing enough research to find the best solution, which cost them an arm and leg in later stages of the project.
4. Test Driven Development
In test drive development you test before you program. That sounds little non-traditional, you may question how can you test before you write code? The opinion on TDD differs and opponents and supporters both have valid points to support their view but based on my vote goes to TDD. The only caveat is that team should be properly trained to write good TDD and time should be given to practice TDD. Once gets proficient team started to give result. It tremendously helps team to create code that is less error prone. In long run it improves the quality of the code and cut time of bug fixes and refactoring sessions.
5. Refactoring
Refactoring is an important agile practice, and developers should always be cognizant of it all the time. It’s not necessary to assign a specific session or time for refactoring the code. Code can be refactor while you intend to do something and finds out that same thing can be achieved without changing the behavior of the program in much less code or code can be more organized or there is a better, smarter, safer way of doing same thing. As mentioned earlier in agile development quality is everyone’s responsibility. So by doing refactoring developer help team to improve the quality of the code that helps the project in long run. Agile principle, “Continuous attention to technical excellence and good design enhances agility”, reminds us the importance of refactoring.
6. Continuous Integration with Automated build/time controlled
If you are not aware of what continuous integration is, you may like to read this blog. The Continuous Integration has been quite prevalent now; many teams have already realized the importance and benefit of implementing CI. By implementing CI team ensure that they their product is ready for release, anytime. Also for many teams it is center piece of their QA, because it acts as first check post to stop errors and issues. CI goes along with automated build and automated testing, which is another best practice of agile development. Early adoption of CI increase quality and reduce time for development for expert teams.
7. Unit and Exploratory Testing
In Agile development quality is everyone’s responsibility. As part of improving quality developers are advised to write unit test with the code. By writing and running unit tests on developer’s machine chances of slipping of errors to production code gets slimmer, and ultimately improves quality of the code.
8. Automated Testing
Automated testing saves an agile team a ton of time. Automated testing is part of continuous integration, as soon as code is integrated; it is automatically tested and built. It’s also important to know that you got to be selective in choosing tests that need to be automated. The tests that are performed only once or twice should not be automated. Finding the right balance between automated and manual test plays an important role in efficiency of overall testing.
9. Task/Release/Issue and Planning Boards
Almost all the tools use Task/scrum boards to move tasks from one progress state to another. It’s really helpful to drop and drag a task from one stage to another and sort them with different filters. Based on my experience same drag and drop experience can be applied to Release, Issue and planning board. Yodiz is one of the agile management tool which provides unique board experience. I think using these boards give more visibility and transparency of the work performed.
10. Velocity/Burn-down/Burn-up and Reporting
It’s very widely use practice and most of the agile teams understand and use the Velocity and burn-down/burn-charts to measure the progress of the project and to estimate and readjust teams goals. If needed my previous blog on velocity and groomed backlog can be accesses here. Over the time period velocity of the team usually gets stable and predictable, which helps teams to plan and estimate future releases more accurately.
11. Sprint Retrospectives
Agile principle, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”, reminds us that an Agile team should reflect back and see what mistakes were made during its last iteration and how to avoid them in the future, or what processes or practices were great and what other ones did not work for the team. The whole team gives its input in such retrospective sessions. Especially scrum-master keep an eye on all the things which did not work that great and should be able to initiate a debate that how can we as a team improve our efficiency.
12. Cross-Functional Team
A Cross functional team is supposed to include members who have all necessary skills needed in the project. When you are working on a project you might need an excellent Java programmer, an architect with SAS experience, programmers who also know how to write the Unit tests and a tester who knows how to automate the tests, an infrastructure specialist who knows how to setup the integration server for CI. It’s responsibility of the project manager to make sure that all people with required skills are present in the team. Agile is time-boxed development, team members with good mix of skills help to complete their work within the specified time without depending on someone outside of the team. My experience is those self-sufficient teams are more successful in terms of completing their project in time.
13. Self-Organizing Team (principles)
There is a lot of confusion around the concept of Agile self-organizing teams. One thing that needs to be cleared is that self-organizing teams are not meant to be same as completely self-managed ones. So question is what are self-organizing teams? The self-organizing teams are those teams who take responsibility of the work they choose to perform. It is important for all the team members to understand what does really it means to be an empowered team. The old saying “With great power comes the great responsibility” perfectly fits in this situation. It’s role of the management to transform sense of responsibility with organization vision to the team. The more self-organizing an agile team gets more effective it becomes, but team don’t become self-organizing themselves. Its responsibility of the management to set the processes in such a way that team could learn how to become self-organized. Team participation in decision making, estimation activities, retrospective session and stand up meeting should be organized in such a way where team are given freedom to give their opinion and take responsibility of the decision made based on their opinion. Scrum master and agile project manager still manage the team but they don’t micro manage them. The task is to let the team understand the goal and vision and let the team product the results without much interruption.
Author: Mobeen Siddiqui, Provides Agile coaching services in Minnesota, particularly in greater Minneapolis area.
