First, I state that I can’t improve the process; instead they should improve their work. I found this statement helpful by allowing the team to assume responsibility on their work and to position me as coach for building trustful relationship. The last thing they should worry about is that I am going to expose their weaknesses. This step is foundation for successfully working together. Trust shouldn’t be declared instead it’s judged by the team. Continue reading
The Japanese came with the idea of delivering products according to client demand. This is less obvious in software development organizations. This post intends to clarify this subject of demand analysis. I guess all organizations want to maximize their Throughput to meet and exceed client demand. The first step towards this goal is simple; understand client demand to arrive at patterns. We should build our software capability to address those patterns so that we can satisfy the demand. Continue reading
In a previous post here I discussed the benefits from having team value stream (TVS) to encourage collaboration and facilitating resolution of external dependencies.
Usually a product development organization has multiple product development teams with each operating under different context. TVS is useful tool to make team policies explicit and visualized to its members and the rest of organization. Continue reading
Arguably, a software development team should not have a value stream (VS). This is because VS is a manufacturing tool and tends to be suitable for liner deterministic process which is not the case for Edge-of-Chaos nature of software development. Continue reading
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.