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.

Reflection on the result for the teams

First week

The immediate and positive responses from the group was reactions like:

• “This is very clear and shows us what we are doing”
• “I can see dependencies between our tasks. And on the ones where we wait for...

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...

This is the second post in a series detailing how we assisted some teams at the Avega Group office in implementing Kanban to manage their workflow. In the first post, we introduced the teams to the basics of Kanban and Lean, emphasizing the importance of limiting work-in-process and the benefits it could bring.

In this post, we’ll cover the initial implementation of Kanban boards for the teams and the early reactions to this new workflow system.

Setting Up the Kanban Boards

Together with the teams, we created simple Kanban boards tailored to their needs. We stressed that these boards were not final and should evolve over time. Here’s what we set up:

• Inbox – This column acts as the team’s to-do list for a comfortable horizon. We didn’t impose a limit on the number of items here but suggested they consider it. Items in this column...

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 were under a lot of stress (they said) and seemed to handle a lot of tasks 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 an 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 differently. They are not creating systems, you know. Both Morgan and I have experiences mostly...

There’s been a lot of buzz around Specification by Example lately, especially in my circles. Recently, I was asked to introduce the topic to a group of interested individuals. Interestingly, the conversations I encounter are predominantly among business analysts, testers, and not just developers.

A common question that often comes up is:

Who writes the specifications? Business people, developers, or testers?

The underlying intent behind this question seems to touch on issues of ownership and collaboration. Drawing from my experience in a recent project and insights from Gojko Adzic’s book, I’d like to share my perspective on this.

Key Process Patterns

Gojko Adzic outlines seven “key process patterns” in his book on Specification by Example. These patterns are essential practices that contribute to successful implementations of Specification by Example:

1. Deriving Scope from Goals – Establishing the scope of a feature or iteration based on...

I received a question from three colleagues about what Twitter is and how to use it. While I don’t consider myself an expert, I use Twitter frequently and have compiled an introductory guide with my own tips on how to navigate it. There are other resources available, such as this one by Scott Hanselmann, but here’s my take on it.

What is Twitter?

According to Wikipedia:

Twitter is an online social networking and micro blogging service that enables its users to send and read text-based posts of up to 140 characters, informally known as “tweets.”

You send short messages (tweets) that are visible to anyone who follows you. You can also follow other users to receive their updates. Most of the content is public (with some exceptions like direct messages) and can be viewed by visiting your Twitter page. That’s...

Right away – this blog post is mostly for me. I have not been dabbling enough with the “dynamic” keyword to say that I know it. This is what and how I understand it now.

So, if you care to read this… please be gentle with your comments. I love to see them and learn that I was wrong – I’m most certainly am.

dynamic keyword

Since .NET 4.0 we have a new keyword – dynamic. If you read the MSDN documentation you’ll learn that:

The dynamic type enables the operations in which it occurs to bypass compile-time type checking. Instead, these operations are resolved at run time.

Ok, but what useful is that? I mean you could write this, you probably shouldn’t but you could:

// Any object can be typed dynamic // The dynamic keyword just means...