Yola & Co. and the Scrum board…(repost)

In 2015 I posted this comic for the first time and it was my first post on agileblog.nl I did. At that time I wrote it (I drew it actually 😉) because I had the discussion over and over again. Fun thing is, it is still a story of my life. This time again, the discussion starts with: “What kind of tooling are we going to use?”. So here it is, a repost with explanation this time.

So there it is, a company that’s scaling the way of working with Scrum. And they are truly scaling with multiple-teams-Scrum instead of what most companies do, multiple-Scrum-teams. They have really thought about the direction they like to go. So it all looked promising at the beginning. Soon after starting the realisation sets in that they still scratching the surface if it comes down to Agile thinking. They are not yet aware about the why’s behind the way how stuff is done in an Agile way.

So here you go again, sitting in a meeting discussing which tool to use as a Scrum board. And again hearing the famous Jira’s and TFS’s from the world of issue trackers passing by. Here are some of the arguments for using a tool you might hear:

• “It’s easy to assign work to someone” (ouch),
• “We have to register the testers’ findings” (ouch again),
• “It is easy because the team is not in the same location most of the time” (ahaaah-ouch-argh…..)
• “We can maintain the Product Backlog in it” (okay, you’re killing me)
• “One can look back on previous bugs and see how it was solved in the past…” (Stop now….you can bury me, I’m already dead)

Now lets discuss those point one by one.

It’s easy to assign tasks.

People, and especially project managers and team leaders, are eager to assign work to resources. Unfortunately this is a form of local optimisation in the form of keeping people busy. On the contrary within Agile environments we try to get the development team members to work together on the most valuable product backlog item first! So we try to get all the team members to work on the same item and with doing so, we facilitate in collective learning, knowledge sharing, co-ownership of the problem at hand, etc. Dividing the work over the team members prevents the team members for having an overview over the bigger picture making ‘assigning tasks’ a necessity and hardens collective learning, knowledge sharing and co-ownership.

Register findings.

Why on earth would someone register findings while we are building the damn thing! Where is the value in that? Now that’s pure waste! The development team work collectively on the most valuable item. This means that the whole team is working on it. And with that I mean, the whole cross-functional development team…..and that includes the tester as well. Look at it as this, I’m decorating the baby room and halfway the ladder I stretch my arm and my wife says: “It’s not good! The wallpaper is not aligned with the previous!”. “Hold you horses lady, the damn paper is still sticking to my fingers and have NOT touched the wall yet 😡!” am I jelling back. This is basically what we do when testers start testing and giving feedback in the form of bugs while the work is still In Progress. It’s the teams collective effort to deliver high quality products so it is generally better to say: “Lets just improve the quality of this feature before putting it to Done!”

Not in the location.

The magic word here is co-location. That’s what is needed for good face-to-face communication which is one of the way for individuals to interact...what happens to be the first value of the Agile Manifesto, individuals and interactions over processes and tools. In my opinion, the first stap for working Agile is not to install a chat client with webcam but putting team in a single room. And there you go, a physical board will do 🙂

Maintain the Product Backlog.

Okay, I have to admit. In my first Scrum team we used Jira as well for the backlog. But guess what? It didn’t work for us as well. After a certain amount of time, we drowned in an endless list of wishes the customer might like to have at a certain moment...maybe. “But we do it for traceability when we get the audits!” Okay, fair point. So they want to know why you altered the production version? We can solve this two ways. First one is to start logging every wish, request, brain fart, etc in a tracking tool. Of those items maybe 20% will make it to production and do you really think the the other 80% matters during an audit? So the second option is, just register the items before starting development in the sprint by the development team. Everything in the tool is done or in progress and will be traceable towards production as part of you’re configuration management. And the backlog? Just stick to Excel! Not bounded to predefined workflows, all fields are freely editable and everyone can edit it simultaneously in the cloud.

Look back on previous bugs.

Seriously? When was the last time you checked the old-bug-database to see if you can find a bug that’s similar to the one you are facing now? In my whole IT career I can remember just one time we have been searching for a record. Took us nearly a week to find it and the bug was not identical and the provided solution definitely not suitable for our case. So unless you are working on a helpdesk or customer servicedesk, registering bugs is useless. Just fix them in the sprint if there are incidents and discuss them in the retrospective.

My summary.

No need for digital Scrum boards. Physical boards facilitate in the communication by: “Hey, I see you’re done with that. Lets start testing it...” instead of *pling*, “Hey, look the tracker system is spamming me again. luckily I got a rule, redirecting this spam to a folder I use to delete once a year...” 😉