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
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 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
The product owner (PO) role requires multi discipline skills, for examlpe:
– Be responsible on deciding the right features at the right time
– Manage myriad of potential sources of requirements
– Product road map development
– Release planning
– Establish ROI from various features
– …… Continue reading
– Write code without having test cases
– Unavailability of required skill to complete features to be demonstrated to client
– Check-in code without having continuous integration server
– Deliver software to clients which can only be implemented by engineers instead of client facing consultants
It’s proactive if we can visualize issues assess their impact. This impact can be immediate by clogging the flow or by inheriting more owing to our already building up technical debt.
Root cause analysis done after confronting failure is of little value. It’s after the fact and tells us what we should have done earlier. Root cause analysis is excellent for learning; however, if we lack the ability to translate this learning to practical actions, the value is little. For example, analysis of root cause of being diabetic is useful, but the cost of correction is prohibitive.
Producing client valued software which is not easy to implement is consequence of decisions we made at the early steps of our delivery cycle. The surge in the implementation cost from one client to another can lead to re-architect of the product, instead of adding enhancements to the product to address new market challenges.
Many of the above consequences could have been highlighted as we visualize the flow of value prior to delivery. It’s not enough to remove the issue to enable flow. The learning we gain from assessing the issue impact at the moment when it happens is vital for organizational learning and change management.
Visualized issues are opportunities for organizational growth through learning. We as software organizations can only grow by learning and imparting this new knowledge in our development practices and work standards. This learning is unique to every organization and it questions our DNA and work tradition. Resolving issues related to technical debt is where we shift from the current-state to the future mode of operation.
Sizing is focused on answering, “If we assume no identified requirement risk, what is the size?” This is useful, but it can be harmful if it’s used for estimation while potential risks are ignored. If that happens, we might achieve high team velocity while the overall system throughput is low. Also, it can widen the execution gap between the team and organization as the team wants isolation in order to achieve its velocity. I found many teams who are devoted to measure their velocities are almost always operate in isolation from the rest of the organization. Once, they begin to align to the organization, velocity becomes of less relevance.
For me the above point is specially critical. The team increases productivity is the driver, while the reality is that the team increases the velocity of divergence from the organization.
Measuring people performance based on number has been always warned against as it:
– Reduces team initiative because the team is focused on achieving its velocity target if it ignores all aspects important to operate in harmony with the organization.
– Leads to non-meaningful comparison between different teams in the organization based on the velocity of each.
– Misguides the organization because after all velocity is a vritual figure at it has no baring to what brings value to the client.
There is lot of literature about performance management and team performance which do not relate to the performance in the Engineering aspects.
We should focus on measuring:
– the business valued features which the client appreciates,
– the cost per feature delivered to the client, and
– Lead Time.