The Agile Tooling Debate
We have had many debates over the last couple of years on agile tooling, what works and what does not work. When agile is scaled and needs to solve enterprise wide problems, the reality is that agile tools are a must.
Manual interactions and collaboration between people becomes too time consuming and it is difficult to coordinate schedules to have all the right people in the same room at the same time, needless to say the endless fight about the boardroom roster and then there is the argument of having to form cross-functional teams with no need to collaborate with anyone outside of their 5 – 9 boundary right? Wrong! If you are considering reaping the benefits from becoming a true agile organisation, using the power of technology in tools is inevitable and the only way to get you there.
An organisation of over 150 people can only get benefits from agile if some level of automation and agile tooling is considered to facilitate collaboration and inter-dependencies across multiple boundaries of the organisation.
Here are some of the main very entertaining points we have heard over the years, all arguing against agile tooling, even calling the use of it dysfunctional. We are arguing otherwise and maybe it is because we have had to solve these problems first hand in organisations over 500 people and not quoting from text books.
What this Agile Tooling post is NOT about
So what this post is NOT about: startups, managing agile in dev teams being totally oblivious as to what is happening in the rest of the organisational world and new age technology organisations that managed to build their organisation right from the bottom up with little chaos and a product that they own without having to deal with different clients having conflicting goals or needs and their clients are really arms-length.
What this post IS about
What this post IS about: the gap agile tools fill where manual approaches to agile adoption falls short and creates too much administrative overheads, how to move from old organisational structures to new, modern agile organisations while minimising risk.
Agile Tooling – Why you need it
Interaction and people over process and tools
So many people diss the use of electronic boards over manual boards, saying that manual boards are about interaction. And having big TV screens visible to the whole team where we have stand ups around is not?
So now the next argument is going to be that the whole backlog is not visible on an electronic board but on a wall as there is bigger real-estate on a wall. And how does this relate to the initial discussion about interaction and manual tasks boards? Not sure, but here’s our response anyway.
We respond to that by saying that how do you get a whole backlog onto a wall, then it is all of a sudden not about having the whole backlog on the wall and if you do, you have a different problem…
So lets be honest about this. Most people that are so anti-tooling have never implemented an agile tool successfully and they are only focused on agile at a team level.
What we have found is that organisations that have helped with agile tooling address agile at an organisational level, and not a team level.
If you are considering agile at organisational levels, do you want to have this view using stickies and spreadsheets?
Or this view, which is the best of both worlds, consolidated into 1 single view with visibility of who is using what and when. Nothing else needed.
Ironically, many agile teams with manual tooling still use Excel to share with the rest of the organisation and to record metrics. Is that not a tool?
Let the devs choose what they want to use
So what is the problem with this approach? When adopting agile people need to go through a big change and here we are referring to the size of change in medium to big organisations, not start-ups. So they need a framework and guidance as to what to use. Small organisations are by nature agile and often get away with a lot by doing what they want. What we have although seen is that once they get ‘bigger’ clients or the organisation’s size goes beyond 20 the need for more ‘governance’ and better agile tooling is always a given, always. So when we start working in organisations where people got to choose what they want to use, collaboration and interaction were fragmented across different ‘tools’ (stickies, spreadsheets, Google docs, numerous agile tools) and the hidden cost of migrating to a more collaborative toolset that ties things together between teams and boundaries were never considered. We just realise that it is quite irresponsible for teams to make decisions if the true impact of their decisions are not considered or understood and most often not dealt with. As lets face it, no organisation is self-organising, so using that as an argument will be a theoretical debate, that yes, in the perfect world would hold water.
If you want to give people the option to use what they want I would suggest some responsibility to creating visibility across fragmented approaches for people that needs to have a bird’s eye view snapshot, and defining a strategy for providing that view. The problem is that the people in the engine room has often not been in more strategic roles, so it is very difficult for them to have an understanding of problems, risks and worries at higher levels of the organisation where this feedback and visibility actually matters and is not available.
So we will go as far as to say that when making these types of decisions, it should not be made with a narrow minded view. Think about the rest of the organisation, not selfishly about just the team.
Manual approaches add a lot of admin overhead when looking at agile at scale, where agile tools supports scaling, better communication and automated pushing and pulling of work over boundaries. If solving these problems were as simple as forming 5 – 9 man cross-functional teams, everyone would have been agile by now and we will be without work.
Product backlog size
When working on product backlogs we often hear people talking about taking parts of the backlog and prioritizing it. That sounds like a really good idea and we agree.
There is also a saying, the way to eat an elephant is one bite at a time. But you would like to know the size of the beast right? If half of the elephant was hidden behind a tree and not visible to you when planning your approach and strategy on how to eat this elephant, even though it was there all along, you might have come up with a totally different approach to begin with.
So taking a subset of the backlog and getting that visible is hiding the size of the problem. You need a place where you are faced with the total size of your delivery nightmare and then from there filter out what you want to see. Making parts of it visible has the objective to get focus and that is great, but in fact creates a false sense of success and being on top of things if the hidden elephant behind the tree is in fact just getting bigger and bigger.
Being able to map this roadmap, getting an idea of how much capacity you need to deliver this and is your current business model working based on this information, is really important. Getting others to collaborate with this without having to walk to a wall or be at the office is really important.
We have often seen where clients take the most important part of a client backlog and prioritise it all manually with stickies on the wall. The client then throws a total curve ball and de-prioritises the scope of that total backlog piece. Now, there are no easy ways to store all of this IP safely in a manner that makes sense, that can easily be retrieved at a later stage and start with the new section of the backlog that was not on the initial wall…oh and by this time we have run out of wall space as well.
In new IT organisations where legacy structures and approaches are not a problem, this is often not a concern and the flow of work through the pipeline is consistent and moving. So things never really backs up.
In most other organisations however, this is although not the case and having huge backlogs are a real problem. Ignoring part of it will not make the problem go away either.
Automation of pushing work is also an area that needs to be considered when doing agile at scale, as the amount of meetings that is needed to discuss all of this manually is not feasible and often a compliant we hear in companies.
So finding a balance between what allows the CEO to sleep at night and what makes teams happy is essential.
So often people ask, what metrics are you measuring? The answer to this is not only metrics at a team level. The metrics we measure is aimed at monitoring strategic implementation all the way down to team level.
Doing burndown charts & sprint velocity charts etc. is most probably very doable manually on team level. The problem though is that the responsibility comes down on one person for recording the metrics, where with agile tools it is done automatically as each person in the team does his/her bit. So there is a subtle dynamic of doing things by each person taking responsibility for doing it, bit by bit and by having real-time statistics available and visible to the team all the time.
When we start looking at agile on an organisation level, the admin of measuring and informing agility at organisational level is a lot of admin overhead if not using an agile tool to automate some of these metrics.
In agile tools, statistics are collected automatically and as part of the process, without having to put extra overhead on teams and processes and manually coordinating things.
Get real, no exec wants a photo in an exec report that shows the status of an agile team’s task board. Doing comparisons between 2 boards from 1 week to another is also not something that adds value as the data displayed in these artifacts can really not be absorbed and processed easily.
BY: TANIA VAN WYK DE VRIES, CEO AT INFOWARE STUDIOS
Interesting Infoware Studios Bookmarks
- See my delicious