Skip to main content

5 min read

Project Management Methodologies and the Atlassian Toolset, Part 1

RS
Project Management Methodologies and the Atlassian Toolset, Part 1
alert2 Icon
PLEASE NOTE
The content of this blog is no longer updated

Project Management Methodologies and the Atlassian Toolset, Part 1

In this multi-part series, we explore the evolution of project management methodologies with a software focus, and provide some lightweight guidance around configuring your Atlassian stack to implement them. Contributing to this article are Adaptavist’s Jon Kern, co-author of the Manifesto for Agile Software Development, and Project Manager Alastair Wilkinson. Part one of the series investigates the early days of software development and the rise of Agile.

Few things have been built in our world without having some amount of process in place to get them done. Sometimes we need just a touch of order and organisation, other times a whole lot of scaffolding and superstructure is required. Over time, humanity has devised several flavours of project management techniques to meet these needs, and in this post we'll discuss how two of the dominant techniques most relevant to building software work at a high level. We'll include info on how the Atlassian stack can be used to implement the best choice for your team that we've learned from helping customers make the move.

At the outset it's useful to think of the methodologies that follow with a mind toward pragmatic implementation. As we outline a methodology, it's important to note that a dogmatic "textbook approach" will seldom fit for any organisation better than one that's tailored to its specific needs.

Early days and the Waterfall Model

The Waterfall Model came about in the industrial era when what we were building was nothing short of the technology of today's world! There was a confidence in knowing a lot about what we were building as well, and therefore, even if a project was quite complicated (such as an automobile), the approach was that it could be figured out ahead of time and thoroughly understood. Consequently, one could define what was to be made, design the system, implement it, then test, deliver, and maintain it.

This model became deeply ingrained in the culture of engineering work, and when we turned our attention to the creation of digital things it was only natural to apply Waterfall there as well.

We ran into complications pretty quickly though: significant time on requirements definition and documentation was required, with no guarantee that what we needed to know about the work was wholly understood. By the time a product was real enough to introduce to customers for feedback, planned time and budget were often used up. Teams would often discover by this point that some requirements were based on incorrect assumptions – or, even worse, the market had changed to make the product obsolete.

And the cost of re-work, along with time lost due to errors and evolving market conditions grows exponentially as the team moves through the stages of the project.

These drawbacks are not to say that Waterfall is without strengths, however. It did indeed help to build a lot of our modern world after all, and it does still have its place in software development. Cases where we have a desired result that is complicated, but not complex; a small project or one with a very short time span; or a repeatable, template-style project that can be planned with reasonable completeness, are three prime examples.

When Atlassian Jira and Confluence are chosen to support it, Waterfall is a piece of cake from a tooling standpoint.

All of the requirements can live in a Confluence space devoted to the product. Each phase can be handled in a Jira Project, or as a step along a workflow depending on the size of the endeavour and the preferences of the team. Requirements on Confluence pages can link to the issues that track their progress. We can even have a little fun automating issue creation with Adaptavist ScriptRunner from phase to phase if desired.

Waterfall can work well when the demand is not complex. Complexity itself is not a bad thing however, and it's often the environment you're in when you move away from the idea that you know everything about the thing you are creating.

Agile, waterfall, methodologies

Dawn of the age of Agile

The failure rate of software development in the early days of the craft is shocking by today's standards: it was 60%.

Clearly something big had to change in the way we were working. As a desire to combat the heavyweight and inefficient-for-the-task Waterfall process grew in disparate individuals and teams, they started to connect with one another, and a movement was born.

Numerous practitioners of new, lighter-weight methods (including Jon Kern, who recently joined the Adaptavist team) eventually gathered to compare and learn from one another. They published a document outlining the common threads that they found across methods and mindsets. What came out of this group was the Manifesto for Agile Software Development, commonly known as "The Agile Manifesto". The document outlined a set of preferences the authors valued as the basis of a new way of working to develop software, and made it a point to include creativity and humanity in the approach they defined.

Several methodologies have flowed from the well of the Agile Manifesto, and one of the most commercially successful processes is Scrum. On the surface, it's a simple project management framework born from fighter pilot decision making loops. In its simplest form, Scrum is a three phase process: plan a sprint that is time-boxed, work on the tasks determined in the planning session, and then at the end hold a retrospective and figure out what could be done better next time.

From the Lean Manufacturing world, comes the Kanban method of managing work. Kanban is designed to keep the work in progress at a consistent and sustainable pace by limiting how much is going on at any one time. As work is completed, the next task is begun.

Jira Software is actually the leading tool in use by software development teams practicing Scrum, Kanban, and anything in between (Scrumban is a funny word for the merging of the two). To support non-software development projects, all that really needs to be done is some configuration of project schemes, essentially making field names apply to business processes, and so on.

As teams embraced the mindset and practices of Agile, they began to change the way software became available to their customers. Some small companies exploded into massive enterprises by harnessing the competitive advantages from Agile practices – namely getting products that the market actually wants released more quickly. These enterprises soon realised that it was easier to do Agile when it was limited to single teams, and a way to scale Agile to meet their needs became increasingly important. We’ll investigate a few choice scaled Agile methodologies in part two of this series.

Are you in the Boston area, and interested in this topic?

Join Ryan Spilken at the Atlassian User Group Boston on July 31st to hear his talk exploring these and other project management methodologies, and how the Atlassian Stack can be used to implement them.

copy_text Icon
Copied!