The Agile Project Manager: Agile Disciplines, Part 1

When you hear the term, “agile,” remember that it’s comprised of many different frameworks and approaches that fundamentally support a more interactive model to prioritize and deliver features. Collectively, those various methodologies are known as agile. They all promote the values of the agile “manifesto,” and they’re consistent with those principles.

As I promised in the first article of this agile series, it’s time to provide details about some of those commonly used agile disciplines so that you can decide which ones to leverage for your projects. In this first part of a two-part article, I’ll cover three frameworks: dynamic systems development method, scrum and extreme programming. Next time, you’ll receive a briefing on Rational Unified Process, Kanban and lean software development, feature-driven development and Crystal.

Dynamic systems development method or DSDM is probably the original approach taken for agile development. Even though it’s based on all the principles we have come to know as agile, it surfaced before the term “agile” was adopted. However, it’s little known outside of the United Kingdom.

Scrum, another agile development method, concentrates particularly on how to manage tasks within a team-based development environment. It’s the most popular and widely adopted agile method, probably because it’s relatively simple to implement and addresses many of the management issues that have plagued IT development teams for decades.

Extreme programming or XP is a more radical agile methodology, focusing more on the software engineering process and addressing analysis, development and test phases with novel approaches that make a substantial difference to the quality of the end product.

While DSDM is probably the most complete agile methodology, scrum and XP are easier to implement — and complementary because they tackle different aspects of software development projects and are both founded on very similar concepts.

Dynamic Systems Development Method

With its origins in the early 1990s, dynamic systems development method (DSDM), addressed the agile technical community’s need for a standard project delivery framework that was based on the popular Rapid Application Development (RAD) system. Due to the widespread use and popularity of RAD, software development had grown with little structure to guide the application of RAD.

To provide better software delivery processes and promote a common industry framework, developers in 1994 formed the DSDM Consortium, an organization that still exists today. The DSDM methodology grew and matured, providing a great foundation for planning, managing, executing and scaling Agile in iterative software development projects.

DSDM is based on nine basic principles:

• Business drives development;
• Development is incremental;
• The team is open to change;
• Initial requirements are set at a high level;
• Development and testing are tightly integrated;
• Collaboration and cooperation rule;
• End users must be involved;
• Teams are empowered; and
• Releases are frequent.

As you can see, these principles focus on the integration of the team, customers and stakeholders around the job of delivering business value. Thus, “fitness for business purpose” becomes the primary criteria for delivery and acceptance, delivering on the Pareto principle: 80 percent of the system value can be delivered in 20 percent of the time.

As the project/development team maps requirements, these requirements are baselined at a high level early in the project. As the team begins working on these requirements, rework is built into the process, allowing changes or modifications to be reversed for all development. Customer requirements are planned and delivered in short, pre-set lengths — time boxes called “iterations.”

You may have heard about requirements prioritization using “MoSCoW Rules,” a term that refers to the mnemonic for assigning priority:

• Must have requirements;
• Should have if at all possible;
• Could have, but not critical; and
• Won’t have this time, but potentially included later.

All work prioritized at the highest level must be completed. Not every requirement in a project or iteration is considered critical, so less critical features or items can be moved to other iterations to keep them from affecting the highest priority requirements.

Here’s what’s useful about the DSDM framework for project delivery: You can implement DSDM with other methodologies, such as extreme programming or the Rational Unified Process, making it a great option for very large-scale development projects.

Scrum

Scrum, one of today’s more popular project management frameworks, is more lightweight than other agile options. It’s popular today because of its simplicity and proven capability for helping technical teams adhere to engineering best practices and frameworks and for helping participants manage, direct and control incremental or iterative projects.

The scrum process follows a series of sprint cycles leading to a release of the product or some functionality to stakeholders or end users. You might find it helpful think of it as a miniature waterfall project lifecycle, contained within delivery of pre-defined functionality or features and allowing for the progressive elaboration of requirements with end users during the process. This process ensures a higher level of satisfaction for users and stakeholders, while still keeping the project confined to time-boxes.

With scrum, several roles work together in the process of delivering projects. Those include:

• The product owner;
• The scrum master;
• Team members;
• Stakeholders; and
• Users.

If you’ve worked around scrum teams, you might have heard references to “chickens” and “pigs.” These terms refer to the classification of involvement levels for different stakeholders in the scrum meetings.

As illustrated in the following cartoon, chickens only have involvement in the meetings; pigs are the people who are primarily speaking and actively committed.

The scrum master is the overseer of the process — that is, the person who compiles and records progress metrics, action items, features and the things to move from the backlog to the sprints. He or she is the facilitator of the team and the process, but not the director of the actual tasks.

Stakeholders and users actively work with the teams. Sometimes they’re even embedded or collocated in a team. They make sure that immediate feedback and fine-tuning of the functionality will deliver the necessary value. This involvement allows planning to be done at a higher level, with requirements unfolding as the teams tackle the work in each sprint.

Scrum team members, who may come from cross-functional teams, collaborate to produce estimates. Then, they sign up to deliver shippable or functional increments during successive sprints. Sprints can range from a week to a month, such that teams have enough time to deliver functionality to the end users and stakeholders. These time-boxed increments ensure the team’s focus on building working software or product. Items not completed are moved to later sprints or to the backlog for re-prioritization.

Once a team commits to a sprint’s product backlog, only the team itself can add functionality or features during the planning process. After a sprint is completed, the scrum master analyzes and reprioritizes the product backlog, and the next set of features or functionality is selected and approved for the next sprint by the scrum master and product owner.

The product owner works with the development team to help map out important functionality and then to prioritize the functionality into what is called the “backlog.” The product backlog consists of features, identified bug fixes, functional and non-functional requirements and improvements to be completed to deliver a working system successfully.

Anyone building complex projects can benefit from using scrum to help prioritize items in the product backlog and pare down large lists into manageable tasks with a high level of interaction among the members of the delivery teams and the stakeholders and end users.

Just like all the other methodologies I’m profiling here, scrum has provided successful delivery to large and small projects with large and small companies worldwide.

If you want to read more about scrum in particular, I recommend looking up the writings of Jeff Sutherland, Ken Schwaber, and Mike Beedle, all of whom have been some of the main contributors to the growth and evolution of scrum.

The Scrum Alliance offers some great success stories and case studies work checking out as well.

Extreme Programming

Extreme programming or XP emphasizes teamwork. Managers, customers and developers are all equal partners in a collaborative team. XP implements a simple yet effective environment in which teams become highly productive. The team organizes itself around the problem to solve as efficiently as possible.

XP and scrum are similar, but you should be aware of some key differences between these two methods. Typically, scrum sprints last longer than XP iterations. For example, while a scrum sprint may last between a week and four weeks, the time for a normal XP iteration is one to two weeks. In addition, scrum teams don’t allow changes during sprints, but XP teams are allowed to make changes during iterations.

XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, short and rapid feedback loops, continuous testing, continuous planning and close teamwork to deliver working software at frequent intervals, typically a week to three weeks.

The original XP construct is rooted around on four simple values that guide the teams:

• Simplicity;
• Communication;
• Feedback; and
• Courage.

Those feed into the supporting practices for technical teams, such as test-driven development, pair programming or refactoring.

In XP, the “customer” works closely with the development team to define and prioritize the work units of functionality, referred to as “user stories” in the methodology. I particularly like the way user stories sometimes provide testers and end users with an easier way to elicit the functionality needed when the description becomes “a story.” The development team estimates, plans and delivers the highest priority user stories in the form of working, tested software. The user stories are completed on an iteration-by-iteration basis. Teams perform work in priority order to maximize productivity. The overall practices with XP provide a supportive, lightweight framework to guide a team and ensure high-quality software for stakeholders.

In part two of this two-part article, we’ll cover additional methodologies to round out your agile education. From there, we’ll start drilling down to provide practical information you can start applying in your work.

Read The Agile Project Manager: Agile Disciplines Part 2

Image source