Coaching and playing Scrum Master for an agile/scrum team in the midst of a multi-national company with strong IT skills-based, enterprise-wide teams (PMO, BA’s, etc.) is an ongoing challenge between gel (still mostly liquid), jello (sort-of solid, transparent), and glass (it might be transparent, but it isn’t malleable anymore).
My current product team develops the integration components (usually APIs) between major corporate systems (like SAP) and other internal and external systems (customer portal, country-based government agencies, warehousing systems, etc.). The team is newly formed – a larger and more agile incarnation of the first version of the product and the team.
Overall, the company was created in 1935, has 500 offices in more than 70 countries, and over 14,000 employees. At a corporate level, agile planning and agile approaches are not generally in use. Two IT projects are approved to work in an agile fashion: the customer portal (using SAFe) and our integrations team (scrum, but not SAFe).
Even more than the portal team using SAFe, we are pushing the edges of the envelope, bleeding the edges of entrenched IT teams, trying to press to be ever-more agile when it comes to servers, middleware designs, architecture, and deployments. Just when we think we have a commitment from one of the skill-based teams to try something different, the next day, the agreement is retracted (“clarified”… ‘oh is THAT what you meant?’) and we have to explain again how agility is a better approach for this team.
Scrum planning is bit like making jello. The newest items in the list are mostly liquid. As we do Backlog Refinement, getting the backlog ready for Sprint Planning, the most important items move into the ‘early jello’ stage – like jelly for your morning toast. Thick but still malleable. After Sprint Planning, we’ve got stable jello for the items within the Sprint. No more stirring. We’ve got jello cubes or gummy bears. Unfortunately, our team is still required to solve the level-3 production bugs and not all of the requesters are informed about the new Demand Pipeline, so during our 2-week sprint, we get some additives mixed into our jello. Marshmallows and celery pieces. Not ideal, but we all make an attempt to keep these to a minimum, and focus primarily on our sprint commitments. Kinda like adding celery or marshmallows into the jello after it’s already done. Lumpy. Crusty. Distracting.
Unfortunately, the Dev Ops approach and ‘continuous anything’ haven’t taken hold here yet. Letting go of control by the enterprise teams and distributing these skillsets into the scrum/product team, is definitely out on the bleeding edge. We’re still working on this arrangement. Experiment-to-learn and ongoing adaptation isn’t a natural behavior here. Still very prescribed. Still a strong design-engineering mentality. They have not learned to operate in ‘jello style’. Cross-functional teams is an idea that seems, to these teams, to be a method that relinquishes control and risks quality, consistency and cost controls.
So why and how did this one integrations team gain approval to work in an agile way. Ironically, because the leader made a great case for how this method could enable this team to deliver working software more often and adjust to changing corporate priorities. We seem to be the only team which delivers components in support of so many other projects (most teams are dedicated and focused only on their business application). Our integration team’s priorities flex on a weekly basis as the requesting projects which need our integration components change their priorities and overall requirements. We are the tip of the funnel in the Demand Pipeline of corporate priorities… our User Stories are actually created from implicit User Stories from other projects. “As the Finance Team, we need to send invoice tax info to the local tax authority in XYZ country….” While we have a ‘gatekeeper’ Product Owner, the Demand Managers for their specific business units are the owners of the projects that need us to send info from points A to B. And they are all jockeying to a spot at the head of our one queue, at the tip of the funnel. And so our backlog prioritization is constantly changing. Scrum is a very good approach for us because of this. We maintain the ability to flex. But….
Success for an agile team using the scrum framework inside of a waterfall, fairly ‘glass-like’ engine, means constant adjustment. We practice process agility, not just product agility.
And herein lies the ongoing value of coaching. Making jello, being agile, in this large and very structured environment is difficult on a daily basis. As Scrum Master and Agile Coach, I play facilitator, trainer, consultant, and coach. Sometimes cheerleader. Sometimes therapist. Protector and Defender of the team’s approach. Communicator of the value we have delivered, in spite of skirmishes along the journey. Purists might say that coaching toward agility in a big waterfall, engineering-driven, non-agile company is a lost cause. But I prefer to focus on the people I’m here to help. How can I facilitate their own journey? How can I help them deliver value is spite of the environment? How can I help them learn models of teamwork and communication that will be a part of their ongoing life and professional journey?
The personal touch… making jello in a glass bowl.
