First of all, you need to be clear why you want to adopt an Agile approach. What is the problem (or opportunity) that warrants using an Agile approach? If your business problems include needing to deliver value faster, lowering the risk of delivering large projects, or doing more with shrinking project budgets, you should definitely read on.
Go and see others who are already embracing Agile principles and have started using the Agile practices. Have an open conversation with the people in your organisation that you want to involve. Ideally, you have an understanding of the possibilities of working Agile and the benefits for you, your team and your customers.
Getting the support of some of your business leaders is another key step. Their support will help ensure your organisation can obtain all of the benefits available with an Agile approach. Make sure you highlight the benefits that Agile can bring to your organisation rather than focussing on the practices. Go and have at a look at the Agile framework to see what’s possible.
You could also bring in an Agile specialist who has been through this process to help construct your business case and support you in trying something different. Another possibility is to bring in someone who has been through this process already and have them articulate to the team how it has transformed their way of working.
Of course, you can always just have a go at a project or business process that you have a reasonable degree of control over. This is a core principle of Agile – 'learn by doing'. Some good places to start are:
Importantly, embrace the likely reality that whatever your try will feel a bit hit and miss to start with. Stay the course, reflect and adjust your approach often, and work as a team to explore how you could change things to ensure you are adding value.
Ensure you have a supportive workplace that is willing to allow you to have a go. Consider your organisational culture to make sure you won’t freak out people when you invite them together and start using new words / practices. Chat with your leader or someone else that may have tried it in your organisation to get some feedback on what worked and what didn’t.
You can get a team on track by training them in the Agile principles and practices. Ideally an Agile capable Agile Coach would lead this. You may have access to a coach inside the organisation or alternatively, you can shop around for one. A coach can help ‘de-mystify’ agile and also help bust any myths that may exist within your organisation.
Show your team what’s in it for them and highlight the benefits that come from increased trust, communication and openness and how it benefits the organisation. As a group, look at all the practices and tools available and choose ones that best suit your project / organisation / industry.
Perhaps the answer lies in a different question: If you don’t set up a project (or business activity) for success from the start, how much time and cost are you prepared to invest to remediate, recover or re-start at a later date? We know that projects often succeed or fail due to the quality of the initial phases, why not invest in an approach that directly addresses that concern by getting started faster and delivering value earlier and more often.
Depending on what you read, project ‘failure’ rates range from 30% to 75%. That is, at best, a large minority of projects do not deliver on the benefits that justified their commencement. There are usually a few reasons for this:
If you do not have a good sponsor, it doesn’t really matter how good you are, you are in for a tough time. A project will benefit from a leader that conveys a simple message with a clear strategic intent. They paint compelling reasons for change and people follow their vision.
If you are feeling brave, have a go yourself See FAQ 1 for more info. Or go and get some training and start with something small. Alternatively, go and source an Agile coach to get you started. The key is to start. No amount of theorising can beat the learning you will get from running your first Agile project, reflecting on what worked, and then continually making it better. This is being Agile.
Initially, an Agile approach can feel like more work when compared to a typical project initiation. But the costs savings/risk minimisation far outweighs any extra effort required to achieve it. Due to the ‘just-in-time’ nature of documentation, combined with time boxed meetings, most people quickly realise that Agile saves them time compared to their current approach. We suggest you write up your idea / project scope using the Strategy on a Page (SoaP) questions. If you can’t summarise your initiative on a page and convince a senior stakeholder of the benefit, then it doesn’t matter what methods or processes you use.
NOTE: You can’t 'govern' or 'methodology' your way out of doing the hard work to successfully execute a project. So even if your workplace has a preferred project management delivery approach, the 3 elements above will still apply.
The Agile approach is primarily about the
There are some alignment diagrams you can find readily on the Internet that illustrate how steps in other methodologies map to their Agile equivalents, however most organisations find this is only needed during the transition to Agile. Once Agile projects are seen to be succeeding, the legacy methodologies tend to be discarded. The remaining elements from them tend to include good financial control and strong risk governance.
We know that when projects get going, things can quickly change. Budgets, scope, decisions, teams, technology, customers and suppliers can all affect your delivery at any point. Traditionally we try and build as much certainty into the plan upfront, then try and stick to the plan even if it turns out to be wrong.
With Agile, you can build into your project the ability to respond to change rapidly. You have direct business involvement, so there is a hard line directly tied to the organisations strategic intent. Change doesn’t have to be mitigated and avoided, but included as an expected part of the way you work. There are usually good reasons for why something happens, so course correcting quickly is often the difference between delivering business value or a project going south.
Agile focuses on empowering teams and individuals to prioritise work and deliver outcomes using a set of practices, principles and tools. The examples that will feel the most different for teams include:
You sure can. Agile portfolio management opens doors to possibilities you could not consider under a traditional portfolio management system. The Agile principles can equally be applied at a portfolio level such as: high-levels of business involvement, full transparency from delivery teams, and 100% commitment to business value as a priority.
From a portfolio management perspective, this usually leads to a ‘portfolio’ wall of incoming, underway and completed projects as an effective visualisation. Everyone can see at a glance what projects you are managing at any given time. It gives you more options in managing projects, fewer and more transparent metrics, more frequent and productive management meetings, and more opportunities for innovation. Treating your project portfolio like a backlog of stories means business executives are able to say, “no” to projects earlier and release resources to more valuable projects quicker.
Agile can be a big shift for people and organisations. For any change to be successful, it’s best to ask a few questions:
If you’ve got these three covered, a Retrospective is your next step. Involving your team and your customers to get the wisdom of the crowd. You could also apply the ‘5 Whys’ analysis across this problem to get to the root cause of why Agile isn’t working. Remember that it is not about knowing Agile, its about ’being’ Agile, where teams continually improve.
If this doesn’t reveal or assist with solving the underlying issues, then you can look to your Internal Coach (if you have one) or use Agile communities like those on LinkedIn or find an Agile consultant to help.
Not at all, in fact by working in iterations, you will get a useable, saleable product ‘out there’ much sooner than with traditional project methodologies. The use of iterations means that you can keep adding layers of functionality or improve the quality of particular features in an incremental way. Agile projects end when the jointly agreed Definition of Done has been reached – this often means when an end-user need has been filled and is ready to be delivered to your customers. Putting the product out incrementally also means that your customers may tell you that you have reached that point much sooner (and for less cost / effort), than you would have if you had launched the end product in one go.
An Agile way of working can be a big shift in your culture, so teams need time to feel comfortable with Agile processes and they need time to learn how to interact with each other in a more open and honest way. In this regard, Agile can be confronting for some teams not used to this level of transparency.
Agile is about being collaborative and working together. It can become more difficult when teams are not physically located together. Having said that, success can be more challenging for any project where team members can’t meet or collaborate easily. There are plenty of tools and techniques around to mitigate co-location issues.
Lastly, there are perceptions that Agile is not strong on discipline, governance and documentation is optional. This is not true. You are still able to satisfy your organisation’s governance objectives using a range of Agile software and document management processes. Agile is a rigorous disciplined technique that follows a team’s regular cadence. The Agile mindset requires stringent practices to ensure success, but these practices are generally more fun and feel more natural to individuals.
In Agile projects, budgets and timelines are set based on releases, or “chunks” of work rather than an unwieldy and unpredictable whole-of-project budget. This means that budgets and timelines can be met with much more certainty and projects can be funded and extended incrementally. A project is able to produce a run-rate of costs per iteration and due to work being ‘shippable’ every iteration, the project can conclude once sufficient value is realised, as opposed to traditional projects that have large pre-sunk deployment costs and timeframes.
Your boss, like any other person going through change needs to know: ‘What’s in it for me?’. All leaders will have their reasons for objecting to any change, however few could argue that they would not like their projects delivered faster, cheaper, for lower risk, with more business value and with a more engaged workforce.
Get to the heart of why your boss has that view, and go from there. Do they really understand it? Do they see a need to change? Have they been fed too many Agile myths that need debunking? Are cost pressures lowering the appetite to try new things? Also consider if you clearly understand why this needs to be done? How are you enrolling other champions in the opportunity Agile provides?
Depending on the cause, you can also try taking them to other similar organisations who have worked with Agile and succeeded, or bring in some experienced help to better respond to objections and opportunities.
Agile is inexpensive. If you have a willing team, executive sponsorship and belief that the Agile principles are relevant to your firm, then the costs are minimal. Your team may benefit from some coaching and mentoring from an Agile specialist until they are off and running. But once you have used Agile, your team will start becoming more self-sufficient, and you will tend to stick with it.
Team members that are focussed on results and delivering value will shine using the Agile way of working. People who won’t collaborate, play politics or are highly resistant to change are not good for any project team, no matter what the methodologies or principles used. People who refuse to (or are afraid of) open accountability, communication, a transparent approach to admitting problems and actively seeking help are going to make the process much more difficult. Just remember that many people adapt to their surroundings and people can change if the culture of the current team changes. Only personal experience with them (or check with their previous teams, not just their bosses) and your intuition will tell you how a particular person will perform in an Agile team.
A benefit of having an open and collaborative team approach to work is that high performers shine and low performers are found out. In many cases, the low performers opt out of Agile teams due to these pressures, creating a win for the team (as they are only left with high performers) and a win for the organisation (as low performing employees are self-selecting out your high performing culture).
The best way to find out is to just get in there and try them. Start with building an agile wall and having Stand Ups. People generally have a list of tasks they have to do either in a project or in their day-to-day work, so just get them to make them Story Cards and get them on a wall. Then move onto introducing Retrospectives – unpack what’s working, what’s not working and what’s still puzzling the team. Once you’ve done this a few times and mastered these processes it will be much easier to introduce other Agile practices into the team. You’ll then be off and running!
A Social Contract is useful a first step in getting the team to agree on how they are going to work using Agile. The team are then empowered to assist in calling out the negative behaviours of the one or two rotten apples spoiling the rest of the barrel. Not everyone has to be best mates, but a collaborative and self-managing team will mean that the process will be more enjoyable and achieve better results.
Executive level support is important in successful Agile adoption and a tool they can contribute with is setting goals for individual behaviour. Ask your executive or sponsor to add team collaboration and communication as a significant portion of team members’ KPIs. If the measure is peer assessed (quarterly survey’s perhaps), people’s behaviour will change, or they will opt out of this style of work, however both outcomes would be a success.
Change it. Work with your facilities management team to find space and be creative about it. Old storage rooms with some minor OH&S changes can make great collaborative project spaces. Co-location is worth the effort to ensure the team can maintain a shared sense of purpose.
If that’s not possible (geographic constraints potentially), put in big screens with Skype™ or similar capability in an ‘always-on’ mode. This helps with the feeling of connectedness that Agile teams thrive in. Also adopt electronic/virtual story walls to keep everyone aligned to what people are working on in real-time.
There is a host of collaborative software available to assist in this challenge that can bring teams together and be a part of the process so that you can simultaneously work through iterations when you’re working together (but apart).
An Agile practice called a Showcase is the key tool used to show the projects deliverables, their benefits and to garner feedback. It is empowering for the team as they present the deliverables and receive regular, direct feedback on the value. As the work is presented each iteration, even a 'less-than-favourable' showcase only results in a single iteration worth of rework, the alternative with traditional projects, is considerably worse.