Agile Zone is brought to you in partnership with:

Martin has worked with many customers in government, finance, manufacturing, health and technology to help them improve their processes and deliver more. He provides management and technical consulting that intends to expose processes and practices to gain transparency, uncover impediments to value delivery and reduce cycle-time as part of an organisations path to agility. Martin is a Professional Scrum Trainer as well as a Visual Studio ALM MVP and Visual Studio ALM Ranger. He writes regularly on http://nakedalm.com/blog, and speaks often on Scrum, good practices and Visual Studio ALM. You can get in touch with Martin through naked ALM. Martin is a DZone MVB and is not an employee of DZone and has posted 64 posts at DZone. You can read more from them at their website. View Full User Profile

Does Your Company Culture Resemble "Survivor"?

07.15.2013
| 4872 views |
  • submit to reddit
metro-process-link

Does your company culture resemble Survivor?  Do you have a culture in your organization where people who help others are considered slackers for not completing their own assignments?

If you are trying to achieve agility, it is imperative that your team members work together to solve problems. I am not saying that you have to do pair programming but you have to have a culture where collaboration and working together is the norm. This is one of the two main roadblocks to agility ( the other one being requirements management) that companies hit time and time again early in their agile adoptions.

Changing this part of your culture is something that has much wider implications than just improving your team's ability to deliver value. It is a harbinger of changes to come and, if you can change this one thing, you will be more able, and committed, to making more changes to your culture going forward. The goal is to have a culture of change where each of your teams is running small, low-risk experiments in processes, practices and tools every iteration. It is the catalyst to wider company adoption and buy-in, and it requires a certain amount of courage and discipline to achieve.

As with most impediments to the path to agility, this is an issue of culture. To change culture, you need commitment and courage not just from those at the coal face but from executive leadership on down. If you are trying to adopt agility from the bottom up, you will have limited success and ultimately you are doomed to failure.

The problem is in how people see their work and treat work done by others. Over many years the US, and in some industries the UK, has moved toward the "Survivor" model. This is where each person is measured and encouraged to look out only for himself. They work in an isolated bubble where they are force fed activities and they are solely responsible for activities in their queue and those people are often stack ranked each year. This process serves to isolate not just the individual but also that person's skills and knowledge.

Ask yourself this: If you won the lottery and never returned to the office, what would be the impact?

You need to foster unit mentality.

If you have seen the Mel Gibson movie “We Were Soldiers,” there is a really memorable phrase that has value in the software space: “Learn the job of the man above you, and the man below you”. Software development is a collaborative effort of a Unit (Development Team) working together to achieve a goal. We need to understand each others' knowledge, skills and even quirks in order to be effective.

It is critical to instill a sense of team and not individual within your organization. If you are going to get anywhere on the path to agility, you need to let go of the matrix. You need to realize that allowing team members to work on more than one project at a time only creates the illusion that there is more work underway. The reality is simple: Workers who switch between projects lose at least 20 percent of their time per project that you add.

The loss of the 100% worker

There is an even greater loss by not working in dedicated teams: You lose most of your people's individual ability to solve problems. Software development is all about problem solving, it's about puzzles -- and developers excel at solving them. Remember that software development is always product development. However, if you give your development team members the wrong puzzles, you will not be utilizing them for the thing that you actually employed them for -- solving the puzzles.

It's the background processing power of a developer's subconscious that you can utilize to solve the most complicated of problems. Developers will figure things out in the bath, or while playing with the kids, or driving home from work. Unfortunately if you give developers many projects to work on and they have to switch often ( you know, to show progress on many things at once) then what becomes the greatest problem in their world? You should have guessed it by now: It's the problem of juggling their workload. So the problem that their subconscious is trying to solve is now how to juggle that work more effectively.

This has the effect of stretching the amount of time that each thing takes as it takes many more cycles for the developer to figure out the problems and thus your software takes many more months to deliver than it should.

Conclusion

Don’t have a company culture that resembles Survivor and instead opt for one of teams. These teams will be a force multiplier to your ability to deliver software and this will give you a competitive advantage. Don’t wait until your competition figures this out!

-Every company deserves working software that successfully and consistently meets your customers needs. We can help you get working software with continuous feedback so that you agile teams can deliver continuous value with Visual Studio, Team Foundation Server & Scrum. We have experts on hand to help improve your process and deliver more value at higher quality.

Published at DZone with permission of Martin Hinshelwood, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)