Have you ever heard someone say that you should focus on your strengths and not your weaknesses? It’s a bit of reverse psychology in the sense that it’s only natural to try and improve those activities that we aren’t good at — our weaknesses — and we should. But if we focus too much attention on weaknesses, our strengths suffer.
Any activity that you do well should be leveraged to the greatest extent possible. Try to do it even better. Only focus on weaknesses that are holding you back. For example, if you’re good at writing code but not so good at designing user experiences, focus on writing better code, faster. Let someone else handle the UX elements. If you tackle them yourself, they will only slow you down and reduce your productivity.
The same is true of agile software development teams. They also have strengths and weaknesses. In the same vein as the above example, the team may do well with server or operating system-level software. They may struggle with desktop applications requiring extensive UX development. They should bring someone on board to handle the UX stuff.
Companies adopt agile development approaches such as Scrum, Kanban, Lean or XP to solve problems. (At least, that should be why they do so. I hope they aren’t just jumping on the latest, trendy, development technique.) For example, they may want to:
- Minimize defects discovered after a release
- Reduce the time-to-market cycle time for releases
- Increase customer participation in the development effort
- Improve the team’s responsiveness to customer issues
In adopting a new development approach, there is a tendency to start over. That is, scrap all existing practices and introduce new ways of doing everything. This is often overkill. Throwing out the good with the bad may make the existing situation worse.
Align team strengths with core agile elements
Before you decide to overhaul your software development approach, assess the team’s strengths and weaknesses. There will be activities that the team excels at, and others that they struggle with. Don’t force them to stop doing what they’re good at in order to fix the problems you face.
Identify the agile skills and workflows needed in the new development approach and align them with the team’s strengths. The team will need to adapt in some areas. There won’t be a perfect match between team strengths and agile needs.
As for those agile core elements left without a matching strength on the team, try to eliminate them. If the team is not good at something, why bother? I know this attitude won’t sit well with some agilists but isn’t this what retrospectives are for? Get started. Be as agile as you can be. Use retrospectives for continuous improvement.
If a skill is really needed and the team lacks it, outsource it or get the team training and/or coaching. Don’t use the lack of a skill as an excuse not to try agile development and don’t use the lack of that skill as an excuse for a failed agile effort.
Bottom Line: Software development teams should focus on their strengths and goals. Weaknesses should be addressed where they limit what the team can achieve.