There are two ways of running your organisation. The more common of the two is to do some form of project-based planning. In this model, the management of the company defines the roadmap – they come up with a prioritised set of projects and allocates time and people to them. For example, they may decide that a team will spend two months on some new search functionality. The team will likely not change, but the project and domain typically changes frequently. If you were to look at this roadmap, you would see different projects typically with rows per team and projects “assigned” to them.
Due to the nature of software engineering, it is rare that a week goes by without this roadmap changing significantly. New business opportunities come along, priorities change, and the plans have to change accordingly. Alternatively a project will take longer than anticipated so all subsequently planned work has to get pushed back.
These roadmaps are usually filled with an abundance of assumptions, and are typically created without any solid information or knowledge of what needs to be done or how much it will cost. This often results in the plan never being truly realised. This can be a massive source of frustration for businesses and development teams alike. These assumptions are often made from people outside of the teams and are done in a very dictatorial way, which can quite easily and effectively quash both innovation and collaboration.
The alternative to the above is to move across to a product team based organisation. This is the way forward, and an option that companies are increasingly turning to in order to try and improve how they develop their products.
In this model, the focus is instead around which areas of the business the company wants to invest in. This removes the focus on projects and instead allows each product team to be able to focus on what is best for it. It is important that the product teams are given space and freedom in order to innovate and collaborate effectively. This means that the business should present a problem to the relevant team, and allow them to come up with the solution.
The teams should be cross functional, composed of members who are capable of carrying out any and all of the tasks that may arise. Over time they will develop a deep understanding of the domain of their product, meaning that the longer they are kept together on the same product, the more efficient they will be become. Tie this in with the concept of continual improvement and you have a recipe for success.
Making It Work
There are a number of key points that I would advise you to follow if you truly want to make the move to product focussed development teams a success.
- Do not prescribe a solution to a product team, give them the problem you are trying to solve and work with them to come up with the best solution
- Resist the urge to be dictatorial and tell people what to do. This quashes innovation and collaboration
- Allow the product managers to be fully accountable and responsible for what happens in their product. Give them steer in order to ensure they are working towards the overall company objectives, but allow them to decide how they will get there
- Give everyone an equal voice – collaboration is key to success
- Limit the amount of people involved in making decisions. The more people involved, the more painful and difficult the process of agreeing a way forward
- Agree on a scorecard for giving backlog items, which will effectively highlight which work will give the biggest ROI
- Do not follow ‘Agile’ like a religion. Every company is different, and whilst the core message will be the same for everyone, the best way to implement this will vary