The PainKiller Team
During the last sprint, we created a new team: “the PainKillers”. Their purpose was to implement new features requested by users as well as fix bugs that were reported. The aim is “to reduce the user pain” (more about User Pain here).This story is about how creating a small team, giving it a cool name, and defining a very clear aim boosts motivation and focus. Let’s say that this is a real implementation of The Black Team described by Timothy Lister and Tom DeMarco in Peopleware: Productive projects and teams.
Tracking user requests
We track new features requested by users on our UserVoice. We review the status of the requests at the beginning of every sprint (two weeks’ time). A typical sprint planning entry has a section like the following in our wiki:
We also track bugs reported by customers using our internal issue tracking system (we use our own Task Tracking System, called TTS, see some pictures here. So we have a report to list the top bugs sorted by user pain (both reported by customers and found internally). Again, a typical sprint planning meeting has an entry like the following:
Requests and bugs coming from the forum are introduced in the TTS and handled as bugs found by users.
The Painkiller Team
We always included the entire “pain related tasks” as part of the regular planning process, but during the last sprint we came up with a new strategy: focus part of the team specifically on the “PainKiller” tasks. The idea is a “sub-team” dedicated full-time to the happiness of our Plastic SCM users.
So we got together a list of requests, assigned them, and started to work. The result was awesome: We resolved 38 tasks regarding customer requests in a two week timespan, most of them integrated in the last public releases 4.1.10.443 and 4.1.10.445. Besides these, a few tasks were handed over to our latest labs version 4.2.33.444.
The results were so delightful that we have decided to repeat the experience in the current sprint.
We even have our own logo, and maybe T-shirts in the near future, who knows…
Why does it work?
We always focused, as a team, on reducing the “user pain”. But as the team grows, and especially for newcomers, fixing issues, and doing “small new features” (and not focusing day and night on cool features like improving the merge system, creating semantic merge or improving performance under heavy load feels like something "not so important".So this initiative is working great because it gives all team members (a bunch of experienced developers together with new hires) a global view of how important reducing the user pain is. We all see immediate feedback since customers receive the releases on a weekly basis, with an impact not only on user satisfaction but also in sales.
It is also a great opportunity for new engineers to put themselves on the front-line, dealing with production code and knowing they are the ones to get this specific issue fixed, taking responsibility, and enabling other senior team members to focus on other tasks. There’s no best way to really learn than fighting in the front line and being the one who has to make it work. By the way, as release manager, I know every task we integrate is peer reviewed and functionally validated, so we still have a security net to make sure things don’t break, along with the daily 24h of automated testing, of course.
0 comentarios: