Subscribe to The Agile CEO via email

Your email:

Charlie Rudd

Charlie Rudd, SolutionsIQ CEO I’m Charlie Rudd, CEO of SolutionsIQ, an Agile company. I’m interested in learning better and better ways to unleash the power of teams by applying Agile management principles and practices throughout the enterprise.

Subscribe to our Newsletter

siq newsletter 180

The Agile CEO: A Blog About Agile Leadership

Current Articles | RSS Feed RSS Feed

The First Step in Scaling Agile: Establish a Solid Foundation of Agile Teams

  
  
  

This post is the fourth in a series on scaling Agile.

Establish a solid foundation of Agile teamsIf this first step seems self-evident, then you would probably be surprised by how many people focus on scaling issues such as integrating work across teams and organization-wide “release trains” without having a clear idea of what they need to do to establish and sustain solid Agile teams. Before delving into this in more detail, I want to connect the dots between team collaboration and Agile practices such as Scrum and Extreme Programming (XP).

Agile in a nutshell

Over the last few blog posts, we have spent most of our time discussing how the family environment is the natural setting from which collaboration first sprung and how teams will prosper if they are able to emulate this environment in the workplace. Maybe you’re thinking that’s all well and good, but isn’t there more to Agile teams than collaboration? What about the rest of the Agile? What about Scrum and XP?

To get some perspective, it’s helpful to revisit why we are doing Agile in the first place. Agile helps us progress under conditions of high uncertainty, the very conditions under which our previous approaches to managing work failed. Although the root causes of uncertainty may vary, the Agile approach to managing through uncertainty is consistent: Progress incrementally and adapt accordingly. This allows us to learn in a stepwise manner what we need to do to deliver an emergent solution. Because the Agile process is iterative, it’s useful to represent it as a cycle:

Adapt, deliver, inspect
In the diagram above, I have chosen verbs that are often used to describe Scrum. However, the verbs we use are not that important. What is important is making sure we have a clear understanding of the underlying activities: (1) Deliver something quickly (2) learn from the outcome (3) apply new learning to the next work increment. 

Work is organized around the objective of speeding learning by doing a little bit at a time. Shorter iterations offer more learning opportunities and diminish the time between ideas and actions. The best way to proceed in this manner is through team collaboration. Teams are able to establish the mutual understanding and trust needed to — quickly — learn together and synthesize ideas into a pragmatic, testable construct:

Adapt, deliver, inspect

Team collaboration is integral to Agile. Without collaborative teams, there is no Agile. Agile practices such as Scrum and XP provide frameworks and techniques for learning rapidly and delivering incrementally. They also include guidance about how to work effectively together as a team. They also assume and depend upon team collaboration. The family pattern for team collaboration complements Agile practices by establishing the workplace conditions needed for team collaboration. It’s the responsibility of the team to learn Scrum and XP and be willing to work in concert. It is the responsibility of the organization’s leadership to create the workplace conditions that are conducive to this working pattern.

Agile Scaling guiding principle

In the first post in this series, I introduced two principles to guide decisions that help us scale Agile:

  1. Be very clear on what Agile capabilities you wish to preserve and scale before you introduce new scaling structures.
  2. Be careful to choose structures that won’t impede, corrupt, dilute or otherwise limit the Agile benefits you hope to achieve at the next level of scale.    

Regarding the first principle, it should be clear by now that in all cases an essential element of the value that we must preserve as we scale are Agile teams themselves. Without Agile teams, there is no Agile at any scale. If Agile teams are compromised as we scale, the benefits of Agile are also compromised.

The first step in scaling Agile is establishing Agile teams. Similarly, the first dimension of scaling is increasing the number of teams. Teams also constitute the first scaling structure. In slightly different words: Agile teams are the foundation for any additional scaling structures. As the foundation, Agile teams should be persistent, mature, well-formed, and well-supported. To the degree that they are not, our further scaling ambitions at the program and portfolio levels will be put in jeopardy.

Since, so far, the only scaling structure we have introduced are the teams themselves, we have not (yet) violated our second scaling principle. However as we discussed above, to get Agile teams established in the first place we need to create the conditions necessary for Agile teams to survive and thrive. In most cases this means not so much creating new structure but revising old organization frameworks that would otherwise impede healthy team development. I summarized some of these stumbling blocks in a previous post.

Scaling Agile teams

Agile is definitely biased in favor of the rule of parsimony, where less is more.  Therefore you should avoid over-building or over-engineering when you can. When it comes to scaling Agile, this means delivering business value through single teams whenever possible. Keep in mind that there are many programs and products that are simply are too large to be completed by a single team. In such cases, there is a need to coordinate and integrate the work of several teams in order to deliver anything with economic value.

In the next blog post in this series, we will begin our discussion of this next level of scale, Agile program management, by comparing it to a village, the corresponding next level of scale after families that occurs in human civilization.   

7 Obstacles that Impede Agile Transformation

  
  
  

This post is the fourth in a series on scaling Agile.

Family-Style Collaboration in the Workplace (Base Unit of Scaling) In my previous post, we introduced the Family Pattern for Team Collaboration, seven success criteria for establishing healthy teams. Although to some degree we can replicate the family environment in the workplace, we should not forget that workplace teams are not families. As natural as it may be at home, family-style collaboration is not natural in today’s workplace and likely won’t occur at all unless deliberate steps are taken and many obstacles overcome.    

Organizational change management

Family-style collaboration in the workplaceFor example, a shared goal (criteria 4) comes naturally enough for a family. However, in the work environment special efforts will need to be made to provide the team with the information and context they will need to align on a goal, with each other and with the broader organization. Similarly, it’s natural enough for a child to learn to trust his parents after being sheltered for years in the comfort of their home. Workplace teams, however, will find it difficult to develop the trust relationships needed for mutual commitments and collaboration if their organizations don’t take steps to provide them with a private, protected space (criteria 6).

In addition to these examples, there will be many other steps the organization will need to take in order for healthy teams to form and persist. Although circumstances vary  by organization, there are impediments that occur frequently enough for us to identify them as recurring obstacles to Agile Transformation.

Here are 7 stumbling blocks that prevent Agile transformation:

1. Lack of physical team space

As mundane as this challenge may sound, it’s sufficient to kill an Agile initiative or stop it before it ever gets started. Collaboration thrives when teams are in intimate proximity. Maybe an exceptional team can overcome this challenge, but not the many teams of a larger Agile transformation. Once teams get established and members have effective working relationships, the team has a greater chance of surviving if some members are dispersed. Also, an Agile program involving many teams does not need to be completely co-located in order to be successful. What is vital is that small groups of people intimately work together and develop the trust and mutual understanding necessary for effective collaboration. It will be extremely difficult for small groups to achieve this state if they are never afforded the opportunity to work in a shared, physical space.

2. Lack of available business collaborators

Each team needs a single point of contact business representative (a.k.a. sponsor or customer). Known as the “product owner” in Scrum, this person needs to frequently engage with the team and have the authority to specify, prioritize, and accept the team’s work. It’s surprising how often organizations attempt to go Agile without taking steps to fulfill this role in a meaningful way (or even at all!). Not properly fulfilling this role will curtail the efficacy of your Agile initiative, even kill it.

3. Incompatibility with existing governance policies

Unlike the first two impediments, it’s unlikely that any one incompatibility will outright kill your program. However, collectively over time they can cause the proverbial death by a thousand cuts. Here are a couple of typical examples:

  • Quality gate sign-off policies. Memorialized documents such as project plans, requirements, and design documents may not be amendable after formal sign-off from upper management (without formal change requests). However, Agile won't work if teams and their product owners are not empowered to make changes to tasks, estimates, priority, and design.
  • Capital expense-tracking procedures. The mechanisms used to track CapEx are sometimes disrupted by new Agile processes. If new procedures are not revised that are conducive to Agile and CapEx policy, this can result in the organization clamping down on how broadly Agile methods are used. 
    4. Exclusion of supervisors and line managers

    When teams are empowered, supervisors sometimes lose job responsibilities. Yet too often organizations make no provisions for addressing these changes in line manager function and status. This can result in active and (less addressable) passive resistance to the Agile transformation from an important and influential constituency. To add insult to injury, Agile programs create new work to support and advocate for teams, if teams are to remain productive and fulfill their full potential. Yet no effort is made to discuss with supervisors (or anyone else) how they might fulfill these new responsibilities.

    5. Individual performance management systems

    This impediment takes two forms: A short form and long form. The short form takes place early in the Agile transformation as employees are assigned to teams and their new Agile team roles conflict with their current individual performance agreement. For example, going with the team may mean losing the ability to complete individual work items, thereby jeopardizing your bonus. The long form of the impediment, like slogging through an every-deepening marsh, slows you down and eventually stops progress as you become deeply mired in clashing values. On the one hand you force-rank peers, putting them in a zero-sum game competition where to win means your peer must lose. On the other, the Agile value is commitment to the team, where all “win” or “lose” together. These two systems are not reconcilable.

    6. Out of phase with upstream and downstream work streams

    The Agile team is somewhere in the middle of a larger flow of work or value stream. It increases frequency of inflow and outflow to every two weeks, maybe even less. If the cadence of work upstream and downstream from the team does not also change, then delays and log jams can occur.

    7. Single team assignment

    Like stumbling block #1, this impediment corresponds to an element of the family pattern for team collaboration (criteria 7). People who are simultaneously committed to more than one “Team” are unable to make meaningful delivery commitments because of inevitable conflicting team imperatives. If members can’t make meaningful commitments, Agile won’t work. This problem grows in magnitude as the program grows in size and more teams are involved.

    In some cases such as #1, lack of physical team space, the stumbling block means something new needs to be added. In other cases, as in #5, individual performance management, something needs to be revised. Taken together, everything that you need to change conditions on the ground, revise policies, and overcome impediments in order to achieve your desired outcome is (organizational) change management. Organizational change management is especially crucial to the success of Agile transformation initiatives because for most organizations profound changes are needed in the behavior and even the attitude of the people affected.

    Change management

    Generally speaking, as the scope of the change increases, the need for change management accelerates. This is because as organization's size increases, organizational complexity also increases, as does organizational inertia. Consequently, any Agile-at-scale initiative, with many teams that are part of a large, dispersed organization, will generate a significant amount of organizational change need — so much that a dedicated organizational change program will be needed to achieve any assurance of success.

    The Family Pattern for Team Collaboration

      
      
      

    This post is the third in a series on scaling Agile. It continues the comparison between the base unit of scaling, the team, and the base unit of society — the family — which was started in my last post, Why Focus on the Team Rather than the Individual?

    In the workplace, collaboration happens on teams, but we first learned to collaborate as children, as members of families.  

    The family pattern for team collaborationThe family is not only where collaboration is first learned, it’s also where collaboration naturally occurs, where for us humans it first evolved. We were born with the ability to collaborate just as we were born with the ability to speak. All we need is to be situated in our natural environment, the family, and collaboration will naturally occur. By modelling our workplace collaboration on the family pattern for team collaboration, we follow the most natural, the most robust, the most successful — indeed, the mother of all collaboration.

    The family profile

    The family is strongly aligned on a shared purpose: Survival. It doesn’t get much more compelling than that. Alignment is so strong that family members have a collective identity, including a shared name. Family members are mutually dependent and devoted to mutual welfare. They also are cross-functional, including at the very least the distinct roles of mother, father, and child. Families are small and persistent, lasting for a long time. Families are amazingly robust and resilient. When the family is able to develop over time, members naturally develop strong bonds, deep trust, and intimate communication. Once family bonds develop, families can survive outrageous misfortunes, including the death of members and years of separation.

    The family environment

    Families exist within a shared inviolate sanctuary, where members can “be themselves” and freely communicate without fear of censure by outsiders. The shared intimacy of the family space is a private domain separated from the public world.

    The family manages its own affairs and creates its own rules with little outside interference. We usually assume that when greater society intervenes in family affairs something is seriously wrong with the family or the society.

    Family as system

    Family systemFamily members form relationships that cohere into a holistic system that maintains dynamic equilibrium. The well-being of each family member depends upon the others. Small changes with one member can result in big and surprising changes elsewhere in the family.

    Like all systems, the family is defined by a boundary that unifies its constituents and separates it from the rest of the world. The family system emerges as the members self-organize through their interactions, and as the family responds to ever-changing external conditions. The family establishes a shared culture or character that is more than the simple addition of the personalities of its members.

    From our above discussion of the family, we can abstract the family pattern for team collaboration as six success criteria for establishing healthy teams.

    The family pattern (for team collaboration): 6 success criteria

    1. Small – Teams should be family-sized (>2; < 10).

    The small size is needed because deep collaboration requires intimate communication and intimate communication does not scale. This is a key reason why scaling Agile requires integrating many small teams rather than increasing team size. 

    2. Long lasting – Teams should be built to persist.

    People need time to develop into teams. However, once they do, their performance increases exponentially compared to what they could do individually (if at all). Team performance should also improve over time. Agile teams should be treated as business assets with enduring business value, not as operational expenses. Like all business assets, they are investments managed to produce an optimal future return. 

    3. Clear boundaries – Clarity on who is on the team, what the team controls, and what the team is responsible for.

    If team membership never stabilizes and the team can be penetrated at will by outsiders, then it will be difficult to create the environment necessary for the team to make significant commitments to each other or the broader organization.

    4. Shared objective and purpose – The team needs to willingly agree to commit to a common objective or purpose.

    Without a shared objective it will be difficult for team members to work through dissent and develop the consensus necessary for meaningful progress.

    5. Private, shared space – A place the team can work together without external disruptions.

    The team needs a shared environment and privacy to build the trust and relationships necessary for effective collaboration and that shields them from external disruptions. 

    6. Empowered – The team is able to organically self-organize and create their own procedures and policies.

    Without the ability to self-determine, the team will have difficulty getting aligned, making collective commitments, and forming a collective identity. 

    7. Single team assignment – Each team member is dedicated full-time to one team.

    There are exceptions: Specialists such as DBAs or UX experts may be shared across teams. However, team members mostly need to be dedicated. Multiple assignments inevitably leads to unresolvable conflicts, unmeaningful commitments, and lack of empowerment. 

    Organizations that wish to scale Agile to large programs must first assure that the conditions needed to develop healthy teams exist and will be preserved. By conforming to the family pattern for team collaboration, organizations can be assured that they create an environment that is not only suitable for healthy team development but in many respects is the optimal collaborative environment because it emulates how collaboration naturally occurs.

    Why Focus on the Team Rather Than the Individual?

      
      
      

    Why focus on the team rather than the individual?This post, the second in a series on scaling Agile, picks up on the discussion started in the first post where I compared different levels of scale in the business world with corresponding levels of scale in our broader society.

    Over the next few posts, I will discuss the base unit of scaling — the team — and compare it to the base unit of society — the family. I hope to demonstrate that knowledge-worker teams are successful when they are able to emulate the natural environment of healthy families, the place where collaboration began.

    Today’s post will focus on why we choose the team as our base unit of analysis rather than the individual.

    As Aristotle said,

    “Man is by nature a social animal; an individual who is unsocial naturally and not accidentally is either beneath our notice (an animal) or more than human (a god)”

    For most of human history, personal identity was secondary to social identity. People thought of themselves as members of a family or tribe first, and as an individual second. The emphasis on the individual over the social is in large part a modern phenomenon. This is partly a product of post-enlightenment political philosophy (individual rights) and partly due to the specialization of labor. Focusing on individual contributions while ignoring the social context obscures our ability to understand how value is generated in the workplace. This is especially true when it comes to knowledge work.

    The Ford assembly line in 1928Knowledge work such as design and innovation depends on the synthesis of diverse perspectives (See Steven Johnson’s video, Where good ideas come from, for a great discussion on this key point). Or, put more succinctly, collaboration. The unique qualities of the participants, their personalities, their personal histories, and how they engage together determines the quality of the work outcome. In other words, the same project, if staffed by different people, will yield different results. Compare this with an assembly-line operation where switching out individual workers does not change the work outcome. On the proverbial assembly line (decidedly not the case in lean organizations, such as Toyota), all we want from the worker is their labor. Labor, abstracted from the individual, is treated as a fungible commodity. The laborer’s unique human characteristics are — best case — non-added value. This traditional management approach is anathema to knowledge work.

    In contrast, the Agile management approach invites knowledge workers to bring their full selves to the workplace. Individual ideas and efforts are integrated into a collective work product. This is why, in Agile environments the unit of the production is the team, not the individual. 

    Scaling Agile is Scaling People

      
      
      

    The challenge of scaling Agile can be posed quite simply: How do you extend the power and magic of a high-performing Agile team to a larger group of people?

    Scaling Agile is Scaling PeopleWouldn’t it be nice if scaling Agile was as easy as scaling insects to the size of monsters as we’ve seen in the old SciFi flicks? Get some radioactive defects from a maniacally-inspired lean start up that failed real fast; sprinkle a little on your Agile team, and… Voila! A team of seven (+ or - 2) 50-foot Agilistas.

    We know that we can’t grow insects to the size of monsters because we are bound by the physics of scaling. The invertebrate can grow so big (on land at least) and then a new structure must be introduced such as backbone for the organism to grow any further. The new structure allows the organism to scale up to a certain size and then a different structure must be introduced to grow even bigger. Each new structure allows for further growth but at the expense of transforming the organism into something different than it was before.

    From this observation we can glean our first big challenge: How do we scale Agile without destroying the benefit of Agile during the process?  To avoid falling in to this trap, let us be guided by these two principles:

    1. Be very clear on what Agile capabilities you wish to preserve and scale before you introduce new structures.
    2. Be careful to choose structures that won’t impede, corrupt, dilute or otherwise limit the Agile benefits you hope to achieve at the next level of scale.    

    To illustrate guiding principle 2 , when we think of organizational structure, a topic closely allied to scaling Agile, we often think in terms of org charts, fixed reporting relationships, top-down communication pathways, fixed job descriptions, and the like. With these ideas in mind, we “scale the organization” by adding new levels and columns to the hierarchy and occasionally concoct a new job description. For those of you who don’t already know this and as we will make more clear a bit later, choosing this as your predominant approach for scaling Agile is a mistake. You risk squelching the Agile value that you wish to scale and, best case, you become distracted and don’t attend to what is really important. Yes, you may wish to—even need—to change your formal organization at some point during your Agile transformation but that is not where you should first look for a solution. To do so is to let the tail wag the dog.

    When it comes to choosing structures, it’s important to keep in the forefront of our minds that scaling Agile is about scaling people; or more precisely scaling human systems. Unfortunately our mental models for “scaling” and “structure” tend to be populated with pictures of scaffolding, cranes, steel girders and concrete. Viewing our task through these metaphors can get us started on the wrong track and in hot pursuit of faux solutions.  Rather, the stuff of human systems is humans and human relationships. So the natural place for us to look for models for scaling human systems is where human systems naturally occur. More specifically: the family, the village, the city port, and the nation state.

    As we will see over the course of this series each naturally occurring human system corresponds to an Agile-at-scale level:

    Family

    The family corresponds to the team

    The village corresponds to the program or product

    Village
     
     City port

    The city port corresponds to the portfolio

    The nation state corresponds to the corporation or enterprise

     State corp

    We seek models for scaling agile from our recent studies of society and culture, especially models that view human interactions in terms of complex systems. Why? Because the closer you look for the source of Agile success the clearer it becomes that it is predicated on treating people as humans—not labor, not self-interested rational agents but humans, collaborating humans. Humans are naturally complex, as are the human systems that naturally form when humans collaborate. Agile unleashes the pent-up power of teams that has been locked down and tied up by our traditional management practices and our never-ending zeal to increase organizational efficiency by extracting labor from people in spite of their human qualities. Qualities we’ve grown accustomed to thinking of in terms of unwanted variance, nuisance, noise and waste.  However, we now understand that what we once viewed as nuisance, noise and waste are the very qualities that we need to learn fast, think afresh, innovate, adapt, and survive in the 21st century. In short, the value that Agile brings us.

    When we successfully scale Agile, we humanize organizations.

    Patent Trolls Beware: Humanity Strikes Back!

      
      
      

    Patent TrollCheck out this ruling from the United States District Court of California sanctioning attorneys for predatory behavior and abuse of copyright law. You don’t expect to be entertained by reading a court document but then court docs usually don’t quote Spock:

    "The needs of the many outweigh the needs of the few."

    — Spock, Star Trek II: The Wrath of Khan (1982)

    The ruling is hilarious (yes, hilarious). It’s also a relief to see the legal system begin to rise from its slumber and put some checks on the bullying behavior of patent trolls and their ilk.  

    For those unfamiliar with the subject, patent trolls are legal entities (often comprised of shell companies) that have acquired the rights to patents (and copyrights) — not to put them to productive use, but to sue third parties for their unlicensed, often inadvertent use. Patent trolls use two different business models:

    • The shakedown: In this case, the patent troll identifies some small fry, often a startup business, and threatens a lawsuit unless the victim pays a license fee. 
    • The protection racket: In this scenario, the patent troll offers a subscription service to the small fry and offers to “protect” the victim by "defending" them against parties who might threaten to sue them (namely themselves).

    You might say, what’s wrong with the troll protecting their interests? Well, what makes it wrong is that the victim may not be using the troll’s patent. They may even own their own patent. However, they have no choice but to enter into costly litigation to defend themselves against the possibly false charges of the patent troll. This litigation can cost hundreds of thousands if not millions of dollars. How many startups can afford that kind of unplanned expense?

    The reason so many fall prey to this line of attack is because the patent system has not kept pace with changes in technology, especially when it comes to software technology. The patents themselves are often hopelessly ambiguous and overlap in definition. For example, dozens if not hundreds of patents have been granted that include the phrase "…managing (or accessing) data on a network…" or its equivalent.  

    How big a problem is this? A recent study estimates $29 billion drag on the economy in 2011 alone. 

    How sad that the original intent of the U.S. constitution — to encourage innovation by safeguarding the interests of individual innovators — has been so completely subverted by patent trolls that have gamed the legal system to extort value from the real innovators that the constitution was originally designed to protect.

    Well, lets hope the worm has turned. My hat's off to you, the Honorable Otis D. Wright II, United States District Judge

    The Lean Startup, Agile, and the Harvard Business Review

      
      
      

    Steve Blank has an article in the May 2013 edition of HBR entitled Why the lean startup changes everything. It is an excellent example of the crossover of Agile principles from the software domain to the much broader context of business management. The fact that it is published in HBR and not Computerworld is significant.

    The Lean Start Up and the Harvard Business ReviewBlank first describes what the Lean startup is and why it’s such a huge improvement over the traditional approach to starting a business. He differentiates the startup from the established business by observing, “One of the critical differences is that while existing companies execute a business model, start-ups look for one.” This turns on its head the historic approach that requires a comprehensive business plan as a prerequisite for funding.

    It turns out that Blank was Eric Reis’s teacher, and was present as Reis conceived the idea for the lean startup. “Eric quickly recognized that waterfall development, the tech industry’s traditional, linear product development approach, should be replaced by iterative Agile techniques. He also saw similarities between this emerging set of start-up disciplines and the Toyota Production System, which had become known as 'lean manufacturing.'”

    Blank then broadens the discussion to suggest that lean start-up principles, if applied more universally by the venture community, could catalyze the creation of an “innovation economy” with “profound economic consequences”. He goes on to say, “If the entire universe of small business embraced (lean startup principles), I strongly suspect it would increase growth and efficiency, and have a direct and immediate impact on GDP and employment.”

    He then moves on to big business. “Corporations have spent the past 20 years increasing their efficiency by driving down costs. But simply focusing on improving existing business models is not enough anymore.”

    Blank concludes by saying, “In the 21st century (continual disruption) will make people in every kind of organization — start-ups, small businesses, corporations, and government — feel the pressure of rapid change. The lean start-up approach will help them meet it head-on, innovate rapidly, and transform business as we know it.”

    The lean startup toolkit is based on Agile principles that help us manage through ever-mounting business uncertainty, something traditional management tools were not designed to do. The traditional management approach has been to avoid uncertainty or to wait it out to. But in a world of continuous disruption, this is no longer possible. That’s why we need Agile management tools like the Lean startup if we are to achieve future success.

    More Waste in Software Development

      
      
      

    Last week we explored how inventory and waiting, two of the original seven lean manufacturing wastes, have analogs in software development.

    This week we will explore two more, overproduction and transportation. As we will see, even though software development has fundamental differences with manufacturing we can use manufacturing as a metaphor that helps us open our minds about what constitutes waste in knowledge work such as software development.


    • Overproduction. Overproduction is production ahead of demand. For example, saleable units waiting in warehouses for buyers are overproduction waste. As is the case with WIP, overproduction increases the risk of obsolescence. 
    Overproduction in software development. Since the model for software use is that one unit (i.e. one release) is shared by many users (even more so in SAAS environments) and the physical material cost of a software unit is minimal, overproduction is not expressed as producing product units in excess of demand. Rather, overproduction in software development occurs when we build features that are either never or rarely used or that are deployed prematurely.
    • Transportation. Transportation waste is the movement of materials and goods that is not actually required to perform the processing. It also includes damage to materials and goods that are the result of transportation.
    Over-production in software development

    Requirements "lost in translation"

    Transport in software development. Since software comprises information electronically stored and accessed, the physical transport of materials or finished goods is of little concern. However, there is the analogous waste of translating and handing off customer requirements through subsequent phases such as functional specifications, UML diagrams, source code, and tests. In addition, there is also information loss (or the introduction of noise) that damages the information just as finished goods and materials are sometimes damaged through transportation.

    I would love to hear your ideas about waste in software development.



    White paper: When you're Agile you get Lean


    If you're interested in this topic,
    please take a look at our new white paper:
    When you're Agile, you get Lean.




     

    Waste in Software Development

      
      
      

    In the first in a 5-part series that explores how Lean principles are applied through the practice of Agile, we discussed how the differences between Lean and Agile in software development are more about when particular practices might be best applied under particular conditions and less about how the two approaches are fundamentally different. In fact, Agile and Lean hold many guiding principles in common.

    In this second installment, we will explore examples of what might qualify as Lean waste in software development.


    The seven kinds of waste, as first outlined by Taiicho Ohno, provides a framework to identify and remove waste from manufacturing. Although software development and manufacturing differ in important ways, once you start looking for the counterparts of manufacturing waste in software development, it's surprising sometimes how easy they are to find. Here we will review two of the original wastes, Inventory and Waiting.

    • Inventory. Inventory includes all parts and materials that have been purchased and are waiting to be used. It also includes work-in-process (WIP). WIP is everything that is being worked on that is not yet ready for shipment or sale. Inventory and WIP lead to waste because by definition they tie up resources that are not yet able to generate a return. In addition, the greater the inventory, the greater the risk of obsolescence, loss, and write off.

    Inventory in software development. In knowledge work such as software development, we can think of inventory as being maintained in documentation and in non-deployed software. Software work-in-process (WIP) is all activity (and therefore expense) subsequent to business case approval but preceding deployment to production. This includes requirements documents, project plans, functional and design specifications, source code, test plans, and tests, plus the time to create these artifacts. If a project is a year or more in duration, WIP continues to build up over the entire period prior to production use. WIP is also tantamount to the accumulation of write-off risk for software investments because if the project ends prematurely or never is delivered, no business value is generated and the WIP investment is lost.

    • Waterfall software project WIPWaiting. Waiting is the delay between steps in production. If an order comes in the mail and sits in a mailbox, that is the waste of waiting. If an item is assembled, the delay before it is packaged is the waste of waiting.

    Waiting in software development. Examples include waiting for milestone and change request approvals and sign-offs, waiting for clarifications and elaborations from sponsors and analysts, waiting for builds and testing to complete, waiting for your turn in meetings and conference calls, waiting for deployment schedules and architectural and code reviews. Any elapsed time in excess of what is needed to execute the added value step is a form of waiting. Looked at in that manner, even the most efficient operations still have much waiting, in principle, leaving plenty of opportunity for future improvements.

    If you have additional examples of waste in software development, I would love to hear about them.




    White paper: When you're Agile you get Lean


    If you're interested in this topic,
    please take a look at our new white paper:
    When you're Agile, you get Lean.

     



     

    Agile vs. Lean: False Debate?

      
      
      

    Ever since Mary and Tom Poppendiek wrote their book Lean Software Development: An Agile Toolkit, there has been a lot of discussion about Lean and Agile in the world of software development. Sometimes we hear about how Agile and Lean are different and sometimes we hear about how they are the same.

    The conversation about how they are different includes discussions such as:

    • Why Kanban is better than Scrum (or not), or
    • Why Lean is better at scale than Scrum, etc.

    The conversation about how they are the same includes discussions such as:

    • How iterative development reduces work in process (WIP), or
    • How Scrum’s dynamic product backlog and user stories facilitate just-in-time requirements.

    It can tricky trying to sort out from these discussions what you should do, particularly for managers who are committed to and may be responsible for the success of their organizations.

    One way to begin integrating these two conversations is to recognize that the conversation about how Agile and Lean are different is usually conducted at a different level of analysis than the conversation about they are similar. The differences are usually discussed at the level of practices, whereas similarities are discussed at a lower level, the level of principles.

    Agile vs. Lean: A false debate?

    Since Agile and Lean share many of the same principles, we can say they share a common philosophy regarding the management of people and investments and how best to thrive in today’s business environment.

    Practices are how the principles are applied to do real work under specific conditions. One should expect that there are different practices to do similar things and, as the nature of the work changes one should also expect the nature of the practices to change but not the underlying principles

    We can now relate this back to our earlier examples. Whether or not Kanban or Scrum is the better practice to apply given specific operating conditions and constraints is a worthy debate. However, one should not expect to conclude that one is “wrong” and the other “right”, since both practices share many of the same principles. Furthermore, when one explains how iterative development reduces WIP, they are describing how the principle of (Lean) waste reduction is implemented in an Agile practice.  

    With this in mind, we can draw a couple of conclusions:

    • An understanding of common principles should guide the decision of which practices should be used and when.
    • As team capabilities and the nature of work changes one should expect practices to be refined and replaced.



    White paper: When you're Agile you get Lean


    If you're interested in this topic,
    please take a look at our new white paper:
    When you're Agile, you get Lean.

     



     

    All Posts