Lean Agile approaches

Two years on kanban

2011-09-30T10:37:00.000+01:00

Having used kanban as a catalyst for continual improvement I feel more capable, confident and way more productive than I have ever been in my life. Starting with a simple plan-doing-done approach to my kanban boards, I quickly evolved them to meet the needs of particular situations.

I have created many kanban style boards for managing specific areas of my life, such as my own career and skills development, moving house, preparing for 400km cycle rides and starting my own company. Kanban really helped me pull in and evaluate other ideas to build on how I work and help me become more effective.

Kanban is not a solution or silver bullet in itself, but this simple to use techniques allow you to develop an effective way to manage, to help you get things done!

Lean practices, system thinking and theory of constraints all kick-started a big change and kanban was the technique that made it all come together. By encouraging me to look at what I was doing and how I was doing it, I had an every growing focus on how to deliver value to myself and to others. I could no longer hide so easily from the truth and tell myself little white lies about a situation, the information on the kanban board kept me honest and encouraged me to evaluate my actions.

Awareness
Just being aware of your circumstances is a major advancement for most individuals and organisations. It is all to easy for us to get too wrapped up in today's deadline without thinking of other concerns (such as if todays deadline is actually of value and if you are doing the right thing to maximise that value).

Managing myself

It is often so much easier managing and advising other people than it is to manage yourself. This is perhaps in part why CxO roles have personal assistance - a service that we could all use to help us focus. As a consultant I feel that psychologically it is much easier to work with a customer to help them improve than it is to help myself improve. Part of that ease is the excitement of learning something new and part is that I am working with someone else.

Through personal kanban and associated lean techniques I have found my own way to manage myself effectively without adding any sense of burdon. Psychologically, I now rarely find it a chore to manage myself as I can easily balance the time I spend being creative with the time I need to focus and deliver value. I can make lots of small decisions throughout the day as to what I need to do to meet my goals, giving a great deal of flexibility.

I can also quickly see what I have achieve and this gives a great boost as when we are busy we often forget the great things we have achieved that day.

Managing others
No one likes to be micro-managed and all good managers dont actually like to micro-manage people. So kanban can be used to focus groups of people (eg. project teams if you use them) towards a particular goal or business vision. Kanban allows the group to not only be a part of the decision process of how to achieve these goals, but also visualise how effective those decisions are with respect to those goals.

At any time, if there is a valuable reason the decisions taken previously could be changes or adapted to move with wider changes in the organisation.

I feel that kanban can be used to help drive progress towards goals very effectively, leading to real management by everyone, or as I like to call it - leadership.

Getting people to help - collaborative delegation
Kanban is a technique that shows real strength when it encourages people to collaborate and I have experience of kanban being a trigger to help cultural change. By encouraging people to get involved, to use the knowledge and experiences to the full, to challenge them and make them much more responsible for the work they do really drives a sense of meaning within them.

There is no need for motivational posters when people love the work they do, the way they work and know that the are delivering real value to the organisation every day. People like to feel part of something bigger and get a kick from helping other

In Summary
Kanban is a great technique once you understand its context, and used with lean and kaizen ideas it is one of those things that really reflects what you put into it. Like any good relationship, if you care about your kanban board it will care for you in return.

Physical boards with distributed teams

2011-04-25T15:37:00.000+01:00

For a physical board with distributed teams, here are some things I done successfully

Have a board buddy
Someone local is a "buddy" for someone distributed. So when the person they buddy with in the distributed team does something, they update the board for them. This has an added bonus that there is more interaction and communication between the team members, especially if you change buddies every week or iteration.

Webcam pointing at the board
The distributed team (and anyone working from home) can see the board status and activity by looking at the webcam feed.

Some ideas I am experimenting with include

Large touch screen devices
Using an online board with a large touch screen device gives a slice of both physical and online board. Using the touch screen you can move cards around the board giving you that psychological experience of interacting directly with the board. At the same time, the board is capturing information about your activities which can be used for feedback and status updates.

With the touch screen, you could also interact with the board in the same way as a physical board, by adding new cards, adding graphical artefacts to the board - such as a "help wanted" icon, updating who is working on which card and most other ways you would interact with a physical board. You could also interact with the scheduling of the cards, by the online board having a slider for priority or T-Shirt size.

As the board is also online, then someone can also update the board using their PC or tablet. This enables anyone to remotely access the board at any time.

Continual improvement - continual value delivery

2011-03-23T09:07:00.000Z

There is a real challenge to improve the way you work whilst still retaining and increasing the amount of value you can deliver to your organisation.

The more people have the opportunity to step back and consider how they "get things done" the more opportunity there is for improvement. It is tragic that most people are of the mindset that they are too busy to consider how they work as they have deadlines, this mindset is often driven by the system that is the organisation.

Until you can step back and really understand the work you have little appreciation of the wasteful activities you do and therefore can really only "solutionise". Anything you that is not based on some "fact finding" seems little more than guess work or just following a trend and hoping for the best.

Smallest Responsible Change (was Minimal responsible feature)

2011-03-19T12:10:00.002Z

Whilst discussing the merits of Behaviour Driven Development at one of the XTC gatherings, I started using the term minimal responsible feature as a way to express how to decide what piece of work to tackle next. I promised Liz Keogh many moons ago that I would write a blog post about it.

In the time it has taken me to write this post (its been kicking around in my backlog for a while) I have evolved my thinking on the term and now prefer to use smallest responsible change (SRC).

The smallest responsible name was triggered by looking at the term minimal marketable feature (MMF), considering what that term expressed and the values that I associated with it. I still like the MMF term as a more specific way of expressing a similar concept. With the smallest responsible change I have a term that I am happy to use in a wide range of contexts which helps promote discussion on how to be effective and make value flow.

Smallest responsible change is a nice general expression of how I like to tackle the work I do, so that the work flows more smoothly and I get more done. Creating a very effective way of turning large body of work into a series of value deliveries.

Smallest
I try where ever to tackle a series of smaller tasks that one big task. This approach tends to earlier feedback from the results of that work.

For example, when writing some new functionality, I will pick out a single piece of behaviour from the requirements (user story, use case) and express that behaviour in a scenario / example (a.k.a acceptance test / unit test). Once the behaviour is defined and implemented by code, I am already getting feedback on the work I am doing. Any feedback from running the behaviour scenarios (a.k.a tests) I receive shapes the next task. If a failing test still fails, I know I need to work on the implementation code. If a passing test now fails, I know I have to look at the code and design and maybe refactor.

Responsible
What does it mean to be responsible? You ask ten people you will get 10 different answers. This is not surprising as our experiences and feelings about a situation come from a unique history - our life to date.

The decision on what is a responsible action to take is therefore based on our current circumstances and our previous history, with hopefully a good dash of holistic thinking.

To be able to define and select the next most responsible action to take therefore requires you to think about your circumstances and base your actions on achieving value.

For example, if you a person next to you collapsed it may be the most responsible thing to try and give them immediate attention if you had basic first aid training. If you had no first aid training, then a cry for help may be the most responsible thing. If there is no one around, then a call to the emergency services may be the most responsible thing to do.

In software development, if you submit code that breaks the build and the build bunny shames you, it could be the most responsible thing to roll back you code. It could equally be the most responsible thing to call over some of your team and ask them what is going on (someone may have forgotten to tell you about an API change). It could also be possible that this issue is always happening with the team and you suggest the team get together and find the root cause to the problem.

Change
Change is happening all the time around us and we need to manage and filter all those changes so we can actually move forward (without a break down).

If you consider the way the brain works with the eye, the eye captures a constant stream of change so the brain has to filter out and focus on just what is important. If it were not for this filtering effect our brain would be overwhelmed.

It is important to limit the amount of change we are dealing with at any moment in time, so the changes are experienced at the rate we can acceptance and deal with them. It may be seen as heroic to work 12 hours a day and multi-task like crazy, but that is less likely to deliver significant value to your company than if you work at a pace you can sustain. If we can find a way to filter out changes (tasks) that are of no value at this time, then we can really focus on those few changes that have real value.

Example from a personal development context
If I want to read a book, what is the smallest responsible change I can do. Well, I often define a card on my kanban board to define the value I believe I will get from reading the book and some idea of how to attain and check that I gained that value (or perhaps see if there was anything else I gained). This is the smallest thing I can do and it is probably the most responsible thing to do as well.

Part of this first smallest responsible change may be to decide how to read the book and I have a common approach of reading chapter by chapter and also treating the book as if I were reviewing it for others. So the next smallest responsible change would be to read the first chapter and start to write down my impression of the book and anything important I had learnt.

The feedback from reading the first chapter may be that I think the book has mislead me about the value I would gain and I would therefore abandon reading any further. This feedback would then save me much time in the future, as not only would I skip read the rest of the book but I would have a reason as to why I dont want to try read the book at a later date.

If I tried to do this with several books at the same time, increasing the amount of change I was dealing with, there would be a lot of context switching between the information in each book, even more so if the books were on different topics. I would have to unload and reload different ideas from each book as I switched over. It would be very easy to mix my impressions and feedback from one book with another and hence make an incorrect value judgement.

Whats in a name - Lean Agile machine

2011-03-19T11:04:00.000Z

I chose the name lean agile machine for this website and my company in part as a parody on the term lean mean machine. I was looking for something that expressed the concepts I was interested in at the time lean system thinking and agile software development.

I try approach everything in a lean manner, by focusing on those tasks that provide the most value and guide me towards my goals. Goals are set in terms of my own direction but also along the lines of reciprocity, aiming to deliver as much value to my clients and to colleagues I work with.

The agile aspects of my approach get people involved as they are best placed to achieve goals when they are empowered and are allowed to define and carry out meaningful work.

These two practices combine to drive much of the social interaction of my life (work, play, cycling, etc) and help me define my values and goals in life. They also just happen to be useful approaches to sofware development and IT in general, which is lucky as that is the world in which I mainly work in.

Lean and agile principles provide many practices to help shape the effectiveness of the services I provide to a customer or employer. To me, delivering a software solution is a concequence of social interaction and understanding generated with clients and colleagues. The actual goal being to build relationships that are productive and help those people involved reach there respective goals - whether that be a big house in the country - married with children - a global traveller - a successful and sustainable business.

Kanban games night

2011-03-04T13:48:00.002Z

Karl Scotland and I will be running a free games night at Skills Matter on the evening of 7th March at SkilsMatter - London, UK.

Karl has kindly volunteered to run the games night before his talk at QCon later in the week. Karl will be running the ball flow game to help us learn and experience kanban and system thinking concepts in a collaborative way. It will also be a lot of fun, as fun is an effective way to learn.

You should get a lot out of this evening whether your experienced practitioner or you are completely new to kanban, lean, system thinking and theory of constraints. The evening will be a welcoming and safe environment to everyone.

Rough plan for the evening:
6.00 pm An opportunity to networking, chat to people
6.30 pm Start to the evening proper: Introduction and games
8.00 pm Retire to the Hat and Feathers for further discussions (optional)

Event sign-up

The hat and feathers is on the corner of Clerkenwell and Goswell road. You are free to join us there if you cant make the event.

Thank you
John Stevenson | @JR0cket | JR0cket.co.uk | JR0cket.com | LeanAgileMachine.com

Kanban elevator pitch

2011-02-16T14:48:00.001Z

My elevator pitch for kanban would be along the following lines..

"Kanban is a way to incrementally and continually improve your approach to meeting your goals, by understanding the situation clearly, identifying the real challenges and testing out your chosen options for resolving those challenges."

As with everything Lean and Agile, this elevator pitch will most likely evolve and can be made more specific depending on different audiences, but I am fairly happy with this general pitch.

Thank you

Faiding cards to improve focus on Kanban board

2011-01-25T11:20:00.005Z

I am using Lean Kit Kanban as my online kanban board and I just tried out a neat feature that is helping me focus on important time dependant tasks.

On the Lean Kit Kanban board you can set all kinds of filters to only show certain cards or you can use the filters to fade all other cards that would otherwise be filtered out. I am using a time based filter fade any card that does not need to be completed in the next 10 days.

With the filter now applied I have more visual information about what may be important to me and therefore can make quicker decisions about which card to tackle next.

This quick visual queue is one of many techniques I used to reduce up front planning. If I know when something is due (or a date passed when the card has significantly less value) then I can plan "just in time" more effectively.

If none of the time dependent cards are of value or I feel that there may be others of greater value I can quickly switch off the filter with a couple of mouse clicks and see the full board.

If I still am not sure about the next valuable card then I can dive into the backlog.

As an aside, I am wondering if it is worth recording how often I dip into the backlog. From an emotional stance, it feels like I only go into my backlog three or four times a month and only for a few minutes each time.

Thank you.

Kanban clinic

2011-01-19T12:00:00.005Z

At February's Limited WIP Society meeting we are having a Kanban Clinic where you have your chance to build your own personal or team kanban board from scratch. You can also work with others to help them build a board if you want to see a kanban board evolve.

If you have an existing board (kanban, scrum, or otherwise), please feel free to bring it along (the design not necessarily the board) and get feedback and advice on any aspects you want to improve on the board.

There is no formal presentation although ideas and examples will be shown and questions arising from the practical work will be discussed.

The slides and presentation video from the January Limited WIP socieity meeting are available on the SkillsMatter website.

Thank you

TDD Kanban for Deliberate Practice

2011-01-08T17:39:00.001Z

To help keep you in a good flow when you are learning or practising the TDD test first approach, it can be useful to use a simple kanban board to manage your flow.

The TDD kanban helps you to focus on each step, helping you to stick to test-code-refactor.

The TDD kanban board has three lanes as follows

Test - you are writing a single test
Code - you are writing code to pass a particular test that is failing
Refactor - you are changing the internal workings of your code

You only have one card on your kanban board (this is your work in progress limit), this reminds you which activity you should be working on and should help you get into the test-code-refactor routine.

The card itself is blank and does not refer to any required behaviour or example code.

Using the TDD Kanban board
To start, place your one and only card on the test lane of the kanban board.

Once you have written a failing test and run your tests, move the card on the kanban board to the code lane and write just enough code to make the test pass.

Once you have written enough code to make the test pass (running all tests), move the card on the kanban board to the refactor lane.

When you have finished your refactor work and have run the tests, move the card back to the test lane and write another failing test.

Credits
The TDD Kanban concept is from the mini kanban display at Jon Jagger's cyberdojo (that's my hand) at the SkillsMatter Lean Agile exchange 2010.

Personal Kanban workshop - 13th January 2011 - Limited WIP Society

2011-01-04T13:20:00.001Z

To kick off 2011 and to help keep on track with our new years resolutions and goals for the year, the Limited WIP Society are running a personal kanban workshop at SkillsMatter on the 13th January.

Sign up page!!

Personal kanban has been used to manage our busy lives very effectively by a growing number of people and I too have found it invaluable to get so much more out of 2010.

I would like to share the techniques I have been using with personal kanban, such as just-in-time planning, review techniques, managing events, keeping in line with personal goals, etc. The workshop is also an opportunity to show your techniques to manage your priorities.

The workshop will be a great opportunity to gather lots of ideas on how to make the most out of 2011.

I have written articles on personal kanban for personal development and just-in-time skills training. You will also find the interesting material at the personal kanban 101 website.

Thank you

Styles of events run by London communities

2010-12-27T03:28:00.001Z

There has been a huge growth in technology events taking place over the last few years, especially where I am based in London, UK. As well as major conferences through the year, such as JAXLondon, QCon, etc, there are a wide range of communities and user groups now well established.

There are a range of event styles that all these community groups run, so here is a breakdown of the most common event styles used

Smaller / evening events
Many communities run events for a few hours on an evening and they may include they following session styles.

Lightning talks
The concept of lightning talks is to present a number of short presentation by different people at a snappy pace. The talks can last from 1 to 10 minutes, although its common to have 5 minute talks.

The timings can be managed strictly with someone shouting out when time is up and the presenter having to immediately stop. It is useful to have a count down or some indication of time remaining for the presenter.

To keep the pace of the lightning talks when presenters swap over, either no slides are used or all slides are loaded onto a single computer in advance.

Lightning talks are a great way to cover a number of different topics, or introduce ideas that may be at a tangent to usual topics. As talks are short in nature, this format is great for those new to presenting to try out

It is common to include lightning talks in other events such as open spaces and unconferences, or as a warm up to a longer talk.

Thunder talks
Similar to the lightening talk but lasting longer (as thunder lasts longer than lightning in nature). Thunder talks often last for up to 20 minutes. Thunder talks are often mixed in with Lightning talks.

Pecha Kucha Night
A Pecha Kucha Night events consist of around a dozen presentations, each presenter having 20 slides, each shown for 20 seconds. Each presenter has just 6 minutes 40 seconds to explain their ideas before the next presenter takes the stage.

Pecha Kucha night is very popular with artists and other creative people for showcasing their works.

Ignite event
Ignite is similar to Pecha Kucha, this time participants are given 5 minutes to speak on a subject accompanied by 20 slides. Each slide is displayed for 15 seconds, and slides are automatically advanced.

Speed geeking
Borrowing the concept of speed dating, speed geeking allows several small groups to get intimate talks.

Presenters are spread around the edged of the room and the audience is split into small groups, one group per presenter. When signalled, each presenter talks to their group for 5 minutes, answering any questions along the way. Each subsequent bell the groups move to the next presenter until the groups have seen each presenter.

The biggest problem with this style of event is presenter tedium. If there are 10 presenters at the event, the presenters have to give their talk 10 times. However, this kind of event is good for those presenters who want to improve there presentational skills with deliberate practice.

Longer / all day / several day events
There are many events that run all day or for several days, usually over a weekend. These events may include lightning and thunder talks, etc.

Unconference

An unconference is a facilitated event in which the sessions (talks, workshops) are created and given by those in attendance, rather than an organised list of public speakers.

Facilitation provides a basic structure for the day, for example how many sessions are going to be held during the event and how long those sessions should be.

Attendees take one or more cards and write down the sessions they want to run, placing them on the schedule board created previously by the event facilitators.

Open Space event

An open space event is quite similar to an Unconference, although typically even less facilitated. The event is facilitated

Hack Day
A hack day is an event where developers, designers and people with ideas gather to develop one or more projects. A hack day may include some up front talks around a topic of the hack day, or presentation of one or more ideas that will be developed during the event.

At the end of the hack day (or days) it is common to have presentations of the hacks to the audience of peers and even awarding prizes.

Open Conference
Open conference organizers seek to open access to the conference for attendees by elimination of cost (relying on community support and sponsorships), they also provide community access to archived presentations and discussions through similar licensing agreements.

Additionally, attendees are encouraged to become participants in a collaborative community that supports and grows the conference--even to derive new open conferences.

Foo Camp and Bar Camp are other examples similar to the unconference, open space, open conference event styles.

I am currently an organiser for several communities, including the London Java Community, Graduate Development Community, London Scala user group, Limited WIP Society and Ubuntu-UK. I have organised open conference events and facilitated open spaces and found them a great way to share knowledge throughout a community.

XPDays London 2010 - an amazing event

2010-12-14T12:07:00.002Z

| XPDay 2010 Wiki | XPDay 2010 feedback page |

The 2010 XPDay in London was an amazing experience and my thanks go to the organisers and all the many people that gave great open space sessions and experience reports.

Not since the 2009 Lean & Kanban exchange at SkillsMatter have I been so engergised after an event (and I have been to quite a few great events this year). I feel I have learnt so much in these two days that it will take me all the holidays to digest (and blog about) everything.

The open space format worked very well for me and produced some great sessions. A great job by Mike Sutton for introducing the open space approach in a very clear way.

It was amazing to see so many people wanting to talk about such a wide range of subjects and it was often a challenge to decide what to go to, but as Mike made clear, it was easy for us to move between sessions.

I enjoyed giving my experience report on Taking kanban to the masses, where I describe some of the practices I have used to help convey understanding of the kanban method and how to visualise your work effectively. Hopefully will be able to catch up with the videos of the other experience reports on the SkillsMatter.com website. I liked the idea of having one organised track, to give you some up front idea of what could be covered in the open spaces.

As for the venue itself, I liked just using the upstairs rooms of SkillsMatter, it seemed to maintain a closeness throughout the two days and helped create a safe environment for people to share their thoughts and ideas. Good food for lunch too, especially the pasta.

The biggest challenge we had with the event was people judging the popularity of there talks. As the venue had one smaller room there was a few occasions where we had to swap. Perhaps we could do a quick raise of hand for those interested in a talk when put on the wall, so that popular talks are put in a big room.

I am really looking forward to the event in 2011 and would be interested in getting more involved, perhaps even helping organise the event.

Session Hightlights
There were so many great sessions on the day that I did not get to see everything I wanted. The session highlights that I remember so far and will write more on are as follows

Kanban 1's Game with Jon Jagger
Forward Internet 25 release per day with no unnecessary overhead
Ideal University course - lots of philosophy, learning how to learn, etc...

There are many more, including a few by Benjamin Mitchell that should be up there. I did missed out on the session about personnas by Sarah Lawfull, so will be looking for a write up about that one.

Reading list for learning Kanban and Lean

2010-12-14T10:40:00.000Z

On my way to understanding lean concepts through the use of Kanban, I have found books by the following authors invaluable:

Eliyahu M. Goldratt
Reading The Goal was a fantastic journey into thinking about lean without getting bogged down in anything technical. The Goal is a great novel and a long way from a dull technical book, it really gets you thinking about the core ideas behind Kanban. Following with a more specific book on the Theory of Constraints defines the lessons learnt in The Goal and adds ideas on how to manage your own constraints in the system.

David J. Anderson
David J. Anderson is one of those leading a march towards Kanban and Lean adoption in software development and his Kanban book is a great guide to applying Kanban to your existing process and identifying opportunities to improve.

Alan Shalloway et al.
The Lean-Agile software development book includes the experiences of the authors extending agile practices into the wider organisation by adding lean techniques to the mix.

Douglas Adams

Douglas Adams had a fascinating way of looking at the world and always came up with brilliant ways of conveying that vision. The way that Douglas would talk through Dirk Gently about the interconnectedness of all things really did grow my ability to engage in system thinking. Reading the two Dirk Gently books: Dirk Gently's Holistic detective Agency and The Long dark tea time of the soul will help get you in a lean thinking way.

There are of course many other good books on Lean, but these are the ones that have suited me best so far (although there is still a lot to read).

Introducing change effectively - All in, but not all a once

2010-12-14T10:38:00.000Z

When it comes to managing change then what ever practices you decide to adopt, its preferable to take an "all in" approach, in that you get as many people involved as you can. This does not mean that you have to adopt everything all at once, but helps you understand the big picture of change within your organisation.

An all in approach gets people involved from all aspects of the business (including revenue generating customers), so you understand the most important issues surrounding change within the business.

An all in approach helps you set meaningful goals that support the business value (e.g. your customers) and aim to extend that business value (e.g.. more customers, happier customers)

For example, if you make a decision that scrum has benefits for your organisation, it is better to get more people on board with adopting the idea of scrum than it is to adopt a full blown implementation of a scrum based process for a select few.

Although scrum is a framework, to get the most out of scrum you need to implement that framework in a way that increases the agility and effectiveness of whole company. It is too challenging to go from nothing to a full blown scrum process in one day (or one sprint) as this would be too much change for most companies (unless you are already agile in all but name).

Adopting XP practices also take time to bed in, whilst most of these practices are pretty straight forward and easy to get going, they take a little longer to become natural and comfortable. Adoption will be much smoother if there is an all in approach where everyone can see the point of these new practices (overal goals and values)

Adopting Kanban is relatively low impact at first as you are not trying to introduce change into your practices, you are simply trying to visualise and expose the relevant details of your current working practice. Using a Kanban method approach to represent everything thats valuable with your practices in a way that is engaging to work with and highly representative takes time and should continue to evolve as your practices evolve.

London Software Craftsmanship community - first meeting

2010-10-07T18:36:00.003+01:00

There was a great turnout for the first meeting of the London Software Craftsmanship community, close to a full house at our gratious hosts SkillsMatter. The following is a summary of the first meeting talk and discussions.

The founders of the LSCc David and Sandro, laid out their ideas about software craftsmanship for the community to chew over and discuss - which members did with great vigour especially towards the end of the evening.

David and Sandro set the tone by annoncing that they are asprining software craftsmen and started the community to bring together lots of ideas share experiences as to what that means.

Some scene setting by David, discussing how programmers are often used just like typists, when really development is an artistic process. Terms like software factory are not what the industry is about and focused on the wrong things.

Warm-up
There was a bit of exercise to warm the audience up, getting us all to stand up to figure out just what sort of audience was attracted to this event. It was good to see a mixture of developers, testers, coaches, analysts and even a CEO. There was a big contingent of Java developers and quite a few .Net devs even thought there was the LDNUG event the same time. It was good to see developers from the python, perl, android and even Erlang space too. There was a nice mix of age groups, quite a few in the over 30 camp but also university students and recent grads.

The talk proper started with an example of how software engineering practices were introduded at NASA, allowing them to deliver 42,000 lines of code with only 17 bugs - the only problem being this cost them $35 Million per year and projects were always delivered late.

Raising the agile model, this was portraied as a very productive time for those teams that really understood the principles and practices that agile estolled. Software craftsmanship was not portraied as a replacement for agile, but perhaps as a way to help us get back to thinking about the core principles and practices of agile that may be forgotton as agile spreads and transforms into "wagile".

The good enough approach is not always good enough and it was felt that many agile projects are now, steadily and iteratively producing mediocre software.

The idea
So, is Software craftsmanship the new shiny toy on the shelf that we all want to play with or does it have something meaningful to say?

David introduced a quote by Robert C Martin:

"The original torch of the agile message has changd hands to the software craftsmanship movement"

and refered to the wikipedia entry on Software Craftsmanship.

Delving deeper it was not portraid not as a certification process, a training course, a book, a tool or specific technique. Simply it is something that you are, the way you approach your work, treating software development as an art, a craft, something you care about.

The Manifesto
The desire to raise the bar of professional software development by practicing it well and heling others learn the craft was expressed in the creation of the manifesto for software crafstmanship:

Not only working software, but also well-crafted software -- it should be as easy / enjoyable to work on an old project as a greenfiled one
Not only responding to change, but also steadily adding value - extending the life of your projects
Not only individuals and interactions, but also a community of professionals - helping each other develop our craft
Not only customer collaboration, but also a productive partnerships - we need to help our clients / employers to value better understanding and better solutions

So what does it take to craft software?
Offered up were the concepts of creativity, judgement, theory and practical skill. Understanding that continuous improvement was seen as the most highly valueable goal, as there are always more things to learn.

One of the most common ways to practice the craft was to undertake deliberate practice - via coding and architectural kata to practice the are, coding dojo to learn language design, and code retreats to learn good design via test first development.

The Journey
Software craftsmanship talks about a journey from apprentice, to journeymen and then master. The apprentice experiences more learning than teaching and is mentored closely by a master. The journeyman has responsibility to take on projects unsupervised and works for many different masters to broaden the range of their experiences. It was commented that the journeyman was best placed to move the industry forward as they have a broader view than a master.

Sandro talked about how you dont have a control over becoming a master - it is driven by the community who look to certain individuals that are perseved as being highly experienced in a particular area.

These labels whislt interesting to talk about how you travel along your journey are not in themselves an important aspect of software craftsmanship.

In summary
The great conversations continued in the "SkillsMatter" pub, The Slaughtered Lamb and there was a lot of merry making going on there after the event.

For myself, a simple way of thinking about all these concepts software craftsmanship is to consider being "responsible", taking actions that are the most responsible thing you could do at the time within the constrains put upon you whilst still delivering value.

Understanding can be difficult if there is confrontation!

2010-10-04T12:20:00.000+01:00

When trying to share some knowledge or raise issues, I try to lead the audience (audience being an individual, team or community) on a thought trail rather than pointing out issues directly or just imparting the answer. By laying out a path of thinking, the audience is more likely to engage with the concepts or information you are imparting and become involved in path to the answer. Once on the path, the audience is more likely to accept the outcome.

Okay, so how do you start a thought trail, it sounds like a long, drawn out, boring process!
Start with the problem statement !!! rather than a question ???

Using the Socratic method of understanding is beneficial to the person who is playing the role of Socraties as they are able to drill down in to the real meaning and understanding of another person. However, asking a hard question (Why often being a hard question at times - if you don't know why you do something) and making people feel they should have the answers at their finger tips is not as conducive to knowledge sharing or collaborative problem solving

Empathise with the audience that have the problem, make that audience feel you are or have been in their situation, this will make them feel warmer and more receptive to what you have to say.

Example:
Socratic Question: Why are you talking to a reporting copy of a 3rd party database that is a day old rather than talking to the application in real time?

Empathy statement: I am concern that we are doing a lot of work to integrate with this application and the information may be out of date. If the schema changes then we may have a broken system and have to carry out a lot of rework under pressure from our angry customers. If we were able to talk to the application directly and ask it questions, perhaps that would require less setting up and would be less likely to change.

The Socratic question, whilst perfectly valid, puts potential conflict in the way of the problem space. You can often make the person you put the question to feel that they are to blame or have made a stupid mistake. If the person is made to feel uncomfortable or in the wrong, then they are less likely to work with you or listen to your advice to resolve the problem.

Using the empathy statement, you have asked the same question, but have asked the person to go on a journey with you to understand concerns of the problem raised and evaluate whether a different approach has merit. The person is encouraged to feel part of the solution, rather than being the cause of the problem.

In writing this article I started to break the premise of the piece by using a title that was a Sochratic method style question: Empathy over Sochratic method?

Instead, I went for the title: Understanding can be difficult if there is confrontation!

I wrote this article after reading the preface of The Goal by Eliyahu M. Goldratt and Jeff Cox. The preface is describing the style of the book which is in the form of a story. The preface states that this has been an effective book style to get across the many issues coveres in an engaging way.

Some thoughts on Limiting work in progress (WIP)

2010-09-26T17:34:00.001+01:00

Limiting your work in progress (WIP) has several benefits I can think of in making individuals and teams more effective

Maintaining Focus
If you regularly have to switch between tasks to get something done, or worse still some outside force is causing you to constantly switch, it is much harder to focus on the individual pieces of work.

When there is a lack of focus, mistakes are more readily made or aspects missed from the work.

Reduction of work / thinking time duplication
When it comes to knowledge based tasks, switching between different tasks has a significant time cost associated with it. If you start working on some task that is going to take a half day to complete, but after a couple of hours have to work on something different, a significant amount of time is required to get back to where you were with the original work.

Working on one task until it is ready to pass on to the next stage gives better feedback on how long that type of activity can take. Better feedback helps you more accurately adjust any estimation you are required to provide.

Maintaining a good flow of work
Switching between tasks interferes with the flow of those tasks and can delay work being completed at the perceived time. Any planning and estimation done prior to the work may not be judged correctly if you do not include time wasted due to task switching.

If you minimise your work in progress and only work on one task at once it is easier to get accurate measurements of time required to complete each task, giving better feedback to your planning and estimation activities.

Avoid building a psychological mountain
If you have too much work or you see the work as to vast or complicated, there is a natural tendency to be overwhelmed or demotivated by the scale or complexity of the work.

Humans can process more work when it is viewed as small and not overly complex.

Technical Debt / Stale work
If you have a lot of work that is in progress, then the effort already invested into it has yet to deliver any value to the customer (in a personal Kanban, the customer may often be yourself). The more work in progress you have therefore means more investment without return of value.

In manufacturing, if you have a high investment (inventory) without delivering any value (sold products) then your business is not being effective.

In software development, if you have a large number of requirements (stories, use cases, etc) in various stages of development, then that is a considerable investment made without that software realising those requirements in the hands of the paying customers.

If you minimise the overall work in progress you have less investment and less risk should there be a change to the project.

Summary
There may well be other benefits to limiting your work in progress, but this is all I can think of for a wet Sunday afternoon. If you can suggest others, I would be most interested.

Thank you.

Reading list for learning Kanban and Lean

2010-09-09T13:10:00.000+01:00

Douglas Adams

There are of course many other good books on Lean, but these are the ones that have suited me best so far (although there is still a lot to read).

Agile Fairytale - stories to express agile concepts

2010-09-05T10:25:00.000+01:00

Agile fairytale is a neat way to express agile concepts in a way that is easily understood, using a context more likely to be meaningful or recognisable to a wide audience.

At the heart of Agile Fairytales are three fundamental concepts:

Agile Values - Agile Fairytales extends the 5 Agile values of Communication, Simplicity, Courage, Feedback, Respect to include Trust and Transparency and applies them to real life
People - Agile Fairytales is based on the belief that we can all change for the better
Continuous Improvement - Agile Fairytales encourages us to improve one step at a time

A Creative Thinking Tool

Agile Fairytales uses simple narratives to structure the way we look at problems. Each fairytale is designed to give us insights into our experiences through a better understanding of ourselves.

When to Use Agile Fairytales

Agile Fairytales are useful in the following situations:

As an icebreaker
When creating a new team
For improving the performance of team members
As a game with friends and family

Interesting presentations from Agile2010

2010-09-05T10:18:00.000+01:00

Here are some presentations I found from the Agile 2010 conference:

Business value modeling - agilecoach.com

QCon brainstorming night

2010-09-02T11:48:00.002+01:00

Thanks to the hospitality of the QCon organisesrs, last nights QCon brainstorming session was a great event. As well as all the great discussions going on, there was a seriously generous helping of really nice food and what seemed a never ending supply of drinks.

QCon is a regular event aimed at those interested and engaged in enterprise software development. The event aims to provide the highest quality presenters and most engaging topics each year. Previously the QCon schedule has been organised from the input of those wishing to present, but for QCon 2011 the goal is to include ideas and recommendations from the community of people who pay to attend QCon when deciding on the schedule.

There was over 30 people that turned up and it was a great atmosphere. I turned up there early (no surprise) with a friend and we were greeted by our very friendly host, Jørn Larsen (on the far right of the picture).

The evening started with all of us grouped around a big table with lots of flipchart sheets and post-it notes. As not everyone was lucky enough to make QCon 2010, we briefly discussed QCon and the different types of days and event that typically go. Usually there are two days of tutorials before the main conference, with the conference itself having a large number of tracks each day (see QCon 2010 tracks).

For the brainstorming proper, we started creating lists of topics we thought would be good for the next qcon event and also identifying any speakers we thought were really good at presenting and generally entertaining the crowd.

I started the ball rolling by writing down some ideas, although half way through writing my first idea I had a feeling that everyone was watching me. When I looked up everyone was watching me, but got on with adding my crazy ideas and this helped encourage everyone else to do the same.

Very quickly there was a wealth of ideas that came poring out and after I had run out of ideas myself I started writing down lots of ideas that people were discussing as them to make sure they were captured.

We also had a kind of retrospective sheet where we could put post-it notes on for things we wanted to see more of or less of, as well as things to start doing and stop doing. The funniest comment I saw was to "Stop giving uncle bob martin a small room" - alluding to the fact that he is always a popular speaker and you cant always get in to see him.

All the flipchart sheets got stuck to the wall and we churned out dozens of sheets worth of ideas. However, it all kind of got put on hold when the first wave of food turned up. Yes, there was so much food that it did come in waves. No one went home hungry and even I was too full by the end to want a doggy back to take home what was left.

There were lots of great discussions happening, its a shame we didn't record them for AppleTV!! There was a continuing trickle of ideas added in between the food, drink and chat until the end of the evening.

Jen and his team now have a very busy few days going through all the weird and wonderful ideas that the group came up with, including all my Kanban, lean system thinking, rightshifting and continual improvements suggestions (I think there was a whole page just on those). If even just a small part of the ideas we all came up with make it in then QCon 2011 should be a really great event.

If you want to know more about what may be appearing at QCon 2011, you can have a look at the tracks for QCon 2010. The most interesting ones for me were Agile Evolution, Software Craftsmanship, Dev and Ops: A single team and Irresponsible Architectures & Unusual Architects

My favourite estimation technique

2010-08-15T21:36:00.000+01:00

Here is my favourite estimation technique in action

Lean or Agile - understand and use both - wisely

2010-08-04T17:59:00.001+01:00

The term agile evolved to encapsulated the principles behind software development practices such as extreme programming, scrum, DSDM and other iterative and incremental approaches. Lean has been around a lot longer, (possibly a great deal longer - Chinese Emperors) but has infrequently seemed to gather momentum in software development until recent years.

On the surface that there is a great deal of commonality between the two approaches. For example with Agile, teams focus on doing enough work to get the job done whilst leaving options open, to help managing the inevitable change with less pain and risk (eg. failing early). This agile practice could be viewed as minimising waste, a lean concept, but do most agile teams have the opportunity to understand that they are minimising waste and the implications of doing so?

Agile processes all seem to have a common plan-do-check-act core with there approach. This is interesting to me as that is exactly how I have started several personal Kanban boards. However, those personal Kanban boards just happened to fit that simple value stream and usually evolved in to a more continuous feedback system for work.

Also a scrum board and a Kanban board can visually look very similar, but have a different context and approach, usually have different values and different outcomes. I have seen (bad) scrum boards that look like a micro waterfall process to a prince2 project manager, with all the same problems. A good Kanban board has values derived from the wider organisation that subtly change how that board is used to bring about a very different outcome.

There are many shared or similar principles at play with both Lean and Agile, especially as we learn lessons from applying lean approaches to software development, perhaps the differences are most evident in the goals and the values driving the practices a lean/agile team adopts.

As the goals and values defined will vary depending on the organisation, the overarching principles of both lean and agile can be used as a common framework for guiding teams and organisations to become a leaner and more agile machine (within the limits of their capacity for organisational change).

Effecting organisational change with agile practices alone is a very difficult way to achieve a positive change, borrowing goals and values from Lean broadens the context of your practices so that the organisation moves closer to working as a whole and therefore sees the wider value of organisational change.

In summary, believing that Lean and Agile is the same when applied to software development seems to be a high level view and misses out on the deeper and richer aspects that lean system thinking helps promote.

Then you have the concepts behind a learning organisation that extends lean and agile even further.... but that's another discussion.

Why use scrum (or any other agile process)?

2010-07-21T14:45:00.002+01:00

Scrum is a process framework for creating your own agile process, meeting the goals of your particular organisation. Some aspects as to why you would use scrum (over some other non-agile or non-iterative process) are as follows:

Managing risk and change effectively

By using small steps and quick feedback (tests, customers) errors from misunderstandings are quickly addressed.
Focusing on the most valuable and most risky aspect of the project up front reduce the cost of failure and therefore give a greater understanding of risk in the project.
Leaving options open until the last responsible moment (avoiding big up front design) reduces the risk of wasted work and helps facilitate change in line with the business goal. Architecture evolves instead of being fixed / ridged

A light touch of order to the chaos

Defines principles to aim for rather than cold dogma
Defining a flow of work and the roles and responsibilities to manage and maintain that flow
Organising without stifling the creativity or variation that increases value of the work

Faster time to market

By releasing functionality early and often, feedback is greatly increased and real understanding of what is needed is quicker to arrive.
As work is done in small self contained pieces it can be created and delivered quickly

Improved quality

Defects are discovered and tackled early by including testing aspects and only software needed by the customer is developed

Improved stakeholder satisfaction

Stakeholders (customers, testers, developers, ba's, etc) have greater involvement and influence in the product development and therefore have more affinity to the project.

Greater employee engagement

Involved in the whole process & decision making activities giving them a greater understanding of the value of their work

Higher productivity and lower costs

Only building what's immediately needed reduces the waste of developing things that are not wanted.
Smaller code bases should on average have fewer bugs, so writing less code is more productive.

This is by no means an exhaustive list of reasons to start agile adoption (with scrum or similar approaches) but give you a flavour as to the aims and benefits of an agile way of working.

Take a look at my scrum overview for more deals of the aspects of scrum.

Quotes about Kanban

@agilemanager Funniest comment on my talk, "I don't want to be the girl w/ a reputation for always saying 'yes'" ;-) @llillian #lkbe10

Summary of the agile manifesto principles

2010-05-06T12:30:00.004+01:00

Regardless of the processes and tools you put in place to become more agile, you should take time to learn and instill the principles of agile to help you understand what you are aiming for. Reading and understanding the implications of the agile manifesto is therefore a very valuable start, although it is just a start of a very important change.

Here is a quick summary of the agile manifesto to get you started:

Highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, empowers business to adapt at its own pace.
Deliver working solutions frequently, continuous feedback - working software is the primary measure of progress.
Business and developers work in concert throughout the project (breaking down that divide)
Build projects around motivated individuals, trust them to get the job done.
Conveying information with face-to-face conversation.
Maintain a constant pace indefinitely - sponsors, developers, and users.
Continuous attention to technical excellence - good design enhances agility.
Simplicity - the art of maximizing the amount of work not done
The best architectures, requirements, and designs emerge from self-organizing teams.
Team focused on continuous improvement.

See the Manifesto for Agile Software for more details

Robert Martin - why tdd is important to a languages survival

2010-04-24T14:56:00.000+01:00

This morning I watched a really great key note from Robert Martin (Object Mentor) about how test driven development is very important to a language, not just in terms of writing clean code but as part of an professional approach to project delivery and relations with the wider industry.

In summary, Smalltalk was an amazing language but its community built walls to keep out the rest of the industry and did not accept that they needed tools to keep their work maintainable through testing (TDD).

I hope you enjoy this 1 hour keynote as much as I did: RailsConf 09: Robert Martin, "What Killed Smalltalk Could Kill Ruby, Too"

Six thinking hats - a collaborative thinking system

2010-03-20T14:24:00.003Z

Edward de Bono devised a simple thinking system called 6 thinking hats which defines how you can approach a problem without descending into argument.

For a long time we have always used argument as a way of discussing ideas and looking for solutions, however argument is very inefficient as its mainly negative and attacking. The argumentative stance can lead to point scoring and antagonism between the persons discussing the idea, leading to a break down in communication.

With the 6 thinking hats approach, people are thinking in the same direction for a short period of time. This same direction thinking, often called parrallel thinking, is highly collaborative and productive. To cover all aspects of the problem, the direction of thinking changes but everyone changes thinking at the same time, maintaining the collaborative nature of the discussion.

This approach helps to open up the topic in discussion and helps avoid any narrow thinking. When considering a problem from these 6 different perspectives you are more likely to establish a robust solution to that problem.

My typical approach is to start with the blue hat to define the objective of the discussion, followed by the white hat to cover all the facts regarding the subject matter.

I perfer to cover the positive thinking before critical thinking, so would follow with the green hat and yellow hats to establish a list of ideas and benefits.

I would then finish off with the red and black hats to help focus on what could practically be achieved and what the team feels is the general approach.

There is an interesting Knowledge Gene on 6 thinking hats for an agile retrospective.

Getting started with BDD and Kanban

2010-02-21T12:34:00.002Z

I am starting writing entry points for getting started with BDD and Kanban, now that Blogspot lets me have pages on this blog.

On the BDD page I have done a quick mind map using Freemind in preparation for the BDD immersion workshop with Liz Keogh on the 26th Feb.

On the Kanban page, there is a quick intro to KanBan and some pointers on how to build a KanBan board and the artefacts that you could add to make the board more expressive.

These pages will evolve as my understanding and experience grows. Any comments or ideas for these pages are very welcome.

Acceptance-test driving development by John Smart

2010-02-14T15:30:00.005Z

A summary of the Acceptance-test driving development talk presented by John Smart, principal consultant at Wakaleo Consulting - held at Skills Matter by the Agile Testing user group on 11th February 2010:

Acceptance testing is a a key agile practice, especially in practices such as behaviour drivend development (BDD) and test driven development (TDD).

The main benefit of acceptance tests in agile are not the tests themselves, but the ease in which they allow people to commuicate. The language of the tests is expressed in the business language (industry domain) usually in a simple to understand structured natural language (often with spreadsheet style tables for typical and edge case data examples).

As the tests are expressed in a business language, they can easily come from the business (customer / product owner). As the language used to write the tests should be universally understood in the team, it is easier for the whole team to work collaboratively on them.

Using the Given-Then-When structure of BDD, the acceptance tests are also in the perspective of the user. The tests focus on what the system does and not how the sysem does it (as was mentioned previously at the last agile testing talk by Gojko - this helps keep a seperation between the acceptance tests and the details of the code written).

Acceptance tests are executable!
EasyB, Fitnesse, JBehave and Cucumber are examples of tools that allow you to execute acceptance tests very easily.

Being able to run the acceptance tests at the drop of a hat is a very powerful way to determine when a feature has been implemented in code. The tests can generate (html) reports as well as being integrated with continuous integration systems eg. Hudson CI and web testing tools such as Selenium. All these tools can be integrated as one build process, so when code is checked in or acceptance tests added, every aspect of that change is managed.

How far do you go?
Acceptance tests are very inefficient to debug your code, as are testers and coders. Finding bugs is wasteful, preventing bugs is much more effective.

When writing acceptance tests think in terms of a story, a happy path of how the system would be used. Then elaborate your tests as you become more in tune with the users of the system (users also include other systems)

By writing acceptance tests in terms of what the system should do, avoids those tests becoming a lag by having to refactor your acceptance tests for code changes.

Please review the slides and the video from the event for examples of using EasyB and how easy it is to use the BDD style language of Given-Then-When for writing your acceptance tests. Also, visit the Agile Testing user group and get involved in the agile testing community.

I would encourage to you to visit the Skills Matter website for lots of upcoming talks on agile testing, BDD and many more excellent topics. I am attending a BDD workshop on the 26th February by the formidable Liz Keogh, I recommend looking this course up if you are interested in learning BDD effectively.

Lean reading - a my current book list of lean

2010-01-21T00:33:00.001Z

My current reading list is loaded with some highly recommended books on Lean System thinking and the theory of constraints. There are a lot of cross-concepts between these two areas and its been good to compare the ideas together.

Theory of Constraint books:
Theory of Constraints - Eliyahu M. Goldratt
The Goal: A Process of Ongoing Improvement - Eliyahu M. Goldratt
It's Not Luck - Eliyahu M. Goldratt

Lean system thinking books:
Lean Thinking: Banish Waste and Create Wealth in Your Corporation - James P. Womack - I started with the audio book, but have got the paper copy for reference as there was a lot of good stuff to process.
The Machine That Changed the World - James P. Womack

After I have finished the above it will be on to the poppendieck books by that time it will hopefully be time for the new book by David J. Anderson on lean and kanban that is rumoured to be in the works.

Personal Kanban for Just-in-time skills development

2010-01-16T09:54:00.002Z

It is not uncommon in IT projects that you are required to learn something on the fly or you see an opportunity to introduce a new technique or tool that would bring great benefits to a project.

How do you manage the learning curve required for something new without major impact to the project?

After reading comments from my previous personal Kanban post by Jim Benson and Bruce, I thought I would expand on the Just-in-time aspect of Kanban.

I currently use my personal Kanban (LeanKitKanban) to drop small size cards into my backlog that are designed to tell me what I need to learn about a subject or tool quickly. The cards have a set goal that should be manageable in a short time period. Each card would have the relevant resources links to help me achieve that goal.

When I get a spare hour I can select one of these and have a focused, time-boxed cards and get up to speed quickly. If I have met the goal and feel confident that what I have learnt was beneficial (either personally or for current work) then I mark that card as a success. If I don't meet the goal, then I will mark the card as incomplete and review it in a mini retrospective. The goal of the retrospective is to help me write better cards quickly, as well as check that the topics I am learning are coheirent.

An example would be good right now:

I was at the Agile Testing user group in December and there was some discussion on continuous integration. I realised that this area has really flourished since I last set up Cruise Control, so I created a group of cards on my Kanban to look at what's new in continuous integration and to reaffirm that I was up to date with the latest practices. In that same week as the meeting I had manage to review the theory (Google, Wikipedia) and learnt a new tool called Hudson (great tool, I recommend it, neatly integrated with Netbeans). All this was pretty easy to fit into my busy schedule as I could easily visualise all my work on the Kanban and see what was important that week and what could wait.

I still have several continuous related cards in the backlog, but for now I have refreshed enough theory to work with Hudson effectively in my project work. If I need to learn Team City or some other CI tool, then I have a model to quickly tackle that learning.

This approach works for me at present as I break down the task on the card to something managable. I am curious to find out how well I can break a large subject area down with this process, for example learning the whole of Spring 3.

For now I will be using this JIT Kanban learning to review and extend my Behaviour Driven Development (BDD) skills as I have a BDD immersion workshop in February with Liz Keogh at SkillsMatter and want to make sure I get the most of the workshop. It should be a great day of learning as Liz has done a great deal of work defining BDD and adding lean system thinking into the topics that will be covered. There will be some homework to take away from the course, so I'll be using my personal Kanban to organise that work into my busy schedule.

Personal Kanban to manage personal development

2010-01-14T17:28:00.001Z

Having an inquisitive minds is a great thing but there can be a tenancy to be interested in too many things that you never learn something deeply enough. How do you stop the inquisitive monster in you mind and get on with just one thing?

I have been using a Kanban system to plan my study and added work in process (WIP) limits to manage the flow so my monster is tamed and I focus on one thing. Any future interests are quickly dropped into my backlog so my monster is satisfied that there is lots more to learn.

I started with a basic design for my Kanban, with the lanes Review, Study and Blogging which nicely followed the plan-do-act design that is often used for visual boards.

After a week of this Kanban design, I felt that something was missing between review and study. When I completed a study task there was not a clear set of tasks I could choose from which I new I wanted to study. I would end up looking at review tasks that I had not finished (or started) meaning more time planning rather than studying. As duplicating planning of study tasks is wasteful, I modified the board design to include a Ready to Study lane so I could quickly choose the next topic.

I renamed Study to Deep in Study to indicate that this was generally a bigger process and I would need to set aside more time. I reinforced the idea that deep in study was a bigger task by limiting the WIP to 2 tasks (I am allowing 2 tasks as I am still detoxing from multi-tasking for far too long).

Once I had completed a study task, the plan was to blog about that topic to help retain the knowledge I had gained. I found it useful to add yet another lane called Evaluating to help me review what I had learnt and had a better idea of what to blog about.

Using a Kanban approach has also helped me develop skills in a just-in-time approach. By adding small tasks to my backlog to help me evaluate new areas of study or tools, I have a pool quick work that I can fit in when I need a break from deeper study. Carrying out a brief review of something new allows me to work out what I need to learn, how much effort it would be to learn and most importantly if it is really worth learning yet. From this quick analysis I can create a number of study and exercise tasks in my Kanban backlog that would help me learn efficiently, indicating effort and priority of each task.

Give public access to your Google Wave

2009-12-03T18:22:00.001Z

You can give public access to your wave by adding a user to your wave called easypublic@appspot.com.

(How it works: easypublic is a robot that adds the public@a.gwave.com which is the real public user)

If you are going to create many public waves, add the easypublic@appspot.com to your contacts list. You can then just drag the easypublic icon from your contacts onto your wave.

By making a wave public, everyone with a Google wave account can follow, edit, reply and add contacts to that wave.

Sending a direct link to a wave

You can tell people about your public wave by just sending them the web address -URL - at the top of your browser when viewing the wave.

(Note: the URL contains information about your Google Wave panels, whether they are minimised / maximised)

Searching for a wave

To find a public wave add a sutable tag to the wave: eg. skillsmatter and in the inbox search box, enter the following text:

with:public tag:skillsmatter

Once someone is following a wave, they can just use the search text:

tag:skillsmatter

Can you be both Lean and Agile?

2009-11-29T21:50:00.000Z

In a Linked in post, someone asked if its possible to be both lean and agile. I think it is possible and this is what I replied:

If you are considering the value of the activities and your deliverables within your process, be that an agile process or not, you are starting to tend towards lean. How far you go towards lean depends on how much introspection you do and how much you act on the results.

Tending towards lean should aim to remove as much waste and deliver the most value as feasible. How lean you become would be driven by an understanding of the value chain of your organisation.

In short, you can be agile and lean, but consider how much value you get from what ever you understand from each of those terms.

I am not an expert in understanding in lean, but the above captures the essence of what I understand at present (at a very abstract level).

Here are some discussions I found about this topic:

Richard Durnall - Lean Vs Agile

DZone - Agile and Lean - Closer than you think

Agile and Lean - the same but different

Putting the 'Lean' into Agile - What Can We Learn from Kanban?

Any comments?

Google Wave for Lean and Kanban exchange at SkillsMatter

2009-11-28T23:09:00.000Z

A Google Wave has been set up for the Lean and Kanban exchange being held at Skills Matter on Tuesday 1st December.

The wave will be updated during each talk with a summary, please add your contributions at the same time if you can - wave is collaborative so join in... Dont worry if what you type it not perfect...

Direct link to wave: http://bit.ly/7yiiQ2

Or search for the wave in the Navigation panel or type in the search criteria in the Inbox panel search box. Either way you should use the following text:

with:public tag:#leankanbanX

with:public tag:skillsmatter

Until you follow a wave or are added by someone, you need to include the with:public, otherwise google wave will just look at your inbox.

Once you are following the wave you can find it in your overcrowded inbox by using:

tag:#leankanbanX or tag:skillsmatter

GoogleWave accounts are by invite only at present, if you need an invite please let me know.

Agile Testing exchange on a wave

2009-11-26T01:27:00.000Z

A Google Wave has been set up for the Agile testing and BDD exchange being held at Skills Matter on Friday 27th November. Search for the tag #agiletextingX and you should find it.

To search for a tag in GoogleWave, add a new search in the Navigation panel or type in the search criteria in the Inbox panel search box. Either way you should use the following text:

with:public tag:#agiletestingX

GoogleWave accounts are by invite only at present, if you need an invite please let me know.