Each team operates under a different context. The purpose of this post is to characterize team context using objective factors. This characterization should improve our understanding about what can matter most when developing a team Agile process. Continue reading
The idea of project in operations management helps to understand the demand on the organization by adding the dimensions of required effort, delivery interval, objectives/ scope, client and required skills. Project planning serves to define the previous attributes, while project execution and tracking is a common way for full-filling demand. 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
Lead Time is the average time from when client submits a request till related software is produced. Cycle Time is average time between two successive releases from the system. The lower the Lead Time the higher the Throughput, which is number of client-valued features, released every time interval. Ultimately this impacts the bottom line by having lower cost per feature. Continue reading
In order to stick, the rollout of Agile across various teams should be support by organizational processes. The rollout should be considered only as one component in the overall process improvement initiative. The following diagram shows the 5 main pillars for organizational agile transformation.
The OSSP helps to have uniform understanding of what management expects from every team with regard to its development process. Apart from its own flavor of agile, the team should meet these expectations. OSSP should be light-weigh document and is neutral, means it does not prescribe any specific technique. OSSP is intended to encourage the team to figure out their process while meeting management expectations.
Visualizing end-to-end value stream is where the organization can have an overall look on the MMF in every stage of the value stream. A project can have involvement from multiple teams before we can deliver client value.
Team-wise agile roll-out should be tuned to the context of the team. We should not impose the team process, instead we should help the team to figure out the suitable agile process which satisfies OSSP requirements.
The Metrics pillar provides measures which are directly tied to the organization business objectives. Metrics derive the improvements to achieve the objectives. Metrics include data collections, validation. analysis and reporting. Metrics form common communication language for objectively understanding the capability and maturity of the organization.
The Periodic Process Appraisal pillar helps in establishing continuous process improvement function in the organization. This pillar provides opportunity gaps on the different facets of process implementation including team agile practices, engineering practices, meeting OSSP requirements and Metrics sanity.
Going to the plain basics, maturity is to deliver what we promise. I heard this definition from a successful sales executive of product development company. For me this summarizes everything!
Meeting commitment is arguably the most important criteria for success. I use the measure of requests percentage which have deviation from target date exceed “x” days. This measure helps to quantify our maturity as organization. It represents the Voice of the Customer (VoC)
This measure can be organizational wide and it can be used to drive the whole improvement initiative.
The following chart gives high level analysis of causes of immaturity as suggested by this measure.
The foundational cause is the inability of people to timely communicate their issues. I worked with developers who had one month-long tasks and kept reporting that things are according to plan till they report failure at the very last day! I carry the responsibility by not allowing trust environment which encourages them to talk and share their concerns.
Sales people making commitment without consulting engineers is well-known issue which can be solved if they are educated about the capacity measures. These capacity measures can directly improve the above VoC measure. The capacity measures include Average Lead Time for each Class of Service. This measure allows sales people to provide informed estimates in the very narrow window that they might have to secure a deal. They can add percentage of uncertainty based on the inherent risks. I suggest this should be maximum of 20% with promise of being reduced as we proceed into the project.
Finally, a key assumption for failing to meet our commitment is the poor definition of customer valued request. Delivery on time requests which are not meaningful actually invalidates our improvement effort.
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.