I started blogging about ideas for agile teams at 101 ideas for agile teams, check it out.
cross-post from bbv Blog
This is a list of actions that Scrum Masters at bbv Software Services AG have applied successfully in their teams to improve performance (= how much gets done in an amount of time). Please note that these actions were created to respond to specific problems found in real world projects. They may not be applicable in general in any situation.
I’d be happy to read your experiences and feedback in the comments section.
1 Be unfaithful
Developers should not always work only in their main area of expertise. They should take a task of work outside their comfort zone from time to time. For example, if you are an user interface expert (you know all the little dirty secrets of all the controls) then help working on data access code, too.
How to enforce:
- More than one person has to work on a User Story, otherwise it will not get accepted.
- Put a limit on the User Stories that can be “Work in Progress” that is one smaller than the team size.
- Perform pair programming.
What you gain:
- Know-how transfer – more people know about all aspects of your software.
- Increases courage – team members will have the heart to do tasks outside their expertise, thus lowering risks of bottlenecks and enforcing team spirit.
2 Commit Review
Whenever a developer wants to commit/check-in something (code, tests, documents) to the version control system, she or he asks a peer developer to review the changes first.
How to enforce:
- Add commit reviews to the definition of done.
- Refuse accepting user stories for which commit reviews are missing (you can still review with the help of the version control system).
What you gain:
- Increases know-how transfer – at least one additional person has seen the changes and may continue working on this particular topic.
- Increases quality – the second developer challenges the decisions made by the first developer, which often leads to better and simpler solutions. Often enough, the original author finds gaps for himself when going through all changes again and explaining them.
- Increases understandability – to answer the questions of the peer developer, the code/test/document is adapted so that other developers likely will understand it.
3 Give-aways, little presents, celebrations
Introduce a culture of celebration. For example, you may give out little presents for achieving the Sprint goal. This can work in situations when motivation is rather low. The award should always be for the whole team, never for individuals.
What you gain:
- Increases motivation (if motivation is low)
4 Introduce test driven development
Use test driven development for developing your software.
What you gain:
- Team can work in parallel with the use of mocks and does not have to wait until real dependencies are available.
- Refactoring – team can refactor code to make it fit to introduce new functionality without changing the functionality due to the tests checking existing behavior.
- Defect count will decrease because of the double bookkeeping done by the developers (test – production code)
5 Introduce acceptance tests for user story acceptance criteria
Let the team write automated tests that check whether the acceptance criteria of user stories are fulfilled.
How to enforce:
- Add acceptance tests (both variants) to the definition of done for user stories.
What you gain:
- More focus – the developers can focus on fulfilling the acceptance criteria of the user stories.
- Stable quality – these tests prevent defects that are introduced through new functionality braking existing features or refactoring. The team can always look forward in confidence.
6 Workshops on coding guidelines, architecture, design, tools, engineering practices
Perform a workshop for the whole team at least once per Sprint where you discuss about or try a new technology, your current architecture, your build-process, how to use Resharper and so on.
How to enforce:
- Reserve time for the workshop and organize a moderator (can be a team member).
What you gain:
- Team spirit – the team can find its own way how it wants to get things done.
- Team wide consistency – all team members will start to merge their individual way of working into a team way of working.
- Team commitment on a topic.
7 Coding Dojos
In a coding dojo, the whole team sits together in a conference room. Two developers do pair programming at a single computer connected to a projector so that all others can see what they do. The pair is rotated every 15 minutes. In this setup, the team solves exercises to train their engineering skills (unit testing, design code, write code, use tools, …).
How to enforce:
- Reserve time for the coding dojo and organize a moderator (can be a team member).
What you gain:
- Know-how transfer amongst all team members on all topics related to software creation.
- Team consensus about how to develop software.
8 Testing Day
When there are no testers (team member mainly responsible for testing aspects) on your team, you can introduce the Testing Day. On every day there is a team member responsible to test the application (round robin). On this day, the team member is freed from all coder duties and can focus on testing the software. As a side note: add a team member with testing expertise! This is only a second best solution.
What you gain:
- Testing is not pushed back in the timeline (and probably forgotten about).
- Focus on testing – no task switch between coding and testing on the testing day leads to more efficient testing and therefore increased quality.
- Whole team takes part in testing and therefore shares responsibility for quality.
9 Emergency Scrum Meeting
Allow each team member to call in an emergency Scrum meeting whenever there is an issue that puts the Sprint goal at risk. All team members are obligated to drop what they are currently doing and join the meeting.
What you gain:
- Big problems are taken care of as fast as possible.
- All team members know that they are not left alone when problems arise.
10 Work-in-progress limits per column on Scrum board
When you see that there are user stories piling up in a column on the Scrum board (for example in the verify column holding user stories that have to be tested), you can introduce WIP limits like normally seen on Kanban boards. These limits force the team to take care of the user stories blocking the flow. In our example, the coders may help the testers by supporting them writing automated tests while the testers focus on which scenarios have to be tested.
How to enforce:
- Write the limits on the Scrum board.
- Call in an emergency Scrum meeting if a limit is violated and discuss how to resolve the violation.
What you gain:
- More user stories get done instead of being worked on.
11 Fast-lane user stories / Kanban – Scrum hybrid
Reserve a percentage of the team capacity (for example 10%) for working on ad-hoc tasks or user stories. The product owner may use this time for unplanned items that have to be finished as soon as possible without having to cancel the Sprint. After finishing a task, every team member is obligated to first take an item from the fast-lane before he or she continues working on the regular Sprint backlog items (until the reserved time is used up). If the reserved time is not enough to finish the ad-hoc items then the PO can either cancel the Sprint or wait for the next Sprint. A Kanban board is a good way to visualize this kind of work because Kanban is optimized to reduce cycle time.
What you gain:
- You can keep the benefits from Sprint planning and release planning.
- The team can still commit to a Sprint goal.
12 Control time-boxes of Spikes and order in which user stories are implemented
Measure whether the time-boxes set for Spikes are really obeyed. Measure whether the user stories are done in the order they were prioritized. Show your results to the team during the retrospective.
What you gain:
- Transparency about how the team works.
- Working on the user stories in the order they were prioritized maximizes the value of the product increment at the end of the Sprint and minimizes the risk that all user stories are work-in-progress but not finished.
- Obeying the time-boxes helps planning future Spikes and to hold the Sprint goal.
13 Fix defects before working on user story task
All team members have to take a defect task before taking a task of a user story.
What you gain:
- Defects are not piled up on the Scrum board.
- Higher motivation due to cleaner platform.
- Quality is better if defects are resolved early in and not at the end of a Sprint – less follow-up defects (the really ugly kind of bugs).
14 Vertical user stories + specialist => pair programming
When working on a user story then pair specialists on different topics with each other so that the know-how of the specialist is spread to the other team members.
How to enforce:
- At the daily Scrum, decide which pairs will work on which tasks.
What you gain:
- Know-how is transferred from the specialists to the team.
- Consistent implementation of the whole user story over technology borders due to pair programming (no information silos).
15 Personal Sprint goals
Every team member chooses a personal Sprint goal at the end of the retrospective. Typical goals are improvements in engineering-skills or tool mastery. Achieving the goal should make the team member a bit more efficient or effective.
Some goals we had in our team:
- learn Visual Studio short-cuts
- learn Resharper short-cuts
- for one Sprint, focus on giving good method/variable/test/class names
- for one Sprint, focus on making small methods
- other practices from the Clean Code Cheat Sheets found here
What you gain:
- Every team member will learn something small every Sprint. Over time, this makes a big difference.
- Increased motivation of team members (learning new stuff has this side effect).
16 Clear distinction of Spikes and User Stories
Use spikes and user stories deliberately. Spikes have a fix time-box and an estimated result. User stories have a fixed result (acceptance criteria) and estimated needed time.
Use user stories when you know what you want. Use Spikes when you want to plan the unknown.
What you gain:
- Spikes allow to plan a Sprint.
- No wastage of work hours.
- Better focus due to fix constraints (on functionality or on time).
- More discipline, either get the needed functionality as fast as possible or get as much information as possible with a limited amount of time.
Thank you for this article! I’ve learned so much reading it! I can’t wait to follow your tips and enforce them in my team. We have just introduced Kanban software to our employers (we use boards on http://kanbantool.com though) and we are eager to make the best of it. I will definitely use your tips.
Very well illustrated! thank you
Thanks for sharing! Great article! =)
Awesome ideas, loved it!!!! , though its tough to implement may be we can take baby steps since I feel this would spread the knowledge of application across the team , removing dependencies.
thank you for sharing from your experience!