Some common Kanban questions–my suggestions

I have been talking about Kanban a lot the last couple of years. Sometimes to the point where I think that I must have talked a hole in the head of the those closest to me. But from time to time you get great response, for example;

Anna (an Avega Group colleague) attended one of my Kanban introductions and became inspired. She started to implement parts of the practices I’ve suggested at her client and soon ran into some questions. She sent me an email and asked for my suggestions on how to act in certain situations.

I of course answered but also felt the questions was not only good, they were also common. So I thought that I’ll share my suggestions here. Bear in mind, as I also told Anna, that Kanban is really just a couple of simple rules – how you apply them in your context is very much up to you. This has led to a plethora of practices and ways to solve problems. These are the ones I have picked up in the great network I have surrounded myself with.

So important to note is that Kanban as methodology doesn’t answer any of these questions. It’s up to you.

“If you quit today”–make someone happy

I have been working as a contractor for the better part of my career. Due to the nature of consultancy and the IT-business in general I’ve seen a lot of colleagues come and go. Brilliant people in many cases, people that you miss so bad when they have quit.
So when the ubiquitous “Thank you for the time here”-mail comes I always try to write them a short sentence saying that I’ve really appreciated their company, competence and just being around them.
And it hits me every time; why didn’t I say anything of this while we were colleagues?

What is agile?

About a year ago I got asked by my project manager to “just give a quick intro and overview; What is agile? 20 minutes or so…” That didn’t feel to bad – but when I got home and started to prepare it struck me; it’s really hard to sum up agile!

For me agile has been become more a less a lifestyle and much of the things I argue for or fight against is about agile or being agile. And also, now that agile is 10 years old, the buzzword has gone into the next phase and almost anything good or cool that people does, related to software is branded with agile ™.

Is TDD agile? If your not doing TDD are you not agile? Standups? Boards? The list goes on and on and I couldn’t come up with an intelligent answer. Either everything had to be included to be agile or nothing was left.

Applying the Switch framework to broken builds

I’m rereading a great book – Switch by the Heath Brothers and it inspires me. The last time I read this book it inspired me to write a post and it’s happening again.

The book is about change, how to accomplish change and especially in situations where you are not in power or control. In short – how to talk to and influence others to understand the need for change and follow through on it.

One very smart thing is that you can download a cheat sheet that contains the ideas in a nutshell – the Switch Framework – for free. Of course it’s not much use if you haven’t read the book, so you better do that first. Could very well be the best book you read.

I thought I would apply the reasoning in the framework to a real life situation and see if I get any ideas on how to get forward. I haven’t implemented this yet but I’ve been reasoning about it with myself and other for quite some time now.

So this is, like many post on this blog, a learning experience for me and I’m sharing it with you. Please supply any feedback to me. I would love to hear your thoughts on the matter.

Log4Net, RollingFile named by Date and the staticLogFileName setting

We have been chasing some strange logging bugs for a while in my current project. We are using log4net to do our logging and it works fine ... until a couple of weeks ago. Some logging didn't occur, in another case we didn't get new files...

Creating a tools only NuGet package

I have started to help out in a new OSS project. The last one was SpecFlow and now it’s Pickles. Pickles is a tool that takes .feature-files from SpecFlow or Cucumber and turns it into a nice living documentation. It’s a great addition to SpecFlow.

Ok – one of the things I have been doing in the Pickles project is to create NuGet packages for the project different runners and especially lately the PowerShell runner. This will be the main way to interact with Pickles locally, which basically means that you’ll just write a command in the Package Manager Console to generate the documentation frictionless. Later you will probably run it as part of your Nant or MsBuild build files.

I learned a great deal about PowerShell and NuGet when I put that NuGet package together and since it was quite some time since I blogged I thought I’ll write down my experiences. This post is a about the NuGet package.

What i learned from 'From User stories to Acceptance tests' with Gojko Adzic

I've just returned back home from a course. It's the first course I've attended in over a year and I'm always amazed how much you can learn in a short time; if the course and teacher is good and if you engage yourself in the course.

This time I knew it would be great since Gojko Adzic was the teacher and the subject was something that I find really interesting and useful - Specification by example.
I would be completely impossible to write down even a fraction of all the stuff I picked up during the two days but I thought I stop at the main points and write down what stood out for me.

As I've been following the BDD and Specification by example community intensively for two years I had quite a lot of knowledge on before hand - the main points I wanted to get out of this was practical tips on how to facilitate and handle the early phases of the lifetime of a specification done in this manner. Being a developer I have focused much on the later parts up to now.

Here are the main topics we discussed, but not in this order as I remember:

• Communicating with examples
• Key process patterns of successful teams
• What makes a good specification
• Fitting into a development process
• Adoption strategies and patterns

BDD and technical scenarios

I got a question from Sham (Shamresh Khan) that I thought was interesting and also common. So I thought I post my answer here in the public and maybe we all can learn a bit.

Sham’s question was something like this:

…some of my scenarios/examples, may be very technical (i.e. checking some algorithm for example). If I write these tests under a user story (using the Gherkin syntax), a business analyst will be able to see them which may confuse them as they try to work out what scenarios exist under the user story or am I wrong here? Maybe all tests should be visible under a user story?

OreDev 2011 - day 3

Last day was great. I didn't go to anything that was really bad and I had some real highlights with Dan North, Gojko Adzic and Mark Rendle on Zen standing out as the best.

After a short and intense Lean Coffee I'm not sitting and waiting for the keynote with Jeff Atwood, who apparently just introduced himself and then went off the stage yesterday. Let's see if he does the keynote himself today

OreDev 2011 - day 2

As always - after the first day my head was just spinning. I was so tired that I slept before I hit the pillow. But today I'm feeling great again and am ready for another great day of learning.

Dan North on Embracing uncertainty

Dan North is one of my true heroes in our industry. I've learned a lot of the stuff that I'm excited about from stuff he written and spoke about. This is about embracing uncertainty - which seems to sit nice with the whole BDD - Deliberate Discovery body of knowledge. Here's a few things I jotted down:

OreDev 2011 - day 1

I was very fortunate to go to OreDev this year. It's just a great show - I described it as a "free bar of knowledge alcohol for learn-o-holics".
I thought I'll take a few moments just to jot down some highlights and stuff I picked up during my first day at OreDev 2011. This is mostly for me... but you can read it if you want.

SpecFlow.Assist.Dynamic–maxing out with Simple.Data

SpecFlow.Assist.Dynamic came about from my own need when I wrote something that used Simple.Data. I saw the power and simplicity (duh!) in Simple.Data by using dynamics. And I started to thinking on how it could be used in SpecFlow to further simplify and shorten up the code in my steps.
This is the third and final post on SpecFlow.Assist.Dynamic. Again this is not the formal documentation. It can be found here. These are just my personal preferences and thoughts on how to use it. This time with Simple.Data. And it won’t be long.

SpecFlow.Assist.Dynamic–how to use it

This is the second post about SpecFlow.Assist.Dynamic – a little tool I wrote to help you write less code in your step definitions, and focus on the actual step instead of infrastructure. You can read the first post here – it explains little about what SpecFlow.Assist.Dynamic is.
In this post I’ll show you how some ways I use the dynamic features to and some tricks that you might not know about.
Again – this is not the documentation for SpecFlow.Assist.Dynamic – that can be found here.

SpecFlow.Assist.Dynamic–what is it?

I have created my first ever NuGet package! I am so proud. Actually it’s just a small extension to SpecFlow and the excellent Assist helpers by Darren Cauthon. But I learned quite a lot about dynamics in the process and I thought I write a post or two on SpecFlow.Assist.Dynamic; what it is, the problem it solves and how it’s made. Later post will be around how to use it and to put it together with Simple.Data to create a real sweet testing experience.
Let me say – before I start – that there is documentation for usage on the GitHub wiki. This is a blog posts on how I made SpecFlow.Assist.Dynamic – not the official documentation.

Simple.Data–the testing story

I have fallen for Simple.Data. Big time. It’s so terse and concise that you almost lose the need for data access abstractions altogether. It’s just … there for you. Just see for yourself here. And when have this power at your fingertips it’s easy to forget the testing story.
How should I use Simple.Data so that I still can write unit and acceptance tests with code using it?
In my unit-tests I do not want to call the database, of course, because that would slow my unit-level tests down. Also if I do automated acceptance I want to go end-to-end, testing the full stack of the application. But there the database access will slow me down, often in the form of a network hop as well.
Have no fear! Mr Rendle have set us up with a couple of ways to mock out the actual call to the database on the lowest level, but still go through Simple.Data.
In this blog post I want to show you a couple of ways to write unit-tests that doesn’t hit the database, but still use Simple.Data.

Is Scrum a –ism that doesn’t work for real?

The other day I got my hands on the Scrum Guide 2011. It’s a updated version of how Ken Schwaber and Jeff Sutherland looks at Scrum, it’s practices and state today. It’s well worth a read – especially if you haven’t read up on Scrum in a while.

And let me here in the outset of this post also state that I have use Scrum a lot and it helped me and my teams a lot as well. I like Scrum to be short – but (had to be one right) I think that some situations doesn’t fit perfectly with Scrum.

After that short side note, let’s get back to the real thing. After I read the article I had an opportunity to sit down with Morgan Ahlström, a fellow lean / agile coach here at Avega Group. We started to discuss about the things we read in the document and finally arrived on the question; can Scrum, as described in the document, actually be done?

The rest of this blog post are inspired by Morgan and written by me. Any strange stuff and faults are just my own and any great stuff is probably Morgan.

Kanban-inzg the Avega Group Office–reflections

This is the third post in a short series on how Morgan and me went about to introduce Kanban and some Lean thinking to two support teams of the Avega Group office. You can read post 1 and post 2 before this to get the complete picture.

With this post I wanted to do some reflections on how the introduction of Kanban took hold for the teams and also what Morgan and me learned in the process. We are used to do this for IT-projects and teams working with system development or maintenance.

Executable specification - the whole stack or not

This is really an age-old BDD question that pops up from time to time. Just now I got a question from an ex-colleague about it. A bit rephrased it something like this:

Should I test through the GUI all the way down to the database? How do you handle test-data in and test executing speed in those cases?

Many of us first got exposed to BDD tests through web applications and the way that we could test through the actual web page. We use tools like Watin, Selenium and other automation tools to accomplish that. We structure our automation code with page wrappers to get manageable automation code that can be re-used in our step definitions. For some BDD even implies automation (which is not at all the case).

On the "other" side we try to go through the whole stack and go through all the of the application and hit the database as it's supposed to be used by the application.
And that's when it strikes us - this thing with test-data is really hard. And a bit slow also.

Kanban-inizing the Avega Group office–getting the show on the road

This is the second post in a small series on how we helped some parts of the Avega Group office to use Kanban to manage their workflow.
In the first post we introduced the teams that we coached to a foundations for why you want to limit your work-in-process, what benefits that could give them and some key elements of Kanban and Lean.
As a final exercise we helped them to create a simple Kanban board for each team. We stressed the fact that the boards not is complete (at any time!) but should change and this is just a suggestion.

Kanban-inizing the Avega Group office–setting the stage

I have recently returned from parental leave and got to experience office tempo first-hand. Was not prepared for that, but it also had me look around and I saw two teams at Avega Group that was under a lot of stress (they said) and seemed to handle a lot of task simultaneously.

Being dunked deeply in the Kanban-pool it made the hair on my neck stand up and I shivered to my bones. WIP is bad you know…

Being a Avega Coach I have some time to spend at the office, so I teamed up with Morgan, a fellow Lean/Agile coach here at Avega Group – and we decided to see if we could do anything about it.

In doing so we had to sharpen our arguments and think a bit different. They are not creating systems you know. Both Morgan and I have experiences mostly with software development teams, of course. So we saw a great learning opportunity.

This has just started but I thought I’ll try to blog about the experience here.