I discussed my visit to CALM Alpha and the new Kanban certification scheme with a client yesterday. We came up with a few ways to monetize knowledge.
Ways to monetize knowledge:
use the knowledge in your work, get paid for the work,
encapsulate the knowledge in a product, get paid for the product,
put it in a book, which is one kind of product. Except books don’t make a lot of money. Books can be an accelerator of other ways,
create a training around it, sell the training,
do consulting on it,
certify others to give the training, take a cut of the training revenue, or sell the certification,
spread the knowledge under an unclear license, and later harass people into paying (also known as the planning poker model),
certify others to practice the knowledge. Sell the certification (repeatedly by requiring periodic re-certification),
use the knowledge to build a product that is not about the knowledge.
Or a variation on the last, find a problem, use all your knowledge (which is a superset of “the knowledge” by a fairly large margin) and build a product that solves that problem. Get paid for solving the problem by selling the product (or licenses, subscriptions or heaven forbid ads on the product).
A wise person said yesterday at the eXtreme Tuesday club: “You need to decide whether you want to share or not.”
Some ways encourage sharing. Others do not.
We’ve done a small safe-to fail experiment with one of the certification pyramids. I’m not sure whether it has had any impact, positive or negative. If you want me to write more about it, contact me, or better, leave a comment .
Semi liveblogged on the train home to Bath. Dissent, ritual or not, welcome.
Beforehand I thought the CALM conference was an interesting attractor, but I was not sure what the boundaries were. I was hoping to meet new interesting people, get to know others better and maybe see the space of agile and lean move forward (or die, also good).
Chatting with Jim Benson and Steve Freeman on the way out, I said I left, because I didn’t feel I was learning or contributing. Jim came with a nice bastardization of ghandi: “be the learning you want to see in the world”. I should have made it more specific – I felt I was about to stop learning or contributing because I was tired.
Outcomes were reached: I met interesting people, learned, and went home with things to explore and exploit.
In the goldfish bowl discussion after lunch, I spoke up – meta – as I was about to nod off, and requested we’d spend some time mashing up stuff. I felt we were not using the experience in the room well. Yes, you can participate in a goldfishbowl, and most of the time most people are listening. Steve suggested I could have done that earlier. I hesitated to do that. There was a fair amount of presentation going on. I know I have less patience with presentations than other people. So I decided to sift for nuggets and do some writing in the meantime. There were already enough organisers, and other people butting in on conference structure does not always a better conference make.
After the goldfishbowl Jon Kendall was kind enough to show how he uses the cognitive edge sensemaking tool on an actual job. Which helped me put the pieces Marc Evers gave me together.
Steve wondered why there was not more debate during the goldfish bowl after lunch. At SPA there used to be heavy debate during goldfish bowls. I guess the timing after lunch wasn’t great, and before lunch we had had a couple of presentations / case studies which for me was tiresome after an interesting evening in the bar. I loved the ritual dissent exercise though.
Another explanation for the lack of debate might be that this is one of the few places I’ve been to in recent years where everyone present can hold strong opinions loosely. People and authors checked there egos at the door, and everyone freely shared how they worked and, more importantly, what had not worked out as they wanted.
I didnt’ feel like debating, because I did not hear much (except during some of the presentations yesterday) that struck me as shortsighed or bad use of metaphor. Which may of course be due to limited understanding on my part. Unlike say at conferences where a certain agile methodology prevails, and people believe long term planning is filling a backlog or if something doesn’t work well ‘the product owner or fill-in-cookie-cutter-rolename-hereshould do this.
Instead there were seasoned practitioners of various things, and most discussions were more like ‘what do you do’ ‘I’ve done this, and the effects of it are like this’. ‘Oh, interesting I’ve done a variation of it and the effects where like this’.
Personally, I am glad the organisers did not try to cram discussing the whole of complexity science in two days. Instead we had people who had applied practices from cynefin, agile and lean and were willing to be frank about what had worked for them and what not, as well as bring in things they didn’t quite understand.
In order to show that I care, As a Cynic, I’ll say that this Cynefin Lean Agile Mashup is never going to amount to a hill of beans. Please move along. Nothing to see here (while some skunks go off into the sunset and do interesting works).
As a frustrated and puzzled skeptic I went to the Agile Lean Europe conference to work on my frustration and puzzles. As a frustrated and puzzled skeptic I returned. To my delight with different frustrations, puzzles and some highlights.
Regardless of what I say next: creating a pan-european agile/lean event that is not tied to one of the schools of thought, nor any functional silo (looking at you, coachcamps and testing days!) is a major achievement. I tried to pull it off with about twenty other folks a couple of years ago, and failed (early, but nevertheless. It is not something I bake cake for ).
First highlight: I found a community that welcomes skepticism without suffocating it. Thanks, amongst others, to @OlafLewitz and @ojuncu for open discussion on twitter beforehand, and to those who offered help instead of rotten tomatoes after I threatened to put trainers and coaches out of a job in a lightning talk . And those who took my call for more coaches combining hands-on work with coaching (too?) seriously. More on that in follow up posts.
Although many of the scheduled talks rehashed things I hoped would have vanished from agile / lean conference agenda’s to make place for new things, I was pleasantly surprised by a number of talks. (See below in talks)
Building a car using a distributed team.
Wikispeed is a collaborative, distributed effort to build a fuel efficient car (one that is also efficient at high speed, unlike some other fuel efficient car). Thorsten Kalnin described how they use whatever works to get there. At this moment that includes for instance aspects of kanban, scrum, using object oriented principles for mechanical engineering and finding storage boxes that can be rented for cheap, while still being suitable to do engineering work.
Seeing Stephen Parry in action again, during his talk and afterwards during dinner. Olaf Lewitz has described other aspects of Stephens’ session. What I particularly liked was ‘your baby is ugly’ – get employees to analyze the companies performance as seen through their customers’ and describe that to their peers and managers (also mostly employees, lets’ not forget that). This is probably a lot more effective than outsiders saying that (e.g. Yours truly tweeting about how SAP is going lean but their products prevent their clients from evolving), and I guess it takes a lot of time and patience. Something I would like to try, nevertheless.
I stayed out of the Claudio Perrone’s A3 presentation after seeing the intro slides from outside which looked so heroic (Big Agile Transition), that I was afraid I would not be able to shut up during the presentation and heckle ehm excite. Turns out the rest of the slide deck is a lot more to my liking, including a pragmatic use of the satir change model somewhere in the middle. So I was wrong. Looking forward to see the video of it.
In the meantime I would recommend reading Toyota Kata by Mike Rother. I took it on the road this week and am pleased by how it does not try to make this kind of open ended coaching look easy, and uses storytelling plus questions to you, the reader, to show how this might work in your practice.
One more for the skeptic
It was only talks. Tip for next years’ organisers: if you want more hands-on sessions make some space for scheduled sessions that last longer than thirty minutes, some sessions that require preparation don’t magically happen in open space. Stephan Eggermont and I enjoy the challenge of seeing what of a three hour session we can meaningfully cram in thirty minutes, but we may be the exception. It seemed most people were watching as opposed to downloading the zip and following along.
I was looking forward to ‘exciters’, Walldorf and Statler from the muppets were given as example, and bar tables were placed in front of the presentations for people to heckle from. I haven’t seen that happen, and didn’t dare to either, preferring the safety of my twitter feed instead . I asked Stephan Eggermont to heckle during my lightning talk, which he did, but I was so focused I didn’t hear him do it…
It seems the open space explanation left out the butterflies. When I described my open space experience to another participant at the end, he stared blankly at me. It also seemed mostly open space veterans where butterflying and bumblebeeing around, as well as applying the law of two feet (sorry, the politically correct wording used in the opening was so complicated I failed to remember it . Shorter PC versions I’ve seen include ‘the law of motion’ or ‘when in doubt, move out’ ).
So I butterflied, mostly, except to host an open space session because someone wanted to pick my brain about session selection processes. The best suggestion in that session came from @LLillian, who stated the obvious thing I’d missed before: besides playing a perfection game, encourage session organizers to Ask for Help, to lower the barrier for new session organisers. Duh. Why didn’t I think of that before! Other than that, it struck me that few of the open space topics were original. It seems we have been struggling with the same problems for a couple of years. Maybe it is rotation of participants, maybe we are asking the wrong questions. Of course, I could have taken responsibility by posing a question as a session. It seems the stuff I’m struggling with right now is in a stage where I don’t know how to formulate the questions yet. It seems grumpy tweets, responses to that and hallway discussions help me move forward .
It will probably take a week or so to pinpoint my newfound frustrations and puzzles, at least I feel my time in Berlin was well spent. Especially now the QWAN Learning Community has some more first followers, I got over the scariest two minutes presenting I’ve done in quite a while, and I got useful feedback on the idea from various people. So thanks everybody for making it happen.
Why limit continuous improvement to planning or programming? Inspired by the DevOps movement and a new breed of server configuration management tools, Stephan Eggermont (playing Dev) and yours truly (playing Ops) set out to see if automating the hell out of a server build would benefit us. We learnt a few things. One of them: each time we logged in to the server was a system administration smell. Something in our approach to automation had failed. Time to ask why a couple of times…
We constructed a web and mail server for an early stage startup. Stephan wrote the application for it together with Diego Lont, and they were looking for a smart way to deploy it. I had looked into automating systems administration tasks with scripting tools such as puppet and chef before, had tried puppet a year before and failed to earn back the time I put in.
This time our goal was to be able to build a new server quickly, because the startup did not have the funds for more expensive disaster recovery options. We also wanted to not think separately about writing documentation: if left as a a separate task, documentation is often just left.
Stephan was somewhat new to linux systems administration and wanted to learn, I have done linux administration on the side for almost ten years now, but many things I still don’t really understand (e-mail, firewalls), even though I administer a couple of servers that seem to be running ok.
We hoped that documenting ourselves in the form of scripts would help us understand, and that writing these scripts in a Domain Specific Language designed to describe servers (puppet in this case, but it could have easily been another tool) would force us to be precise in describing our understanding.
So why did we need to log in?
Our web server would not start, but puppet did not pass the output of the web server (lighttpd) on to us.
Why did our web server not start?
We made errors writing its configuration file.
Why did we make errors in writing the configuration file?
We used lighttpd, a web server I hadn’t used in a couple of years. Its configuration is not that hard, but you have to use exactly the right lines. Especially with secure sockets (a bit tricky on most servers) this turned out to be harder than we thought.
We don’t have automated tests yet for the configuration, Stephan and Diego’s software has automated tests on the inside, but the mail and web server stuff does not have automated tests. I have a virtual machine that is, with the puppet scripts, roughly a copy of the production machine, but learning puppet and figuring out how to automate tests for the environment was too big a step.
There are many more whys. Sometimes we were in a hurry, so we didn’t sit together to think through the next step, do it, and reflect on it. Sometimes we still did things directly on the server, because we could not figure out how to quickly do it in puppet. The first steps in automation required a lot more patience than I expected. The object oriented database used does not come with a ubuntu package, but needed to be installed with a couple of shell scripts that required manual intervention. We did not have the courage or understanding to rewrite the scripts as (automated) puppet recipes or an APT package.
It didn’t occur to us at first that logging in was a smell. We just started to notice after a while, that whenever we logged in to the production server, there was something we had overlooked. We broke something, or could not see whether something was running properly or not. Sometimes we took action to prevent having to log in the next time, sometimes we thought it was too much work for now, and accepted that our automation is not yet ‘perfect’.
If you made it this far, congratulations! You may want to hear more. If so, join us this Sunday at 15:00 In the configuration management devroom during FOSDEM 2011 in Brussels (no registration required). We’ll be talking about configuration management for developers. Learn from our mistakes, so you can make different ones
Thanks to Stephan for coming up with the first title. And Marc Evers for shaping the second one.
I saw this tweet by Alan Shalloway the other day, it went like this*
“Scrum, XP, Kanban, XP, lets’ assume they all work”.
This describes the conferences I’m attending this fall and the sessions I’m running reasonably well. I’m even assuming Java works, which seems to be more and more of a stretch for the near future .
What have I been up to so far? The Belgian Lean and Kanban conference a few weeks ago attracted quite a lot of people new to agile and lean software development. Rob Westgeest and yours truly also presented at a private conference for the dutch tax authorities, we never ex pected to have a room packed with over 120 people for an extreme extreme (duplication intentional. TDD as if you really meant it is an exercise we learnt from Keith Braithwaite) test driven development demonstration. The agilecomes to you vendor event at which I did some systems thinking was also a lot of fun; the panel discussion afterwards prepared with focused questionnaire by Jeffrey Fredrick and colleagues was very effective – the audience shared a few concerns, so we could answer a couple of questions in depth. For instance, several people were wondering about writing down requirements (they wondered about the how, the presenters wondered about the why ), and their angles were different: some wanted to know how to combine working with stories and iterations with medium term strategy, while others were concerned with demands for documentation from the organisation. Which of course led to a couple of why questions from the panelists .
It’s fun to see crowds gathering for things I’ve cared about for a couple of years, and it is even better to see extremists of various sorts look over their fences and see what we have in common again, like in the ‘good old days’ of the agile manifesto. at, just in case you are wondering what I’m doing at the scrum gathering Amsterdam, November 15-17 – this will be the first scrum gathering I’ll attend, thanks to the invitation by Tobias Mayer and Gerry Kirk to host a ‘deep dive’ into extreme programming practices that complement scrum (and kanban) well. This gathering will also feature a Kanban deep dive. On the other extreme, I’ll be attending the software craftsmanship conference in Bletchley Park tomorrow; besides focusing on people and process really getting to know your tools and techniques to actually build stuff also works.
Barry Evans works as an independent consultant and writer, and is based in France and the UK. I met Barry a few years ago at Agile Open in Belgium, when he was working as a senior coach in BT’s large-scale Agile introduction. Now we’ve done an interview to find out more about his new book “The Trousers of Reality”.
While I was on holiday, Marc started creating a new product from scratch. He’d been walking around with a problem he wanted to solve and couldn’t find anything that he liked. Marc also wanted to try out the Scala programming language, to see if it would be worth using, and thought nothing helps you focus more than building an actual product.
I didn’t get it. But I gave Marc a hand anyway, because we had previously decided that QWAN values:
supporting someone who has a passion over discussing the business case at length
We chose the theme ‘my method is bigger than yours… or is it?’ because it seems that as this agile software development thing goes mainstream more and more people lose sight of what we perceived was one of the underlying goals of the Agile Manifesto: get continuous experimentation and learning going by developing software and helping others do it across communities – hence the signing by people involved in all ‘lightweight’ methodologies at the time. We like the Named clouds meme and hope it spurs some discussions.
Even if this theme does not speak to you, come to Agile Open Holland anyway – anything goes, and new cloud formations are likely to form during the conference. Named ones in the sessions and the hallways, unnamed ones in the sky (we do hope the sun shines most of the time though..).
I am one of those people who, at times, propages practices inspired by the toyota way (e.g. lean software development). However, I also have my eyes and critical mind open – I don’t want to be part of a cargo cult, I want to practice and promote practices that make work both more effective and the results of the work more valuable, and make work more fun and sustainable.
A friend of mine recently mentioned a toyota employee who died from overwork. It took me a while to find the full story – at first I only found reports from 2002. Apparently, his widow won a lawsuit against toyota – his death is now officially declared ‘karoshi’ (the japanese word for overwork).