Understanding Agile Project Management

There’s a lot of buzz about Agile software development. But Agile is more than just a process for creating software: it’s also a mindset and a management method. For a company or team to become truly agile, they need to not only be open to new ideas about software development but also the process by which they manage and oversee this development process. After all, Agile is a new kind of thinking about software development-not just during output but from beginning to end.

Teams who cannot commit to learning the management process risk sabotaging their own success at the onset of any new project.

Fortunately for companies, the agile project management mindset isn’t just applicable to software development; it’s viable for nearly any department. From marketing to finance, Agile principles can help organizations find smarter, faster ways to collaborate on projects and services in order to deliver higher quality results to their customers. But agile, like anything, is only valuable if the person understands it. We’ll explore what it takes to get the right methods and mindset in place.

A Brief Overview of What Agile Software Development Is

If you’re not already familiar with Agile software development, we’ll recap it briefly before proceeding. (If you’d like, you can read more about it here). Agile replaces the old traditional software development lifecycle (SDLC), also known as waterfall, with a faster and more collaborative approach that does several things differently:

The primary aim of Agile is responsiveness. Agile software development is designed to help teams quickly get a working software prototype up and running that they can test and modify as early as possible in the development process. The goal is simple: create a prototype that can be built, presented to its end users for testing, and refined accordingly until the best solution has been developed. Rather than keep the end users of a new software waiting until a finished version has been released, Agile software development processes invite them to participate in the development process in order to improve the software’s usability. This not only helps developers better understand what their customers want it also helps users get the exact requirements they wanted.

For customers, some of the most outstanding benefits of Agile software development include:

• Reduced costs due to the hyper-focus on value at every phase of the project
• Faster delivery thanks to the focus on working software over documenting deliverables
• Increased project predictability and transparency via frequent (often daily) project reviews

Agile Software Development Is More Than a Process; It’s a Way of Thinking

What sets Agile apart from many of its other counterparts is that it has a clear and well-developed set of principles that companies can apply to almost any business situation.

At its core, Agile isn’t a discrete set of tools or a specialized programming language. While it does bring new roles to the process, the majority of Agile value lies in how the project is managed. This extends from how people collaborate, to how the project is planned. How the project is managed, not the technology, makes all the difference. It’s also why Agile can easily be extended to other disciplines.

A More In-Depth Look at Agile Principles

Now that we understand Agile software development (and why it’s more than just a process), we can look at some of the guiding principles behind the Agile mindset and how it’s fundamentally different from traditional software project management thinking. As you read through the principles, imagine how these best practices can make a difference in other disciplines.

Dynamic Collaboration Over Documents

A core principle of Agile management is to move promptly from documents to collaboration. This means that once a project’s requirements are captured, the next step is to move quickly to a working prototype. Then, as requirements emerge and evolve, those changes are directly applied to the prototype.

This dynamism doesn’t just impact the beginning of the process. The collaborative nature of Agile impacts the entire timeline, including how work is managed and measured. When we review project phases later in the article, we can see how constant collaboration can take the place of extensive documentation, saving everybody time.

Iterative Phases Versus a Linear Process

When the Agile Manifesto was first published in 2001, it sought to overturn traditional waterfall software development. One of the manifesto’s key ideas was a move from a rigid linear process to a series of iterations that sometimes overlap. Rather than waiting for one phase to end before the next begins, Agile management encourages overlapping phases of development where appropriate.

Breaking a long process into more modular phases makes it easier to manage. It also makes it simpler to iterate, as certain phases can be looped without slowing down the overall project. It also shortens the time distance between a decision and review, meaning feedback comes faster. This, in turn, leads to faster adjustments or fixes, reducing the overall timeline while boosting quality.

Self-Organized Collaboration, Not Command and Control

Agile software development works because teams are empowered to collaborate in small, cross-functional groups. They are assigned a task and expected to reach that goal without micromanagement. This is one of the toughest cultural challenges for some organizations, especially those used to rigid hierarchical management structures.

The cross-functional nature of Agile teams also allows for a high degree of self-organization (more on this later). Teams collaborate as required, checking in during a daily scrum to report on their work. Managing this level of autonomy requires balancing a big-picture perspective with the need to watch for constraints or delays. Ideally, it’s those challenges where most of the project management time is focused.

ALSO READ: What Is Rapid Application Development? A Faster Path to Superior Value

Continuous Transparency Instead of Retrospective Reporting

You’ll learn more about how Agile “looks back,” but continuous reporting is a key feature of Agile. Rather than waiting until a project or phase ends, frequent project collaboration and measurement ensures the project is always on track. If part of the work is delayed, the risk can be contained and mitigated quickly, rather than bring the whole piece of work to a halt.

This puts a burden on project management to quickly consume lots of status information. They need to know precisely where each piece of the project stands. They’re also responsible for sharing that information with the customer and other stakeholders.

Next, we’ll learn how those duties are split between specialized Agile roles.

The Unique Roles in Agile Project Management

While Agile project management sets it apart philosophically, its unique project roles turn that philosophy into action. And they’re also responsible for the unique division of cross-functional labor that makes Agile faster, smarter, and more cost-effective.

Product Owner

The Product Owner’s primary duty is to serve as the voice of the customer and their requirements. This doesn’t remove the customer from the process, which is essential since their feedback is both valuable and essential to Agile methodology. But the Product Owner stands in as their representative as their needs are captured and work begins. They also manage the tradeoffs that come up during project management, prioritizing needs, and scheduling features. They are responsible for respecting and refining customer requirements from start to finish.

Scrum Master

You’ve probably heard of a Scrum if you’re familiar with Agile. Scrum is a frequent (sometimes daily) collaborative check-in between teams. It’s the Scrum Master’s role to orchestrates the check-ins. This role retains some traditional project manager duties, but its primary responsibility is to ensure teams adhere to Agile principles. This makes the Scrum Master as much a coach and mentor as they are a traditional PM. Think of them as a Project Manager Plus.

Team Members

This role includes everyone else working on a software project, including designers, developers, database specialists, and testers. It would also include other required personnel, along with whatever subject matter experts are needed.

Project Managers (Or Not)

Some Agile advocates will tell you that the Agile methodology doesn’t require project managers. This is especially true since the duties of a traditional PM role are already divided across the team. While assuring success and tracking progress are handled between many of the pre-defined roles, there are still details that fall outside these duties.

This can include managing budget and monitoring risks from outside the project. For instance, if a business needs to shift resources between Agile projects, schedules need to be adjusted. This is an excellent example of duties that would need to be handled by a project manager. The project manager might also be responsible for communication between the Agile teams and the larger organization.

The Unique Processes of Agile

Beyond unique roles, the Agile process also has some different project phases and artifacts. Combined with new roles and rules, this is what differentiates the methodology.

Building User Stories

User stories capture a project’s business and technology requirements. Developed by the Product Owner, they’re written in a way that is tightly focused on and around the user. The goal is to clarify the requirements into a single, easily understood story. For instance, a single user story might be “the user logs into an account for the first time.”

The user story can be expanded to capture additional technical detail, as long as it stays focused on the same user and task. The above story can be expanded to capture how a user logs into an account for the first time from a new device. Beyond that, new user stories are required.

Estimating User Stories

Once these stories are written, they must be translated into “units of work.” This is done by assigning them points based on the level of effort and potential risk. Labeled estimation, the story points are assigned in a collaborative way between the team and the Scrum Master.

Working in Sprints

Sprints are the smallest unit of work inside Agile. There’s no magic length, but a good working average is about two weeks. Each sprint is built around a certain number of stories. This means, at the end of the sprint, the team expects the included stories to be completed.

Measuring via Burndown

Progress inside a sprint is measured via a burndown chart that tracks work versus time. It’s reviewed during daily scrums and also helps anchor conversations between the Scrum Master and the Product Owner.

Creating Backlogs

Sometimes a story needs to be deprioritized. Or, during a Sprint progress, not everything gets done. In either case, these incomplete stories are placed into either a sprint or project backlog by the product owner. Since they’re responsible for prioritizing stories, it’s their job.

Looking Back via Retrospectives

We’ve talked a lot about continuous feedback and constant measurement. That doesn’t mean that Agile doesn’t value real project retrospectives. The retrospective can occur at the end of a Sprint, or at the end of the project itself. The meeting focuses on how the teams collaborated and challenges encountered. Most importantly, it’s about learning from the past to ensure the next iteration is better.

RECOMMENDED: How to Get Your Team To Execute (and Love) Agile Digital Transformation Practices

Obstacles to Effective Agile

Despite Agile’s enormous potential for organizations looking to create value for their customers, there can be challenges to implementation. They’re all solvable, but they serve as a decent measure of potential Agile success.

Culture-Driven Constraints

Agile works best in organizations willing to adapt to both a new mindset and a new way of managing work. It means that some organizations might find converting to Agile more difficult than others. When you’re assessing readiness, ask yourself:

Is your organization ready for change?

Agile methodology requires embracing new skills and structures. Large, change-resistant cultures are not always ready to pivot. This doesn’t mean Agile won’t work. It just means the challenges need to be confronted first.

Is this a collaborative, cross-functional culture?

Agile works best in a collaborative environment where teams are empowered to work across siloes. If your teams are still heavily segregated into specialist roles, that’s a constraint that needs to be solved.

Can you get the talent?

Even a top-notch software team, left to its own devices, won’t succeed inside Agile. The specialized roles, especially Product Owner and Scrum Master, are absolutely critical. This talent must either be hired or trained.

Project-Driven Constraints

Sometimes it’s not your organization that stands in the way of successful Agile implementation. Particular projects might not be a good fit.

Is the customer ready?

Customer feedback, and lots of it, is key to the Agile process. If your customer isn’t ready to engage to this level, it will make Agile difficult but not impossible. Just remember, the Product Owner can’t replace the customer, no matter how passionate they are.

Is the project easily managed?

Agile works best when projects can be divided into smaller component pieces or separated into distinct features and functions. Overly complicated projects, especially those with very specialized infrastructure needs, aren’t always a good fit for true Agile.

Feeling Ready?

If you were able to answer yes to all of the above questions, you might be ready to take on your first Agile project. So, what’s the next step on your path to Agile project management? First, discuss it with your team to build consensus. The next step is to find a partner that can help you scope the project and bring the necessary talent you need to get started.

At Kintone, we work with organizations looking to take this first step. We can help you identify both Agile opportunities and obstacles to help you create a path forward. We’ll help you solve the business, technology, and cultural constraints that arise. Most importantly, we’ll be with you every step of the way.

Originally published at https://blog.kintone.com.