Backlog tools are seldom the first-order problem in an organization. And even the best ones can’t solve the first-order problems for you. However, bad tools do get directly in the way of your transformation efforts. That’s why it’s useful to tell one from the other.

 

– God bless me, but the backlog, is very like a list! (adapted from John Godfrey Saxe)

Having been involved in the development of a backlog tool (that’s Agilefant, nowadays known also as Nektion) since 2004, I’ve been a long time dismayed by the quality of the tool reviews out there.

I know, it’s individuals and interactions over processes and tools but bear with me here. Tools are seldom the first-order problem and even the best tools can’t save you. However, bad tools do get directly in the way of your transformation efforts. That’s why it’s useful to tell one from the other.

Unfortunately, most tool reviews seem to be camouflaged marketing, huge tables or lists consisting of extremely shallow observations of the tools’ capabilities and/or copy-paste from the vendor’s sites. I honestly don’t know why these are done in the first place! Perhaps virtual name-dropping gets you traffic?

Gartner’s magic quadrant reports seem to come the closest, but they, too, suffer from staying at a superficial level.

Another confounding factor is that as SAFe and the like spread further, the vendors’ marketing folk pick up that this is something their product should be able to do as well. And they go and change their website to say that surely their product supports SAFe whether or not that actually is evenclosely the case in reality. Of course similar things tend to happen to everything which has demand – like it has for Agile, Scrum, Lean or Kanban.

If there was a clear upside to doing good tool reviews, surely someone would have done so already. And kept at it, because whenever I have found something that might be useful, it’s cut short after some two posts.

So, while producing useful tool reviews will probably prove to be a futile effort in ways I don’t yet foresee, I’m willing to take my chances and try it.

But before going into the actual reviews, in this post I’ll lay some necessary groundwork.

SO, WHAT MAKES A TOOL GOOD?

In my experience, the “goodness” of a tool really comes down to three things:

1. The conceptual strength of the tool
2. How easy it is to get started
3. To what degree you can tailor and adapt the tool as you learn more of what you need

I’ll try to elaborate a bit on what I mean by these below.

1. THE CONCEPTUAL STRENGTH OF THE TOOL

At the heart of the challenge is the concept of ‘product backlog’ and being able to support how it’s supposed to work. While that might sound simple – “just list the most important items” – taking a closer look at what has been said about it will reveal a vast landscape of needs.

Exploring that further would be a subject of another post itself, but you can get a taste of what I mean by skimming through chapter 2 of “Towards Agile Product and Portfolio Management”.

2. EASE OF GETTING STARTED

The ease of getting started is in direct contradiction to the conceptual strength of the tool. This makes things challenging.

I’ve seen cases where people want to start by getting a board-like view for the company’s high-level initiatives (a ‘portfolio kanban’, if you will). But equally crucial is the need to support a single team in its daily work.

While Trello might, with individual boards, cater to both of these needs, its conceptual strength stops short when people start wanting to combine these views into a coherent whole.

From the portfolio perspective this can expand into wanting swim-lanes for ‘strategic themes’, roll-upped progress metrics based on the epics’ breakdown and so on.

Likewise, on the level of the individual team, being able to tie the team-level work items to the big audacious hairy goals of the company is something that may help guide the decisions. As expert work such as programming is essentially problem-solving, and there are many ways to solve problems, an understanding of the big picture helps the team align their solutions to the company goals.

Either way, you have to start somewhere, and if the conceptual strength gets in the way of just jotting things down as you would on post-it notes or a paper notebook, it will cripple the drive.

3. TAILORING TO YOUR NEEDS

To be able to combine both the easiness of getting started and the conceptual strength, you need to be able to adapt and grow the tool as you need to, creating new concepts and relationships and renaming the old ones.

This makes it possible for the tooling to grow with you. Otherwise, you have to force your way of working to the model enforced by the tool. This could be a “big hairy proven framework” which incarnates the latest version of the Unified Software Development Processes or Capability Maturity Models of late 1990s – or something else which doesn’t quite fit your reality.

No matter how enlightened, if a big model is forced on the organization too soon, the result will be co-optation: your system projects will be cast as ‘release trains’, your component teams as ‘feature teams’, and your non-customer facing business units as ‘value streams’. In such a scenario, the tooling wille become a strait jacket. In such a case, if you are going through with your transformation, not only will you have to change the organization, but also dismantle the tooling.

An important but fairly simple as well as often overlooked part of tailoring is being able to rename the concepts in the tool.

While choice of names will matter in the long-run (think of for example, ‘projects’ vs #noprojects), in a transformation you want to be able to pick your fights.

Will you, from the get-go, have to convince your C-level managers to talk of Epics, Sagas, Novels and Steam Trains or simply Business Value Proposals and Projects like they’ve used to?

THE CANDIDATE TOOLS

At the time of writing this, I’m considering to take the following tools under a closer scrutiny; in alphabetical order, these are:

• Agilecraft – the self-claimed leader which to date has not lent itself for easy sign-up and tire-kicking
• Agilefant – the open source version from 2014 – as a baseline
• Favro – the offspring of Hansoft from Sweden
• Google Sheets – not because spreadsheets are that good but because they just might be better than anything else
• Leankit– I’ve heard good things about this, though nowadays it has been acquired by the more traditional vendor Planview
• CA Agile Central (formerly known as Rally) – first IPO, then going to CA to die?
• Taiga – the other open source tool worth mentioning
• Targetprocess – long-standing original thinking from Belarus
• VersionOne – besides Rally, the other U.S. based ‘enterprise agile’ vendor; nowadays acquired by CollabNet, which already many years ago swalloved an early player, ScrumWorks

Of the obvious possible choices, I’m skipping JIRA, at least for now. This is because of my customer engagements. I am anyhow in the process of writing a separate thread of posts covering it.

I’m also skipping big software houses’ such as HP’s, IBM’s and Microsoft’s offerings, even though nowadays they, too, claim to support “agile”. I may be wrong in doing so, but for some reasons I can’t quite verbalize, I don’t feel it’s relevant to address them. And you can read how they by some strange mechanism get put up as leaders anyway from any Gartner or Forrester report.

So that’s it for the groundwork, and stay tuned for the first review. I will be backlinking the results to this post, and following Nitor on Twitter you’ll hear about it among the first.

If you have suggestions for tools which I should take a closer look at, or want to affect the order in which I go through the candidates, get in touch!

– Culture is the product of the system; change the system and behavior changes
(John Seddon)

As a community, advocates of agile often seem preoccupied with the notions of culture and mindset. Even when people who have been involved in successful transformations actually talk about structural changes, they tend to refer to it as “changing the culture” – for example in these presentations by Mirette Kangas and Fred George.

This emphasis on culture paints the picture where “if you just change hearts & minds and train everyone, self-organization happens and things fall into place”.

My journeys in enterprises have taken me to places where seemingly everyone was trained in “agile” but as the key structures remained unchanged, the impediments persisted.

In one organization, “Done” did not mean that something was deployed and running in production. Done merely meant that the feature had been handed off to the Q&A and release organization. And as there was no easy way to measure the time in the Q&A and release phase, they measured the time spent in the development phase and called it the ‘lead time’. As we pointed this out and went on to explore this further, we discovered that for features that had been developed in 1-2 months, the total lead time could be as long as 18 months.

Another common example of a structural problem comes from contractual issues. In one organization, the people were excited about the new ways of working, and most had been trained as well. But upon asking if they could mix the current, component based teams to form cross-functional feature teams, the answer was a disheartened sigh.

After a bit of prodding, it was revealed that because of the outsourcing contracts in place, this was considered impossible. Moreover, the outsourcing had resulted in a considerable amount of offshoring. This had led into people on different sites specializing further into certain kinds of tasks. Because everybody had to have something to work on, prioritizing according to highest customer value was not possible.

And as the people who were responsible for the contracts did not feel the pain, nothing was done about these issues when the contracts were eventually renewed.

You cant’ change structure bottom-up

Organizations tend to grow so that when problems occur, specialists are hired to take care of them. Over time this results in organizing such specialists into their own resource pools. Then work gets done by handing it over from one pool to another. Such structures are in direct contrast with the notion of cross-functional feature teams and organizing around delivering value to the customers.

In my experience, the drive to adopt agile often arrives at organizations at the level of development managers and team leads. However, the prevailing structures can only be changed by C-level executives, and hiring a “VP of agile” will not be enough.

Take it from the thought leaders

It doesn’t help that currently the most popular framework for scaling agile, SAFe, is not that explicit (at least compared to the total amount of material in the framework) of the need to change the structures. Examining the structures lurks under the notion of “applying systems thinking”.

To me SAFe has seemed almost surprisingly agnostic about the matter as it allows “development value streams” and says that “there is no one right answer”. The fine print does warn though that with development value streams you will end up with a lot of dependencies.

I had the chance of discussing this with folks from Scaled Agile Inc. They consider it a conscious choice: it’s better to get a foot in the door and then proceed to help the client from there instead of getting completely turned down as a result of proposing radical changes up front.

While that may be true, there are thought leaders who criticize SAFe from SAFe from the point of view that because of the sheer amount of material, it can easily turn into scaffolding for the legacy organization to hide behind.

Also some thought leaders have taken the notion of changing the structure as a central part of their teaching. In fact, they consider the preoccupation with culture as failure demand caused by the inability to change structures.

They articulate this so well that I’ll step aside here and provide a few pointers so you can delve deeper into the matter.

The ones I’ve raised here work quite well even if you only listen to the audio, so you can explore them while for example commuting. These speakers have also lot of other presentations available on Youtube which further deepens the point. Here’ I’ve tried to pick those presentations that most directly cover the point I’m trying to convey and put them into an order they are most easily approachable. Enjoy!

Four presentations worth checking out

 

Author	Presentation	Quote
Mike Cottmeyer (2017) @mcottmeyer	Is culture really the issue? (Youtube, podcast)	“Most organizations are deeply flawed from the perspective of delivering value. Teaching them to want something is not enough. At some point you have to do the work of removing the impediments. And if the impediment is 2M lines of legacy mainframe code in a key business system, you just fix by the next sprint”
Craig Larman (2016) www.craiglarman.com	More with LeSS: a decade of descaling with LeSS @ Agile Munich meetup (Youtube)	“I can quickly spot a young naive change person when they say you have to change culture; you can’t change culture”
Jason Little (2017) @jasonlittle	Rethinking agile transformation (Youtube) @ Agile Montreal	“Co-optation is the most common mode I see. A VP of agile is hired, the structures persist, we do things as we always did them, and the agile is put in front of everything.”
Dan North (2017) @tastapod	How to break the rules @ Goto 2017 (Youtube)	“In companies we have a huge number of rules to cope with the limitations of the old way of working. In a transformation we not only have to dismantle them but also come up with the new and mostly very different kinds of rules to manage the new limitations”