The other day I was trying to articulate what ‘Agile project management’ means…
I thought I’d share my explanation below. It may be useful for others who’ve heard about Agile project management, but don’t necessarily know what it means!
WHAT IS AGILE PROJECT MANAGEMENT?
Historically, a Project Manager within an organisation would be responsible for managing huge projects that would often take a year or more to deliver. The process would often involve lengthy summary documents, project management spreadsheets and RAG status documents. They’d try to scope out everything that needed to be achieved within the project upfront (before any development work started).
The Project Manager would commit to the business that the project would be delivered within a set timeframe. Then, they’d task various teams to deliver the project within that timeframe.
- The business would decide to do X.
- It would appoint a Project Manager to scope out every potential scenario of X and try to pre-empt how it would work.
- They’d send a lengthy document or tickets to the development team.
- The development team would begin building X (development teams were usually outsourced. Plus, there wasn’t great communication between the business and the development team)
- Much later, maybe a year on, they’d deliver X to their customers,
- …only to find that customers’ needs had changed within the year it took them to build X and it was no longer fit for purpose.
This led to;
- a lot of regret spend within companies
- dissatisfied customers
- poor sales figures
…not to mention overstretched and disgruntled employees.
In turn, companies experienced a lot of churn. They also spent most of their time recruiting, because unhappy employees (especially developers) kept leaving.
Then along came the world of Start-up companies in Silicon Valley in the U.S.. For example; Facebook, Google, Uber and Netflix. These former start ups (which are now billion dollar companies, for good reason) don’t work in this way at all.
This is thanks to a new way of delivering projects within organisations = Agile project management.
Some of the main principles of an Agile organisation are:
– They have a Product mentality, rather than a Project mentality.
– Everything they do is based on customer insight and user experience. An Agile Project/Product Manager has ongoing discussions with customers so they know exactly how their needs are shifting and can ensure that what is being delivered will meet these changing needs
– In order to achieve the above (i.e. making sure everything that’s delivered meets customer needs) an Agile organisation needs to be lean, move quickly and be open to changing direction if need be.
– For this reason, Agile businesses have thrown lengthy Project Management methodologies in the bin. Instead, they use small, focused in-house teams to launch online products/services and enhance existing ones on an ongoing basis (the product lifecycle).
– Rather than trying to document everything they believe needs to be done upfront, Agile Project Managers focus on working with the development team to build simple, working functionality that customers can use as soon as possible.
Once they’ve developed a simple prototype, they can test the concept with customers. Their feedback will help the business to continue improving the product whilst customers use it.
Often this basic working functionality is called the MVP (Minimum Viable Product)
– Working in this way means that a customer could be using a very basic version of a product within a matter of months (sometimes even weeks!) rather than years. This reduces risk to the organisation by proving the viability of the concept, without spending years and loads of money building it to perfection – and only then getting it in front of customers.
– An Agile Project Manager works very closely with the Tech team (the developers who write the code to make the online product work) and has an ongoing dialogue with them to make sure things stay on track. They need to ensure the team delivers working functionality and enhancements, and fixes things that aren’t working, so that new and improved versions of the product can be put in front of customers to test.
The same applies to keeping stakeholders updated on the progress of the project. Stakeholders (including clients) are kept in the loop via frequent communication. They get full visibility of how the product is progressing (via showcases and demos) so they can suggest tweaks or improvements before the Tech team gets too far into development (ie. before the point at which there’s no turning back)
– Working in this way requires a flat structure where every member of each team is valued for the skills they bring. Agile cannot survive within a hierarchical organisation. In fact, leaders of an organisation need to have a sound understanding of the role the Project/Product Manager and Technology team play in delivering improving versions of the working product/service to the customer. There also needs to be a shared understanding of how important it is for the customer to feed back before they get too far with development.
So, where does the Project Manager fit into the Agile team?
In the past, all the ‘suits’ at the top would sit around a desk and make decisions on what needed to be achieved and how it should be done. However, an Agile organisation understands that it should play to the key strengths of its employees – the ‘suits’ at the top make the decisions on what needs to be achieved, e.g. “Grow B2B revenue by x%“.
However, they leave the achievement of ‘How to get there‘ up to the relevant ‘do-ers’ in the business. This is usually the Project Manager or Product Manager and the Tech team.
The Project Manager will work closely with the development team and relevant stakeholders to work out how to achieve the business KPI. For example, a goal of growing revenue by x% will be turned into actual product initiatives, e.g. “Charge users to unlock valuable features of the website”.
They’ll then need to speak to potential customers to work out how they would prioritise their most ‘valuable features‘. Once they have a list of say 10 valuable features, they’ll then break those down even further and focus on one of those features at a time.
One feature will then be discussed with the Technology team in detail and they’ll suggest how quickly they could get a very basic workable version of that one feature complete (the MVP) so it can be put in front of customers to test and feedback on.
What would have happened in a non-Agile business? The Project Manager would spend about 6 months documenting all 10 features at once, try to scope out how each one would work on paper (without speaking to the Tech team), spend months setting up the delivery of those 10 features as a project, with made up timescales for delivery.
For this reason, Project Managers in an Agile organisation tend to focus on just a couple of product areas. Rather than large projects, and they split all the deliverables across that project into small cycles of delivery, called ‘sprints‘.
A sprint is usually a two or three week cycle where all the members of the Agile team work together to get as much of the product (if new) or enhancement (if adding to an existing product) built. This is so it can be put in front of customers as soon as possible, so they can test it and feed back.
This is where roles and responsibilities of an Agile team are very important.
Key players in an Agile team
– A Project or Product Manager: Acts as the voice of the customer, runs a daily stand up meeting with the Tech team to ensure they’re on track, schedules showcases of working functionality and holds focus groups with customers to get feedback and input. Works closely with the Technology team to brief in the work, using online ticketing tools such as JIRA to detail how each piece of functionality should be built by the Tech team. Some companies combine the roles of Product Manager and Project Manager, but many still keep them separate.
Has ongoing discussions with the team to make sure everyone is aligned on expectations (the lynchpin between the Tech team and the Business Stakeholders.) They report back to the business on the status of the project and allow stakeholders and customers to see bits of working functionality whenever it’s ready. They often get involved in setting KPIs for the success of the product and have stakeholder meetings to discuss performance against those KPIs and where improvements can be made. If there are barriers to progress, the PM will work with the Product Manager and business stakeholders to unblock these barriers.
– Designers and Developers: Responsible for building working functionality and ensuring it offers a good online user experience for customers. There are all sorts of developers using various types of code language to build websites, online products, portals and mobile applications – basically anything that’s consumed by customers online.
Common challenges when implementing Agile
The biggest challenge when implementing an ‘Agile’ culture is mindset. Many people (who haven’t worked in an Agile environment) view ‘Agile’ as a dirty word. They may be willing to adopt some of the processes or practices, but this isn’t sufficient to make real change.
Agile is something you are, not something you do. If you want to become an Agile business, you’ll need to invest in training of ALL employees and commit to supporting them mentally and emotionally, as well as the physical process changes required.
Reiterate the benefits of being Agile and give real-world examples of Agile companies and their success. Provide ongoing support, set the example by initiating open conversations where everyone’s voice can be heard. And, be patient. Change won’t happen overnight, nor will it be plain sailing.
If you persevere, continue to learn and enhance the process, and maintain an open dialogue among team members – you’ll get there. You can build products that customers love, whilst minimising risk and spend to the business.
