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.
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?
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:
- Make users successful
- Create a setting for great teamwork
- Deliver value continuously
- 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.
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.
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?
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”.
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).
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.