Something that I’ve been playing around with for the last few months in my to do app of choice, Todoist, is seeing if I find value in using the Eisenhower matrix to help me prioritise tasks.
But I have encountered a stumbling block when I consider this for use in a personal context: what do I with the “Delegate” label (urgent but not important)?
Continue reading Eisenhower matrix in personal projects—what does urgent but not important mean?This week it was revealed that car hire company Hertz has sued Accenture for US$32 million for failing to deliver either a functional website or mobile app during a 16-month digital transformation project.
While there is a lot that could (and will) be said about this. It’s quite remarkable that even now digital and software development projects are still being carried out using traditional ‘waterfall’ project management approaches with all the design and planning done up-front rather than using an agile, just-in-time approach.
In every project there are four key elements:
Whether these elements are regarded as fixed or variable is what distinguishes one project management methodology from another.
In so-called ‘traditional’ or ‘waterfall’ projects features are fixed.
Requirements are gathered, plans are drawn up and the project does not finish until the last feature has been delivered.
If the project goes off-track, more money and resources are thrown at the project and the deadline slips further and further away.
As projects get later, often quality also suffers, as this cartoon demonstrates:
This is what happened to the Hertz/Accenture project. Started in August 2016, a new website and mobile app were meant to be launched in December 2017. The project was abandoned in May 2018. Nothing was usable; nothing was launched.
In contrast, an agile approach to project management fixes time, resources (cost) and quality. It is the features that are variable.
A minimum viable product (MVP) will be delivered quickly, tested with real users and iterated on to bring more features to market incrementally.
Time is fixed using fixed-length sprints. Resources are fixed using established teams who stay together for months. Quality is fixed by establishing good testing disciplines, agreeing on common practices, and establishing a solid definition of done.
There is an old military adage that even the best plan goes awry after the first contact with the enemy. So it is with projects: there ought to be an expectation that features will evolve and change as you learn more about the product during development, user testing and once those new features have been delivered to end users.
As our own agile journey continues, we would benefit from bearing in mind the eight principles of the AgilePM framework:
The Vision Tasks team has recently delivered v1.4 to SIT and ELS. This is a major milestone for the project and a huge confidence boost for the team. (Well done, Tasks team!) This is a fabulous foundation on which to build, incrementally.
Over the next few months, I’d like to see one of the focuses for the team to be working towards being able to deliver releasable features at the end of each sprint (even if they don’t immediately get put into production).
There is some work to be done first to get us to that point but that’s the goal: steadily delivering quality.
Originally published on my work internal blog.
One of the biggest challenges we faced when we started down the Agile path was how to accommodate working on multiple projects concurrently. This is a little insight into how we are currently managing ourselves across two projects plus business as usual tasks.
Most Agile/XP/Scrum literature assumes a single, cross-functional team working on a single project for a single customer using a narrow range of technical disciplines. The primary reason for this is that task-switching is really expensive: it is much more efficient to remain focused on one project.
That way of working, though attractive, is more or less impossible in our situation; something that I’ve also heard from other university digital teams. We don’t just work on projects, we have business as usual commitments (which include meetings, support calls, personal development, blogging, editorial calendar updates, etc.), consultancy (where we work on approved institutional-priority projects managed by other teams) and portfolio mechanics (board meetings and related admin, writing up project ideas and terms of reference documents, etc.).
After all that excitement has been deducted from our working week, we are generally left with only about 40% of our time to dedicate to pushing projects towards completion. We therefore need to be careful to extract as much value as we can.
Continue reading Agile release planning with multiple projects