From my view, Program Management Office (PMO) helps when we engage with clients to address their requirements which can be full-filled through managing group of projects. PMO should use Work-Breakdown-Structure (WBS) as key tool for identifying required deliverables. By logically grouping these WBS items into projects, we can manage the whole work as an overarching program.The aim of this post is to relate the WBS items to Feature card (MMF) for managing requirements. Continue reading
The visual board models the value stream. The stages of the value stream are exhaustive list of possible actions that could be applied on a certain feature card. This regardless whether this feature card represents new feature, client specific enhancement, requirement defect or bug. For me every stage in the value stream has analogy with method which is allowed to operate on certain object (feature card).
This analogy can be particular helpful to unify the understanding on what we could do when we process a certain feature card. Extending the use of the ticketing system to keep creating tasks linked to a ticket (card on visual board) can lead to waste due to micro management through task assignment. Instead confine the ticket to represent a card and use the visual board to:
– Provide common understanding of the value stream
– Ensure uniformity of methods which can operate in a certain card (UX, Graphic design, architecture, development, code review and so forth). This particularly can be helpful to improve the skills of people to better perform those methods. This has direct impact on quality and economy of delivery.
– A corollary to previous point, this analogy can serve to reduce dependency on single point of failure.
– Help to have consistent mapping of status of tickets in the ticketing system to the stage of visual board.
Exploding the ticketing system with tickets can be misleading because we should have business value attached to the ticket. Also, it reduces collaboration as task ticket is assigned by a team leader instead of being pulled by assignee whenever he has capacity. In general I found this creates inconsistencies.
Ticketing system and visual board are complementary. While the ticketing system is excellent for tracking, automating builds and communication with other support groups, it has limited value during the development of the feature card. Feature card development is a different game which requires high collaboration through visualization and having the ball bounces back and force between various stages of the value stream.
Despite the delivered software has no bug, it is not uncommon for clients to ask for changes. This for me is a Requirement Defect. This corresponds to Validation activity of the V-model to ensure that software would be working and acceptable in its intended environment. Software Validation is implemented in Agile through product manager review. Continue reading
The product backlog is arguably the most important artifact for Agile team.
The problem is how to ensure that the product backlog timely includes all requests with their relative prioritization apart from their source.
This takes us to the product owner role in managing the hand-offs from demand to the development team(s) using the product backlog as medium of communication.
The biggest team complaint is that there are back doors for pushing requirements. This situation leads to:
– The team takes prioritization decision.
– Rift the team from following the value stream due to uncontrolled work as it’s not included in the visual board.
– Compromise the product by making the team working at low value requests.
As shown in the diagram, the product owner is responsible to coordinate with all possible sources of requests and translate their needs into prioritized backlog items. The backlog item is a card on the visual board and can either be MMF, Defect or Service. It is important to have explicit policies for each of these three types. Adding the dimension of priority (regular, target date and urgent) can add rules to these policies.
Finally, being a gate-keeper, the product-owner can ensure:
– The integrity of the product,
– Avoid adding requests which create technical debt,
– Assume ownership on the product acceptance, and
– Be considered by the team as the ultimate authority for clarifying requirements.
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
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