Should you have a set number of acceptance criteria?

Should you have a set number of acceptance criteria?

A conversation came up today in which a statement was made about having a set number (three, in this case) of acceptance criteria per user story. My gut reaction was that I didn’t agree, how can you define that? But then I got to thinking that maybe it wasn’t such a bad idea.

I turned to the internet and asked twitter, the replies were heartening.

I agree with these replies, however, I’m not convinced on having a fixed arbitrary limit. I think it’s a case of being vigilant and for someone to say “Hey, that’s a lot of A/C, maybe we should split this?”

It’s also relatively simple to avoid the limit by loopholes. For example, your A/C could be described as Given, When, Then. In this, you could add “and then … and then… and then…”. It’s still one A/C, but has multiple steps.

As with everything in the world of building software, it’s about balance and discipline.

Advertisements

A great retrospective!

A great retrospective!

I’ve blogged before about remote teams where I am now and how well we manage to make it work, even with people in another timezone. Because we’ve got people remote, our retrospectives are, naturally, done over video chat (hangouts in our case) and we use webwhiteboard (by none other than Henrik Kniberg!) to make it as interactive as possible.

Today, we had just such a meeting and I really wanted to show you the output. Nothing much to learn from this post (except how we retro), but I thought the webwhiteboard worth sharing – just for fun.

Selection_003

Nothing is immutable

Nothing is immutable

“But they’re the project goals!”
“So what? They’re not appropriate any more.”
“But they’re the project goals, you can’t change them!”
“Watch me.”

Challenge everything and remember, nothing is immutable. If you make your project goals redundant (and you should always try and prove the negative hypothesis), you’ve made a huge discovery.

Nothing is above the laws of science – hypothesise, test, learn.

Dancing to the wrong beat

Dancing to the wrong beat

It’s something we’re not going to get away from: mashing traditional projects and project management with agile. You know it as many names – waterfall, scrumerfall, scrumbut – each as bad as the last. It comes in many guises: time lines, gantt charts, milestones and my favourite, governance.

You can have timelines and milestones, they’re not too far removed from Release Planning, as coined by (and then retired by) Mike Cohn. Gantt charts are OK, if you turn them on the side and use them as a product backlog, but something I cannot really get behind is governance.

Now, there are a truckload of different types of governance, but what I’m talking about is “agile governance”. Brian Wernham talks about it an an APM blog post here and it’s an interesting read. Essentially, it’s a sponsored, empowered set of controls. You could argue that the blog post is over 18 months old and not relevant anymore, but my experience says otherwise.

Sounds crappy, huh?

The idea of governance is that it allows a group of key project people (think stakeholders and team members) to get together regularly in a room and talk about the project. Not altogether too dissimilar to sprint demo, except the governance meeting is future looking and the demo is a view of the last itertion.

The trouble with the governance meeting is that it tries to tie you into a plan, “What are we going to do next?”, “When can we have X thing?”, “What are our biggest risks and how do we avoid them?”

But the biggest and most troublesome problem with the governance meeting is compounded during an “agile transition/adoption”, you can bet your ass that before a company started being agile, they had governance meetings and so, after the adoption, continuing with the governance just helps to reinforce bad habits and out of date ideas on how “projects” should work.

The meetings cause anxiety – instead of going into it (as in a demo) with a list of things to show for your effort, you’re going in with a list of problems that, if you could solve them, you already would have, so they’re unsolvable right now and not worth talking about, they just make you more anxious. You’re going to talk about the future of a project with some of the wrong people and not all of the right people – afterall, it’s a team sport – why leave some of your A players on the bench? Many of the people in that room will not be in your team and not be accountable for the work that get’s done, the planning or the outcome.

Push to get rid of governance and provide everything anyone needs at your demo. It’s the only way we’ll make any real progress on a project. I think that the GDS has got it mostly right. It’s the government, so they’re going to have governance, but they couch it in these terms

GDS has defined 6 principles for governing service delivery. Following them should help you create the right culture within your service. They are:

  1. Don’t slow down delivery
  2. Decisions when they’re needed, at the right level
  3. Do it with the right people
  4. Go see for yourself
  5. Only do it if it adds value
  6. Trust and verify

See what it doesn’t say there? It doesn’t say weekly (or regular) meetings with the same people just to see what the status of a project is and complain when it’s not “on schedule”. Head through to the Governance Principles page, it’s an excellent and enlightening read.

It’s not often anyone can say “let’s be more like the government”.

#agile slack channel – http://hashtagagile.com

#agile slack channel – http://hashtagagile.com

I’ve started a new Slack channel called #agile. You can find out more and signup at http://hashtagagile.com.

A while ago I started a #people Slack channel, for discussion around HR, management and people ops. At the moment there are ~260 people on that channel. It’s not always busy, but there’s usually someone to ask about things, or just have a conversation with. I looked for a similar channel for agile discussion, but came up short – so, I thought I’d make my own.

There is no shortage of forums and websites, communities and clubs with which to talk about agile, ask questions and get answers. What there isn’t, though, is somewhere to get live chat, instant replies and all the other good stuff that you get from something like Slack. #agile is a chat community for talking about all things agile: from software engineering to scrum mastering, methodologies, culture, process and anything else.

So, if you’re interested in chatting with other folk about all things agile, then head to http://hashtagagile.com, sign up and join in the conversation. It’s a bit quiet at the moment, as it’s only just started, but all it needs is your voice as one of the founders to make it useful.

The secret of #noEstimates

The secret of #noEstimates

I’ve not really understood the no estimates movement. I’ve read a bunch of blog posts and followed the twitter hashtag and discussed with friends and peers, but it just seems like a different kind of estimating, albeit using empirical evidence (not that story points don’t).

Anyway, the secret is this: INVEST.

If your stories adhere to this acronym, then you’ll be able to do #noEstimates and, by “adhere” I really mean, be “Independent”. I believe this is the one most important things about the movement – being able to make decisions about what to build and deploy, how to prioritise and project comes down to the quality and size of your stories.

The trouble is, that is really, really difficult.

How to have better remote team meetings

How to have better remote team meetings

Where I work now, half the team is based in Romania. Yes, they’re an offshore team, but you wouldn’t think it the way they integrate so well with our teams, tools and general day-to-day. One of the things I was way of when I started, was how they would get involved with team meetings, like planning, stand-ups, retrospectives, etc.

I’ve experienced people joining team meetings remotely before: there’s a room with most of the team in, sitting around a table and then one giant talking head on the screen (it’s even bigger on a projector screen). It takes real discipline and frequent repetitions to make sure the remote worker is included in the conversation and gets the value they need and the common understanding the team needs.

However, at my current job, we do it slightly differently. Instead of booking a room and having one or two talking heads, everyones does the hangout from their desk instead. The key thing to experience here is that everyone is “remote’ in that they’re dialling in.

It levels the playing field for the whole team.

Yes, it levels it lower than in-person meetings and you have work hard to make sure it works, but I’ve been surprised and impressed at how well these meetings have worked. Especially complex meetings that involve more interaction like a retrospective.

It’s not perfect – it’ll be a long time before remote team meetings are on par with IRL ones – but it certainly helps keep remote members feeling included.

Ways and Means committee

Ways and Means committee

The inaugural meeting of the Ways and Means committee convened at ThoughtWorks Werkstatt Berlin on the 31st of March. This first event of the committed brought together tech industry people from all over Europe. Hosted and conceived by Dmytri Kleiner and Dino Frese from ThoughtWorks, the Ways and Means committee is a group that aims to help tech leaders share experiences, discuss problems and cultivate a network of a trusted peers with which to seek advise.

This meeting asked the question “Why do sprints fail and what can we do about it?”. We were not looking to solve the industrys problems in a single session, but really, to see what kind of things that, as tech leaders, are within our power to influence.

After an introduction presentation from Dennis Traub from ThoughtWorks and a conversation starter from Mike Pearce from MOO.com, the session broke into groups to brainstorm just why sprints do fail. The teams jotted down ideas on post-it notes with no filtering, trying to capture the behaviours or conditions required for sprints to fail. Once that was done, we grouped similar post-its toeether and identified the following themes as being categorical causes of failing sprints:

  • Stakeholder expectation management
    • Some examples of these kind of issues were stakeholder patience, predictability issues, lack of transparency, bad requirements and stakeholder mandated solutions
  • Team Culture
    • Picking the “easy” bits of “agile”. The inspect and adapt loo is missing. People are “convinved” to commit to too much work.
  • Bugs and Fires
    • Business as usual will always be a fact of life, how do we deal with these kind of things without losing momentum on what really counts.
  • Process as ritual
    • When you decide what to do, you decide how you’re going to do it. But many become slaves to what is laid down as process – unquestioningly following it without really understanding why. The backlog becomes a theological debate, velocity is the only truth of progress etc.
  • Purpose/vision/Focus
    • Why do we do what we do? What is driving is to build these particular feature? Lack of understanding around what the purpose

Given we had three teams and limited time, we dot-voted on which were the themes that we’d most like to discuss further. These were “Stakeholder expecatation and management”, “Team Culture” and “Process as Ritual”. We agreed that our goal, like the original Agile Manifesto, was to come up with a set of principles that could guide a team when coming up against any of the above problems. As we weren’t able to solve for every issue that we had recorded (and frankly, wouldn’t be able to) principles were a better way of providing broad guidance for a multitude of sins without being too perscriptive.

So, after some lengthy debate, these were the principles that we created.

  • Stakeholder expectation management
    • Values and Metrics: Meet a business value over showing productivity.
    • Transparency and Dependencies: Transparency over commitment
    • Milestones and continuity: Goals over features
    • Goals and business value over showing productivity and finishing features.
  • Process as ritual
    • Question the process
    • Don’t be a backlog pack-rat (don’t keep every story for the sake of theology)
  • Team culture
    • Agile has to be cultural (not from a scrum manual)
    • Culture starts small. Build organically, infect and contage.
    • Hire to cultural fit
    • Teams should look at their own balance of culture, but needs to work bottom-up-top-down.

We closed the session with a mini-retrospective on how we should continue with the Ways and Means committee, the general consensus was that it should be a little longer, less warmup and more discussion and that we should communicate by way of a mailing list.

At the risk of repeating myself about what agile is…

At the risk of repeating myself about what agile is…

It is not a set of practices. There is no silver bullet, golden nugget or platinum compass. The agile manifesto is a set of values and principles that have learning, excellence and collaboration baked into their very heart. They will not prescribe how to deliver valuable, delightful software, they will not explain whether TDD or BDD is best. They do not insist that you use a product backlog, user stories, story points, iterations, stand ups, demos, code reviews, peer programming or continuous integration.

“Agile” adoption will not help you if you do not understand this. It will not help you if you are conflating “scrum” with “agile”. It will not help you if you do not truly understand what it is you’re getting yourself into.

… agile is defined by its principles rather than specific practices.

– Mike Cohen

The agile manifesto is what it is: guiding principles and values that empower you to make your OWN decisions on how to deliver valuable software (or anything for that matter).

Are you intelligent? Do you do intelligence?

Are you intelligent? Do you do intelligence?

Well, are you? Are you intelligent? Or perhaps you do intelligence. Do you? You do? No.

No, you don’t do intelligence just as you don’t do clever and you certainly don’t do agile|Agile|aGiLe.

I read this article today Kanban Is Not Agile and I’ve read a few others like it in the past. No, Kanban isn’t agile. But neither is scrum or DSDM, or crystal or SAFe or whatever.

You cannot DO principles and values, you are principled and you hold values. When someone says “We’re agile!” challenge them, ask “What does that mean?” because I can almost guarantee they’ll say “We do scrum|kanban!”. You’re following practices that stem from upholding the values and principles of the manifest, but you’re not doing agile.

What’s more and what will hold business back until they realise it, is that while these values and principles are software-centric, they certainly aren’t software dependent. If you distil the values and principles, you get things that any one can uphold, regardless of industry.

You don’t DO agile, you ARE agile.