Roles & the Definition of Done

If you’re building a team from scratch, this part is actually quite interesting and I’ll try not to talk too much about maturity of process at this stage as I think that subject is actually worthy of a post of its own.

Selling Agile

If I asked everyone how long a piece of work would take, and then I asked them how long that piece of work actually took. Some would estimate too little, others, too much and some will estimate just right.

But if I then asked how close was the product to what the customer had requested. No one knew.

So I set a sequence of meetings for the team with some expectations as to what I was aiming for in each meeting.

Meeting 2; Roles & the Definition of Done

Kanban is quite simple compared to something like Scrum and the roles are the first simplification;

• Product Owner
• Team Member
• Product Owner

The Product Owner is one of those roles that doesn’t feature in all kanban implementations, but I like it because it pushes some responsibility back to the people that want the products and as a result, the Product Owner has a hugely important role to play.

The main responsibility I give to a Product Owner is to define their Definition of Done. This is a useful way of avoiding an unhappy customer, if they said the product needed to X things and the team committed to that, the customer needs to raise any changes to the spec at a product review. Reacting to change is a key component of Agile, but agreeing on a definition of done allows the team to focus on an end goal.

Team Member

The team members are the people that deliver the product, there’s not a lot more to say about it. You may have specialists (Kanban supports the role of specialists over generalists, another excellent reason to use kanban for operational teams) or you may have generalists. These people may focus on specific areas, such as 1 or 2 Designers vs 2 or 3 Developers vs 1 QA, for example.

However, as we found from playing the games in the first meeting, no one can add new work to Doing if the WIP limit has been reached, so no matter how many specialists you have compared to generalists, you should expect the team members to work as a team and help move beyond a block.

Definition of Done

If you’re building a team from scratch, this part is actually quite interesting and I’ll try not to talk too much about maturity of process at this stage as I think that subject is actually worthy of a post of its own.

The Product Owner or your Project Manager needs to bring each of your projects to the meeting, again, a big wall and a lot of sticky notes is a nice interactive way of doing this part.

In my opinion, it is really good to have these sessions as a team rather than asking a Product Owner to relay it to a Project Manager who then relays it to the Team.

Get the Project Manager or Product Owner to list their projects at the top or side of a wall/whiteboard and then challenge the Product Owner(s) to define what their Definition of Done would look like. Use leading questions, such as;

Would you be able to sign-off on that?

Is that a must have or a nice to have? Encourage the team to ask questions based on their knowledge of the subject;

• What are minimum user counts?
• What are peak user numbers expected to be?
• How many active links are there?
• Who owns the current process?
• Who owns that dependency?

Try to make a card for every question and for every answer, these material will be used in the next meeting when we start to build a backlog.