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.

The Benefits of Agile and Scrum

By John Carrington, AgilePM® Practitioner and Trainer, CSM, PRINCE2®, LSSBB 

Today, many organisations are experiencing the benefits of an Agile approach. But why all the fuss? What is Agile actually offering to the teams using it?

Let’s start with how and why Agile came about. In 2001, 17 Software Developers met in Snowbird, Utah. They recognized that the way being used to deliver software in projects was not working and software developers typically burnt out in their careers.

Teams would be working all hours to deliver on commitments given at the beginning of the project, which could no longer be met due to changes encountered along the way, like the customer changing their mind or things coming to light that hadn’t been planned for. The pressure of delivering using traditional methods meant that life as a software developer in the 80s and 90s simply could not be sustained. They needed to find a way that people could work and deliver software at a sustainable pace and keep going in their chosen careers, past the age of 40! The Agile Manifesto was born.

According to the 2016 VersionOne State of Agile™ Survey:

  • 87% of respondents reported being better able to manage changing priorities after implementing Agile.
  • 85% said they had increased team productivity.
  • 84% reported improved project visibility.

So let us not forget the reason Agile came about in the first place: to improve the daily lives of the team.

Agile helps teams adopt and continue habits which produce regular, consistent results at a sustainable pace of delivery.

One of the benefits of doing that, over the long term, is the longevity of team members’ careers.

Businesses are often attracted by the better, faster, cheaper benefits — and the teams delivering software benefit by becoming self-organized, high performing teams.

In traditional approaches to managing projects, the time when commitments are made and milestones are confirmed is at the beginning of the project in the planning phase. At that point, delivery dates are far enough away for everyone to be comfortable in their commitments.

The problem with this approach is that the beginning of the project is the time when the development team knows the least about the solutions the team is building, but it is also the time when plans are formed, dates are committed to, and deadlines are set. So they don’t know at this stage which problems may surface and what investigation work will need performing. In other words, they don’t know what they don’t know.

Scrum is one of a number of Agile frameworks that encourages ceremonies or events at various points in the sprint which is the time allocated to development work. These ceremonies enable the team to adopt working practices, like regularly reviewing the work with the customer, and retrospectively looking back at how the team performed in respect of the framework, which facilitate iterative and incremental development.

For example, the 15-minute Daily Scrum is a meeting for the team to update each other on progress, to ensure they are on target to meet their commitment of the Sprint Goal and to ensure there are no blockers.

You don’t need more than 15 minutes to do this, but new teams tend to overrun, which means people stop attending because they take too much time up and it becomes “Anti-Scrum.” This is a clear example of where “doing Scrum” because the guide says we need a daily meeting and “being Agile” are in direct contrast, as approaches.

Scrum can help teams to adopt Agile ways of working by providing enough rigour and discipline in the form of ceremonies/events, roles and responsibilities and artefacts for those teams to develop strong habits of working with Agile practices.

By sticking to the somewhat rigorous Scrum Framework, Agile teams learn good habits and develop a sustainable pace, working to their own commitments rather than to a schedule defined and managed by someone else.

Agilists are generalising specialists… Scrum teams are the “Special Forces” versions of software development teams because they are multi-skilled and cross-functional – small enough to have all of the skills they will need but not too large so they remain agile.

In fact, the special forces analogy continues because in Agile, we talk about “T-shaped” teams where team members have more than one skill, just like in special forces patrols. If one team member of a special forces patrol becomes unavailable, then the idea is that the whole team is not compromised.

In Agile teams, whilst the situation is less “life and death” (although it does not feel like it sometimes!) team members are cross functional so that we limit the amount of times we need to go outside of the team to get the work done. The other benefit is that we continuously learn and improve from each other and as a team.

It’s a Brave New (Agile) World

As we look at the job market over the coming months, we are likely to see more permanent and contract roles specifying Agile skills and there is certainly great opportunity to be realized with those with Agile and Scrum qualifications. That being said, many traditional roles are not, at first glance, part of the Agile vision, so Project Managers, Business Analysts and others are naturally wondering where they fit in.

Many larger organizations are experiencing transformations at the moment and businesses of all sizes are trying to figure out how Agile works at scale. We are seeing job postings for hybrid roles such as Scrum Master/Project Manager and Agile Business Analyst, Agile Delivery Manager, and Agile Coach/Scrum Master as the job market struggles to understand the roles and the differentiated responsibilities within an Agile environment.

Part of this momentum will be a natural restructuring of hierarchy, a necessary re-organizing of roles (both in title and responsibility) and recruitment campaigns that bridge the gap between the hybrid approaches of the early Agile adoptions and take the job market through to the required level of understanding of permanent and contract roles.

Until both organisations and recruitment agencies truly understand what it means to be Agile, we are likely to see more of these “hybrid” roles until organisations catch up with their own transformations. The job market is likely to see lots of changes in the near future whilst the changes that large organisations are making by transforming to Agile approaches filter through to their talent acquisition efforts.

Take this opportunity to ensure you have the key Agile skills that these businesses are going to need to give yourself the optimal chance of getting that next position!

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 Agile skills? IIL can help. Browse our Agile and Scrum courses. If you have a team to train, request a free consultation.

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

About the Author

John Carrington (AgilePM® Practitioner and Trainer, CSM, PRINCE2®, LSSBB) is an experienced consultant, well versed in all aspects of the Agile project lifecycle and program management, with over 20 years of experience in corporate businesses. John has been involved global software implementations, business transformations, and change projects. John is an excellent communicator with strong influencing skills and a passion to deliver the highest quality outcomes, on time and within budget.[/trx_infobox]

Agile Retrospectives: A Tool for Team Learning

By Luis Gonçalves    |   Co-founder of Evolution4All, Founder of ScrumMaster Growth

An Agile retrospective is an effective tool used at the end of every iteration to analyze the team’s performance during the project.

Team members gather to review what worked well and what did not so they can improve their performance on future projects.

For companies that are unfamiliar with retrospectives, there are tools and exercises they can use to make the sessions run more smoothly:

  • The Sailboat exercise uses illustrations to identify the strengths and weaknesses. In the diagram, the team is the boat while the “worked well” parts are the wind and the “did not work” areas are anchors. Once the team has established what worked and what did not, they can discuss improvements they can make for the next project.
  • The Starfish retrospective does not focus on what worked versus what did not. Instead, it uses five categories to address what the team should keep doing, start doing, stop doing, do more of and do less of. The diagram helps the team reflect on varying degrees of success or failure with each part of the project.
  • The Happiness retrospective analyzes how the different areas of the project made each team member feel during the project. Each member rates their feelings towards the team, process, and technology as sad, happy, or somewhere in between. Once everyone has inputted their feelings, the group can discuss each area to find improvements for next project.

The Learning Component

Agile retrospectives are a simple yet highly effective way to improve team performance for software projects. Many industry professionals often provide insight or advice on running a great session to make their team work better and improve performance. However, one area of the retrospective that tends to be overlooked is the learning component.

Most retrospective sessions do not create opportunities for the team to learn from their experience.  For some, it has become merely a mechanical process and part of the project closing. While the session might generate ideas on ways to improve, it often does not encourage actual learning.

Retrospective Scrums are so much more than just an end-of-project meeting. They are the cornerstone for all inspection and adaptation cycles. While teams should not limit their learning just to the retrospective, the truth is this is where most of the learning occurs. It is the most common place for data mining, or collecting information about the sprint; what happened and the challenges faced.

The learning that can be done during the session becomes secondary to the ideas that are generated by the team to avoid default thinking patterns in future projects. When the focus on agile retrospectives is on the learning, they will always be successful. 

Agile Retrospectives with a Focus on Learning

To illustrate this, a Scrum Master recently ran an Agile Retrospective for her team with the focus being on learning. Like most retrospectives, the team looked at the project, provided insight on what worked or did not work, generated ideas to improve performance and then went into the sprint to try the ideas.

Rather than focusing on the outcome of the idea, the team paid attention to the learning that occurred. They ended the process feeling successful because not only did they learn something, but they were able to objectively discuss topics and solutions for improvement.

By creating an environment where the focus is on the learning aspect and not the outcome, the facilitator was able to run a successful session.

In the traditional method, when the focus is more on the outcome, the team may often feel like they failed when they discuss their actions and find their implementations were ineffective because they did not learn anything from the process.

Another example occurred recently when a team tried to work with daily sprints. They met in the morning with the product owner to discuss the topic that they wanted to implement. Using MOB Programming, the owner and team were able to deliver their story that same evening.

Before their day ended, the team and product owner met for an agile retrospective. While not an easy meeting, the team members were highly professional and mature.

One issue that was listed was the amount of time lost during the day. There were several possible reasons for their time management issues but the team felt that the biggest waster was the time that members spent on planning, grooming, and meeting for sprints. Rather than hosting daily sprints, the team decided that it would be more beneficial to only have weekly sprints. They came to this conclusion using this model:

We hypothesize by <implementing this change>
We will <solve this problem>
Which will have <these benefits>
As measured by <this measurement>

Their sentences read:

We hypothesize by <increasing the length of our sprint to 1 week>
We will <not spend so much time in the meeting>
Which will have <an increase in productivity>
As measured <the number of stories delivered in the same amount of time as before, and by our gut feeling>

During the Sprint meeting one week later, the Scrum Master created a learning wall so that the team could provide input on what they felt they learned during the week. In this method, the staff could measure and clearly see if their changes were effective. The team felt happy when they were successful but frustrated and sad when their changes did not work.

There were 2 possible options they could have learned:

  1. Increasing sprint meetings to one per week, staff would spend less time in daily meetings which would improve productivity.
  2. Increasing sprints to once per week would have no effect because there were other external factors interfering with the level of productivity.

Either way, the team felt that they had succeeded in their learning objective.

By focusing their session on the learning aspect, the team assessed and discussed what they learned during the week. They could then use their knowledge to initiate improvements and adaptations in their behavior for the next project. In this session, the team felt successful because they learned from their experience.

Learning is a vital part of the Agile Retrospective that is often overlooked. By focusing more energy on the learning part rather than the outcomes, the team will feel more successful as they adapt their behavior and implement changes to improve their performance for future projects. For more information or ideas, visit this List or read Tools for Distributed Agile Retrospectives.

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.

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

About the Author

Luis Gonçalves is the co-founder of Evolution4All and founder of ScrumMaster Growth.

He is co-author of Getting Value Out Of Agile Retrospectives which has more than 25,000 copies distributed and discusses the importance of Agile Retrospective.[/trx_infobox]



Pilots Need Flight Planning, Scrum Teams Need Sprint Planning

By Tom Friend, FLEX Coach, CSP, ACP, AHF, PSM, CSM | Business Agility Consultant, IIL

Catch Tom’s presentation, “Collective Intelligence: Leveraging the ‘Swarm’ on your Teams,” at the virtual Agile and Scrum conference on May 4th.

Many years before my career in software development, I was a pilot in the U.S. Air Force, flying aircraft all over the world. As fantastic as this sounds, it did require planning and preparation to ensure that each flight was properly set up for success.

Before every flight, the crew would sit down with a set of data and mission goals, and plan the flight to the best of their ability and knowledge. The measurable successes of each flight mission were directly tied to the quality of the flight crew’s preparation. For every flight, equipment and cargo loads, fuel, crew, weather, and many other variables needed to be taken into consideration during flight planning.

Just as flight planning ensures the success of a military mission, Sprint Planning ensures that a Scrum Team will start a sprint off on the path to success.

For example, all of the work to be performed in a given Sprint can be planned ahead of time. This plan, therefore, sets measurable, actionable goals for the team to strive for. This plan, which is created by the collaborative work of the entire Scrum Team, maps out the plan to the destination. In Scrum, just like in aviation, the destination is the overarching goal. Whether it’s a flight crew or a Scrum Team, a collective plan will set you on the successful path to your end goal.

The Scrum Guide™ mentions some questions which Sprint Planning is designed to address: What can be done in the Sprint? How will the work get done to meet the Sprint Goal? What Product Backlog Items in the Product Backlog are priority and will be considered for the Sprint? In Scrum, the Product Owner stacks the top actionable product backlog items (PBIs) by value at the top of the Product Backlog to help answer these questions.

The destination is usually found in the PBIs selected by the Product Owner. In order to be selected and brought to Sprint planning, the PBIs need to be prepared and refined to a point that they are sized and understood by the team. The number of PBIs is based on capacity of the team over the next sprint.

Once the Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is the destination met through the implementation of the selected PBIs. It provides direction to the Team on why it is building the Product increment, the output of the sprint.

Once the PBIs and Sprint goal are selected, the Team collaborates how to get to a ‘Done’ product increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog. This is the flight plan for the sprint.  Each PBI constitutes a segment in the flight plan of working product increment that gets the team closer to the destination sprint goal.

During the course of Sprint planning, the Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend in order to provide technical or domain advice.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

The similarities between Sprint Planning and flight planning are numerous. With my experience as both an Air Force pilot and as a Scrum Master over the years, I have learned how to build simple checklists which provide a path to the goal, consistency between projects, and better outcomes for individuals, teams, and the Sprint process.

Below is an outline of a Sprint planning checklist, which you may find useful in planning out your sprints. Consider it a starting point to build your own if you have interest. Best of luck!

Sprint Planning Checklist

  1. Scrum Master Open the Sprint iteration meeting
    1.  Welcome
    2. Review purpose
    3. Agenda
    4. Organizing tools
    5. Parking Lot
  2. Product Owner Product Vision and Roadmap; Remind the team of the larger picture
  3. Agile Team Status update group huddle
    1. Development status, state of our architecture, results of previous iterations
    2. Discuss any new information that may impact the plan
  4. Scrum Master Share velocity
  5. Determine the time box and total working days (subtract days for holidays or other whole-team impacting events)
  6. Scrum Master Check in on any currently known issues, concerns, impediments, and record as appropriate to revisit at future meetings
  7. Team Review and update definition of Done
  8. Product Owner Present the Stories from the Backlog
  9. Delivery Team Determine tasks, signs up for work, and estimates tasks they own
    1. Product Owner Answer clarifying questions and elaborates acceptance criteria as appropriate
    2. Scrum Master Facilitate collaboration Key focus
      1. Tasks
      2. Estimates
      3. Owners
  1. Scrum Master Check for new issues after the clarifying questions and records them for appropriate action
  2. Scrum Master Check in on any dependencies or assumptions determined during planning and record as appropriate
  3. Team Commitment to the Product Owner for the Tasks they have accepted
  4. Sprint Name and goal is finalized, can be a collaborative effort
  5. Scrum Master Close the meeting
    1. Communication / Story updates / WIKI / Emails as needed to Capture and communicate lessons learned
    2. Parking Lot – all items should either be determined resolved or turned into Action Items
    3. Action items assigned and agreed on
    4. Process Action Plan – distribute action items to owners
    5. Retrospective for the Meeting Iterative feedback for the meeting itself makes them better for the team and empowers them to take ownership
    6. End on a high note

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.

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

About the Author

Tom Friend is an Agile Coach and Trainer currently at Duke Energy in Charlotte, NC.  Tom is a retired military pilot, small unit leader, and squadron commander. He is an accomplished Agile consultant, trainer, and coach with 23 years’ experience leading software development teams in various industries to include federal, banking, cable, telecommunications, and energy. He has 12 years of hands on Agile / XP / Scrum software development experience.  He is a distinguished graduate from Air War College and has a BS in Aeronautics. [/trx_infobox]

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]