Recognizing a riptide

There is so much advancement of technology, I can’t keep up at the moment.  Chrome, FireFox, Drupal, WordPress, Video, Live Streaming, Angular vs React, SSL, HTTP/2.  Upgrades to the tooling I’ve built have been put off so long, that now they are beginning to be incompatible.

I can see, now, that I’ve been swimming in an ocean of sorts.  There is a strong current of technical change and technical debt, that is pulling me out to sea.

A Riptide!!!!

Now I knew the answer:  Swim parallel to shore to get out of the current, then swim back to shore.

Sideways for a while, it is.

Happy Easter

Some interesting reading time today, it’s Easter and drizzled rain for most of the day, so I layed around with the laptop

I put that one in the idea hopper. SubPub Messaging; scales to 10+M, yow

I read about Simon Greenleaf

While teaching law at Harvard, Professor Greenleaf stated to his class that the resurrection of Jesus Christ was simply a legend; as an atheist he thought miracles to be impossible. In a rebuttal, three of his law students challenged him to apply his acclaimed rules of evidence to the resurrection account.

After much prodding, Greenleaf accepted his students’ challenge and began an investigation into the evidence. Focusing his brilliant legal mind on the facts of history, Greenleaf attempted to prove the resurrection account was false.

Greenleaf was so persuaded by the evidence that he became a committed Christian. He believed that any unbiased person who honestly examines the evidence will conclude what he did—that Jesus Christ has truly risen.

Note 10-1-2017: A reader asked that I research whether or not Greenleaf was already a Christian (Episcopalian) when he wrote this, and I took the challenge.

The story of the challenge by his students can’t be proven and that he was an atheist can’t be proven, nor dis-proven.  I could not find positive proof that he was or was not an Episcopalian, nor active in the Massachusetts Bible Society.

This doesn’t detract from the findings.   Jesus was born a man, crucified, and resurrected.

I can add that one to may existing faith:
John 21:24 This is the disciple who testifies to these things and who wrote them down. We know that his testimony is true.

The Death of Agile

The death of agile?

  • The skills and talents of individual programmers are the main determinant of software quality. No amount of management, methodology, or high-level architecture astronautism can compensate for a poor quality team.
  • The motivation and empowerment of programmers has a direct and strong relationship to the quality of  the software.
  • Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver.
  • The consequences of poor design decisions multiply rapidly.
  • It will usually take multiple attempts to arrive at a viable design.
  • You  should make it easy to throw away code and start again.
  • Latency kills. Short feedback loops to measurable outcomes create good software.
  • Estimates are guess-timates; they are mostly useless. There is a geometric relationship between the length of an estimate and its inaccuracy.
  • Software does not scale. Software teams do not scale. Architecture should be as much about enabling small teams to work on small components as the technical requirements of the software.
    Coconut Headphones: Why Agile Has Failed

The Rest of the Story

Why we moved from Scrum to Kanban

Why we moved from Scrum to Kanban

When I joined my current team, we were a full on Scrum shop: three roles (product owner, scrum master, team), three ceremonies (sprint planning, spring review, retrospective), three artifacts (etc), the whole shebang.  And, it mostly worked, in that things got done, software got shipped.

However, in our retrospectives we had a few recurring issues that kept coming up:

  • Our sprint planning meetings were horrible.  They went on forever (at least half a day), were exhausting, and everyone left them feeling like there must be a better way
  • Testing was always getting squeezed towards the end of the sprint
  •  A reasonable proportion of stories (~30%) fell into the next sprint

When we delved into these, we developed some detailed explanations.

Sprint Planning Hell

The problem with our sprint planning meetings was that nobody wanted to commit to building the story until they understood how they would build it.  Consequently, each sprint planning became a design meeting, and often asked questions that the product owner couldn’t answer, because at that point the story consisted of “As a user I want to A so that B”.
So we moved to asking the analysts on the team to develop a lightweight spec for the story before bringing it to Sprint Planning.
This resulted in the planning meeting becoming even more of a design session, which then often asked technical questions which couldn’t be answered without some investigation.
So then we moved to having a ‘solution design’ session for each story before Sprint Planning, so that there was an approved technical design in place before we did planning poker on the story.
When was this analysis and design being done?  During the previous sprint, of course…

Squeezed Testing

You can’t test until there’s some code to test.  Of course, you can do test prep, you can write the acceptance criteria, you can set up test data, but… ultimately, if you’re a tester, you’re at the back end of the process.  And this is a problem, because any overrun by anyone ahead of you in the process affects you.  Was it ever thus.

Consequently our testers were always under pressure – either they have to bust a gut to test the story before the end of the sprint, or they had to be the bad news bears and tell the Scrum Master (me) that the story wouldn’t be ready and would have to be completed in the next sprint.

Stories Over-running

This issue is really a symptom of the previous two – with analysis and design being squeezed out of the front of the sprint, and testing out of the back, the sprint really just became the actual coding phase of the activity.  We even considered formally moving testing out of the sprint, but I drew the line at that one, and started looking for a better way.

Problems with Traditional Scrum

Based on the above, I thought Scrum had the following problems:

It assumes that everybody can do everything

I’ve never worked in a team like this.  At the very least, all the teams I’ve worked with have a split between analysts, developers and testers.  And within these, there will be people with specific skills – one story might need some serious database analysis, another some significant graphic design activity. Different people have different skills, and whatever process you use should recognise that.

It assumes that developing stories is a single task

Even within the (good) disciplines of a two week sprint, a story needs to go through a number of phases:

  • Elaborate
  • Develop
  • Test
Inside these can be multiple other steps (design, style, review, etc).  These steps are sequential – you can’t style the UI until it has been designed, you can’t test the story until the code has been written.
The combination of these two problems, that building software has different sequential steps and these steps are typically done by different people, led us to look at Kanban.

Why Kanban Works For Us

This article doesn’t have the space to describe the history or background of Kanban – the web is awash with such articles, and I don’t think I have a great deal to add to them.
The key thing Kanban brought to our small team was the concept of flow.  That a story flowed through a sequence of steps, from “As a User I want to A so that B” to some shipped working software.  This flow has a sequence, and some dependencies.  Anyone who’s worked in a team building software for more than ten minutes knows this, so let’s recognise it and make it explicit.

Our First Kanban Board

As is traditional, we got a whiteboard, some markers, some post-its, and constructed our board.  It consisted of six columns:
The next story to be pulled from the backlog
Add detail to the story so that it can be coded, together with a technical design
Write the code
Test the code
Business review the implementation, to make sure it meets the original idea
Each story flows across the columns, and, importantly, is pulled from left to right by the following step.  So, developers pull elaborated stories only when they’ve finished the story they’ve been coding; that story, in turn, is now ready to be pulled into test.

WIP Limits

A key feature of Kanban is its ‘work in progress’ (WIP) limits.  This is the way of defining when a stage in the process flow is at its limit, and no new work should be pulled.  In the early days, we didn’t impose these, wanting to see if any natural limits emerged.  In practice they did, and once everyone realised that the essence is only to pull new work when you have capacity, we had few problems, and didn’t need to enforce WIP limits.

Advantages of Kanban

Having been running Kanban for over a year now, we’ve found the following advantages:


The state of play for the whole development team is immediately obvious to everyone in the office – including all the people who don’t work on the software delivery team. We used to have the Kanban board in the open part of the office, where everyone could see it.  We now have a big screen TV showing the virtual board in our ALM software, but that’s a whole different blog post.
Of course, every article out there on Kanban promotes visualisation as a key benefit, but I just wanted to add my voice to the crowd.

Continuous vs Batch

To me, Scrum often felt like a ‘batch process’ model of software development – you do these things, heave them over the wall (into production) and then do the next things.  Everything had to fit the two-week sprint cycle.  With Kanban, I feel like we’re now using a continuous-flow process – small stories scurry across the board quickly, and can be shipped when ready; larger stories take longer.  I think it’s no accident that this is a good fit with the ‘continuous delivery’ model of software delivery.