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.

In the world of agile software development, and the scrum framework in particular, frequent retrospective sessions with the team are a natural part of our work cycle. As scrum master and coach, I bring the team together to discuss how we are getting along with each other, whether we need to tweak our process to improve the flow of work, what recurring impediments we could solve, and what new concepts we could learn to improve overall teamwork.

Last week, I introduced my team to Edward de Bono’s Six Hats and Tuckman’s Model of the cycles that teams go through as they learn to work together (the Forming-Storming model). While both these models have been around for decades, they were new to the team members, and have been quite helpful in self-retrospection. The team now has a common language and a common mental model for understanding the team behavior since, after only 3.5 sprints, we are deep in the heart of the storming phase. And, they now have some options on what ‘hat’ they might choose to wear as they have difficult design choices to make. We also like using the Squad Health Check cards to assess 3-4 elements after each sprint.

But this week was a bit different. A good and healthy alternative. This week, our team manager is moving on to another company, spreading his own professional wings in other directions. So yesterday, instead of our normal retrospection, we took time for a bit of team bonding. We headed out to happy hour at a rooftop bar here in Lisbon to just enjoy each other’s company, learn a bit more about each other personally, and take a breather from the difficulties and stresses of the project. The outing was my idea, and apparently, a happy hour outing as a farewell is not too common. For me, these outings are the moment when the now-ex-boss shifts into possible friendship mode. Lisbon isn’t that big, and we all may see each other again soon. It’s good to build bridges. And, our little excursion, much like personal vacations, are a chance to breathe deep, laugh a bit, strengthen the personal bonds on which the success of difficult decisions rely, and just have a bit of crazy fun.

Here’s my team. We took a normal straight photo, but then I wanted the crazy one. This was taken at the Sky Bar at the Tivoli, on Avenida Liberdade, Lisboa. 🙂