In my last post I had talked about a possible drawback of Agile basically being that Agile projects tend to drive developers instead of steering them.
I basically summed the problem up as being one of software development on Agile projects being a really long set of continuous sprints on an already laid out path.
I have been thinking quite a bit about some possible solutions to this problem, and in this post I hope to provide some.
Racing the good race
One of the analogies of Agile projects is that of a race. In Scrum we call the iteration a sprint.
I think this analogy points clearly to the solution.
When I used to be on the track team in high school we would do sprints. It was called interval training and it sucked.
Well, at first it didn’t. At first you would do some of your runs, like a series of 100m dashes and feel great. But, by the end of the session, if you ran it as hard as you could, your lungs would be burning and it wasn’t all that uncommon to puke up your guts.
People just aren’t meant to sprint over and over again without a break. When we were pushed too hard on the track we would end up slowing down the entire time on the next training session in order to pace ourselves.
You have to find the right combination of sprints vs. rests.
Enter the cool down sprint
My most promising idea is: after a certain number of sprints the team slows down and basically takes a breather.
Not to say the team just sits around and doesn’t do anything. Far from it. Instead the team does what they think needs to be done and is important.
Kind of a self-reflection / sharpening the saw / building tools and making ourselves more efficient sprint.
I would guess it would be beneficial to do something like this every 5 or 6 sprints.
The idea here would be you just trust the team to work, but no one directs the team as to what that work is.
I think it is a good way to take some of the pressure off and reenergize the team to start the next set of intervals.
This next idea is stolen
I’m not sure exactly from where, but I heard of a team before that gave each member of the team some amount of “dollars” they could spend each iteration.
Product owners and managers were given “dollars” as well. The idea was that you could spend your money on items that you wanted to put in the sprint. The priorities were set based on where the dollars fell.
In order for something like this to work, you need to give far more dollars to product owner, support people and other people on the business side of the house, but by giving a certain amount of dollars to developers, you allow them to have some amount of say in what is worked on.
This kind of solution solves the problem by allowing developers to have more control over their destiny rather than feeling the path is laid out for them. It gives them the ability to work on something they see valuable or even just fun without pressure or guilt because everyone understands the concept of spending their own money how they see fit.
Developer free time
This idea is stolen as well. Actually it is stolen from Larry Silverman who is my current employer at TrackAbout.com.
This idea is pretty simple; here is a quote from our dev wiki describing it:
You may be familiar with Google's policy that each employee is granted 20% free time to pursue their own interests. Of the projects that result, some of the best become live Google products. Google has nearly infinite resources, and with thousands of developers trying so many things, every so often one of them is going to be a winner and create a major new revenue stream. Obviously, TrackAbout does not have infinite resources. But we admire the spirit of Google's free time policy and would like to emulate it to the degree we can.
The following Developer Free Time policy is intended to promote creative thinking and innovation by providing developers an opportunity to explore new ideas and technologies. In the spirit of Continuous Improvement, you may choose to take this time to explore an idea or improve your own skill set. Of course, we hope that some of work might prove beneficial to TrackAbout.
Most importantly, the policy is intended to allow you, the developer, to stretch your proverbial legs and have some fun!
The Details
- The program is voluntary, not mandatory. You don't have to participate, but it's encouraged.
- Each developer is granted 2 days per quarter to pursue their interests/projects.
- No approval is required for the project, but feel free to use Larry or other devs as a sounding board for ideas to pursue.
- Developers can take the 2 days at any time during the quarter (when inspiration strikes!), provided it doesn't place at risk a release under development.
- Developers can team up on projects.
- After completion, the developer (or team) will submit a brief write-up to the Dev Team summarizing the work they did and what was accomplished, explored or learned.
- If the dev (or team) wants to present their work to the dev team or to the greater company, it's encouraged but not required.
It’s about nurturing passion
After thinking about my last post for some time and what possible solutions to the problem I described, I realized it is all about nurturing passion.
Agile and Kanban like thinking tend to get us really focused on producing and producing.
Don’t get me wrong, I love to know that my team is operating efficiently and producing lots of value for the customer, but sometimes we need to really make efforts to balance that production with what really makes the developer engine run.
Sometimes we need to take a pit stop or do an oil change so we can keep that machine running smoothly and if we don’t, just like any machine, it will break down.
I realized that most people in our profession don’t get here because they love a paycheck, but because they really love writing code and exploring technology.