Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

April, 2009

Change of Address
This blog has moved to
  • Being Cellfish

    Agile Managers


    A typical problem in an organization "starting to be agile" is that some managers (typically middle managers) don't see where they fit into the new process. So in order to complete the transition successfully you need to have especially middle management in the plan. At a talk at Scrum Gathering 2008 it was mentioned that middle managers should be involved early and encouraged to participate in the process of identifying their new roles.

    So what are these new roles? If we use Scrum as an example (because it is popular and has three well defined roles) it is obvious that managers typically don't are part of the team. They're manager and often cannot contribute to the sprint just like any other team member. Managers also typically dislikes being demoted to team members. They worked hard to be managers...

    So many managers thinks Scrum master sounds like a new cool title for them. I think this is where many companies go wrong. The Scrum master is not a manager. It's a coach, facilitator and guardian of the process, the team and product owner. As such the Scrum master must be skilled and be really excited about the cause. Another warning. Even when the manager actually has the skills and desire a Scrum master needs it might still be a bad idea making him a Scrum master because of the risk that the team will hear him speak as a manager and not Scrum master hence "following orders" rather than "listening to advice".

    So that leaves us with the product owner role. In my experience companies successfully adopting Scrum tend to make their former managers product owners. This way their old management backpack does not affect the team's evolution and also the managers are doing what they've always done; prioritizing and deciding what the team should do (but now in a new way).

    Sometimes the manager is not skilled enough to be a product owner because someone else has more knowledge of customer requests and so on. Don't panic! In my experience people with good knowledge of what the customers really want often feel they have little  or no time to spend with the team. So even though this is not an ideal scenario the former manager can step in as a product owner proxy when needed. You can also be assured that the team will come up with a list of impediments they cannot solve. So you as their former manager can come to their rescue help the team unblock some impediments.

    And even if you're not the Scrum master nor the product owner you can still help the team by coaching them toward "better". For more tips on what managers can do read about daily stand-ups and impediment involvement.

  • Being Cellfish

    Definition of Done


    Your favorite agile literature probably talks about the importance of defining what done means so everybody (team and product owner if we use Scrum terms) knows what we mean when we say something is done. And having a catchy acronym to remember what your definition of done is is in my opinion a good thing.

    When I did my Scrum certification a few years ago I learned an acronym that was a suggestion for what done meant. The catchiness in this acronym is that it is the Swedish word for done:

    Kodat - Coded/Implemented
    Levererat - Delivered/checked-in/published
    Accepterat - Accepted i.e. solved according to agreement
    Redovisat - Documented
    Tested - By developers and QA
    So translating this to CDADT or IDADT isn't really that catchy in my opinion. My current team came up with a different acronym without really looking at the Swedish example. The result:
    Designed - discuss design/solution with peer(s)
    Implemented - for code: coding guidelines including comments apply
    Reviewed - Solution reviewed before check-in
    Tested - work with QA to make sure team tests everything QA wants team to test but not things QA will test anyway.
    Now that's a catchy acronym in my opinion! Especially since it is supposed to increase quality. Irony is so funny in my opinion...
  • Being Cellfish

    Kanban vs Scrum

    Yesterday Henrik Kniberg published this draft on Kanban vs Scrum. I think it is a great article describing the differences (and similarities) between Scrum and Kanban so you should take the time and read it since there are times when a Kanban approach is better than a non-Kanban approach (and vice versa). I also like the fact that Henrik ends his article by pointing out the importance of retrospects. And if you wonder about when to have retrospects in a team using the Kanban approach I suggest reading this.
  • Being Cellfish

    Team Rules


    Some teams come up with a number of team rules that are posted next to the task-board. The idea is to have a number of rules that everybody in the team are committed to follow. And there is typically one rule at the top:

    Anybody can remove a rule they are not committed to at any time, this rule excluded.

    I think this is a great exercise to force the team to talk about their expectations on each other. Because rules can be anything from detailed practices to general things. So the discussion is actually more important than the resulting list of rules in some cases.

    An observation we made in our team when we recently had a team rule discussion is that the word "rule" implies a punishment when not followed. So in my opinion a better word for this exercise is "team values" because that's what we're discussing. A number of common values that the whole team have the same understanding of. Because if you just list a number of values without discussion the meaning, then different people with interpret them differently. So what kind of values can a team come up with? Well here are a few examples:

    • We should always check-in better code.
    • Our definition of done is XXX.
    • We should eat lunch together each day.
    • We should use TDD/BDD.
    • We should respect meeting start- and end times

    Do you have more examples of values you think a team should consider?

Page 2 of 2 (14 items) 12