Modern Agile meets Design Thinking

This is a guest post by Sigrun Tallungs (@tallungs). The original was written in Swedish and published on this blog earlier. That post, in turn, was a response to my post on Modern Agile.

What I like about Modern Agile is that it shines a light on what really hurts today, beyond the traditional focus on pumping out software features. Modern Agile aims to understand how we create value. Here’s how: Someone has to love what we create (”Make people awesome”). And for us to succeed we need to feel safe and reduce the risks involved (”Make safety a prerequisite”). Since we cannot figure out in advance what people really need, the way to go is to carry out a great number of experiments. That’s is basically all Modern Agile is – but that’s a lot!

Since its birth, the agile movement has engaged software developers but relatively few others. To face the challenges of today we need to involve all parties in the business surrounding the service or service eco-system we are developing. It is the co-operation of all these people that needs to be agile.

Continue reading

Modern Agile möter Design Thinking

En gästkrönika av Sigrun Tallungs som en fortsättning på mitt tidigare inlägg om Modern Agile.

Det som jag gillar med Modern Agile är att det riktar strålkastarljuset på det som gör ont idag, det som ligger bortom funktionerna. Modern Agile siktar in sig på konsten att förstå hur vi skapar värde: Så här ungefär: Någon måste bli nöjd och glad av det vi bygger (”Make people awesome”) och för att lyckas måste vi alla vara trygga och minska riskerna (”Make safety a prerequisite”). Och eftersom vi inte kan räkna ut i förväg vad folk blir glada av så måste vi sjösätta väldigt många experiment. Det är egentligen allt innehåll i Modern Agile. Men det räcker ju å andra sidan långt.

Under de 15 senaste åren är det ju mest systemutvecklare som engagerat sig i att förbättra utvecklingsmetoderna. Men för att lösa de utmaningar vi har idag krävs fler kompetenser från alla delar av den verksamhet som finns runt en tjänst. Det är samarbetet mellan alla dessa som behöver vara var smidigt och agilt. Men frågan är hur man ska engagera de kompetenser som har för vana att jobba jämförelsevis traditionellt?

Continue reading

My Take on Modern Agile

The cover version

I’ve had some good experiences using the Modern Agile model for explaining agile thinking to people. For reasons laid out below I use a somewhat adjusted version of the model (words in italics have been altered from the original), like this:

  1. Make users successful
  2. Create a setting for great teamwork
  3. Deliver value continuously
  4. Experiment and learn rapidly

If you’re interested in why I feel that Modern Agile is important and why I have adjusted it for my own purposes, please read on.

Continue reading

Why You Should Avoid Using Projects in Software


Organizing work around projects does not fit any form of work that is creative, open-ended, and patterns-based, relying on human ingenuity and judgement to create value. This is most notable in research, creative jobs, and development in all its forms; be it organizational change, personal growth or software development.

Continue reading

When the manager’s out, the coaches dance on the table

I work as a software consultant and often in the role of a so-called “team coach” or “agile coach”. That’s basically just a hyped-up term for helping teams and departments to improve, to be more effective, and guide them on their way amongst a myriad of options. So coaching is great and many coaches I know are great, but there’s something bothering me. My opinion is that much of what I do is a kind of management – not of the people but of the work, and I’m getting more and more concerned about this. Should this really be the coach’s job?

Continue reading

Honey, let’s start over: A tale of business kaikaku

When Ian told them what he’d done, they couldn’t believe their ears. He had what!? He had erased every document in the company database concerning hiring and retaining staff. Joan’s deep thoughts on “talent management” simply gone. Gone! “Hey, what about the backups?”, Helen asked. Ian just smiled, “Those too”.

Continue reading

Recently, I retweeted an item from Neil Killick and I was surprised to see a response from Tom Gilb, legendary software methodologist. The tweets can be viewed in the picture below (read from bottom up).

Two tweets, my retweet and Tom Gilb's reply

Talking to Tom

Apart from the honor of getting some of his attention, I was a bit concerned with the response. I seemed simplistic and categorical to me. Quite frankly, it sounded like something out of a schoolbook in software engineering from the 80s. I find myself in disagreement with it. To disagree with Tom Gilb is scary so I needed to write down why.

Continue reading

Functional Scope Design: Why requirements must go and design for use should take its place