In an agile world the definition of done is interesting. Sometimes a feature is considered done, from a developer or development process perspective, when it’s moved to the Done-column. Now it “just” needs to be tested and released. Easy-peasy. Not so fast.

Let’s dissect this statement in to little pieces and go thru them one by one – only then can we understand and form an opinion on the why. Trust me, there are many small concepts hidden here.

Definition of done

In scrum, the team (in best cases) makes up a Definition of Done. This is a “contract” between the team members. It’s important to define this because otherwise we don’t know when we are done. When a user story (or ticket) is “done” and it’s Pull Requested to the release branch (a request to add the code to the next release), it can be considered done. This is just an example. I will tell you the problem with this approach.

Throwing stuff over the hedge

Most developers I have worked with strongly dislikes to be included late in the thought process of a User Story (or ticket). Most wants to understand the problem and provide a solution themselves, rather than just implement the solution given by an architect or the Product Owner (or ticket reporter). So far good. So why are developers sometimes doing the same? Meaning throwing stuff over the hedge in the sense that they want to be done with their ticket once it’s included in the release branch? What about testing? What about informing the reporter? What about seeing it in action? What about integration?

How to disable developers from accountability

The worst thing we can do as team members, team leads or managers is to remove our skilled work force from the decision process, as well as the release process. What I mean is this scenario: Pat is working on a ticket and once she is “done”, it’s being tested by the QA team. They find loads of bugs and discovers scenarios of breaking the code (along with other unrelated stuff) that no developer would have ever thought about. They add so much value…or are they just sucking the energy out of Pat? By giving the testing responsibility to someone else we are removing the accountability from the developers. They are then only a small part of the process, a cog in the machinery. They never see the entire process. In my experience they feel less involved and may even write suboptimal code because they know it’s being tested later anyway, and they’ll have to fix the issues. Of course developers should test their own features.

They are then only a small part of the process, a cog in the machinery.

Another development process

An alternative to all this is to setup a different development process. One that enables the developers. It’s simple yet complex. And it keeps the developer responsible until the real Done.

An example of a Kanban development process:

1. User Story or ticket comes in and gets prioritized by the Product Owner
2. Developers picks up from the top of the Backlog (like in any agile project)
3. Developers are 100% responsible for moving the ticket to the other process states (In Progress, Testing, Blocked, Done)
4. Once the developer has worked on their local, they do a PR (Pull Request) to the testing environment (peer reviewed), where the Reporter or Product Owner checks and reviews the visual implementation and may even show it to their stakeholders. The developer is fully responsible to completely test their own feature. Responsible doesn’t mean they have to do it themselves. Perhaps colleagues can help. Perhaps they build tests. But they are responsible.
5. Once it all is good – and it’s “potentially shippable” – it can be merged to master. Wait what? Where is the release branch? There isn’t any. In a fast-moving Kanban Development Process there is no need to slow things down by doing integration and release via release branches. Instead, it goes straight to master, which triggers a deploy of the branch on the server. This can happen ten times a day if needed. And we get small incremental releases, which removes risk and improves agility.
6. Done.

The above describes the process where the developer is fully responsible from “In Progress” to “Done” without vague areas like “Done-Done”, “Released” or “Done-Done-Done”. Done is when it’s done, when it’s released and in production and it creates value. As with all lean flows, everything we spend time on is a complete waste until it’s delivered. No value at all. Just junk. It’s only when it’s in production, on the website, in full function that it’s creating (potentially) any value. But that’s another post…

• accountability
• Git
• Kanban