Agile programs in organization start either in public or stealth mode. They are either, all-teams-together or pilot-team-only agile programs. ‘Public agile initiative’ has team or organization announcing its agile initiative with a big organization wide fanfare. Stealth mode programs are executed with limited or no noise, with one or more specifically identified teams. Agile programs can also vary depending on the number and intensity with which different agile practices are adopted. Some agile programs may start with few agile practices, others may prefer wholesale process adoption for experiencing the synergy of practices done together. If the public-mode agile initiative is started as an enterprise scale program, the pressure of getting agile transition successful mounts on the stakeholders – the risks and impacts are higher for enterprise level transitions.
Agile programs start with adoption of few commonly known practices by teams. Scrum adoption will start with user stories backlog creation, sprint planning, user stories acceptance review, daily stand-ups, retrospection etc. Teams will receive their first few training lessons from agile coaches or practitioners; who will train them to get these practices adopted immediately. It is important to follow these practices consistently on each sprint because they provide the needed structure for iterative and incremental development. They are important for tracking, communicating and executing in agile iterations. They are our agile ceremonies!
Agile stakeholders, with short and limited vision, soon get lost in agile ceremonies. They think that the agile transition job is done, and results will follow once these practices are adopted. In reality, it’s just the beginning of an agile journey. Inexperienced leaders and managers review and enforce on-time execution of these celebrated events. The issue scope, time and speed control directives – ‘Sprint planning should be complete by Monday first half’ , “We would like to see all retrospection done by Friday morning before the end-of-sprint”, “How many story points got completed compared to other teams”, “Can we increase number of user stories getting started or accepted in a sprint?”. They think, only work required to complete the agile transition is operationalizing these activities consistently without any failures.
Well, when we focus too much on these ceremonies and start using incorrect measures to judge the progress of agile initiative, soon the system gets skewed to reinforce activities which are not in interest of agile improvements. Management rejoices; they see their success in implementing practices as-planned. They are getting their reports on time; they know what is planned for each sprint deliverables, and who is working on what. They can hold the team responsible for not delivering on the planned items for each sprint, and they can do it more often in agile.
My advice to agile stakeholders is — ‘ground yourself’. You have just launched an agile rocket in space; you have big tasks ahead to get it into a right orbit, and then drive it into an unknown but continuously improving territory to reap real benefits endlessly. Agile leads need to initiate continuous improvements in practices, technology, tools, values, principles, competencies, collaboration, communication etc. within teams to drive agile efforts to next level.
Following are some of the questions agile leads can ask (in no specific order) to trigger continuous improvements within teams:
- What is the commitment level of team for agile (scrum)? Do they just comply or commit to agile?
- Have all teams adopted scrum?
- How teams feel about agile initiative and different way of working? Do they have objections or resistance to scrum? Have we provided teams the open environment to voice these objections?
- Do team member understand and embrace agile values and principle?
- What has improved? What is the improvement in quality, productivity, predictability and cycle time?
- Are scrum teams self-organized?
- Is your product owner involved?
- What is the status on emergent agile simple design, test automation and continuous integration?
- What are the continuous integration challenges?
- Are you practicing more matured agile practices like Test-driven-development and Behavior-driven development? Are these XP development practices yielding noticeable results?
- Are your scrum masters trained? What other training are needed for the team?
- What is expertise of the team in user story driven development?
- Do you have a checklist for “Done-Done of user story” and “Ready-Ready for user story”?
- Has the code and design quality improved? How we can improve it – TDD, refactoring, reviews?
- Do your teams know how to create iterative, emergent design or you still do big-design-upfront within sprint?
- Are sprint retrospection leading to improvements?
- What needs to be changed in your values, principles and culture for better agile adoption and continuous improvements?
- Do we need different measure for agile?
- What are the impacts on external teams (facility, HR)?
- What needs to be done to improve communication and knowledge sharing?
- Are your practices supporting agile values?
- What are the challenges of distributed teams? Are we able to scale scrum?
- What are the wastes in our agile development and how we are eliminating them?
- Are we always working on most important items?
- Are we able to complete testing within each sprint?
- Are we able to handle sprint interrupts?
- Are the teams adequately staffed with right skills sets?
- How are code reviews done?
- What is the expertise level for each adopted practices?
- Are we using right tools for the agile practices?
Initiate continuous improvement programs to improve the agile journey. Identify, plan and solve problems which are hindering agility. Create a recognized ‘agile transition committee’ (ATC) responsible for identifying, creating, managing and supporting the improvement plan. This can be a team of key stakeholders responsible for agile transition with agile coaches, experts and enthusiasts. The primary function of this team is to create a backlog(like a scrum product backlog) of actionable, improvement items, ensure that they are allocated for actions and all necessary support, resources, and guidance is provided.
ATC can facilitate creation of ‘Continuous improvement task teams’ (CITT) to work on specific improvement items. They can be full-time or part-time teams. CITT can be a formal or voluntary team. Voluntary teams have an advantage of commitment. They can build communities around the improvement items to re-enforce and build expertise for continuous improvements. They are committed to addressing cross-cutting concerns. CITT can also be one of the existing scrum teams including the tasks of improvement plan in their iteration backlog.
 |
CITT can target one improvement at a time and research, observe, model, implement, promote and transfer that across scrum teams. CITT can run their scrums to work on a continuous improvement backlog items. ATC team should facilitate overall improvement program and prioritize the improvements for value added results.
Continuous improvement is the engine on which the agile initiative survives and grows. It’s the heart of agile. Without continuous improvement, the agile efforts will not succeed. Organization gravity will kill stagnant agile initiatives.
ATC team will work like a scrum team with an agile improvement backlog; delivering improvements every iteration. They will also act as a product owner for ensuring improvement backlog is prioritized, groomed and ready to be consumed by CITT.
Create and manage continuous improvements teams and communities within organization to fuel your agile initiatives.
Technodeation 