Book Review: The Lean Startup

10127019So I have to admit – I expected more from this book. It’s been lauded as an important part of the Agile “Body of Knowledge” and I probably expected to much – especially in the context of why I read the book recently.

So what didn’t I like? First, the language of the book wasn’t easy to absorb. Some people can write so well, it’s easy to take in. Others (myself included) are more heavy-handed it makes reading more of a chore. Second – the advice in the book is very focused on quickly iterating through prototypes and MVPs. It doesn’t suit the character of the initiative I’m working on now (luckily there’s also 4DX). But that’s not the author’s fault.

Having said these negatives, I believe the book as a place in the Agile canon and definitely should be read by Agile practitioners – even if it doesn’t directly suit your needs.

Personal Kanban to the rescue

For my everyday “productivity” tool, I use a custom mix of practices adopted from Covey’s 7 Habits of Highly Effective People, Allen’s Getting Things Done, and Agile. In the past week or so, I felt uncharacteristically overwhelmed with everything that needs to be done. As is typical in complex situations, the root causes were multiple (although easy to  identify): we’re buying a new apartment and moving soon, we have a big family event coming soon, and (because life is not fair) got hit with several family emergencies.

Fortuitously I was in the middle of Jim Benson’s Personal Kanban – a book that was on my reading list for far too long. I had the pleasure of listening to Mr. Benson’s keynote at Agile By Example a few years back and it opened my eyes to a lot of subtleties of tracking working via Kanban.  As I consider my self a proficient user of Kanban, the book did not hold revelations (although I still heartily recommend it), but it did knock me out of my funk.

I had to set up temporary Crisis Kanban to get the important stuff handled!

That evening we set down with my wife to set everything up. Lacking a good whiteboard and wanting portability, I settled on having each value stream be a separate piece of A4 paper labeled with the name and relative importance. Tasks went (obviously) on stickies. Columns were the most simple possible – Backlog / Doing / Done. This allowed us to inventory all we had to do.

We agreed to make sure to close at least one task per day each. In the evening, we review progress and list out the 2-3 tasks e want to tackle the next day. \

Suddenly I’m much calmer.

Energy in planning

Last Monday we had our next sprint planning (#13 for those keeping count). It was a Monday, not the usual Friday to avoid missing half the team, who took a day off to celebrate the last day of school. But this strays from my topic…

I really enjoy what we call “turnaround day” – we do our Sprint Review and Sprint Planning on the same day (more on that another time). One of the reasons is that the team feels very energized during and right after the meeting.

So much that we moved up the Planning in the day, because the engineers actually want to start working on the stories that day. We’ve previously thought that planning on a Friday afternoon would allow people to calm down, have time to absorb the work over the weekend (subconsciously!) and start cracking on it on Monday. Well, surprise!

Why do I think they’re so energized:

  • new shiny things to do! – new stories, means new opportunities, challenges, valuable contributions
  • we meet as a team – working in a LeSS framework, this is one of the times members of all the teams come together to collaborate
  • egalitarian meets experts – on one hand, everyone has input into their team’s backlog sprint, including freshly hired interns; on the other – the technical leads and senior engineers get asked about their opinions on key items
  • playfulness – there is an amount of joking and ribbing that occurs at the meetings:
    • we have an informal (and unenforced) rule “you touch the story card last, your team has to take it” – ended with someone using tweezers during planning
    • last time I heard the phrase “I can take these for my team, since I’m going on vacation” (tongue firmly in cheek)
    • wayward story cards make it into initial backlog piles, before someone notices the sabotage

And in the end, we are surprised how much the team is able to pick up for the next sprint and they do deliver!

Well, two more weeks and we get to plan again.

 

New Trends in Program Management – Conference Report

After a busy week and a fantastic five-day weekend, I finally sat down to write my thoughts on the New Trends in Program Management conference I attended last week in my hometown of Gdańsk.

It’s interesting to see that a conference run by PMI would contain mostly presentations on Agile. Is it a permanent change or a fad?

I gave a presentation on my team’s implementation of a LeSS-like structure. You can find the slides online and I can talk about some aspects in future posts. Here’s a rundown of the interesting presentations I attended.

Happiness.jpg

Opening Keynote: Embedding a Culture of Happiness in Program Management (Mohamed Khalifa, Muhammad Ilyas)

I had to check my badge to verify I was at a Program Management conference! But seriously, it gladdens me that more and more people are realizing that happy employees are productive ones – and it doesn’t matter if your motives are selfish or altruistic – your organization will prosper.

A nice touch of the keynote was a survey handed out to participants, where you could rate your work happiness. I verified I was happy (which wasn’t a given), but also realized why.
SAFe – they love, they hate it (Michael Bad Coach.jpgKacprzak)

Looking at the program, one of my goals was to listen to more people practicing SAFe. I’m very skeptical of this methodology – and I wanted to open myself to arguments that could sway me.

Strangely enough, this presentation strayed far from SAFe, but was an interesting look into the life of an independent Agile coach/consultant. There is an interesting tension in having to make a living and declining engagement – either that the organization does not need you or are not ready for you.

Soapbox: Both are a failure of leadership. In the first case, leaders ignore that they have talented people in their organization that know what to do (which is strange, since hey hired them!) – or as I like to quote “you can’t be a prophet in your own land”. The other is, when leadership only pays “lip service” to an adoption or transformation (they want things to change, but don’t want to change), they select methods without being clear on goals (adopt Agile [i.e. Scrum] or else!). 

The letter to Santa Program Manager (Bartosz Rożan)

This was an elementary step through various anti-patterns in day-to-day Scrum with an accent on problems around the roles of Product Owner and Program Managers. While a lot was basic stuff, I think it was well-geared to most of the audience – looking at how traditional Program Management can benefit from agility.

Does SAFe always work? (Konrad Świstelnicki, Astrid Kleinau-Kleffe)

I had more luck in the afternoon, when I to listen to an actual adoption of a SAFe-like structure. I’m appending the “-like”, because this, like every other example I heard of, applied pieces of SAFe that made sense in their context, but not the methodology as a whole – which is how it keeps getting pitched. I also like the presenters take on distributed team planning:

SAFE.jpg

Keynote: Authorization Tiers: A Framework for Project Empowerment (April Mills)

Disclaimer: April is a close colleague of mine and she showed me this frameworks weeks before the presentation.

April take the works of David Marquet and extends them from 1:1 situations to provide a framework for project sponsors and project execution teams to optimize for the ability to perform and adapt – taking out the frustration on both sides the equation. I’m not sure, she’s posted the slides for this, but you can check her blog and get in contact.

Oxford Debate: Control is the best form of trust

While no breakthroughs occurred, this was the funniest event at the conference. I urge the organizers to repeat this next year, but right after lunch – as an energizer!

How engineers learned to meet all deadlines (Niels Malotaux)

Niels will deny and protest, but while he vehemently denies his methods are Agile, I believe they are 100% (OK, 92.67%). In a great case study, Niels presented how even in a company who’s culture and restrictions required following a lot of daunting processes, you could achieve deadlines and have a great product by shortening feedback loops, eliminating waste, and focusing on delivering value. Or as I like to say – Agile.

At this point I had to leave due to other obligations and couldn’t catch the second afternoon events. Apparently I would’ve won a prize in the raffle at the end, but wasn’t present to claim it 😦 Next time, please don’t let me know 😉

I enjoyed myself at the NTPM conference so much, that I regretted skipping it last year. I hope not to make the same mistake next year. I listened to some great presentations, had some great chats over coffee and lunch, a great evening over beers and pierogi with April and Niels.

Thank you to the organizers for a great event and for inviting me to speak.