RoR-e

For years Agile and now lean development processes have been practiced at many companies successfully to create software. I tend to Lean towards "Lean" development mainly because it has not been bastardized. In fact I have found most companies that call themselves Agile have no idea what Agile means.

I find these processes address key problems in development. Unfortunately they don't address many issues I find to be extremely important. The biggest issue being Employee turnover. By this I don't mean just developers changing jobs I mean anyone moving. Developing software should not just be a process it should engage your entire team and be fun.

Let me introduce what I call:

The Gamification Development Process

First there are several goals this process tries to achieve.

• Communication
• Better and more open ideas flowing in the office
• Low employee turnover
• Motivated workers
• Idea wins mentality

Let me say, I would like to inherit all the Lean processes and My intention is not to rehash what lean is all about so please read up on "lean Processes" if you don't know what Lean is.

Game Process 1:

Once a month (or every X weeks) a company will break their company down into several competing teams. Marketing, Developers, Creative even the C-Level employees will be broken into teams. Each team should be broken down into a good mix of each skill-set.

Each of these teams will be asked to create something useful for the company. What each team creates (or starts to make) depends entirely on the team. No idea can be vetoed. At the end of the day (or the next day) the teams will pitch their idea/solution to the company.

The winning team wins something. Cash, a vacation day, an iPad... You can really have any prize.

What this process does is first it gives you a set time where ideas at your company flow to the leaders. If you see an idea that can make money for the company you can immediately make that idea the next company project. Also now employees will constantly be thinking, "What can we do to win next month?" Employees will be talking with each other during the month, constantly trying to come up with the next best idea for the company. I can't count the number of times good ideas are brought up at low levels but never addressed to management.

Also your employees are now excited to come to work. If your idea becomes a real project you have:

• A Sense of ownership
• Pride
• Recognition
• Motivation

You can also more easily see where good ideas are forming in your company. Remember Ideas should win not seniority.

Game Process 2:

Give developers time to ask other employee's "What their biggest pain point is". I remember when I worked at ShoeDazzle. I was given a good amount of flexibility to work on what I wanted. I'm not sure if this was because I didn't listen to management well or because they truly gave me freedom but that is beside the point.

I would approach the DBA and ask, "What are you asked to do repeatedly that I can automate?" The first time I asked the DBA his response was, "I've never had a developer in 15 years ask me that!" He rattled off about 5 of his biggest pain points. Three of his pains I finished in less than an hour and it freed up at least a day every week for him to do other things.

If you ask your developers to take a day every couple weeks to help automate different people's jobs the reward will be handsome. Make this part of your culture.

This process first makes developers more approachable. If your employees are talking to your developers, your problems can be automated. It also makes the daily grind just a little more easy to deal with. People get bored with their jobs because many times they are doing the same mundane things over and over. If these mundane things eventually go away, employees are happier and happy employees don't leave.

This builds:

• Communication
• Motivation (it's so much easier to work at a place with less tedious tasks.
• Feeling that you actually helped someone directly
• Less employee turn-over

Game Process 3:

Stop making schedules. Goals are fine, Schedule kill. You miss a schedule and everyone gets disappointed. When I say everyone I mean C-level all the way down to the garbage man. Goals serve the same purpose but the feeling of a deadline kills moral. Sure you need to see results but don't you think 90% of your employees try to hit their goal.

So what is the difference between a Goal and a schedule.

• Verbiage (If you don't think this is a big deal it is)
• A goal does not have a MS project gantt chart.
• A goal does not take days of meetings to estimate when it will be done. (Spend your time working not scheduling)

Yes I do understand things need to get completed but first management needs to come up with ideas well in advance of a completed date. Management should be starting projects for Christmas in July. The project should have an on/off switch and should be turned on for Christmas. The project should not be complete at Christmas. Completing a project in the nick of time kills quality and increases stress levels. It also puts a stop on Game Process 1 & 2.

Game Process 4:

Reward your employees. Analog Devices had an idea of a spot award. Any employee can give another employee a spot award. Lets say I automate my DBA's workflow. The DBA can elect to give a reward to me out of his spot award allowance. Management gives the award or even increase the award amount if it was worth it. Several Companies have processes like this. The award normally isn't large. The good news, it doesn't need to be large.

Game Process 5:

Sales people are commonly paid a commission of sales. Even when the sale actually required a developers time. Some projects should have a financial reward. For example, if a projects goal is to increase conversion rate by X% you should be able to quantify that conversion rate (extra customers) into Revenue. The whole development team should see a small % of that revenue go back into their pockets.

The project should pay the entire team not just the project leader. This promotes people within the team to contribute and help out even if they are not working on the project itself. It is also unique to your company. Developers will strive for a more robust better solution if it helps their bank account. Do you want your developer to say "OK" when they know of a better way to do things? Trust me it happens all the time.

Also the reward should be good but not 50% of the developers pay check. Also feel free to say the reward is for extra revenue for the first month of the project. Having the reward go on forever can easily make the team content. This is not the goal. The goal is to motivate and increase quality.

Sounds like you will be paying a lot of Money

So you are reading this and thinking, WOW this is going to cost a lot of money. Maybe not.

First, many of these awards are a direct result of more profit. You might be paying more but as the saying goes. I'd rather 10% of a million dollars than 50% of a thousand dollars.

Second, All of these processes reduce employee turn-over. Employee turn-over is one of the worst things that can happen to a company.

Third, If the rewards are thought out the profit gains will outweigh the rewards.

4th, Productivity will surely increase.

Last, you don't need to incorporate all these tools. even a couple of these processes will help your company in more ways than one.

My goal is to continue blogging about "The Gamification Development Process". Feel free to add comments. Also every great idea needs an acronym...

The Gamification Development Process.... GDP

Until next time....