If you've worked in a Scrum shop for any amount of time then you already know that momentum is the name of the game. If Scrum had a mantra it would likely be something like... "Just get on with it...". This can often translate to a sense of urgency, and depending on your perspective, it can be a good thing or a bad thing. In many ways, this straight-forward mantra is what attracts some people to this process, although without proper management you can quickly lose momentum and burn people out. Don't believe me? Google it, if yee doubt the claim.
Do a little reading and you will quickly find the consequences of these conditions can lead to lost productivity, reduced quality, and more often then not valuable people quiting. To make matters worse, techniques to combat these conditions can be quite varied, depending largely on the personality of your team and/or individual team members. Putting that aside, lets try and enumerate some practices that can help mitigate some of the aforementioned concerns.
In my experience, developers tend to be some combination of artist, scientist (sometimes mad), inventor, and for some... masochist. While we can't cater to the last one we can do something about the former items. If you think about it, there are always things the team wish they could work on. This could be new product ideas, technology exploration, graphic artwork, animations, design patterns, etc. Assuming these projects are not too far off the track, side projects can go a long way to giving developers something to look forward to. If you do a little research it is easy to find plenty of examples of how these types of projects can often lead to huge successes for companies, so this is not all that crazy.
Invest in Automation
This section could easily be called "Repetition is Evil". Monotonous tasks will absolutely drive devs crazy. While this could be an entire article in itself (note to self), the message here is simple... get rid of the drudgery. This not only makes people happier, it can lead to huge cost savings for companies by letting devs work on more productive tasks, and can lead to huge increases in quality and capacity. Here we are talking about letting teams adopt new tools, build Continuous Integration infrastructure, testing rigs, deployment routines, etc. Some companies may wince at the thought of shelling out a couple grand on new tools, books, or whatever, but anyone who knows anything about this business will tell you it is usually worth it.
Mix up the Roles
This can be tough in some organizations but can really produce amazing results when viewed from a teaming perspective. In this scenario, we are taking someone out of the normal commitment pool which can be a bit of a break by itself. Instead, we can rotate the dev through a variety of other roles. This can be used to help people see each others position from a different perspective which can lead to a better appreciation of what each role provides to the others. Here are a few examples:
- Change places with the Scrum Master: It can be tough running between teams, organizing your own team, dealing with conflict resolution, facilitating meetings, making on-the-spot decisions, and meeting the individual demands of each and every team member. The Scrum Master can be the unsung hero and everyone should spend some time in their shoes
- Become one of your users: This is a great shadowing technique... Send some time in your users shoes and you will usually walk away with a better sense of what works and what doesn't. This can be a great motivator for improving products, enhancing usability, and keeping a dialog between the devs and end-users
- Be the support monkey: Most teams have some kind of support burden which is usually impossible to estimate. Take one person out of rotation and let them answer these calls. This can relieve the pressure for others and provide everyone with much needed visibility into things they may not have written themselves. Between calls, they can start picking away at open or lingering bugs, or take care of other housekeeping issues
- Become the enemy: If you have products that are really concerned about security... Spend some time trying to break into your own system. This can be eye-opening and fun
Rethink your productivity rates
In a previous article (SCRUM-tastic Tuesday - Estimation guesswork) I discussed the notion of a productivity rates. This is the number of hours per day each team member is expected to be making progress towards the completion of committed tasks. This tries to acknowledge time spent on the phone, answering emails, attending meetings, training, lunch, etc... No estimate should extend beyond this number. If people are consistently frazzled by the end of the Sprint, then you may need to rethink your productivity rate to give people a little more breathing room. If everyone is always rushed, defects and/or implementation compromises will start to develop which; in the long-run; can be very costly.
Embrace your pain-points
Each team knows what they are, and usually know how they would address them "if" they were given the time. Let them do it. If something is holding your team back then it makes sense to let them deal with it.
Share the "New" work
There is just something pleasant about creating your own project from scratch. While you may be constrained by team or organizational standards, you are not constrained by having to reverse engineer a lot of Intellectual/Technical Debt. When new projects arise or old projects lead to creating a new set of libraries, solutions, etc. share the wealth.
Don't forget play time
I have never been part of a dev shop that only worked 9 to 5. Developers work long hard hours, and they need a break just as much as anyone else. There are lots of ways to support this, and companies that understand this will usually get a better return on their investment. Ideally, you want to give developers time away from their desks but engaged in something together. Depending on your corporate and/or team culture options can vary widely. Here are a few ideas...
- Send the team to a nerdy conference like TechEd, Code Camps, or designer events
- Send the team out for a night on the town. This could include, dinner, concert tickets, and maybe even drinks
- How about team paint-balling... Let them get rid of some of that aggression. This works best when they can challenge the management team
- Sponsor a game night. This could be a giant Halo event using corporate projectors, a few bean-bags, poker, Uno, or whatever. Buy a few drinks, pizza, and taxi-fare and let them have some fun
Hopefully, this provokes some thought about how you can manage some very costly concerns. Trying weaving some of these ideas into some of your Sprints and you may just have a happier team in the end. As a side note, the issues presented above plague many Agile processes within the development community so feel free to adapt your reading accordingly. With that said, this article is titled "SCRUM-tastic".