Info

Stories Connecting Dots with Markus Andrezak

Stories Connecting Dots by Markus Andrezak tries to discover the many different ways businesses navigate in an environment of change. Stories Connecting Dots versucht die unterschiedlichsten Wege zu entdecken, auf denen Unternehmen erfolgreich mit drastischem Wandel umgehen..
RSS Feed Subscribe in Apple Podcasts
Stories Connecting Dots with Markus Andrezak
2019
March
January


2018
December
October
May
March
January


2017
December
October
July
June
May
April
March
February
January


2016
December


Categories

All Episodes
Archives
Categories
Now displaying: Category: business
Dec 13, 2018

Jabe Bloom and Marc Burgauer - Designing Systems

Last week, beginning of December 2018, I happened to be guest of the DevOps Conference in Munich. The nice people from the organising company gave me the chance to actually make it a family meeting with my pals J Paul Reed (a giant in the field of DevOps), Marc Burgauer (from Scotland, doing Agile consulting in Banking) and Jabe Bloom (co-founder and chief scientist of Praxisflow).

It was 3 really busy days, the bunch of us were continuously mingling in giving talks, workshops, being active in a panel and all kinds of fun. Finally on the last day, we all gave a huge workshop together, using all kinds of techniques and tools from all of our fields and it felt like really great collaboration - throwing together all our expertise from all the fields we've been busy in and merging the approaches. Collaboration without vanity and really sharing. It rarely feels this good!!!

On the evening before the workshop, Marc, Jabe and me sat down in my hotel room and recorded roughly two hours of ramblings on designing systems. When Jabe is with you, it's always on the highest level and really abstract design theory. But Jabe has this tough in which he can really go sky high, risking to be Icarus. But just before his abstract knowledge makes gets him too close to the sun, he defends to us other mortal souls and he connects back to earth and leaves us all with a "ahhhh, I see what you mean!!!" The background is that Jabe is currently working on his PhD in Design at the Carnegie Mellon University and as such he is a monster in reading about all of the most abstract literature in design theory - specialising in change in human systems in extreme time spans (like hundreds of years). Of course, there are huge connections between these theories and what we are doing. 

Having Marc in this round is a totally different perspective yet and I love how the three of us managed to blast through all kinds of topics. Honestly, this one is one for the lodert and possibly for a niche. But I guess the niche will love it.

I'll make it short this time and leave it with the character of the recording: Raw, uncut and a little meandering but always true to the topic and lots of lots of depth. I love this and it feels authentic to how my life and job is.

Thanks guys in being my guests and inspiration in this episode.

This is part 1 of 2 parts. The next part will make up the next episode and will follow in a week or so. This just had to be out there.

Some notes and hints

How different timeframes and different temporality change our thinking and how we have to take care about this. We mention Bungay, User Stories, Epics, Strategy …

The focus of Agile is compression of timeframes. It can be a problem once we loose the language for longer timeframes.

„Employee goes „I can’t think of a way to come up with a chain of two week events that would add up to your one year story. I can’t do it. It doesn’t make any sense.“

The role of middle management in story telling and expertise.

A Peter Principle of temporality, explaining micro management.

OKRs and stories

Humanist culture is about "What am I doing?“ not „How do I measure what I am doing?“ but "What am I doing?“‚

Determinism vs. "The Quality within", love vs. Process

The more efficient you get, the more exploration you can do.

Science doe not have time as a component. The scientific method is always in retrospective. It always thinks about the past and it never thinks about the future. The predictions it does on the future are based on a determined future. There is no **Open** in science.

The thing about the Jony Yveish people out there is that they are able to imagine things that don't exist and can't be measured. You can't use determinism to get there. You can't use quantification to get there. You can only use story telling and narrative.

How can Roger Martin's Knowledge funnel be used in a way that it brings mystery? It needs to be used non-linearly. You throw a thing in the middle, it pops up to the top and a mystery is born. That'd be a different way to innovate rather than simply finding "valuable problems" to solve.

Doing Hackathons more right and more wrong.

Apollo 13 mission story: Time constraints, a known set of components and *isolation* (so the team has to be put away from everybody)

"If we had this, then we could make that!"

Three temporalities to making sense:
- How do I make sense of what's going on?
- Retrospective coherence:How can I later explain why I did this in the future. (constraining)
- Prospective coherence. If I put this thing that doesn't exist into the world, how does it change the stories that I'm in?


Books

I guess this is really abstract stuff. I just love it and I assure that if you are a regular listener, there is a lot in it for you!

 

 

 

Jan 26, 2018

Fridtjof „Fridel“ Detzner hat die letzten 18 Jahre mit seinen Freunden daran gearbeitet von einem Bauernhof aus die Voraussetzungen für Jimdo zu schaffen und dann Jimdo mit aufgebaut. Dort hilft er auch noch ein bisschen mit, er sucht aber nach neuen Feldern.

Fridtjof „Fridel“ Detzner hat die letzten 18 Jahre mit seinen Freunden daran gearbeitet von einem Bauernhof aus die Voraussetzungen für Jimdo zu schaffen und dann Jimdo mitkönnen aufgebaut. Dort hilft er auch noch ein bisschen mit, er sucht aber nach neuen Feldern.

Darum hat Fridel ein Jahr hinter sich, dass anders war als anderen vorher. Er ist mit einem Fernsehteam durch die Welt gereist um für die Serie Founders Valley zu drehen. Sie wird weltweit ausgestrahlt und Du kannst sie auch auf youtube anschauen. Dafür ist das Team monatelang durch die Welt gefahren. In anderen Kulturen und Kontexten wurde geschaut,

  • was „Gründen“ dort bedeutet
  • was Gründer dort antreibt
  • welche Probleme Gründer und die Gesellschaft dort haben
  • ob esMuster von Gemeinsamkeiten mit Startups bei uns gibt

Und wenn einer eine Reise tut, dann kann er was erzählen. Und hier erzählt Fridel uns über die Erfahrungen in den anderen Ländern, und was diese Erfahrungen mit ihm machen und zu welchen Erkenntnissen und Konsequenzen sie ihnen treiben. Wir hören von Gründergeschichten im Kontext von Mangel und instabilen Gesellschaften und extremem Kontrast von Armut und Reichtum. Er erzählt von Sein und Schein und vom Kontrast zwischen Erwartung und echter Erfahrung. Wir hören von Glück und Unglück und ihrer Nähe zueinander und von ihren Geschwistern Erfüllung und Trott.

Wir stellen fest, dass einiges was spießig scheint für uns überraschend Sinn machen kann, genauso wie Dinge, die zu „corporate“ erscheinen. Aber auch darüber, dass vieles nur im Machen (und dann im Reflektieren) gelernt werden kann. So wie Fridel es meistens macht.

Diese Episode hat mir besonders Spaß gemacht: Fridel und ich kennen uns seit langem und wir haben einiges zusammen gemacht. Wir teilen aber auch viele Interessen und Einstellungen im „Beruf“ und im Rest des Lebens miteinander. Vielleicht hört man es.

Viel Spaß bei dieser sehr persönlichen Folge von Stories Connecting Dots.

Wenn es Dir gefällt, empfiehl die Folge und den Podcast bitte weiter und schicke mir Feedback und Ideen. Gern aber auch, wenn etwas für sich nicht stimmt! Hilf mir und schicke ein Review mit 5 Sternen an iTunes!

Bis in ein paar Wochen mit Folge 16!

Links

- Founders Valley bei der Deutschen Welle
- Founders Valley bei youtube
- Simon Sinek’s Ted Talk „How Great Leaders Inspire Action“, den Fridel mehrfach anspricht.
- Das Buch „Start with Why!“ dazu von Simon Sinek

Apr 16, 2017

Episode 7 - Jeff Patton - User Story Maps and the discovery of great products

Another one of the greats. I follow his work since years, I integrate lots of what he does in my work. Everyone knowing me or having had a training with me, knows what he does with Story Maps. But having come up with Story Maps and having written the first book around is „this little thing“ to Jeff Patton.

Jeff is really deep into product work and he has lots of thoughts to offer on Agile and especially on everything around stories and story thinking. And one of the reasons he knows all about that is because he was already there when it happened. He was in the same building with Kent Beck when Extreme Programming happened and Stories came up. He was coached by Rob Mee of Pivotal Tracker fame.

So, this is not just a deep dive on stories and the Story Mapping technique that emerged form it but also some oral history on how and where it all started to happen.

Nowadays, Jeff more and more dives into the discovery phase and at the end of the podcast we will hear lots about this and where this might clash with Agile or how it is taught in most cases.

But what is so relaxing is that we really don’t talk much process. And I think the reason is that product is much less process than it is orthogonal to process and it is about thinking of quality, what quality means to whom, for whom we’re building things and having empathy for them.

Speaking of empathy: Enjoy a nice conversation with a humble, humorous and relaxed Jeff Patton!

Chapters

  1. 0:02:04 (User) Stories - the base of all
  2. 0:13:19 Documents are like vacation stories
  3. 0:31:43 Story Maps - what it is, how i emerged
  4. 0:43:10 How to teach Story Maps
  5. 0:55:34 Struggling with the backlog as a prioritised list
  6. 0:57:54 Products we like: A BMW 335 convertible, Netflix and Spotify, an EV 320 Microphone and a Sonos speaker
  7. 1:04:34 Why have (Agile) things gotta be so complicated?
  8. 1:11:44 Is software harder than software and: First off, no process is going to help you

Chapter Notes

2:04 (User) Stories - the base of it all

Going down memory lane, meeting lots of now famous people, e.g. Kent Beck

"People have gotten User Stories wrong from the beginning"

"When I first heard the term "Stories" I thought it was stupid - what we’re doing is important stuff. Stories  … that sounds like fantasy or fiction … it doesn’t sound serious at all"

"What Kent meant with stories was really stories. We should be talking with each other and telling stories about the products"

"The goal is building shared understanding"

"What we are talking about isn’t what to build. What we’re talking about with each other is: who’s using this product and why and what benefit they get. and understanding that we can then talk about together about what to build."

"Where things go horribly wrong is when people use stories and try to do what they used to do."

"So, people try to use stories as an alternative to other specification algorithms, when that’s not what they were meant to be"

How stories are not precise and complete

8:22 Comparing stories and UML The promise with UML was that you had to learn UML and then you had to talk to someone who knew UML. Stories fix all this.

"Stories fix all kind of crappy documentation. Because know we have humans to talk to to explain things"

"I keep telling people that if you’re using stories, you have to change your process" 

"The problem stories don’t solve is the way you specify. … If you’re using stories, you still have to figure out ways to specify."

"I think people write documents because they don’t like to talk to each other."

11:15 Documents are like vacation photos

 „The minute you write stories and hand them over without having a conversation, that’s the moment when things start to go wrong.“

17:14 How Kent Beck never called "stories" "user stories"

Rumors and misconceptions on stories and sizes and templates 

How somehow people and many Scrum Master are spreading the rumor of „we have to use (User) Stories all the way  

"The way Agile works is we build little things, and we work in short cycles. … But the problem is that when we build a product that is supposed to go to the market and create value it is not something we build in days."

"Those things we can build in a few days hardly have value and it becomes hard to tell a story about those things"

"I learned these things around 2000 and we called them stories and not user stories, and we didn’t use the term epic and you know, the user story template - we certainly didn’t use that."

23:14 How the founder of Pivotal Tracker, Rob Mee, was Jeff’s XP coach, refused using the template in his tool and now it does anyway: "I’m never gonna put that stupid template inside of Tracker … well, it’s in there now. And I’m sure not because Rob thinks it’s a good idea."

"But the template falls apart super easy. … The conversations we need to have are far more sophisticated than that."

"As a user I want just dumbs down all the rich conversations we need to have …"

The three (or five?) C’s of stories

Ron Jeffries 3 C’s: Card Conversation, Confirmation

"The conversation is not about the acceptance criteria but about Who, What and Why! … It’s meant to be a bit of a back and forth."

"What I see people doing these days is: Card -> Conformation"

Documents are contracts and with stories "we finally recognise that documents are never gonna be good enough, they’re never gonna be precise enough and what matters is understanding and the only way we get it is by talking to each other."

"Shared documents aren’t shared understanding" and that will make a lot of people uncomfortable.

31:43 Story Maps - what it is, how it emerged

A solution for breaking big things down that take weeks and weeks to build into little things we can build in days.

The metaphor of rocks that when you break them, remain rocks … just: little rocks. Just like big stories (no matter if you call them epics or not) that when you break them down just remain … stories.

"Story mapping is the thing that I used to do to get from a big idea to break it down into small parts." How story maps emerged from the technique called "User Task Model" over "Span Plan" (influenced by the Poppendiecks) to Story Maps (which name came up in a discussion with Alistair Cockbourn).

How Jeff wanted to write a huge book on everything outside of Agile, but then Story Maps took off and then the small book on story Maps got bigger and bigger.

A next book is planned. Jeff is not afraid, and still has lots to say. It’ll be easy. Ha!

Jeff’s book has three forewords. It reflects the mantra of product work, being credited to Marty Cagan, that it’s all about the intersection between valuable, usable and feasible. The three forewords represent that by having representatives from UX - Alan Cooper, development - Martin Fowler and finally product itself - Marty Cagan. That trinity is called a Core Team and is still widely used.

43:10 How to teach Story Maps

Two good ways:

  1. Simply mapping something live and lead discussions, conversations.
  2. Mapping a morning from waking up to getting to work, then let a group mix the individual morning stories and change it, because some strange event happened, like: Getting up too late.

These are ways that lets people focus on writing down activities rather than things or functionalities. Also, it makes obvious that different people behave differently. Further it teaches how to slice and cut things away, e.g. because there is less time than usual. some things can not be sliced out (morning hygiene) but need to be thinned out.

Maps are useful for still seeing the whole while we flesh out the small things.

"We need details when we go into the next sprint, but we still need to be able to see the whole. Because it’s the whole that has value. That’s the real value of a map."

An application in a workshop: Planning the first release of a wine shop.

55:34 Struggling with the backlog as a prioritised list

"There’s a lot of things I disagree with on how Agile gets taught and used and abused. One of the things I struggle with is the way it is taught that a backlog needs to be a prioritised list."

"If you think of a new product … it would be completely impossible to understand what it is … based on a prioritised list of features."

"It is so valuable to see the whole. And you don’t get that in a flat backlog."

"When you talk about parts of a thing, you normally need all of them."

57:54 Products we like: A BMW 335 convertible, Netflix and Spotify, an EV 320 Microphone and a Sonos speaker

Trying to find out why we like them.

For starters, the BMW is super impractible for where Jeff lives, as they have lots of snow. He still loves it.

Netflix now works for Jeff as a traveler, because downloads are possible.

"Why we encourage people to talk about why they like a product is because why you like a product has a lot to do with who you are."

"The toughest choices are not what features your product has, the toughest choice is who your product is for and the really hard choice is who your product is not for."

"If people really love a product, I always ask: "What did you use before?"."

"When you’re using a good product, you can sorta smell the thought and care that went into creating the product."

"That’s what I really worry about when we talk all about Agile and breaking things into little pieces … that we lose sight of who its for and that we lose sight of all the little things that matter so much … and start working about acceptance criteria."

1:04:34 Why have (Agile) things gotta be so complicated?

While teaching discovery (e.g. in 5 day immersion workshops), Jeff realises that people no longer know, see and have empathy with their clients, users, etc.

"We have to come with a lot of process junk and waste to help us manage what we’re doing when a little bit of empathy and understanding of who you’re building for goes a long way."

"In a lot of contexts it’s not easy to get to the customers. And to what you say, even if we could get to them, we don’t want to. It’s not comfortable talking to those people - and it’s unnerving sometimes."

1:11:44 Is software harder than software and: First off, no process is going to help you

When Apple had a problem with a new carrier, it was normal for a developer to linger around at the carrier. "At Apple it was not not unusual, no one was asking: why aren’t you at your desk? Why aren’t you writing code? It was absolutely rational to do that."

At a different spot:

Q: "If you think of Apple, on a range from 1 to 10 where would you put the quality they ship at Apple?"

A: "I’d put it at 9."

Q: "Where would you put what you ship here?"

A: "About a six."

Q: "If you were at Apple and you would ship a six, what do you think would happen to you? You ship 6 here all the time."

A: "We celebrate that we ship all the time."

Conclusion: "Something has to change around here that is not process"

"Everything is becoming more blurred all the time."

"The hardware isn’t even the hardware. It’s the software that’s changing it."

"More and more you buy a piece of hardware and it’s not like it’s in the box and the partnership with the manufacturer is done. There’s an ownership lifecycle that supports it."

"I was at a conference in Australia and the speaker right before was a designer at Lego. and he came up with that idea that they came up with that perfect Lego model that was really testing well but it was too expensive to build. And he said „you know how it is when the perfect solution is too expensive to build and we have to figure out something different.“ And the audience was quiet and the audience was „no, I don’t know what you’re talking about."

"I see so many people in the software world arguing for what’s best and not for what’s feasible and not understanding that it’s not about best …"

We have to learn again to prototype.

"And at times a prototype is more expensive than the real thing."

"What’s interesting is that Agile Development has gotten totally effed up when it comes to this prototyping thing. There is all this emphasis on potentially shippable software, there is this emphasis on software being built and tested, but look: we’ve lost our ability to use code to build rough stuff to see if we’re building the right thing."

"More and more I talk about learning velocity vs. building velocity."

"If you’re trying to learn something the most expensive way is to build production quality software."

"Building the wrong thing at high quality is waste."

„If there is gonna be a contemporary agile way of building things t’s gonna be this mix of product thinking and customer centric thinking and Agile thinking and I’ll be honest: It’ll break the Agile Manifesto."

Great final words

"What makes a product better is not more stuff, it’s good stuff."

Links

1