Archive for category: Project Management

Agile management is quickly gaining popularity in the modern workplace as a way to complete work in the complex, ever-changing world. Agile thrives in adaptive cultures where team members are quick to change if the outcome is a more productive work experience.

In this agile project management guide you will discover,

• What is Agile project management?
• How does Agile project management work?
• History of Agile project management
• Agile pros and cons
• Who uses Agile project management?
• What are the 4 core values of Agile?
• What are the 12 principles of Agile?
• Key components of Agile project management
• What are the 6 steps in Agile project management?
• Transitioning to Agile project management
• Getting started with Agile project management

Super-adaptable, Agile project management is an incremental and non-linear approach to project management. It focuses on breaking down large projects into more manageable tasks, which are completed in short iterations throughout the project life cycle. Teams that adopt the Agile methodology are able to complete work faster, adapt to changing project requirements, and optimize their workflow.

As the name suggests, Agile allows teams to be better equipped to quickly change direction and focus. Software companies and marketing agencies are especially aware of the tendency to demand changes from project stakeholders that happen from week to week.

The Agile methodology allows teams to re-evaluate the work they are doing and adjust in given increments to make sure that as the work and customer landscape changes, the focus also changes for the team.

If you’re new to the Agile project management, it might look at first like a complex and difficult-to-manage system. But, whether you realize it or not, you’re already doing many of the things Agile requires. With a few tweaks, you’ll be on your way to shorter development cycles and smaller, more frequent product releases.

Agile project management does not require the oversight of a project manager, as traditional ‘waterfall’ project management does. Instead, teams share a project manager’s responsibilities to communicate and collaborate better among themselves. Results are analysed more frequently, not just at the end, and teams adapt to changing feedback and desired results, causing a process of continual development.

Agile project management may seem like a 21^st century phenomenon, but it has its roots in the rapid application development (RAD), pioneered by English IT engineer James Martin in the 1990s in software development.

This was a reaction to the top-down ‘waterfall’ processes of the previous decades, driven by the technological changes of user interface experience. It fed back knowledge from the development process into the design of the project itself, testing problems early on in the lifecycle rather than waiting until the end.

This Agile Alliance, set up in 2001, was the beginning of today’s Agile philosophy. They developed the 12 principles covered below. From this point, it has evolved among project management workflows across all industries, organizations and markets.

There are a range of advantages and disadvantages to following an Agile methodology in your business. Consider these Agile pros and cons to help decide if it’s the right direction for you.

Benefits of Agile project management.

There are various advantages of an Agile project methodology, which include:

• Freedom for employees to work on models that leverage their strengths.
• More efficient use of resources and rapid deployment.
• Greater flexibility and adaptability to changing needs.
• Quicker detection of and remedies to problems.
• Improved collaboration with co-workers and users, leading to better functionality in products that better meet user needs.
• Clearly defined goals and processes do not need to be firmed up before work can start.

Disadvantages of Agile project management.

A few drawbacks to consider before you implement an Agile project methodology are that it:

• Is easy to slide off-road without predetermined paths of action.
• Provides less predictable outcomes.
• Works less well for businesses that require plenty of time to analyze problems or undertake market research.
• Can fall flat without good collaborative skills and good personal relations.

The main difference between Agile and Scrum meetings is that Agile is a general approach to project management – Scrum is a specific method within it.

Originally created for software development, the Agile approach to project management is quickly being adapted by more than just IT teams. Some industries also looking at the Agile methodology and other Agile frameworks to deliver innovative products in uncertain environments include:

• Marketers
• Universities
• Military
• Automotive industry

Many organizations can benefit from Agile project management, and it’s simple to set up and utilize.

In the software world, when a decision to build or further develop an existing technology is made, the end product may be hard to define. Agile allows for that ambiguity because of its flexibility to change direction on a project as work moves into the future.

While you can take advantage of Agile software, books, or Agile coaches, each Agile team is unique. Understanding the basics can help you put together an Agile methodology that works for you and your team.

The Agile Manifesto outlines 4 core values and 12 guiding principles that serve as a North Star for any team adopting an Agile methodology.

The 4 core values of Agile are:

1. Individuals and interactions over processes and tools.

As sophisticated as technology gets, the human element will always serve as an important role in any kind of project management. Relying too heavily on processes and tools results in an inability to adapt to changing circumstances.

2. Working software over comprehensive documentation.

As important as documentation is, working software is more important. This value is all about giving the developers exactly what they need to get the job done, without overloading them.

3. Customer collaboration over contract negotiation.

Your customers are one of your most powerful assets. Whether internal or external customers, involving them throughout the process can help to ensure that the end product meets their needs more effectively.

4. Responding to change over following a plan.

This value is one of the biggest departures from traditional project management. Historically, change was seen as an expense, and one to be avoided. Agile allows for continuous change throughout the life of any given project. Each sprint provides an opportunity for review and course correction.

Agile methodologies can be as diverse and unique as each individual team. However, the 12 principles of Agile should always guide your decisions and product development.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (or whatever else you deliver).
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver projects frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
4. Coordinating team members must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6. Face-to-face conversation is the most efficient and effective method of conveying information to and within different teams.
7. The final product is the primary measure of progress.
8. Agile processes promote sustainable development. All stakeholders should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Datasheet:  The Agile Marketing Cheat Sheet
Webinar:  What’s Keeping Marketers From Going Agile?

User stories.

Put simply, a user story is a high-level definition of a work request. It contains just enough information so the team can produce a reasonable estimate of the effort required to accomplish the request.

This short, simple description is written from the user’s perspective and focuses on outlining what your client wants (their goals) and why.

Sprints.

Sprints are a short iteration, usually taking between one to three weeks to complete, where teams work on tasks determined in the sprint planning meeting. As you move forward, the idea is to continuously repeat these sprints until your product is feature ready.

Once the sprint is over, you review the product see what is and isn’t working, make adjustments, and begin another sprint to improve the product or service.

Stand-up meetings.

Daily stand-up meetings (under 10 minutes), also known as ‘daily Scrum meetings,’ are a great way to ensure everyone is on track and informed. These daily interactions are known as ‘stand up’ because the participants are required to stay standing, helping to keep the meetings short and to the point.

Agile board.

An Agile board helps your team track the progress of your project. This can be a whiteboard with sticky notes, a simple Kanban board, or a function within your project management software.

Backlog.

As project requests are added through your intake system, they become outstanding stories in the backlog. During Agile planning sessions, your team will estimate story points to each task.

During sprint planning, stories in the backlog are moved into the sprint to be completed during the iteration. Managing your backlog is a vital role for project managers in an Agile environment.

Agile team roles.

Different Agile methodologies may require specific team roles to adhere to the framework, or may not require any specified roles. Though individual Agile implementation may not require all of these roles, here are a few common roles that you may find:

• Scrum Master.  The Scrum Master ensures that each sprint stays on track and helps to remove or resolve any issues or challenges that may come up. They are the team’s advocate.
• Product owner.  The role of the product owner is to define the goals of each sprint, manage and prioritize the team backlog, and be the voice of the customer or internal stakeholder.
• Team members.  The people on this team are the ones who execute the work in each sprint. These teams, usually of three to seven people, can be composed of different specialties and strengths. Or they can be teams of people with the same job roles.
• Stakeholders.  This is an informational role only. The stakeholders should be kept up to date on the product and sprint goals, have the opportunity to review and approve work during a sprint, and provide feedback during the sprint retrospective.

Each Agile methodology has its own unique list of team members and roles. While the titles may change, there are a few universal role characteristics that most Agile team structures should have:

1. T-shaped:  A valuable Agile team member has a wide breadth of basic knowledge about their subject but also deep knowledge, experience, and ability in one (or more) specific areas.
2. Cross-functional:  Cross-functional Agile team members have skills outside their traditional areas. They might know some basic graphic design principles and data analysis or even some HTML/CSS.
3. Adaptable:  If they have a diverse skill set, they know how to use it. No matter the environment, their output remains consistent.
4. Curious:  Part of optimizing and becoming more efficient is asking the right questions and challenging the way things have always been when it’s appropriate.
5. Entrepreneurial:  An Agile team member is one that doesn’t wait to be told what to do. They’re ready to fill in and develop campaigns where they see a need.
6. Team-oriented:  Team players prioritize the success of the team over their own personal glory. If everyone is delivering on time and syncing well together, they see that as a win.
7. Committed to excellence:  One of the key benefits of Agile projects is delivering quality work, faster. Team members who are committed to excellence don’t settle for average. They’re not hung up on perfection, but they’re dedicated to always producing their best work.

Learn more about Agile teams.

The goal of Agile is to produce shorter development cycles and more frequent product releases than traditional waterfall project management. This shorter time frame enables project teams to react to changes in the client’s needs more effectively.

As we said before, you can use a few different Agile frameworks — Scrum and Kanban are two of the most common. But each Agile methodology will follow the same basic process, which includes:

1. Project planning.

As with any project, before beginning your team should understand the end goal, the value to the organization or client, and how it will be achieved.

You can develop a project scope here, but remember that the purpose of using Agile project management is to be able to address changes and additions to the project easily, so the project scope shouldn’t be seen as unchangeable.

Learn more about project planning.

2. Product roadmap creation.

A roadmap is a breakdown of the features that will make up the final product. This is a crucial component of the planning stage of Agile, because your team will build these individual features during each sprint.

At this point, you will also develop a product backlog, which is a list of all the features and deliverables that will make up the final product. When you plan sprints later on, your team will pull tasks from this backlog.

3. Release planning.

In traditional waterfall project management, there is one implementation date that comes after an entire project has been developed. When using Agile, however, your project uses shorter development cycles (called sprints) with features released at the end of each cycle.

Before kicking off the project, you’ll make a high-level plan for feature releases and at the beginning of each sprint, you’ll revisit and reassess the release plan for that feature.

4. Sprint planning.

Before each sprint begins, the stakeholders need to hold a sprint planning meeting to determine:

• What will be accomplished by each person during that sprint
• How it will be achieved
• Assess the task load

It’s important to share the load evenly among team members so they can accomplish their assigned tasks during the sprint. You’ll also need to visually document your workflow for team transparency, shared understanding within the team, and identifying and removing bottlenecks.

Learn more about sprint planning.

5. Daily stand-ups.

To help your team accomplish their tasks during each sprint and assess whether any changes need to be made, hold short daily stand-up meetings. During these meetings, each team member will briefly talk about what they accomplished the day before and what they will be working on that day.

These daily meetings should be only 15 minutes long. They aren’t meant to be extended problem-solving sessions or a chance to talk about general news items. Some teams will even hold these meetings standing up to keep it brief.

Learn more about daily stand-up meetings.

6. Sprint review and retrospective.

After the end of each sprint, your team will hold two meetings.

First, you will hold a sprint review with the project stakeholders to show them the finished product. This is an important part of keeping open communication with stakeholders. An in-person or video conference meeting allows both groups to build a relationship and discuss product issues that arise.

Second, you will have a sprint retrospective meeting with your stakeholders to discuss:

• What went well during the sprint?
• What could have been better?
• Was the task load too heavy or too light for each member?
• What was accomplished during the sprint?

If your team is new to Agile project management, don’t skip this essential meeting. It helps you gauge how much your team can tackle during each sprint and the most efficient sprint length for future projects.

Learn more:  Workfront for Project Management.

Blog:  Agile vs Waterfall

Once you feel comfortable moving forward with Agile, you’ll want to start by educating your Agile teams on:

• How they will transition into their new roles
• When they will begin having daily stand-up meetings
• How they will transition their current work into the Agile methodology

After you establish transition steps and make sure everyone is comfortable with the new style of work, you’ll want to monitor and track their progress and success.

If they are struggling to run at the same velocity as before, what may be causing those issues? If the team isn’t updating stories with their current status, have those statuses been clearly defined?

Tracking a new Agile team’s progress or success will encourage confidence in the changes. In addition, having these Agile metrics will help justify the benefits of transitioning a team to Agile when in higher-level meetings.

Finally, it’s important to provide your team and new Scrum Masters with a form that outlines helpful questions to ask during daily stand-ups and the iteration retrospectives. This provides some excellent documentation for future reviews of processes. It will also allow for the team to identify areas that need improvement and help it answer questions it may not think to talk about if it is new to Agile.

Learn more:  Implementing Agile at scale

What are the three biggest challenges of Agile project management?

Resistance to change is a common pitfall. Waterfall project management remains top of the tree and the go-to for companies reluctant to try out new workflows. There could be a lack of support from management, who want old-fashioned measurables, or colleagues who just want to be told what to do.

What are the most popular Agile project management tools?

There are a wide range of Agile project management tools available. The best one can depend on your business, industry and any priority areas. Some of the most popular frameworks to implement an Agile methodology include:

• Scrum
• Kanban
• Extreme Progamming
• Crystal
• Disciplined Agile Development

When is project management considered truly Agile?

Project management can be considered properly Agile when it offers the following:

• Transparency
• Customer focus
• Adaptability
• Sense of ownership (shared leadership)
• Continuous improvement

These are the most basic and important parts of Agile project management. As you transition your team to an Agile methodology, these processes, Agile software and tools, roles and principles will help you change your mindset and begin working together to be more flexible and adapt to changes as they come.

Agile isn’t for everyone, but teams who use it correctly will experience enormous benefits, including streamlined work processes and rapid innovation.

Scrumban is an interesting concept that is halfway between Scrum and Kanban — two different Agile methodologies for managing projects. It was initially created to help project teams transition from Scrum and Kanban. But, many teams discovered that Scrumban enables them to capture the best of both worlds.

Below, we’ll discuss what Scrumban is, which elements it takes from Scrum and Kanban, and how it might benefit your projects. 

What is Scrumban?

The word “Scrumban” is a combination of Kanban and Scrum terminology. So, the best way to explain Scrumban is to provide an overview of the two different frameworks and then discuss how they’ve merged to create Scrumban. 

What is Scrum? 

Scrum is an Agile framework that consists of one to four-week sprints. It is designed to help small self-organized teams consistently deliver concrete products or outcomes. 

The Scrum team manages a list of overall project requirements (called the backlog) and determines which ones will be accomplished in the next sprint. After this has been determined, the sprint is “locked,” and any other work must be completed in a future iteration. At the end of each sprint, the outcomes are reviewed, and the plan for the next iteration is created or revised.

What is Kanban? 

Kanban is less time-based than Scrum. Rather than focusing on sprints and scheduled deliveries, it focuses on to-do lists and spreading work out across the team. Instead of limiting work by sprint, it’s limited by workloads. In other words, at any time, you can change which tasks will be completed next as long as you don’t increase the number of assigned tasks.  

Kanban uses a board format to help teams visualize the project workflow and understand what stage tasks are in. It was initially managed using post-it notes on a physical board, but there are now software options that provide virtual Kanban boards. 

How does Scrumban combine the two frameworks?

So, what is Scrumban? Scrumban seeks to find a middle ground for teams who find Scrum too rigid and Kanban too flexible. 

Scrumban typically uses the Scrum backlog approach of planning, prioritizing, and allocating work. But, it uses Kanban boards to help visualize the planned work so teams can quickly see task progress and pinpoint bottlenecks. Some Scrumban teams maintain the use of sprints, while others choose to abandon this Scrum requirement.  

Scrumban often uses Kanban rules around the amount of work that can be in progress at any one time. Using this method, a team will start a set amount of tasks at once. Then, other work is only initiated when some of those activities finish, so there are never more tasks in progress than the number the team deems it can handle at once. 

Introducing the Scrumban process

Agile is all about flexibility and adapting to the needs of your team and project. Therefore, not all Agile teams practice Scrumban the same way. 

Here’s a typical Scrumban process flow:

1. At the beginning of the project, the team creates a project backlog of all known requirements, features, and outcomes. New requirements are added as they are discovered.
2. Before each iteration or sprint, the team creates a WIP (work in progress) list of items from the backlog. These are requirements they want to accomplish in the upcoming iteration. 
3. The WIP is placed in a “to do” column on the Scrumban board.
4. When a team member is ready to take on a new task, they take something from the ‘to do’ column on the board and place it in the ‘in progress’ column. Once complete, they will move it to the ‘done’ column and take on a new piece of work. (No one completes more than one task at a time.)
5. If the number of activities in the ‘to do’ column gets too low, a planning meeting is held to add more items to the WIP. So, for instance, if your team has only five tasks left, a planning meeting may be held to add more, even though the iteration isn’t over yet. 
6. Throughout the project, teams attend daily standup meetings to discuss what they’ve completed in the last 24 hours, what they plan to do in the next 24 hours, and any problems they’re facing. 

Scrum vs. Kanban vs. Scrumban: which to choose?

When considering whether to implement Scrum vs. Kanban vs. Scrumban, it’s important to realize there’s no one right answer. Different frameworks work best for different projects and teams. 

Scrum is often the best option for projects that are expected to develop and deliver physical products consistently. If you have a customer who wants to see progress every few weeks, Scrum may be a better framework for you. 

Kanban is typically the best approach for projects providing a service or that have continually changing priorities. For instance, if you’re providing support for a delivered software, Kanban is a great option. 

If you have a project that has both product and support features (such as providing new software and a maintenance package), then Scrumban may be the right choice. It enables you to bring together the strengths of both separate frameworks. 

Whether you’re using Scrum, Kanban, Scrumban, or any other framework, the right project management software can help make your project a success. Wrike supports multiple frameworks so that each team can embrace the one that works best for their current project. Check out a free trial today.

At the beginning of 2017, our then three-person content team here at Wrike was faced with a rather large problem. Because we proofread every bit of English text that goes out on a public-facing platform, we were getting deluged by requests from 400+ employees to both write and edit lead gen emails, UI/UX tooltips, landing page messages, sales enablement materials, and even job descriptions! There was precious little time to create the inbound marketing content we were hired for.

Because we didn’t have the leeway to add personnel, our only choice was to revise the way we did things in order to handle the chaotic influx of work. More specifically, we chose to get our work done using a Scrum framework.

How Scrum Helps With the Chaos

We’ve written about Scrum before. It’s a method for accomplishing work where teams use principles from the Agile Manifesto made famous by pioneering software development teams back in 2001.

Scrum is a process whereby teams break down and accomplish large projects in chunks, allowing for iterations to improve the product progressively. Usually, the process is broken down into the three artifacts of Scrum. And even though it was birthed in the software development industry, it is just as effective in others — from manufacturing to marketing even with projects such as renovating a house!

Marcus Miller, the founder of the UK-based digital marketing agency Bowler Hat shares: “After we had such success at work with Scrum, I used the same approach for renovating a house we bought. I am in the UK and it was a Victorian-era three story property. Not decorated in 30 years. No heating. Complete refit from wiring to heating to decoration. Scrum helped us manage that project and maintain my sanity as well. It is super flexible and certainly works well outside of the software development world. Which makes sense as LEAN really comes from manufacturing principles anyhow.”

Scrum is a great tool with which to face an abundance of to-do items because the approach forces teams to look only at concrete next steps that have been prioritized. Massive projects can be accomplished in bite-sized chunks. Woolly mammoths can be eaten, piece by piece.

Even better, a working version of the final product (the Minimum Viable Product or MVP) is produced at every sprint. This allows the team to continuously improve the project with every work period, instead of trying to perfect the product right out of the gate.

The Elements of Scrum

There is a Scrum vocabulary you’ll need to get familiar with before digging into the methodology itself. Boiled down to its essence, Scrum requires three roles in its participants:

• A product owner, who owns the scope, the backlog, and can clarify all questions
• A Scrum Master, who facilitates the standup meetings and finds the most efficient way for the team to get work done
• The team members, who are typically cross-functional and are under pressure to deliver

The Scrum process itself involves:

• A board (either a physical or digital Scrum board) where the team can see what tasks are being worked on, by whom, and the status of each task
• The product owner breaking down a massive project into individual tasks (the backlog) and prioritizing which tasks in the backlog must be dealt with first
• Team members working on their priorities for a specific duration, AKA a sprint (i.e. a day, a week, two weeks, a month)
• A Scrum Master leading a daily standup meeting of no more than 10 minutes where each team member updates the team on his or her work progress
• A retrospective at the end of each Scrum period to evaluate what worked and what can be improved in the future (lessons learned).

How to Make Scrum Work

What are some best practices to keep in mind when starting out Scrum for the very first time?

1. Clarify Priorities in Your Product Backlog

First off, you have to know what is the most crucial task to accomplish.

This means the product owner should list what goals need to be accomplished and which tasks are priorities. The Scrum Master then facilitates the team to contribute ideas on what work needs to be done to accomplish those goals along with estimates (in time, effort, or budget). The product owner decides what is the MVP — what gets delivered, what is not. And the team decides how many of those deliverables can be completed by the end of a sprint.

Seth Messer, Senior Developer at Vecteezy explains how this process is crucial to figuring out what needs to be done to achieve the goal: “As developers, we have a timeline (i.e. we have an end goal for a unit of work). This means we know what we want to do, and we want it done by a certain point. So for instance, maybe we want a new version of a website completed by February 2018. Starting the workload is easy, and we know what the end result should look like (e.g. a new website), but all that time in the middle is hard. What work should be done and when?”

2. Keep Standup Meetings Short and Precise

What are the Scrum ceremonies? The daily standup meeting is a crucial part of the Scrum process as it allows the team to gather around common problems and eradicate them together. It should be no longer than 10 to 15 minutes depending on team size. And while meetings are common elsewhere in the business world, the standup might not be immediately comfortable for a new Scrum team.

Gavin Woods, certified SCRUM Master from the SCRUM Alliance, leads digital transformation projects for clients in various industries for PITSS and acknowledges that it may take getting used to. He says: “Frankly, utilizing Scrum in some organizations can be an entire work-culture shift. As it requires people to be more open about their work, about their struggles, and solving problems together. Some people are not comfortable with that.”

“When you first start with SCRUM, the SCRUM Master needs to instill the culture of being open but precise,” Woods says. “Doing so requires SCRUM Masters to be very direct and sometimes pushy, to get team members to learn how to participate.”

The trick to keeping standups short is to (surprise) stand up during the meeting so no one is tempted to talk longer than needed. Then ask each team member to answer 3 questions, succinctly:

• What have you accomplished?
• What are you currently doing?
• What are your roadblocks? / Where do you need help?

If something takes too long to explain, it should be done in another meeting. If a task does not necessarily concern the rest of the team, it can be mentioned in passing.

The standup meeting allows roadblocks to be aired as soon as it hinders progress on your work. As such, it’s crucial to be honest when you need help from your team in a specific area.

3. Document Those Lessons Learned

Don’t forget to hold a retrospective at the end of each sprint. This is typically an hour-long meeting where the team goes over what went well, what was learned, and what could be improved for future sprints.

“This is not intended to generate a long laundry list of tasks,” Miller shares in this article, “Rather, the idea is to identify one or two small strategic improvements to the process. This often takes the form of one or two issues for each tactical approach.”

Make sure lessons are documented in your knowledge base and can be retrieved easily by anyone on the team. And don’t let the negative aspects overshadow your team’s victories.

“It’s important to maintain the balance of what went well,” says Woods. “As positivity inspires creativity.”

What Happens When You Implement Scrum?

When we implemented the Scrum process internally, our content team quickly discovered three things:

1. We were quickly working through our backlog of content creation.
2. We were more able to tackle ad hoc requests because we knew when and which individuals had bandwidth to handle them.
3. We were functioning much more collaboratively and supportively, which made it much easier to slog through the tasks.

Similar results occur for our customers who have implemented the Scrum framework and used Wrike as the tool to manage work on their Scrum Gantt chart and Scrum board.

Procurify, a purchasing software startup in Canada, found that they saved 70% of their time by planning their sprints in Wrike. They now have visibility into one another’s work and the ability to collaborate across different teams. “By having a central tool to manage the whole process,” says Eugene Dong, Co-Founder and CTO of Procurify, “we’re able to actually see what individuals are doing and if it completely matches our company goals.”

Tactus develops innovative touch screens with unique physical buttons that can appear or disappear onscreen as needed. But as they increased the velocity of production, they found their communication wasn’t keeping pace. By using Wrike to do Scrum, they shortened their sprints by 80% — from a week to a day. “Updating colleagues happens instantly without waiting for the next face-to-face, which makes collaboration between scheduled meetings much easier,” says Curtis Ray, VP of Engineering at Tactus.

Parting Advice to Scrum Newbies

Practice makes perfect. You won’t understand how to do Scrum well until you jump in and commit to the process. But once you do, it will fundamentally change how your team interacts and collaborates.

Gavin Woods leaves us with this nugget of truth: “How you implement Scrum is a process. If you took a course and became a Certified SCRUM Master, the first thing you will realize is perfecting Scrum won’t happen overnight. Everything down from the process to the principles may require not only training, but also sometimes a culture change within your organization and team because it can be a dramatic shift on how things get done.”

Kanban, Lean project management, Six Sigma, Scrum… there are a mountain of Agile methodologies to choose from. And if you’re new to project management, it can be a lot to take in. You may know that Scrum is one of the most common approaches to Agile project management, but what is it exactly? (Besides a group of scuffed-up rugby players, that is.)

Scrum is an approach to managing complicated projects that may have to adapt to changes in scope or requirements. By emphasizing productivity, focus and collaboration, Scrum teams build high-quality deliverables quickly and can more easily adapt to change. Curious about how it all works? Read on for an introduction to Scrum.

The Process

When a customer (internal or external) comes to the team with a certain need, the final product is broken up into individual chunks. (Traditionally this has been a software need, but the process also works for any project that is comprised of multiple stages and pieces, such as a marketing launch.) The pieces are prioritized and tackled in a series of short bursts called sprints. Teams can determine their own sprint length, provided it’s less than 4 weeks (one to two weeks is common). At the end of each sprint, the team delivers a product increment — essentially, a version of the product that could be shipped if necessary. Transparency is a key principle in Scrum, so teams and stakeholders review the results of each sprint together. This ensures everyone’s on the same page about priorities and deliverables, and any adjustments can be made right away.

Teams promote internal transparency through daily standups. During these brief, 15-minute meetings, everyone reports what they accomplished yesterday, what they plan to work on that day, and any current “impediments” (factors that are keeping them from working more efficiently). This visibility helps uncover problems and bring them to the forefront quickly, so the team can tackle and overcome them together.

Who’s Who: Scrum Roles

There are three main roles in Scrum: the product owner, the scrum master, and the development team.

Product Owner: Product owners represent the customer’s interests. They decide what the team will work on next, so the team’s efforts stay focused on high-priority tasks that create the most value. The Kanban product owner must always be available to provide input or guidance to the development team, although it’s important to note that product owners are not managers — scrum teams self-organize.

Scrum Master: The Scrum master’s #1 goal is to help the development team be self-sufficient. Scrum masters intercept and remove barriers to team progress, and act as a buffer between the team and any outside forces that might interfere with productivity. S/he leads daily standup meetings, so while the product owner is responsible for what the team will produce, the scrum master oversees the how.

Development Team: Development teams are made up of cross-functional team members, so the group has all the necessary skills to deliver the final product. The team focuses on only one project at a time; members don’t multitask or split their efforts between multiple projects. Once the product owner makes an ordered list of what needs to be done, the development team decides how much they can complete in a single sprint and plan accordingly.

You may have heard the words “pig” and “chicken” tossed around in conversations about Scrum. If so, you may be asking yourself, what do farm animals have to do with software development? Within the development team, members are assigned roles as either pigs or chickens. A pig is the person responsible for the completion of a specific task. They’re the ones “risking their bacon.” Chickens may be involved in the task, but are not ultimately responsible. Only pigs can speak about their tasks during daily standup meetings; chickens just listen.

Core Values

As an Agile framework, Scrum shares the values of the Agile Manifesto. But it also creates its own guidelines. These are the five golden rules in Scrum:

Openness: Scrum sees collaboration as the most effective way to create the best possible product. So teamwork and transparency are essential. Rather than anxiously downplaying  problems, Scrum team members are open about their progress and any roadblocks they encounter.

Focus: With Scrum, multitasking is out. Since productivity is key, splitting the team’s attention across multiple projects, or redirecting their efforts mid-sprint by shifting priorities, is avoided at all costs. Instead, teams concentrate on the task at hand for the highest velocity and best quality product.

Courage: Teams must have the tenacity to commit to an ambitious (but attainable) amount of work for each sprint. Scrum masters must also be able to stand up to stakeholders if necessary, and the product owner must guide the development team with authority.

Commitment: Each sprint is itself commitment: teams must agree on what they’re going to accomplish and stick to it. This value is reflected in each team’s unique “Definition of Done,” a list of criteria to determine whether a feature or deliverable is truly finished — that it’s not only fully functional, but meets the team’s standards for quality.

Respect: In the service of true collaboration, roles and responsibilities are transparent. Each member of the team is respected equally, regardless of job description, seniority, or status. The development team must honor the product owner’s authority in deciding what the team works on, and the product owner needs to respect the team’s need follow whatever work process is best for them.

Now that you’ve got the basics, are you curious about the pros and cons of Scrum (and other top project management methodologies, such as Kanban vs. Scrum)? Wondering what are the 5 Scrum ceremonies? Read our Quick-Start Guide to Project Management Methodologies and you’ll be an expert in no time!