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).
Devnology Community Day, Saturday February 4, Baarn, Netherlands
Keeping with my plan to do more shorter, local conferences and not keeping with my plan to avoid weekend conferences, I’ll be hosting Robert Chatley and Matt Wynne’s eXtreme Startup at the Devnology Community Day
It was great fun to run it at last years’ XP Days Benelux. It’s always amazing to see how focusing on incoming feature requests lets you easily forget the big picture.
Participants at Devnology should have at least as much frustration So bring your laptop or pair up with someone and join the fun. The only
thing you need is your favorite programming environment and a way to respond to HTTP requests.
FOSDEM – Sunday February 5, Brussels, Belgium
If you break a plan, do it in style. So I’ll also be doing something on the Sunday. Stephan Eggermont has arranged a Smalltalk Devroom at FOSDEM
To keep my sustainable pace, I’ll just move my weekend to the Monday and Tuesday after these conferences. We’ll see how that works out.
Mini XP Days Benelux – Monday April 23, Heeze, Netherlands
Keeping up with the two main session themes of last year, smalltalk and configuration management, Stephan Eggermont and yours truly will rerun our session on getting started with Chef and Puppet at mini XP Days Benelux, the full program is yet to be announced.
Rob Westgeest kindly championed our session, as he assumed we learnt from the feedback from the previous session. The lego-themed slides were well received, but we could have focused the introductory stories more on one or two complete examples, as opposed to telling a bunch of benefits related to things we’ve done. The same went more or less for the code samples. It wasn’t clear to all participants how the ‘big picture’ fit together, so we’ll see if we can visualize that.
I look forward to seeing you at one of these conferences!
What do Extreme Startup, Smalltalk and Server Login Considered Harmful have in common?
I’ve made some slides to promote sessions about them at XP Days Benelux. Competition for the most hilarious Official Half Minute Pitch at each half day of the conference is fierce. This year sessionorganisers can send in slides. Luckily Stephan Eggermont reminded me that the deadline is right about now. With a few iterations, film poster-like slides are my themes for this year.
When Robert Chatley asked if I wanted to be stand-in for Matt Wynne, who has more sensible priorities than most of us I thought for half a minute and said yes. The eXtreme Startup is a hands-on session that lasts a morning, but allows for new participants halfway through. I attended it at Agile Cambridge, and found it loads of fun and educational. Can you and your partner code against the market and your competitors? Will you deliver the most business value against changing demand? Can you balance the flow of euros against technical debt? Join us this friday at 9:30 in room 16 and find out.
One of the ways to iterate quickly while finding out what is a good market fit, is to use a language and environment that was build to explore the unknown. Join Stephan Eggermont and yours truly this Friday at 16:30 in Room 16 and find out how web development can be like desktop GUI development, and how Debugger Driven Development optimizes your inner software development loop! No code was harmed in the making of this session.
So, you’ve found your strategy to find your market and keep up with it and you’ve found a development sweet spot. Now your deployments can’t keep up. Servers burn down, your mail is a spam magnet and as a systems administrator you are getting tired of late night phone calls. Devops configuration management to the rescue? Come to our session “Server Login Considered Harmful” and find out if Chef can save your Puppet’s bacon. Find out this Thursday at 11:00, again – surprise surprise? – in Room 16.
XP Days Benelux is already sold out, I just wanted to share the fun Ihad in preparing it. Still hoping to see you there .
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.
I’m live blogging from the uk government IT meeting on agile at the SPA conference. Nothing beats a blogpost fired off in anger
Here are some tweets I would like to elaborate on:
Me: “Offshoring government it is stupid”
Eric Lefevre (@elefevre): “why? on paper, if there is any way to commoditize software for government, it would sound like a win, wouldn’t it?”
Me: “Software is executable knowledge. Offshoring software is giving a potential enemy exclusive posession of that knowledge.”
Imagine, if you will, the UK code breakers in the 1920’s outsourcing some of their work to Germany, because labour there in the crisis after the first world war was cheap. Manual computations, but nevertheless. What would have happened by 1938?
This is a bit of a straw man of course. However, the problem with outsourcing and/or offshoring is that you put executable knowledge, plus the expertise to grow that knowledge and build knew software from it in the hands of one party. That leads to a dependency on that party. As long as things go fine, that is swell. When things go bad, not so much.
If you think that documentation is going to help. It might, if you are lucky. Most of the knowledge that goes into software is tacit, and very difficult and costly to transfer.
So if you are a government agency (or a company for that matter), don’t be stupid. Keep some good technical people on permanent staff, who know how your crucial systems work, and can make modifications. If you add some external staff to that to be flexible in capacity or bring in specialist knowledge, great!
Just don’t forget to let them work side by side with your permanent staff on a daily basis, so your organisation does not leak knowledge that it can’t recover on its own.
Just remember, knowledge is power. If you’re not careful, you will learn that lesson the hard way.
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.
I planned to write individual posts about new and upcoming workshops, but the rate at which we get invited and accepted to conferences this fall outstrips my ability to post new entries I have to post now, before the conferences themselves are over… I hope you’ll join us for at least one of these. We’ll be doing some hard-core programming workshops as well as more enterprise and facilitation oriented sessions this fall.