I have always hated functional silos and shared service centers with a passion, but never really thought about why.
They always get in the way of getting stuff done and it seems they only exist to slow things down.
Only recently did I realize how blindingly obvious it was why they did not work. They do not feel your pain. They are not in your value stream.
I’ll try to explain with some examples.
Yesterday I got a mail from one of my clients that started with:
“The telecom sector is a dynamic industry, which requires us to constantly focus on costs. We have therefor introduced 3 measures to help us manage costs.”
And it continues to require me to agree to a 5% reduction in my hourly rate. If I don’t agree I might lose my contract.
Oh.. and they need an answer today.
Now here is why I will not negotiate about cost. There is nothing to negotiate about.
Today I got a mail from my barber. He is a successful and smart businessman with a good running business, employees and happy customers.
He had another problem though. He was still trying to get his phone system supplier to show him the names of his clients instead of regular caller ID. I helped him out before with this particular case when I helped him convert the export from his client database to the format the phone supplier needed it in. But now it turned out they could only import 500 numbers, not all his 2000 clients. Could I help him out once more to filter the list?
Lars Vonk recently posted this comment on Joshua’s talk about Lean Startup: Why It Rocks Far More Than Agile Development
So I listened 30 minutes and stopped because I am thinking if this leanstartup is really an ugly baby? I heard a couple of things which feels like an agile rebranding thing:
- The example on the 9 months building and then launching. What book tells you that? How about Principle #1 from the Manifesto: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Are you doing customer tests in the definition of done? Then it is the leanstartup definition of done. What is that about?
Should I continue and read the book or is it a waste of time? What does it really add?
The first thing I need to get off my chest however is that it is not Lean Startup vs Agile. It is Lean Startup & Agile. It is like Extreme Programming and Agile. On the surface they are similar, but with a small twist. And once you dig deeper you find elements in both that feed of each other. And today almost all decent Agile teams are using both Extreme Programming techniques with Agile.
The short answer to question 1 is: You should certainly continue and read the book.
The longer answer to question 2:
For me the best summary is Agile is the right way to build software. Lean Startup is about finding out what the right software is to build in environments of extreme uncertainty.
I just stumbled on an blog entry on Leanca.mp which asks the question: “How can we prevent Lean Startup from becoming dogma.
And it has some interesting comments on there, in original order:
Lean Startup needs to avoid becoming dogmatic or a religion
and:
Let’s not get into where agile ended up with SCRUM. As much as I love the whole movement, I start to feel more dogmatism and it is very important to become aware of it before it is too late.
And ends with:
I’m really interested to learn from Agilists, Designers and others who’ve been there, so we can learn from you..
So. Here’s my take on it. You are asking the wrong question. Let me explain.
Over the past few weeks and months I have used quite a bit of NodeJS and Redis when I am developing. Now I am nowhere near a full-time developer. I am mainly doing Lean Startup consulting, Agile Coaching and Storytelling workshops, but at one of my clients I am also helping out developing an MVP when time permits.
But before I get to the good bits, let’s start with all the reasons why I do not love Node and Redis.
One of the reasons I hate analogies is that we are still stuck with them way after they lost their usefulness in a particular situation. Even to the point they can be considered harmful.
Of course the reason I love analogies is that they are very powerful because we can use something familiar to describe something unfamiliar.
I think the architecture analogy has lost it’s usefulness in IT. In the old days it might have been useful when we were building big monolithic IT systems and compare that to building a carefully constructed cathedral, but the world has changed.
