What’s the Difference Between Anarchy and Self-Organizing Teams?

What’s the difference between anarchy and self-organizing teams? The Merriam-Webster dictionary defines “Anarchy” as:

  • a state of lawlessness or political disorder due to the absence of governmental authority
  • a utopian society of individuals who enjoy complete freedom without government
  • absence or denial of any authority or established order

Wikipedia defines “self-organization” as follows:

Self-organization is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.”

However, that doesn’t mean that self-organizing teams are given a blank check to do whatever they want to do without any higher-level direction and it also doesn’t mean that self-organizing teams should not be held accountable for their actions. The team needs to earn the right to be self-organizing by proving that they are responsible about making and keeping commitments – that’s an essential part of self-organization and one of the key things that distinguishes self-organization from “anarchy”. It would be irresponsible for any manager to rely on a team to be self-organizing if the team doesn’t hold themselves accountable for meeting commitments.

Reliance on self-organizing teams is a very powerful and very important concept in Agile and, if it is done correctly, it can have a huge impact on the whole company. As an example, Valpak, is one of the successful case studies in my book and one of the significant differences Agile has made on their organization is due to self-organizing teams:

  • Prior to Agile, the company had to do a fair amount of management (as most companies do) to resolve individual and team performance issues
  • After Agile, those issues almost totally went away because the teams became self-organizing. If there was someone with a performance issue on the team, the team did not tolerate it and resolved it themselves.

The successful implementation of Agile and self-organizing teams at Valpak allowed their senior management team to focus on higher-level strategic issues much more than they had ever been able to do before because they were freed from managing so many day-to-day issues.

What are the attributes of a good, self-organizing team?

  • They understand and take responsibility for fulfilling the higher-level business direction of the company that they work for but no one has to micro-manage them to get it done.
  • No one needs to pressure them into making commitments – they make commitments eagerly, voluntarily, and responsibly.
  • They’re very clear and unambiguous about the commitments that they make
  • They take commitments seriously and have the integrity and self-discipline to take accountability for their actions and follow-through to make sure that any commitments they make are consistently met

Developing a highly effective, self-organizing team is not an easy thing to do and it can take time but its a very powerful component of Agile. There is also typically a balance between letting self-organization go too far and becoming an end in itself or turning into anarchy. Most companies do not exist totally for the benefit of the workers (that’s what socialism is and we all know how successful that is) so overall business direction and leadership is still important. What is needed; however, is visionary leadership, not micro-management.

What is Agile Functional Decomposition?

What is Agile functional decomposition? (and why is it important?) Investopedia defines “functional decomposition” as follows:

“A method of business analysis that dissects a complex business process to show its individual elements. Functional decomposition is used to facilitate the understanding and management of large and/or complex processes and can be used to help solve problems…Basically, functional decomposition takes something complicated and simplifies it. The individual elements of the process and their hierarchical relationship to each other are commonly displayed in a diagram called a functional decomposition diagram.”

Why is that relevant to Agile? Agile is about maximizing the business value that a project produces. On small, simple projects, you might be able to discover what that business value is easily based on direct face-to-face discussion with the Product Owner and individual stakeholders. On large enterprise-level projects, that may not be so easy to do. As an example, I was involved in a large project with about 500 user stories and we had to do some prioritization to move things out to a future release. It’s very difficult to do that on a project of that size without understanding the relationships among the stories if they’re not organized into some kind of functional hierarchy.

Using Agile functional decomposition to organize stories into epics and themes makes it possible to keep all of the stories well-aligned with producing the higher-level business value that the project is intended to produce and makes it a lot easier to effectively manage the Product Backlog. It also provides a capability for traceability – you can look at the top-level functionality and then look down into the functional decomposition to verify that the lower-level functionality is really complete and sufficient to support the higher-level functionality.

Functional decomposition has been around for years but many people don’t think it is relevant to Agile projects – it’s one of those traditional, plan-driven practices that many people seem to assume is now obsolete and no longer relevant with Agile, but I don’t believe that is the case. You don’t have to completely throw away all the traditional plan-driven practices you may have learned in order to practice Agile and some of those practices become especially important as you begin to try to scale Agile to an enterprise level…Functional Decomposition is an example.

The Importance of Systems Thinking and Agile

Understanding the importance of systems thinking and Agile is critical in order to gain a deeper understanding of Agile. Wikipedia defines “Systems Thinking as follows:

“Systems thinking is the process of understanding how things, regarded as systems, influence one another within a whole. In nature, systems thinking examples include ecosystems in which various elements such as air, water, movement, plants, and animals work together to survive or perish. In organizations, systems consist of people, structures, and processes that work together to make an organization “healthy” or “unhealthy”.”

Why is “Systems Thinking” important? It allows you to see things in an entirely different perspective:

  • You see the “whole” rather than the “pieces” and understand their relationship. In an agile implementation you see the business as a large ecosystem and see the development process as only one component of that ecosystem and you begin to better understand how the two are interrelated to each other.
  • Within an Agile development process, you begin to better understand how all the components of that process work together to make the overall process more effective and instead of following the process rigidly and mechanically, you see it as a much more dynamic process where each component of the process may need to be adjusted to fit the situation.

“Binary Thinking” is the antithesis of Systems Thinking. Instead of seeing the real complexity that is inherent in many situations, people who engage in binary thinking are sometimes looking for a simple, cause-effect explanation for something that isn’t really very simple at all. They:

  • Tend to see the Agile values and principles in “black-and-white” terms as absolute statements rather than relative statements that need to be interpreted in the context of the situation as they were intended to be.
  • See the relationship of Agile and more traditional plan-driven approaches as “either-or”, mutually exclusive choices (Either you’re Agile or you’re not) and they may see these approaches as competitive with each other rather than seeing them as potentially complementary.

That sort of narrow thinking has led to many stereotypes, myths, and misconceptions about what Agile is and also about what traditional Project Management is. We need to rethink what Agile is as well as rethink what traditional Project Management is to see them in a new light as potentially complementary rather than competitive approaches and “systems thinking” is the key to that. It is also the key to becoming a “learning organization”. Wikipedia defines a “learning organization as follows:

“A learning organization is the term given to a company that facilitates the learning of its members and continuously transforms itself. Learning organizations develop as a result of the pressures facing modern organizations and enables them to remain competitive in the business environment. A learning organization has five main features; systems thinking, personal mastery, mental models, shared vision and team learning. The Learning organization concept was coined through the work and research of Peter Senge and his colleagues (Senge, 1994). It encourages organizations to shift to a more interconnected way of thinking.”

Adopting a “systems thinking” approach and becoming a learning organization are two of the most important aspects of enterprise-level agility.

The Importance of Agile Project Governance

Do the words “Agile Project Governance” sound like they go together? On first glance, your answer might be “No” – the idea of superimposing a Project Governance Model on an Agile project sounds like mixing oil and vinegar, but I don’t believe that is necessarily the case especially when you attempt to scale an Agile project to large, complex enterprise-level projects.

Much of the wisdom about Agile has been about how to optimize the performance of an individual Agile team. There are hundreds of books about almost every aspect of optimizing Agile team performance that you can imagine but the idea of scaling Agile to enterprise-level projects is a road that is far less traveled and requires a lot of new thinking. In many cases, it requires blending together some plan-driven principles and practices with Agile principles and practices to create an overall governance model for large, complex programs consisting of multiple teams.

The predominant thinking in many cases seems to be that you have to shift the entire culture of a corporation to adapt it to an Agile development approach. My experience has been that is not necessarily the best approach in many situations. The culture of a company needs to be built around what makes sense for that company to be most successful in whatever business environment that it operates in and that is not always well-aligned with becoming totally Agile. An Agile culture works best in companies who are focused on product innovation such as companies who produce and sell software products like Intuit Quickbooks or where some form of product innovation is closely related to their primary business goals like Amazon.com.

In companies where product innovation is not the most important factor in the success of the business, it becomes a lot more difficult to convert a company to an Agile development approach because it may not make sense to force the company to adopt a culture that is totally Agile. Consider, for example, the following case studies from my new book:

  • Harvard Pilgrim Healthcare (HPHC) – HPHC’s business success is driven largely by customer satisfaction (they have been ranked number one in healthcare industry surveys for over nine years) and operational excellence (being able to process millions of healthcare transactions efficiently at a very low cost. They were faced with a requirement to do a massive redesign of all their operational systems that involved over 100 Agile teams over a five year period. Obviously, they can’t afford any disruption of customer service in that process and there are a lot of moving parts that need to be carefully coordinated to avoid any disruption of service to their customers.
  • General Dynamics, UK is a large defense contractor in Europe. Obviously, there business has to be geared around government contracting so there are limits on how Agile they can become, yet they were able to blend together some level of traditional plan-driven project/program management practices with an Agile development approach to achieve the right balance to fit their business.
  • Valpak is a very Agile company and fast-paced product innovation is much more critical to their business success. Valpak is the company that periodically sends you those blue envelopes stuffed with coupons. They have a huge processing facility in Tampa where paper comes in one end and millions of coupons stuffed in envelopes ready for mailing come out the other end and the whole operation is very highly automated. It is a very impressive operation and Valpak has been very successful in transforming their entire business using Dean Leffingwell’s Scaled Agile Framework.

The key point is that each of these three businesses is different and trying to use a “one size fits all” approach to force each business to adapt to a “textbook” agile development model would not have been the best solution. The right approach is to go in the other direction and fit the methodology (or combination of methodologies) to fit the business environment. It requires a lot more skill to do that but fortunately some frameworks and models are evolving to make that a lot easier to do. Dean Leffingwell’s Scaled Agile Framework
is only one example. My new book, Managed Agile Development – Making Agile Work for Your Business provides a lot more guidance on this topic.

What is an Agile Business Analyst? How is the Role Different?

Many software development projects are moving rapidly to an Agile development approach which has dramatically impacted the role of a project manager in an Agile environment.  Agile also has a significant impact on the role of a Business Analyst.  In this article, we will explore “What is an Agile Business Analyst?” and “How is the role different?”.

What is an Agile Business Analyst?

Traditional Business Analyst Role

The traditional role of a Business Analyst is defined as follows:

“The business analyst’s primary objective is helping businesses implement technology solutions in a cost-effective way by determining the requirements of a project or program, and communicating them clearly to stakeholders, facilitators and partners.” Business Analyst Job Description, Villanova Univ.

That’s the predominant role that has been played by Business Analysts for many years.  In some cases, it has boiled down to simply talking to users about what their needs are and writing requirements documents and it has become a very documentation-intensive role.  However, the real value-added that a Business Analyst should provide is in helping to define innovative solutions to business problems and not just simply creating requirements documents.  In a traditional plan-driven environment, documentation often takes on a life of its own and we lose sight of the fact that the goal is to create business value and documentation is only a by-product.

What Are the Skills Needed by a Business Analyst?

It’s useful to step back and look at the skills that a good Business Analyst needs to really provide value-added beyond simply writing requirements documents.   A Business Analyst has to have an understanding of:

  1. The Business Domain that they work in (finance, healthcare, manufacturing, or whatever else it might be). That means that the BA understands how that business operates, what the major business processes are, the metrics that are important to the business, and how to improve the processes from a business perspective
  2. Process Improvement Tools and Techniques – They need to understand how to use process improvement tools and techniques such as Six Sigma and others to analyze an existing business process and identify and define opportunities for improvement
  3. An IT Solutions perspective – they need to know how to translate that understanding of the business process improvement needs into IT solution requirements to create effective and innovative business solutions.
  4. A Project Process Understanding – Finally, they need to understand how an overall project development process works and how their role fits into that process so that they can work most effectively as a member of a development team.

These fundamental skills have not changed over the years and a good Business Analyst is strong in all of these areas; however, in some cases the role of a BA has degenerated into simply writing requirements documents.

What Is Wrong With the Traditional Business Analyst Role?

The problems with the Traditional Business Analyst role are essentially the same as a Traditional Project Management role.

  • Level of Uncertainty – In today’s environment, there is a much higher level of uncertainty associated with defining software solutions.  The traditional approach of documenting detailed requirements for projects prior to the start of the project just doesn’t work well with high levels of uncertainty.  You would likely wind up wasting a lot of time trying to define detailed requirements upfront prior to the start of the project based on speculation and those requirements might then go through an enormous amount of change as the project is in progress.
  • Emphasis on Creativity and Innovation – In the past, the primary emphasis in many projects has been on planning and control to achieve predictability of project costs and schedules.  Competitive pressures today have created a need to put more emphasis on creativity and innovation to maximize the business value of the solution.  An over-emphasis on planning and control can destroy creativity and innovation.  Can you imagine trying to develop the next generation of a very innovative product like a new iPhone using a traditional, plan-driven approach based on developing detailed requirements for the product upfront?

How Do Agile Requirements Work?

To understand the role of a Business Analyst in an Agile environment, we first need to understand how an Agile requirements process works.  There are a lot of misconceptions about Agile – some people may think that there are no documented requirements and the project is started by the developers writing code.   That is not the case.  The approach for developing requirements in an Agile project should be directly related to the level of uncertainty in the project:

  • In a project with a high level of uncertainty, it would be foolish to try to develop detailed requirements prior to the start of the project and the requirements might be limited to an overall vision and high-level requirements that the project must meet.  More detailed requirements would be further elaborated as the project is in progress based on direct feedback and inputs from the users.
  • If there is a lower level of uncertainty, the project might go further towards developing more defined requirements particularly if there is a need for some level of predictability of the project costs and schedule.  However, an Agile environment would still emphasize some level of flexibility and adaptivity to maximize the business value of the solution as the project is in progress.

There are several key differences in an Agile approach:

  1. Less Emphasis on Documentation – Agile requirements are considerably simplified and are typically written in terms of “user stories”.  A “user story” is a brief and very succinct definition of a business need without much detail about how it will be implemented,  A “user story” is considered to be a “placeholder for conversation” and it is understood that further definition of how it will be implemented will be determined based on direct, face-to-face communications with the users as the user stories are being implemented.
  2. Changes Are Encouraged – An Agile approach is designed around flexibility and adaptivity to maximize the value of the solution.  For that reason, changes to requirements as the project is in progress are encouraged.
  3. Direct Communication – There is a lot more direct communication between the business users and the project team.  First, there is a Product Owner who represents the business who directly participates in the project to provide overall business direction and priorities.  Second, the developers on the project team are expected to communicate directly with the business users to further elaborate and define requirements.

In this kind of environment, I think it should be obvious that the role of a Business Analyst should be more than just a “middle-man” to talk to the users and document requirements.  That would inhibit direct communications with the project team and probably also limit the flexibility and adaptivity that is so important to an Agile approach.

What is an Agile Business Analyst?

The role of a Business Analyst in an Agile environment is not well-defined just as there is no defined role for a Project Manager at a team-level in an Agile environment.  On small, simple Agile projects there may not be a need for either of these two roles but that is frequently not the case on large, complex enterprise-level projects.

The role of a BA is often neglected – it is assumed that the Product Owner plays that role but it can be difficult for a Product Owner to perform that role without some assistance on very large complex projects. I recently had to create a job description for hiring a BA on an agile project – here’s what I came up with as the primary skills needed:

  1. Analyzing a broadly-defined area and using functional decomposition to define high-level epics and stories to create a well-organized, value-driven framework to provide the required business value in the Product Backlog.  If the stories and epics follow a logical functional hierarchy it provides a mechanism for better understanding the relationship of the stories and epics to each other and for satisfying overall business goals.
  2. Writing individual stories that are very clear and concise and are easy to understand and implement by the development team.Writing effective user stories is a skill that is often taken for granted. What is often overlooked in good stories is the “why” or the “so that” clause that expresses the business value the story is intended to provide. A good BA can provide that perspective that is difficult for a developer to provide.
  3. Identifying related user stories and epics, grouping them into themes as necessary and documenting the interrelationship and associated business process flows as necessary.The interrelationship of user stories and epics should be well-understood and the implementation of stories across different functional areas may require some planning and coordination so that they are consistently implemented. This overall framework can provide a mechanism for easily identifying any inconsistencies and/or missing functionality.
  4. On large projects, there may be a need to integrate the needs of related projects as well as the needs of a number of different stakeholders to produce an overall solution.

The key point is that if a Business Analyst is involved at all in an Agile project, he/she should add value in some way and should not be just an intermediary between the development team and the business users and stakeholders.

The Next Generation Project Manager

The way that the next generation Project Manager is evolving is similar to the next generation of Quality Manager in the 1990s. I worked in a number of roles in the quality management profession in the early 1990’s. At that time, the quality management profession was going through a significant shift in thinking from an emphasis on quality control to more modern approaches such as Six Sigma and TQM.

  • The old approach relied very heavily on inspection after a product had been built to find defects before the product shipped
  • The new approach involved going into the processes and improving the process as necessary to eliminate the source of the defects and preventing the defects from happening at all.

The benefits of the new approach were obvious:

  • It eliminates the costs of a lot of unnecessary inspectors to find defects if the products are inherently more reliable
  • It has a huge impact on reducing costs of reworking and scrapping defective products and obviously significantly improved customer satisfaction

That changed the very nature of the quality management profession and many people who had defined their whole careers around the old quality control approach couldn’t adapt to that change and found themselves out of work while others who learned the benefits of the new approach continued to thrive.

In my opinion, there is a similar change going on in the project management profession today that is equally significant and requires us to rethink some of the very basic tenets of project management that have been taken for granted for many years. An example is the “project management iron triangle” (also known as the “triple constraint”) which has been a fundamental concept in project management for a long time. The idea behind it is that all three of the legs of the “iron triangle” (time, cost, and scope) are interrelated and changing any one of them is going to effect one or more of the other legs of the triangle. For example, if you increase scope, it’s likely to have an impact on both the cost and schedule of the project.

A key measurement of Project Managers for a long time has been how well they managed these triple constraints to control costs and schedules associated with a project. A project was deemed successful if it met the requirements it was supposed to meet within the planned cost and schedule. To control costs and schedules, you obviously have to control the scope of the project and limit changes to the requirements once the project has started. These ideas have been so well-engrained into the way projects have been managed for so long that it has begun to define what project management is just as the image of quality control inspectors used to define what quality management was at one time.

What’s wrong with that picture?

  • It might work OK in some areas like the construction industry where it is more realistic to predict and control the requirements, cost, and schedule for a project – it doesn’t work well at all in other areas where the requirements are much more difficult to define and control and a more adaptive approach is needed such as most software development projects. In those areas, there are many projects that might meet their cost and schedule goals but fail to deliver significant business value because it can be so difficult to define all the requirements before the project starts.
  • The traditional “iron triangle” approach does not recognize the value produced by the project as a variable. It assumes that the requirements accurately define the value that the project must produce and those requirements can be defined before the project starts – in many areas today that just isn’t very realistic at all and a much more flexible and adaptive approach is needed.

So, what does that mean for the project management profession as we know it? Does that mean that traditional project managers will become extinct like dinosaurs? I don’t think so, but I think any project manager who only knows the traditional project management disciplines of managing costs and schedules and can’t take a more adaptive approach when required may be severely limited in his/her career options.

I’m proud to be a project manager and I am dedicated to doing whatever I can to contribute to the ongoing improvement of the project management profession, but I do understand that we need to adapt and change to embrace new ways of doing project management. I learned a long time ago that anyone who thinks that they can “rest on their laurels” and stop learning and growing makes themselves uncompetitive and may be out of a job.

I have a vision for what I call “The Next Generation Project Manager” that I’ve tried to articulate in my two books – it’s a project manager who is equally well-versed in all the traditional project management principles and practices as well as all the Agile principles and practices; but beyond that, he/she understands those principles and practices at a deeper level and knows how to blend them together as necessary to fit any given situation.

Does that sound like an ambitious goal? It certainly is, but it is no more ambitious than what other professions such as the quality management profession have gone through over the years. I hope that through the writing I’ve done that I’ve been able to help others in the project management profession recognize the magnitude of this change and successfully adapt to it.

Making Agile Work with Offshore Teams

One more excellent question I got at the Valpak presentation last night was regarding “Making Agile Work with Offshore Teams” Here’s a brief response…There are a lot of difficulties and you have to be willing to accept a lot of compromises from an ideal Agile team. Here are a few examples:

  1. Commmunications is a major challenge. I was in a situation where the entire development team was in India and only the customer-facing people were in the US. In a normal Agile environment where the team is collocated and on the same time zone, a brief Daily Standup may be sufficient; but if that is the only (or primary) form of communications with the team throughout the day, it can be very difficult to limit the Daily Standup to just a brief 15 minute session. You have to learn to adapt the communication practices to the situation.
  2. Tools are essential to help close this communication gap and maintain coordination. Where you might be able to use “stickies” on a board with local, collocated teams; that just doesn’t work very well at all with distributed teams to keep everyone informed about what everyone else is doing.
  3. Cultural ChallengesThere are several significant cultural challenges:
    • There are a lot of good developers in India, but it can be very tough to find a lot of senior-level developers. In the Indian culture, someone may be perceived as a failure if they haven’t moved into a management position by some point in their career. For that reason, becoming a very senior-level developer who is not in a management position may not be regarded very highly. The impact of that is instead of having a team of peers who are self-organizing and all individually capable of self-directed work, you may have to compromise and select a few senior-level Team Leaders to provide direction to the rest of the team.
    • Indian people are also very polite and respectful and somewhat regimented (probably due to many years of British rule). In an ideal Agile team, that also works against being a totally self-directed team and you may find that more direction needs to be provided to the team.

Those are only a few of the more significant challenges, but the Indian people work very hard and are very committed to their work. If you go into it expecting that you’re going to be able to setup an ideal team as if they were collocated and from the same culture, you’ll probably get very frustrated; but if you learn to make the best of the situation and make a few compromises, you will find it to be a pleasure to work with the people in India – it just takes a bit of adaptation to make it work.

Tips and Tricks for “Selling” Agile (Superseded)

This post has been superseded by a new version. The new version can be found here:
How Do You Go About Selling Agile?

I visited with Stephanie Stewart and Tom Loftus at Valpak last night and gave a presentation on my new book to a Tampa Bay Agile Meetup. We had a great audience and they asked some great questions that stimulated me to do a couple of blog posts. The first question was “Do you have any tips and tricks for ‘selling’ Agile to management?” That’s a great question and I’ve certainly learned some lessons about that (the hard way) that I can share.

  1. First, you have to look at it from an overall business perspective , not from a more limited development process perspective. It’s very easy to get “tunnel vision” with Agile – we get so enthusiastic about the benefits of Agile from a development process perspective that we assume that what’s good for the development process must be good for the company as a whole and that’s not necessarily the case. Agile is most beneficial to companies whose success is driven heavily by product innovation (see my prior blog on corporate culture).But what if you work for McDonalds? How does becoming more Agile benefit the company? McDonalds is not known very much for leadership in introducing new products. They have improved in introducing new products in recent years (for example, their McCafe coffee has helped them take business away from Starbucks) but rapid product innovation still may not be the most important driver of their business. Rather than attempting to force-fit a company to an Agile approach; you may have to craft an approach that is more well-aligned with the primary success factors that drive the company’s business and becoming more Agile may or may not be the most important factor in the company’s overall business success.
  2. Second, you have to recognize that some companies are scared to death of Agile – they’re afraid of losing control and that fear is not totally unfounded if the Agile approach is not well-designed and managed. So, you may need to start off with more of a hybrid approach as an initial first step to demonstrate success rather than going full-bore into a complete corporate Agile transformation. You also need to recognize that an Agile transformation can take a long time and demands a lot of patience and perseverance.

Finally, nothing sells better than results. Work on developing good results and that will sell itself.

I hope that helps some people avoid learning some of these lessons “the hard way” as I have.

The Relationship of Agile and Corporate Culture

It’s important to understand the relationship of Agile and corporate culture. Adapting an Agile development process to a corporate culture can be a very difficult thing to do because changing a well-established corporate culture is not easy. If you ignore this problem and implement an Agile development process without attempting to integrate it with the overall business environment that it is part of, it’s not likely to be totally effective. The predominant thinking seems to be that you have to force the whole company to be Agile in order to adapt it to an Agile development process; I don’t believe that is the best solution in many cases. A company’s culture should be designed and optimized around the business and markets that company operates in.

One of my favorite books on this subject is “The Discipline of Market Leaders” by Treacy and Wierzema. It identifies three primary “value disciplines”

  1. Operational Excellence – Companies who focus on operational excellence succeed or fail by offering products and services more efficiently than their competitors can offer them. McDonald’s and Walmart are examples of companies whose primary value discipline is operational excellence. They do the same thing repeatedly at a low cost; that is what “operational excellence” is and it is reflected in their culture.
  2. Product Leadership – Companies who focus on product leadership succeed or fail primarily by innovating products to meet market needs faster and better than their competitors. Apple and Samsung are examples of companies whose primary value discipline is product leadership. Constant innovation is very important to these companies and they might be dominated by engineers who wear jeans and sweatshirts to work.
  3. Customer Intimacy – Companies who focus on customer intimacy succeed or fail primarily by providing a high level of personalized service to their customers relative to other competitors. Ritz Carlton Hotels is an example of a company who is driven by a culture of customer intimacy – their employees are trained that customer needs and customer service always come first and their processes need to be flexible to adapt to customer needs.

The idea of value disciplines is that a company can’t be deficient in any of the three areas; however, no company can be all things to all people and the company needs to choose one value discipline as the primary area of focus to excel in. The value discipline that is chosen as the primary competitive differentiator tends to define the whole company and its culture and values.

How do these value disciplines align with an Agile development approach? Obviously, the Product Leadership discipline has a very strong alignment. Companies who are in a business that demands Product Leadership as a critical success factor will have little difficulty in adapting to an Agile development approach because there is a natural alignment with the primary success factors in their business. Operational Excellence is probably the one that is most difficult to align an Agile Development approach with. In these companies, there are several alternatives:

  1. Ignore the misalignment and just implement Agile as a development process without attempting to align it with the business. That’s not likely to deliver optimum results, in my opinion.
  2. Attempt to force the company to change its culture to be more Agile. That may not be successful either and also may not be the best solution for the company’s business
  3. Develop an “Adaptation Layer” between the Agile development approach and the company’s business environment. This approach is probably the most practical and most likely to be successful in many cases. It might consist of putting a thin plan-driven “wrapper” around an Agile development approach to integrate it with the company’s business.

My Agile Project Management Training provides more details on this approach and provides some case studies of companies who have taken different approaches for solving this problem.

What’s the Right Level of Detail to Put in an Agile User Story?

Questions frequently come up about “What’s the Right Level of Detail to Put in an Agile User Story?” – I want to share some thoughts with you on that subject:

There is no absolute right/wrong answer about how much detail a story should contain – the best answer is “it depends”. The level of detail in the story depends on a number of factors including:

  • The complexity and nature of the story itself
  • The level of interaction available from the Product Owner to explain what is required
  • Where the story is in the overall lifecycle – there are at least three levels of detail required depending on how you plan projects, releases, and sprints:
  • Project-level Planning – Least detailed, suitable for very high-level project planning
  • Release-level Planning – medium detail, enough detail to do story point estimates
  • Sprint-level Planning – most detail, suitable for actually starting development and planning development tasks

Here’s what I recommend as some guidelines:

  • It is always best to err on the side of less detail rather than more detail as a starting point – Agile has a concept of “Just Barely Good Enough” which means you put a sufficient level of effort into the task to accomplish what is needed and nothing more – anything more than that is waste
  • Use a top-down, functional decomposition approach to progressively elaborate the level of detail in stories:
  • Start at the top-level to identify epics and story titles only
  • Once that is done and approved, write the actual stories, but only to the level of detail required
  • Rely on the developers and others on the team (QA) to tell you when the story is good enough – a lot of collaboration and face-to-face communication is essential – we need to get away from the Waterfall approach where a BA writes detailed requirements (stories) and then hands those requirements off to developers

Again, the key thing I want to emphasize is that there is no right/wrong answer about how much detail a story should contain…some general guidelines and models can be developed to guide the effort, but the real test of whether a story is well-written or not is based on feedback from the people who have to use the information in the story for whatever purpose it is intended for (estimation or development).

Blending Agile and Traditional Project Management