Monday, 22 March 2021

Individuals and interactions over processes and tools

Of the four main claims in the agile manifesto, “individuals and interactions over processes and tools” is the one which is the most violated and missed. Particularly by people keen on implementing agile processes by the book. It's easy to start thinking immediately in terms of processes and workflows. It's a trap. It's just a habit. In most cases, managers create processes and workflows to compensate for a lack of trust among people in a team.

individuals and interactions
individuals and interactions matter more

When communication breaks down, each team member does their own thing. It's just "heads down". While this may increase the lines of code they produce, it's unlikely to produce more useful and working software. Regardless of whether I've worked alone or in a team, quite often discussing a feature before I begin work on it, I get insights which I wouldn't have gotten on my own. The additional perspectives are invaluable. This ranges from how it might look on the UI, to what the main purpose of a feature is, to how to implement the relevant data structure or algorithm. This type of exchange happens because of good team interactions.

Good vibrations

It's really peculiar and hard to measure, but the feeling of interactions is still important. This "soft" part of software development, especially how it impacts effectiveness, is probably the most important part.

“Yes, And” in improv - Luke collaborating on stage

In improv comedy, there is a concept of "Yes, And". When developing a scene, two improv actors enter the stage with absolutely nothing but their imagination. Once one of them starts, the other immediately responds to the "offer" of the first. That offer becomes "reality", for the purposes of the skit.

This happens on the language level too. When coming up with dialogue, improv actors, dare i say comedians, always try to accept what the previous person said. Saying "No" or "Yes, but" kills the dynamic of a scene. It decelerates. Rapidly. This is the essence of collaboration. If the environment is such, that everyone can build on everyone else's creative ideas, it accelerates the rate at which these ideas come about.

It's not only about the "communication saturation" which scrum co-creator Jeff Sutherland has mentioned in the past, where there is a larger number of connections among project participants. In particular, on the infamous Borland Quattro Pro project, they delivered 1 million lines of code in 18 months, with a team of a few people. There were many more discussions with project managers and testers than you would have on a typical project. Team leads dialed in individuals and interactions, thus achieving an incredible outcome.

The quality of individuals and interactions

Here the focus is on the quality of the interaction. At each step forward, you advance it. You are moving rapidly forward. You discover what you are making as you make it. It requires full attention. It requires being plugged into what your teammates are doing, as you want to run with any offer they make.

If you thinking giving a presentation in public is hard, try making one up on the spot, with a few coworkers. While this might seem a bit wacky, it's actually a highly refined set of skills practiced in the improv theater community. While the actors don't know what any particular scene will be about before they start, each actor submerges himself into what everyone else is doing. As a result, they find ideal ripostes to every offer. The scene’s conflict is discovered organically. Tension builds. It culminates. And then the troupe completes the scene. Pure creativity comes from being completely plugged in to the situation. And from listening closely to other team members.

This improv meme has been on the fringe of the agile community for a while. I suspect its because there is a strong desire for focusing on individuals and interactions over processes and tools. People never seem to stop amazing me, especially the amount of creativity which others find in themselves. In a team setting, the culture in which a team operates allows for this type of free-flow of creative ideas. This assumes that everyone feels safe enough to offer ideas as they are created. That's where this Agile principle of ‘individuals and interactions over processes and tools’ puts you.

Friday, 31 July 2020

Introducing the Align Remotely podcast

I’m excited to share that I’m finally launching a podcast, after a few almost successful attempts in the past.

The Align Remotely podcast will focus on leading distributed teams and everything associated with that topic, like leadership and operations to help achieve together, now that nearly everyone works from home.

In addition to the actual recording, the show notes will also include a visual representation of the discussion, a transcript, as well as any other resources mentioned during the discussion. This should help make the contents skimmable and also useful for anyone who prefers a more visual way to consume audio content.

The first episode was recorded with James Newson, who is a technical specialist around remote work. We cover any potential issues and possibilities around hybrid working, for when the coronavirus epidemic is over. And there is a lot more to it than I thought, because usually I was just leaning on company IT to “sort it out”, without having a proper think-through.

You can find out more at https://www.alignremotely.com and look for the podcast whereever you consume your podcasts. The first episode is over here: https://podcast.alignremotely.com/e/1rnkp6z8

Friday, 10 July 2020

Why the silo megaphone effect undercuts your ability to align

The biggest challenge I've had with building alignment as a team leader was the "silo megaphone effect". In the past, I've attended a number of surreal stakeholder meetings attended by:

  • head of product
  • head of delivery
  • a technical person
  • a head of QA
  • or possibly other managers.

Each participant makes statements that--on their own--made absolute sense. For example, the QA person argued for keeping a certain standard in terms of quality. The delivery person wanted to bring in the date as much as possible. The product person wanted to throw in as much scope as possible to make it easier to sell the product. I understood what they were saying. I could fully understand why they were saying what they were. They genuinely believed they were arguing for the overall benefit of the company, as a whole.

Nevertheless, if you juxtaposed what one manager was saying against the other, it was less than clear what the overall priority was. And this is exactly what I call the silo megaphone effect.

Each manager spent a lot of time with their respective team. So they had agreement amongst themselves as to the best course of action. But when meeting across department boundaries, the communication broke down. Nassim Taleb noted that firemen with much downtime who talk to each other for too long come to agree on many things that an outside, impartial observer would find ludicrous (they develop political ideas that are very similar). In particular, each manager running a department has a certain set of objectives and assumptions that are reinforced by discussions with people he's managing, resulting in rather surreal coordination efforts.

The silo megaphone effect refers to the tendency for managers to specifically argue what is best for their particular functional area. The inadvertent focus is on local maximization. This happens by default, despite everyone having the best of intentions.

I've fallen into the trap myself, of arguing for a short term benefit that will bring in the schedule at the expense of properly solving a problem at an organizational level. Sometimes the schedule pressure was just immense.

The main way that I dealt with this was to cross-reference statements from different stakeholders, and then ask for further clarification. The aim was to achieve what’s called “referential integrity” in a database. Where every data point is fully linked up to every other data point. Ultimately, in order to delegate effectively, we needed to agree what the ground rules were. This way we could communicate them to the teams, and hold ourselves accountable to them.

Read more in Align Remotely.

Thursday, 2 July 2020

Why addressing errors effectively lies at the heart of team performance

No one wakes up in the morning excited to go to work and look ignorant, incompetent, or disruptive. While it's not true of everyone, I think it's fair to say that anyone who gets a job wants to be there and usually wants to do well--for the purpose of self-respect. Look at how elated most people are when they accept a job after getting an offer. It's when they enter into the "systems" at a particular company, that everything usually takes a left turn.

Modern Times (1936) trailer: capturing the essence of managing

In established companies, it's sadly common for employees to be habituated in a context of fear of failure. Especially if there is a lot of pressure from management to perform at a high level. There are ambitious goals, often coupled with a lack of clarity on how they will be achieved. In practice, employees focus on looking busy (however that is defined). They end up fearing failure, of not living up to expectations.

As a manager, there is a fine line to draw here. You don't want to set the bar too low and cause everyone to just slack off. The starting point here is one of psychological safety; according to the research, this is one of the main factors driving high performance in teams. In particular, how you handle errors, failures, or surprises in a way that keeps the team accountable while enabling them to believe that they will be listened to--if they speak up.

Common error types

According to Amy Edmondson in The Fearless Organization, there are 3 different types of errors which happen professionally, and their meaning is largely driven by context:

  1. mechanical errors in a highly repeated process that just need to be minimized in frequency: this is what Modern Times parodied
  2. interaction errors which result from highly complicated relationships, especially in a larger company
  3. thwarted expectations around a goal in the context of experimentation, often a surprising result of an experiment

A large part of the challenge of large companies is that they treat all errors as if they were all #1 by default. This approach may be tied to political gamesmanship. But not everything is just a deviation from a standard (regardless of who actually decides and imposes that standard). Especially in knowledge work like software, where completing something requires you to learn something you don't know up front. Edmondson quips, “For knowledge work to flourish, the workplace must be one where people feel able to share their knowledge!”

I don’t know who dropped this in Leeds city centre but I feel their disappointment.
Photographer: Sarah Kilian | Source: Unsplash

In my software experience, most of the problems encountered, especially around people and process, were due to #2. Company systems were wrong, inadequate or just misaligned. Unfortunately, this typically meant that a person or department was singled out and blamed. I tried hard to bring the discussion back into a discussion around how the work was done, and if something could be done to prevent a similar problem from re-occurring.

The last type (#3) is essentially an opportunity to improve the company, the product, or the workflow, packaged as an intellectual surprise. Sometimes, the team would come across a much better way to solve or define a technical problem than they had originally wanted to do otherwise. This was particularly common in the early days of designing a large system. The same can be true on the business side, if the company is open to experimentation on that end. These are so valuable, that most innovation circles try to maximize the number of these errors through structured experimentation and record-keeping, in order to speed up overall progress.

Be open to taking ownership and admitting mistakes

From the perspective of psychological safety, it's critical to start with assuming any error is a #2. This includes assuming that the leader in the system is responsible for the system. More importantly, he is also part of the system. Which means that the manager needs to be open to letting their ego bruised, and be willing to admit mistakes in front of their fellow team members, in the service of improving life for everyone. Once I did this enough times with my team, they realized and eventually believed that I was genuinely interested in optimizing how the team worked.

Set of four brass vintage skeleton keys on neutral background. Very steampunk look!
Photographer: Jen Theodore | Source: Unsplash

Essentially the way to solve the misaligned expectations problem (bar too high vs too low) is to view the work as a system. And that way, you depersonalize the work enough, that fears become less of a driver for action. Instead, employees follow their genuine interest in improving their own work life. This allays fears of failure. And gets everyone more involved and excited.

Ultimately, you care about the output your team produces, so focus your management on that, rather than on policing individual effectiveness. Paradoxically it produces better results.

Key Takeaways

  • Psychological safety lies at the heart of high performing teams
  • Most commonly errors are assumed to be individual mistakes, rather than the result of complicated interactions gone wrong.
  • Get the team excited about improving the workflow

Wednesday, 15 April 2020

How to measure how much a #remote team is "gelling"

"No, you see, you have to monitor what people are doing. If you don't do that, people will just do a minimum of work," Alessja said.

I used to run this same team, and everything felt faster. They were talking to each other to figure out how to pass things along. And things just happened. True self management. And now the performance fell apart. It had devolved into everyone working on their own tasks again, as I was trying to coordinate a number of teams simultaneously.

"I don't feel comfortable with that", I countered. By increasing control and trying to force people to go faster, you'd likely get the opposite effect. I had in mind my previous experience at the Lego event. Moreover, there are other ways to keep discipline in a new product environment.

"I tend to agree", the senior executive on the call diplomatically concurred.

Was I just being naive? I'd already managed this team in the past. At this point, I was running a program that included it, just shipping something new. I couldn't figure out what's wrong.

Photographer: Markus Spiske | Source: Unsplash

Throughout the day, people would reach out to me if they needed something during the day. And it felt increasingly like a hub and spoke system. Not like the well-optimized flat hierarchy I was hoping for. With me as the hub of anything happening. And the bottleneck-in-chief.

Instead, everyone was being held accountable individually for their contribution. By team leads. Which I had agreed on, in order to lower my own overwhelm when dealing with so many people. But now I was having second thoughts.

What happened?

Later that day, I started thinking about metrics again. The team felt like it was going a lot slower than it used to. Strictly speaking, velocity was low. Much of the current work was just bug fixing. We didn't initially have enough of an infrastructure to ship new features with integration tests; even though now this infrastructure existed, a big gap existed between where manual testing happened and where automation was.

On a lark, I checked the cycle time. And it turned out we were up to a median of approximately 9 days per item, across the whole program. Including the team who had previously achieved 36 hours of median cycle time. Something was off--systemically.

What was different?

I realized that factor I overlooked here is the team dynamic. And we previously had a team dynamic that arose, when we were introducing habits to reduce cycle time. In particular, to minimize the handoff times between functions. Like make sure that code is reviewed quickly. Or that we don't take on too many issues into the sprint, parking the majority in "awaiting" states.

In effect, cycle time is correlated enough with how well a team interacts, that it can serve as a measure of the team dynamic. The quality of the interactions. Because there is just one goal for everyone, regardless of specialty and seniority, it becomes easier to work as a team. And handoff work among people effectively.

While in large organizations, cycle time highlight how work floats between silos, it seems to work at a team level also.

Key takeaways

  • In addition to measuring the raw time of taking a task from start to finish, cycle helps measure how well a team is functioning, if there are no major organizational constraints.
  • As it is accurate in "real-time", cycle time can be used to experiment and improve delivery team dynamics.

Monday, 30 March 2020

What is your biggest question about working remotely?

Just to pick up where I left off last week, my daughter and I managed to get back home. And currently we are under quarantine for 2 weeks. Fortunately, without symptoms so far. We're very lucky that so far nothing particularly bad has happened. And slowly the disease is starting to hit people we know or our friends' parents.

Today I wanted to ask about your shift to working remotely, especially if you haven't done much of that so far. I've run remote teams for a few years, so I'm hoping I may be able to help with any questions or concerns you might have.

On my end, I think the biggest new challenge is the childcare one--working in parallel with becoming a full time homeschooler. That means re=prioritizing. On the fly. Overall spending more time with kids is a good thing, but somewhat painful in the short term. For example, it's difficult to pretend business as usual, when a 5 year old pretending she's a mermaid in the background, flapping her plastic tail on the ground.

Just reply to this message with your question/questions or leave a question in the comments on the blog.

Thursday, 19 March 2020

Why Covid-19 numerical models overlook the reality families face

It all started innocently enough.

As I've been working remotely for a few years, I felt I hadn't been taking much advantage of it. So when my mom invited me to Cancun with my daughter who's in preschool, I figured "why not?" As long as my team had everything they needed and were clear on priorities, I could go. Moreover, I could just work from abroad. The only real difference was my time-zone availability. Beyond that, nothing changed for them.

For me, it just meant getting up for 6 am meetings. But being much closer to the equator helped rationalize this. Particularly since I already had a team member in Columbia, even closer to the equator with 6 am sunrise, 6 pm sunset.

While there were a few news reports about Corona virus in Wuhan province in China, there didn't seem to be much to be concerned about. My wife bought a box of face masks for our flight just in case. My daughter was excited about the face masks, at least initially. Kind of like Halloween.

You can probably guess where this is going.

At the airport, when we were walking around with our face masks, people gave us somewhat awkward looks. Although we weren't the only ones, we were one of a handful of people with masks. Both in Warsaw and later in Zurich.

When we got to Cancun, the world went #CovidCrazy. Suddenly, borders started closing, starting with the Polish one (for everyone except citizens) but we still had to get there in order to cross the border. We almost boarded our return flight but decided not to, as there would be two changeovers and a bus ride across the German-Polish border, with hours of backlog. Not ideal for travelling with a lot of luggage and a preschooler.

Then to get back to Poland, all of the connecting flights became impractical, because those countries shut down their borders. Even though we'd only be changing flights, we'd have to cross the border at the airport to pick up and drop off our luggage while changing airlines.

Finally, it looks like the Polish government looks like it may organize direct flights via the national carrier back to Warsaw. But still waiting on confirmation for this. Without it, we'll be in Mexico until the international lock down resolves itself. Or more accurately, in self-quarantine so that we can travel at a moment's notice.

We live in volatile times. It's funny how I recently penned a few posts about proactivity, while remaining flexible and not locking into a rigid plan, as the optimal strategy. Clearly this is a mindset which helps now.

Like a number of friends with split up families with dependents around the globe, both kids and seniors, the realities of the advice that comes out of mathematical models are a bit more complicated than it would have been for me as a single or even childless young couple. Kids can spread the disease but not have much symptoms. Grandparents face the risk of death due to lack of absolute numbers of ventilators. All that said, I am happy that I am quarantined among family and able to take care of them and myself. I'm hopeful that this situation will play itself out eventually.

There must eventually be some kind of way to restart flights using some type of nearly automated pre-certification of health/lack of Covid-19. The Chinese have some kind of device that measure body temperature from a few meters away. We just need to start thinking through what we can change in order to continue containing the virus, while giving people some ability to remain mobile.

Also, there have been a number of efforts among makers to come up with technical solutions to the expected shortfall of ventilator masks, like that of my friend Sal: http://diyventilators.com/. If you are interesting in helping out, join the chat at that site and say hi.