I am Michael Allen

Your Security Accreditor is not (ever (never ever)) a User

2015-07-09T12:46:00+00:00

This post is part of a series of Rules of thumb for writing Agile Stories

In the last post in this series, Rule 4 - Many Users of many types, I gave a very loose definition of what I call a user. That was:

A user is “someone who will use a product of our teams work to do something”.

Some people this doesn’t cover are: your Security Accreditor, your Chief Technology Officer, your Single Responsible Officer, the team themselves. These people can never ever be users. That’s a pretty bold statement but I think I can back it up.

Introducing Butler

2015-04-16T16:48:00+00:00

I am a supremely lazy person. With the rise of wrappers like virtualenv, bundler, foreman, etc, I find the shell commands I need to remember getting really long. Things like:

Run only unit tests

foreman run python test.py unit

Run the database migrations

bundle exec rake db:migrate

Start my java app

java -jar target/my-java-app-0.1.5.jar

I figure someone else should be remembering those for me. Ideally I should only need to remember migrate to migrate the db and unit to run the unit tests.

Many users of many types

2015-03-27T11:23:00+00:00

This post is part of a series of Rules of thumb for writing Agile Stories

There’s a problem with the “As a user…” that never sat right with me. Who is the user? What defines a user? I think there’s too much focus only on the “typical” user, the person sitting in front of a browser registering to vote, or viewing their Driving License, etc.

I don’t agree.

Who-What-Why not Who-What-What

2015-03-26T10:23:00+00:00

This post is part of a series of Rules of thumb for writing Agile Stories

A story is formed of three parts. Who has the need, What is the need and Why do they have it.

A rookie mistake I often found myself making was confusing the Why and the What so that my stories read like this:

As a User
I want to do the thing
so that I have done the thing.

A story like this isn’t useful because it doesn’t describe the Why.

Embed context in your stories

2015-03-24T12:30:00+00:00

This post is part of a series of Rules of thumb for writing Agile Stories

As a User I want…

What is the User doing? Why are they here? What is their motivation? Is the kettle currently on?

Ask why first

2015-03-19T19:38:00+00:00

This post is part of a series of Rules of thumb for writing Agile Stories

The first thing we do when writing a story is describe what it’s going to do. Usually a short name for the story has been described and we’ve been talking about the story for a few minutes (or maybe a few hours) before we decide to actually write the body of the story.

Say something like:

Name: “Do Thing”

When we sit down to write the story the first thing everyone wants to write is what it’s going to do:

Name: “Do Thing”
I want to do the thing

It’s the natural thing to do.

Rules of thumb for writing Agile Stories

2015-03-19T19:17:00+00:00

TLDR: I’m using these rules of thumb when writing stories for Agile projects

Rule 1 - Ask why first
Rule 2 - Embed context into your stories
Rule 3 - Who-What-Why not Who-What-What
Rule 4 - Many Users of many types
Rule 5 - Your Security Accreditor is not (ever (never ever)) a User
Rule 6 - It’s a problem, not a solution

How many times have you read the following:

As a User
I want to do the thing
so that I have done the thing.

or:

As the Accreditor
I want to ensure you have done the thing
so hackers can’t do this other thing.

or even:

As the team
I want some other team to do this thing
so that our Users can use our thing.

If you work in an Agile team I guarantee you’ve seen those stories. You may even have a set of them on the wall right now.

Overuse of reuse

2014-12-15T12:49:00+00:00

I’m currently working with the Department for Work and Pensions and I’ve found that not everyone means the same thing when they say “reuse”. This has led to me sitting in meetings telling people “this won’t be reusable” to people who think reusable means something different than I.

As I see it we are building a single service that will be deployed once and other services will hook in to it. I’d call that “sharing”, it’s a form of reuse but it’s not the only one. It’s also worth noting that it’s a very hard thing to do.

Five nines

2014-11-26T21:13:00+00:00

I wrote this 2 months ago at the end of a long project. Now having recently finished Alpha on a new project for DWP that was even more challenging… I wish I had listened to my own advice.

Using Mustache on Register to vote

2014-08-05T15:28:00+00:00

One of the more interesting stories that came out of our work on Individual Electoral Registration (IER) was our adoption of Mustache, a logic-less templating language.

The brilliant Tom Byers and I have wrote up our process of migrating to Mustache templating on the Register to Vote exemplar.

Unconference

2014-05-13T00:34:15+00:00

A few weeks ago during Kainos kickoff event I ran a short unconference for our GOV Business Unit, the unit that focuses on Government projects like the Government Digital Services.

TL;DR - It was great fun and well worth the time: Photos, Session topics, notes from the sessions to come soon.

Self-documenting using pattern matching

2014-03-30T14:15:21+00:00

I’m a big fan of self-documenting code. The idea is that code is written in a language humans can understand for a reason. It isn’t meant to be read by a computer, that’s why we have compilers and interpreters, it’s meant to be read by other people. Or in fact by yourself, weeks or months after it was written.

So if code is meant to be read by people then it should be easy to understand.

Secondly code is written to fill a purpose. A purpose usually described in a story, or a requirements document depending on your teams process, that once finished usually will never be looked at again.

On Register to Vote we have quite a lot of rules and laws we have to follow, often confusing and convoluted. Rather than writing extensive documentation explaining why the code does what it does, I’ve been making a point of trying to document the business rules in the code itself.

As it happens Scala has a very handy set of pattern matching abilities that has made it very easy to do this.

Why I want to write

2014-03-29T15:25:00+00:00

The “Hello, World!” post of a new blog is a difficult one to get right, hopefully I bypassed that one last week with my first post.

Before I start in earnest though I thought I should explain why I want to write. It’ll be interesting to, after a few months, write a follow up to this and see what I have actually got from writing.

Git init; git commit -m 'first post';

2014-03-17T18:01:12+00:00