One of the key parts of Agile Software Development is the concept of iterative and incremental development (IID). I here people say this frequently – but when I ask more specific questions I hear things like, “We we develop small chunks and we have two week iterations.” We there is an entire group of Agile methods becoming mainstream that are iteration-less – instead they follow a continuous flow model. So if Agile requires IID, and Lean and Kanban are iteration-less, does that mean they aren’t Agile. Well, no, because iterative development doesn’t mean you are doing iterations.

In incremental development various parts of the system are developed at different times or rates, and integrated as they are completed. You can do this in a waterfall project or an iterative project. The alternative to incremental development is to develop the entire system with a “big bang” integration.

In iterative development the team plans to iterate, or go back over parts of the system, to revise and improve the system. In iterative development testing and/or user feedback is used to revise the targets of the successive deliverables. You don’t have to have iterations to be doing iterative development. The practice of iterations arises from a desire to coordinate feedback from increments with revising a future deliverable. Iterative and Incremental Development work well together. A hard stop, or a time-boxed iteration, has historically been useful to coordinate feedback with deliverables.

One of the powerful and interesting things that has happened in the last decade in software development is Continuous Integration. This is a practice that arose from Martin Fowler and Kent Beck in the Extreme Programming community. Continuous Integration means we can deliver increments of software at any time. I have worked with a team whose continuous integration environment was so robust they were prepared to responsibly deliver updates to production several times a day. When you can continually deliver working software then you can eliminate the hard stop. Just perform the user feedback of the application whenever it makes sense. You can use this feedback to revise the successive deliverables without creating a hard top for everyone on the team.

No iterations in IID?

There are several benefits of going iteration-less. A big benefit of single piece flow is not stopping the entire team every week or two weeks. Reducing batching to a single item results in an increase in the amount of time development can be focused on writing code. For example, if the entire team has to stop for two days (one for delivery one for planning) every two weeks, you are effectively eliminating 20% of the time developers can work. A second benefit of going iteration-less is the elimination of an artificial constraint that an item must be small enough to fit into the time-box. While it is always better to deliver small pieces at a time – value cannot always be shaped into the time-box. A third benefit of going iteration-less is that demand on related resources has a smoother pattern. Time-boxes batch related work such as testing, requirements grooming, and deployment. The pace is more sustainable for the non-development resources.

There are several drawbacks to going iteration-less if the team doesn’t address them. First there can be challenges with coordinating feedback into successive deliverables. If the developers just keep writing code – when do we update the backlog with the input we would historically receive at the iteration review. Also, since there is no time-box, there is also a perceived lack of pressure to get to done. Additionally, by not enforcing effective decomposition there can be a lack of pressure to design well. Also, there isn’t a fixed time to stop and review the development processes to keep the team in synch. Finally, continuous delivery can result in continuous demand on related resources like analysts and quality assurance.

There are effective strategies for dealing with each of these drawbacks. For example, the developers that just delivered a feature can stop to get feedback from the customer without disrupting the entire team. You can create visibility into delays by tracking the days of effort against each story as it moves across the board – which will result in pressure to get to done. Enforcing norms that work must be small enough to get through in less than two weeks – but allowing for exceptions when it makes sense to the team will help ensure good design. You don’t have to come to a hard stop on everything in process to do a team retrospective (operations review). Finally, the related resources timing can be decoupled from the teams cadence. For example, business analysts can still groom backlog in weekly batches to create some buffer.

History if IID

One of the interesting things for many current agilists to understand is that we have been doing IID in software development since the late 50’s – that’s right – half a century. Here are some highlights.

1957: Gerald Weinberg runs a project at IBM using IID practices.

1960: Gerald Weinberg starts teaching IID at the IBM System’s Research Intitute

1969: Robert Glass published a paper on current practices in IID in ACM Computer Surveys

1975: Vic Gasill and Albert Turner publish Iterative Enhancement: A Practical Technique for Software Deveopment in IEEE Transactions on Software Engineering

1980: Gerald Weinberg publishes Adaptive Programming: The New Religion

1984: Tom Gilb recommends two week iterations as a best practice

1985: Barry Boehm promotes the spiral model – using risk as the key prioritization method

1986: Fred Brooks publishes No Silver Bullet which articulates the benefits of IID over waterfall

1988: Tom Gilb publishes Principles of Software Engineering Management showing an evolutionary approach to development

1990’s: Scrum, DSDM, RUP, XP, and FDD all become mature practices

It is just in this decade, fueled by improved development tools, lower cost computing and network, and in response to pressure to rapidly deliver solutions with a high level of unknowns that IID, in the form of Agile methods, has become common place.

I have an interesting paradox I have been listening to in the Agile community. On the one hand the craftsmanship discussions resonate with me. After years of experience, apprenticeship, and study one can develop the art and craft of being a great developer. There were points in my life where I have experienced this – in the 80’s with RPG (laugh if you want to) and in the early-mid 90’s with C++.  I was a craftsman of both languages. Since then I have worked with real craftsman – and have established the craft involved in helping development teams perform above their own expectations.

On the other hand, I hear talk of cross functional teams. How the developers should be involved in all aspects of deciding what the product is, how to run the project, where the market is going, how to best optimize profit in an industry, and how to position and sell the product.

And this is paradox. Some developers believe that there is a craft that takes years to develop to what they do. But they don’t recognize craft in enterprise analysis, project management, product management, market analysis, or sales and marketing. I believe this to be a common form of social bias that intelligent people are particularly prone to. The belief that what one person does is very complicated – but that what other people do is very easy.

I had a meeting once with the CFO, COO, CIO, and head of HR. They were having a debate. Each executive was relatively limited in realizing the complexity of the other’s job. At one point, the CFO was telling the CIO how he should run the support organization. The CFO was coming from a simplistic and limited view. I mentioned to the team I had some ideas about how the business should handle non-performing assets from the recent spate of acquisitions. The CFO asked me what I was doing – that there was no way I understood the complexity of his domain. I smiled and told him that since he was directing the technology team without a clear understanding – I was ready to direct the accounting operations on behalf of the the CIO. Luckily, I had established enough trust that the CFO thought about it and laughed. He realized that what appears simple on the outside is difficult when you get down to brass tacks.

So, while I believe that co-locating teams is important to successful teams – and I believe that we need to generate a shared understanding across everyone involved in the project. I also believe that in many jobs there are fine details that separate the very competent from the capable. There is room for specialization in most jobs in the product development organization. But, when we try to push to far in the direction of the generalizing specialist we get dilution across the board.

I have been reading a lot about of the recent group discussions and papers regarding Kanban and Lean Software Development. One of the things I have noticed is that there is not a consistent application of the concepts regarding time. One of the reasons we establish a body of knowledge is to create a common language that helps us communicate based on a shared understanding. This inconsistency in the use of terms around time create a gap in understanding. In an effort to help the conversation here are the appropriate definitions for each type of time.

Durations

Duration is simply a measure of elapsed time.

Lead Time: The average time it takes for one unit to go through the entire process – from start to finish – including time waiting between sub-processes. Lead time can take different perspectives.

Development Lead Time is the time it takes for a unit to go through development from release from the backlog until it is done (which includes analysis, development, test, acceptance, deployment – but maybe not release to production). It is interesting to the development manager.

Order Lead Time is the time that elapses between when the customer places an order and when the customer receives what they ordered. In cases where requests are queued in a back log and releases are decoupled from development completion this can be far longer than the Development Lead Time. This is interesting to customer.

Order to Cash Lead Time is the time from when the customer places the order to the time cash is received by the business. While this is often longer than the Order Lead Time it can be shorter than the Order Lead Time when the customer prepays. This is interesting to the person paying the bills.

Process Lead Time: The time the unit is being worked on in a specific process before it is passed on to the next process. For example, within Development Lead Time this could be analysis, development, automated test, acceptance test or deployment time. This is interesting to the person performing the specific process or activity.

Processing Time: The time the unit is actually being worked on. It would be the sum of all the Process Lead Times. This is interesting to use as we try to improve our Lead Time.

Value Add Time: The Processing Time spent on a unit that transforms the unit in a way that the customer is willing to pay for. Not all Processing Time is Value Add Time – although non-Value Add Time can be necessary due to compliance requirements, to optimize performance of value add resources, and to minimize rework. This is interesting as it has been the subject of much of the lightweight process effort in Agile development. When taken to far it results in increased Rework Time and increased Process Lead Time.

Rework Time: The Processing Time that results from poor quality.  Failure Demand is the amount of resource that is consumed by Rework Time. This is interesting as it is expensive.

Queue Time: The time a unit sits between sub-processes waiting for someone to work on it. This is interesting to us as we try to improve our Lead Time. This is no cost to improving flow to reduce Queue Time but it reduces Lead Time.

Cadences

Cadence is a measure of time per unit.

Cycle Time: The average time between units coming out the end of the pipe. This is interesting because it helps us predict Lead Time.

Takt Time: How often units need to come out the end of the pipe to meet customer demand. This is interesting because it reflects the rate we need to produce to optimize investment against revenue.

You would expect Lead Time to be the sum of Processing Time, Queue Time, and Rework Time – and it is in a purely serial process flow. But in cases where work moves in parallel the sum of Processing Time, Queue Time and Rework Time will be greater than the Lead Time. Lead Time is interesting because it is what we use to make commitments.  Improving Lead Time can be done by reducing Queue Time, shortening Process Lead Time, eliminating Rework Time, minimizing non-Value Add Time, and performing processes in parallel.

The concept of Value Add Time is interesting and has had strong impact on Agile processes. At some point things like documentation, planning, testing, and adding additional features are not adding value in a way the customer is willing to pay for. Reducing these items to the bare minimum time that is necessary to meet the needs of the customer is helpful. Reducing them to the point they increase rework or reduce the productivity of the value added performers is not helpful.

The biggest inconsistency I have noticed is the improper use of Lead Time (a duration), Cycle Time (a cadence), and Takt Time (a cadence). In summary, Lead Time is how long it takes us to build and deliver it, Cycle Time is how often a new one is produced, and Takt Time is the rate of customer demand. In a stable system, Duration and Cadence are related by Little’s Law. The cadence of Cycle Time will equal WIP divided by the duration of Lead Time.

I believe that consistent use of these terms will help us have more meaningful conversations and continue to improve the ways that we deliver software to our customers. Part of my focus over the last decade has been on reducing Lead Time through reducing WIP, Queue Time, and non-Value Add Time, improving quality to reduce Rework Time, and improving architecture, automation, and shared understanding to reduce Processing Time. Having a shared understanding for each type of time leads to productive conversations around specific techniques and improves the teams ability to focus on the right types of improvements.

There is a nice summary of Kanban at http://www.kanbandistilled.com/. It shows Feature Requests going into the Software Development Pipeline and Improved Software coming out.The article does a great job of showing how Kanban helps improve the flow of software development. Getting better at software development is important and Agile methods have been helping teams achive this goal. This is the first bargain of Agile-delivering software faster and with much higher quality then ever before. In most organizations however, this is only a small part of the business equation. Even when development is successful, a narrow focus on software  development narrows the value an organization will achieve. We also need to align of development with the most important needs of the business, balance development with adoption, and ensure improved business performance is achieved.

Feeding the Software Development Pipeline

Unless a company is a software development service provider, its business is not about software development. Software likely enhances the businesses ability to create value for it’s customers. So, while Agile development helps teams get better at software development – the goal is to get better at creating value for it’s customers. The focus of Agile software development is upside down. The focus should be on the capabilities of the business. Aligning development with the needs of the business requires understanding  which business capabilities will benefit from improvement and prioritizing these needs based on business value.

After using a business capability approach to need identification and prioritization, the business needs must be appropriately scoped and communicated to development. Over the last month I have been writing about Making Agile Requirements Work. need to make sure the requests that go into the Software Development Pipeline are clear and appropriately defined. Following the six principles of Agile Requirements That Work help with this feeding of the Software Development Pipeline.

1. Articulate Purpose and Outcome
2. Establish a Shared Language
3. Provide a Stable View of the Business
4. Support Progressive Elaboration
5. Testable
6. Prioritized and Reflect Business Value and Risk

Gaining Business Benefit

The other part of the equation is to ensure the organization adopts and supports the improved software. Once the Software Development Pipeline has produced Improved Software, it still isn’t valuable until the Business Capability has achieved the intended performance improvement. Just as the elicitation and analysis of requirements has to match the cadence and needs of Software Development. Software Development has to match the cadence and needs of the organizations ability to adopt and support Improved Software. Part of the overall feedback to the organization includes ensuring the capability improvement is achieved.

Risk

At every step in this equation different risks may exist. identifying, prioritizing, and scoping feature requests have risk associated with a lack of understanding. Software Development has risk associated with the Ability to Execute and Verify the delivered software. Benefit realization has risks associated with achieving adoption and being able to sustain and support change in the organization. These risks should be explicitly managed and feedback mechanisms should be in place to recognize the realization of risks. Failing to understand and manage risks in an integrated fashion will also diminish the organization’s ability to maximize benefit from it’s investment.

The Real Agile Bargain

The real agile bargain is the maximizing of economic outcomes by increasing the speed and focus an organization can improve and respond to the market. The Agile Business Value Equation is solved at the Business Capability Level. The ability to rapidly develop high quality software moves Technology from a change obstacle to become an change enabler. This happens at the intersection of Feeding the Software Development Pipeline, Developing the Software, and Gaining Business Benefit. Solving any of these parts independent of each other does not result in optimizing business agility.

The Gilb’s have started a series of posts against Agile. The first on is Wrong Focus.

“It is not about working software. It is not about your preferred working process. It is not about user stories. It is not only about your customer or user. It is all about delivering, to your set of Stakeholders, value improvements to them, to what they care about, what makes their world better, within agreeable, minimum or pre-determined costs. If that is not the main focus, if that is not clear to everyone on the team, you will eventually loose! If your methods are not focusing on delivering that value, as todays most popular Agile methods are not, they will fail to deliver, they will become last years fad.”

They claim Agile software development is flawed because it focuses on improving the process and environment of the team developing software. These improvements result in improved customer collaboration that ensures the team better understands what the customer wants. From my experience, the combination of improved environment, appropriately sized process, and customer collaboration results in mature agile teams doing a great job of delivering the projects and products. But I understand their point. There is a difference between understanding the customer and focusing on delivering customer value.

Wrong Focus

Whether the software development organization is building software for external clients or to enable the organization’s business processes, there are always more things that can validly be improved than there are resources to do the work. Not all of the improvements will result in the same return of business value to the overall organization. Some benefits are more valuable to the organization than others. If you don’t pick the one that is most valuable to the business it is not the right investment for the business. In any of these improvements, there is more improving that is valid than is necessary to achieve the benefit. If the team works on improvements that aren’t the focus of the effort, “while they are there”,  they are not focusing on business value. This delays delivery of the effort and is not the right investment for the business.

Nothing in the Agile Manifesto, nor most of the Agile methods, give the tools to pick the right improvements to focus on. They also create an environment where it is extremely likely to work on more then is the minimum necessary to achieve the targeted business benefit. In many organizations, close customer collaboration can lead to “gold-plating” of features. If you offer the customer whatever they want – they will ask for it.

Wrong Focus in Practice

I have a customer right now that is going to build some software to support their field employees. The business goal is to achieve a significant cost reduction in the field through improving quality and efficiency in the field. The developers are extremely interested in developing mobile applications, distributed collaboration, GPS interfaces, image capture and markup, mapping, barcode, and training training. They have started a new business to build this product with the hope of selling it outside the business in the future. The challenge here is how do they clearly identify those improvements in the field and in dispatching that will deliver the significant reduction in field expense. If they go and and talk to the dispatchers they might find 30 things that could be done better. All of these improvements would result in an improvement in work conditions or performance. But they may not be aligned with the current business focus. The same will happen in the field.

Just because it will improve satisfaction or make someone’s job easier doesn’t mean it will help with the current business focus. How do they align absolutely the minimum amount of technology to deliver on these improvements? Especially when their interests are in this bigger, more robust solution. Especially when this limiting of features is not in line with their future business objectives. Nothing in Agile addresses how to deal with this conflict.

Where’s the Answer

I address this in Feeding the Agile Beast. This is the domain of Business Analysis. As the Gilb’s point out, most Agile methods abstract this from the team. They focus on improving their processes and collaboration. In Scrum, Business Analysis is abstracted behind the Product Owner. In XP, it is abstracted behind the Onsite Customer. I don’t agree with the implication from the Gilb’s that this abstraction is a deficiency in Agile. It is just outside the scope. I also don’t agree with Agile teams that close collaboration with the customer is sufficient to ensure business value is achieved. This is not an OR conversation. This needs to be handled as an AND conversation. This is the next thing we need to learn – how to keep an Agile team laser focused on business value AND maintain the benefits of understanding the customer that comes with Agile software development.

The problem with many current methods of Elicit Requirements on software development projects is that they don’t add economic value to the solution effort. Many projects develop unrealistically detailed requirements in large batches up front. Due to the impossibility of accurately defining exactly what the effort requires they aren’t completely useful. In addition to resulting in churn and rework they require a high level of effort to maintain. In response to problems with Big Up-front Elicitation efforts some projects have resorted to “too little” requirement definition up front. This also results in expensive churn and a lack of project focus that delays the time to value. In both cases the transaction costs associated with producing and maintaining the documents offset any value they might bring.

The How Trap

The How Trap is a very human condition. If you see someone at the fax machine and ask them what they are doing, they will say “Sending a Fax”. That isn’t what they are doing though. That is “how” they are doing something – not what they are doing. The How Trap is very common. Ric Merrifield, in his book Re-Th!nk: A Business Manifesto for Cost Cutting and Innovation talks about Dick Fosbury and the Fosbury Flop. Dick Fosbury realized the How of the high jump was to go as high as possible and abandoned trying to perfect any of the existing techniques that involved jumping over the bar so you could land on your feet. His focus on the What of jumping as high as possible led him to jump over it backwards and land on his back. His gold medal in the 1968 Summer Olympics pointed out the wisdom of his approach. When requirements are elicited on a How-Trap basis assumptions are made that limit options that should be considered to accomplish the goal of the effort.

To avoid the how trap elicit requirements based on outcomes and purposes. Avoid getting trapped in How specific language. You can be pretty specific about the purpose or outcome without falling into non-productive detail. For example, the outcomes and purposes associated with Pay Employees doesn’t change much regardless of the implementation. People need to be paid a specific amount, there are specific tax requirements, and there are clear governance and compliance needs. These don’t change whether Pay Employees is outsourced, done manually, or automated internally.

Remember Fosbury’s goal was not to jump higher it was to clear the bar at its highest point. Sending a fax is never the requirement. It is something like Communicate Status or Confirm Order. This is a subtle distinction but frees up the team to apply their creativity to the How and will lead to significantly different outcomes.

This is the final post in my review of the impact of Agile on the tasks within the knowledge areas of the BABOK®.  There are some interesting findings from this exercise. The implications are that while some business analysis tasks are performed within the development team, the business analyst role itself is more strategic and challenging on agile projects. A clear understanding of the BABOK tasks and how they should be addressed on Agile projects will dramatically increase your ability to deliver value through Agile projects.

So, What’s New?

First off, the business analysis tasks are not just aimed at documenting requirements. There are three primary targets of analysis activities. Many tasks address the features of the product. These are aimed ensuring requirements are elicited, communicated, and the solution is verified. There are business analysis tasks aimed at understanding organizational readiness and transition requirements. Finally, there are business analysis tasks aimed at understanding and improving the ability of the organization to develop and deliver the solution.

Secondly, all the tasks are still necessary. However, unlike a traditional project, where many of the analysis tasks are performed up front, they are performed continuously throughout the project. The requirements for the solution, the ability to deliver, and the readiness of the organization are evaluated incrementally throughout the project and the approach is adapted to improve fit and performance.

Finally, the understanding of requirements, organizational readiness, and development capabilities is progressively elaborated throughout the project.  In Agile, the development team itself performs detailed business analysis activities within the development iterations. The business analyst continues to operate in front of and after the development efforts. Lightweight requirements documentation combined with an emerging understanding means the business analyst become an advocate for the product. They collaborate with the team to ensure a shared understanding unfolds. The business analyst also facilitates the understanding and implementation of improvements in the business analysis and organizational readiness processes.

Summary of Business Analysis Knowledge Areas

Business Analysis Planning and Monitoring.  The tasks in this knowledge area are still primarily performed on the front end. The team will agree on the approach it will take in business analysis tasks. This means agreeing on who and how. All the task purposes in the BABOK still need to be planned – but planned to support the cadence of the team and the emergence of understanding through the project. The way the business analysis tasks are performed are not cast in stone, they will be updated through inspection and adaptation throughout the life of the project.

Elicitation. This knowledge area occurs continuously in a progressive fashion and responsibility for the product requirements changes hands during each iteration.  These hand-offs associated with the various levels of elicitation can contribute to lost knowledge and increased transaction costs.  An approach that ensures continuity of understanding is critical.

Requirements Management and Communication. The existence of Requirements Management and Communication in a single Knowledge Area demonstrates the closely held traditional belief that documenting and tracking something is the best way to communicate it. It is important that the method of documenting requirements at the higher level is lightweight while still facilitating understanding, focus and priority. In Agile projects, communication should be viewed as completely distinct tasks. At the detailed levels, there is a transfer of context, purposes, and outcomes requirements that is best performed through conversation between the customer and the development team.

Enterprise Analysis. The business analyst will still carry primary responsibility for understanding organizational readiness, transition requirements, and solution verification.  They will need to communicate findings from releases back into transition requirements to improve release performance. Gaps in the fit of the solution will feed back into the requirements backlog. Enterprise Analysis is very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value.

Solution Assessment and Validation. These tasks happen continuously in a progressive fashion. The Big Solution Architecture will still be developed with input from the Business Analyst as well as Architects. The Business Analyst will need to understand and address the impact that progressive elaboration has on the transition requirements.

Requirements Analysis. Prioritization and organization of requirements happens as part of backlog prioritization. The business analyst should make sure that business value concerns and risks associated with assumptions and constraints are clearly understood here. Like Enterprise Analysis these tasks are very strategic, often outside the scope of the typical Agile development team (presumed to be understood by the Product Owner), and are critical to the team’s ability to burn down risk early and get to business value fast.

Missing Tasks

I believe there are at least three areas regarding business analysis on Agile projects that are not addressed by the BABOK.

Enrolling Stakeholders involves making sure everyone understands how they will participate. Just documenting a process or developing some templates don’t ensure appropriate engagement.  Stakeholders may play a role making sure shared understanding of the product requirements exists, they may be responsible for development process feedback, or they may need to participate in the transition of the solution.

Understanding Requirements is the new task or set of tasks that deal with generating the shared understanding of context, purpose, and outcome that is necessary for successful projects. Since the understanding of what is being developed and how it is being developed will emerge over the course of the project specific tasks must be in place to establish this shared understanding.  This may sound like a subtle extension of communicate requirements but this is social in nature and is fundamentally different than the push of communicating requirements.

Organizational Learning extends Enterprise Analysis. Not only does the readiness of the organization to use the product need to be reviewed, the ability to develop, deliver, and support the product needs to be evaluated. This task includes the introspection, retrospectives, operations reviews, and outside review of best practices that the organization performs to improve its ability to use and deliver solutions.

Agile Business Analysis Summary

The common concept that Business Analyst’s add no value to Agile projects is flawed. It is true that some of the detailed business analysis activities will be best served through direct interaction between developer’s and the customer. The high level planning and coordination around these direct interactions should not be abandoned but should be managed to facilitate focus on business value and shared understanding while minimizing transaction costs.

Additionally, there are many critical business analysis tasks outside the scope of the development team. Particularly, the tasks involving Solution Validation, Enterprise Analysis, and the inputs to Requirements Analysis are very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value. A clear understanding of the tasks and purposes in the BABOK® demonstrates the strategic nature of Business Analysis tasks, highlights where the tasks should be performed within the Agile development team, and will increase the ability of the development team to achieve its objective of rapid delivery customer value.

Today I am discussing the tasks from the BABOK® associated with Requirements Analysis. These are the tasks to organize, prioritize, and model requirements and risks. There are six tasks associated with Requirements Analysis. I show the BABOK purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

Prioritize Requirements

Organize Requirements

Specify and Model Requirements

Define Assumptions and Constraints

Verify Requirements

Validate Requirements

Agile Requirements Analysis
All of the tasks in Requirements Analysis are important on Agile projects. The primary distinction in this Knowledge area is the support for the emergence of the solution over time. Particularly interesting is Define Assumptions and Constraints. While many Agile teams focus on the impediments to delivering code, they fail to manage the bigger risks and constraints associated with getting to business value.

This post is going to go back over the past month’s posts and bring them together into a model I can use to discuss Big Agile. I took me a while to noodle this out so I haven’t posted in over a week. This approach is based on over two decades of improving performance in development organizations. The last decade has been spent working to explicitly articulate what I’ve done to consistently deliver results. It is amazing how much you learn when you take concepts practiced unconsciously and write them in a (relatively) concise format.

Enterprise Agility

Many companies are dependent on technology to be competitive. Either because they deliver technology as their product or because technology enables the processes they depend on. For those companies it is important to be able to operate faster than their competition.  This requires not only the ability to rapidly deliver technology – but the ability to adapt their organization.  This is the concept of operating within your competitors decision cycle. The model I use to demonstrate this concept is John Boyd’s O-O-D-A model.

This is Enterprise Agility, when the enterprise has learned to leverage technology and change management to develop an energized workforce frequently delivering value that meets the emerging needs of the customer.

Three Concepts for Achieving the Agile Enterprise

I am going to build on three concepts in showing how to build Enterprise Agility.

1. Theory of Constraints. You can’t get there all at once. It is necessary to decide where to focus. You have to develop the underlying capabilities from the bottom up. If you can’t produce quality product, the best ideas in the world will run into problems. The way of thinking about problems covered in the management system the Theory of Constraints provides the method for deciding where to focus. Identify the current constraint, get the most out of the capability that is the constraint, subordinate the system to the constraint, elevate the constraint, and then continue to pursue this cycle. This “Process of On-Going Improvement” is applied to the flow of value to the customer.

2. Creative Solution Finding. Once we understand where to change we need to understand what to change to. We have to apply a method to lead the overall adoption effort that supports aligning the capabilities with the overall goals of the organization. The stages of Creative Solution Finding are useful for identifying the situation specific approach to developing this road-map. There is no magic sauce for developing this road-map. By applying the seven principles, along with a knowledge of applicable best practices, a useful road-map that fits both the process and social context of the Enterprise can be developed.

3. The Learning Organization. Technology development efforts are knowledge based efforts. As such, they are performed through a social construct. To improve the performance of software development we have to not only improve the methods of development, we have to improve the performance of the social construct. First the individuals on the team must be willing to change. While the People Design principle in Creative Solution Finding will help prepare individuals for change, their personal fears and concerns must also be addressed. Once the constraint is identified and a road-map for improvement is developed, the learning organization concepts in the Fifth Discipline are relevant. The right individual competencies must be developed on the team to do the job (Personal Mastery and Mental Models).  The team has to be functioning well together (Shared Vision and Team Learning).  And the Team has to be functioning in a way that is aligned with the goal of the overall system (Systems Thinking).  The primary tool used to influence a social construct to create change and to improve performance is the conversation.

Discussing Big Agile

So the approach is to take the Big Agile capabilities, (1) provide insight to identify when a specific set of capabilities at a level of scaling are the current constraint, (2) leverage the solution finding model and best practices to define/refine the roadmap to move toward,  (3) and then identify the competencies to develop and conversations that are necessary to execute the change.  Then continue the cycle continuously.

This is the Big Agile improvement approach. It takes a model that I have been applying for two decades implicitly and evolving explicitly for the last decade. Clear direction combined with appropriate best practices and an effective adoption approach. All that’s left now is to build out the details of the capabilities, when they are a constraint, how to select appropriate best practices, and the conversations and change approach at each level of scaling for the model.

One of the hot topics at Agile 2009 was scaling agile and the Agile Enterprise. As we work toward a book on Big Agile:  Incremental strategies for Enterprise Agile adoption I want to establish a clear definition on what I mean by enterprise Agile adoption and what the Agile Enterprise is.

First off, The Agile Manifesto really applies to software development. Small Team Agile is about getting teams together to develop software in a way that meets certain criteria. Agile teams operate as a healthy team and they reliably deliver a continual stream of high-quality valuable software. Valuable means that it serves some purpose for the customer. There are engineering practices, management practices, and leadership practices that combine together to enable Agile teams to be successful. A key benefit of Agile teams is that you can produce the most valuable features first, and continue to invest until the economic value of the code has been realized. Agile teams are different then most traditional software development teams because of the focus on small incremental delivery of always releasable code and the focus on pushing decision rights down to (empowering) the team.

Scaling Agile

I believe there are four distinct levels of Agile adoption. This is not four maturity levels. It is distinct levels where the engineering, management, and leadership capabilities express themselves differently to support the expanding context. In most organizations the scaling will not be linear – it will be implemented across these levels of scaling based on the needs of the business.

Horizontal Scaling is the first level of scaling. This is the ability to get multiple teams to deliver a continual stream of high-quality valuable software. What happens when you begin to have the ability to spread Agile across teams is you begin to have the ability to strike a new bargain with the business. You can help product management interface with the business and customers in a new way where you can be responsive to individual customer requirements and changes in preferences in the market.

First Order Scaling is where multiple teams are coordinated across a common project or product. Once you have teams reliably performing, a new level of coordination arises. Your constraint is no longer in the pace of development. New opportunities to exploit speed and responsiveness arise across product development are possible. Taking advantage of these new opportunities requires the engineering, management, and leadership practices to be expressed in new ways. For example, Architecture becomes more important from a common perspective. Agile, this raises the ability to strike new bargains with the customer. Complex projects can be developed in a more responsive fashion.

Second Order Scaling is where multiple teams are coordinated across multiple projects and products. This is where you may begin to see economic benefits from reuse across products. The new bargain you strike with the business is now at the portfolio level. The business can be more flexible in investment into products and projects and then shift to other efforts when the economic benefit has been maximized.

Third Order Scaling (the Agile Enteprise) is where the Agile Enterprise exists. This is where the business leverages the ability to continually deliver high quality valuable products beyond the product development effort. New bargains can be struck in Customer Service, Sales and Marketing, Invoicing, and every customer facing part of the business. Faster learning from the market, customer preferences, and other environmental inputs is leveraged to rapidly produce products that profitably adapt to what we learn.  Other internal functions are also impacted. In fact, third order scaling often comes into play in even Small Team Agile. Once you can benefit from (or have to take into account) making changes to the way value is delivered to your customer beyond the product development organization, you need to think about Third Order Scaling.

Big Agile and Orders of Scaling

Scaling Agile has different meanings depending on the respective scale. From effective small teams, to reliable small team adoption, through products, portfolio’s to the organization -the focus is on achieving scale appropriate outcomes and purposes while maintaining focused value creation at the Agile team level. You can’t execute an Agile strategy from the top if you can’t first operate in a reliable agile fashion at the small team level.