Coaching bears and ninjas

A long time ago, in a galaxy far, far away, friends asked me to help them out with their Scrum implementation. Come in, organize things, it’s not working as we hoped it would, they said. So I went. After all, they were my friends. And, it was an IT company with its own product on the market, which at the time you didn’t come across often. But wait. Of course I didn’t just blindly accept the offer. I did my homework and interviewed them first – what they wanted to accomplish, what was the reality, what opportunities they’d seen, what the expectations were… They were all members of the senior leadership team, so they knew what they were talking about. (Or at least I didn’t challenge that assumption at the time.) I did the same with the COO, the sponsor of my engagement.  

What about the CEO, you may ask. Well, the CEO was not much involved in these things, they said, and was more into things like strategy, board meetings, budgets and politics (?!). Basically, not available. But the COO was in charge of the things I needed, so that’s good, right? I assumed. Anyway, a lot of stuff came out of these interviews that all can be summed up as: things were just going too slow and projects were already late. Frankly, in hindsight, it was actually going pretty well considering what else I found out along the way. Of course, as always in such a case, heroes jumping to the rescue around each corner kept the whole thing together. (Have I mentioned the culture already?)

Alright. That’s just too much for one guy to handle. I needed a team. However, this was no job for the faint-hearted. They needed to have quite a bit of experience, plus willingness to roll up the sleeves and get their hands dirty. And what a team I managed to put together! To make well-rounded, I looked for diverse skillsets and backgrounds. Naturally, as a consequence, everyone had strong opinions and was willing to argue them. But that was good, right? I needed that. I wanted that. I’d rather be working with people with integrity than with ones just following orders. Although, at times I wondered whether I should re-examine this principle. They did put my determination to the test, and not once, if you know what I mean. Anyway, it took some time, and not just time, to get all the pieces of the puzzle in, get us all aboard, create a change strategy, prioritize things and divide the work.

The results followed soon. Introducing cross-functional teams cut the number of dependencies significantly; common cadence and release planning enabled us to plan an integrated delivery of a product increment; scrum of scrums helped manage those dependencies, enabling us to react to unexpected developments and so keep our delivery in check. Last but certainly not least, team coaching started to pay off. People started opening up; some quiet, restrained people started to shine and take on greater responsibilities and voice their opinions. Retros became more useful with teams optimizing their internal flows, team agreements helping a lot with this: what kind of team we wanted to be, what values we wanted to embed in daily work and interactions, what we expected from each role, what had already been working in our favor or holding us back, etc. On top of that, we made reviews fun and focused on live demonstrations and not on burn-down charts, with all the teams and many of the stakeholders present and pitching their feedback. On the other side of the product flow, discovery was lagging, so we helped the product department create a new discovery flow to keep up with improved delivery. (Some said more agile delivery, but then, what is Agile really?) With all this going on, we managed to train the whole engineering and product department in the essentials of the agile approach, focusing on why and not how. Let people understand why we needed to do things a certain way, what context dictated this, when and how this approach could be helpful, and what was required from all of us to make it work. Thus, we hoped, people would make better day-to-day decisions and see easier where the opportunities for improvement were. The result? The company launched its flagship product on time, and within a year cut time-to-market and improved process time by almost 50%. We also helped the company move its focus from projects to products, and that led to a significant investment into building the product department up. Mission accomplished? Well, let’s put it like this: first iteration – done!

But, as you might have already suspected, we came across some bumps – no, potholes rather – along the way. Black ice, you say? Well, good that we were not moving that fast after all. Joking aside, some people still resisted the approach. Even worse, there were islands of this negativity – occasionally, new joiners left in less than a month! Like they had just bounced off. At times, I wondered how all this negativity had come together like that, and… was it done on purpose? So, we began asking questions like what kind of behaviors we wanted to encourage, what kind of decisions we wanted people to make, and how we wanted them to act when no one was looking, what was the hiring strategy regarding this, and, in the end, how we were promoting the right people, and discouraging and ultimately letting go of the people who just refused to fit in. It turned out that even the leadership wasn’t sure, but sure enough everyone had their own ideas. That meant we needed to align the leadership on the culture and values they wanted to promote in the company. Leadership alignment workshops? Checked. Values – done! My team pitched in by helping the HR with how to look for these values and behaviors when interviewing people. And my team also adjusted our change strategy to fit more closely with Chip and Dan’s Switch model. Second iteration – done!

Wait – I haven’t mentioned this yet, but I’d never liked the blind implementation of the Spotify model already in place, because the key elements of this organizational design – trust and autonomy – were, as I became more and more aware, missing. But the engineering department was really fond of it, probably because it sounded so Agile (btw, what was that again?). In reality, it meant line management was not placed in teams but across them, so the line managers, labeled chapter leads, didn’t have the right information on either how people were performing, or if they met the expectations set before them. Both of these, it was becoming clear, were going to be increasingly important in the near future since my team was put under pressure to supply that feedback. On the other hand, I wasn’t convinced the expectations being passed down were in line with all the changes introduced either, as I was more and more aware that my team and chapter leads were not prioritizing the same things. So, I assumed this newly aligned set of values and behaviors would help. BTW, what was that saying about assumptions being mothers of? 

In the middle of all this, a big leadership change came – the COO left, and the CEO took over. For me, that meant I would finally be able to work with the CEO more. But it turned out the CEO had quite a different style of leadership than the COO, and that turned out to be crucial for the next iteration of changes. One day, the CEO announced to the leadership new company goals – big words like Delivery, Excellence, Disruption,… and of course – Agile! After giving it some thought, I realized these big words were not goals actually – they were values. The CEO wanted the organization, and so its people, to behave a certain way, and this was laying the blueprint. That’s actually great! There was just one small problem – no one really understood what it all meant. Especially me – what was Agile again, please? (I’m sure you all know it means different things in different contexts, right?) Since I had already been, unsuccessfully, talking the CEO into doing some 1-1 coaching, this finally gave me a good leverage: let’s define what this all meant. The CEO reluctantly agreed, basically wanting to indulge me by showing me respect, I felt. The result was nothing less than ground-breaking.

I decided on a solution-focused approach: imagine one morning you walk into the office and, by some miracle, all the “goals” have been met; how would you know it happened; what would you notice; what others would notice; on a scale 1-10, where were we right now; why X and not 1; what else… what else… until nothing else could pop up. And, finally, what would X+1 look like. Oh, let’s not forget – what else… what else… what else. Yes! Thank you! No, no, that was me thinking to myself. The CEO still didn’t realize the importance of it, or at least didn’t admit openly more than that we had just clarified a couple of thingies. I realized that this time aligning just the leadership wouldn’t be enough, and led several rounds of alignment workshops, expanding the audience in each round, for all the “goals”.

Around the same time, the engineering leadership finally admitted the Spotify model wasn’t working. So, we agreed we needed a new organizational design that would enable us to tackle all the complexities we’d been experiencing – from dependencies due to architectural constraints, to expectations about performance, to products in varying stages of the lifecycle, to different KPIs, to what’s important and what’s ephemeral, to competing cultures, to company polar bears’ existence being threatened,… to customized ways of working. No, not Agile ways of working! Because, after those alignment sessions, I was correcting everyone who’d use this label that in this company we didn’t want to be Agile, but instead – visually transparent based on empirical data, with our flow optimized for predictability and efficiency, breaking siloes wherever we found them, and continually and iteratively improving. Of course we came up with simple and catchy metaphors for each of these, so people would easily remember them. And we used a lot of tools to enable all this, like data-driven dashboards, health checks, quarterly team OKRs, virtual feature teams, WIP limits, automized anonymous feedback gathering, regular roadmap checkpoints to examine priorities/dependencies/risks, etc. 

We ended up creating a delivery structure that would be present in all teams in the likes of middle managers, efficiently passing expectations down and feedback all the way up to Chief Delivery Officer, with small “centers of expertise” groups whose skills and coaching could be called upon by middle managers whenever needed. The whole organizational design was simplified into multiple value streams with an appropriate process for each of them. I’m especially proud of the new, custom process framework my team and I developed to address specific challenges some company ninjas had – who, btw, despised Scrum and threatened to leave if required to apply it (let alone understand it!), but were at the same time baffled to learn Kanban was not just a board with colored post-its. I later dubbed it NINJA Framework = Ninja Is Not Just (another) Agile Framework. It consisted of only 9 simple rules that ninjas had to obey, and what they did inside those constraints we didn’t care. Most notably, they had to have their own metrics of success, which they needed to review regularly; a plan of delivery for the next 24hrs; what needed to be done prior to commencing any work; to sub-task anything larger than 2 days of work; to define their DoRs and DoDs; to clearly limit their WIP; and to have clear actions on improving the process coupled with metrics to validate those improvements. After all, weren’t we supposed to fit our approach to the complexities of the circumstances we faced (as the notable Welshman put it)? Third iteration – done? 

Mission accomplished, I’d say! I must confess that I suspected it was not going to be my kind of cup of agility. Most of my team soon left. And soon I would leave too. In retrospect, I did make some assumptions that I should have validated sooner, but I’m proud of the accomplishment – my team and I helped this company equip itself with tools to create efficiently whatever it wanted, including the culture they needed to deliver it. Exactly what the company needed. And, it all stemmed from just one(!) solution-focused coaching session with the person in charge. Unbelievable, right? But I wouldn’t have made it without my team. We wouldn’t have made it, actually, had it not been for the culture we created together in our team.

My one regret? 

That I hadn’t convinced top leadership of the importance of coaching or made them realize that their own willingness to change was setting the upper limit on the organizational development. (Well, self-selection of teams, incorporated in the virtual feature team practice, would’ve been great too!)

About Aleksandar Basrak 1 Article
Aleksandar Basrak is an Agile and Professional coach with experience in all SDLC stages. This experience has brought home to him the issues engineers and their leaders face in modern software development, and he has used these insights to adjust his approach. He has led teams towards excellence by promoting openness in communication and transparency in decision-making. His background in experimental physics has taught him how to validate hypotheses through experiments and use empiricism to get meaningful insights. Supporting people to be more successful in their work and helping organizations meet their goals is what deeply motivates him. Besides enabling teams and leaders, he is passionate about chasing after his pets, good reads, and hiking.

Be the first to comment

Leave a Reply

Your email address will not be published.