Lean: Big Picture over Local Optimisations
I recently finished reading Lean Thinking and one of the things that was repeatedly emphasised is the need to look at the process as a whole rather than trying to optimise each part individually.
If we phrased this in a similar way to the Agile Manifesto it would probably read 'Big Picture over Local Optimisations'.
The examples in Lean Thinking tend to be more manufacturing focused but I think this idea can certainly be applied in thinking about software projects too.
Individual vs Team Focus
For me on a software development team what we care about is the quality of the team as a whole not the individuals on it.
It’s all good being very strong technically but you have to be able to work effectively with other people to solve problems otherwise your value to a development team is much reduced.
I wrote a bit about this previously in my lean look at pair programming but I think it goes beyond just ensuring that we are sharing knowledge around the team by having people collaborating closely with each other.
When I first joined ThoughtWorks my former colleague Fred George was always talking about the value of being poly skilled - having the ability to carry out more than one role - and I think this is lost when we refer to people as being their role i.e. 'you ARE a developer' rather than 'you CAN PLAY the developer role'.
If we have people on a team who are polyskilled or generalising specialist (although I think generalising specialist refers more to poly skilled across a role rather than being able to carry out multiple roles) then we can get away with building teams which are smaller in number and which are more resilient and able to respond when team members are ill or absent.
Horizonal vs Vertical teams
Creating teams of people by the layer or horizontal which they work on rather than the piece of functionality or vertical which they are working on seems to be one of the most obvious ways of locally optimising instead of looking at the big picture i.e. the delivery of a piece of functionality to the business.
I guess the theory is that if we put everyone working on similar things on the same layer in the same team then it will result in greater productivity than having people who are working on different areas of the system but have the same underlying goals.
The problem is that we create a lot of handover points - opportunities for context and information to be lost - and the ineffectiveness of this approach as a communication mechanism means that it takes much longer to integrate the components from each horizontal than it would have done with a team with people from each layer in it.
In addition any techniques used to try and increase the productivity of an individual team will be ineffective since they will only satisfy a local optima and will have a knock on effect to the rest of the system.
For example, let’s say we have three teams A, B and C and team B aren’t as productive as we were expecting. Applying pressure to team B may have an impact on their immediate productivity but it’s likely to affect the other two teams since team B will probably be less communicative towards those teams since they are trying to optimise their own performance.
Having a vertical team which is responsible for the delivery of a feature or features end to end works much better from my experience.
Colocated vs Distributed teams
One of my favourite agile ideas is having a co-located team, with the business people, analysts and developers all working in the same physical location.
Sometimes though the decision is taken to distribute teams across multiple locations - be it because that’s more convenient or cheaper to do.
The big picture i.e. project delivery is likely to become more difficult to achieve due to the increased cost of communication that has been created.
For me there is nothing better than face to face communication - even with phone calls/instant messaging/emailing it is still an extremely valuable form of communication. With any of the other three it’s much more difficult to read what someone is really thinking and you can come across as being much more aggressive than you intended to in any of those mediums.
My colleagues in India/China will certainly have some tools/techniques to bridge these gaps that I’m not aware of but I still remain convinced that if we have the choice then a co-located team is the best choice.
In Summary
These are just some of the ideas that came to mind when trying to apply one of the principles of lean to software development teams. Although many of these may seem obvious sometimes it takes another angle of looking at the problem to make that visible.
If you can think of any others feel free to mention them in the comments.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.