Every development team is different. Sometimes you walk onto the floor where the developers live and it is a hive of activity. There might be a few people clustered around a white board, whilst others are having an animated discussion around a screen. Often the workspace is set up to enable easy communication with no barriers, and break out areas where people can go to focus on a particular challenge. Through that noise, movement and activity you get a sense of collaboration.
Other times you can be deafened, deafened by the clattering of keyboards… and nothing else. People are obviously busy and getting things done but what they are doing is not immediately apparent. Sometimes conversations will spark up but they are often muted with people wanting to get back to the task in hand. If you observe longer you might find people getting frustrated with each other, annoyed about interruptions and thinking that time collaborating in meetings is a waste of time, time away from getting real work done.
I’m going to suggest that the way success is measured in these two extreme examples is different. And that may be driving behaviours.
In the first example I would guess that the team is motivated by flow. They want to minimise the cycle time of getting work completed. This is driving collaboration and the desire to minimise work in progress. Whilst it might seem from the outside that all the noise and communication is wasteful and yes it might be less efficient from an individual’s perspective, it is effective in getting the work in hand done.
In the other scenario, you could walk up to any person and ask “are you busy?” and you would get a resounding confirmation. People in that team may feel maxed out. And it is likely that their managers would be very happy. After all, each member in that team is being fully utilised writing code. What’s not to like? The managers may even be reaching out to the recruitment market to ensure that the organisation’s delivery commitments are made.
What is happening is the two organisations are optimised around a different dimension. Team 1 are flow optimised and team 2 are resource optimised.
If you buy into lean thinking, then the focus should be on flow and not resources. Results for a business are achieved when ideas are processed by the development team and release to customers as quickly as possible.
Running people at 100% capacity is risky. By definition something at 100% capacity means nothing else can be taken on. Upstream that means work can stall. It means there is no contingency for the unexpected. Busy people become bottlenecks. If you are a bottleneck in a resource optimised organisation you become the focus of attention as you are critical to getting things done. Some people like that but not everyone does. And what happens in resource optimised organisations if one of the bottlenecks decides to leave?
In flow optimised organisations people tend to avoid being bottlenecks. Instead of being a doer people in these organisations are enablers. It might seem like a subtle difference but it is a fundamental in organisations that are routinely delivering new features to their customers as oppose to continuously putting out fires.