The Phoenix Project – 5 reasons why you should read it!

24 November 201424 November 2014 / one.hundred.acorns / Leave a comment

tl;dr: buy it here! ;-)

#1: It’s well-written

First of all, I won’t pretend that I’m able to judge the book’s literary quality as English is not my mother tongue. But the read is really gripping and absorbing and it’s quite hard to stop reading it, you want to devour it! The authors managed to find the right tone and the right pace to tell an 300-ish pages IT story, which is a performance in itself!

#2: It’s real

Well, almost :-) Even if this novel is a fiction the story sounds pretty real. It tells things that will certainly resonate with you if you’ve been involved in an IT project. Whether you are a developer, a project leader, part of the operation team, member of the compliance department, the security guy or even the CEO, it will certainly remind your own past experiences.

#3: It’s unique

As far as I know, it’s the only one of its kind. I’ve read Commitment by Olav Maassen, Chris Matts and Chris Geary but it’s a picture novel (and by the way, go get your copy if you haven’t read it yet!). There’s also The Goal by Eliyahu Goldratt and The Gold Mine by Freddy and Michael Ballé but even if I did not read them (yet!) they seem both more business oriented (correct me if I’m wrong!).

#4: It strikes home

If you’re in the situation the main character is facing at the beginning of the book, then you will obviously have some ideas to get things better. Some of you might realize that your fate is not fixed and that there are other way to work, more efficiently!

#5: It’s not just limited to the finding

As the story goes on, you might learn about new things. You’ll discover the power of DevOps and Continuous Delivery just to name a few. You’ll find out what the Value Stream is all about and how to increase its efficiency. What Lean can bring you.

Get your copy!

Bridge the gap between dev team and business people! – Idea #4

7 September 20149 November 2015 / one.hundred.acorns / Leave a comment

This article is the fourth out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people.

Written so far:

Value Stream Mapping

First time I discovered Value Stream Mapping was when reading the very interesting “Lean Enterprise” book by Joanne Molesky, Barry O’Reilly and Jez Humble. The final version of the book will be released in December but the early release version is available for download at a lower price since a few months now.

A Value Stream Mapping is a method from lean-management that allows you to quickly visualize the flow of value delivered from the genesis of a project until the customer delivery. It has originated from manufacturing but it can easily be applied on software development as explained in “Lean Enterprise“.

The exercise is pretty straightforward, you just have to write down all the stages that are necessary to bring an idea to its delivery and write under each steps the Lead Time (LT) and Value Added Time (VA). The Lead Time is the elapsed time needed to arrive from a stage to another and the Value Added Time is the amount of time really spent on that step where value has been added (the real work)

When working with huge companies where there are a lot of processes and departments, the exercise might take some time to accomplish as you’d need to meet people from all the different department involved in order to collect all the data. For us it was quite easier as it took us only one and a half hour to end-up with this:

(Pink post-it notes represent process stages, LT and VA are written under each)

First thing to do is to select a recent representative project (the kind of project your company is used to do in terms of size, people involved …) and obviously one that has been released to the customer! Invite enough people to be able to determine all the steps and find out corresponding LT and VA. We were only 3 to perform the Value Stream Mapping (a Business Analyst, the Head of Development and myself). As soon as all the steps have been found out, we used time tracking and reporting tools to get the exact amount of time spent on each steps (the VA) and when exactly those started. Some of the steps might be done in parallel and iteratively, that’s why some sticky notes are under other ones (in that case the corresponding VA is the sum of the whole column).

As soon as you have written down everything, just sum up all the VA’s and LT’s (some conversion might be needed here as some figures might be in days and other in weeks or months) and divide the total VA by the total LT to find out the Value Stream efficiency rate. The lower it is, the bigger is the chance to easily find some process improvement ideas!

The very interesting part starts at the end of the exercise! Well, you know, everyone might have in mind where usually things are stuck and where you might need some improvement to speed the value flow. But having the Value Stream in front of you clearly helps to focus.

The Value Stream is the perfect medium to start collaborating. Invite a couple of key people to join (from development and business side) and talk together in order to find out what could be improved in order to speed up the flow of value delivered and avoid wasting precious time. List out all the ideas and try them! Redo the exercise later on and check if the efficiency rate increased!

You will get a better understanding between all the stakeholders of how work moves through the company. People from different departments and having different point of views join together and collaborate to improve the whole company’s efficiency.

Mission accomplished!

#CraftConf – Gojko Adzic – Flexible scope

30 April 20145 May 2014 / one.hundred.acorns / Leave a comment

First of all, I’m a big fan of Gojko’s work. I’m constantly trying to contaminate people around me and ask them to read Impact Mapping which I think might be a super duper solution to lesser the gap between IT and business people (and this is just one advantage amongst others! Just read it :-) ).

This presentation was not (only) about Impact Mapping, though, but more on how to write better User Stories. Gojko showed us how by spending 10 minutes more on writing user stories, they could be 10.000 times better :-)

The fact: our systems lack on flexibility. And that’s pretty strange, because this is always something people are searching for. Most of the time they’re even OK to pay more for flexibility (think about train of flight tickets that are much more expensive with some flexible options).

Systems are often built with a lack of flexibility and when their limits are reached people get into a crisis situation where the only possible option to keep the business alive is to Think & Redesign the whole system (and Measure if they’ve built it the right way this time!). But why wait for a crisis or chaos to do things the right way? Wouldn’t it be simpler to do it from the beginning? Make sense, uh? Jez Humble wrote about “Does Systemic Change Require a Crisis?” in his Lean Enterprise book. He quoted “The Corporate Culture Survival Guide” book by Edgar Schein. Pretty interesting.

Ok, so we should think about flexibility sooner. But keep in mind that trying to have a flexible scope is impossible without having a big picture of the goal to reach. User Stories are often disconnected from real business needs. Why? Because business people like to write what they would like to have on Power Point slides, not by saying things like “as a user I want this or that”.

Tim Hartford wrote the Adapt book, where he tells us about the Palchinsky principles. As stated here: “Peter Palchinsky was born in 1875. He was a mining engineer who wished to take a more humanitarian approach to engineering […] He argued that Russian engineers did not approach problems in an “academic-dilettantish” way. Instead, they took on every problem as a purely technical one and assumed that if a solution incorporated the latest science, then it was the best solution”. Does this remember you something? Doesn’t it sound pretty familiar with what we’re experiencing today? Palchinsky said that linear plans never works because they do not consider Local, Time and Human dimensions. What would that mean? Well, did I tell you to read Impact Mapping yet? ;-)

So, how to take those dimensions into account? Think about:

Variation: search for ideas and try new things…
Survivability: …on a survivable scale, meaning where failure is survivable for your company….
Selection: … and get rid of those which do not work! (A/B test, monitoring, …), learn from your mistakes!

We somehow have to create a GPS for our apps! And as a GPS system would do, replan in case of problems! User Stories should somehow include the “excepted time for arrival” information!

How could we apply the 3 dimensions above in our User Stories? Here’s Gojko’s advice:

Variation: Plan to learn! US should not be commitments but options! We definitely need to change our mental perception of US. Use what Tim Brown says in “Change by Design”: create options during what he calls a divergent phase and then make choices during the convergent phase.

Selection: Plan to discard mistakes: put a victory condition on your User Stories.
Survivability: Plan not to kill your company :-) Great User Stories are survivable experiments!