Implementing Agile Project Management
and Scrum
Your Agile project IMPLEMENTATION wizard
Brought to You by Dave Litten
Applying Agile Project Management
What’s all the Ruckus About?
Scrum is an Agile development framework that dramatically changes how people work, how they organize themselves, and it makes organizations faster, better and far more productive.
“Spotify’s competition is Google, Amazon and Apple, any one of whom could crush them in a nanosecond, unless they’re faster, better, cheaper. And they must stay that way. They have to keep on running out ahead.” – Jeff Sutherland
So, why employ Scrum?
Going Agile allows an organization to be faster, better, and cheaper than industry Goliaths. It needs excellent team coordination that are continuously deploying products or services and sprinting.
Scrum masters should also be experienced Agile coaches
So, while agile is used by countless organizations such as Microsoft, Apple, Facebook, Google and Spotify, you need to be aware of what is under the hood before jumping straight in …
It’s so easy to Screw Up
It’s very easy to get many great contributions, but in agile, you still need leadership – someone at the helm. Without using iterations, you won’t know what works and what does not.
Sprints and iteration-lead delivery allows early identification of what is working, and if it isn’t, chance to fix it.
The emphasis should be on working, functioning products that at customer business value.
What’s Wrong with Predictive Approaches?
Going a couple of decades, the Waterfall (predictive) method for projects was the prevailing way software (and most products or services) were developed.
Predictive approaches mean committing a large amount of time and effort up-front gathering detailed requirements and planning. As for any project, most key decisions were based on assumptions and best estimates at that point in time.
Agile and Scrum – Your flexible Friend
Different types of projects require different methods.
Initially humans wandered the earth as hunter-gatherers, but after several ‘ages’ including the Industrial Revolution, we are now in the Information Revolution.
The touchstone here is that we are focused on information and collaboration - rather than manufacturing, and we now rely on knowledge workers.
When knowledge work projects become more common, communication and collaboration aspects made the work more uncertain and less definable.
When faced with such uncertainty, a process of trial and experiment is required to determine what works, identify and resolve issues and problems early, and incrementally and iteratively build on small successes.
This is where the agile approach comes into play.
The resulting agile process will be iterative and incremental with frequent reviews and adaption.
The result is an empirical process.
This agile approach is required for projects where the work execution is characterized by uncertainty and risks.
For the record:
Incremental means developing and building some before building all. Here, products are developed and delivered to users at different times with the intention to adapt to external feedback.
Iterative development is a strategy where multiple passes over the work are used to converge on a good solution
As two great examples here, Google update their desktop and mobile applications every week or two, while Microsoft releases brand new versions of every single one of their projects every three weeks
How come they can do this - while other companies take years?
By using Agile and Scrum.
This Projex Agile Academy Practice Guide will show you:
Implementing agile in your organisation and projects
The Agile Mindset
Rather than traditional software development like the Waterfall method, where you might spend many months or years on a project before even showing it to the user, Agile is all about moving fast, releasing often, and reacting to the real needs of your users.
Agile development takes the emphasis off you and puts it on your customers. It seems a small change, but it brings huge benefits.
The Project Management Institute carried out the following research:
Here’s some more stats:
Check it out, you get faster development, more releases, and more revenue. What’s not to love? From the outset, you need to know that agile is not a ‘one-stop fix-all’ for projects, agile has its share of idiosyncrasies that you need be aware of …
What exactly is Agile?
At its core, Agile isn’t so much a methodology as a philosophy. It’s a blanket term for an approach to project management that prioritizes incremental, feedback-driven changes into software development
To understand why Agile works so well, we need to do a bit of a history lesson. Until the last few decades, the Waterfall method was the prevailing way software (and most products) were developed. This meant spending a huge amount of time and effort upfront gathering resources and planning with a lot of key decisions based purely on assumption.
But by the 1970s, it was clear this method wasn’t working.
Modern developers found the Waterfall method constricting, regulated, and too slow moving.
The waterfall method relies on predictability and sequence, but what these software developers needed was a more flexible project management method that made room for errors, bugs, setbacks, and feedback from real users.
In 2001, a group of seventeen individuals came together and created:
“An alternative to documentation driven, heavyweight
software development processes”
They called the documented outcome the Agile Manifesto.
As part of their Manifesto, the creators of Agile defined 4 key values (below right) that all Agile projects should adhere to:
However, this does not mean you should not use your time-proven tools, documentation, and plans – rather that the above list is your focus.
There are 12 Guiding Agile Principles for those running an agile project:
To sum up the core principles of agile:
We’ve all become very needy consumers, and Agile is a fantastic way to make sure the user’s needs are put front and center whenever you’re developing new software.
Your Organization/Project Fit with Agile
This all sounds great on the surface, but not every project can benefit from Agile project management.
Some project ‘types’ may be perfect for agile – such as forms of research and development, while other types/industries may not – such as the construction industry.
Even within a single organization, some projects may be best using agile – others not.
Agile might be a big departure from how your company or its employees work – or even the organisation culture, so you need to know whether your environment can handle these kinds of changes.
Let’s check out the typical criteria that would point to the use of agile (or not)
Here are some tough yet important questions to answer:
How risk-averse are you?
This applies to your organization top-down as well as to projects and individuals.
Since Agile is all about continuously deploying and learning from your mistakes, you are taking on potentially higher levels of risk than you would if you went with a more traditional predictive project management style.
There is a world of difference between using agile in a high-tech start-up verses using agile within a financial or pharmaceutical company. Very often its your shareholders viewpoint that will hold sway.
If your choice is Agile, then you must be prepared to take on any unknown issues and risks that surface along the way.
Is your team flexible?
In Agile, you work with your customers to make the product better.
Just about anyone I have ever worked with has a sense of pride in what they do as well as an ego (including myself)!
You will want to determine if this sits well with your specialist teams such as designers, developers, testers, and so on…
Can everyone involved in an agile project – including all internal and external stakeholders, put their ego to one side and let their work effort, initiatives and ideas as flow in the direction of customer needs?
How rigid is your company hierarchy?
Check out this diagram:
Notice the direct link stakeholders, customers and users. One of the key principles of Agile is not only to work with your users, but that developers will have daily access to key stakeholders.
Can your organizational structure become more flexible – or is there a strict hierarchy in place?
Assume a ‘middle manager’ – or even a senior manager, who due to their role and responsibilities plus their seniority, being asked to allow an engineering tester say, have direct communication with a customer/user and further, allow them both to make decisions?
How do you measure performance?
So how does your culture define success and progress?
This question includes measuring progress, personal performance and even impacts on an individual’s personal goals. Imagine an individual at their annual performance review…
If they are measured on efficiency and effectivity metrics of their staff, how do you think they would respond to assigning people to an agile project?
Remember also, that agile project management is all about working to continuously refine your processes and better your product. If you are regularly expected to ‘multi-task’ and will often be temporarily re-assigned, you’re not going to get the best results that Agile has to offer.
Next up, I want to walk you through an Agile/Scrum project from start to finish …
Implementing Agile and Scrum into your projects
Agile is a constant blend of planning, execution, learning, and iteration
Agile is all about rhythm, and as a project manager or team leader, it’s your job to keep a ‘helicopter view’ to make sure everyone is working together smoothly.
So, let’s start at the beginning:
There is a commonly used RoadMap for what is known as Extended Scrum, take a moment to read through these steps:
Step 1: The Vision
Set your vision with a strategy meeting
At the beginning of a new Agile/Scrum project, you need to define a clear business need or vision that your project is addressing. You need to answer why you’re doing what you’re setting out to do.
The Vision is the core belief that you’ll refer to it as you design, build, and test.
For product companies, one of the best ways to define your vision is to use ‘The Elevator Pitch’ by pulling together eight key sections as above:
I am sure you can see how easily the Vision Statement as above could be modified for say, a service company.
Who should attend?
This is where you get buy-in on your project, so as many key stakeholders should be present, including relevant executives, managers, and directors, as well as all product owners.
When does this occur?
Your vision strategy meeting should happen before any project starts or at least annually to make sure your mission still is valid, with periodic meetings for updates.
Step 2: Create your Product Roadmap
Once your strategy has agreed, the product owner will want to translate that vision into a Product Roadmap.
This is a high-level view of the requirements for your project with an approximate timeframe for when you will develop each of the main deliverable product milestones.
This is intended to be a high-level view and will be continually updated and elaborated. Creating your Roadmap is a matter of just identifying, prioritizing, and roughly estimating the work effort each piece of your product will take on the way to making a shippable product.
So, what would a typical Product Roadmap look like for an Agile project? There are many ways, but here is a simple example:
The best way to structure a Product Roadmap is to use metrics related to goals, objectives and outcomes. As a guideline, each goal can have up to 5 features.
For each of these goals, you want to include 5 key pieces of information: Date, Name, Goal, Features, and Metrics
This gives you a clear idea of what needs to be done, when, and how you’ll measure success.
Who should be there?
The product roadmap is created by the Product Owner but should also include agreement and contribution from any other stakeholders in the project – for example, marketing, sales, support, and development team representatives.
When does it happen?
The roadmap needs to be in place before you start Sprint Planning, so it’s best to move into creating it directly after your strategy meeting.
How long should it take?
The RoadMap should take as long as it does to feel confident that you’ve covered all the applicable goals.
Step 3: Develop your Release Plan
This is where you estimate your first timelines:
At this stage, the product owner creates a high-level timetable for the release of working software.
Agile projects will have multiple releases of course, so you will want to prioritize the features needed to get you to launch first.
This all depends on the complexity of your project and your Sprint duration (no more than four weeks in duration). It also depends upon your Releases – typically three to five sprints per release.
Who should be there?
The product owner, project managers, and all team members should be there, including any key stakeholders
When does it happen?
At a minimum, your release plans should be created on the first day of any new release and reviewed at least every quarter.
Step 4: Sprint Planning
A typical sprint lasts between 1–4 weeks and each successive sprint should remain the same length throughout the entire project as this enables teams to plan future work more accurately based on their past performance.
A Product Backlog may represent many weeks or months of work – more than can be done in a single sprint.
The Scrum Team will agree a goal for the sprint and the development team determines the specific backlog items that are aligned with that goal and can be realistically delivered by the end of this sprint.
To do this, the team creates a plan for how to complete the backlog items.
The Product Owner shares the initial sprint goal and presents the prioritised Product Backlog Items (PBI). The development team then determines what it can deliver.
Who should be there?
Sprint planning is a team effort, and therefore the product owner, project managers, and all team members should be present to voice their thoughts and concerns.
When does it happen?
Sprint planning takes place at the start of each sprint cycle. For example, if you’re doing weekly sprints, you’ll do a planning session every Monday (or whatever day of the week you choose to start on).
How long should it take?
Sprint planning sets the tone for the cycle. So, while you don’t want to spend too much time at this stage, it could realistically take you 2–4 hours
Step 5: Carry out your Daily Scrum Standups
Throughout every sprint you need opportunities to make sure no roadblocks are creeping up and getting in the way of completing your goals on time. That’s where the daily meeting, or “Standup” plays its part.
A standup is a daily, 15-minute meeting where your team comes together to discuss three things:
These meetings are essential for fostering the kind of communication that drives Agile project management. Agile depends on reacting quickly to issues and voicing them in a public space is a powerful way to foster cross-team collaboration.
Step 6: The Sprint Review
If everything has gone as planned, by the end of your sprint cycle you should have a functioning product and this review focuses on that product(s).
At this point, we inspect and adapt what we have done by providing a transparent look at the current state of the product. The Sprint Review occurs near the end of the Sprint.
The review is an opportunity to demonstrate to people on your team and any key stakeholders – such as the users and/or customers. The Sprint Review is supposed to be an informal meeting with low ceremony and high value.
The Sprint Review gives us an opportunity to identify ways to adapt, to respond to change while it is still affordable to do so, at the end of every Sprint.
Who should be there?
Your entire team as well as any key stakeholders should be at your sprint review to check in on progress and voice their support.
When does it happen?
The sprint review takes place at the end of each sprint.
Step 7: Holding your Sprint Retrospective
Sprint Retrospectives give the whole team an opportunity to stop and review for a moment. Here, teams are free to examine what’s happening, analyze the way they work, identify ways to improve, and make plans to implement those improvements.
Don’t simply plan, but also take this time to discuss how the previous sprint went and how you could improve in your next one.
Who should be there?
The retrospective is a natural extension of the review, and so while your stakeholders can leave, the rest of the team should be involved and giving their insights.
When does it happen?
It makes the most sense for your sprint retrospective to happen right after your Sprint Review.
Summary
At this point, you should have a functional product you can ship, get feedback on, and plan new features or fixes.
This ongoing shipping, learning, and building, along with prioritized product development and shipping is what makes Agile so powerful.
What is Kanban?
Like Scrum, Kanban is an Agile methodology built around continual delivery.
Scrum is not well-suited to highly interrupt-driven work because you would be unable to reliably plan iterations of a week or more.
In interrupt-driven environments, you would be better off considering Kanban.
Kanban is not a stand-alone process solution, instead it is an approach overlaid on an existing process.
The Kanban board is there to help visualize
Being able to see all the items you’re working on in context of each other can be incredibly informative and help keep things clear and simple when projects get complex. You can see all your items and where they fit in the flow from to-do to doing to done.
Keep your work-in-progress (WIP) limited
Like in Scrum where the backlog is defined before your sprint and nothing can be added (except by the team), Kanban relies on teams knowing how much they can do in each sprint.
Clear Visual Steps
To keep the flow of Kanban moving, you should always know what happens next after an item is finished. This means keeping your backlog prioritized and updated.
Kanban suggests that you:
Extreme Programming (XP)
If you are using Scrum to develop software, team members need to be skilled in technical practices for developing software.
Development teams use these to manage the flow of task-level work during sprint execution.
XP involves high customer involvement, rapid feedback loops, continuous testing and planning, and close teamwork to deliver working software quickly.
Here are the technical practices:
Extreme Programming was described by software engineer Kent Beck. Here is a simplified view of a typical Extreme Programming Project:
In XP, there are tight feedback loops where the “customer” works closely with the team to define and prioritize granular features/requirements called User Stories.
The team then estimates, prioritizes, and plans the delivery of these stories, getting more feedback from the customer until it’s ready for release.
Final thoughts on implementing Agile project management
You now should have a clear understanding of what Agile project management looks like and a few of the powerful ways you can use it on your own teams.
But “agile” is an umbrella term providing a specific set of values, approaches and principles based on iterative and incremental development - as laid down in the Agile Manifesto.
So you won’t be surprised to learn that there are many other practices that fall under the blanket term of agile – as shown in the following diagram:
