views:

293

answers:

3

Management of our business unit provided us with new goals to achieve: flexibility and quality. Our functional leaders (e.g Test lead, Java team lead etc) should transform these high level goals to something more specific that can be used to improve level of flexibility of individuals and teams and quality of products. Let's focus on the first point: flexibility. I would like to see opinions on the next questions:

  1. Just for start, what is it? How can we define flexibility of team or developer?
  2. How would we measure flexibility of individuals and teams?
  3. How could we improve flexibility?

Please, share you thoughts, I will really appreciate this.

+2  A: 

Presumably they aren't talking about a wellness program, so I would think that flexibility is the ability to take on tasks that are outside your normal role, or for a team, projects that fall outside your normal capabilities. For example, if you are normally a tester, that you would pick up some coding or design capabilities. If you are normally, a designer that you'd gain the ability to construct some tests. If your team typically works to spec, that you'd be able to work agilely with an evolving feature set.

There are many different ways to approach this but they all have a common theme: learning. Individuals need to pick up different skills and work in different areas to gain cross functional experience. Teams need to learn and try different ways of working and/or take on projects in different domains. You might also want to try pairing as a mechanism for skill transfer -- this would be asymmetric pairing by intent so that a senior person takes a novice under their wing.

In my opinion, this is a good goal -- to an extent. Having the ability to fill multiple roles is generally a good thing. Taking it to an extreme could, however, leave with a lot of people who are sort of good at many things and no one who is really good at anything.

tvanfosson
+1  A: 

Don't you just love these edicts from management?

To hazard a guess, I'd say they're talking about the flexibility of the employees to do more than one thing. For a developer it may mean learn new languages, technologies, tools and products. It may also mean learn something about the business other than software development, such as the business case for the product, product strategy, financials, etc. It may also mean be flexible in your work hours, as in, work longer for the good of the company without complaining.

As for how to measure? That's a good question. IMO in order to measure any "improvement" to your "flexibility" you'd have to measure your current "flexibility". Without a solid definition of what "flexibility" is, this will be extremely difficult. Or really easy, if you become Machiavellian. Help QA trobleshoot an issue? You've been flexible. Write a quick-and-dirty script to automate some mundane chore? You've been flexible. Have lunch with someone from another department and talk about what they do? You've been flexible. Come in one weekend to work to get a release out the door? You've been flexible.

Patrick Cuff
A: 

Flexibility may well refer to how easily can something go from someone asking, "Can application X do Y?" to it actually being done running in production. Thus, a more flexible team can handle changing requirements which may happen in some businesses; the IT team has to be able to handle the case of something totally new coming in and integrate that into the current systems.

Flexibility is more about process and project management, I'd say. Developers usually have a good deal of freedom in performing various tasks and this is a slightly different form of flexibility, how does a developer handle the change as opposed to a project team handling a change. The key question is how long would it take if someone said, "Drop everything and get this done NOW!" to where there is some prototype running?

Improving flexibility may require changing some processes as well as ensuring that your development teams have broad knowledge of things as sometimes you may get some executive saying, "I'm hearing so much about X. What are we doing about that?" where X could be cloud computing, virtualization, service-oriented architecture, Ruby on Rails, ASP.Net MVC or any of 101 other buzzwords that aren't necessarily easy for the IT guys to respond, "Here is where we use it," or "Here is why we don't use it."

Course this assumes we aren't talking about the Flex from Adobe. ;)

JB King