The Nuts and Bolts of Agile and Scrum

By J. LeRoy Ward,  PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL

Agile and Scrum: What’s the difference?

It seems like almost every company, regardless of their industry, is practicing Agile and Scrum in some way and at some level of proficiency. If you’re new to Agile and Scrum, you may be scratching your head wondering first, what are they? And, second, what’s the difference between the two?

What is Agile?

First and foremost, Agile is a philosophy, an approach to work (think producing software or some other product) that says we will have more satisfied customers if we break up our project into iterations than try to do the whole thing at once. As we complete each iteration we have a workable increment of the product. The customer will examine it and provide feedback that we can use for the next iteration. We continue with this iterative, incremental approach until the customer is completely satisfied. An Agile approach significantly reduces the risk of customer dissatisfaction.

This is markedly different from the Waterfall approach where requirements are collected at the outset and then the team, with very little customer interaction, builds the entire product which is then delivered to the customer for acceptance. The Waterfall approach, while useful for certain projects, has proven completely unsatisfactory for projects where a high level of customer interaction is required because of the uncertainty inherent in the end product.

The Agile philosophy is best described in the Agile Manifesto, written in 2001.

Because Agile is a philosophy, it can be implemented in many different ways. One of those is Scrum. Let’s take a look

What is Scrum?

Scrum is the world’s most popular way to implement Agile. It’s not a methodology; rather it’s a framework, but with some very specific “rules of the road,” which you can find in The Scrum Guide, written by Sutherland and Schwaber. Here’s how Scrum works.

The Scrum Team is comprised of a Scrum Master, Product Owner, and the Development Team. (Note: there are no Project Managers in Scrum!) The Scrum Master is a servant leader who makes sure the Development Team follows the Scrum process. The Scrum Master also provides interference for the Scrum Team from outsiders. One important point: the Scrum Master is not the boss!

The Product Owner (PO) is responsible for maximizing the value of the product the Development Team is producing. The PO works very closely with the Development Team, helping them understand what’s important by managing the Product Backlog which is a rank-ordered list of all features, functions, requirements, enhancements, and/or fixes related to a specific product.

The Development Team does the work! They are self-organizing and make all the decisions regarding how to do the work and define what “Done” means. Each backlog item is accomplished in a series of Sprints, or iterations, which last no longer than 4 weeks. A Sprint Review is held at the end of a Sprint where the PO reviews the results.

Each day of the Sprint, the Scrum Team meets for fifteen minutes in a “daily standup,” where they answer three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. What obstacles are in your way?

The Team is not briefing the PO or Scrum Master. They are briefing each other.

Scrum is very easy to understand but is difficult to master because of the organizational change that needs to occur to implement it. Thousands of companies are using Scrum with very impressive results. Yours may find it helpful as well.

About the Author
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.


Why Project Managers Need to be Agile

As an agile and project management instructor and practitioner, I am asked quite often, “Should I worry about this agile thing?” or “Why do I need to be agile?” Many project managers are seeing the trend towards agile by many companies and are worried they may not be ready for the transition — and they should be!

As companies look for a way to avoid the problems with a traditional project approach, they are finding that agile looks promising. So if companies are moving in that direction, project managers should be looking at how they fit into the agile environment.

The first big problem in the transition is that there are no direct correlations to the project manager position in the agile environment. This alone should be a warning sign. If a project manager isn’t getting ready for this transition by picking up new “agile” skills, they are going to be left behind, or worse, let go. Smart project managers are looking to understand and develop these skills before the transition takes place.

What skills are we talking about?

To begin with, the traditional project manager skills include organizing, planning, negotiating, defining scope, managing change, motivating, facilitating, communicating and more.

Do these skills go away in an agile environment? 

Many are still used, but some are downplayed for other skills. For example, detailed planning up front and then following this detailed plan to the letter for the rest of the project is not needed or wanted in the agile environment. On the other hand, flexibility, adaptability, and teamwork, are at the top of the list.. These are not the skills we learn in traditional project management. So taking the time to learn about, develop, and practice these skills now –before they are required—is beneficial.

What else do project managers need to be concerned with?

Since the job functions are different, where do we fit in and how do we ensure there is a place for us? One of the most difficult things for a traditional project manager is thinking agile. Agile isn’t just another methodology that if you follow the process, you will be successful. It is a new way of thinking, a new way of working. If we have a new way of thinking and working, then we need to start changing now.

The position of project manager doesn’t exist in the minds of many agilists.  If you are to transition, you need to figure out which agile role you feel best suited to or can become best suited to.  In some organizations, project managers are converted into scrum masters, facilitators or coaches; in others they are product owners; in still others they are no longer needed and released.  Each of these has its inherent difficulties.

Let’s look at the scrum master/facilitator/coach position. In this position, we are supposed to be the experienced agile team member who knows enough about agile to help the team overcome obstacles and guide them to successful implementation.  Just by the description, this seems to be a bad fit for a project manager who is used to organizing the project with the help of the project management team, and then focusing the team on following the plan.

In agile, teams are self-directed! Telling them what to do will undermine the entire effort. Also, if you do not have experience with agile, you are not the best person to be guiding the team to a successful agile transition. If you want to move into this position it will take some study, andmore importantly, some practice using the concepts, especially of servant leader and group self-direction.

How about the product owner? This position seems to be a natural transition due to the amount of interaction and relationships that have been developed with the customer in working on traditional projects. So, what could be wrong with this situation? We may feel comfortable going into the position but will quickly find out that we do not know the customer side well enough to make daily decisions about how to move forward without consultation with the customer.

Unfortunately, this is exactly why a product owner is assigned to the agile team full time, so the team doesn’t need to wait for decisions, that can be made by the product owner. Unless you come from the product side or you have become an expert of the product, this is most likely not a realistic position to transition into.

Well, that only leaves being released! In some cases, where a project manager cannot make the transition, this might be in the best interest of both the individual and the company; however, what I have seen is that many organizations are short-sighted. They don’t think they need the project managers anymore, only to find out that they need someone to organize and coordinate the efforts of the developer teams using agile and the infrastructure teams still using waterfall; someone who understands both sides.

Also with larger projects, agile involves multiple teams and there is a need to have someone organize the efforts of all the teams. The project manager is perfect for this coordination roll at the higher level. You can sell this position for yourself to management.

In order to be able to fill any of these roles, a project manager would be smart to start educating themselves on agile tools and processes. IIL has a great Agile and Scrum Fundamentals class that helps teams and project managers to understand the basics and begin using the tools to improve project delivery. IIL also has an Agile Development and Project Management course to help you understand how you could transition from a traditional project management methodology into agile. See IIL’s full Agile and Scrum curriculum

Let’s revisit the original question: “Why do I need to be agile?” As organizations transition to an agile environment, we can choose to be part of the solution or not. Why not help to lead the transition to agile in your organization? This way you are ensuring there is a position for you in the new environment rather than waiting until you are required to transition. Good luck on making your move.

©2017, Nielsen Solutions LLC


Jeff Nielsen, PMP, PgMP, PMI-ACP, CSM is a
Sr. Program Manager and Agile Coach.He has over 30 years of project management experience and 7 years of program management experience in both the military and the airlines industries.


How to achieve the Agile Transformation — Part 1

By: Jim Stewart PMP, CSM

What pushes organizations to embrace Agile and what projects waterfall won’t serve.

Organizations that run projects are increasingly looking at transforming the company toward using the Agile methodology. For one example, GE – who is heavily involved in the “Internet of Things” – is having not only developers but also managers trained in . But before we can define exactly what the Agile transformation is, a little background is in order.

For years and years, companies that run projects have done so using the classic ‘waterfall’ methodology, so-called because the phases cascade down from one to the other like a waterfall.

But increasingly, organizations are looking for ways to demonstrate business value faster, to adapt to changing requirements and to deploy teams that are more nimble and self-organizing.

In short, they are considering the Agile methodology. There are several variants of Agile including Lean, Scrum, Extreme Programming, etc. But most Agile adopters are considering using the Scrum methodology.

There are certain types of projects for which Agile is especially well-suited. (And not always software projects. IIL’s sales team and marketing department use Agile to manage their workload and have daily stand-ups for their regular meetings.)

Good options for going Agile include projects where:

  • Requirements are not well-understood or cannot be articulated
  • There is a high degree of complexity and uniqueness
  • There is a high degree of uncertainty
  • The greatest potential benefit is for complex work involving knowledge creation and collaboration, e.g., new product development

Scrum has certain tenets or guidelines that must be met for the project to even be considered Agile. It must:

  • Use time boxes sprints, typically of 2 – 4 week duration
  • Have short daily meetings (scrums)
  • Use a Scrum Master who facilitates rather than a project manager
  • Employ self-organizing teams who decide what to work on and how to do it
  • Be guided by a concept called servant leadership

The concept of servant leadership was developed by a management expert Robert K. Greenleaf. Having spent many years at AT&T, he felt that the authoritarian methods of managing in organizations were not meeting the needs of either management or workers.

Greenleaf discusses the “need for a better approach to leadership, one that puts serving others — including employees, customers, and community — as the number-one priority. Servant leadership emphasizes increased service to others, a holistic approach to work, promoting a sense of community, and the sharing of power in decision making.” (Italics mine.)

Greenleaf’s characteristics of the servant leader include listening, empathy, healing, awareness, persuasion, conceptualization, foresight, stewardship, commitment to the growth of people, building community.”1

And so those companies that are looking to ‘Go Agile’ are looking at what has come to be known as an Agile Transformation. (The scope of this article concerns itself largely with companies that are making a wholesale shift. Some companies are adopting Agile only in departments, not at the enterprise level.)

So what do we mean when we say Agile Transformation? This definition is as good as any:

“The Agile transformation definition is an act of transforming an organization’s form or nature gradually to one that is able to embrace and thrive in a flexible, collaborative, self-organizing, fast changing environment. The Agile Manifesto2 values and principles can be taught and exercised throughout any type of organization as it does not just apply to development teams.

The entire organization needs to understand the definition of an agile transformation and the value of it in order to benefit from the rewards of achieving true, healthy agility. The complete cultural and organizational mindset must change to one that embraces a culture of self-organization and collaboration.”3

Note that the definition of Agile Transformation does not say something like “project teams will learn to be self-organizing using Scrum Masters” or “there will be daily Scrums and time boxes called Sprints.” Sure, as noted above, those are true.

But note the last sentence of the definition. It speaks of a “complete cultural and organizational mindset change.” It should be obvious to anyone who has spent more than five minutes working for an organization that effecting change is one of the most difficult things you can do.

But like it or not, the hallmark of any Agile transformation is change. Unless companies that are considering doing transformations are open to the idea of change, the effort is doomed to failure and they might just as well stay with traditional project management techniques.

So it seems to me that the first prerequisite to any Agile Transformation within companies is for its leaders to be open to a new way of doing business.

In the next post, we’ll talk about the challenges inherent in an Agile transformation and how to deal with them.

  1. The Art And Science Of Servant Leader In Agile Scrum World. Sreedhar Khoganti. PM Times.
  2. The Agile Manifesto. A formal proclamation of four key values and 12 principles to guide an iterative and people-centric approach to software development. http://agilemanifesto.org/
  3. Agile Transformation: Understanding What it Means to be Agile. Cast software.com. http://www.castsoftware.com/research-labs/agile-transformation-what-is-it-definition

Jim Stewart PMP, CSM  has over twenty years’ experience in managing projects in IT, financial services and pharmaceutical. A PMP since 2001 and Certified Scrum Master since 2013, he frequently helps organizations increase their project maturity by incorporating best practices.


Do Too Many Cooks Spoil the Broth? In Scrum They Do!

By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM   |   Executive Vice President – Enterprise Solutions, IIL

Catch LeRoy’s presentation, “Agile: The One Bandwagon You May Want to Jump On!,” at the virtual Agile and Scrum conference on May 4th.

How many cooks do you need in a kitchen? The answer is you can have as many as you like as long as one is the boss. If you don’t have a boss, there’s chaos.

In a kitchen, there is one that is the boss, the Executive Chef (often called “Chef”), and he or she calls the shots. Everyone else (such as the Sous Chefs, Pastry Chef, Line Cooks and all the other kitchen staff) knows exactly how the system works and who’s in charge. In fact, this hierarchy works very well. Just look at any major restaurant or hotel kitchen and you’ll see exactly what I mean. (I’ve worked in restaurants large and small, independent, and as part of a large resort hotel, and I can tell you the Chef is indeed the boss!) Do you think for a second that Gordon Ramsay, Bobby Flay or Mario Batali is not the boss in their kitchens? Think again.

But in Scrum, too many “cooks,” or Scrum team members, really do spoil the “broth” (read: project). Why? Because in Scrum there is no “boss.”

The Scrum team is supposed to be a self-organizing body who figures things out on their own. There’s no Project Manager barking out orders, and the Scrum Master’s role is limited to ensuring the Scrum process is being followed and no one bothers the team.

According to The 2015 State of Scrum Report published by the Scrum Alliance, Scrum teams averaged seven members. The recommended size range is seven, plus or minus 2. Respondents in IT/software development reported an average team size of 6.6 members.

Team size evidently does have an impact of Scrum success. For example:

When there are 4-9 members on a team, Scrum is successful 77% of the time.

When there are 10 or more, Scrum success drops to 65%.

When there are 3 or fewer on a Scrum team, the success rate is only 50%.

So, not only does having more than the recommended number of members negatively impact success, so does having fewer than what’s recommended.

To be sure it’s difficult to self-organize when there are more than 10 team members. First, if everyone is ostensibly equal on a self-organizing team then everyone will have their say, resulting in a large number of opinions that have to be discussed and debated (sometimes endlessly). While the ultimate decision may be sound, oftentimes these kinds of discussions end in compromises. And while a compromise decision may soothe the egos of those involved, it may not be the best one for the project.

I also think that too many team members invoke an Animal Farm mentality, which you will recall if you read Orwell’s classic, can best be expressed and rephrased as:

“All Scrum team members are equal, but some are more equal than others.”

When the “more equal” members assert their influence, the others either fall in line, rebel, or become alienated. Hardly the end result anyone wants from a self-organizing team.

With three or fewer team members, I just don’t think there’s enough diversity of experience and ideas to reach the best decision. Three’s a crowd, as the old saying goes, and perhaps some issues arise when two members feel strongly about one course of action, and the holdout has to simply agree. If that happens enough, the third wheel, as it were, stops rendering his or her opinion.

So, we’re left with seven (plus or minus two) as the optimum team size in Scrum. But wait a minute, seven has always been touted as the optimum number of team members in project management, at least for the core team. So, what’s the big deal about Scrum and the number seven? Not much really, and that’s the point.

We can apply many of the best practices we’ve used all these years on traditional projects on our Scrum projects and, in fact, we should. After all, our only goal is to get the project done successfully. However way gets us there is the route we should take.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

Ready to improve your project success rates? IIL can help. Request a free consultation today.

[trx_infobox style=”regular” closeable=”no” icon=”inherit”]LeRoy Ward

About the Author

J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs. [/trx_infobox]