Frameworks give us a recipe to follow while allowing customization to suit our needs. In my third implementation of a large-scale change from more traditional project management to more agile product and service delivery, I see while each experience has been different – the reasons for change and the frameworks used – the transformations faced similar challenges.
The reasons for change were different.
- Company A: cross-team feature delivery
- This company struggled with delivering to expectations – too many ad hoc requests were going around the project plans, distracting teams from deliverables to urgent requests. The shoulder-tapping demand was out of control and the cadence of delivery was too slow. Managing intake better gave them the opportunity to deliver the most valued features more quickly.
- Company B: more frequent feature release
- This company shifted to agile for one of its many application development teams mostly because the team recognized they needed to release more often than a waterfall approach would allow. The systems needed to be more responsive to our internal users so active backlog grooming gave the team the opportunity to better meet needs as they arose.
- Company C: accelerated platform development
- This company was accelerating their digital transformation so shifting to more agile product development was the main goal. Getting more frequent feedback from our leaders and users enabled adjustment and iteration which was a critical opportunity for this new platform
Some of the challenges were the same.
- People. Even the most experimental of technologists struggled with this new way of working – and were uncomfortable with not being experts. Failing early, often, small and gracefully proved more difficult for teams focused on 100% quality and uptime. Preparing our teams and individuals took more time than expected with a regular leader to laggard distribution. Being both honest and constructive in retros often conflicted – sometimes reverting to complaint sessions.
- Process. The frameworks we used offered the recipe for our new ways of working but each needed to be customized and these adjustments were similar. Our infrastructure teams needed to work more kanban. Program management needed to be reinforced. Reporting to our C suites wasn’t as automated as we wanted. Breaking down our requests to manageable chunks proved harder than expected.
- Tech. The tech stacks shifted along with the move to more agility so we needed to invest in new architecture and release management. We had to retrain our teams in these tech and bring in talent with experience.
- Data. Our data governance – quality and ownership – lagged behind the shift and became our Achilles heel as teams struggled to release quickly with imperfect data, exposing this vulnerability to our users.
There is no one solution for all so lean on agile ceremonies to increase the opportunities and decrease the challenges…
- Don’t reinvent the wheel. It is great to offer your teams one framework as your base so that they can have reference material out of the box. Some will pursue certifications in your selection which can make them active members of your change champion network.
- Don’t mandate standardization. Consider your first program increment to be your petri dish where you experiment with variations of the framework to see what is working best. One example is to let teams define their sprint schedule – e.g. 2 or 3 weeks, Monday or Wednesday start.
- Don’t let perfect be the enemy of good. Get the ball rolling so that the people, process, tech and data can improve over the course of your first 4-5 program increments. Make progress and set expectations for imperfection, celebrating your progression towards your goals.
- Build products… every sprint on every team. Build, demo and celebrate small wins regularly and your culture will shift to one that values outputs over overtime.
#changeleadership
Blue Cairn 