It is common in larger traditional organizations that product and/or service delivery is managed through delivery life cycles (DLC). The release is a constraint imposed upon the delivery system. Agility can be brought into the delivery system through decoupling the release outcome into objectives and focus areas while following simple fundamentals.
Driver, Structure and Organization
The work process is driven by the release outcome, structured by iterative/incremental flow practices following objectives, and organized through dynamically organized teams and specific support services (Fig. 1) .
The established value stream is guided through the simple agility fundamentals of working on the most important things cut down to its smallest possible value; finish started work before taking on new and seek/provide help from/to peers; deliver value on a regular basis and seek feedback as often as possible; adapt work process iteratively.
The dynamic organization of the larger team allows for better focus on objectives as well as enabling the delivery of value. Dynamic organized teams [1] (DOTs) concentrate on building the required components of the desired objective, while specific support services (3S) through testing, and other eventual specific components, facilitate the delivery on demand from the DOTs. Such regrouping of the larger team into smaller temporary focused fractions favor communication and cooperation while avoiding the creations of silos within the team.
Fig. 1
Iterative flow system (IFS)
The iterative flow system encourages a combination of both iterative and continuous flow practices. This allows for the different teams (DOTs and 3S) to process their work in a coherent and adaptable manner (Fig. 2) .
Fig. 2
The first step is to identify the appropriate iteration objective which will guide selection of work items and the appropriate focus areas to achieve the objective. The full understanding and acceptance of the work items will allow the formation of DOTs and 3S accordingly.
Work items related to the iteration objective will be taken by DOTs, all other work will be the concern of the 3S who work on a continuous flow basis. The DOTs may in turn request the services from the 3S to deliver their work.
The events governing the iteration flow are:
- Work intake process (planning), where work requests are prioritized and sized by work type and class of service, sequenced, and accepted upon understanding and the team capacity.
- Objective update (daily, or whatever cadence best suits the team), is about alignment to the iteration objective, updating information, dealing with impediments, and managing dependencies.
- Review and reflect (verification for success and learning) session to close the iteration, for feedback gathering, pivoting decisions, and inspect and adapt according to new findings and evidence.
Some guidelines
To enhance the operation of the Iteration Flow System a series of guidelines seem pertinent:
- on dependency management: identify dependencies early, at product backlog creation, and factor in dependencies at work estimation.
- on prioritization: size the work items (see if they fit into an iteration) and their cost of delay (the impact of delivering late).
- on throughput: associate work cadence to the amount of work finished in a sprint.
- on estimation: measure average cycle time (from the moment work starts until it’s done), and/or lead time (from the moment work is accepted until it’s done) helps with expectations management.
- on success alignment: use Release burnup instead of iteration burn down (cumulative flow diagram could be an option) it’s more gratifying and provides good information on advancement towards the release outcome.
____________________________________________
[1] definition: dynamic organized teams are ephemeral groups of people assembled – the duration of an iteration – to address the solution of a particular focus area.
Note: this paper is not intended to be a theoretical document, it is just a testimony of evidence gathered while working with several teams whose agility suffered under the release constraint. While this exercise was not enough to “agilise” a quite rigid organization, it certainly helped the teams make their ways of working sustainable (in line with principle 8 of the Agile Manifesto)
Agile Ways 