We often discuss the benefits of Innovation Accounting which is also known as Lean Startup with our clients. We experimented with different forms of learning - from plain old talking about the subjects and sketching the principles to presentations, we always had the feeling that there had to be a better way. Especially since the great ideas we help develop by facilitating idea development workshops will become even more valuable if you apply these hard to explain principles on top. Sven clustering ideas produced in a workshop The slides Sven prepared seemed to be interesting judging by the numbers on slideshare. But still the reactions when we gave that talk did not totally satisfy us. When Sven and Katrin of CoCreact sketched a workshop on the subject at Play for Agile 2013 we immediately knew that was the missing link between our experience and delivering it to our clients. Workshop participants working on their idea iteratively This new workshop we’re talking about simulates several iterations, so the agile and lean product development mindset is not only a subject that’s discussed, but an actual hands on experience that’s undergone by the participants. Ideas are developed, presented to potential customers and reworked several times. How we achieve this? Strict time-boxing of the iterations in a sand-box created by our experience in iterative product/campaign/idea design. Groups interchange their new ideas switching vendor and client roles The pictures originate from something we do before including a workshop in our portfolio: a final prototype workshop. We believe in iterative idea development so much that we apply it to the workshop on the topic too. It was quite a success although we made it hard for the participants by selecting them from very different expertise: advertising, strategic consulting and even human resources. We always advocate diverse teams, but to see how the groups that in some cases came from completely different working domains performed surprised even us. Diverse people - diverse footwear We were making a lot of things happen since the last blog post which is almost a year old. This workshop is one of our personal highlights since it manages to deliver the benefits of Lean Product Developement. We’re just preparing the next lean product development workshop for a client which Sven guided in developing ideas before. Now we’ll let them rinse and repeat the accelerated feedback loop technique described above. It’s a great way to see why we also call it Innovation Accounting: you have a timebox/budget, you deliver a lean increment to the customer once you run out of time/budget, you ship. Then you weave in the insights of your customer’s feedback into the next iteration. Accountants love this for the reduced risk, and we love the term Innovation Accounting since it underlines that Lean Startup is also a more than interesting process for mature companies.
originally published on the official arduino blog This summer I had a speaker engagement at the Codemotion conference in Berlin which I really enjoyed for many reasons. For starters Jule & me participated in an inspiring wearable computing workshop where we met Zoe Romano for the first time. The next day I talked about a possible and easy way how to build the internet of things. Presenting thoughts on & actions how to build the IOT. After the talk it seemed to appear like a a good idea to Zoe that I should get a sneak peek at some new Arduino hardware. There weren’t any more details since it was still secret back then. Of course it didn’t took me much time for consideration since I really love Arduino for making our hardware prototyping so much easier. I happily agreed on checking out this new mysterious device. <!-- more --> The talk was about how to connect anything to the internet using an open source framework I initiated called the Rat Pack, so I assumed it had to do something with online connectivity or that something had to be connected to the internet. Turns out it was about both ;-). Making things talk with each other online (source: slideshare). When Zoe told me about the Arduino Yun I was immediately stoked: an Arduino Board equipped with wifi, plus being able to access a small real time linux system. How awesome is that? Exactly. I couldn’t wait to get hold of the Yun, and when it finally arrived it became quite obvious to me that I had a well thought and rounded product in my hands. Before I really knew what hit me this thing took shape on our balcony: Back then secret device, back then secret Yun. I’ll skip the amazing deeper tech details if you don’t mind (Uploading via wireless LAN, remote debugging, SSH access, Ruby on your Yun…). If you do mind please tell me, I’m glad to blog about them too ;-). I’ll just give you a rough outline of the journey I went through with the Yun so far. The first idea was to integrate it into the Rat Pack ecosystem. Adapting the Arduino client code of the rat pack was fairly easy, it simply uses Linux shell commands on the Yun instead of putting the HTTP command together in the Arduino C code. It’s just a small detail but dramatically reduces the complexity of your project. You don’t have to implement the HTTP calls yourself, you can rely on the work horse that Linux is. Being inspired by this first success with the Yun I thought maybe I could reduce complexity of the prototype of a device that we use to welcome guests at our place. I’m talking about the Bursting Bubbles Foursqaure Switch. Foursquare & Arduino powered soap bubble machine. When you check in to our balcony with foursquare, a soap bubble machine starts filling the air with bursting bubbles. The first prototype uses Arduino connected to an XBee Wifly to control the soap bubble machine and a Rat Pack server that handles the Foursqaure API. Initial approach with lots of moving parts™. Quite complex and actually and as you might have guessed the Yun helped reducing both the software and the hardware complexity drastically. Adding it to the project made it possible to cut off a lot of fat. Actually it now only consists of the Yun connected to the soap bubble machine. The Yun way. What’s true for the hardware is also true for the software. Have a look at the code base. Reduced comlpexity is achieved by processing the response of the Foursqaure API on Linino as opposed to letting the Ruby server take care of it. And although there’s much debate when it comes to JSON processing with regular expressions in general, I just used grep and a matching regexp to extract the information from Foursquare’s JSON response. The parts marked green are the only ones necessary after adding the Yun to the setup. Losing some pounds. Or rather kilobytes… For us at making things happen the Yun will also be the platform of choice for our Internet Of Things workshops. Until now we use Arduinos and XBee WiFlys since they turned out to be the most robust solution for introducing a group of people to the principles of connecting things to the internet. Current ‘IOT Basics’ workshop setup. Although this works most of the time there is still time needed to wire things up and debug the hardware the participants build. With the Yun we can reduce the time necessary for setting things up and debugging the custom setup and use it to concentrate on spreading our knowledge on the subject. Actually you only need two wires for the basic Rat Pack example when using the Yun: Future workshop setup: drastically reduced wiring effort. So on the bottom line I see the Arduino Yun as a major milestone in making the internet of things available to a broader audience and empowering fellow makers and tinkerers to spent less time debugging and more time inventing. Less complexity = more time for creativity (source: twitter). It will also make our workshops far less complex and let the participants concentrate less setting things up and focus on their creativity. I did not use all of it’s features yet, I’m more than curious to explore more of it. The feature I’ll focus on next is the possibilities of actually using the pins of your Arduino via RESTful web service. I guess I’ll keep you posted about that. Thanks Arduino for this awesome device and thanks for letting me have a look at it a little earlier. It seems like the beginning of a wonderful friendship…
If you met Jule & me lately and talked about the #internetofthings chances are high you will have heard the term “Makers Go Pro”. Here is one example for a pro version of a tinker-idea: a real life facebook likes counter. Real life facebook by the numbers. Source: smiirl.com So what are the differences between pro and tinker projects? In my opinion one aspect is about the quality of the hardware in terms of tech and in most cases more striking - design. <!-- more --> Rather tech focussed approach. Source: skolti.com_ Of course there are also tinker projects that combine technology and design. This mainly depends on your own abilities and your network. If you aren’t too much into package design perhaps there is somebody in your netowork who is? Real life facebook interaction. Source: makezine.com What I see as the main difference between tinkering and pro maker artifacts is the ability to produce in large quantities and to be connected to other makers or manufacturers that are able to do so. Rat Pack IOT’s circuit board. Source: pics.makingthingshappen.de There is a rising economy of services that provide just that - hardware as a service if you like. Send your CAD files and let them produce your packaging, or as in the example above: let your circuit board designs be produced in professional quality. In addition put the plans for your circuit board on open source and enable everybody to reproduce it. I’m excited about all the possibilities we already have and guess we have some quite interesting times ahead. What we need to see most to be able to take the next step towards the much quoted next industrial revolution is a way of collaborating between all the different fields of a maker project, be it tinkering or corporate work. A thought to be discussed. So feel free to go ahead & tell us your thoughts on the subject. We’re curious!
If you ask me what lean hardware development is and you have a background in software or the startup economy the explenation is short: lean startup applied to physical product development. The more interesting conversation starts if you do not have a software background. Developing software products the weapon of choice to minimize risk & waste and at the same time maximize chances of success & return of invest these days is lean entrepreneurship: agile software development tightly glued to lean startup product development. So what does this mean for the development process of physical goods? Can it be applied to my average internet of things project too? You might have guessed - the answer is: yes! I’ll elaborate it using as little buzzwords as possible so you can concentrate on the advantages of the concept of lean hardware itself. The mood lamp. <!-- more --> What you see here is the hardware manifestation of the starting point of my approach of developing web apps: a minimum viable product. It is a prototype that represents the minimum set of features to be viable to its users by delivering a certain value. It’s also viable to its producers to validate the proposition of the value they had in mind to be delivered to their customers. Question is: What Is It? It’s the mood light - using the rat pack internet of things framework for rapid iot prototyping and a sentiment analysis web api to mix colors depending on the percentage of positive, neutral and negative tweets that relate to a given hashtag: red for negative, blue for neutral and green for positive moods. Rather minimal although already proposing a certain value: delight the attendees of an event for the time of their visit by displaying the mood of the event’s twitter timeline intuitively. Mood Lamp User Lab Spring 2012 the fabulous Digiwomen asked if I could build something physical that’s somehow related to social media to kick off the Social Media Week with a blast. So I started that minimal to get the product in contact with real users early and to weave in their feedback and more important their reaction to shape the face of the product. This technique is called validated learning or rapid prototyping. Back to our value proposition: delighting the attendees of an event for the time of their visit. The first test drives of this hypothesis took place at selected local events: the picture above shows a hacktable and I also took the prototype with me to a CoCreact! Workshop where I actually sketched making things happen’s value proposition, which is another story ;-). The first reaction of users to a product can be bitter medicine: you spent half a year developing something you thought they’d love and then it turns out they don’t exactly do so. Sweet time wasted. But wait - I did not spend such a ridiculous amount of time before confronting myself with a first feedback, did I? First user feedback & the first reactions too are always a surprise. Sometimes rather small suprises. Sometimes they are of epic dimension. In our case the first reactions are solid fun. Turns out confronting the value proposition with The Reality™ proved it wrong. The reactions showed people were interested in this object - but delight was yet to be added. The rate of change of the colors made it more appealing for a chilled, snoozy room like setting. Which is cool unless you’re briefed to open an event with a big bang of attention. In this situation you can either persevere - stay on course - or pivot - change the direction you’re moving. Basically the element of sentiment represenation proved itself quite handy. Persevere. But the way I represented it needed a little pivot. Or perhaps even a huge one ;-). Sometimes you have to pivot hard: hacked Vinyl Killer Quite out of the blue I started collaborating with my partner in crime Jeremy who told me about this toy his kids played with - a little plastic VW bulli that drives around a record using an integrated needle and speakers to actually play the vinyl it moves on. “What’s it called?” “It’s a Vinyl Killer”. You could tell it by the look on my face: we found our new direction: a Vinyl Killer playing a record in different speeds according to the mood of an event’s twitter stream was the way to go. Missing Link I prototyped the missing links: regulating the voltage of the toy via our online Arduino devices and adjusting the software to ditch neutral moods - how boring anyways. The first users’ reactions were more than promising. A quick check against the initial value proposition “Delighting the attendees of an event for the time of their visit” made me finally say: value proposition validated! It’s proved itself fun, easy to understand and just the show act the event organizers had in mind for its starting event. Minimum Viable Product ready for action. You can have a look at this video from the event to see how it went :-). On the bottom line please keep in mind: when developing basically anything - the lean entrepreneurship (aka lean startup) approach makes you flexible enough to respond to user feedback & more important the behaviour of people using your product. Be it software, hardware or conceptual / strategic work: moving fast in slow steps reduces risks and maximizes your chances of success by making you - lean actually.
The first serious Internet of Things project I worked on was the digital foosball table I prototyped for Sinner Schrader’s Radical Innovation Lab. An interesting detail that you might not have guessed: I only built the software. A slim little Ruby API & attached to a realtime web app and to the Arduino hardware. The hardware was built by one of my all time favorite colleagues Thomas Jacob. I admired the hardware skills he had and didn’t dare to dream of developing something similar on my own. I was only a software guy, right? First working prototype in action, check wired for details. <!-- more -->Right, but: Arduino is perfect to get into the subject of hardware hacking. Although I’ll never reach Thomas level of craftsmanship in general I was able to build hardware that connects itself to the internet pretty fast. The first prototype was just a breadboard with a switch that could light an led on the other side of the world. Or in my case: on the other side of the breadboard. The following projects I did all had two things in common: a lean development approach and a variation of the API and wireless hardware shields in various forms. These experiences lead to the Rat Pack Remote Control Workshops that we offer. Aimed at software people who want to see their Arduino projects talk to eacht other via a wireless internet connection. Some wires attached to a few lines of code: the Rat Pack. When I was asked to talk about the Rat Pack device at Codemotion I was glad to offer a talk on the subject. I used it as an opportunity to distill all the previous versions to a handy package that acts as a basic building block for the IoT: the Rat Pack Repo that describes what’s necessary to built a little IoT project using Arduino Uno & Sparkfun’s Wifly Shield. The idea is: use this little example that enables you to make an LED light up globally by pressing a button locally to connect almost anything to the internet. Almost Anything? For example the wearable computing projects that where done at the great workshop Kobakant did in cooperation with Zoe Romano to open Codemotion. Jule weaving in some electronic life into fabrics. Jule and me participated, but my initial intention to develop my conductive thread sewing skills further was a little distracted: inspiration struck me. I realized I could adjust the Rat Pack using the Xbee Breakout Lilypad to attach the Xbee Wifly that slumbered in my toolbox. I managed to do so and the adjusted code is part of the Rat Pack Repo on github now. The fritzing sketch has still to be done - I hope to see some Open Source / Open Hardware contribution love happening there soon ;-). When inspiration strikes… (source: Arduino) The workshop was quite exciting already. When I did my talk I was even more excited by all the interest in the subject and even more by the very communicative and open crowd. Breaking the first rule of live demo over and over again. So many people getting in touch with me after the talk, during the day & during the following days isn’t really symptomatic for a german tech event. I really enjoyed the multi cultural, international and open vibe and took quite some inspiration with me. I hope I was of any help to the crowd too. If you missed the talk you can get a glimpse how it was by checking the slides: Rat Pack Remote Control - an Internet Of Things ™ primer I was glad to do some client work in Berlin the next couple of days - which I’m also quite exctied about currently but that would be a little off topic here. I used the drive & the new encounters of the weekend to connect myself a little in this pulsating city. From the amazing Knowable crew who are about to built a github for makers - which will make my life much easier - over the very inspiring lunch breaks to the visit at the Berlin Fab Lab - where I also ran into Kobakant’s Hanna - this week in Berlin was really packed with inspiration and new encounters. I’m on my way back to Hamburg right now which I miss pretty much. I will miss Berlin too I guess, looking forward to see you again soon! I’d also love to see some reports of actual IoT projects built on the Rat Pack example. I’d love to see some open source contributions aka pull requests to improve it even more. Curious where this project will lead to!
We are in the middle of an energetic scene: groups of two are presenting each other prototyped solutions for problems you can have when planning a vacation. Concentrated listening, questions and answers. Feedback loop in full effect. But how could it come to this? The power of the back of the napkin (Photo by @cuxdu) Like many good stories it all begins with a cliché<!-- more -->: agile conference, evening get together at the bar, two agilists, one napkin and a pen. While discussing the similarities between one core principle of strategicplay and the product development approach of the accelerated feedback loop it became obvious to us that the creative problem solving approach of “diverge & converge” approach is also part of the quantifeid learning when applying lean startup techniques. All of a sudden Katrin aka @cuxdu stated that we should prototype a workshop around the idea of, well, rapid prototyping. Assisted by strategic play. We sketched the topics that had to be covered and a rough timeline. Could probably work, let’s see if we still like the idea tomorrow morning before Play 4 Agile’s session planning. Which we did, so there we are right in the middle of a group of people that is really amazing to facilitate. Find problems, let your partner group pick one to solve. Prototype a solution, get feedback by showing it to your target group on the other side of the table. Ditch your solution strategy because it didn’t work or enhance the solution that hit a nerve to make it even more appealing. Pivot or persevere. Rinse and repeat. Prototyping with Lego or Paper & Pencil - anything goes. Amazingly we see almost all theoretic arguments in favor of rapid prototyping happening in the workshop: failing fast saves you budget - in this case time - to adapt to the misunderstood customer demand. If you pleased your customer with your solution you start working on putting smiles on their faces by continuing to steer in the direction you chose. The build-measure-learn loops are accelerated by the decreasing timebox sizes Katrin & me set. One pair of groups even accellerates beyond these boundaries by having several increments in a single timebox - quite astonishing! I think I will offer this workshop at the next open space I participate in to iterate it a little. One success factor here is the mix of people: agilists have the matching feedback and failure culture by default. Another one is the amazing atmosphere at the conference itself that just inspires you. Perhaps the amazing results we saw were caused by the opening day’s facilitation technique to get everyboy’s mind in a creative state: three people putting some stress on the left and right brain half for 20 seconds until you reached a state of an open mind indicated by glowing eyes. I think I was yelled at for a little longer by the way ;-). The same observation could be made at the hacktable we organized. It’s an open format where you meet and bring things or topics with you that you want to hack on in a group. Hacktable with Raspberry Pi & Lego case. Coincidence? Our friends at humanist lab hosted the event - we provided hacked tables out of spare desk materials for the hacktable which is quite poetic I guess ;-). The result were the same glowing eyes I saw after the brain massage at the beginning of Play 4 Agile. Shining eyes & open minds - post hacktable talks. What does this mean for the mentioned workshop? I’ll continue working on it in surroundings where the eyes start glowing on their own like a hacktable or an open space unconference. Our agile colleagues at ScrumCenter are using the format via a Creative Commons (CC-BY-SA) license for their lean startup product owner certification and as you may imagine I am more than curious about their experience. In addition I want to let the format prove itself in not so matching surroundings where the mindset of the people perhaps isn’t too much biased towards an open failure and feedback culture to see how much work is to put in getting people into the mood for an accelerated feedback loop. If you are interested in hosting this workshop yourself or with my facilitation go ahead and get in touch. I’m curious how the idea will develop and try to keep you posted!
One of the first things I tell potential clients that hire me for an agile transformation is that part of my goals is to make myself superfluous. Although more or less common sense for people with an agile background this provokes more often than never puzzled faces. “Isn’t he supposed to lead the product development process by managing the product team with agile methodologies?” Transforming intangible perceptions into actionable items In fact I’m supposed to enable the product development team to start managing itself in an agile manner. Reads itself like a minor difference in the formulation, but has a major impact on the proceeding. <!-- more -->Of course I start leading & managing the team. Introduce the necessary events, evolve daily stand-ups to short & precise meetings, get everybody on the same page and facilitate the retrospectives. Apart from the latter, a fully developed agile team is able to answer the three magic daily questions and organize the events on its own. When it comes to retrospectives, it’s a little bit different. You need a neutral facilitator here a little longer. For my last client this meant that after the time intensive initial phase of coaching I stopped attending on a daily basis after we both felt comfortable with it. I continued to facilitate the retrospectives for some more weeks, and after we tried and saw that there are still action items and the resulting improvements as tangible outcomes I realized I brought that team to the agile path and futhermore to a state in which it could walk this way without further assistance. Short & direct feedback. <3. Tangible outcomes are amongst the core metrics I am judged by. In the beginning the effects of the new process are still very intangible. “We like that we now communicate more with each other, but we are affraid losing our efficiency!”. When moving from batch processing your specialized task to think a little cross functional this is a natural reaction to the change. Measured by the quantity of product features you deliver it in fact will look like losing efficiency. When judging by the quality of what you deliver the efficiency equation looks quite attractive. In fact after a short period of time the propelled quality becomes quite obvious - be it the lowered technical debts, the increased harmony of the team or the ability to react to customer wishes faster. As you may have realized I used the formulation “measure quantity” and “judge quality”. I did this on purpose since it stresses the very tangible nature of quantity and the more intangible way we perceive quality. In my retrospectives I’m quite strict about actionable items as a result. They make our progress tangible and I see them as a basic metric to measure the progress we make. In fact I put a little square on every action item sticky and we check this box if we accomplished the task in the next retrospective. This is just a small example of validated learning. Which is one of the aspects in the focus of lean entrepreneurship. It is about learning based on the data you collect from your product and finding the right metrics to measure the value and the growth of it. Which is why I see Agile & lean entrepreneurship as a synergy of greatest potential. Participating in the 2012 Agile Design Camp I bootstrapped some provocative slides to bring the audience into the mood for discussing the topic. The core hypothesis here is that agile focusses on the process success while lean entrepreneurship focusses on the product success: ‘Agile vs Lean’ on Slideshare Of course this is only true to some extent. When working in agile environments the chance of meeting practicioners that do not only think in terms of their special subject but also have the product in their vision is quite high. When iterating over your processes lean entrepreneurial thinking as a result can be an outcome quite naturally. This is a result of the fact that the right process framework takes away unnecessary pressure from your team. This enables the practicioeners to actually think about what they build as opposed to being busy with figuring out how to finish tasks in time. I would say this is similar to moving up on the Maslov pyramid - just in the domain of your product quality and not concerning personal life’s quality where Maslov’s famous geometric metaphor is originally pointed at. To quantify if our newly gained freedom actually results in higher value for the customer moving from judging prodcut quality to measuring product quality is essential. One way to achieve this goal is the path of lean entrepreneurship. Viewing from that angle I think it becomes quote obvious why I chose the provocative hypothesis that agile focusses on the process success while lean entrepreneurship focusses on the product success.
Transforming an existing and effective product team with its own existing processes into an even more effective SCRUM team is quite a challenging task. You need to get to know both people and organization and see how you spread agile values amongst both best. In a current client’s assignment we reached a point where the process is learned and the values & mindest widely settled. Now the risk of boring the team with repeating facilitation techniques is high, which is a luxury problem I am quite glad to face ;-). Finishing the preparations for todays retrospective I started retrospect the state of making things happen a little. Starting my own business this february was quite a ride. I was lucky to have a product vision ready for my venture - Strategic Play helped developing it in an awesome CoCreAct workshop. With some local companies waiting for me to work for them the biggest challenge was the bureaucratic means necessary to go into business. Since then my concept of offering both Process Coaching and Application Development - knock on wood - works out quite nice. I sometimes need to explain how I am able to offer both, but that’s another story. Finding my own product vision (image: 5v3n.com) <!-- more --> One challenge you face working as a contractor is the not too surprising fact that no start up or company hires you because she wants you to learn something new from her. Most of the time she searches someone to teach her something new from your portfolio instead. Of course every project makes you learn and adds useful skills to your agile or tech tool belt. But if you really want to advance or even pivot a little you have to invest the time in your own learning. One important aspect of my approach to learning is inspiration. There are inspiring people in my surrounding already. A place to maximize the specific inspirational density nonetheless are barcamps and community events. During the last quarter there were two very special events of this kind where I found loads of inspiration. The first one was the UX Camp Hamburg. Being asked to talk about UX concerning the infamous Internet of Things beforehand was awesome - I wrote about my experience from the Maker’s perspective at Makers & Co already. In addition I did not hesitate to put a spontaneous session called “UX & Agile” on the planning board. Knowing your audience is key to preparing a talk. Since I didn’t know anything about them and had to open the event with the first talk I just improvised a little. I used a flipchart, pens and the biggest track room full with a lot of curious people. Went quite well I’d say since there were lots of questions. Opening UX Camp Hamburg with “UX & Agile” (image: twitter.com/suzhi) I felt we had a real nice conversation going on and I scribbled a lot of pages with viualisations of agile metaphors since that’s the way I explain best. I even received some friendly coverage, i.e, from Hamburg’s Digital Media Women so I think I pleased the audience. Being asked to repeat both sessions in the afternoon was quite reassuring too. Having paid my barcamp dues with leading two sessions myself I enjoyed visiting some sessions without a bad conscience. The main topic UX is quite self evident working in (or being brought in to establish) lean and agile contexts. Seeing the different approaches how to include it in classic project setups and the pains you have there was quite interesting. Amongst the sessions I enjoyed the most were “Lean UX” where Karen Lindemann gave a brief overview of the way Thoughtworks is integrating strategies to focus more on UX in their agile & lean workflow. Karen on Thoughtwork’s approach: “Lean UX”(image: twitter.com/gabormolnar) Chatting with the participants was very inspiring too - all in all a saturday spent more than well. The other event that stood out was Railsgirls Hamburg. I guess you are asking yourself the question why I list an event where I coached people without any experience in Web App Development at all amongst the events I learned from most. Let me elaborate. Concentrated learners (image: 500px) Designing web applications these days we talk a lot about the infamous “Embrace Constrains” paradigm. It basically says: “By constraining your product you will see the core of your product” and is applied concerning mobile vs. desktop browser, small vs. tall budget and so on. What I found out at Railsgirls by embracing the skill constratint is what’s in the core of my way to drive product development. We had some tutorials we should go through which I adjusted a little by adding IxD skribbling up front. Then this picture basically sums it up: Skribble - Implement - Ship! (image: EyeEm) It all burned down to: “Skribble - Implement - Ship!” Then check the result, rinse & repeat. Of course we left out the Product Visioning here, but basically this is what it’s all about. Plan, Do, Check, Act as Deming would have put it. So besides being a great idea in general and the coaching being a real pleasure I also learned a lot. What comes after the inspiration is choosing the topics worth further persuasion. I developed the habit of starting spare time projects to learn new technical skills preferably in teams of fellow knowledge & experience seekers. On the process side I read quite a lot in the past but the best way to sharpen my existing skills or learn new ones is learning by doing as well. Ok - so why is this post called “Hello World!”? It’s a test balloon to see if what I write about my experiences is of any interest to you. So please go ahead and tell me. Share the post, give me feedback or even better: tell us about your tactics in the field of knowledge acquisition. I am curious!