Kanban Check – A daily overview of Kanban

It’s pretty tough looking after 9 projects, a lot of things to keep an eye on. It’s even harder when some of the projects use a totally different process to the others. We are a Scrum shop, we follow the scrum process – mostly. Recently a few of our projects started to use Kanban, which is a learning experience.

Keeping an eye on 9 Scrum projects is made easier by the Scrum Check that Gwyn put together. A simple checklist of things to look for each day on each project. The idea is that as it’s so easy to miss things that are not there, but should be, write out a list of what should set up, and check it each day. That way if I forget to send out invites to the next demo (for example), it turns up in the Scrum Check.

Kanban is a different process, which leads to the question of what things should I be looking for, on a day to day basis, to give me an early warning is the process is derailing.

At a first iteration, I have the following checks, (if the answer to any question is no, then thats a sign something might be wrong, and I need to investigate)

Daily Checks

  1. Can I see the Kanban Board?
  2. Has it changed since yesterday?
  3. Are any of the columns empty?
  4. Are all of the columns under the WIP limit?
  5. Do the columns actually describe the flow of work?
  6. Are all stories unblocked (by a definition relavent to that column)?

Weekly Checks

  1. Is there a demo booked in the near future?
  2. Does the client/product owner know how quickly stories are progressing though the board? (The cycle time)
  3. If there is a deadline, do we know what stories need to be done?
  4. Does the recent cycle time predict the stories for the deadline will be done on time?
This checklist is a work in progress. I’m going to be using it on the Kanban projects I can see in the next few weeks. But in the meantime if you disagree with anything, or think I’m missing something, tell me about it below – all comments welcome on this one!
By |September 26th, 2011|Entrepreneurial|3 Comments

Creating a webapp is creating a startup

Graph with stack of coins

Photo: teegardin

Do you think of writing a webapp in similar terms to creating a startup? I think that they are in very similar. Let me explain to you why, and see if you agree.

I’ve been building and coding webapps for many years now. I have experience of working in a startup that went bust, and I have experienced working as a consultant helping other businesses create their webapps from first principles, as well as working for large corporations building large application. I have build several side projects, and tried running them as businesses, including my latest project, Frozen Event. So I think I have a pretty good range of experience to draw from to back up this argument.

What is a startup…

In order to explain what I mean, let me first explain what I mean when I say “startup”. I’m thinking of something different to what I suspect you are picturing right now. It’s not about being cash strapped, or working out of your parents basement. It’s more about trying to build a business. Building a way of doing work you can in some way sell.

But what does “Building a way of doing work” mean? If you think about any successful business. They know how they work. Anyone from McDonalds to the tailor who makes my dance trousers. They know how they greet a customer on first contact, how to market to them, and how to reliably deliver the product the customer wants. All of this together is “a way of doing work”.

Now think of a startup (it doesn’t matter what industry). They are figuring this out. They don’t yet know what marketing is going to work, what steps are needed to time and time again deliver a reliable product. This is the essence of a startup. They don’t yet know how they work. But they are in the process of figuring it out. Once they have figured it out, they are not longer a startup.

What does that have to do with webapps?

Can you say that the code is the most important part of any webapp you have launched? I can’t, in every example I can think of, the most important part is the way the user experiences the site (I’m not talking about UX, but what I would call concept design). It is also normally the hardest part to get right. Building a webapp for a clients lets me see this time and time again on a variety of different projects.

Typically we start off with an idea of what we want the site to achieve, maybe it’s to increase the number of phone calls to a bookings service, or encourage more sales for an e-commerce site. Sometime we will also have an idea of how to do it, but not always. As we build the site, we start to think about questions like “Does the user need to log in in order to do what we want them to do?”, “What happens after they take whatever action we are trying to get them to do”, and similar questions.

Let me give you an example. For Frozen Event (a site which allows photographers to sell photos) I’m considering some from of bulk discount. Something along the lines of if a user buys one photos the price is £2, 5 photos is £7 and 10 photos is £10. But there are several things I don’t know… What if a user buys 5 photos from one photographer, and 5 from a second photographer. The user is likely to expect to pay £10 for 10 photos, and each photographer is going to expect to receive £7 for selling 5 photos. It’s not immediatly clear how to resolve that.

The specific questions can vary a lot from site to site, and each one has to be considered on a case by case basis. However in the early stages, we don’t know how they work. At least not yet.

Can you see the analogy yet – how this is the same as a startup? We start of not yet knowing how it works. As we proceed into the project, it is a task exploration and discovery. Working out what it is we need to do, and how it needs to be done. There is no predefined set of steps to take, no map. Because if there were, then we would just be duplicating a system that already exists.

At least, that has been my experience of building webapps, it is also why its always interesting. Each new project brings a new set of questions, and a fresh set of chalenges to keep me fresh. If you have had a different experience or viewpoint I would love to hear it in the comments below.

By |September 10th, 2011|Entrepreneurial|0 Comments

Standing room only – a new use for Coke Cans

There are many things you can do with a Coke can or two, or 48 in this case. Olly decided to try a new lunchtime exercise…

We all know prototyping something is the best way to find out quickly if its a good idea, and it turns out it only takes 48 cans of coke  and a spare desk-top to convert a normal desk into a standing one…

 

Let me know if you have tried working with a standing desk

By |May 12th, 2011|Entrepreneurial|1 Comment

Getting stuck in Commitment Debt

I was inspired today by a post on Rachel Davies’ blog to write something that has been brewing in my mind for some time. So today I want to share with you the concept of commitment debt.

Towards the end of 2010, I tried mapping my own projects, work, social, personal etc, and fitting them onto a Kanban board. (If you don’t know what a Kanban board is, its not that important right now, you just need to know that its a way of visualising your current workload, so that you can see and visualise what unnecessary work you are doing. You can read more about using Kanban for personal productivity here)

What I discovered shocked me! The number of simultaneous things I had going on at once was about 25, and I was still accepting more!

I was in commitment debt!

I had taken on far more commitments than I was able to deliver. Just like financial or technical debt, it was slowing me down, preventing me from being able to choose what to do. It was even starting to get me down.

I had to go though each project, and work out which ones I could just cancel, on the spot, which ones I could postpose, which ones I was totally committed to and could not get out of.

Then for several months, I picked a project each week, and focused my spare time on it, and slowly starting to bring them to completion.

I then had to do the same to several projects that I had been able to postpose, but could not get out of.

Finally I was able to look at the projects I had been able to cancel. Most of them were no longer relevant. Some where never even a good idea in the first place! I can only assume I was taking them on to procrastinate on the commitments I already had!

So just like financial debt. I had to prioritise and start to repay the most serious debts first.

Is this something you have experience yourself, or seen in others? Have you found any good techniques for getting out of this problem, or spotting it before it becomes too serious? Let me know in the comments below

 

 

By |March 7th, 2011|Entrepreneurial|3 Comments

Alchemist Dreams of Liqueurs

Test tubes of liqueurs in a rackIts rare that I come across a new company doing something creative, doing it well, and making me think “wow! this is cool” so when I do, I feel I ought to shout about it…

In our office we just shared a round of handmade bespoke liqueurs, served from an old style Alchemsist test tubes. They were lovely!

You can get your own set, to liven up your party, or Friday afternoon in the office by heading over to www.alchemistdreams.co.uk

By |March 4th, 2011|Entrepreneurial|0 Comments

Lessons learned from writing and launching a WebApp in 23 days

Less than a week ago I launched HabitualApp. Given that my day job is creating webapps this isn’t something I would normally make a big deal of. However this site was different – I wrote it entirely on my own. That meant I had to do:

  • Concept Design (what is the app, why does it exsit)
  • Usability Design
  • Visual Design
  • Software Design
  • Styling (writing the css/html)
  • Programming
  • Marketing

I’m a big fan of cross functional teams, but the truth is normally there is quite a broad team behind an app, and its rare for one person to be able to do all of the above. To make things even more challenging, I had set myself the target of launching the site by the last day of 2010. That was just 23 days after I initially had the idea!

For a long time I have wanted to create a site, launch it as quickly as possible, and then grow it from there. This is something that not everyone is comfortable with; there are a lot of potential problems with launching a site before it is ready. So working on my own was the best way to have the freedom to do exactly what I wanted to do.

The sitehas been running for 6 days now, and its going pretty well. It has had over 1300  unique visitors, and over 90 users have signed up. It’s time I take a quick look back at what I leaned so far, and what I want to find out next.

Limiting the features let me launch early

The first thing was that writing a web app from scratch in less than 1 month is totally possible. I wasn’t particularly pressed for time, even though I did most of the work in evenings and lunch times (though I did manage a good bit of work during the holidays). The only way I could launch something in such a short time though was to be ruthless at cutting out features.

The login system piggybacks on Facebook, which was a great time saver, as well as giving several added features for free. I had a lot of ideas for features I wanted to add, (and still want to add) but I was pretty ruthless at cutting them down to the smallest set possible. This was necessary as I did the final bit of coding the day before launch (I wanted to have one day to reflect before hitting the big red button)

This was the hardest part. Ideas fell into three basic categories: Ones the app is unusable without, things the app would be dull and boring without, and those which are nice to have. Telling the difference between the last two categories is a difficult to get right and something I suspect I will get better at with time.

One example is that when you create a habit, it posts this to your Facebook account. Clearly the app is usable without this, but I decided to put it in anyway. I decided that the social aspect was an important part of the app, and without this, using the app would feel too much of a solitary experience. The same goes with the list of habits your friends have, which is shown when you log in.

A bit of knowledge on design theory goes a LONG way

I learned that I can do visual design! Ok, the site is not going to win any awards for being pretty, but I don’t think it’s going to end on anyone’s ugly list either. I spent some time teaching myself basic colour theory using sites likes worqx (opposing colours on the colour wheel look good together, etc.) before using an open source colour scheme and getting on with it.

I found it very useful to have a limited set of five colours, and some basic ideas on when to use them made a huge difference. I had three different shades of my main colour, with two highlight colours. I also used some ideas on column spacing as explained in the 960 grid system, which helped keep things feeling balanced.

Watching real users is invaluable

 

After the first couple of features were working I started getting friends to use the app while I watched. I started with other computer developers, and moved onto less technically skilled friends. At each point I managed to hold my frustration back (“Isn’t it OBVIOUS you click that button!”) instead noting where they were confused about what to do. After each session with a user I would spend some time improving the usability of where they were struggling the most. By the time I launched I was able to show a friend the site, and she could do all the main tasks with no prompting from me.

Design is iterative (both usability and visual design)

After 5 days or so I did the first pass at styling the app. I thought it looked pretty cool, till I looked at it again on day 6. Looking at it with fresh eyes made several things stand out and look ugly. The same was true with the usability of the site. Both designs were changed once or twice in a big way, and had a whole slew of little tweaks. The final design is quite different from the first one, but grew out of it. If I hadn’t actually done the first design, I would not have had the chance to develop it. The fact that design is iterative was new to me. I have often worked with designers who keep changing bits of pieces of the design. Now I have a much better feel for why they do it (of course, even their first drafts are better than anything I can do!)

Driving traffic to the app is harder than I thought

When I announced the app, I posted it on my twitter feed, and on my blog, and sat back hoping to see some people sign up. I figured I had enough followers and subscribers to get at least a few signups. Wrong. No-one signed up. Oops!

So I started pinging people directly, only one person really took the bait (and a few signed up to keep me happy). This was when I realised that getting traffic to the site was going to be harder that I thought. My ideas of just building an app and letting the traffic build up totally on its own was going to fail if no-one at all ever saw it.

I submitted the app to Facebook, which let me push the app out to my Facebook friends. Rather than spamming everyone, I decided to keep it targeted to those people whom I thought would be interested. I had to guess who that would be, so one thing I want to do for next time is get a pre-prepared list of who wants to know about my app launches (You can now sign up to get notified when I launch a new WebApp). This generated maybe three or four more sign-ups. Things were not looking great.

Then I got my first real break. My friend Haje wrote this post on Pixiq, and posted on his twitter account. Haje has quite a large following of photographers (which he earned by writing a lot of good content over several years) and was inspired to use daily habits to help people improve their photography. That provided a wave of users. I was able to get to a computer in time to add a photography habit to the list of recommended habits users see on first log-in, and that is still the most popular habit on the site.

My second break came from Lifehacker. They posted this article on habit forming, which I found via a twitter search on “habit” at the same time as I was told about it by one of the Facebook friends I had sent the app too. A good part of the article is very closely aligned with what my app does, so I didn’t feel at all bad about adding a comment mentioning the main difference and linking to my app. There was some confusion here as my comment didn’t appear at once. Turns out to prevent spammers they manually approve the first comment from each poster. So I had to wait several hours before my comment appeared. I suspect this is common on many popular sites that can generate a lot of traffic.

I was very lucky with both of these breaks; if neither of them had happened my app would be sitting about with nothing to do.

So now that I have a number of users I need to decide on my next steps. Some of them are engaging with the app, some are not. Of those that are, only a few are using it regularly, which is what I would term to be real engagement…

Getting user feedback is hard

When I talk to friends in person, a lot of them have ideas on what to add, and change. But only a few people have contacted me from the site. By email. The number one requested feature so far is to break the close coupling with Facebook. Initially I was worried about this, because I see facebook posts as a good way to let people know about the app. I’m only willing to do this because its also IMHO a very useful feature of the app, however it seems that only 110 or so of my visits came from Facebook, so I expect that to be the next thing I do.

From all of this, I have created a checklist of ideas that I want to take forward into my next app.

  1. Build something quickly, even if it looks bad
  2. Set a launch date in advance. More than anything else, that helped me keep the feature count low
  3. Allow some time for tinkering with it, tweaking the design and the UI based on feedback
  4. Have some better ideas on how to spread word about the app. Luck won’t happen every time
By |January 7th, 2011|Entrepreneurial|8 Comments

HabitualApp: Making Habits that Stick

Today I am launching HabitualApp, a free webapp for tracking thirty day trial habits. You can find it here, and follow it on twitter, @habitualapp

It’s the time of year for new year’s resolutions, and thirty day trials are a great technique for making resolutions succeed. They can be used to:

  • Change existing behaviours, such as go to bed earlier,
  • Add new behaviours, like eat more fruit,
  • Remove unwanted behaviours, like giving up smoking.

You pick an action to do, or not do, every day, and then do (or don’t do) it every day for thirty days. Since thirty days is a managable amount of time, and one action is also managable, the idea is that it is easy to stick with. However you only consider the trial a success if you do thirty days in a row, with no exceptions. If you miss a day, then you restart from day one!

Each day that you do whatever it is you have decided to do, you mark it on a calendar. Once three or four days are marked, the psychological drive to not waste those good days by having to start again kicks in. That helps keep the motivation going, until the end of the trial.

Habitual shows you this calendar, and lets you mark which days you have done. Just type in the name of the new habit, and a new calenar will be created for it, as well as a post made to your Facebook account, so your friends can see what you are doing (and hopefully be supportive).

Login is done entirely through Facebook, so you need to have a Facebook account to use it. This is something of an experiment, and if it takes off I may add Twitter, Google and general OpenID login. I will have to see how things progress.

Here are a couple of links if you want to read more about the idea of the thirty day trial:

By |December 31st, 2010|Entrepreneurial|10 Comments

Preparing and Rehearsing a Talk

My colleague Gwyn and I have just returned from Krakow, Poland, where we gave our Sword of Integration talk. It was the best presentation we have given so far, both in terms of how well we feel we delivered it, and the feedback we got from the audience. So I wanted to share with you some of the ideas and techniques that we used to create, and rehearse the presentation.

Gwyn did the initial talk in 2008 at the London XP day (I was unable to attend) as a 5 minute lighting talk. He showed how to create an integration token from paper in under 5 minutes. This got good reception, and Rachael Davis asked to use the idea of the sword in her upcoming book on Agile coaching.

This gave us the idea that there was something here worth building into a full talk. The first thing we decide was that the presentation was going to be fun. Fun to give, and fun to listen to. This meant it had to include making the sword as part of the presentation, and what could be more fun than a full sword fight, live on stage?

From here it was a simple matter of finding a general theme: “Low tech practices to extend agile” and collecting as many of the things we had learned that fit into this theme, and building short acting sketches round each of them.

We ran the acting sketches initially as improv sketches between the two of us, then refined them to tell a story. We both have experience of performance arts (Gwyn has done improvisation comedy, and I have a background of acting school and dance performances), so we were both used to the idea of rehearsals, and of adapting things on the fly.

Then we ran the presentation several times back in London, once just to ourselves, and once to the rest of the company, to see if they liked it.

The talk also contains a few mini lecture parts. We have a lot of conversations about how to present these. Stories work best. I like to think of a real example where the subject I’m talking about came up, and tell it in the form of a story. A beginning, a middle and an end.

The final part, which we do every time we run the presentation, is to do a full rehearsal of all the acting parts. We either do this the night before, or in the final few hours before the talk. In Poland we did both. This serves three purposes. It caches the material in short term memory, it reminds each of us of the cues we have for when to start talking, and it builds trust between us that we remember our parts. For me rehearsals are also a time to make all the mistakes :-)

Finally we script the very beginning of the talk. This means that there is little chance of getting stage fright in the first few minutes – or until the initial rush of adrenaline has passed.

Now we have done the talk together several times. We are building up a good understanding and trust. We both know each others parts, so if we one of us starts to falter, the other can jump in. The best bit is that the audience doesn’t know who was meant to say what, and so doesn’t suffer.

The best part of giving a talk that the audience likes so much is the feedback. The feedback we got this time was amazing. I had a wonderful warm feeling reading the positive comments on twitter afterwards, and we have been invited to present the talk in Bucharest and Kiev.

By |April 13th, 2010|Entrepreneurial|2 Comments

Practice daily tactical decision making

You want to be successful

I don’t know what you want to do with your day, week or life. However I am sure that whatever it is, you want to be successful at it. The best way to achieve this is not to obsess on strategy, but to practice making tactical decisions.

Stategy and Tactics

Most advice talks about setting a big picture, and using this to drive the day to day decisions in the right direction. I will follow a common terminology of calling the big picture strategy

  • What market is the business going to target?
  • What properties in monopoly will a player buy?
  • Which major sports competitions will an athlete target this year?

and the day to day details tactics:

  • Hiring the great programmer for your development team.
  • A chess player captures an unguarded pawn.
  • An athlete has a good brakefast before a major event.

Strategic thinking is long term. It looks at the general shape a project. Tactical thinking is short term. It  takes advantage of an opportunity that will not last (and may not have been planned for)

Traditional Advice

Get the strategic thinking sorted, then work on a tactical implementation.  It will be clear which tactical opportunities to chase, and which to ignore.

This is true as far as it goes.

It’s (reasonably) easy to get strategy right. There is one strategy and plenty of time to think about it, and to refine it. While there are examples of bad strategies, (Microsoft ignoring the internet) most of the time, a strategy is sound.

It’s also reasonably easy to make good Tactical decisions, but also easy to get tactics wrong. Due to their short term nature, there is less time to think making it easy to not spot a problem. On deeper reflection it may turn out to not align with your strategy, or be a blunder.

Having a good strategy is of no use if it is supported by poor tactical decisions. Bad tactical decisions are as risky as a bad strategy, but far more common.

Improve Tactical Decision Making

With this in mind, it makes sense to work on how to reliably make good tactical decision. To help you, here is a simple checklist you can start with:

  1. Is there a critical need to respond to an external events in order to prevent damage?
  2. Is there an unlooked for opportunity available right now?
  3. Is there an opertunity created by the strategy that can be cached in now?
  4. What is the best move to further the strategy?

But the best way to improve tactical decision making is simple. Practice, and lots of it. The context doesn’t matter. Business, games, sports, holidays. Be aware whenever a tactical decision is taken. Afterwards assess the decision, was it good or bad? If it was bad, what would have been better? No doubt many will turn out to be bad. But with practice, the number of bad decisions will drop.

Does this work?

In a word, yes.

In Rapid Chess Improvement,  Michael de la Maza points out that even at high level of chess, games are not won by superior strategy, but lost due to tactical blunders. By developing a training system based on increasing his tactical analysis his ranking increased four times more than was commonly accepted as possible.

In 2008 at the Beijing olympics, Usain Bolt  broke the world 100m spint record. In interview afterwards he admitting to eating, not a sensible breakfast, but chicken nuggets. Further interviews revealed that he was unsure how he would react to the local Chinese food, so he tactically chose to eat food he knew would not upset his digestion.

Always practicing

There are always more tactical decisions waiting, and there is always room for improvement. While there may be no magical formula that will always produce the strongest tactical decision, the pursuit for improvement is one that is satisfying, and where continuing improvements are clearly visible.

By |February 18th, 2010|Entrepreneurial|0 Comments

Chain of Fools

What do you do when you have one person who is the repository of knowledge for a critical part of your project, infrastructure or similar.

You need some way to address this situation, otherwise that poor person will go mad dealing with other peoples problems, never feel free to go on holiday, and if they get hit by a bus you really are in trouble.

Steven Williamson at youDevise told me a cool technique they use to fix this problem, they use Horace. Horace in this case referred to a stuffed toy. A woolly mammoth to be precise.

The one guy who knows everything about, for example the CI system, gives Horace to someone. He gives it to someone who does not know anything about the CI system, a “fool”, who while intelligent, has no knowledge of this CI system works.

This person is now the only person people can ask for help. When the CI system stops running your tests, you have to to ask whoever has Horace. Of course, they don’t know the answer, and so have to ask the guy who gave them Horace. The expert.

After this happens a few times, a change occurs. From time to time, you ask the guy with Horace, and he already knows the answer. Its the same problem he got asked two days ago, and he learnt the answer then. He didn’t have to go and ask the original source of all knowledge. He is learning.

Fast forward a bit more, and he is now answering most questions without having to ask the original guy. He has leant most of what he needs to know to fix the CI system. Its time to extend the chain.

He selects a new “fool”. Someone new, with no knowledge of how the CI system works, and gives him a present. He gives him Horace. Now the new fool gets asked all the questions. When he doesn’t know the answer, he asks the guy who gave him Horace. If he doesn’t know, he can ask the expert.  A chain is formed. You can only get help from the person who gave you Horace, forcing the knowledge to be passed about the company.

By constantly adding a new link the the chain of fools, you slowly, but surely change it into a chain of experts.

By |December 10th, 2009|Entrepreneurial|0 Comments