How work can be – Stories of agile & lean

Post Category
→Food for Thought

[This topic in German will be part of the upcoming 2nd sipgate book \o/].

We don’t have any middle management at sipgate. In our teams nobody is anybody else’s boss. Hearing this, visitors often assume we’re without leaders. In fact, the opposite is true.

(Disclaimer: We do have a hierarchy. It only has 2 levels but it’s there. Our not-so-called C-level sets strategy and everyone else is trying to execute it.)

The roles of Scrum Master and Product Owner have elements of leadership in them. Product Owners have authority about what is being build. They do not have authority about people, their jobs, how the team builds something or the broader organizational setup.

Because nobody gets to lead solely by the power vested in them by some management title, everybody takes the lead sometime. If something is important to you and you don’t take the lead, there’s a chance nobody will. Fortunately, the issue that’s important enough to take action is a different one for different people. So it distributes nicely.

Some people will now object that there is always an informal hierarchy in a team anyway. And someone at the top. After pondering this for months and qualitative surveys at the coffee machine I can’t confirm this. Who’s on top is ever-shifting. Within any given team there are several people that lead, depending on the area in question. UX? Dan. Java? Lara. JavaScript? Kim. We follow their lead because we trust them to best judge the long term consequences of any decision. And yet, they usually don’t decide on their own, but together with others.

I’m pretty sure that half my colleagues would be team leads in other companies. They’ve got all the skills you’re looking for: take responsibility, present results in front of 100+ people, give constructive feedback, facilitate discussions and they’re reflected.

Btw, this post isn’t called “Agile Leadership” for a reason. In my experience, when managers talk about “Agile Leadership”, they babble about “empowerment” while keeping the existing hierarchy and its reporting structure as it is. Yeah, right. Wash me but don’t make me wet, much?

And what do we get from having a flat hierarchy? Everybody takes responsibility. We can take decisions fast. We don’t waste time on political games. Instead we can add value.

Scrum doesn’t fix an organization’s problems. It makes problems glaringly obvious so that you they have a chance to fix them themselves. Except that “glaringly obvious” is relative and sometimes you still need someone to point to the steaming pile o’ shit of a problem and say it out loud. Sometimes to someone that has the authority to fire the messenger.

As a Scrum Master or agile coach it is part of your job to speak truth to power if necessary. And while it’s certainly a good idea to work on delivery, and phrasing hard truths in a way that make it possible for the recipient to accept and stomach them, there’s still a risk involved.

That’s why you need to have a certain level of independence. And a big part of that independence is money. How can you expose someone to an uncomfortable truth, if that person can fire you from a job you depend on? Depend on for rent, for food, for insurance. For your kid.

It’s a whole lot easier to “have guts” if you have an emergency fund, e.g. 3 to 6 months of living expanses in cash in a bank account. How many months you need depends on how fast you think you can land another job. Ultimately it depends on what you need to feel secure. My need for financial security is high, so we’ve got 12 months. This is just living expenses, not fancy vacations. Not that it’s necessary at my workplace but it’s still a very comforting feeling and helps me not be afraid to say what I think needs saying.

If you don’t have an emergency fund, why not start now? If you can’t save big chunks, chip away at it. Small contributions will also help. Having some money in the bank will make you more effective in you job. And it’ll let you sleep better at night.

The other day, I’ve had 3 visitors from a large corporation. Since one of them was from HR we talked a lot about these topics and exchanged our hiring processes. One hidden criterium of theirs is that people must be “leidensfähig” to a certain extent.

“Leidensfähig” is a beautiful German word that literally translates to “ able to suffer”. If you’re leidensfähig, you are able to put up with a certain amount of (corporate) bullshit without quitting. We cast for the exact opposite. If something sucks, it’s your responsibility to go fix it.

It reminded me of how much hiring criteria differ between companies and that it’s really no wonder that turnover is to be expected during any big change. You’ve hired people to work in a certain way and – boom – now you ask them to work in a different way. Not all employees can and want to work in a new way. It’s not their fault either. It’s just people and companies going their separate ways. It’s not them, it’s not the company. They are just not a good match for each other anymore .

At the end of 2011 I wrote about what makes an agile mindset (in my opinion) and even made a fancy infographic about it:

It concentrates on how people think about their colleagues as humans vs. cogs; whether they have a growth vs. a fixed mindset; iterative product development vs. extensive planning and more. These are all still valid, but I can add another set of examples today.

The past few weeks I have often thought about how conversations changed at sipgate over the course of the years and why it is much easier and more fun to get things done than in the beginning. So here’s a list of behaviours and how they changed:

“It can’t be done!” -> “We have to take X into account”

In the beginning, many a discussion about potential features revolved around a central theme of what we can’t do. There seemed to be an awful lot of things we couldn’t do, despite the fact that we were working with software. If we created it in the first place, we can also change it. Made me so angry, I ranted about it here.

These conversations have been replaced by “If we want to do that we have to take care of X and Y. Oh, and Z will be tricky, too. From the top of my head we look at a two month effort. Is this feature worth two months to us?” A much more productive conversation!

“Clearly A is better!” “No, B!” -> “Can we just try it?”

We used to discuss options endlessly. Fruitless hypothesizing. Nowadays one of us will rather soon ask something along the lines of: “Can we try it out? (What would it cost to just try? Can we decide this or who else would need to take this decision with us? How easy is it to roll this back if it doesn’t work out? Who might we confuse with this?)”

And the number of theories you can easily put into practice to see what happens is surprisingly high. I’d estimate about 90% of the time we realize that, yep, we could just try it out without repercussions.

? -> “Where’s the value to customers?”

Here I’m not sure what was the focus before. I suspect there wasn’t any focus. But nowadays if you want anything done you’re better prepared to explain how it is of value to a customer. Otherwise, fat chance!

As my colleague Mathias so beautifully put it about how we build websites: “At first we designed desktop first, then mobile first, then content first and finally: Purpose first.” What is it that we want the customer to achieve on a given page? This approach makes decisions and trade-offs clearer and points you into the direction you need to take.

Summary: Appreciative and constructive

In general the whole company’s vibe has become much more appreciative and constructive. There are hardly any cynics left. Instead we’re pointing out what’s already going well and look for solutions where it’s not. Most days, anyway. Nobody’s perfect 😉
It is a highly satisfying way to work!

I’ve got a confession to make: I think fun in retrospectives is overrated. And I never bring cookies, when I facilitate.

Don’t get me wrong, I prefer having a good time to moping about and yes, I prefer participants to be in a good mood. Light hearted people are more creative and willing to try new things.

But all my most important retrospectives – the ones I still remember years later – were horrible! Or at the very least deeply uncomfortable. That holds true regardless of whether I facilitated or was a regular participant.

The important retrospectives, the ones that really counted and made a profound difference were about troubling topics: When something or someone wasn’t working out despite everyones best efforts. They had a big impact like teams dissolving; people leaving teams or even the company. That category of events.

Something like that is decidedly not fun. But it’s necessary to have these conversations. I’m grateful to people who have the guts to bring up the crucial topics even if it hurts in that moment. After the dust has settled everyone is better off, because a harmful situation has turned into a new beginning. And work in general, not just that the retrospective, has a chance to be fun again.

When I first learned about Kanban, I also learned about “Swarming”. Swarming is when the whole team pitches in to work on the same thing. That same thing is often a blocking task that WIP limits helped surface. Can’t work on “your” tasks because you reached the WIP limit? Go help clear that blocking task up ahead!

Swarming with a team is not unusual and works pretty well. Some teams try to always work on only one story together so they’re swarming non-stop. And you can turn up the magic and swarm with large parts of the company.

Let me give you three examples of what you can achieve if you join forces and people do tasks outside of their normal job description.

1) Patch all the code

Some years ago we had a legacy product that was in use and earning money while not being actively maintained. Suddenly a wild security hole was revealed. It was a problem for everyone using that version of the specific language we were using. (Yes, you’re right, it was PHP.)

Not fixing the bug would have been irresponsible. How could we make it secure again, given that no team was taking care of the product and nobody really knew the code base anymore?

Drag 3 developers from their teams and go at it for a month? Takes long and these people are missing in their respective teams. And you make these 3 people rather unhappy. No, let’s stop and fix. Let’s take 2 days with all developers, spread the burden evenly and get it over with.

Fortunately the bug was least easy to search for. Two developers prepared a big board with a slip of paper for each and every instance of the bug in the legacy code base.

On Monday morning all developers met and paired up – one person with faint memories of the code base and a newer hire. Each pair took a slip and went on their merry way. All developers together finished that task within 2 days and with a high sense of community.

2) sipgate calling

After handling outstanding payments pretty badly for years, we decided to wow our customers in a commonly negative situation. Instead of passing late payers to a debt collection company we switched to writing friendly “Hey, maybe you forgot to pay us?” emails.

As part of switching from old to new way of handling we wanted to personally call about 200 customers with overdue payments. 200 is a lot of calls for the 3-person team that was wowifying our reminder process. 67 calls per person is daunting.

That’s why they asked the whole company to volunteer. They asked for people willing to help call customers at a certain time and date. They kicked it off with a short training and then some 20 people were calling up customers, nicely asking to update payment details. 10 calls per person is a lot more doable than 67.

3) Got a minute? Answer a ticket

In times of needs you can ask for quick help on Yammer. Sometimes customer support tickets pile up. That can be due to an incident or unusually few people to tackle tickets or both. In these cases you can rally the troops:

“Due to $reasons we have 4 times as many tickets as we normally do. We’re a bit overwhelmed. If you’ve got a spare minute and a Zendesk account, please check if you can resolve any of the tickets in our queue -> link”

At least once, yours truly did have time, read about 30 tickets, decided she could help with about 10 of them. Of these 10 only one popped back open because my answer didn’t help with everything. Which means I closed 9 tickets as a non-customer-support-person. Sweet!

Did I take longer than a proper CS person would have?
Definitely.

Isn’t it wasteful then?No! Not to me anyway. Sharing your colleagues’ burden in that way strengthens relationships.

Okay not wasteful then, but it’s still inefficient for people to pitch in with tasks they don’t have routine in …Probably. But then again, I don’t care about being efficient. I care about being effective. And that’s what swarming is. It cuts a big, intimidating mountain for a few people into realistic hills for many people.

And yes, that last example only worked because a lot more people have Zendesk accounts than just customer support people. These licenses are pricey. It’s a trade-off. We opted for the ability to act effectively rather than (money-) efficiency.

Out of 75ish people only 3 raised their hands. That’s not a lot of people. All three handraisers were fellow speakers and agile practioners.

I was one of them. Interestingly, I had hesitated to raise my hand. Have I been on teams who finished early? Sure thing!

Yet, right before asking, Allan had dissected common definitions of “projects” and “project success”. One of the success criteria is “on scope”.

Now when you look at “my” early delivered projects, they were not on scope. We were able to call it a day early, because we had cut scope. While building it we identified parts that didn’t add value and decided not to build these.

For a moment there, I was debating with myself whether that’s “cheating”. It could easily be judged that way from a traditional point of view. I mean, isn’t it easy to deliver early if you skip bits? Anyone can do that, can’t they?

I did raise my hand in the end because it’s not cheating to me. Quite the opposite, “responding to change” is at the core of agile. Finding out more while you do the project and adapting to it: If you find out you don’t need even half of the stuff you thought was important you get to finish early. Yay!

And it ain’t easy either. Simple, but not easy, for two reasons: 1) Finding out what can be left out is tricky. 2) Letting go of planned scope is psychologically difficult.

Recently I’ve been presenting our Work Hacks at a couple of places and talking about pairing up as part of it. Not only do we pair program but we also mob program and pair up across roles: Dev and UX designer, PO and customer support, UX and PO, dev and customer support, dev and … You get the idea. We’ve done just about every combination our very cross-functional teams allow for.

Whenever I talk about this, a common follow up question is: “How did you introduce pair programming?” or “How did you make people adopt pair programming?”

Short answer:
We didn’t. Nobody made a concerted effort to establish pair programming at sipgate.

Long answer:
Not long after we started using Scrum it dawned on us that Scrum alone wouldn’t save us. Only combined with sound software engineering practices such as the ones from XP would we be able to improve our codebase.

Sometimes I hear tales by developers from other companies about management not wanting them to pair program or TDD. In our case the opposite was true. Our management was okay with TDD and pair programming. There just weren’t many people interested in doing it.

Fortunately “not many” is more than “nobody”. There were some curious minds and teams who started to try it out.

It worked well for them so they kept doing it and told others about it. And what do you know, just a few short years later (about three or so) the tables had turned and pairing up was the new normal. Now you were the oddball when you didn’t want to pair up.

To this day it depends a lot on the team. Some teams pair up all the time, some mob, some only pair up for critical stuff. All of that is okay.

We all agree that pairing programming leads to fewer defects and better readability. And pairing up across disciplines helps us keep tight feedback loops and to spread knowledge.

Maybe it’s because usability was such a strong focus of mine for such a long time but I feel like most good ideas boil down to usability. It’s kind of my “grand unifying theory of good practices”. To me, Agile Software Development is about providing good usability to the customer (not necessarily the user). Clean Code is about good usability for other developers. They’re both about going the extra mile to make someone else’s life easier.

Not convinced? Well, I hope it’s easy to see how Clean Code will make code more usable for its future maintainers. That’s why I’ll concentrate on making the case that agile software development is for product development what usability is for product. Continue reading →