What is an Agile Mindset? Six years later

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!

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

My most important retrospectives were horrible

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.

All my most important retrospectives were horrible

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.

PS: Interested in retrospectives? Sign up to the Retromat newsletter to get related news and tricks!

Examples for Swarming beyond the team

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.

Swarming cuts a big, intimidating mountain for a few people into realistic hills for many people.

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.

To say it with the words of my former choir leader:

Viele Hände, schnelles Ende
Many hands, fast end

Smart chap, that choir leader 🙂

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

How to deliver a project early

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

How did you introduce pair programming at sipgate?

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.

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

We have it backwards

We don’t go out and do difficult things because we’re confident. We do difficult things and that gives us confidence.

We don’t work longer hours and get more done. We work less, sleep enough and get more done.

We don’t have more defects in production when we deliver often. We have fewer defects when we deliver more often.

Immigrants don’t take away jobs. Immigrants create more jobs than they take.

Makes me wonder what else we’ve got backwards…

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

 

Agile is about usability. So is Clean Code.

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.

Agile Software Development is about providing good usability to the customer

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

Improve your Retrospectives with this 1 weird trick: Liftoffs

When health is concerned, preventing issues altogether is often easier than treating them once they’ve manifested. The same can be said for retrospectives:

In retrospectives we often make up for the fact that we didn't have a liftoff

Either Deborah Hartmann Preuss or Steve Holyer said that in a conversation and it rang true. Very few teams get a proper liftoff and they lose weeks and months of productivity to initial friction. In contrast, a proper liftoff sets up a team for success by laying a solid foundation of agreements and shared understandings. Then the team doesn’t have to spend their retrospectives patching up problems that could have been avoided.

What are liftoffs exactly?

You might know them as kickoffs, jump starts, launches or project starts – a meeting at the beginning of a team coming together and / or starting to work on something. I’m going with the name “liftoff” because of the book by the same name written by Diana Larsen and Ainsley Nies. Continue reading

Story Cubes for Retrospectives

Sometimes we have guests over who want to learn more about our Open Friday and see it in action. Lately we’ve been asking for a session in return so that visitors add to our pool of knowledge. These guest sessions are often interesting and sometimes you strike gold: Cynthia Hohlstein and Kevin Plechinger hosted an inspiring session on and with Story Cubes. Because neither of them blogs, I get to share their idea with you: Story Cubes are sets of 9 dice with images on them. The images cover a wide range of motives, such as a speech bubble, a sheep, a star, a hand or a walking stick figure. The idea is that you roll 3 dice and then tell a story that contains the 3 motives you rolled.

3 Story CubesThis can easily be turned into a fun activity for agile retrospectives if players answer a question instead of just telling a story. Cynthia and Kevin already had a couple of ideas:

  • What was last sprint like?
  • How do customers view our product?
  • What’s the state of agility here in our company?
  • What was your carreer path? How did you get here?

We spend the hour-long session answering questions in groups of three. It was very interesting because the cubes prompt you to talk about aspects you wouldn’t normally have touched on – you tell the truth and still have to incorporate the 3 images. Among others, we used the “Customer View” question and it was quite revealing. Story Cubes help with changing perspective and add a fun element.

Thank you Cynthia and Kevin for introducing us to story cubes!

PS: Interested in retrospectives? Sign up to the Retromat newsletter to get related news and tricks!

 

5 more things I learned at Agile on the Beach 2016

From Kat Matfield’s session “User Research in an irrational world”:
1) If at all possible, look at records of what people actually did in the real-world situation, (screen recordings, chat logs, …) instead of putting them into a research situation (in which they will always pay more attention) or asking them to remember (memory is extremely unreliable).

From Gez Smith’s session “Agile Marketing”:
2) Maybe 1 thing goes viral per year. Rest is planted and pushed with fake accounts

From Darci Dutcher’s session “Running killer workshops without killing yourself”:
3) If you use dot-voting and don’t limit the number of votes you get information about the long tail of interests. Not relevant in short retros but maybe for a longer workshop.

4) A retro is a sub-kind of workshop. I never thought of retrospectives in those terms. Nice realization.

From my own session:
5) Putting your cell phone near a mic is a really bad idea (audio feedback)

I also learned about Jeff Patton’s Cups, the sticky note bonus shape and that I’ll try to remind more speakers to repeat the audiences question before answering it.

All in all, a very nice (knowledge) haul 🙂