Open Letter to “Lean Kanban University”
Dear Sir/Madam,
I’m a full-time Scrum Master working at Lunar Logic Polska. I use scrum and kanban regularly at work, and I am keen to develop my knowledge.
I heard of “Lean Kanban University” via Twitter and am interested to hear that there is now a University specializing in lean and kanban. I am keen to learn more about LKU and wonder if you could answer some questions I have?
1) What degrees do you award?
2) Who have you been externally accredited by in order to earn the title ‘University’?
3) You offer an accredited kanban training program - for the avoidance of doubt, please could you confirm to me how this was accredited and by whom?
I would be most grateful to hear your response. Thank you in advance!
John Cieslik-Bridgen
(sent 27th February 2012)
The Founder
Since taking part in Lean Startup Machine London, I’ve read “Thinking Fast and Slow” by the Nobel prize winning economist Daniel Kahneman. It’s provided some useful contrasts to the lean startup way of thinking, and also some very useful insights into the mind of ‘The Founder’.
“Most startups fail” was one of the opening statements at LSM London, and Kahneman looks at this too, but from the perspective of a psychologist and economist. For him, the startup founder is affected by a form of optimistic bias - he calls this “entrepreneurial delusion”:
“The chances that a small business will survive for five years in the United States are about 35%. But the individuals who open such businesses do not believe that the statistics apply to them”
In fact, he cites surveys that show that 81% of entrepreneurs put their chances of success at 70% or better. The upsides of this optimistic bias include persistence in the face of obstacles, but there are other downsides too, that can make the founder a difficult character to work with.
“It’s such a fine line between stupid and clever” says the ingenuous David St. Hubbins in ’This is Spinal Tap’. For the founder, the line is perhaps between optimism and vanity, determination and arrogance. Whilst I’ve worked with some fine startup founders, I’ve also seen certain patterns of behaviour repeat themselves, perhaps with a root in these individuals’ optimism bias.
“We’re just like Amazon, only smaller” AKA the curse of premature scalability or premature optimisation. It must have been around 1999 that I worked with my first startup, an eLearning platform. On this project the founder had very strict rules designed to ensure scalability - down to restricting the number of SQL queries used per page. All very thoughtful, but the project never saw the light of day. When I later worked at Openbet, the founder there told me that their approach to scalability was to worry about it when it became a problem, by which time there would more than likely be cash to throw at the problem. Openbet went on to become one of the world’s largest suppliers of software to the gambling industry. More recently I’ve seen founders insist on being “in the cloud” to ensure a scalable architecture. Only to later face the unexpected problem of a total lack of users. At this point Kahneman would remind us that the problem is not unexpected at all. So put vanity to one side. You are unlikely to be Amazon-like in scale - build simple, and grow when really needed.
“One more feature will make all the difference” This anti-pattern typically emerges towards the end of a project’s lifecycle, as customer uptake is lower than expected, and founders hunt around for a mythical missing magic feature. One of the things I really like about the lean startup approach is the suggestion that the founder should try to find and validate the ‘narcotic’ element of their idea right from the very first customer development interviews. Sean Ellis suggests that:
“achieving product/market fit requires at least 40% of users saying that they would be ‘very disappointed’ without your product”
Whatever the number, look to validate this at the beginning of your project. You are unlikely to stumble upon the magical missing feature later.
“Left a bit, right a bit” I cannot think of any project I have ever worked on anywhere, ever, which has benefited in a tangible way from pixel-level tinkering. And yet it happens all the time. Ask yourself if you are really adding value for your customers, should you find yourself doing this. And how do you know you are adding value?
“What I’m doing needs custom development” More and more recently, I’ve noticed that there are low or lower-tech solutions that can help founders test the water with their ideas. One of the mentors at LSM London talked to me about an idea, and said that it was proving difficult to find a development team to bring it to market. The idea was a community building project, so I asked if they had a Facebook page to try to measure how much interest there might be. This had not been considered - but is now up and running, attracting interest and extending the project’s reach in the most cost-effective way. For free. Don’t neglect Facebook, Twitter, a skinned Wordpress blog, hooking up to open APIs and other non-custom development routes to a product launch. Even though I now work at a custom web development company, we regularly advise potential clients to pursue such routes at least initially. It’s in our interests as well that clients succeed and use their budget wisely - though they are often surprised to hear us attempting to dissuade them from the custom route.
“I know best” The most dangerous founder anti-pattern of all. You don’t. Your customers do. Socrates taught his pupils that true wisdom consists of realising how little you know. Mind you, he was put to death, so be careful how you deliver this message.
I salute and admire the bravery and optimism of all the startup founders I’ve worked with, and as I work on my own ventures at the moment, I’m doing my best to avoid these and other traps I have seen the unwary fall into.
Certifiable?
Let’s start with an exercise in compare and contrast.
Course number one
- 2 days of classroom learning
- some pre-course reading recommended
- role-playing exercises with other participants
- an examination that guaranteed a pass
- UKP 1000
Course number two
- pre-course test taken to check knowledge
- 2+ days of real customer development exercises with real customers
- hands-on work running experiments and presenting results
- competitive element with peer and industry expert feedback
- real team work, real teams, real prizes
- UKP 200
One of these courses provides an industry recognised qualification. Which one? Course number one. I’m comparing and contrasting Certified Scrum Master training with the Lean Startup Machine competition I took part in London this weekend.
That’s not to say that I didn’t get a great deal of value from CSM training. However, it must be said that my first work with scrum started seven years ago, and I’ve been a full-time, dedicated Scrum Master at Lunar Logic Polska for the last three years. When participants on the CSM course that I attended introduced themselves, I was nearest to the trainer, and so went first. I warned my fellow participants that they could well have much more experience than me. It turned out that apart from the trainer, I was the most experienced Scrum Master in the room.
I should add that the CSM course I took was good. I have no complaints as to the content (solid fundamentals), although I didn’t like some of the delivery. Role play exercises of the type ‘imagine you are planning product x’ were almost totally without benefit and to my mind, should have no place in the training. The trainer had a good mix of theoretical knowledge of scrum, and extensive real world experience to call upon when discussing implementation. But it concerns me hugely to think of the sixteen other participants setting off from that course as ‘Certified Scrum Masters’. Or should I say, “after taking the online assessment that they were guaranteed to pass”.
It’s a powerful word - ‘master’. The course details in fact describe CSM training as learning ‘scrum basics’. In which case I would question the use of the word ‘master’, and encourage people to look beyond the letters ‘CSM’ when looking over a CV. Take a look at the comments gathered on this blog to see some of the opinions from other CSMs and Scrum Trainers on the qualification. It does seem that I’m not alone in my misgivings, to put it mildly.
I spoke with Eric Ries briefly over Skype at LSM London about the subject of certification within the Lean Startup community, thinking of the contrast that the Lean Startup Machine experience had illustrated for me. His reaction didn’t suprise me - he said that whilst he was open to the idea of providing some certification, thus far, the greatest interest had been from those who want to cash in on the idea. He also issued the caution “let’s avoid the bullshit that has spread around the agile world” - thinking perhaps of unseemly infighting within the scrum community recently (although at least Scrum.org doesn’t insist on attendance on a money-spinning course for the PSM qualification).
Caution is clearly needed to avoid such schisms and allegations of profit-driven training. As I attended the various workshops and received advice from mentors during LSM London, it struck me that perhaps a more meaningful approach to certification could borrow from the ‘apprenticeship’ notion as used by the software craftsmanship community. I think they are right in the idea of a professional journey (the idea, of course, is nothing new, borrowing unashamedly from the medieval guilds), and I think there is a role for acknowledged masters in nurturing and developing fresh talent. We’re using just that approach in the mentoring that takes place in Startup/Lean Startup Weekends right now.
Which leads me to the idea that I would much rather see something akin to a semi-formalised system of peer recognition than anything like course-based certification. I don’t think pure experience, whilst important, is enough. Peer review and recognition is needed, as well as validation from recognised experts - the true ‘masters’ of their craft. Can a given person demonstrate work on a startup? What were the successes and, just as important, the failures? What was learned? Who can vouch for this experience? Has this person a proven track record of successful team work? Can they point to occasions where they have used lean tools and techniques to help a team, product, or project? All of these experiences, cultivated over a range of clients and projects, form our validated learning portfolio, and at some point we might start to mentor others. Provided that our community accepts that we are the right people to do so.
I spoke with some colleagues at HackKRK this evening, who were quick to point out what a great point of reference a GitHub username can be for developers these days. It’s often harder for Project Managers or Scrum Masters, as considerations of client confidentiality often prevent much sharing, and I suspect there’s not so much true project work that goes on privately. One of my motivations in writing this blog is to promote and share ideas that may help my peers, and maybe it can serve as a point of reference for my professional background as well?
In any case, I hope my words can inform, and sometimes even entertain. Perhaps that latter hope means I that I am, ultimately… certifiable.
Live Chef at LSM London
It’s amazing what a few people who have never met before can achieve in less than a day. I’m at Lean Startup Machine in London, learning how validated learning can drive business development. The sad fact is that most startups fail. Why? Not because they had a bad product. They often had a great product. Just not enough people wanted it. Those that succeeded, on the other hand, learned what would work - even if this meant radical changes to their plans.
So instead of tackling the ‘hows’ of launching a startup (I work in software development, and these ‘hows’ are right now my day-to-day work), as lean practitioners we’re trying to answer a much more fundamental set of questions. Is there a problem that people care about? Should we fix it? And you could even say that we’re trying to fail in certain respects - by failing fast, we can get a reality check on our ideas, and adapt.
The team that I’m working on has an interesting proposition. We want to develop a system that’s like a satnav for your cooking. The familiar model for many agilists is to assemble epics and stories, and even, these days, plan for an MVP. Based on assumptions and a good dose of gut feel. Lean startup development wants you out - out of your comfort zone, out of the office, out in the street, out talking to your customers. Why? Well, for a start, you think you know your customers. So what have you got to lose by checking your assumptions? We talked, listened, and learned. We got certain assumptions wrong. Badly wrong. One fundamental example - target market. Our bias was such that we thought (wanted?) our audience to be like us. Thirty-something professionals, the dinner party set, cooking to impress. When the most enthusiastic response of the first set of customer interviews came from a sixty year old lady, who asked if our system could go on an iPad, we saw how badly the target group assumption was off. And then we heard of a seven year old girl, who loves to learn new recipes at home, and loves gadgets. It’s not bad to learn that your target market is way, way bigger than you realised.
That exercise cost us precisely nothing, taught us a great deal, and prevented us heading in a direction that might have closed off opportunities.
This is a work in progress at the moment, but to give an idea of the experimentation that lean startup methodology encourages, we’re running a test to see if people will click on a link to ‘purchase’ an iPhone/Android/iPad app. There is no app yet - but seeing if people will click on a purchase link for an app that promises the Live Chef experience helps validate a key risky hypothesis - will people pay? We’re even managing some AB testing to see how much people seem prepared to pay. So we’ll be able to go into the last day’s presentation with data - conversion rates, and an indication of pricing for an application. There’s more testing we’d like to do, on subscription rates for a premium service - we’ll probably be able to do that tomorrow morning. We’ll hopefully try to mock up a low-tech prototype tomorrow as well. Perhaps something in PHP with Twilio. Perhaps the Google text-to-speech service. Perhaps a video. But the main thing is that we know so much more about our customers, their behaviour, their price sensitivities than we otherwise would have done. All thanks to the lean startup methodology.
When I compare this to the approach that I’ve followed on numerous startups over the last three years at Lunar Logic Polska, and even back in the first dot.com boom (yes, I’m old enough to have worked as a developer back then), I can only wish that I’d had the Lean Startup Machine experience sooner. Lean startup methodology gives you a common sense toolkit of techniques that will help you learn FAST. Fail fast maybe. But isn’t that a good thing, for everything apart from our fragile egos?
Five things part (2) - ethics
My last post was entitled “Five things I’m glad I learned - part (1)”. I’ve had to change that for this outing, as I’m not really sure that the word “learned” is appropriate for the subject of ethics. Perhaps ‘study’ or simply ‘explore’ would be more appropriate.
If there was one module that provoked sighs and resentment on my computer science course at ARU it was the compulsory module on ethical issues in computing. The general expectation was that the module would lack relevance to the world of work, and that our time would be better spent coding. And yet, in the decade since graduating, I can’t think of a workplace where I’ve not had to confront ethical issues of one type or another, so I’m pleased to see that the MSc course prospectus still lists one of its goals as
[to be able to]recognise your obligations to function in a professional, moral and ethical way
‘Professionalism’, on the other hand, seems to be a lofty and shared aim in the IT industry. At almost every conference I attend, there are talks that refer to software engineers as professionals - but I can’t think of a time where this was set in a moral or ethical framework. I think it should be.
Whether it is in our day-to-day relations with colleagues, contract negotiations with clients, the thorny issues of privacy or piracy, or even in how we interact with our competitors or rivals, it is my strong belief that we need a strong ethical framework to shape our behaviour. Working in the gambling industry, this did become a problem for me. I can’t abstract myself away from the reality of what the software I was writing was doing to individuals. From time to time, Support Engineers would be asked to investigate fraud allegations, and it was at times like these that the sad reality of the human stories behind the numbers would emerge. Ethical issues were not the reason I left this industry, although they did contribute. I would be particularly uncomfortable, for example, when discussions about how to make it as easy to play slot machines as possible would take place. And because of the commercial imperative driving the businesses using our software, there were far more discussions of that ilk than discussions around, say, self-exclusion by players or detecting problem gaming patterns.
As a young manager too, difficult decisions nearly always had an ethical dimension. What to do about the colleague who was suspected of dishonesty? How to deal with allegations of bullying or harassment? How to balance the need to let off steam after work with the importance ensuring appropriate standards of behaviour? And I can see now that in many of the cases I found most difficult or even traumatic to deal with, had so-called ‘professional’ behaviour been shaped by a stronger ethical framework, matters would not have progressed to the point where any kind of intervention would be required.
So I remain convinced that some discussion of ethical issues in computing should be part of our professional development. And that we should have a professional body with ethical standards codified - but that is a longer discussion for another time.
