While examining an agility initiative and implementation look out for good, bad and ugly practices and conditions that are affecting the agile environment.
First, focus on what’s good and spend most time strengthening, and building upon what works.
Then, fix what’s bad through the understanding of the organization’s needs and following practices that are suitable for the teams.
Further, try to eradicate the ugly through the promotion of understanding of agility values, principles and practices.
Finally, improve your environment and practices based on feedback.
Rinse and repeat!
Here are some examples of what was identified at several agility initiatives and transitions I was involved with:
Identifying these conditions helped to analyse and experiment corrective actions:
1. At the independent start-up …
we set up the three development teams for Scrum and the systems architecture team under Kanban. Then a PO guideline was established for the product manager to follow and was coached to create a value backlog. Finally as the new CEO was a fervent Prince2 believer we included sprints into the Stage delivery phase of Prince2.
2. At the specialized department of a big enterprise …
the defined value streams were ready for agile yet Scrum was forced across the organization. Revision of agile values and principles helped adopt agility, some dev teams went for Scrum and others for Kanban, IT Ops went for Kanban. Some pople reluctant to adopt new WoW were discretely set aside with assigned maintenance tasks. The DevOps principles once understood by all, allowed for the adoption of a shared services model between devs and ops staff. Then POs were trained and coached towards value delivery, PBL creation and maintenance, and work prioritization, guided by fit for purpose value and cost of delay. Finally, Product managers, CTO, and COO were invited to share a common working space, this reducing micromanagement of teams and improved communication among them.
3. For the single development project …
the clarification of agile values and principles helped the team to set the delivery approach and opted for a flow management set up to change their ways of working. This brought both main stakeholders to the table in an effort to work out a coherent PBL. The power conflict became more of a cooperative dialogue.
4. For the internal start-up within a multinational …
the will and finances for the agile WoW enabled securing the right skills for value delivery. The development done via Scrum by the vendor was managed through a Scrum of Scrums approach and a PO strategy was designed and set in place to regain control of the value stream. Scrum practices by the feature teams were enhanced with Kanban practices at the PO level and component team level, together with a DevOps mentality to infrastructure facilitation. The vendor was replaced by internal development staff and IT Operations contracted to a single supplier.
5. For the services unit at a major bank …
with leadership sponsorship and a team of coaches, the agile transitioning of teams was able to go ahead. The implementation of a scaled agile concept, a copy-paste version of a model that worked for another organization, posed a problem as it was not quite fit for purpose for the situation. Therefore the approach was mainly to coach teams towards their own agility as well as promote an understanding of agile values and principles among the leadership. A certain coaching of PO practices followed with a view of creating coherent backlogs for teams to work out of. The command and control culture began to be diluted among agile practices that encouraged tust and team empowerment . The set up of an agility community of practice and center of excellence could help hedge different agendas for the agile transition.
6. At the IT solutions department of the insurance company …
the agile pilot wasn’t a great success as teams were pushed to participate, hence the forth coming approach was to promote agility while offering a service by which teams can be coached into the new WoW if so desired.
The first step was to identify the value chain the projects belonged to; then set projects for agility through 3 things: creating viable backlogs, setting or adapting teams for cross functionality, and agreeing to deliver value frequently. We followed by defining workflows, focusing on responsibilities and accountability to define roles within the teams. Finally, we addressed the work intake process and the minimum business increments to be delivered. Although this all made sense for most teams it somehow clashed with the command-and-control approach from the management who took agile metrics for a means of reporting and justification. Agile coaching ways cut short by budgetary cuts.
Agile Ways 