Agile for Traditional Projects

By Susan Parente | Risk Management Guru – Agile Generalist – Instructor and Consultant, IIL

“Can Agile practices be incorporated with traditional project management?” This is a very common question today, and the answer is yes!

In this blog, I’ll cover two great Agile practices that teams have found to be valuable to incorporate on traditional projects, and which may help your team make the shift from traditional to Agile project management: A Daily Stand-up meeting and a Kanban board.

The daily stand-up meeting

The daily stand-up is used in Scrum, one of the most popular frameworks for implementing Agile. In this meeting, the project team members answer the following three questions:

  1. “What have I completed since yesterday that supports the iteration goal?”
  2. “What do I plan to complete today to support the iteration goal?”
  3. And lastly, “What are the barriers or impediments that are getting in my way in completing the work I have to do to support the iteration goal?”

This truly is a stand-up meeting, where all participants are standing. The meeting is time-boxed which means that it must end at the allocated time, generally 15 minutes. This forces people to prioritize what they talk about and to make sure they are efficient with the use of meeting time. (If you decide to have a daily stand-up meeting and let it run over 15 minutes, you’re not actually doing the practice of a daily stand-up, as it is a time-boxed event).

What you will likely find is in the first few daily stand-up meetings, not everyone will have an opportunity to speak; however, after a few meetings, people will figure out how to be succinct so that everyone has an opportunity to speak. It’s important for the Project Manager (PM), team lead, or facilitator in a traditional project to allow the team to work through this, as it is a part of the process of team development.

It is also important for the PM to take the lead and provide meeting support, but only to remind team members to focus on the three questions they need to answer (as noted above) and remind them if they’re getting off-topic with doing so.

Keep in mind that the purpose of the daily stand-up meeting is for the team to provide status to all team members, not to report to the project manager or the customer. Of course, it is valuable for the project manager to attend this meeting as the team facilitator; however, their role is more focused on listening and enforcing process than leading the team.

The Kanban board

A project Kanban board, or task board, is used by agile team members to work through project tasks. The project sponsor need not know that you are using an Agile method, and neither do your team members. In some organizations, it can be worrisome to customers and team members to use ‘Agile’ if they don’t know much about it. It can be an intimidating change. Using the Kanban board has been very effective for teams that I have coached or led because the teams had multiple tasks that changed every week. It is an easier way to manage these tasks and to make sure they get completed in a prioritized order while being able to track who is working on which tasks.

As designed, a Kanban board minimizes the project work-in-process and allows the team to complete all of the project work, not knowing necessarily how long each task would take. As each task is completed, the team member who completed it updates the board and assigns themselves to the next prioritized task.

Other Agile practices that teams have found to be valuable to incorporate for traditional projects include:

  • Information radiators
  • War rooms (collocation of the team)
  • Team retrospectives
  • Burndown charts
  • Relative sizing/estimating
  • And others

What is nice about incorporating Agile practices while doing traditional project management is that you may receive some benefit from using these practices while your organization may not be ready for an Agile project management approach. As a PM, you probably have some authority as to how your development team works and are able to use some of these tools even without agreement from senior management, or from your customer.

By incorporating Agile practices into traditional project management, you can reap the benefits of these practices and also, in the meantime, educate your team and your customer on Agile practices so they are more comfortable with using them. 

Related Courses from IIL:

Courses can be tailored to meet your organization’s needs. Request a free consultation


Susan Parente (PMP, PMI-RMP, PMI-ACP, PSM I, CSM, CSPO, CISSP, CRISC, RESILIA, ITIL, MS Eng. Mgmt.) is an instructor and consultant at IIL, an Adjunct Professor at the University of Virginia, Post University (CT), and Montclair State University (NJ). She is an author, mentor and teacher focused on risk management, traditional and Agile project management. Her experience is augmented by her Masters in Engineering Management with a focus in Marketing of Technology, from George Washington University (DC), along with a number of professional certifications. Ms. Parente has 18+ years’ experience leading software and business development projects in the private and public sectors, including a decade of experience implementing IT projects for the DoD.

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.

Dr. Harold Kerzner Q&A: How Changes in Project Management Are Supporting Agile and Scrum

This past November as part of IIL’s IPM Day online conference, Dr. Harold Kerzner delivered a keynote on “How Changes in Project Management Are Supporting Agile and Scrum. 

The keynote discussed how, over the years, project management has undergone continuous improvement efforts by extracting best practices from other management practices such as Six Sigma. Now, the reverse is happening: other techniques are extracting some of the best practices from project management for their own continuous improvement efforts. This appears to be true for continuous improvements in Agile and Scrum activities. The landscape in project management is continuously changing for the better!

Following Dr. Kerzner’s keynote, we received hundreds of questions for his live Q&A portion (so many that they couldn’t be addressed in the allotted 15 minutes!) and we are excited to share highlights here, organized in the following categories:

  • Agile and Scrum 
  • Project Managers of the Future 
  • Reporting and Metrics 
  • Portfolio Management
  • Public Sector
  • Challenges
  • Cultural Differences 
  • Project Failure and Success 
  • Benefit Harvesting
  • Miscellaneous

Content has been edited and condensed for clarity.


Can the traditional PM role still exist in an Agile world?

Yes, because some projects can be handled better using traditional project management.

How do we plan effective scheduling using framework, v. traditional and agile?

In traditional project management, everything is linear and we try to lay out a complete schedule at the initiation of the project. With flexible frameworks such as Agile and Scrum, we work with smaller units of time that allow us more flexibility in the adjustment of scope to fit a schedule. In Agile, we tend to fix time and cost, and allow scope to change as needed. With traditional project management, scope is fixed and we tend to allow cost and schedule to change as needed.

How can Scrum or Kanban (agile methodologies in general) methods fit the existing PMI® framework (i.e. PMBOK® Guide)?

My personal belief is that they do not fit, at least well, if you believe that all processes and activities identified in the PMBOK® Guide must appear in each methodology. The future will be flexible approaches that are customized to each user or client. PMs may discover that only 20% of the PMBOK® Guide is needed, as an example.

Is there a way to transition from waterfall to Agile or is it “all in”? Do we have to go to an agile framework and shed all waterfall oriented controls?

My experience has been that you will have a great deal of difficulty going straight to Agile without first adopting some form of project management. Then, it is up to the company, based upon their types of projects, to decide how many of the tools and practices of traditional project management should be carried over. There are some practices that are common to both.

Agile always offers stakeholders the upper hand in modifying the scope after each sprint. As a project manager, how can we limit the change so that we don’t want the team to modify the code after every demo?

I understand your concern, but what are the alternatives especially if you might want repeat business from this client? My personal feeling is that I can live with frequent scope modification as opposed to continuously explaining cost overruns and schedule slippages.

What is the best approach to managing Domain name projects? Would it be better to follow the waterfall traditional project management approach or the Agile/Scrum method?

This is a tough question to answer because it depends on the type of project, size, nature of the project, how many people, whether it will involve change management, etc…

Does the Agile & Scrum framework reduce/omit the requirement of a traditional PM in the IT Industry?

I have to be non-committal, but I believe that each company must make their own decision on this. Regardless of the industry, there are always going be projects that work well using traditional project management practices.

Thank you for explaining the difference between Benefits and Values. This is expected by the executives. What are your recommendations for being certified in Agile and Scrum and is it value added for project managers or the leadership managing project managers as well? If so, which designation do you recommend? Thanks.

Being an educator for five decades, I am a believer in life-long learning. Having said that, I recommend obtaining the additional certifications as long as they will benefit your career goals.


Should a company have a methodology or is it better to allow project managers to manage as they want?

Great question! I believe in the future that methodologies will be eliminated and replaced with tools such as forms, guidelines, templates and checklists. I have one client that has 50++ tools. At the beginning of a project, the PM and some team members select the tools needed and then create a customized methodology or flexible methodology or framework that best fits the client’s needs.

I just got my PMP®. Given the future you are envisioning what do you recommend I begin with?

What I normally tell my students is to work for a small company where, as a project manager, you manage everything and really get to understand project management. Working in a large company, you might manage only a small part of a project and never see the big picture of project management. Start small and then climb the ladder.

What can older project managers do to extend their careers? Are there other fields (e.g. training) that can be pursued?

If you are set in your ways and refuse to be removed from your comfort zone, you have a problem. If you are willing to change, then education is the start.

What are the top 3 skills that define the project manager of the future? How should new professionals seek to gain these skills. Thanks!

For more than 40 years of teaching project management, I have emphasized that the single most important skill is the ability of the PM to manage pressure and stress, not only what is placed upon them, but also what is placed upon the team. As for 2nd and 3rd place, I would pick team building skills and decision-making skills.

How will AI/machine learning affect the role of a project manager and skill sets needed?

I wrote a blog last year on AI and Project Management.

How do you see Project Management and Organizational Change Management working together in the future to achieve benefits and value in projects?

I see project managers staying on board the project and becoming the change agent. They will then be responsible for implementing the changes needed to extract the benefits.


Tools such as EVM (Earned Value Management) provide a metric for schedule and budget. What type of metrics are you seeing as proven practices for measuring benefits and value?

There is no single metric for either benefits or value. Value metrics are made up of attributes or components. For example, I saw an IT company use a value metric that had 5 components: time, cost, functionality, safety protocols, and quality of design. Each component had a weighting factor assigned to it and the totals were rolled up and reported in one dashboard metric.

Executives are interested in KPIs (Key Performance Indicators) which can be loaded. What is your advice in linking dashboards, metrics and KPIs?

I agree that a linkage is necessary. However, I also believe that you should give executives dashboards that provide them with the information they need rather than the information they want. If you have a metric library that has 50 metrics, I would not create dashboards to display all 50 metrics. I would instead ask the executives, “What decisions do you expect to make, and what metrics do you need to help you make those decisions?” Providing executives with too much information is an invitation for executive micromanagement.

Dr. Kerzner said that teams are now allowed to use multiple tools. How then do you balance this with the need to maintain standards so you can successfully create consolidated dashboards?

There will be standards for each tool used. The standards for dashboards involve space, colors, images, aesthetics, etc… but not specifically the information displayed, specifically the metrics. This will be customized for each client.

My understanding is that a dashboard is operational in nature to track the progress of project throughout its lifecycle while a project scorecard will address the need to link up the project objectives, benefits and values to the strategic objectives of the organization?

You are correct. This is how I teach it as well.


Lots of times decisions on portfolio made on projects, e.g. with NPV which is purely financial measures and when one looks at more attributes (value creation) upfront, it is likely possible that the optimized portfolio may spit out potentially different set of projects to execute on. This is optimization exercise and companies struggle. Your guidance to us on how to overcome this situation?

Great question. There are financial values and nonfinancial values that need to be considered. Unfortunately, as I see it, perhaps the weakest part of project selection is in the criteria we use which appears to still be financial. As part of business case development, we are now stressing that organizations learn how to prepare a benefits realization plan as part of the business case. Once this happens, we should have a much clearer picture of the realistic benefits and value possible. But how long this will take for companies to learn, I do not know.

We are a Marketing Services Provider whose clients include many large retailers and financial institutions. Of course, we are always working with limited resources. What is your take on portfolio management for a consulting company like ours?

Portfolio management begins with identification of your largest or most critical clients and what projects need to be undertaken to maintain their business. Using techniques like Kaplan and Norton’s Balance Scorecard is a great start at doing this.


I work for the Public sector in Cape Verde, a small African County in the west African coast. Considering the projects complexity in the public sector, involving many stakeholders, changing scope and short cycles, what would be your thoughts on a better approach to use Project Management methodologies in this area and how agile practices can help? Thank you Dr. Kerzner.

Methodologies are not necessarily the solution to your problems. With traditional project management, sad to say, we often try to stay as far away as possible from stakeholders and clients during project execution for fear of scope changes they may request and stakeholder meddling. With techniques such as Agile, we welcome client/stakeholder involvement and expect these people to have at least a cursory understanding of project management and Agile practices. In other words, it appears that in Agile and Scrum clients and stakeholders appear to have a much better understanding of their roles and responsibilities on the project. This should make life better for the PMs.

What is your experience or best practice in managing projects in the public sector in relation to Benefits and Value management?

Public sector projects do not have profit motives, and this changes the picture a bit. But there are other challenges in the public sector that impact benefits and value. I recommend you get a book entitled Public Sector Project Management by Wirick. It is a John Wiley publication and a good book.

How to benchmark business in government monopoly?

David Wirick wrote a book entitled Public Sector Project Management. The book is published by John Wiley. It shows the differences between public and private sectors, and you can easily then see the benchmarking issues.


What to do when we start a project in a company that does not have basic ideas about projects?

This is an invitation for disaster. My recommendation is education, and this includes senior management.

How to “sell” to upper management the need for training in PM for the executives?

My experience is that people external to the organization, such as consultants, have an easier time convincing them of the need for training. Executives may fear that internal people promoting training are trying in some way to “feather their own bed” so to speak.

What to do when Executive-Level management doesn’t want to attend education rollout strategies?

You need to find at least one executive champion to help you convince other executives of the importance of this. If all of the executives are in agreement that education at their level is not needed, I would update my resume.

What if your PMO refuses to adjust its methodology for business needs and only looks at itself first? How does an individual PM drive that change?

You may need to have a champion at the executive levels to assist you. All you need to find is just one executive to champion your cause. Otherwise, you will have difficulty.

What is the biggest challenge in project management?

The biggest challenge is overcoming the belief that companies have that one-size-fits-all with regard to a PM methodology. In the future, methodologies must be customized for each client. PMs need flexibility.

Do you have any recommendations for managing (and motivating) IT employees (technology or app dev folks) that are resistant to the change that digital transformation requires?

The architects of the corporate culture are the people that reside on the top floor of the building. If workers are afraid or being removed from their comfort zone, then there is a point where senior management must step in and “force” the changes to take place.

If the Sponsor refuses to attend or be a part of the project, should the PM propose for project cancellation rather than making decisions on behalf of the Sponsor, when he/she is not authorized?

I have lived through this scenario in a multitude of companies. What I tell PMs to do, is to make the decision yourself, and then e-mail the sponsor with your decision asking if they agree or disagree with your decision.  This basically forces them to act because there is now a paper trail.


Dr. Kerzner – thanks for the presentation. When you speak to the politics/religion/culture gaps – how did your daughter bridge the gaps between cultures? What other suggestions do you have to overcome these in short order if thrown into a global program?

My daughter learned from her global team members. They provided her with some educational insights. She wasn’t embarrassed to ask her global team members for advice and recommendations.

I’ve worked with multi-cultural teams and hit roadblocks due to how decisions are made. How do you suggest consensus be achieved across teams?

Believing that consensus can be achieved is probably wishful thinking. At the onset of a project, you must get the team to understand that you do not expect consensus on every challenge and that the team must go along with the vote or any other process you use. People must be prepared early on for disagreements and how decisions will be made.

How to measure whether a Project Manager has enquired sufficient Politics, Religion and Cultural skills?

At present, I do not see any measurements being made. However, in the future I expect to see metrics on projects measuring political exposure, religious exposure and cultural sensitivity. These metrics would be reported on dashboards along with other metrics such as time, cost and scope.

How to prioritize when there is a clash between benefits vs. politics and culture?

This is why we have project sponsors and governance committees to assist in the prioritization of constraints and sometimes alternatives.


You mentioned that you must have a failure mark for a project…what if failure is not an option?

If failure is not an option, then you must carefully look at the tradeoffs and alternatives. This is a common occurrence on projects that must abide by regulations such as projects for OSHA, EPA, Health and Safety, etc…

RE: Project Health Checks – What is an example of establishing a Failure Criteria, versus establishing a Success Criteria?

You are creating a new product for marketing and the sales force. The exit criteria might be to stop working on the project when the expected sales price reaches a certain value. There are degrees of success based upon the profits expected. The success criteria, which could be a mere image of the exit criteria, could be to develop a product than can sell for less than a certain dollar value.

Often, we set up the success factors for the finished project. By going agile it will be so very important to break down those success factors into smaller ones and going into a stepwise approach. How shall I connect these to stakeholders?

Every project can have a different definition of success. When working with stakeholders, step #1 is having an agreed upon definition of success. Step #2 is then working with the stakeholders to decide upon the metrics and critical success factors you will use to confirm throughout the project that success is achievable. This should be done at the beginning of the project and reported on dashboards periodically.


What’s the benefit of doing benefit harvesting? What’s the value to the company?

The results of a project are deliverables and outcomes. These, by themselves, have very limited value unless someone can harvest the benefits expected from them.

Dr. Kerzner, can you recommend any resources (authors, journals, etc.) to help educate PMs on the topic of Benefit Harvesting?

There are some books on Change Management that include benefits harvesting. I wrote a white paper for IIL on Benefits Realization and Value Management.

If benefit harvesting is part of project management then don’t you think it is taking a big piece of program management?

Yes, it is a massive piece of project management but many people haven’t realized it as yet.

Who exactly is harvesting benefits from the project in business environment? If the successful project outcome is then transferred to operations, it seems that operations colleagues are those that are harvesting benefits from the successful project.

Sales and marketing may be responsible for harvesting the benefits of new products created through projects. IT may be responsible for harvesting the benefits of new software to be used. Other projects that lead to change management initiatives may be transferred to specific groups in operations.

Hi Harold – great Keynote! Within organizations that commit to having project teams involved in benefit harvesting and value extraction, is there evidence that the number of projects delivered within that organization is reduced? If so, does the value delivered with this expanded focus outweigh what could be achieved by delivering more projects?

When companies learn how to create metrics to measure and report benefits and value, it will become easier to establish a portfolio of projects that maximizes the expected benefits and value to the firm. In this regard, the high value or high benefits projects will be prioritized. We will also then eliminate the “pet” projects of senior management that may or may not produce benefits. I would expect the number or projects to be reduced.

Dr. Kerzner, shouldn’t benefit harvesting be done before the project even begins, to identify the benefits and value the project will provide? Or, is benefit harvesting different from the process of Cost/Benefit Analysis, finding the ROI etc.? Thank you!

Benefits harvesting cannot be done until there are outcomes and deliverables; i.e. completed projects. Also, cost/benefit analysis is based upon a “guess” as to what the benefits will be, and usually the benefits are explained qualitatively, not quantitatively. The true C/B ratio and ROI cannot be determined accurately until after benefits harvesting.

Do we need to wait till we complete the project and realise the deliverable, then work on harvesting the benefits and then sustaining the values? Is it a linear relationship between those three elements of deliverables, benefits and values?

Very good question. I explained it as though it is linear. Actually, it is nonlinear if we work on projects where we can establish metrics for benefits and value and perform the measurements throughout the project. Unfortunately, most companies are not that mature yet and tend to perform benefits realization and value management after the project delivers an outcome. Agile and Scrum projects are an exception.

Great presentation, thank you. What do you see as the differences, if any, between change management and benefits harvesting?

Change management includes all of the activities that may have to be done at project completion to harvest the benefits.


Great information. The only one I wasn’t too clear on is the Impact of Mergers & Acquisitions on Project Management. Can you briefly summarize that one?

Whenever there are M&A activities, there will be a landlord and a tenant. Believing that there will be equal partners is not going to happen. The problem is when the landlord dictates to the tenant how project management should work even though the tenant has a superior approach to project management. Developing an agreed-upon approach that both parties will accept will take time.

If it takes years to realize benefits, how can executives decide if the exit criteria are applicable?

The exit criteria identify when to pull the plug on the project. The exit criteria on the project must be monitored throughout the life of the project, not only to see if it is still valid, but to see if it needs to be updated or changed.

I don’t think it depends on culture. I think it’s understanding the way people solve problems. Bridging adaptive and innovative problem-solving styles trumps culture.

I agree with you. There are books being written on a topic called “Design Thinking” which relates to innovation project management. Design thinking requires a total acceptance by the culture of a firm and may cause a new culture to be created that focuses on collaboration and decision-making. I am researching this topic now.

Have a question for Dr. Kerzner? Leave your comment below.

Harold Kerzner (M.S., Ph.D., Engineering, and M.B.A) is IIL’s Senior Executive Director for Project Management. He is a globally recognized expert on project management and strategic planning, and the author of many best-selling textbooks including Project Management: A Systems Approach to Planning, Scheduling, and Controlling and Project Management 2.0. Dr. Kerzner has previously taught project management and business administration at Baldwin-Wallace University, engineering at the University of Illinois and business administration at Utah State University. He obtained his industrial experience at Thiokol Corporation where he held both program management and project engineering responsibilities on a variety of NASA, Air Force, Army, Navy and internal R&D programs.

PMI, PMBOK, and PMP are marks of the Project Management Institute, Inc.

Reflection and Takeaways on Agility from the SMC-IT 2018 Space Mission Design conference

By Tom Friend – Agile Consultant / LtCol USAF (Ret)

The 6th International Conference on Space Mission Challenges for Information Technology, held in Alcala de Henares, Spain, brought together scientists, engineers, and researchers from NASA, the European Space Agency, universities and industry.

Case studies on how agile methodologies have been applied to mission planning and how scrum has been used in spacecraft construction were discussed, as well as topics such as developing and delivering software, reliability and reuse of software, onboard processing, and communication.

Representing Scrum, Inc. as a keynote speaker, I opened the conference with “Scrum to the Stars” which looked back into aviation history and to the future of innovation in aerospace, and how Scrum methodologies have been, and will continue to be effective tools.

Iterative discovery has been at the core of aviation exploration since the dawn of flight. Whether it was the first aeronauts in balloons, or the Wright brothers at Kitty Hawk, explorers of flight used processes that built on incremental failures and successes. Aerospace design processes were modified as improvements to flight technology were discovered, and the knowledge base expanded. Empiricism and Incremental improvement evolved as a standard path to improvement.  This standard path emerges as patterns.  For example Interfaces in small satellites are deliberately over-designed to reduce need for disruptive renegotiation.  The pattern of S\simple pre-negotiated physical bus structure for data and power increase design versatility, and loose production coupling.  One of the most significant scructural patterns is that of standard adapters allows objects with incompatible interfaces to work together by wrapping its own interface around that of an already existing interface.  These are just some of the patterns that when combined defines the evolving path to improvement.

In essence, Scrum was there at the start of aerospace exploration. Over the years, as systems have increased in size and complexity, common sense has been lost, and projects hit overruns in both time and money spent. By utilizing an Agile framework, you can break down these complex systems into smaller pieces that can then be integrated into the whole design. The step-by-step, incremental approach can be an effective time and cost management tool.

Today the trend in space exploration is making small satellites. Frequently, these small satellites are part of a larger mission.  In doing this, risk is reduced by breaking a complex mission into parts and delivering it in smaller submission components. Think of it as component architecture with your software systems, same pattern. The end deliverable: small satellites that are tailored to a particular mission.

This approach complements Agile planning where focus is on delivering small increments of value and dedicated Scrum teams to build and deliver the satellites.   The success and low cost of small satellites with focused space missions is now mainstream with a standard type of microsatellite called, “CubeSat” that follows set size and weight requirements. This standard is a simple 6-page document keeping with the Agile tradition of minimum viable documentation.

CubeSats by necessity have evolved to leverage many Scrum in Hardware Patterns to speed development and reduce costs. This conformance to patterns has created a whole cottage industry of commercial off the shelf (COTS) suppliers.  They provide hardware and software systems and components that can be used together like LEGOs because they have standard power, size, bussing, and know stable interfaces that allow them to be configured quickly and with low expense.

One of my favorite ways to demonstrate how effective Scrum can be in a hardware setting is a class I give using the CubeSat format. This class is generally offered in a 6-hour format, and is very hands on. In this course, we build a 3D paper CubeSat with a specific mission. All the steps from mission design, roadmap, and components are broken down into a backlog and worked by a scrum team to deliver a fully functional model.  We then walk through the launch and operation of the CubeSat, discussing what each component is doing as it circles the table in the middle of the room that represents Earth.

This simple class exercise using scrum to build components and the visualization of talking through a mission shows how prototyping lets you see problems with design early and builds shared understanding on the team.  These are lessons that you can take back to your own teams to make them even better.

About the Author

Tom Friend 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.

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.
  3. Agile Transformation: Understanding What it Means to be Agile. Cast

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.

Why Your Agile Implementation Failed

Join IIL’s virtual conference on Thursday, May 4th for more insights on Agile, Scrum, and Kanban.

By Roy Schilling

At one point in my career, I was a manager in a large financial organization.  Being tired of missed deadlines and disappointed customers, I wanted a better way to deliver – faster, better, cheaper.  I had been reading about Agile and how it had helped organizations with exactly what I was looking to solve.

My Agile journey started pretty much like everyone else – hours on the internet and a 2-day class.  At the end of the class, I was the proud owner of a certificate and had a high-level of confidence that I could implement this Agile thing in my organization.  I quickly looked for a project, formed my team and started executing – now we’re Agile!  The result, however, was something quite different from what I expected.  The team never really formed, we had personalities that didn’t work well together, people were getting yanked out of the team for “special assignments”, and a whole host of other anti-patterns which caused us to ultimately fail – and in a big way.

The reality was that I had no idea what I was doing.  I had no experience and no one to help set up the guardrails needed to keep the team (and me) headed in the right direction.  Sadly, this is a very common situation.  Lots of energy, desire, motivation, but no experience to make it work.  Training was a great start, but not enough to guarantee success.


I could have walked away with my failure, and declared Agile to be the problem.  “It just can’t work in my organization” is something I’ve heard far too often as an excuse for simple mistakes.  Instead, I was fortunate enough to have met someone with significant experience in the industry, who offered his help to mentor and coach me.  After spending a short time together, we got my team re-aligned, analyzed skill sets and personalities, setup team working agreements and started working with leadership to help them understand their part in all this.  In short, he got me back on track.


One of the most important things he helped me with was in becoming a better leader.  He helped me understand that I was spending too much time managing down, worrying about “resource allocation” and dealing with the minutia of daily activities.  I had hired good people; it was time to get out of their way, let them do their jobs and give them the support they needed to accomplish the goals they set out to achieve.  This was a major change from my management style, and one of the most difficult and important lessons I had ever learned as a manager.  Without his help, I may never have made that leap.


To summarize, hiring a coach taught me:

  1. To be an active listener
  2. To give my team the environment and support they need and trust them to get the job done
  3. To effectively communicate with everyone, and always find the time for face-to-face discussions (and daily stand-ups)


But most importantly,

He taught me how to successfully implement Agile and get everyone on the same page; how to destroy the barriers and bring a new mentality to the company as a whole.

Having a coach to help me through the transformation (personal and organizational) was critical to the success of my organization.  Without his involvement, I would likely have had failure after failure, or just walked away from it altogether.  The cost to my organization would have been significant due to those failures, and I still would have had disappointed customers.

I’ve since moved on and have become an Agile coach myself, but even with many years’ experience behind me, I still reach out to other coaches and my mentor for advice, and to share my experiences to help others as well.

If you are transforming your organization, or just yourself, take advice from someone who has already gone through it.

Avoid my mistakes – find a coach/mentor, learn from others who have more experience than you, ask for help and embrace your mistakes.

Roy Schilling is an Agile Trainer and Coach and is based in the Charlotte area.  Roy has 30+ years in IT and 16+ years practicing Lean/Agile in small to large organizations. Roy’s certifications include CSM, CSPO, CSP, ACP and ICP-ACC.

Tech Startups and Agile – A Perfect Fit

by Jim Stewart

To begin, let’s differentiate large traditional organizations from tech startups by identifying some of their typical attributes.

Large established organizations tend to be more risk-averse and have detailed processes in place. Usually, they apply the classic “waterfall” methodology to manage projects. While this method is well-understood, it involves very specific steps, long timelines, and lots of paperwork.

Conversely, tech startups tend to be risk takers  -they have to be- They’re usually creating a “disruptive”product or service in a highly competitive market—something innovative that’s never been produced before.

How startups emerge

According to a US Chamber of Commerce study1, in 2011, millennials launched almost 160,000 startups per month. Twenty-nine percent of all entrepreneurs were 20 to 34 years old.

The US Chamber of Commerce defines millennials as those born between 1980 and 1999, which means they are currently between the ages of 18 and 27. At more than 80M people, millennials have overtaken the baby boomer generation, which was previously the largest generation.

All of this entrepreneurialism helps to drive the economy. According to statistics from the Small Business Administration:2

  • Between 1993 and 2011, small firms accounted for 64% of the net new jobs created (or 11.8 million of the 18.5 million net new jobs).
  • Since the last recession (mid-2009 to 2011), small firms, led by the larger ones in the category (20-499 employees), accounted for 67% of the net new jobs.

Millennials have already started to impact society and will continue to for many years. As a group, they are more diverse and more socially conscious than their predecessors.  As the first generation to grow up with home computers literally at their fingertips, they are both familiar with and comfortable using all types of technology. They are truly “wired.”

The generation Y, how they are also called, believe email and voicemail are for older generations. I’ve frequently seen my millennial kids carry on entire text conversations without ever calling the people they’re “talking” to. They often text and expect a quick response. Unlike their predecessor, Gen Y, prefer quick communication and are intolerant of bureaucracy.

Clearly, not all millennials work for startups or have the desire to found or fund one. However, even those who work in large traditional organizations exhibit much more of an entrepreneurial spirit than previous generations. This entrepreneurial – not to mention independent – spirit is seen not only in their desire to create startups, but is evident in the evolution and expansion of what has become called the “gig economy.”

How is Agile Different than Traditional Project Management?

Briefly, Agile—or the Scrum variant—uses time-boxes (sprints), which are typically two-to-four weeks in duration. At the end of the sprint, the self-governing project team has what is considered a potentially shippable product. This is the terminology used but typically the team runs as many scrum sessions are as necessary to complete the entire product.

This contrasts with the timeline and results of a traditional project plan. After three months of work on a traditional project, you may still be gathering the requirements for a product. After three months of work on an Agile project, you may have run as many as six sprints, iteratively creating a product, refining it, and making changes along the way.

Why is Agile the Best Fit for Tech Startups?

As mentioned, tech startups are often run by and/or staffed with millennials. (Employees in startups tend to work round-the-clock hours.) Agile’s quick return on business value appeals to millennials. They not only want to be able to “turn on a dime,” they want to see the results of their work as quickly as possible with as little overhead as possible. Additionally, since Agile cultivates a much stronger team environment, it’s clear why this group-oriented generation would take to it so readily.

However, this doesn’t mean that Agile appeals exclusively to millennials—it was started by baby boomers—or that it must be applied in a tech startup environment. Nor is traditional waterfall project management going away. Both are valuable methodologies, and both will continue to be used in organizations for the foreseeable future.

But, for tech startups in a millennial age, the smart money is on an increased adoption of Agile as the preferred methodology.

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 move forward with agile adoption? IIL can help. Request a free consultation today.

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

About the Author

Jim Stewart 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.



  1. The Millennial Generation Research Review, U.S Chamber of Commerce Foundation.
  2. Frequently Asked Questions, Small Business Administration.
  3. Gig Economy,

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!

Ready to improve your Agile skills? IIL can help. Visit our website at

[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]