Cost originates from Investments to hire and retain talents and maintain required hardware, software licenses, training and similar cost. Another part of the cost is the operating cost for the organization, for example, rent and furniture.
From my background the operating cost is a fraction of the investments required to keep the talent and sharpen their skills so that they are capable to provide technology products.
Software development is almost solely relying on developers from various skills to achieve the goal.
Unless these knowledge workers collaborate effectively, then it’s matter of luck to realize our goal.
A typical software organization has multiple engineering teams, quality assurance, release engineering, architects, systems engineering, integration professionals, implementation consultants, and account management.
Imagine on organization which has ten teams and there is a visualized issue which clogged the flow. The issue can’t be resolved by the reporting team alone. This team might need to talk with 1, 2 or more teams in order to figure a resolution. From my experience, we usually can have the issue resolved by not more than four teams in most cases. Assume each team report one issue daily. This means that the possible lines of collaboration = C(10,4) = 210
Forgetting about combinatorics of communication complexity, these lines of communication can be assessed if we can visualize the flow with all involved teams.
I suggest the following:
- Hold 2-3 times a week visual board meeting.
- Meeting is attended by product manager and engineering manager from every product development team. A manager or senior technical person is required to attend from each other group.
- The work-flow on the visual board contains a stage for every team or activity required for delivery of value to the client.
- The card on the board can be MMF or any professional service required to enable the flow.
- A card should have target date based on the scheduled release plan of the organization.
- A card should have date when it was added to the board.
- We use red sticky to indicate there issue related to this card. As I mentioned in my earlier blog-post here?, an issue is defined as what stops us to complete the work of the card according to the DONE criteria.
- Ask the teams to have their work up on the board and look at the cards existing in the stages of other teams.
- Questions should be directed towards surfacing team dependencies.
- I recommend the following four questions to be answered by every team:
- What you do in your team than can affect others?
- What other teams do which can affect you?
- Do you have any issue with one of your team cards?
- Does your team know which card to pull next?
- The previous 4 questions if thought about and answered would almost always reveal the hidden issue.
- The red sticky note should provide description of the issue and date when it was reported.
- Before the meeting ends go through the issues with the team and help in identifying people who would participate in solving each issue.
- At the next stand-up review the status of the issues and asks the directly affected team to provide a status. Issues which stay around for more than x business days should be appropriately escalated.
- The solution for resolving an issue should be assessed that it doesn’t only provide near term resolution but longer term avoidance of adding to the technical debt.