AgileDashboardKanbanScrumUser storiesVideo

Working software over proce$$es and fools

Quite frequently people in agile (and non-agile) projects or at conferences and workshops come up to me and ask me what tooling they should use. “Which online agile dashboard tooling do you recommend us?”, “What is the best code repository?” or even “We are doing a Scrum project. Are we allowed to use a UML modeling tools such as Enterprise Architect in Scrum?” In all situations, I reply using the all-time favorite Scrum Master – which I’m not and never will be – response: it depends. Not because I don’t know much about agile tooling, but because there’s many different sides to the subject. To be honest, in my opinion, the discussion around agile tooling is expanding faster than the universe. 

Agile hippies and Scrumdamentalists

First of all, there are groups in the agile community – if there ever was a single one – with highly idealistic attitudes, where people have this almost John Lennon-esc view of how agile will make the world a better place and will bring world peace at last. This is a world where all tools are considered evil, and are comparable to releasing drones in Afghanistan. A world where using tools feels cheating. These agile hippies as I refer to them rely heavily on the left side of the Agile Manifesto. This is where “Working software over comprehensive documentation” turns into “No, we don not document in agile projects,” and where “Individuals and interaction over processes and tools” become “No, you’re not allowed to use a modeling tool in an agile project.” To me, although this is an interesting view, it is also a rather naïve way of looking at the world of agile.

 image

Next, there are what I refer to as the Scrumdamentalists. With the rising popularity of agile and agile approaches such as Scrum and now Agility Path – basically Scrum but with the word “enterprise” added to the names of all the roles and deliverables – many newbies have enrolled in Scrum Mastery; well-willing people with brand new certificates but hardly any real-life experience in agile projects. Scrumdamentalists will follow the Scrum Guide, which they consider to be their bible, quite literally. Now the Scrum Guide is an interesting read as it comes to tooling, as it hardly discusses tooling. The Scrum Guide does not refer to unit testing frameworks, or how to set up your dashboard, or even where to store your user stories. In fact, the Scrum Guide does not even mention user stories. At all.

The agile suits

On the other, total opposite side of the spectrum, we find the vendors. Agile is more and more becoming a vehicle to make money. We already had a plethora of monopolized certification programs – or scams if you wish – to make money from, but more recently we are seeing that agile principles and techniques are penetrating board rooms of large enterprises. Hence the sudden need from agile methodologists to quickly come up with enterprise agile approaches. Think Disciplined Agile Delivery, SAFe and Agility Path – which, with the risk of being called blasphemous, you could describe as the Scrum Guide with the word enterprise taped to it. 

image

And when there’s enterprises involved, there’s tools to be sold, and there’s money to be made. So the vendors, which I refer to as the agile suits, enter the agile arena as well. Some vendors are achieving this by displaying agile street credibility, such as Atlassian, who print t-shirts for nerds – yes, which I do wear – and send funny video’s on how to pair program out on YouTube. As you can imagine this strategy goes down quite well with the agile hippies. Other vendors such as IBM Rational, have long established board room credibility, and have found ways to sell their often quite expensive and extensive tool sets to CTO’s and CIO’s. Tools that are often not specifically targeted at agile, but have been lying around on shelves anyway. A company I know just bought around a million dollars worth of tooling on a large vendor’s application lifecycle management platform to run their enterprise agile projects. Same ball game, different strategies.

Fuzzy

But let’s be honest, besides these somewhat black-and-white views on the world, it is virtually impossible or at least undesirable to run an agile software development project without tools. If you are trying to organize your rehousing using agile techniques – which I did once – just using post-its on the kitchen door can be enough tooling, but not when you’re delivering working software. For instance, there seems to be little debate about using a development environment. Think Visual Studio, Eclipse, IntelliJ. And although I’ve seen passionate discussion between developers about which development environment to use, nobody will dispute that you need one.

But after that, it gets more fuzzy. When discussing agile tooling there is a wide variety of categories to consider. Are you discussing Scrum Boards, Kanban Boards, agile dashboards or Task Boards for instance? Most co-located teams use post-its on the wall, but distributed teams are going to have to rely on something more electronically organized boards. But then what? Mingle? Trello? Speedbird9? Jira Agile?

On my current project we have set up a special room with projector and comfy seats just for doing demo’s and retrospectives. Oh, and for doing modeling sessions, because we are using a modeling tool for use cases and domain modeling – Enterprise Architect in this particular case. So can you use modeling tools in agile projects? Well, I think you can. If you really need it. I wouldn’t recommend setting up a modeling environment such as Enterprise Architect for a six week mobile project, but if you intend to rebuild all administrative systems of let’s say an insurance company, a modeling environment is indispensable.

And what about bug tracking? We do need tools for that, right? Should we use Basecamp? Or should we use Jira instead? Recently I visited a project where the tester explained that whenever he found a bug on a feature he was testing, he created an issue in Jira. The developer then could pick it up from Jira, and work on it. Sounds reasonable right? It’s just that in this project both the tester and the developer are always working on the same feature, and they are literately sitting back-to-back in the office.

And what about bug tracking? Management reporting? Tools for unit testing? Integration testing? Continuous integration? Continuous delivery? Are you getting on the continuous delivery train? There are even so many categories of tools, that it’s almost impossible to name them all. If you had enough time, you could probably create a short list for each of the categories, but then again, every project if different, so the requirements for tools in each project is likely different too.

YAGNI

This is where, as often, the YAGNI acronym comes in handy. You Ain’t Gonna Need It. You will need to pick the right tools for the right job. If your just hanging up a picture on the wall, a hammer and nail will probably do the trick, but if your totally reconstructing your kitchen from the ground up, you will definitively need other heavier equipment.

Software development is not much different when it comes to tooling. If you’re a two man co-located team, post-its on the wall will do fine, and you can easily produce your burn-down chart on a piece of paper or an Excel spread sheet. If you are an international trading company that develops new software around the clock with a highly distributed team of for example requirements people in Singapore and New York, analysts in Stockholm, developers in Poland, and testers in Germany, as I’ve seen recently, you might best consider using a complete application lifecycle management platform.

At last, some guidelines

I do feel sorry if you hoped that this article would present you with the out-of-the-box right tool choice for your project. I am unable to make such recommendation. Your project can and is very likely very different from mine. It might have a different number of teams, a different number of people, different technology, and a different geographical distribution of people. There is no one-size-fits-all agile tool set, as there is no one-size-fits-all agile process.

However, I do want to leave you with some practical guidelines when it comes to choosing a specific tool set for your project. So here they are:

  • Start minimal. Always start with the minimal set of tools that will do the work for your current situation. It is always easier to add tools later, then to have to remove tools which you’ve been using for half a year just because they didn’t add much value.
  • 3M. If you are a co-located team that is not re-building the entire application landscape of a large insurance company, my favorite 3M tooling will do the job nicely: start with post-its on the wall.

    image
  • Track your items. But, always start with tracking the progress of your work items from day one in the project, whether these are user stories, features, smart use cases, chores, bugs or whatever your doing. This way you at least have data on your project from the start, and you can start counting and measuring at any point in time, which you will want eventually.
  • Yes, Excel. As developers, you might have a big grudge against Microsoft Excel (probably because it’s the favorite tool for project managers), but I’ve seen many projects that have used a single (not a hard disk full of them) spread sheet successfully to keep track of everything you will need to know in your project. Think of burn-down or burn-up charts, retrospective outcomes, velocity numbers and current work item statuses.
  • Only add when needed. When starting with a minimal set of tools in your project, for some reason, at some point in time, you will realize that some element of your work could be optimized by using a tool. Usually you start to realize this during a sprint´s retrospective. Only now figure out what you’ve been missing, identify the minimal set of requirements for a-tool-to-add, and than simply choose the cheapest and best fitted product to add to your eco-system. And this tool doesn’t have to be the absolute best or most bling-bling rich tool you can find on the planet. Just keep it simple.
  • Don’t get religious. Many people in the Scrum community feel that it is mandatory to use user stories as their unit of work. However, if you consider the Scrum Guide, the phrase user story does not even appear in it. With tooling, it’s not much different. I’ve had many discussions with people who feel very religious about one tool or another. Jira is a good example. There’s nothing wrong with Jira, but it is by far to be considered mandatory in Scrum projects. Nor is it mandatory to even use an online issue tracking tool. Especially when the whole team is in the same room.
  • Agile tools don’t exist. Also, don’t let others judge which tools you can or can not use in your agile project. Or even worse, which tools are agile or are not agile. In my humble opinion, there’s no such thing as an agile tool. Tools are either fitted to your project, or are not fitted. I’ve been using UML modeling tools and model driven development tools successfully in many agile projects, despite the fact that some zealots think it is not agile to use such tools.
  • No free lunch. There’s no such thing as a free lunch. Every tool comes with consequences. Post-its will eventually fall off the wall. Free online dashboard tools are often limited to a certain number of users, of are only available for free for a certain period of time. Frameworks will version. Make sure you realize the consequences. By default, any automated tool you add will create a (vendor) lock-in.

To wrap things up, I’m sorry that I’m unable to give you more concrete tooling recommendations. Every project is different, and agile is a sliding scale. Personally, I consider it wise to start small, and only add tools when the add value, instead of starting with a fully integrated application lifecycle management support eco-system. And at last, always keep in mind that a fool with a tool is still a fool. The same goes for agile fools with tools. 

Note. This article will be published in SDN Magazine 121. See also: SDN Magazine.