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.

3 Critical Similarities Between Project Management and Agile

By Harold Kerzner, Ph.D.     |     Senior Executive Director for Project Management, IIL

The intent of this blog is not to enter into the debate of whether or not Agile and Scrum are outgrowths of project management, but to show some of the similarities that between them that have increased their rate of success. There are three similarities that I will discuss.

Executive Understanding

Years ago, executives viewed techniques like project management as something that was nice to have rather than a necessity. As such, project management was seen as a fad that could disappear quickly. This resulted in limited support for any and all techniques like project management, except in a few project-driven industries where project management was a necessity.

The growth of project management, as well as Agile and Scrum, is largely due to a better understand of these techniques in the top floor of the building and the accompanying support. Consider the following words used by executives in describing project management:[1]

  • An international, multicultural and global approach
  • Allows us to capture best practices
  • A technique for continuous improvement
  • Selling customers on our project delivery process is just as important as selling them the deliverables
  • The processes increase our credibility as a trusted partner
  • Allows us to have repeatable success and accelerate the time to value for our customers
  • The processes provide us with a competitive advantage
  • The processes shorten our time-to-market
  • The processes allow us to create a more integrated and agile organization
  • The new processes allow us to eliminate unnecessary steps that we used before
  • We can now provide our customers with end-to-end multiservice solutions
  • We are now making decisions based upon facts and evidence rather than just guesses

These comments could very well reflect how executives see Agile and Scrum today rather than just project management. For many of the companies that speak these words, managing traditional, Agile or Scrum projects is more than just a typical career path. In these companies, once every few years, there is an assessment as to which four or five career paths are a necessity for the company’s growth over the next decade. In these companies, project management, Agile, and Scrum mastery are now seen as some of the four or five strategic competencies necessary for the firm to grow. The support for these processes now exists at the senior-most levels of management.



Within the last decade, significantly more companies have begun trusting project leaders to make both project and business-related decisions. For decades, many of the business-related decisions were made by the executives, project sponsors or business owners. Simply stated, there was an inherent fear that project leaders would begin making decisions that were reserved for the executive levels of management. Decision-making controls were put in place.

Today, we believe that we are managing our business by projects. Everything we do in the company can be regarded as some sort of project. As such, project leaders, whether in traditional project management, Agile or Scrum, are seen now as managing part of a business rather than merely projects, and are expected to make both project and business decisions, within certain limits of course.



When mistrust prevails, executives maintain control by developing rigid methodologies for managing projects. The methodologies are based upon rigid policies and procedures, and every project manager on every project must follow the same policies and procedures described within the methodology. While project leaders may be allowed to make “some” decisions, all critical decisions are made by the project sponsors or the executive levels of management.

Today, rigid methodologies are broken down into four components; forms, guidelines, templates and checklists. As a project leader, picture yourself walking through a cafeteria. On the shelves are all the forms, guidelines, templates and checklists that make up the methodology. Because of the trust placed in you, you have the right to select only those forms, guidelines, templates and checklists that you need for your project. This is a freedom that did not exist years ago.

Agile and Scrum activities, as well as many forms of traditional project management, use the term “framework” rather than methodology. Frameworks are flexible and allow the project leader and the team to select which of several tools will be used on a given project. There may be as many as 50 tools from which selections can be made.

In my opinion, the biggest reason why Agile and Scrum have been successful is because of the trust that senior management has placed in the hands of the project leaders, or Scrum Masters as they are called in Scrum. Accompanying this trust is the freedom to use only those portions of the framework that are appropriate to satisfy a particular client’s needs.

These three similarities are greatly enhancing our success rate on traditional, Agile and Scrum projects. Are there other similarities? Most certainly there are. But in the author’s opinion, these appear to be the most critical today.

[1] Adapted from Harold Kerzner, Project Management Best Practices: Achieving Global Excellence, IIL, and Wiley Co-publishers, 3rd edition, 2013; Pages 13-15


Harold Kerzner, Ph.D. 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, most recently Project Management 2.0.