Software Development Priorities, Values

in that order…

  • Readability
    • try to let every change make it easier, quicker to understand, learn, remember
  • Maintainability
  • Changeability, evolutionary design

.
.
.

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.

Intrapreneur Canvas

An internally focused exploration of an idea is different from an externally focused one. In my experience, noticeable differences have been related to market, revenue, customer etc. F.ex, relatively small potential improvements in work within main value streams could clearly dwarf size of investments, or have been considered already.

Anyway, here’s a kind of intranpreneur canvas that’s been useful for me a few times lately when thinking about building new software.

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:

Lean Decision Filter

“What should I work on next?”

Yuval Yeret quotes David Anderson:

  • Value trumps Flow – Expedite at the expense of flow to maximize value
  • Flow trumps Waste Elimination – Increase WIP (work in progress) if required to maintain flow even though it will add waste
  • Eliminate waste to improve efficiency – Do not pursue economy of scale

See also Al Shalloway on Lean thinking about waste in software development – it’s not about optimizing and reducing the use of “resources” (to quote a tweet by @drunkcod).

 

Developing in the Cloud

So I don’t have much time for hobby projects… And when I do have time, it is from various computers, with various setup.

That’s why I’m testing the following combination of online services, and so far it looks promising for my needs…

Slack is Unplanned Improvement Work

Full utilization cause delays - http://agileconsulting.blogspot.no/2011/07/explaining-why-limiting-wip-is-so.html
Full utilization is not effective, not efficient, and causes delays

Being busy all the time is bad for you, your team, and your organization.  It is far better to allow for slack, which is not a bad thing, but creates opportunities for improvement without needing to schedule them.

“Recipe” for what to work on next, incorporating slack:

  1. Can you help progress existing planned, started work?
    Work on that.
  2. Can’t do that?
    Find bottleneck and help work to release it.
  3. Can’t do that either?
    Do some (improvement) work which

    • won’t create any work downstream,
    • will improve future throughput, and
    • can be paused as soon as existing kanban related work is available.

A bit more reading related to slack.

#techsafety

At LKNA13 in Chicago this year I listened to @JoshuaKerievsky talk about #techsafety.

He made me think about quite a few aspects of safety and injuries for a programmer. Here’s a few quotes and elements:

  • safety on team (ref own dev competence)
  • «working with CVS is hurting my soul.»
  • safe from uncertain work situation
  • safe to deploy – bugs, crash
  • safe from pressure – politics, policies
  • Emotional Injuries: Schedule Stress, Lost Respect, Fear of Failure, Torn Trust, etc

What’s interesting is his claim that having #techsafety as a primary value would be profitable and produce outstanding results. I think I buy into that, even if he hasn’t had time to prove it yet with his own company, @IndustrialLogic.

A few twitter notes from the session.

Edit: Joshua have written on #techsafety himself: