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!
At TopConf Linz 2017, Allan Kelly posed a question to the audience: “Have you ever delivered a project early?”
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.
Once more I come to the conclusion that the trick is not to work superfast but to selectively do less.