The Meta of getting to Small in an Agile World

If you are Agile in the Product delivery and software development space, there is strong emphasis on thinking small.  This means decomposing work to small pieces to allow for iterative and incremental delivery and eventually the continuous flow of work. While this sounds straight-forward, in practice, it is hard because it disregards the challenging mindset shift that must occur to get people to think small. 

It is important for Agile teams, coaches, and leaders need to understand for those who have never decomposed their work to “small” size chunks, they have little idea what that means and it may take time. This article focuses on several reasons why “decomposing the work to small pieces” is challenging and the meta surrounding the concept of small.

Small is mindset shift  

Imagine that you have never considered what is small and someone says, “think small!”  This is meaningless without any context or experience in “getting to small”.  To achieve the concept of understanding small bite-sized pieces or work, there is mindset change that must occur.  Imagine if you were piloting a plane for the first time and your instructor says, you must go “fast” to take off.  What does fast enough mean if you’ve not done this before? If you only ride a bicycle, then fast may mean 25 mph (or 40 kph). However, in order to take-off, fast means 75 mph (or 120 kph) for a propeller plane and 170 mph (or 275 kph) for a jet.  There must be a strategic steps to shift the mindset to think differently that includes allowing the team time to learn and experience their way to small. 

Small is Relative 

What is “small” will be different depending on the type of work a team is doing. There is back-end, middleware, front-end work and more. Each team must gauge what is small based on their work. Also, what is small will differ from team to team and is relative to team size, talent, and experience. What is small must be specific to each team. Management must not compare sizes across teams as this will deteriorate the relative sizing for the specific teams.

  
Small is Complex 

Creative work like building new products and services (or features therein) are considered complex (per the Cynefin framework) as there are unknowns and “unknown unknowns”, ergo requiring a "probe–sense–respond" approach.  Many will translate small to days of work. But translating small to time of work disregards the complexity and unknowns of the work. In an Agile world, we consider not just effort, we look at complexity of the work (e.g., what is known and unknown), and any risks involved in the work (e.g., what skills, experience, tools, infrastructure a team has and more specifically what they don’t have.  What this means is that to identify small work, you must look at effort, complexity, and risk so it isn’t straight-forward.

Small is Imprecise 

In an Agile world, we don't pretend to think that we can have precision in our sizes. We want good sizes but we have to move away from the traditional mindset where we think we can provide accurate estimates. If it isn't correct, this is actually okay as we’ll soon learn more about the work.  When you size the work within an iteration (aka, sprint) and the iteration is done, you will quickly build a historical database of sizing and will learn more about the work.  The very next iteration, you will have learned whether you were over or under for a size and when similar type work comes along you have input for the future sizing of work.  In other words, “don’t sweat the sizing”. 

Summary

When transforming to Agile, there is a shift to to small pieces of work allowing for iterative and incremental delivery of the work. Small is challenging for teams that have not had to work decompose to small. Understanding the meta around getting to small can help coaches, teams, and leaders navigate the challenges knowing that it is a mindset shift, it is imprecise, it is relative to the work and each team, and is complex.  

Are there Dangers with ChatGPT for Agile?

How will ChatGPT impact Agile? This article discusses ChatGPT and its implications to Agile in the industry today. ChatGPT is taking the internet by storm and hard to ignore. Because of this, it cannot be ignored by those in the Agile field. What are the implications of ChatGPT on Agile? Here is a brief summary of what is ChatGPT and a review of what is Agile and its current journey.

What is ChatGPT?

ChatGPT is an artificial intelligence (AI) chatbot-type tool developed by OpenAI. It is adept at producing human text-based output on the input it is given. This model incorporates a large body of text data and can create responses to questions, write articles, and more. The challenges with ChatGPT are that it is only as good as the “large body of text data”, can be used maliciously and with bias, can spread misinformation, and is ethically complex in its application and future application. This applies to any field that people may use it for including Agile.   

What is Agile?

Once upon a time (in 2001) Agile was unveiled based on the Manifesto of Agile Software Development which is comprised of Agile Values and Principles. The objective of articulating the values and principles is to apply them in the form of an Agile transformation to derive better business results. However, the manifesto does not provide guidance on how to apply Agile. 

Soon, a number of processes and methods (e.g., XP, Scrum, Kanban, SAFe, etc.) were established to construct and apply agile ways of working. Agile has also spawn a number of certification programs in an attempt to educate people in Agile ways of working, in some cases aligned with a process or method. During this same time, Agile coaches were educated to help their own companies and Agile consultancies to help other companies apply Agile ways of working. The Agile movement has grown and expanded in a number of fields beyond software development.  After over 20 years, what are the results? The challenges are three-fold.  

• First, the current state of Agile is underwhelming. The most recent State of Agile Report (16th Annual – 2023), tells us the following. Only 18 percent of organizations implemented Agile for all the teams. Around 50 percent of respondents report that less than half of their teams are using agile, and 84 percent acknowledge that their organizations are below a high level of competencies. There is clearly plenty of opportunity for growth.
• Second, some of the Agile savvy (e.g., coaches, consultants, leaders, managers) seemed to lack an understanding of what is agile. In an Agile study where 109 agile professionals answered a survey on Scrum events and Agile principles, 59% could name 3 or more of the five Scrum events, while only 11% knew 3 or more of the twelve Agile principles. This is quite astounding. And they didn’t need the full statement of the principle but got credit for even the key words of the principle. The concluding hypothesis is that the reason there is such a lack of awareness of Agile principles is that there is much less focused on the mindset and culture and maybe too much focus on the mechanics.
• Third, the implementation of an Agile transformation is complex per the definition provided by the Cynefin framework. Agile transformations are neither linear nor predictive. It depends on the readiness of the culture and willingness of its leaders in their ability to move forward. Complexity means that it is not clear on what the best next step is until you act, ergo you need to probe, sense, response your way forward. This is why experimentation helps reveal what is possible each step of the way. You must both meet the company and teams where they are and help them determine what is the next step to further the transformation.  

What this tells us is that there are great opportunities for improvement and that there is no easy way to apply Agile, no one-size fits all, and no clear roadmap. Why? Because every organization is different due to their current culture, size, fields, practices, and more. 

Implication of ChatGPT and Agile

Now that we have an overview of both topics, the question is what are the implications of ChatGPT to Agile (and vica-versa)?  I’ll start by saying “What you put in is what you get out”. ChatGPT is only as good as the “large body of text data” available to pull from. The good news is that today there are reams of text data on Agile. The bad news is that there is no rating system on the quality of most of the Agile related information. With the advent of blog’s, there is a large body of unverified knowledge that enters into the “large body” of available data. What are the implications of this? 

• Arguable Quality of response - The quality of ChatGPT generated articles and answers should be read with a grain of salt. This isn’t a “knock” on ChatGPT, and instead it is due to the quality of the body of text data that ChatGPT draws from. And the reality is there is no one right way of applying Agile.  
• Propensity for Misinformation - There is a danger of misinformation and abuse of those who use ChatGPT to bias their responses. Some may be accidental as the body of text being pulled in isn’t broadly approved or agreed upon. While I don’t expect that most will be intentionally abusive, do keep in mind, there is money to be made in selling agile so bias may be seen.  
• Not doing your own Research - While you may want to occasionally use ChatGPT, it is better to learn from the body of Agile knowledge out there (e.g., books, articles, presentations, seminars, etc.) according to the areas that will benefit your current needs in your Agile transformation or need. In other words, do your own research so you can critically judge the quality of information that gets generated.
• Taking Agile Jobs - Can ChatGPT take jobs away from Agile Coaches and Consultants? This is unlikely as a significant part of an Agile transformation include coaches and consultants who have been on a transformation journey that can help companies navigate the complexity of both the current needs and the anticipation of near-term needs. ChatGPT cannot “read the room” like an Agile Coach. Should a company think that ChatGPT will be “enough”, it highlights that they don’t understand the complexities of a transformation and what it takes to change culture.

Summation

Now that you have some background, let us again turn to the question, “how will ChatGPT impact Agile?” There will be those that use ChatGPT to provide answers for Agile theory and questions. If you want to write an Agile article, it will help provide input and insight, although you have to be aware that the value of the information is only as good as what it pulls from. Think of ChatGPT as another resource to help you think through your ideas on agile topics and how it may help you in your Agile transformation. However, just remember, it is just a tool like other tools.     

It is unlikely that ChatGPT will take over Agile roles and the art of the transformation. A big part of Agile transformation is discovering, observing, and experimenting on what will work and what will make progress. Remember, when defining Agile, it really implies a transformation. This is a combination of doing agile and more importantly being agile. This means transforming mindset and culture. It is currently unlikely that ChatGPT will have this capability as transformations are complex with the real need to experiment (e.g., probe, sense, response) toward progress.  Coaches and consultants are still important to help transform organizations and more importantly to help leaders and teams make the mindset-shift to truly becoming Agile. 

-------

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

• A Discussion with ChatGPT about Agile 
• How to Experiment with ChatGPT 
• Are there Benefits for adding ChatGPT as a team member? 

Breaking Bad Story Point Anti-Patterns

There is occasional controversy in the Agile coaching community on whether to apply Story Points on user stories. This often stems from the challenge where some think that story points are a direct replacement for estimation and an expectation of precision while others suggest that instead of story point sizing, we should focus on focusing on small pieces of work. In other words, when applying a practice (e.g., story points), a bad pattern is implemented which is opposed to the way practice is meant to be applied. This is known as an anti-pattern. Anti-patterns lead to results that are counterproductive to the intent of the practice and reduce their effectiveness. In other words, not good. 

What is Story Point Sizing? 

Before we go further, let’s take a moment to define what is a story point? A story point is a unit of measure describing the size, complexity, and risk to gauge the amount of work needed to complete a particular user story. 

Story points are also a relative measure to a specific team. Every team creates their own story point sizing framework based on the type of work they do, the skills and experience of the team, and what they personally perceive to be a small, medium, or large amount of work. The team collaboratively determines the story points for each story based on its perceived size, complexity, and risk. 

Story points are often correlated with small, medium, and large sized work. Some use the Fibonacci as it provides a numeric distribution that can be used to differentiate between sizes of work typically using 1, 2, 3, 5, 8, 13, 21. When using Fibonacci numbers, 1, 2, and 3 are aligned with small work, 5 and 8 are medium sized work, and 13 and 21 denote large pieces of work. 

Velocity is a metric that can help a team understand their sustainable pace by identifying the amount of story points of work a team can complete in an iteration. In each case (e.g., story points and velocity), this is why you should not compare the story point velocity across different teams. Story points and velocity are very specifically a team measure and should not be tampered with by those outside of the team. 

Anti-patterns of applying Story Points 

The reason there is concern surrounding applying story points is the ways it gets applied. As mentioned, story points are a combination of size, complexity, and risk of that specific piece of work (aka., user story). This means they are not meant to be used as a predictor or for accuracy. Here are several anti-patterns of story points in the way they get applied: 

• Hours-Days Effort anti-pattern - Some apply story point sizing as if it is nothing more than an estimated effort of hours and days. There is often a direct translation of number of hours and/or days and forget (or ignore) the complexity, risk, and uncertainty in the work.  
• Pretend Certainty anti-pattern - There is often ascribed a sense of certainty when applying story point sizing where it gets used to predict when work will get done. At best, it can help with understanding progress, but you would never estimate “all” of the work up front anyway as priorities (and requirements) tend to shift so it would be a waste to do so. 
• Pretend Precision anti-pattern – There is precision when using story points which isn’t appropriate. The numbers that story points represent are meant to be ball-park numbers as it is an amalgamation of size, complexity, and risk. 
• Contrived Comparison anti-pattern – Some organizations attempt to compare story points and velocity across teams even though they are relative to the team’s composition and the type of work they focus on. This is inappropriate and decreases the integrity of story points and velocity. 
• Effort Tampering anti-pattern – This occurs when someone outside of the team (usually management) attempts to influence the amount a work a team does by insisting on improvement. This impacts the integrity of the story point sizing framework and the velocity data as those are meant specifically for that team to have meaning. 
• Inflation anti-pattern – This can be the result of when someone outside of the team applies the Effort Tampering anti-pattern by attempts to make the team “work harder”. The result may be that the team inflates their numbers to ‘satisfy’ the influencer and effectively impact the integrity of the story point sizing framework. 
• Productivity anti-pattern – This is when story points and velocity get conflated as a productivity measure by those outside of the team. They are not productivity measures and will warp the intent of both story points and velocity. 

Mending Anti-Patterns  

The best way to eliminate or reduce anti-patterns, is to first understand what anti-patterns look like (see Anti-Pattern section above and search of other information on anti-patterns). Then do detective work to uncover what anti-patterns may exist. Follow this with determining an action to remove or eliminate them. You can do this through a theme-based retrospective where the focus is on identifying anti-patterns. 

Anti-patterns within an organization are more commonplace than you think. They are often due to a lack of clarity of what are story points, how they should be applied, and a lack of awareness that they are specifically a team-based measure. There may also be management or team member influence to use the practice or technique incorrectly. If too many of these anti-patterns exist, then the value of using story points as a team measure and as an instructive tool to help team gauge what is considered small diminishes.

Company Success with an Enterprise Pipeline of Ideas

The Enterprise Idea Pipeline provides you with an end-to-end view of the flow of ideas from the moment they are recorded to when they are released.  It is meant for the enterprise to respond to high value ideas the moment they came so the enterprise does not miss the idea’s window of opportunity.  

It provides three primary benefits to an enterprise.  First, it is a channel that provides an end-to-end flow of ideas from the moment they are recorded to when they are released and reflected upon.  Second, it is the enterprise level portfolio backlog of ideas.  Third, it is meant to highlight high value ideas the moment they came in so that the enterprise does not miss the idea’s window of opportunity.  

The culture needed for the Enterprise Idea Pipeline is one where the enterprise immediately considers ideas as they come in because they are based on a current problem or opportunity.  You don’t wait for the next budget cycle to consider the idea. The pipeline is a more adaptable way of managing the portfolio of work across your enterprise since ideas can be admitted anytime and feedback may adapt its priority or reshape the idea.  Also, the pipeline brings enterprise-wide visibility and transparency to the work occurring within an organization.

Before moving further, what is an idea?  An idea is something that is deemed as valuable and has yet to be created.  The moment it is recorded, it may be small or large.  Depending on its level of customer value, it may become work that is worthy of evolving into a product or service or a significant feature of each.    

The pipeline is a working example of the delivery axis focused on delivering customer value as illustrated above. As the delivery axis represents the end-to-end flow of customer value from the recording of the idea to the point where it is released and reflected upon so is the Enterprise Idea Pipeline. 

The Enterprise Idea Pipeline can be known by different names such as a portfolio backlog, enterprise kanban board, and idea pipeline. What makes them all similar is that they hold the big ideas that may eventually (or immediately) be worked on by teams.  The Enterprise Idea Pipeline acts as the parent and feeder to all product backlogs and helps you connect strategy and ideas to user stories (and even tasks) and visa-versa.  

The pipeline is primarily used in medium to large companies, when visibility is needed to make investment decisions across portfolios to better understand where the highest value work lives.  It also helps when there are dependencies across multiple products, or when ideas do not have an obvious resting place in a product backlog.  When an enterprise is small and made up of a singular product, then the product backlog acts as the enterprise idea pipeline as these are the ideas that may be included in the future of that product.  

To learn more about applying an Enterprise Pipeline of Ideas in your company so you can be more customer value driven, feel free to reach out to Mario Moreira at: https://www.linkedin.com/in/mariomoreira/

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/

Good and Bad Reasons for Moving to Agile

There are various reasons behind moving to Agile. Some are proactive and some are reactive. Proactive motivations tend to be accompanied by a greater understanding of the business benefits of Agile and the culture change it implies. However, this is not always the case. The reasons behind the motivation can determine your chances to achieve a real transformation. Let’s take at a notional proactive-reactive model that looks at some motivations for moving to Agile and what you can do to enhance your chances of gaining the business benefits of doing so.  

• "It’s the trendy thing to do." Agile is popular, so we should do it. This is reactive and not a strong motivator for change. When another trend comes along, Agile may be abandoned. Agile may be seen as a hollow initiative and some may wait it out to see if it will go away. It will be important to investigate the benefits of Agile to see if it is right for you. Then determine if real commitment can be gained. 
• "The competition is doing it." Others are doing it, so we better do it. This is reactive. Although it may provide a driver for change, it does not provide clarity on why Agile was chosen. Some will question why what a competitor does is good for us. What happens when they do something else? It will be important to investigate the benefits of Agile to see if it is right for you. 
• "We need to reduce costs." This is a reactive and insufficient reason whereby Agile is seen as a tool to cut costs and maybe the workforce. This will not lead to the business benefits of moving to Agile. Although it may be an outcome, other benefits of Agile may be gained if you are willing to adapt the culture. 
• "What we have isn’t working." We’ve been using another process to deliver software and it isn’t effective. This is a reactive reason with little understanding of Agile, but it may provide an initial motivation for change. However, moving to Agile without understanding what it takes may lead to a failed deployment. It is best to understand the root cause for the failures in the past, because this can affect your change to Agile. 
• "We hope to increase employee morale." This is a proactive reason based on an understanding of the importance of employee engagement and empowerment to improve morale. Validate that there is real commitment to empowering employees and self-organizing teams. 
• "We hope to improve productivity." This is a proactive reason when the goal is to empower employees and help them improve productivity. The danger is that management may believe that Agile is something someone else must do to increase productivity or the real intent is to make employees work harder. The other challenge is that productivity may come at the expense of sacrificing quality. It will be important to investigate all of the benefits of Agile, not just productivity. 
• “We aim to decrease time to market.” This is a proactive reason in which Agile is seen as a way to shorten release cycles. If there is an understanding that this implies a change across the organization to get from market idea to release and it is meant to satisfy the customer, then this is a good starting point. It is still important to discuss the benefits of Agile to see if it is right for you. 
• “We want to deliver customer value.” This is a proactive and genuine reason if Agile is seen as a way to engage the customer and understand value. Validate whether there is a real commitment to delivering value and an understanding of the need to change organizational behaviors and processes to get there .
• “We believe in the Agile values and principles.” This is a proactive and genuine reason where Agile may be seen as a positive change in company vision and behavior. Validate a drive toward continuous customer engagement and employee engagement that can help gain the business benefits that Agile can bring. 

In all of these cases, you need to validate commitment to the values and principles and the culture and business change it entails. Once the initial motivation is understood, we can work to adapt it with the goal of better gaining the business benefits of going Agile.  

What Color is receptive to Agile?

In Frederic Laloux’ book “Reinventing Organizations”, he describes organization paradigms as an evolution in human consciousness.  Examining these paradigms can provide insight into organization attributes that lend themselves to an Agile culture.  The early paradigm starts with the Reactive-Infrared paradigm and then Magic-Magenta paradigm.  Both of these embody the early stages of humankind which include smaller groups such as tribes of people.  This is followed by the Impulsive-Red paradigm which has the guiding metaphor of a wolf pack illustrated by tribal militia, mafia, and street gangs. 

The Conformist-Amber has the guiding metaphor of an army illustrated by a church hierarchy, military, and most government agencies.   Next is the Achievement-Orange which has the guiding metaphor of the machine illustrated by multinational companies and charter schools.  A majority of the organizations today tend to reflect a red, amber, or orange paradigm.

From an Agile perspective, it is after this where it becomes interesting.  A general alignment can be made to two of the latter paradigms that may be considered as behaviors you would hope to see in an Agile enterprise. These are the Pluralistic-Green and the Evolutionary-Teal paradigms. 

The Pluralistic-Green organization strives to bring equality where all viewpoints are treated equality irrespective of position and power.  It uses the family as the guiding metaphor where we are in it together and help each other out. One of the breakthroughs of a green organization is Empowerment. Empowerment is focused on pushing a majority of decisions down to the frontline (e.g., where the work is).  This is directly aligned with Agile thinking where there is a focus on pushing down decision-making to the lowest possible level where the most information resides regarding the topic.  

Another breakthrough of a green organization is that it is a values-driven culture. This very much aligns with the importance of leading with Agile values and principles. The green organization understands that a shared culture where leaders play by shared values is the glue that keeps those in organizations feeling appreciated and empowered that can lead to extraordinary employee motivation.  

The Evolutionary-Teal paradigm emphasizes that the organization adapts as circumstances change. Its metaphor is one where the organization is a separate living organism. In a teal paradigm, titles and positions are replaced with roles, where one worker can fill multiple roles. This is very much like the concept of the cross-functional team within an Agile structure.  This paradigm emphasizes the capability to self-organize around the organizational purpose.  The hierarchical structures are replaced with self-organization focusing on the smaller teams. This is aligned with the Agile principle of self-organizing teams (aka, the best architectures, requirements, and designs emerge from self-organizing teams).  

To read more about how the colors of Pluralistic-Green and Evolutionary-Teal can benefit an Agile journey, consider reading The Agile Enterprise: The Agile Enterprise: Building and Running Agile Organizations. You can also learn more about colors of organizations by reading Reinventing Organizations.