A series on successful project management with Jira - Part One: Do you need to take an Agile, Waterfall or Hybrid approach to your project management?

In the first of this three-part series on getting your project management right, I look at the Agile approach and how Atlassian Jira shines in this area. It’s not perfect though. So, I also look at its limitations and what else you need to consider for efficient and successful project delivery, especially when you are developing physical products.

Why Jira is popular for Agile practices?

Atlassian+Background.png

Atlassian’s Jira is one of the most popular tools for software teams using Agile practices, such as Scrum, to deliver software features to customers. Why is this?

To explain, let’s look at the different terms which you’re probably already familiar with: Stories, Story Points, Sprints and Epics.

Software teams deliver features called Stories which are short requests written from the viewpoint of the end-user.

Next, the teams estimate the size of each Story using Story Points, based on the perceived effort to implement the Story and other factors such as complexity and risk. Estimations are just that, estimates. They are fluid which makes them great for Agile styles of working.

The Stories are then implemented in small iterations called Sprints. Stories can be worked on simultaneously by the team, and often they are not dependent on one another. Using Epics, a collection of Stories that are delivered over several Sprints, you can plan for a few sprints ahead of time.

As is often the case with software development, you don’t need to plan too far into the future – it’s uncertain and evolving. That’s why the detailed planning is done much closer to when the features are going to be developed.

Jira’s out-of-the-box software supports this style of working wonderfully.

But a word of warning, this is fine for developing software products where your product is made up of bits and bytes of code. But the same can’t always be said of developing physical products.

What makes project managing physical products so different from software?

You can find many online articles about Agile for hardware vs. software, including my blog that touches on it: OK, that was Agile - so what's next?

But when it comes to planning and developing physical products, there are three main differences to software products which are:

  1. Physical products require resources from a wide range of specialist teams
    Rather than teams who are dedicated to one product, different teams are involved at different points in bringing the product to market.

  2. Finishing one activity depends on another
    There are connections and interdependencies between the activities and across different projects. For example, you can’t move onto the next phase of development until a certain part has arrived or been built.

  3. When planning and estimating a piece of work, and the activities within it, you need to consider not just the effort that is required, but also the duration from start to end
    In project management speak this is known as the critical path.  As part of this, project managers need to be aware of and factor in lead times, such as the time it takes from purchasing components to their arrival, through to assembling a prototype for testing.

These three points all require long-term planning, short-term action, and delivering the product to market in as short a time as possible.

Sadly, Story Point estimation doesn’t cater for this level of complexity. 

Is Waterfall the way to go?

Now, I’m not suggesting that Agile practices are not fit-for-purpose for developing physical products. Looking at the other end of the spectrum, there’s the Waterfall approach, which is linear and sequential. This might have suited project managing physical products in the past, but it has its limits in the fast-moving environment that most companies find themselves in now. 

Hybrid – can you really get both?

While Atlassian also promotes Jira as a project management tool, it’s lacking key functionality to support the complexity I’ve talked about above.

The good news is that you can have the best of both worlds (Agile and Waterfall), and I can help you with that.

Exactly what that looks like, how it works, and selecting the right tools is the challenge.  Thanks to my experience working in various companies across different industries and stages, this is where I thrive.

I’ve learnt from my own successes and failures working with startups to large enterprises and everything in between. Overcoming the challenges set out in this article has become my specialist area.

Not sure how to get the best of both worlds and what that might look like for your unique project? Let’s talk.

Here’s part two, where we look at mastering the three planning horizons: short, medium, and long-term.

Previous
Previous

A series on successful project management with Jira - Part Two: Successfully managing the three planning horizons: short, medium, and long-term

Next
Next

Jira Service Management as a Business Process Management and Automation System