(http://www.energizedwork.com/weblog/2008/05/velocity-capacity-and-productivity)
Pressuring people to work harder, work longer hours, and take on an increased workload is not the way to increase velocity. It’s the way to start a death march. [...]
The way to reveal extra capacity and increase velocity is to relentlessly remove obstacles, eliminate waste and improve continuously. Help the team focus on the product, on quality, and to deliver only the functionality that adds value to the product and generates revenue. Keep the process simple and intuitive so that people don’t have to stop and think what the next step is. And protect peoples’ flow time by preventing interruptions. Help the team avoid creating inventory, i.e. functionality that is complete but cannot generate revenue because it is not deployed to the production environment. Quickly remove obstacles that are identified in the daily standups and minimize dependencies so the team doesn’t have to rely on others to get stuff done. This also cuts down on the time spent waiting around and chasing down and the effort required to hand stuff over.
(from http://blog.crisp.se/2013/07/12/henrikkniberg/the-solution-to-technical-debt)
As team, you decide how much work to pull in – that pull-scheduling principle is fundamental to both Agile and Lean. It’s built into the agile methods. For example, in Scrum Sprint Planning the team chooses how many backlog items to pull into a sprint, same in XP Planning Game. In Kanban, the team has a work-in-progress limit and only pulls in the next item when the current one is Done. Basically, the team has full power and responsibility over quality. Use the power!
In concrete terms: If you are doing Scrum, and you’ve been delivering about 8-10 features per sprint, try reducing that. Only pull in 6 stories next sprint, despite any perceived pressure. Ask yourself at each sprint retrospective. “What is the quality of the code that we produced this sprint (scale 1-5)”. If it is less than 4-5, then pull in fewer stories next sprint. Keep doing that until you find your sustainable pace.
This has business implications of course. The product owner (or whatever you call the person who makes business priorities) will have to prioritize harder. She’s used to seeing 8-10 stories come out of each sprint. Now she will only see 6-7, so she needs to decide which stories NOT to build.
Yes, this will lead to arguments and tough discussions. The real source of pressure (if there was any) will reveal itself. Quality is invisible in the short term, and that needs to be explained. Take the battle! Stand by your decision. If programmers don’t take responsibility for the quality of their code, who will?