Article originally published at www.scrumalliance.org.
You can find the original article here.
I’d like to share my experiences in working both with and without tools designed for a specific purpose.
I worry when colleagues and teammates talk about principles. I am concerned about the frequent transformation of principles in diktats, because many of us often tend to interpret principles literally. The more we are at the beginning of our learning path on a specific topic, the more we apply principles literally, and the more we tend to misunderstand them. In my opinion, slavishly upholding principles does not help with effective learning, and I prefer a teacher who is moderate in his beliefs. For this reason, I was impressed when I first read the Agile Manifesto values. The values are all expressed in this form: “We value this more than that.”
The thing that impressed me is that right after the enunciation of the values, the authors explained why they expressed the principles in such a form. They specified that they saw value in all the items, but they placed higher value on the items on the left: While there is value in the items on the right, we value the items on the left more.
I can appreciate such an approach, but it still needs some explanation in specific contexts and situations.
Individuals and interactions over processes and tools
When expressing sentences in such a form, it is easy to get the first part and overlook the second part, or the items on the right. People are inclined to think of the element on the right as the “evil side.” This is a dangerous effect, and I am particularly interested in and want to focus on one of the Agile values that says Individuals and interactions over processes and tools.
Indispensable enablers
We know that there is great benefit in underlining how most of the value is gained if the work is centered around individuals and their interactions. Yet, to perform effectively, I think that a good tool is indispensable. More than this, I think that the less experienced we are, the more we need a good tool to help us.
Maybe I have a bias in interpreting our experience, but I still want to share it.
My team is part of an IT department that is immersed in an Agile and collaborative culture. Agile Manifesto principles permeate choices and actions, even when people are not conscious about this influence. Individuals are the focal point of every action in the following ways:
- The environment in which our team acts valorizes people and their relationships.
- The preferred way to find solutions is to talk with people and ask for advice.
- The suggested way to fix ideas is to share acquired knowledge and mentor peers.
- Product design emerges from the continuous collaboration between internal customers and the development teams.
- Full attention is given to personal growth and development and to individuals’ realization.
- Teams and individuals actively contribute to continuous improvement of processes and relationships.
Processes and tools
A few months after our team was formed, we developed an infrastructure and reorganized the tools. As a side effect of this reorganization, the tool we used for our product backlog and for other Scrum artifacts disappeared!
The ineffective tool experience
We soon migrated to a new tool developed by a big vendor but, unfortunately, we ran into problems. For example:
- We could not delete items that were mistakenly created.
- The tool lacked common built-in queries, such as “My items in the current sprint.”
- The tool had a terrible click stream (three clicks to access the product backlog) and an overall bad user experience.
- It offered no easy way to view stories and tasks together from the same interface.
It was our only tool, so we had to go with it.
After a few weeks, and because we were uncomfortable working with the tool, we experienced some negative side effects:
- Team members often forgot to update their status, thus negating the usefulness of the task board.
- The team subconsciously avoided backlog refinement, because changing tasks or splitting backlog items was an arduous process.
- Developers worked on items that were neither in the sprint backlog nor in the product backlog, since they were incomplete and no one wanted to fill in items.
- Often implementations were not driven by requirements, resulting in mismatches between code and the sprint backlog.
What do we need?
Based on this experience, and in agreement with IT management, we decided to allow the team to abandon the tool and try to customize Microsoft Excel files.
The goals were to:
- Empower the team.
- Give the team time to experiment.
- Let the team define the requirements that they wanted in a tool to help them with their Scrum practices.
We created a few standard files for the product backlog, sprint backlog, and acceptance tests. We then checked them into a configuration management system and shared them with business stakeholders. For several months, we worked with the Excel application as our only tool.
Obviously, it was not an optimal solution, and we knew it. We had been uncomfortable with Excel from the beginning, but we were free to find out what we really needed. After almost one year of working that way, we knew exactly which actions were the most common for the team. Moreover, we knew that we needed to carry those actions with no corresponding overhead in our definitive tool.
All the bullet points should have been natural actions in the work flow. This was not the case with our previous tool and with the Excel files. All these actions were painful to carry out, and no one wanted to spend time working out the kinks, thus forcing the ScrumMaster to become a Guardian of Scrum! He was always busy inspecting artifacts and asking team members or business users to reformulate, prioritize, update the status, or close items.
All the processes appeared to be bureaucratic in nature, producing no added value.
Finding an effective tool
A new tool appeared on the horizon!
After months of cumbersome tasks and processes, the team was enthusiastic about its new tool adoption — everyone had been exploring and using the tool.
The current tool is far from perfect, but it addresses the team’s critical needs:
The previous boxes highlight obvious and simple needs, yet these features are not easy to find in common enterprise tools.
Though many requirements are still not addressed, the most important ones are addressed at an acceptable or working level, and we can appreciate the results. In the sprints following the adoption of the new tool, we observed a renewed enthusiasm for the Scrum framework. Team members were able to really work for the sprint goal, reducing scope creep and removing the need for one member to coordinate everyone’s work.
Everyone contributed to the sprint artifacts, helping the ScrumMaster and product owner to become helpful team members instead of mere writers and coordinators. This contribution avoided having to fall back on the command-and-control approach.
Sprint after sprint, the team was able to better inspect the sprint results and adjust their estimations and commitments for the next sprints. Having a real sprint backlog that is easily accessible helped members commit to realistic goals, thus contributing to everyone’s satisfaction.
Tools have their place
In the end, if you do not have an acceptable tool to enable Scrum, your team might have a difficult time working toward sprint goals and managing backlog items. Be mindful that the problem is not Scrum itself but the tools that facilitate the Agile processes.
To work with no overhead, identify what the team needs most and promptly provide a tool that addresses those needs.
In my experience this appears to be an indispensable baseline for further enhancements.
