Tag: agile

visualization board tools

first: you should visualize more.

then:

there’s several things to consider when selecting a board tool. what types of work do you have, what abstraction level is useful to visualize, etc. is any tool already in use and known? how does types of work behave, how much reality is useful to visualize?

there’s roughly 3 types of boards when I look at visual tools.

(first: a swimlane is a visual element separating a type of work vertically. in a grid-based board it’s end-to-end, from left to right, but the columns/ phases are the same for all swimlanes. in a more flexible board it can be a vertical split within a column/ phase, having it’s own customized sub-process.)

1. simple lists.  examples are:

  • trello,
  • o365 planner boards, where there seems to be a shortcut to attach documents from a teamsite related to the (context of the) planner board

2. grid-based boards.

i’ve seen two types of rows in grid-based boards, one where you can define your own end-to-end swimlanes, and one typically used in scrum where each user story is a separate row/ swimlane.

one example is jira boards, in which cards mostly are jira tickets.

3. more flexible boards, that can reflect a more complex reality regarding how different types of work items flows through different phases, subcolumns and sub-swimlanes reflecting custom sub-processes etc.

an example here is LeanKit.

if guided by any kanban (thinking tool) toolbox, remember:

  • start where you are – visualize current state, work behaviour first, then improve step by step (and update visualization in step with that)
  • YAGNI, you ain’t gonna need it, unless you experience that you need it… so start simple unless you see that you need something less simple (f.ex a custom sub-process, a new work type/ card type, etc)

reading tips: kanban learning center by LeanKit, incl Kanban Roadmap/ how to get started, and some howto-s.

regarding board tools, please feel free to share any tips on visualization tools you’ve experienced as useful in your own work.

Daily Meeting Checklist

Are work boards updated?

– at least regarding your own work
– “No“? let’s take a look

Are there any issues, problems?

– “Yes“? let’s talk about it…

Can you answer “what’s next”?

– (for you)
– at least until next daily meeting
– “No“? let’s take a look…

  • Can you join existing planned, started work?
  • No? Can you help with any bottleneck, problem?
  • No?
    • A bit much work in progress?
      => Do some improvement work
    • Lastly: consider starting new planned work

Remember:

TDC 2012

Yesterday I attended TDC.

It was fun to see so many from the software development community in Trondheim turn out all at once.

I also had a short talk about better ways to work, focusing on delays and feedback – especially how it’s more central to knowledge work than we think.

Here’s the slides if you’re curious (PDF):
201210 TDC Better ways to work

Update: I added a few slides for a talk at the office – see extended version (pdf) if you like, containing a few more links/ reading tips.

 

 

Lean Coffee: Democratic, Responsive Meetings

Lean Coffee is a meeting format where you don’t finalize the agenda before the meeting starts.

It can take place in a café, but also in a meeting room, living room, or almost anywhere.

The topic is often Lean, Kanban, agility in business and product development (like software development), but the format lends itself to any topic.

An example of established groups meeting for lean coffee is Lean Coffee Oslo.

These groups are people meeting on their own time to learn, but this format has big potential benefits in business context as well.

Lean Coffee at a café

A few quotes from LWS on Lean Coffee:

Essentially, a Lean Coffee is a group of people working together to learn … in an informal setting.  It’s like a mini-unconference where the participants decide on the schedule.
….

Step 1: Everybody writes down topics they’d like to discuss on stickies ….
Step 2: Each topic is briefly described …
Step 3: … votes …
Step 4: … stickies with the most votes at the top
Step 5: Each of these stickies are discussed
Step 6: If enough time … do another stickie

A few quotes from @ourfounder and @sprezzatura on why democratize meetings:

Agendas are so 20th Century.
….

When you set an agenda, you control the conversation. …. When you control the agenda, you control the lessons learned. Since we enter a meeting with only our assumptions to guide us, agendas follow our assumptions. Our assumptions are based on what we already know. But what about the things we don’t know? Quite often, it’s the conversations we don’t plan on that give us the most insight. Why not instead run our meetings to learn or to discover?
….

Conventional wisdom suggests that businesses hold far too many meetings attendees deem a waste of their time. ….  To combat this, some call for meetings with rigid agendas.
….

the discussion of a stated topic is a conversation. In fact, the entire reason we are calling the meeting is to have a conversation.
….

If we want to learn from our meetings, we need to allow the conversation to be set by the very professionals we invited to the meeting in the first place.  …. Allowing the group to have a say in setting the agenda gives them buy-in for the importance of the topics.
….

as the person who called the meeting, you can now direct the overall topic and even seed a few of the initial sticky notes. You can even set a few “must discuss” stickies at the top of the board and prioritize them the highest.

Notes:

  • Takeaways
    • either privately or f.ex a right-most column on the board
    • per topic or sharing takeaways in general at the end of the lean coffee

Read more:

 

What’s In a Kanban Standup?

First and foremost:

Focus on work items, not people.

Then:

Finishing is more important than starting.

Practical tip: start to the right/ at the end of your board, and identify impediments to finishing tasks as you go upstream on the board.

Only two questions are really necessary in the actual standup if the team’s real process is reflected on the board:

 The team will be asked if the board accurately reflects what is being worked upon. The team will be asked if there is anything that is slowing down or stopping throughput. After these two questions are answered by the team, the stand-up is over.

(Karl Scotland via @dpjoyce.)

Update: a few more reading tips.

Agile Version Control

The goal is to enable you to be more agile, i.e., to improve your ability to change and adjust.

Here’s what I think:

Mainline and CI

Branches and merging
  • Beware of feature branches, and kill them as soon as you can if you do use them. (One tip: feature toggle)
  • Branches: Merge from mainline every day if you have them.
  • Good naming goes for build code and infrastructure, too, so I’d prefer branch names like mainline, release, featureA, fixB
  • Limit branches agressively – they represent more work in progress (and you want less work in progress) including risk of big merges
  • Agile version control for multiple teams
    Illustration from Henrik's article

    Merging: merge down, copy up – always accept stabilizing changes, never impose destabilizing changes.

Inspiration:

Martin Fowler: articles on continuous integration

Henrik Kniberg: Agile version control with multiple teams

Extracting a Personal Kanban from an Overgrown ToDo List

Last week I looked at my overgrown todo list, or rather several lists, and preparation for a demo at work was coming up, and I have a long trip to prepare for… So I simply had to create a personal kanban on the cupboard behind me:   Collaboration on the demo preparation led to tasks on the board, and I took the most important and urgent tasks from my todo lists onto the board. I used a form of priority filter, with a generic todo column to the left, then a “soon”/today column, then the usual doing and done columns. It worked really well to let tasks float up and to the right in the todo columns, kind of like bubbles. I got an immediate impression of relative urgency (more to the right) and relative importance (upwards), making it very easy to decide what the next task should be when I finished a task.

How to Get Started with Kanban, and Why

Monday February 7 I talked about Kanban at Trondheim XP & Agile Meetup.

I think it went well, even if I made a few presenter mistakes, based on feedback and the great questions and discussions.

Here’s the presentation with a few adjustments, like a few additional links for further reading.

How to Get Started with Kanban, and Why