Duplication is not efficient – don’t encourage it

In the digital world that we live and work within, I find it interesting how some project management approaches are still encouraging the frequent use of pen and paper to capture requirements and track progress. Even Agile, a methodology which I adore and evangelize prefers this, but I’m far from convinced.

My biggest concern with this approach is duplication. The time spent to physically write requirements or tasks onto an index card is largely wasted as it will need to be reproduced within a software tool also. Having a physical sprint board hanging on the wall with the user stories attached may give a nice visual representation of progress – but for the team only. Again, this data will need to be reproduced digitally and, critically, updated frequently as stories move back and forth, get reassigned or closed.

From experience (and I appreciate that I’m generalising a little), a developer wants only to log into their task system, work on and complete a task that is assigned to them before closing it off or reassigning. The suggestion that getting up from your desk and physically moving a card from “in progress” to “done” is a little too idealistic for me to digest. 

It’s a novelty which will wear off quickly.

It isn’t just for requirements or user stories either. Considering that our tablets, laptops and mobile phones all talk to each other and share the same data, why make meeting notes in a notepad when you could make them digitally once and have access to them wherever you are. Distributing typed notes and actions from your iPad immediately after the meeting has concluded is efficient. Taking time to decipher your written notes, re-word and eventually get into the hands of those who need to see them is not. And that’s assuming you can find your notepad and single copy of your data.

I’m labouring a point – but it is true. Duplication is not efficient.

I’m not blindsided or stubborn enough to notice that there are some benefits to working with physical materials. Collaboration could be considered easier when sat around a table moving index cards around, for example. In addition, if your project team is working on internal development and does not require separate reporting (or in other words, your stakeholders are based in the same location and can visually see the sprint board) then duplication is minimal and it might work for you.

Weighing everything up, my point still stands. Digital companies spend a lot of time investing in automation and limiting duplication of work for one single reason – to increase efficiency. Why then, would you add a project management layer on top of this which forces keeping two different systems in sync and updated. Change something on a physical user story card also means tracking it down within the system and updating it digitally also.

If you can remove an hour’s worth of work from a Project Manager or Scrum Master’s daily schedule by avoiding the need to duplicate data, that is surely a worthwhile consideration for any sensible structure.

Agile is becoming the norm – coach it but don’t force it

In the last decade, we’ve seen many changes around the attitude towards the adoption of Agile as the default project management methodology when it comes to delivering software development projects. The Agile framework has gone from the untrusted, untested new kid on the block to the established veteran that the majority of modern development houses are adopting to deliver their software.

We’ve seen a huge shift in not only the way in which we tackle project management from a supplier point of view, but also the attitude towards Agile from clients. It goes deeper than that – in the past, the project management process used to deliver a project was just something that went on in the background. The client didn’t really care themselves with how something was delivered as long as they were supplied with an end product eventually.

When adopting an Agile framework, it should be treated as a selling point – a key ingredient in why your project is going to be a success. Gone are the days of the black box where requirements went in and a product came out – in the modern era, collaboration is key and it should be something that both sides of a project team should absolutely thrive upon.

As a company, you could have the best process in the world but if your client does not want to work this way then there is little point in trying to force them into it, or you’re just going to damage your relationship. Educating or coaching them on the process benefits however is something that should be encouraged, being careful not to undermine their current preferred way of working. In time, any of their concerns with Agile will be alleviated through careful coaching.

As Agile has become more known in the industry (at least, clients know enough about Agile to think that they want to use it), these barriers and uncertainty levels are starting to disappear. Agile, when implemented correctly, is every bit as professional and governed as the more traditional Waterfall or PRINCE2 approaches, and companies are starting to see this.

The proof, they say, is in the pudding. And if you’ve managed to work with a willing client on an Agile project, any remaining doubts are normally erased once the first sprint demo has been completed and the client can physically see what the project team has been working on. Project metrics still remain a critical element of tracking project success, but for many people there is no better metric than something tangible that you can see and interact with yourself.

This is now the way of thinking from a client perspective. Not only do they now have requirements in what they want delivered, but how they want it delivered is starting to become a factor. As more and more Agile success stories roll in, everyone wants a piece of the action. It’s our job, as project managers, as coaches, as anyone involved in software delivery, to embrace this, coach it and use it as another key reason for doing business.