Continuously Improving output of a team

Question

I am having my own software service company, DIGICORP and I am leading a team of 10 developers. The total company size is of around 50 persons. We are four friends who have started this venture from 2004.

During last year, we have read the Getting Real and Rework books from 37signals founders. We closely followed what Zappos did, we have started focusing more on providing quality service and building great environment in the company. This has changed a lot in the way we were doing business.

We have been able to build a friendly culture. We also make sure that the team does not face any issues with infrastructure. We keep doing innovative events to make sure that the team has more and more reasons to work at the company.

We started making following changes to our business decisions

• Limited Team Size
• Not throwing more time at a problem (Avoiding late night stays and working on weekends)
• 5 days and 8 hours of effective output

We face mainly following two issues.

• We find that the output we get today was less as compared to past. This is not just an observation, some of our old employees talk to us in one to one and they also raise the same question.
• We recently discovered that in the friendly culture we have most of the time started showing the better side of the work that way it is becoming more difficult nowadays to reprimand someone when they make mistake. Also due to the same fact, everyone in the company has a feeling that they are producing the greatest output.

So the answer I am looking for :

• How can we improve culture so that everyone in the team keeps improving output regularly and their 8 hours keep becoming more and more valuable?

Answer 1

A few questions and suggestions:

1. How are you measuring your output?
2. How are you measuring the quality of your output?
3. Are you able to extend your software easily?

It's always easy to say that 'We got more stuff done in the past', but without some sort of measurement (including a longer term cost e.g. The quality & extendsibility factors) you don't really know. There are software development methodologies (e.g. Kanban) that offer techniques to measure velocity and output (although it's never an exact science). In short you need to start recording how long it took to build x type of functionality at quality level y and then start measuring against that when you make process changes.

In response to the comments section below - In that case you want to start measuring output directly, even though you're working on different applications yo can still start measuring common units of work, e.g. 'SSO takes us about 3 days to build and we typically get 2 critical defects reported on it' or 'A CRUD screen that works end to end takes us about 4 days to build and we get 0 defects reported back (our Unit and Integration tests rock!)'

1. Have you advanced your build infrastructure to Continuous Delivery?

It sounds like your infrastructure is good. But could you deploy to PRD in the next hour if the client wanted it?

In response to the comments section below - Start with good CI practices (Jenkins is a popular x-platform, x-language tool here) and then move to Continuous Deployment for your dev environments (In the Java world, JRebel is great for this) and Continuous Delivery for your test and prd systems. Doing this takes time, but it will pay you back in increased output.

1. What development methodology are you using? Is it one of the Agile methodologies such as Lean or Kanban?

I never like to slavishly follow a particular methodology, but I'm currently a big fan of using Kanban as it shows the velocity and output of the team I'm working with. Most crucially it shows you very quickly where the blockages are "Oh look, we're developing the code really quickly, but we're overwhelming QA - so we can either add more QA or write more BDD/ATDD style tests to take that burden off QA".

In response to the comments section below - Whatever fits your team best, but you can measure the individual's and team's output. What's the unit? There is no scientific unit you can use :). You need to build up some historical stats on how long it takes to build something as well as keep an eye on the quality of that work (# of genuine bugs reported & difficulty in extending). I use JIRA and Greenhopper to track this as developers can put in their estimates and then the real time it took them to complete a task. Over time we learn how to split up tasks into 1 day chunks and we can then reasonably accurately measure the output. Please remember this is not an exact science and developers are not production line workers

1. Have you got a team of 'smart people who get stuff done'?
2. Are the team collectively responsible for issues?

The best teams I've seen always have the peer pressure to maintain a high quality bar through things like static code analysis (Sonar is good here) and peer code/design reviews.

In response to the comments section below - Start with the reporting that CI builds can give you. In the Java world its PMD, FindBugs, JDepend, Code coverage from your tests and many more. Very quickly individuals want to have the highest percentage of coverage, never break the build, least amount of FindBugs warnings etc. Also encourage ideas from the developers on how to improve quality and that sense of working with peers. Lunchtime or later afternoon presentations on a technology and that sort of thing help.

Also, you can encourage a collective approach to resolving issues. Assuming you've got the right culture in place, individuals know when they've screwed up and they also know that the team will work hard to help their colleague get out of the mess. We're all human and make plenty of mistakes after all! In fact dare I say that mistakes should not be punished - sometimes you need to make brave technical decisions that later on don't work out, it's the nature of software development (at times).

There are some people who simply aren't up to being part of a culture like that ('smart and get stuff done'). You may have to find them a niche or simply let them go (that's the harsh realities of business).

HTH!

Answer 2

"Continuously Improving". Sounds like you should be doing retrospectives.

A retrospective is a meeting held by a project team at the end of a project or process (often after an iteration) to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects.

Correctly performed retrospectives should improve team performance by removing impediments.

By involving the whole team in this, you will get better suggestions and team commitment.

Answer 3

We keep doing innovative events to make sure that the team has more and more reasons to work at the company.

In my experience, a strong team is the best reason you can provide someone to stay at a company. If a person feels connected to their team and feels like they have some responsibility for the team's output, they get greater joy when the team succeeds and are less likely to leave.

I know this from personal experience, as I stayed at a job in a hostile environment for far too long all b/c I liked my team and felt I'd be letting them down if I left. This fact was also talked about in detail in a soft skills course I took called 'Building Teams that Work'.

You said that you like to keep your teams small. I'm guessing that each team is working on a different project. Perhaps at the end of each year, you could give awards for teams who have gone above and beyond. My current work give them at the company party each year, and feedback is taken in from our customers and from other employees. Everyone in the team is given a nice looking award and a gift certificate. It's a good way to recognize strong teams who have produced great work for the company.

As for the 8 hour target, is this 8 hours daily or on average? I personally don't mind working up to 10 hours a day, if I can take a day or two off when timing allows. What about during a crunch? I know you said in your question that you are trying to avoid them but you never know when unexpected work will come. Do you have some sort of Flex-Time policy? If you work some extra hours here, you can take off some time there?

Mandating 8 hours a day is putting a time measurement on a thought process. Some days, developers get in the grove and can stay there for hours. Other days, the juices just don't flow and 5pm never comes soon enough. Maybe provide your devs with some free time each week where they can research something not work related to learn something new?

I hope that gives you some ideas.