I have worked with a couple of agile teams in the past few years in different stages of agile transformation. I have experienced a pattern that I would like to dig into in this post.

What does that mean?

These teams has long and deep discussions about the scrum / kanban / agile board and their colums. When and how to move a task? What circumstances, conditions are allowing the moving of a ticket?

I have seen 20+ pages “Law of Scrumboard”. A book including checklists, rules and handovers how people should behave.

I might become boring but I visit the the agile manifesto again and again:

Stop for a moment and visit the Agile Manifesto
medium.com

Collaboration!

The collaboration part of the agile manifesto has a special place in my heart.

I think all the rituals — for example in Scrum — has to help and enable collaboration. Handovers has to be a natural part of the process based on confidence, not based on regulations. It is no way to have a law for every situation.

I would like to encourage you to agree on a Definiton of Done, that reflects the team’s best intensions about what is good, when things are done.

Here is a few questions you should be able to answer:

• What does quality code mean for the team?
• What is the expected output from a review?
• How to act and communicate with the stakeholder for succesful delivery everyday?
• If there is an issue: How to ask for help?

A Defintion of Done

A good defintion of done shoud focus the followings:

• There is always a story behind the assignment. Take your time, talk to the stakeholders, the users. Invest into grabbing onto their story, their motivations.
• A solid story, also including the expected results. That can be a description of an expected behaviour or some other measurable results. These are the artefacts for validating your solution. You are building confidence by testing the code against them.
• Collaboration has a bigger context. Yes, good team collaboration is crucial, but you need the stakeholder and the user with you on the whole journey. An assignment shouldn’t be a “Fire and Forget” thing. It is the interface between you and them. Ask for being present, ask for availability. Arrange weekly demos / status meetings ensuring collaboration.
• Agree on a scope but keep the discussion open about what are the must haves and what are the nice to haves. Something might be important on day one, but might be less relevant after the first demo.
• And there are always unknown

Handling the unknown
There are things known and things unknown and in between are the doors. — Jim Morirsonmedium.com

• Talk about timing, deadline and their priority. Many times timing is important but a feature that requires more time can be just as important.
• Strengthen the confidence in quality with continous and automated testing instead of a handovers. You had demos. You are practicing continous delivery. It should be good enough.

Definition of Done
The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a…www.agilealliance.org

I was focusing on Definiton of Done, but you can apply all these thoughts on other parts of the process, like Definition of Ready or Release.

Don’t hesitate to dismantle bureaucracy and replace it with collaboration, because you are doing it for the good:

for happy coding!