What does the 4th Agile Principle (Business and Development Work Together) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you align with the Agile values and principles? In this article, I expand on the fourth principle to better understand what it means and attempt to identify what evidence looks like to determine if a culture change may be occurring. What is this principle?  

Business people and developers must work together daily throughout the project. Agile attempts to bring an understanding of business value to the development team and the technical choices and challenges to the business side. To do this, it attempts to integrate business and development as one team. In traditional approaches, there is often little interaction between the business (e.g., product management, sales, and marketing) and development (aka, cross-functional technical team). On the business side, this may be the Product Manager or Business Owner. Scrum introduces the Product Owner (PO) role and XP introduces the Customer role as the bridge between the customer and the development team. These roles allow for a closer embodiment of the business and development team spirit and avoid fiefdoms and throwing work “over the wall” from one group to another with little interaction. 

The intent is to make a sincere effort to build a collaborative and amicable yet productive relationship between business and development. Development benefits from a better understanding of what the customer finds valuable. The business side benefits because development will ask for details that the business may not have thought about. In both cases, the result is a product that more closely aligns with what the customer finds valuable. What actions and evidence exhibit business people and developers working together?

• An established and productive relationship between business/customers and development
• A dedicated business owner who works continuously with the development team. 
• Development comprises a cross-functional team with developers, testers, technical writers, designers, and so on. 
• The business owner with the development team work together during iterative planning to build a mutual understanding of the requirements of what to build. 
• The development team demos the working product to the business owner and customers to gain feedback to better align with customer value. 
• The development team can reach out to the business owner whenever needed throughout the project lifecycle.   

It is up to you to determine what supporting evidence will highlight that continuous integration, build, test, and frequent delivery is occurring. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question is, do you believe that business and development should work continuously together as a team?

-------------------------------------------------------------------------------------------------

To learn more about what the Agile Principles look like in Action, consider reading:

• 1st Agile Principle (Satisfying Customer with Valuable Software) at: https://cmforagile.blogspot.com/2023/09/many-want-to-go-agile-or-claim-to-be.html
• 2nd Agile Principle (Welcome Change to Requirements) at: https://cmforagile.blogspot.com/2024/01/do-you-have-evidence-to-support-2nd.html
• 3rd Agile Principle (Frequent Delivery) at: https://cmforagile.blogspot.com/2024/02/what-does-3rd-agile-principle-frequent.html

A Discussion with ChatGPT about Agile

I had a good discussion with ChatGPT about two weeks ago. I started by asking “What is Agile?” The response was that “Agile is a methodology” with a bit more details. While technically incorrect, given the amount of information and vectors it pulled from, it wasn't completely wrong. What I mean by this is that many people, including some “Agile experts”, refer to Agile as a methodology which is incorrect. Depending on where ChatGPT is pulling this information from, this isn’t a surprise.   

• My response: “Agile is a set of values and principles. Some Agile information is not aligned with Agile values and principles and instead rely heavily on Agile processes and methodologies or people's misinterpretation on what is agile”.  
• ChaptGPT's response: You are correct. Agile is indeed a set of values and principles outlined in the Agile Manifesto, and it emphasizes flexibility, collaboration, iterative development, and customer satisfaction. However, misinterpretation or a focus solely on Agile processes and methodologies can lead to a deviation from these values and principles.

I was happy to see that it was aware of the Agile Values and Principles as this is how Agile is defined by the Agile Manifesto which is the seminal information defining Agile. And as I mentioned in my previous article, The Dangers of ChatGPT to Agile, there is a lack of quality evaluators on the numerous Agile articles and presentations in cyberspace that indicate if the information provided is right or wrong, good or bad.

Two weeks later (today), I asked ChatGPT the same question, “What is Agile.” This time it included the Agile Values and Principles as part of its long-winded response that included:

"Agile is an iterative and incremental approach to project management and product development that emphasizes flexibility, collaboration, and continuous improvement. It was created as a response to traditional, plan-driven project management methodologies that often struggled to adapt to changing requirements and deliver value in a timely manner.

Here are some key aspects of Agile:

1. Values and Principles: Agile is guided by the Agile Manifesto, which outlines four core values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. These values prioritize human-centric approaches and adaptability.
2. Iterative Development, 3. Cross-functional Teams, 4. Continuous Improvement, 5. Customer Collaboration, 6. Flexibility and Adaptability" (Note: I removed the details of 2 thru 6 from ChatGPT as this wasn’t relevant to this article).  

While ChatGPT will continue to develop and response to my queries, I am happy to see that it is using my (and others’) input to fine-tune its language model and improve its responses.

-------------

If you are interested in learning more about ChatGPT in relation Agile, Teamwork, or experimentation, consider reading these additional articles:

• Are there Dangers with ChatGPT for Agile? 
• How to Experiment with ChatGPT 
• Are there Benefits for adding ChatGPT as a Team Member?

Has Covid-19 boosted Business Agility?

Written by Nawel Lengliz and Mario Moreira

Economists might argue that the Covid 19 crisis caused a lot of disruption to companies. I strongly believe the pandemic has helped companies improve the way they collaborate, especially via remote work, which boosted their business or, more precisely, their business agility. Let me explain how.

First and foremost, remote work has helped teams in democratizing information sharing. In effect, by using digital tools, it has become easier to have access to information, to briefings of decisions or to digital white boards in the sense that people do not have to be physically present in meetings to understand the meeting outcomes.

Democratizing information sharing has paved the ground for a natural transition to something we believe in a lot in the Agile community: Visualization of the work. This technique, borrowed from lean manufacturing, consists of using a board that shows all the work being done via cards representing each piece of work, is simple and very powerful. Besides creating a shared understanding on who is doing what within the team, using boards helps to visualize problems in the system of work. For example you may find there is too much work in progress (WIP), work with competing priorities or tasks that have remained stagnant. Therefore, by making problems visible, it becomes easier for teams to discuss problems and try to overcome them by continuously improving their system of work. 

Another advantage to the transition to remote work is the ability to have worldwide access to talent. I remember when Covid 19 broke out, I was part of a global company and we wanted to create an Agile community of practice for the french speaking region. Thanks to remote collaboration, we were able to include skillful people located in francophone Africa. This cross-border collaboration allowed very creative ideas to emerge and spark new perspectives. We were all energized by the diversity of our backgrounds and experiences.

Finally, using digital tools during retrospectives or feedback sessions makes it possible for teams to write notes and share their ideas while building trust. This ability to speak up without fear helps to improve the Psychological Safety climate within teams. According to Amy Edmondson, a famous psychology researcher, creating psychological safety is the number one condition for creating high-performing teams.

Nevertheless, people working remotely sometimes miss face-to-face collaboration (I am among them). In fact, being in the same room creates energy as people communicate not only with words, but also with their body language. However, as food for thought, according to some research, flying generates an equivalent of ¼ tonne of CO2 per hour. Is it really worth generating such an amount of pollution to attend a couple of meetings over a day?

In summary, the Covid 19 pandemic urged companies to try or improve new ways of working remotely with such results as democratizing information sharing, making work visible, accessing talent everywhere and using digital tools to foster psychological safety. These techniques have helped companies move faster, be more inclusive and promote collaboration that helped employees to become happier and to our planet being more ecologically healthier. 

• Learn more about Nawel Lengliz at: https://www.linkedin.com/in/nawel-lengliz-111b795/
• Learn more about Mario Moreira at: https://www.linkedin.com/in/mariomoreira/

How Agile is creating a new Horizon for HR

A collaboration by Amy Jackson and Mario Moreira

Gone are the days of certainty.  In order to stay competitive companies must constantly innovate, adapt to changing market conditions, and deliver value to their customers faster than ever before.  As a result, many organizations are embracing Agile principles and practices, which are highly collaborative, iterative and focused on delivering maximum value to customers. 

As Agile adapts organizations, so must Human Resources (HR) adapt.  HR is poised to become leaders in the Agile transformation.  From an organizational change perspective, HR can facilitate and improve organizational agility by crafting programs that improve collaboration, ownership, adaptability, speed, and customer focus.  This can include:

• Continuous Learning – determine the appropriate Agile learning path for your teams.  For those just starting out, introduce the Agile Values and Principles and make parallels to the culture and behaviors your organization values. 
• Adapting Leadership - rethink the role of the manager.  Consider moving from a command and control approach to servant leader/ coach.  Leaders should focus on coaching and removing impediments.
• Empowering Teams – teams that are given clear direction and outcomes should be empowered to determine how they will work to achieve their outcome.  This autonomy will drive higher levels of creativity and engagement, and if done right, deliver maximum value to customers.
• Adapting Performance Feedback – consider moving away from “traditional” annual reviews to more frequent feedback and faster feedback loops.  Individuals and teams can adapt more quickly and apply learnings to improve work.  Provide tools and techniques that empower employees to take ownership of their development.
• Rewarding Agile Behaviors – evaluate programs to ensure they reward the behaviors and mindset you value.  In an agile environment, teams work collaboratively, consider rewards that promote teamwork and collaboration, or recognition for continuous learning, and rewards for delivering value to customers.  A one size fits all approach may not be appropriate.
• Reshaping Talent Acquisition – hire for culture fit and mindset and make this a priority.   Working in an agile environment is not for everyone. 

In addition to focusing on programs that drive agility, HR as an organization should embrace new ways of working that reinforce the Agile Values and Principles.  First, educate yourself and don’t be afraid to experiment and try new ways of working within your HR team.  For example, if you’re considering the idea of Self-Organizing teams, consider experimenting within your team.  You will become more knowledgeable and better equipped with first-hand experience to help guide, coach and facilitate the organization in their journey to become agile. 

As you think about adapting your programs, consider using Open Space Technology.  Open Space is a great way to gather feedback, ideas and insights from your employees that can inform how you design programs for your teams.  This approach promotes collaboration.

If you plan to change or modify one of your existing programs, consider breaking this work into small increments to avoid delivering a “big bang” fully baked program which may not meet the needs of your customer.  If you plan to move away from “traditional” performance management in favor of real-time continuous feedback consider starting with one team, educate them on the value of real-time feedback and then train them on how to give and receive feedback.  Gather their feedback and iterate as needed and then begin to scale the program.

In addition, start connecting to customer value.  Consider creating a compelling purpose that is focused on customer value.  Strive to keep the (external) customer front and center by linking your programs to the value they will bring to the customer. Empower your employees to make decisions that are customer centric – this shift may mean that you change how you compensate or incentivize your employees by moving away from performance metrics that are internally focused in favor of rewarding behavior and actions that delight the customer. 

Strategic HR organizations have expertise in helping companies achieve objectives through focus on organizational culture and high-performing teams.  Given this capability there is a natural role for HR to play in an Agile culture.  HR has an opportunity to become Agile coaches and change agents.  Embrace and ready yourself for change. This may be the new horizon for HR.

-----------------

Learn more about Amy Jackson at: https://www.linkedin.com/in/amjackson/

Mario Moreira writes more about Agile and HR in his book "The Agile Enterprise" in Chapter 21 "Reinventing HR for Agile"

-->--> --> --> -->

Exploring Five Pair Programming Techniques

A collaboration by Antonio González Sanchis and Mario Moreira

Extreme Programming (XP) introduced a programming technique that’s been famous since its early days: pair programming. It sounds simple, two people working together with the same computer. However, what people don’t know is that there are many ways in which you can approach this technique. Let’s explore a few:

Driver-navigator: This is the best known style of pairing. It consists of one person ‘driving’, taking the keyboard and coding or doing the work, while the other one is ‘navigating’. The Navigator’s job is to pay attention to the work being done by the driver while keeping the big picture in mind.  They should guide the driver in the right direction. It is very important that driver explains every decision they make, otherwise the navigator might lose interest and may stop paying attention. It’s healthy to switch roles every now and then.

Ping-Pong: For this approach you might need two keyboards connected to the same computer. In contrast to the driver-navigator mode, in ping-pong both people can be driving at any point in time. A good strategy for this approach is to have one person writing the tests while the other one tries to pass them. As in the previous approach, you should be switching roles often.

Backseat navigator: A typical approach when there’s a new team member in the group or a junior colleague. The navigator (usually the more senior team member) tells the driver, who has the keyboard, what to do to solve a problem with every little detail. The navigator should provide insights on how to solve the problem but also on why that’s the best solution in mind. It’s a good way to ramp up new members in your team as they build relationships with other people in the team while learning about the working style.

Tour: If there is an even number of team members or someone who you used to pair with went on holidays, you are not going to stop working. However, when those people return or you start pairing with someone, you don’t want them to start right away. Therefore, a good way to start would be to do a ‘tour’ through the code or work you did in their absence. The person who doesn’t know the most about the work takes the keyboard and the mouse and starts driving through the code while the ‘expert’ acts as a navigator and explains every detail.

Distributed pairing: Often people tend to think pairing is for collocated teams but that’s not entirely true. While pairing face-to-face is definitely much more effective than remotely, there are many tools and ways colleagues can pair. A good suggestion would be to use a videoconference messaging tool with a screen sharing app that allows the navigator to see in real time what the driver is doing.

These are not the only pairing styles that you might encounter but they are the best known.  They are also the easier techniques to try when you want to start pair programming. Also, examples seem to focus on software development but pairing is applicable to almost every field.  For example if you are in marketing and are launching an email campaign, you can pair with someone to navigate through the email while you write it, etc.

There might be anti-patterns when pairing. For example, you might find cases when the navigator is ‘sleeping’. This means the navigator can be checking emails, texting or even coding in parallel without paying much attention to the driver. Try to identify the root causes of this behaviour before you jump in into action. Usually it might be because the driver is not explaining properly the reasons why he is doing a specific task in a particular way.

Lastly, keep in mind that while pair programming may work in every role or department, it might not be suitable for every work. There will be times when you just want to discuss the approach with the team and go do it by yourself. That’s also a way of getting feedback, which in the end is the main purpose of pair programming: getting feedback early.  

If you are interested in trying pair programming, the first thing to do is review the list of possible techniques (above) and select one that you will experiment with.  Then identify your pair.  Brainstorm on how you might approach pair programming, specify how long you will try your experiment, and begin.  

------------

Learn more about Antonio González Sanchis at https://www.linkedin.com/in/antoniogonzalezsanchis/

Read more of Mario's article at: http://cmforagile.blogspot.com 

Startupbucks (aka Starbucks) the OaaS Innovation Incubator

As I was momentarily pausing from working on a presentation, I leaned back and noticed that there was quite a bit of “business” occurring in my local Starbucks.  There were a lot of enthusiastic conversations with a collection of open laptops, notebooks, tablets, and more being used to share, illustrate, and note ideas.  This wasn't the first time I’d seen this same level of engagement in a Starbucks. 

Then something occurred to me.  I was witnessing an incubator of business, non-profit, and personal ideas being generated and matured.  Of course some people are there for just a coffee and a chair to relax.  Others are there for a quick pick-me-up for the day or remainder of the day.  Alternatively, it was clear that Starbucks was this place where business was happening, where new ideas were being generated, where collaboration was happening, and where progress was being made.  It was an incubator of innovation! 

That’s where it occurred to me, Starbucks was part coffee shop and part office-as-a-service (OaaS) incubator.  I therefore have redubbed Starbucks to Startupbucks!  The first part of the name (Startup) is a place where new ideas come to life and blossom surrounded by the aroma of coffee beans.  The second part of the name (bucks) is coincidentally where hopes for financial reward is part of the innovation dream.   I wonder how much business has been conducted in Startupbucks and much money this translates into?   Next time you are in Starbucks, take a look around.  Are you seeing the same thing that I am?  Finally, thank you Starbucks and the many coffee shops like you for providing us this OaaS that makes a great incubator of ideas and haven for progress!    

Virtual Teams – Agile or Bust

A collaboration by David Grabel and Mario Moreira

You’ve just been given a plum assignment, heading up a major new application development project. Congratulations! Your boss just got off the phone with a large off-shore contracting firm.  At the labor prices they are quoting, we’ll save a fortune and come in under budget. He knows that you’ve been experimenting with virtual teams; it’s time to kick this into high gear and really cut our labor costs. DON’T DO IT! By the time you factor in the extra costs for travel, the high costs of the locally based support personnel (project managers, architects, etc.), the increased systems and telecommunications cost, the miscommunication caused by lack of face-to-face conversations, and the rewrites this will require, the cost savings will evaporate. They will never complete it on time and the missed revenue alone will eat up all of your savings.

There are good reasons to rely on virtual teams. Cost savings is not one of them. Real world constraints can make virtual teams unavoidable. Your company might have a liberal “work from home” policy. Your development centers could be scattered about a large campus, across the country or around the world. You may have a strong relationship with an off-shore development company that has delivered high quality software on time in the past. You might be partnering with a company from another state. All virtual teams are distributed, whether it’s a single member working from home or dozens of teams scattered around the world. Co-located teams will almost always be more efficient and effective than virtual or distributed teams. When virtual teams are unavoidable, the key to success is to Be Agile. If you follow the agile values and principles you can successfully deliver valuable working software, quickly, with high quality, even with virtual teams.  Let us explore how the Agile values and principles can be put into action to help with virtual teams.

• Value people and interactions over processes and tools by enabling virtual and physical face-to-face conversations. If team members are in different time zones, encourage flexible hours and provide high quality video conferences for stand-ups and other ceremonies. Supplement the teams with collaboration tools. Bring the teams together periodically to learn each other’s business contexts, cultures, and individual needs. Virtual teams necessarily need to rely more on electronic tools like agile project managers and collaboration software. These tools help, but virtual teams need to nurture the interpersonal relationships that allow trust to develop. Trust within and across teams is vital to agile success.

• Value working software over comprehensive documentation by writing stories about the users experience and by delivering small increments quickly based on those stories. The traditional wisdom has been that virtual teams require very detailed requirements and design documents. These heavyweight artifacts don’t exist on agile projects. Very detailed requirements create the illusion of completeness and accuracy. All those details about what they system shall do obscure the problems we are trying to solve

• Value customer collaboration over contract negotiations by scheduling regular demos with customers to get their feedback and deepen the understanding of the business problems to be solved. This is more important than checking the boxes on a requirements document. This is a case where virtual meeting tools can bring remote teams and customers together even when they are physically apart.

The agile values and principles are the best guiding lights available today to make virtual teams work. If you have to use virtual teams, please consider using agile practices and staying true to the values and principles. 

Right-sizing Documentation in an Agile World

Within an Agile context, there is a focus on right-sizing documentation.  This is a response to the bureaucracy that has led to large volumes of project and product documents which are often left unread, are out-of-date the moment they are complete, and seem to have little value to the team.   On the other hand, I have heard folks who are in an Agile context say that no documentation is needed.  The truth is somewhere in between.    

One of the values in Agile is “working software over comprehensive documentation”.  This does not mean that there is no value to the item on the right, but there is more value to the item on the left.  The key is right-sizing the documentation.  Right-sizing means that the level of effort applied to write and maintain the documentation plus the value of that written document should have a greater return on investment (ROI) then not having that information readily available (i.e., the effort it would take reconstruct the information and impact of not having that information for current decisions).   With that in mind, here is some high-level guidance on right-sizing documentation. 

• Documentation should be living and evolutionary and not “sitting on the shelf”.   Move away from the notion that document is “final”.
• Consider some documentation to live at the product level where it may naturally evolve from both sprint to sprint and from release to release. 
• Documentation should take on a collaborative nature.  It should not be written by one person to perfection, and then shared with others.  It should instead be shared often during draft to gain input   
• Update your documentation continuously as new things are learned.  If you learn something that can impact the team or help with decision-making, go to the document and update it. 
• Focus on just barely good enough documentation and avoid big upfront details which typically means a lot of guessing and wasted time.   Barely good enough means document what you currently know.  If you no longer need the document, it is reasonable to retire it. 
• Be concise and lean.  Write in succinct prose and add bullet points if reasonable.  Avoid long and flowing prose which may lose the reader’s attention.
• Documentation can take many forms.  It is not only a Word document, documentation can live on a wiki, in the Agile planning tool, as comments in code, and much more
• Document decisions.  Knowing the decisions helps those who must maintain the product and understand why things were decided or done in a certain way.   
• Realize that there is a difference between internal and external documentation.  External documents may be a User Guide or document that gets delivered to the customer.  These should be considered as “working software” and follow the rules of the done criteria.    

What might get documented in an Agile world?  The major documentation comes in the forms of user stories and epics.  This includes writing the user story in canonical form, with details, and acceptance criteria.  Technically, another significant form of documentation is the code itself. It should be written in team agreed coding standards with appropriate comments that specify what the code does (or simply and clearly enough that don't need explanation) and why it was written a certain why.  Remember that code needs to be maintained so if someone has to "figure out" what you wrote and why in order to support the code, then it is problematic.

You should consider lean versions of your architecture, coding, and test strategies that help inform the team of ways of working. Impediments that require effort to fix should be documented.  Items such as coding standards, an overview of your working processes and policies, done criteria such also be documented and shared. 

What do you think of this guidance?  Do they make sense?  Do you have any other tips?

A Path from Command and Control to Agility

Have you ever noticed a team where little engagement, a lack of ownership, and team decisions are scarce?  One reason could be the amount of command-and-control from management that is occurring.  Often times this is one of those unspoken elephants in the middle of the room.   Command-and-control bosses and leaders are a sure way to kill the feeling of ownership, engagement, and empowerment in team members. 

Agile comes along and promotes self-organizing teams, transparency, and team decision-making.  It also helps companies bring more value to customers and adapt to the market conditions, ultimately leading to making more money.  Within an Agile culture, it no longer requires a manager to tell a team what to do.  The number of organizations following Agile continues to increase. They realize that they no longer need directive managers but leaders who act more as coach and mentor, then the traditional boss.  So what is a command-and-control manager to do?   

• If they feel they have command-and-control traits and are willing to make that move to Agile, they can test their comfort level with collaboration first.  When a team decision is needed, consider an experiment.  Ask the team for their thoughts.  See if the command-and-control manager can be just one voice of the many that are on the team instead of forcing a direction.  Better yet, see if the manger can remain quiet and let the team arrive at a decision.  If this works, next they can test their comfort level with self-organizing teams.  The next time there is a decision that impacts the team, ask they can ask the team to discuss it amongst themselves and decide the course of action.  Stand back and let them decide. 

• If the manager is inquisitive about Agile, provide them some education on the Agile values and principles.  They should consider what they think each of the principles mean and if they believe in them.  A bolder move is having them share the Agile principles with their team and ask them what they think it means.  Also they can ask the team members how it can be exhibited on a team.  Ask the team members if they think we would be a good idea to exercise some of the principles. 

• If they have directive tendency and their current role has them interacting with customers to understand customer needs, then they may consider becoming a Product Owner (PO) for the team.  While they should no longer be manager, a PO helps shape the product through the collection and grooming of the requirements.  The PO also shares the need with team members during the Agile-related planning events (e.g., Sprint Planning).   

• Learn about the concept of bounded authority.  This is where the team can make their own decisions, organize, and commit to their own work.  It does not mean that teams can do whatever they want.  The balance is that the manager keeps limited responsibilities to provide vision and support for their staff while allowing the team the ownership to self-organize around the work.  

So I will leave you with this question.  Which approach will lead to more productive and high-performing teams?   Is it a culture where managers tell employees what to do or is it a culture where employees are self-organizing, feel ownership of the work, and are able to use much more brain power?   If managers exhibit command-and-control tendencies, it is in their best interest in the long run to adapt toward and Agile mindset and allow for self-organizing teams.  Since Agile is pervasive in many companies, it is an opportunity to adapt and help the organization toward better business results.  

The Knight bringing Agile to the Day

Once upon a time, a Knight challenged the King saying that we should provide people with what they need and not what we want to provide them. Instead of asking people for all of their needs now and not deliver until a year later, we should deliver their more important needs in shorter time periods to ensure we provide them with their needs sooner and then allow them to adapt to their needs as life changes around them.

The Knight learned that the marketplace and the customers therein drove the real needs. This gets to the heart of providing business value, value that the customer perceives, value that can change in this ever-changing world.

As the Agile Manifesto (the Knight's creed) says, Agile values working software over comprehensive documentation. Working software is where the customer sees the value. The “right” amount of documentation, neither too comprehensive nor too little, can lead us to working software more quickly.

Individuals and interactions have more value than processes and tools. This does not mean that processes and tools are not important, it is just that defined processes and tools should not determine how the individuals should interact to get their work done.

Customer collaboration is valued over contract negotiations since Agile values the continuous interaction with customers to ensure we are constantly reducing the risk and increasing the certainty of delivering what the customer really needs.

And finally, responding to change over following a plan allows us to adapt to change with collaborative control that ensures the change is both welcome, understood, and continuously validated.

Agile embraces change and accepts the fact that life is uncertain. By providing methods and techniques to minimize risk and increase certainty, this ensures we close the gap between what the customer actually wants and what we end up delivering.

With that, the Knight brought Agile into the day and people into the light.