As part of an agile transformation, I was guiding an organization towards smaller batches enabling more frequent inspections of the organization’s progress against a ‘known good’ definition-of-done. For complex agile projects, this approach validates that the correct collective progress is being made, and ensures issues are addressed as they are uncovered.
The organization was insistent on retaining their traditional development mindset and keeping their dependencies documented using ‘depends on’ links, effectively generating a dynamic Gantt chart. Whenever a team issued a new dependency link, the dependency got an immediate high priority from leadership until the two teams agreed upon a path forward together. A new dependency would disrupt the receiving team who had other critical work to complete. Over time, the teams reverted back to on-going partial work with ever increasing dependencies on other teams. The onslaught of dependencies disrupted teams from reaching their sprint goal, lowered their definition-of-done to maintain velocity, and undermined their predictability.
How one handles dependencies are completely different in traditional development compared to agile development. I have struggled to help leaders understand that there are two ways of delivering complex programs, that these two ways are based upon different principle sets, and that they are executed with different expectations and rituals.
Traditional development follows a series of milestones of progressive decision making over time, for example, serial agreements to business case, product requirements, architecture & design, implementation, validation, market readiness and finally product launch decisions. A traditional development Gantt chart maps out the program plan with dependencies within the phases showing where one team’s outcome enables another team’s work. This is consistent with traditional development’s making a plan and executing the plan. The use of the phases helps provide early detection that something’s amiss. For example, if a team cannot complete all of their architecture & design decisions by the design complete date, executives know that they have an issue early in the program.
Agile development is different, first and foremost, because the product is in the continuous state of being ‘ready to ship’, or ‘done’. To do this, means that product backlog and architecture has been constructed such that the teams can work independently and incrementally in design, development and validation. At any point in time, all teams can operate and inspect the current ‘production’ system. When everyone agrees that sufficient customer value has been achieved, the system is immediately released to customers. Equally important, no one team is allowed to cause builds of the whole system to fail, validation to become stalled, or deployments to the staging environment to pause. Even during early development, any of the aforementioned events is equal to a production outage and teams do everything to return the system to ‘production’ quality.
So, how are the interim agile development dependencies handled across teams? Think of a traditional program’s Gantt chart as being a horizontal relationship map over time. Now rotate the Gantt chart 90 degrees where an incremental agile program outcome is at the top and all necessary work cascades downward to stories that teams complete during the same sprint (or a few sprints). This is called, a hierarchically structured backlog, where stories are completed to enable an epic, epics are completed to deliver a theme, where each issue type of the hierarchy is ‘done’ and inspected. Each and all teams’ progress can be inspected and tracked.
But using vertical dependencies, or a cross-organization hierarchically structured backlog, planning is focused on a series of inspectable, incremental, cross-team outcomes that keeps the system operational even when feature-poor. This allows surfacing unknown risks early and uniform inspection of progress across the whole organization. When there is a failure, the identification of the root cause and corrective action can happen quickly to enable the current incremental outcome and adjust the future outcomes.
Agile development’s known-good, production quality first over traditional development’s feature design and coding first allows leadership to have a common standard to inspect and understand progress. Traditional development’s strict phase-driven decision making allows leadership to have a different standard to inspect and understand progress. However, a mixture of low quality implementation and loose phase-driven decision making means pure development chaos.
No comments:
Post a Comment