There are numerous project management methodologies, each with their own plus points. When it comes to project management methodology, one size definitely doesn’t fit all, so it’s important to choose the one that will help you achieve the best outcome possible.
Here at Tisski, we implement different methodologies depending on the project, but Agile is certainly one of our most commonly used. In this guide to Agile project management, Tisski Delivery Manager, Grace Hunnings, gives us a helpful overview of the Agile methodology and shares some insights into how we apply it to Tisski projects.
The term ‘Agile’ (in this context) was coined by a group of ‘independent thinkers around software development’. They came together to discuss an alternative to Waterfall methods as they were frustrated with heavyweight, document-driven processes that made it a struggle to allow for changing requirements.
The ‘Agile Manifesto’ was formed as an output of this conversation, with the aim to improve the method of developing software. The manifesto states:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
While there is value in the items on the right, we value the items on the left more.
On the whole, Agile project management (APM) is based on the 12 principles outlined in the Agile Manifesto.
APM addresses the need to implement more frequently in an iterative approach. The method encourages feedback while ensuring adherence to high standards, ensuring the project is delivering maximum benefit and value in line with a business’ strategic objectives within a set time and budget allowance.
The key characteristic of APM allow a project to be responsive to change. A project will be broken down into manageable requirements which are prioritised based on importance. Working from the highest priority first, a collection of the smaller requirements are put forward to be implemented within a specified timeframe, known as a ‘sprint’.
A series of meetings are held throughout the sprint to review progress, collect feedback and manage lessons learnt. At the end of each sprint, these requirements may go into operational use.
Essentially, APM blends planning and execution of requirements to effectively adapt to change.
There are many benefits of adopting APM over of alternative project management methods, but first and foremost, it helps to balance changing requirements. Agile promotes the opportunity to embrace change and encourages continuous improvements, which helps focus on technical excellence.
APM is also a great method when it comes to supporting cultural changes, building on client and user engagement. It allows for a very collaborative working style, empowering everyone involved, and its iterative deployments allow for frequent feedback and early realisation of benefits not only to the solution but to the progress and dynamics of the project.
There are a family of frameworks that support Agile project management. These frameworks can be project focused in a generic sense (Kanban, Lean, Scrum, SAFe), while others are specific to IT (ASD, DAD, DSDM, FDD).
Scrum is one of the most popular Agile frameworks and is based on empiricism. It’s upheld by three pillars: transparency, inspection and adaption.
A Scrum framework consists of a small team referred to as a ‘Scrum team’; they have designated roles, responsibilities, events and deliverables assigned to them. The Scrum team should be self-organising and cross-functional, comprising of:
Generally, Scrum is put into practice in four key meetings:
Originally designed for software development, Agile has come a long way and its method has evolved over time so it’s now applicable to an array of large-scale and complex projects. You can always apply the ‘Agile Manifesto’ to your team by replacing ‘software’ with ‘solution’, ‘product’ or ‘service’.
Some key indicators where a project may benefit from an Agile approach are the need for fast-changing deliverables based on lack of scope definition, continuous improvements based on frequent customer feedback, or the requirement to prototype a solution first and enhance based on its outcome.
Tisski promotes three foundations for their Agile mindset:
Tisski’s approach to Agile adopts two types of methodology:
Tisski don’t typically subscribe to the pure Agile mantra that you have to release to live at the end of every sprint. In our experience, at times, this is too high risk for our clients who have CAB (change-advisory board) processes to follow, or who are concerned about the risk of having constant change made to business-critical systems.
We take the approach of ‘locking’ at the end of the build sprints and then completing the operational readiness activities of the build sprint (like user acceptance testing, training and data migration) to give go-live confidence.
Anyone wishing to adopt APM should prioritise the following skills and traits:
A key tool for Tisski is a software called DevOps; it gives project teams the ability to collaborate on builds and provides the ability to test and deploy with continuous improvement and continuous delivery, enabling the benefits of Agile.
DevOps allows creation of a backlog of requirements with associated build time and priority, where you can commit requirements to a Sprint during Sprint planning. Within the Sprint, the use of task boards and dashboards can be used daily in stand-ups to assign tasks, track progress via burn-down charts and track velocity.
Adopting an Agile approach is all about buy-in from your team. Ensuring you have the right people on board with the appropriate skillset that can empower them is fundamental, alongside the willingness to adopt this approach.
Your team need to be accepting of change and feedback and view this as a positive to enrich and evolve your product or service. Training on Agile is a plus, as it will help your team understand both the mindset and its benefits.
It’s also important to make sure you are using the right project management tools for your team. Different tools will suit different teams and may be dependent on your team size, product/service, and collaboration with other teams.