How work can be – Stories of agile & lean

Post Category
→Change

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 .

Why would this rub me the wrong way? That nobody is pair programming? After all, I am indeed a huge fan of pairing up. I witness this practice’s many benefits every single day at work. But no, that’s not the point. My alarms went off because “lack of pair programming” was presented as an actual problem. It’s not.

Let me repeat that: As much as I love pair programming, not doing it is not a problem in and of itself. Rather, pair programming is a possible solution to a host of problems an organization might be having such as:

And depending on the actual underlying problem there are different solutions available, one of which could be pair programming.

Nobody who’s not already a convert will start pair programming just “because”. Instead go looking for the actual problem. Ask “So what?” That phrase is magical and you can use it repeatedly. Just like there’s the Five Whys, dig deeper with five “So what’s”:

“Our problem is that nobody’s pair programming!”
“So what? Why is that a problem?”
“Nobody knows anybody else’s code. It’s 1 system = 1 developer.”
“So what?”
“Whenever a developer is sick or on holiday development in their area comes to a screeching halt. And there’s always someone sick or on holiday. Makes us super slow to release. And I dread the day someone quits.”
“Well, that does seem like a pickle…”

Okay, it weren’t five “So what’s” because I suck at making up examples but you get the point.

This is not specific to agile practices either, though Agile folks have a reputation for dogmatism. Here’s a recent example from the field of web analytics: “We’ve got a huge problem: We can’t do cross-domain tracking.” Soooo …? What are the questions I want answers to and that we can’t answer because we lack this?

I’ve learned “So what?” in the context of Henrik Kniberg’s Cause-Effect-Diagrams and have since used it whenever I suspect that a “problem” someone presents is actually their (preferred) solution. It’s the same as with product features:

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!

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.

Let’s start with one of the solution-focused tenets: “Everybody is the expert for their own situation”. Based on our experiences we all see the world differently and can never truly know anyone else’s impressions. We each live on our own island and usually don’t know much about the islands of other people.

Let’s say there are 2 people on their respective islands, Zilli and Kurti. Zilli’s island sports a glorious coconut tree and Zilli looooves coconut. The meat, the milk, the pina colada – she loves all of it!

Kurti’s island on the other hand has fir trees growing. Kurti has never heard of coconuts in his whole life, let alone seen one. What a sad state of affairs! Zilli wants to share the coconut goodness and saves one of her precious coconuts to throw over to Kurti. What do you think how Kurti will react? Grateful?

Unlikely. Zilli just attacked him with a big stone. Unprovoked! Why would she do that? Kurti has no choice. He has to defend himself!

Which in turn will anger Zilli. Kurti lets her gift go to waste! That was an excellent coconut! Pfft, she’s never going to share anything with such an ungrateful person!

Not a good exchange at all. Yet, it often plays out like this when someone tries to introduce change. But Zilli could have done better. She could have asked, whether Kurti is interested in trying coconuts. And if he’s not, accept that. And if he is, all the better! She could have shown him how the crack one. The meat, the milk, the pina colada. Chances are that Kurti would have liked some of it.

I plan on using this metaphor a lot in the future. I want to pass on what I learn. I hail from a long line of teachers, I can’t help myself. Heck, this blog is nothing but a big pile of coconuts, so that I have an outlet. You’re here on your own free will, so I hope that’s okay with you. And if we meet face to face and I ask “Would you like a coconut?” you know that I’ve got excellent, excellent ( 😉 ) advice that you didn’t exactly ask for. You can say no. That’s okay. It’s why I ask first 🙂

After about 2 or 3 years into my agile journey there was a time when I would listen to a talk or read a book and be like “Yeah, it’s exactly like that! I wish someone had told me 3 years ago! It would have helped me a lot! Why didn’t anyone tell me that?”

The specific information provoking that thought was typically something about people, how they behave and communicate, and how change unfolds in an organization.

After even more time I now have the sneaky suspicion that “they” did tell me that. But I wasn’t ready. The factual information didn’t stick, because it was beyond my horizon. I wonder if there are some things you have to experience yourself, mistakes you have to make and only in hindsight you can appreciate the wisdom of others.

Not sure if that is disheartening (I’d rather learn from others than make mistakes myself) or liberating (we are allowed to fail). All I know is that I’m a lot more patient than I used to be. I can now let others make mistakes they need to make in order to learn. And I try to not push advice on others, when they haven’t asked for it. It’s something, I guess 😉

In many ways I’m paid for having conversations: As Jerry Weinberg said, every problem is a people problem – I try to solve these people problems by having conversations or making other people have conversations with each other.

But sometimes that’s not enough. It hit me, that my more successful interactions in crucial situations have not just been about exchanging perspectives. I’ve had data with me. Consequences of behavior expressed as numbers and charts, or even as a price.

When you’re leaning towards the “touchy-feely” end of things, it’s easy to forget how data can make the case for you.

For instance, if a Product Owner receives too many feature requests to implement all of them and is not empowered to reject them, the requests will pile up. If that pile is hidden in a ticket tracker, the problem is invisible. The requesters will just wonder and / or bitch why the developers don’t fulfill their requests, whereas the developers will groan under an impossible workload.

If the PO tracks the requests on a board the problem will at least be visible, when the board overflows. The PO can point to it and make their case. Will this change anyone’s behavior?

What if the PO tracks the incoming vs. the finished tickets to demonstrate how much demand and capacity are out of sync: The yellow line represents the accumulating unsatisfied requests. This is a chart to base a discussion on. Much better than “it’s just too many”. The PO and the stakeholders now see that there’s about 3 too many requests per week and that there’s no way for the developers to ever catch up with the pile. Time to take some decisions.

Data is powerful! Especially if the information not hidden in a sea of numbers. If you want to convince people take the time to coax out the information. Make a fancy chart! You know you want to 😉

Sometimes it’s enough to bring a few numbers to put things into perspective: That you’re not complaining unreasonably. It can help counter the opinions (read “not backed by data”) of people higher up in the food chain.

Whenever I encounter a significant problem I think about how to make it accessible, visible or even palpable* for others who I want to help me solve it.

* There once was a team that inflated a balloon for every ticket they got. Within a week they were up to their knees in balloons, communicating to every one that they got way too many requests. Can’t find the original source 🙁

When I give my talk “Thank God it’s Open Friday!” people always tell me how much they liked hearing about our failures on the way to a solution that works well for us.

It’s surprising to me, because our previous trials with a slack day are only loosely related to the very successful end result. It’s the part of the talk for which I always doubt whether it’s interesting to anyone. That part only exists, because I created the talk for Agile 2015 in the “Experience Report” track. If I had created a “normal” talk I would have only presented our shiny solution. Much like other people tend to present their shiny solution and rarely the way they took to get there.

That’s how we end up showing each other our pretty sides, once we have figured it all out and we hide the hard work and multiple failures it took to get there.

That can be quite intimidating for people who just start working in a better / different way. Like everyone else just flipped a switch and they are the only one’s struggling.

Well, you’re not. sipgate is a fantastic place to work. It has been for about 2 or 3 years. But we started down the agile road in 2010. Now 2016 is nearly upon us. That leaves 3 years that were less than stellar. Some times during these 3 years downright sucked. And I want to tell you of the suckage and the working solutions that we surfaced with. Heck, I might even tell you of the things we still haven’t figured out. It’s not like we don’t have problems anymore…

There is an interesting passage in “Joy, Inc.” about change saying that when you take away one reward system you have to replace it with a different reward system – one that encourages the behaviours you’d like to see – as soon as possible.

As long as the old reward system lives, people will fall back into their established patterns. And rewards don’t only mean bonusses. It also means bonusses, but non-monetary rewards are more important, such as being needed, being the hero, etc. You need to replace these rewards – e.g. with the ability to go on an uninterrupted vacation and without huge stacks of work waiting when you come back.

In that vein, Rich told a great story: A research company wanted to work more in teams. Everybody was on board, good people, they implemented new collaborative processes and still… People didn’t “really” work together. And they couldn’t put their finger on why that was. Rich was stumped too.

Until he finally thought to ask: “What do you celebrate around here?” And they showed him their wall of plaques for patents granted. Each plaque with 1 name on it. They celebrated individual achievement, not group achievement and it hobbled their intention to collaborate. It worked out for them after they had torn down the wall.