Category Archives: Enterprise-level Agile

Making Agile Work for Your Business

Background

Making Agile work for your business is a real challenge. There is widespread knowledge that exists about almost every possible aspect of how to optimize an Agile development process at a team level; however, the knowledge about how to make Agile work at an enterprise level is much more limited. There have been numerous failures in trying to make Agile work at an enterprise level and I believe that there are some significant misconceptions behind these failures:

Agile versus Waterfall

At the project management level, there is a big misconception that there is a binary and mutually-exclusive choice between an Agile approach and a traditional plan-driven project management approach (or what people many times refer to loosely as “Waterfall”). The result of this misconception is that people often try to force-fit projects to one of those extremes when a much better solution is to fit the approach to the project and sometimes a hybrid of the two approaches is the best fit. (See my online training course “Learning the Truth About Agile versus Waterfall” for more on that)

Aligning Agile With a Business Strategy

Another big misconception is that whatever is good for the development process must be good for the company as a whole and that is also not necessarily the case. At the business management level, the approach should be designed around what makes the most sense for the company’s business and that may or may not be exactly the same as the approach used to manage projects at the development level. The people designing the enterprise-level strategy need to be able to understand the business strategy as well as the development strategy and fit the two together. It isn’t necessarily just a matter of forcing the entire company to become more agile.

  • An Agile development process is easiest to apply in companies whose primary business is developing software products (Such as Intuit QuickBooks and TurboTax) or companies where software development has a very direct and significant leverage effect on the company’s business (Such as Amazon.com). In those companies, there is a fairly direct alignment between a company’s overall business management goals and an Agile development process.
  • In companies where that is not the case, the alignment may be less direct. For example, it may or may not be totally realistic for a company to adopt a complete, top-to-bottom Agile approach for their entire business and a more traditional, plan-driven approach may be appropriate at the higher levels (at least as an interim solution). However, that doesn’t preclude implementing a totally Agile or hybrid Agile development process. The Managed Agile Development process is an example of a hybrid Agile approach that can be used in that kind of environment.

Enterprise-level Agile Transformation Strategies

There are a number of different potential strategies at an organizational level for implementing an Agile transformation:

  • Some organizations may choose to implement a relatively complete top-to-bottom Agile transformation for their business – Dean Leffingwell’s Scaled Agile Framework (SAFe) is an example of such a model. However, that can be a very ambitious and gut-wrenching change for many organizations and it also may not be the best solution.
  • Fortunately, there are other alternatives companies can select to fit an Agile approach with their business

Organizations typically have different layers of management as shown in the diagram below; and, at each level, there is a choice of taking more of an Agile approach or more of a traditional, plan-driven approach:

Enterprise Agile Frameworks

Overall Summary

The important thing to recognize is that this is not a “one size fits all” decision. What is the right approach for one company may not be the best approach for another. It’s kind of like a chess game to choose the fit the right strategy to each level of the organization as shown in the diagram below:

Enterprise Agile 2

It should be apparent that making Agile work at an enterprise level isn’t necessarily as simple as it might seem and requires a broad understanding of both the business strategy and the development strategy to fit the two together. For more information on this subject, check out my online training course on “Making Agile Work for Your Business”.

What is an Agile PMO? Is it Possible? How Would it Work?

Background

I recently saw a question on a LinkedIn discussion group asking: What is an Agile PMO?

  • There are many people in the Agile community who might say that there is no role for a PMO in an Agile/Lean environment and
  • That the whole concept of a PMO is inconsistent with Agile.
  • That opinion is based on a stereotype that the role of the PMO is heavily associated with controlling and enforcing rigid, waterfall-style policies for selecting and managing the execution of projects and programs.

In that kind of environment, a PMO might require:

  • Very thorough and detailed upfront planning to justify the ROI on projects to support rigorous project/product portfolio management decisions
  • Rigid control of project execution to ensure that projects meet their cost and schedule goals and deliver the expected ROI

There is no doubt that some PMO’s have played that kind of role to some extent in the past; however, it is a stereotype to believe that is the only possible role for a PMO to play.

Understanding the Truth About “Agile versus Waterfall”

The key to understanding this issue is to first understand that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”.  It is better to think of this as a range of alternatives between heavily plan-driven at one extreme and heavily adaptive at the other extreme. That looks something like this:

Range of Agility

And, the right approach is to fit the methodology to the nature of the project and business environment rather than going in the other direction and attempting to force-fit projects and business to some kind of canned approach (whatever it might be – Agile or not).

What’s the General Role of a PMO in Any Organization?

The general role of any PMO is to:

  • Align the selection and execution of projects and programs with the organization’s business goals. That includes:
    • Project/Product Portfolio Management,
    • Providing oversight of project execution and
    • The overall interface for management and reporting of projects and programs to senior management and the business
  • Coordination, guidance, and training to project teams as needed in the organization’s methodologies and standards for project management.

Those general functions probably don’t change in an Agile/Lean project environment. However, how a PMO performs those functions may change significantly depending on the organization’s overall strategy for implementing an Agile transformation.

  • Some organizations may choose to implement a relatively complete top-to-bottom Agile transformation for their business
  • Dean Leffingwell’s Scaled Agile Framework (SAFe) is an example of such a model
  • However, that can be a very ambitious and gut-wrenching change for many organizations. And, it may also may not be the best solution

It may be a mistake to believe that you have to force a company to do an extensive, top-to-bottom Agile transformation in order to adopt an Agile process at the development level.  There are many ways to adapt an agile development process to a company whose overall business may not be totally compatible with an agile approach at the enterprise level.

If you accept the notion that you need to tailor the approach to fit the nature of the business, it should be evident that:

  • The design of a PMO should be consistent with that approach and
  • There isn’t a single “canned” solution for what an “Agile PMO” is.  However, there are some general guidelines that should be useful.

What Does a Traditional PMO Look Like?

A traditional PMO organization that is oriented around a heavily plan-driven approach might look something like this:

Typical Traditional PMO Structure
Reference: Cobb, Charles, “Making Sense of Agile Project Management”, Wiley, 2011

In this kind of environment:

  • The PMO typically takes almost complete responsibility for the execution of projects on behalf of the business sponsors
  • The emphasis in this kind of organization is typically on planning and control of projects

This kind of organization would be consistent with a heavily plan-driven approach. However, how does that role change as an organization moves towards more of an adaptive approach?

What is an Agile PMO?

A more adaptive version of a PMO organization might look something like this:

What is an Agile PMO?
Potential Agile PMO Structure
Reference: Cobb, Charles, “Making Sense of Agile Project Management”, Wiley, 2011

Key Differences

Here’s what some of the key differences might be as an organization moves towards more of an adaptive (Agile) approach:

Advisory Role

The role of the PMO becomes more of an advisory role and a consultative role rather than a controlling role. The function of the PMO should be to:

  • Put in place well-trained people coupled with
  • The right process and tools
  • To make the process most effective and efficient and
  • To keep it well-aligned with the company’s business

Primary Responsibility

The primary responsibility for providing direction to projects:

  • Shifts more to the business side represented by the Product Owner in the projects and
  • There is a much more of a closer coupling with the business side, and
  • There is more emphasis on the PMO providing business value rather than simply managing project costs and schedules

Role of Functional Organizations

The role of the functional organizations (Development, QA Testing, etc.) also changes to providing more of an advisory function as the resources are more committed to project teams and the project teams become more self-organizing

Key Challenges

This model can be a very big change for many businesses because:

  • It puts a lot more responsibility on the business side of the organization to provide direction to projects. And, the business organization may not be well-prepared to take on that responsibility
  • It requires developing a close collaborative relationship between the project team and the business rather than using a PMO as a “middle-man”
  • It also relies much more heavily on self-organizing teams

For those reasons and others, a totally adaptive approach may not be the right approach for all businesses. And, even if it is, it may take time to migrate an existing organization to that kind of approach. Fortunately, there are many ways to develop a hybrid approach to blend a traditional plan-driven approach with a more adaptive approach to fit a given business and project environment.

Hybrid Environments

The role of the PMO should be aligned with supporting whatever the overall business strategy is. That might require a hybrid of an Agile and traditional plan-driven approach. For example, here are some of the ways that a hybrid approach might be implemented:

Project/Product Portfolio Management

The PMO may still be the focal point for Project/Product Portfolio Management. However, a more agile approach might be used to perform that function.

  • Instead of very rigorous upfront planning that might be required to analyze project ROI to support a more traditional, plan-driven project/product portfolio management approach,
  • A more dynamic decision-making process might be used at that level with a much more limited amount of upfront planning and less-detailed ROI analysis.

Project Execution

In the other functions related to managing the execution of projects, the PMO:

  • Probably would probably delegate more responsibility to project teams and
  • Play more of a facilitative and consultative role to support the project teams rather than playing a controlling role.

Overall Summary

In summary,

  • Agile certainly forces some rethinking of the role of a PMO. However, it doesn’t necessarily make the whole concept of a PMO obsolete and irrelevant
  • There are a wide range of strategies an organization can choose for implementing an Agile transformation at an enterprise level. It isn’t necessarily a binary choice between a pure “Waterfall approach from top-to-bottom or a totally “Agile” approach from top-to-bottom. You have to choose the right approach to fit the business rather than attempting to force-fit the business to some kind of “textbook” approach.

The important thing to recognize is that this is not a “one size fits all” decision. What is the right approach for one company may not be the best approach for another.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Do You Have Excessive Fear of Failure?

Do You Have Excessive Fear of Failure? I participated in a discussion on LinkedIn this morning that stimulated my thinking. The individual who started the discussion asked the question,

“If a pilot project is discontinued because it didn’t achieve results it had hoped for, would that be considered project failure?”

What’s the Impact of Failure?

The answer seemed obvious to me but it really stimulated my thinking – one of the key things that differentiates an Agile approach from a traditional plan-driven approach is the attitude towards failure:

  • In an Agile environment, a “failure” is regarded in a positive sense as an opportunity for learning and there’s a very popular mantra of “fail early, fail often”. In other words, sometimes you just have to try something and see what works and take a risk rather than being totally risk-averse and attempting to analyze and anticipate every possible risk and contingency before you even get started.
  • In a traditional, plan-driven environment, the attitude towards failure is many times very different. Any significant unexpected event might be regarded as a failure and many times is regarded negatively. There is an inference that it’s a failure in planning that you didn’t do enough upfront planning to anticipate the problem and avoid it.

What’s the Right Approach?

I don’t think either of these two approaches is necessarily right or wrong. Like many things, it depends on the situation. There are some situations that call for a more risk-averse approach and some that don’t:

The Edge of Chaos

  • Some businesses have to operate on the “edge of chaos” because of a highly competitive business environment.
  • If they were overly risk-averse and had excessive fear of failure, they would not be successful in their business and that would be a failure in itself to not do anything to “push the envelope”.
  • Another saying I like is “If you’ve never failed, you’re not trying hard enough”.
  • Amazon.com is probably a good example of a company that has a lot of failures like their smartphone, yet they continue to push the envelope to explore very risky new technology such as package delivery with drones because I’m sure that they feel that they need to continue to “push the envelope” to maintain their competitive position

Other More Conservative Environments

In other environments, the consequences of problems may be much more significant and need to be more thoroughly anticipated and mitigated. Sending an astronaut to the moon might be an example. Check out the book, “Failure Is Not an Option: Mission Control From Mercury to Apollo 13 and Beyond” for more on that

The Gray Area

There’s also a lot of gray area between those extremes where it may require considerable judgment to figure out what the right approach should be.

  • Any project that involves a large amount of uncertainty might be an example. You need to figure out how much of that uncertainty you can tolerate and let it be resolved as the project progresses and how much of it you can’t tolerate and need to resolve upfront before the project starts.
  • It would probably be very irresponsible to take a cavalier approach and ignore the potential impact of risks; but, on the other hand, it could be equally problematic to get bogged down in “analysis paralysis” and never get started trying to anticipate and mitigate every possible risk that could possibly happen.

What Level of Risk Is Acceptable?

The most important thing is to have a clear mutual understanding and a sense of partnership between the project team and the project sponsor about what the goals of the project are, what level of risk is acceptable in the project, and how those risks will be managed.

Agile Projects

In an Agile project, that’s typically easier to do because the relationship with the business sponsor is based on a spirit of trust and partnership as well as openness and transparency and

  • The Business Sponsor (represented by the Product Owner) is expected to have a sufficient level of judgment and maturity to make good, sound decisions on the project.
  • Because there is an understanding that some of the risks and uncertainties will be resolved while the project progresses, the Business Sponsor (represented by the Product Owner) is also intimately involved as the project progresses to provide ongoing direction

Traditional Plan-driven Projects

In many traditional, plan-driven environments, the business sponsors may not have that level of maturity and there may be less of a spirit of partnership with the project team.

  • The Business Sponsors frequently put that responsibility totally on the project team to “just get it done” and don’t necessarily want to know about any risks at all.
  • That can lead to a fear of failure and a “CYA” approach by the project team to over-analyze the project to avoid any possible problems and it can also lead to less-than-open sharing of project information to avoid airing any “dirty laundry” with the project sponsors.

Overall Summary

It seems to me that the partnership approach where the business and the project team mutually agree on the project risks and how they will be managed is a lot more sensible and has numerous advantages.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is an Enterprise-level Agile Coach?

What is an Enterprise-level Agile Coach? When people use the term “Agile Coach” it is often not exactly clear what they mean.

Typical Team-level Agile Coach Role

Most often, what they’re talking about as an “Agile Coach” is what I would call a team-level Agile Coach. That is someone who works at a tactical level with individual members of an Agile team to help them become more proficient in executing a Scrum process.

  • There is very little standardization or certification for what it takes to become an “Agile Coach” at that level and
  • Almost anyone could claim to be an “Agile Coach”.

What Is an Enterprise-level Agile Coach?

What is an Enterprise-level Agile Coach?

Beyond that; however,

  • The role of an Agile Coach at an enterprise-level needs to be better-defined and differentiated from a normal team-level “Agile Coach” role.
  • An enterprise-level Agile Coach works at a more strategic level to integrate an Agile development process with a company’s business. (See diagram above)

Enterprise-level Challenges

An Agile Coach at an enterprise level typically helps plan and organize an enterprise-level agile transformation.

  • However, many Agile Coaches are only trained in Agile from a team-level development process perspective and make the assumption that whatever is good for the development process must be good for the business as a whole
  • They also may assume that it is a binary and mutually-exclusive decision to be either “Agile” or “Waterfall” and attempt to force-fit the entire company into an Agile model when the right solution is to fit the approach to the company’s business

The Impact of the Business Environment

The problem is that there is a big difference between companies whose primary business is focused on product development and other types of businesses.

Product Development Companies

  • Agile works very well in companies that are in the primary business of developing products (particularly software products). Intuit is an example that develops TurboTax, Quicken, and QuickBooks).
  • In those companies, there is a strong and natural alignment between an Agile development process and the overall business goals of the company
  • It is very easy to apply an Agile development process in that environment.

Non-Product Development Companies

It is much more difficult to apply an Agile development process in a company that is not in the primary business of developing products. In that kind of business, the relationship of an Agile development process to the company’s overall business strategy is much more indirect.

In companies that are not in the primary business of developing products,

  • You can’t just force the company to be “Agile” in order to make the company more amenable to an Agile development process
  • The company’s overall culture and business strategy needs to be optimized around the critical success factors for that business

Fitting the Approach to the Business

For example,

  • If a company is in a business that requires operational excellence, it needs to focus its overall culture and business strategy primarily on efficiency of operations and reducing costs and
  • That doesn’t necessarily align completely with just becoming more “Agile”.
  • In that kind of environment, you have to develop a strategy that considers both the company’s business strategy and the requirements of an Agile development process to develop a well-integrated approach.
  • The implementation of that strategy often requires fitting the approach to the company’s business environment rather than simply trying to force-fit the company to some kind of overall Agile approach.

Blending Agile and Plan-Driven Project Management

The approach that you might wind up with in that kind of environment also could be a blend of Agile and traditional plan-driven management principles and practices blended together in the right proportions to fit the situation. That is a lot more difficult thing to do and requires a lot more skill than a typical team-level Agile coach would normally have. It requires an understanding of:

  • Agile principles and practices; as well as
  • Traditional project management principles and practices
  • And a deeper understanding of the principles behind both of them (not just the mechanics) to know how to blend them together as necessary to fit a given situation

Business Perspective

Beyond that; however, it also requires the ability to look at a very complex, broad-based, enterprise-level business from both a more strategic high-level business management perspective as well as a more tactical product development process perspective to develop a strategy for integrating the two.

What often seems to happen is

  • Someone who is trained in “Agile” from a development process perspective attempts to steer the company in the right direction and
  • That person typically doesn’t have the breadth of business management experience and agile development process experience to know how to successfully integrate the two.

Is it any wonder why some of these “Agile transformations” are not successful?

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Managing Conflict in Agile Teams – Is Conflict Normal?

I recently saw a LinkedIn post from someone who was requesting advice on managing conflict in Agile teams. One response was to remove the people who are causing the conflict from the team.

  • That may not be an appropriate solution – some level of conflict is necessary and healthy in a high performance team.
  • A team where everyone always agrees with everyone else on the team would probably not be a very high performance team.
  • In this particular situation, the conflict was occurring over estimation and that’s an area where you certainly want to bring out opposing views and attempt to resolve them rather than suppress them.
Managing Conflict in Agile Teams

How Do You Manage Conflict in Agile Teams?

The right way to manage conflict on an Agile team is not to try to stifle conflict but to accept some values among the team to listen to the views of others and treat them with respect and consideration if you disagree with them.

  • Each person on the team also needs to put their own ego and emotions aside and instead of focusing on who’s right and wrong, focus on working collaboratively with others towards what is in the best interest of the team and the business.
  • Some times people become argumentative and pursue an argument just to have the last word or try to prove that they’re right and others are wrong – that behavior can be very counter-productive.
  • Having a clearly-defined set of values that everyone on the team agrees to is a good way to minimize that kind of behavior.

Tuckman’s Stages of Group Development

I suggest that anyone who wants to learn more about team dynamics do some reading on “Tuckman’s Stages of Group Development”. It’s an excellent model for understanding the stages teams go through in the journey to becoming a high performance team. Here’s a brief summary – Tuckman’s model consists of four stages:

1. Forming

The first stage is called “Forming”. In this stage, “Individual behavior is driven by a desire to be accepted by the others, and avoid controversy or conflict. Serious issues and feelings are avoided, and people focus on being busy with routines, such as team organization, who does what, when to meet, etc. But individuals are also gathering information and impressions – about each other, and about the scope of the task and how to approach it. This is a comfortable stage to be in, but the avoidance of conflict and threat means that not much actually gets done.”

2. Storming

The next stage is called “Storming”. During this stage, “Individuals in the group can only remain nice to each other for so long, as important issues start to be addressed.

  • Some people’s patience will break early, and minor confrontations will arise that are quickly dealt with or glossed over.

  • These may relate to the work of the group itself, or to roles and responsibilities within the group.

  • Some will observe that it’s good to be getting into the real issues, whilst others will wish to remain in the comfort and security of stage 1.

  • Depending on the culture of the organization and individuals, the conflict will be more or less suppressed, but it’ll be there, under the surface.

  • To deal with the conflict, individuals may feel they are winning or losing battles, and will look for structural clarity and rules to prevent the conflict persisting.”

3. Norming

As Stage 2 evolves, the “rules of engagement” for the group become established, and the scope of the group’s tasks or responsibilities are clear and agreed.

  • Having had their arguments, they now understand each other better, and can appreciate each other’s skills and experience. Individuals listen to each other, appreciate and support each other, and are prepared to change pre-conceived views: they feel they’re part of a cohesive, effective group.

  • However, individuals have had to work hard to attain this stage, and may resist any pressure to change – especially from the outside – for fear that the group will break up, or revert to a storm.”

4. Performing

The final stage is called “Performing”. “Not all groups reach this stage, characterized by a state of interdependence and flexibility.

  • Everyone knows each other well enough to be able to work together, and trusts each other enough to allow independent activity. Roles and responsibilities change according to need in an almost seamless way.

  • Group identity, loyalty and morale are all high, and everyone is equally task-orientated and people-orientated. This high degree of comfort means that all the energy of the group can be directed towards the task(s) in hand.”

There are several important things to recognize about this model:

  • You can’t just jump past the “Storming” stage and go right to the “Performing” stage unless the people on the team have a lot of maturity on working in other teams. You have to progress through these stages to some extent to make progress. For that reason, conflict should be viewed as a sign of progress that you’ve moved past the “forming” stage.
  • You don’t necessarily always proceed through these stages in a strict sequential order…sometimes a team will regress and fall back to an earlier stage and start over from that point and you might go back-and-forth like that over a period of time.
  • The natural progression for a team that is in conflict is to move to the “norming” stage and you do that by adopting rules and values of how the team interacts with each other. Those rules and values are like “training wheels on a bike”. After teams have reached a point of maturity, those rules become just a natural part of people’s behavior and the team reaches the “performing” stage which is similar to riding a bike without the “training wheels”.

Source: “Stages of Group Development”

Overall Summary

One of the key points in this model is the conflict is a normal and necessary stage of progression on the journey to becoming a high-performance team. For that reason, you shouldn’t try to stifle conflict – the best approach is to manage it by setting values so that it doesn’t become destructive.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Was Steve Jobs an Effective Agile Leader?

Was Steve Jobs an effective Agile leader? I watched the movie “Jobs” this weekend about the life of Steve Jobs and his career at Apple and it was very thought-provoking. 

Steve Jobs was absolutely brilliant, embodied a lot of Agile values, and he was enormously successful in developing some very innovative products in a relatively short amount of time that made Apple very successful;  but he was ruthless, tyrannical, and very insensitive in his relationships with people. 

I was thinking – is that style of leadership really consistent with Agile and is it an effective style of leadership for an Agile environment?

  • Much of the thinking behind Agile is based on the idea of empowered and self-organizing teams where the product definition bubbles up rather than being driven down from above,  Steve Jobs’ leadership style doesn’t seem to be very consistent with that model, but he was very successful in getting things done.
  • Another thing that seems to be not entirely consistent with Agile is that Agile is based on the idea of teams working at a “sustainable pace” and it was apparent that many of the teams that worked under Steve’s direction at Apple worked incredible hours to get things done but they were very passionate and dedicated to their work.

Here are some quotes from Steve Jobs that indicate his values that are related to Agile:

  • Focus and Simplicity – “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things…
    “That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
  • Planning – “Again, you can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something – your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.”
  • Quality – “Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”
  • Innovation – “Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.”
  • Requirements and Customer Needs – “You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new
  • Seeing the “Big Picture” – “A lot of people in our industry haven’t had very diverse experiences. So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have…To turn really interesting ideas and fledgling technologies into a company that can continue to innovate for years, it requires a lot of disciplines.”
  • Continuous Improvement – “I have a great respect for incremental improvement, and I’ve done that sort of thing in my life, but I’ve always been attracted to the more revolutionary changes. I don’t know why. Because they’re harder. They’re much more stressful emotionally. And you usually go through a period where everybody tells you that you’ve completely failed.”
  • Tools – “It’s not the tools that you have faith in – tools are just tools. They work, or they don’t work. It’s people you have faith in or not.”
  • Leadership Style – “It’s not about charisma and personality, it’s about results and products and those very bedrock things that are why people at Apple and outside of Apple are getting more excited about the company and what Apple stands for and what its potential is to contribute to the industry…The people who are doing the work are the moving force behind the Macintosh. My job is to create a space for them, to clear out the rest of the organization and keep it at bay.”

And one of his most famous quotes that really sums up his values is “Stay hungry, stay foolish”. 

Overall Summary

My thoughts on this are that:

  • Steve Jobs definitely had some “rough edges” in his relationships with people but he embodies many of the characteristics of an effective Agile leader
  • There probably isn’t one leadership style that is effective in all situations and some “out of the box” thinking is definitely worthwhile rather than implementing some kind of “textbook” Agile approach in all situations

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Enterprise-level Product Backlog Organization

A lot of thinking about Agile seems to be based on small, single-team projects rather than large, complex enterprise-level initiatives and there is a limited amount of information on what needs to be done to scale small, single team projects to large, complex enterprise-level initiatives and how to structure an enterprise-level product backlog.

Product Backlog Planning

One of those areas that often needs to be done differently on large, complex, enterprise-level projects is Product Backlog organization.  On small single-team Agile projects, the predominant thinking seems to be that you only need to plan the backlog a few sprints in advance, you just prioritize the stories in the backlog, and then pull them off as needed to start a sprint. 

That method starts to break down as you scale projects to large, complex enterprise levels.  There are a number of problems I’ve seen with that approach:

The Importance of Planning

Without planning the backlog further in advance, it’s difficult to assess the overall scope of the project and determine the resources required for the project. 

  • For example, I’ve seen a project that just started development with a small, single Agile development team and after two years of development still had no end-in-sight of when the project would be completed. 
  • It was a major surprise when we stepped back and re-planned the entire backlog at a high level to find that the project was going to take almost another two years to complete with the current level of resources.

Large Product Backlogs

When you have a large product backlog with hundreds or perhaps even over 1,000 stories, understanding the inter-relationship of the stories becomes important. 

When you make priority changes among stories in the Product Backlog, it often doesn’t make sense to do it the level of individual stories…if you move one story up in the Product Backlog, what about the other stories that are inter-related with it? 

  • Wouldn’t you want to move all of those stories together as a group?  Organizing the Product Backlog into Epics and perhaps even themes provides a way to make priority decisions at a higher level that is more appropriate for enterprise-level projects. 
  • At that level, priority decisions are often more based on a higher-level of epics and themes rather than at the level of individual stories within an epic or theme.

Architecture

Another major problem area is architecture. If you take a piecemeal approach to doing individual stories without planning and considering the entire solution, it can lead to poor architectural decisions and possibly significant rework later on.

Multiple Teams

Finally, when a project grows to the point that multiple teams are involved, it becomes even more essential to organize the work to be done in a way that it can be segmented among multiple teams without requiring excessive amounts of coordination overhead among the teams.

Overall Summary

In another article I recently wrote on “Enterprise-level Agile Implementation“, I discussed the other levels of management that are typically found at an enterprise-level in larger companies that need to be integrated such as Program Management and Product/Project Portfolio Management.  In a large company,

  • Organizing the Product Backlog into a hierarchical structure can be essential to support effective decision-making at those higher levels of management above the level of a single Agile team
  • And that is often critical to ensure that all of the projects in an organization are well-aligned with the company’s overall business strategy.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Enterprise-level Agile Implementation

I was recently asked to help a consulting firm who is working with a client having trouble with a very large enterprise-level Agile implementation. 

  • It seems that the company had gone head-over-heels into Agile across the whole company and the senior executives were unhappy with the way it was going. 
  • Many projects were going off track and senior management didn’t feel like they had much visibility and predictability to see if all the development efforts were really well-aligned with the company’s business strategy. 
  • I think this is a typical problem that many companies face for large-scale, enterprise-level Agile implementations.

The Challenge

The problem is that large companies typically have some kind of management infrastructure such as a PMO  for managing projects as well as some kind of project portfolio management approach to align projects with the company’s business strategy and that existing management infrastructure probably isn’t totally compatible with an Agile development approach.  The choices are:

  1. Dismantle the existing management infrastructure and simply implement Agile at a development team level with no guiding management infrastructure.  That typically results in problems  such as projects going out of control and not being well-aligned with the company’s business strategy.
  2. Implement a new top-to-bottom Agile management approach such as the Scaled Agile Framework.  This is a good solution but requires a major redefinition of the company’s management infrastructure and some companies are just not ready to make that kind of gut-wrenching change.
  3. Implement a “bridge” between the existing management infrastructure and the Agile development approach using a hybrid management approach overlaid on top of the Agile development process.

Higher Levels of Management

The most important point is that you can’t ignore the need for these higher levels of management and implement Agile as a development process without defining some way that it integrates with the company’s overall business strategy. The choices look something like this:

Enterprise Level Agiie Business Strategy

This can be a difficult thing to do because standard Agile methodologies such as Scrum do not provide much guidance above the development team level and there are a number of choices at each of these levels.  At each level, there is a choice of implementing a more Agile or a more traditional, plan-driven management approach.  It is somewhat like a chess game as shown in the diagram below:

Enterprise Agile 2

Potential Enterprise-level Agile Frameworks

Here’s how I would position some of the frameworks for filling this need:

Enterprise Agile 3

The three frameworks shown above are:

  1. My own Managed Agile Development model
  2. Scott Ambler’s Disciplined Agile Delivery model
  3. Dean Leffingwell’s Scaled Agile Framework (SAFe)

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Emotional Intelligence in Agile – Why Is Emotional Intelligence Important?

The role of emotional intelligence in Agile is important to understand. It is a skill that is very difficult to master for many people.

Emotional Intelligence in Agile

What is Emotional Intelligence?

HelpGuide.org defines “emotional intelligence as follows:

“Emotional intelligence (EQ) is the ability to identify, use, understand, and manage emotions in positive ways to relieve stress, communicate effectively, empathize with others, overcome challenges, and defuse conflict. Emotional intelligence impacts many different aspects of your daily life, such as the way you behave and the way you interact with others.”

Why is that so important in an Agile environment? It’s important because:

  • Agile relies so heavily on teamwork and open, honest, and
  • Transparent communication both within the team and with other stakeholders outside of the team.

Key Attributes Associated with Emotional Intelligence

HelpGuide.org goes on to define four key attributes associated with “emotional intelligence”:

CharacteristicDescription
Self-AwarenessYou recognize your own emotions and how they affect your thoughts and behavior, know your strengths and weaknesses, and have self-confidence
Self-ManagementYou’re able to control impulsive feelings and behaviors, manage your emotions in healthy ways, take initiative, follow through on commitments, and adapt to changing circumstances
Social AwarenessYou can understand the emotions, needs, and concerns of other people, pick up on emotional cues, feel comfortable socially, and recognize the power dynamics in a group or organization
Relationship ManagementYou know how to develop and maintain good relationships, communicate clearly, inspire and influence others, work well in a team, and manage conflict

Source: www.helpguide.org/mental/eq5_raising_emotional_intelligence.htm

The easiest way to see how this impacts the performance of Agile teams is to observe the behavior of someone who has a low level of emotional intelligence. Here is an example:

  • On an Agile team I’ve worked with, there was one particular individual who was very bright and intelligent but
  • He had a very strong and dominating personality and what I would consider a low level of emotional intelligence.

Here are some characteristics I saw – He:

  • Liked to be in control of everything. He wanted to be seen as the “hero” who is leading the entire effort. There was a saying on the team that if it’s not XX’s idea, it sucks
  • Was opinionated and confrontational, didn’t value other people’s perspective, and attacked other people openly in emails
  • Had a strong vested interest in his own ideas and proving himself “right”. He lost objectivity and wasn’t able to see different sides of a decision

Impact on an Agile Team

How does that impact the effectiveness of an Agile team?

  • It can stifle the contribution of others on the team. It’s well known that more minds can work better than one and the performance of a team is maximized when everyone on the team is fully engaged and actively contributing to decisions and the work of the team.
  • It can lead to poor decisions. Decisions may be biased in favor of one person’s point of view and may not objectively consider all aspects of the problem

Here’s some excellent additional reading on this subject:

http://www.helpguide.org/mental/eq5_raising_emotional_intelligence.htm

How Do You Acquire Emotional Intelligence?

I believe that the first and most important step is self-awareness. You have to be somewhat introspective and be able to look at yourself openly and honestly and also learn to be comfortable being open and transparent with others.

  • That doesn’t come naturally to all people and requires a certain amount of self-confidence to develop. Many people have a “shell” that they operate within and that “shell” can be either thick or thin.
  • There’s a concept that I learned a long time ago called the “Johari Window” that is still valid today.

The Johari Window

The Johari Window is a tool that is used to analyze someone’s level of self-awareness. It breaks up people’s self awareness into four quadrants:

AreaDescription
Open/Free AreaPersonality attributes and characteristics that are known to yourself and to others
Blind AreaPersonality attributes and characteristics that are known to others but not by yourself
Hidden AreaPersonality attributes and characteristics that are known by yourself but not by others
Unknown AreaPersonality attributes and characteristics that you are not fully aware of and others are also not aware of

Source: http://en.wikipedia.org/wiki/Johari_window

Alan Chapman has created a very nice diagram that shows the relationship of these four quadrants:

Johari Window Model

Source: http://www.businessballs.com/johariwindowmodeldiagram.pdf

Key Points

The key points are:

  • People who have a high level of self-awareness and who are also open and transparent in their behavior with others:
    • Have a relatively large quadrant one (Open/Free Area)
    • The other quadrants are relatively small
  • The objective of increasing your self-awareness, openness, and transparency is to:
    • Increase the size of quadrant one (Open/Free Area)
    • Relative to the size of the “Blind” and “Hidden” quadrants.
  • Another objective is to more fully develop your true potential through self-discovery of skills, attributes, and characteristics in the “Unknown” area that neither you or others you interact with are fully aware of.

How Do You Develop Self Awareness?

Years ago, I can remember many companies made self-awareness training a key part of their management development curriculum for new managers:

  • The principle behind that was that you couldn’t be very effective as a manager if you had a hidden personal agenda and
  • You weren’t open and transparent in your relationships with other people
  • Your employees will recognize the external veneer that you put on, see right through it, and lose respect for you

Unfortunately, over the years, many companies have cut back on that kind of training.

  • It was perceived as too “touchy-feely” and when times got tough, it was one of the first things that got cut because it was not seen to have a direct contribution to company profitability.
  • The relationship to company profitability may be indirect, but I think it is just as essential today for managers and even more important for people participating in Agile teams.

There are some exercises that can be done with Agile teams to develop higher levels of self awareness. For example, here’s a Johari Window self-assessment tool:

http://kevan.org/johari

Overall Summary

Emotional Intelligence is important in an Agile environment.

  • It is essential for creating an environment of trust where people feel comfortable with being open and honest with others in a small group
  • Once people have become comfortable with doing that in a small group, they can then take more risks and practice the same behavior outside of that small protected group environment
  • Self-awareness is a very important skill for achieving emotional intelligence. You must be able to see yourself openly and honestly in order to improve

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Developing an Agile Company Culture

Developing an Agile company culture can be a major obstacle to successfully implementing an Agile development approach; however, it doesn’t have to be that difficult.

  • Some people make the mistake of thinking that you have to change the entire culture of a company in order to adopt an Agile development approach.
  • I don’t believe that is either necessary or appropriate in many cases; a company’s culture should be designed around whatever business they are in and that may or may not be well-aligned with implementing an Agile development approach.
  • See my previous blog post on “Agile and Corporate Culture” for more discussion on this:

Impact of Corporate Culture

Agile works best in companies that are in the business of developing products or where software product development is somehow very directly related to their primary business.

  • In other companies where the relationship is more indirect, it can be much more difficult to implement an Agile development approach because it may not be as well-aligned with the company’s primary business objectives.
  • An example is Walmart…Walmart’s primary business is driven by reducing costs. I’m sure that software development plays some role in that but it is much more indirect than a company like Amazon.com whose business is very directly leveraged by software development.
  • It should be very easy for a company like Amazon.com to implement an Agile development approach and far more difficult for a company like Walmart to do the same thing.

The key point is that since Walmart’s primary business is through conventional brick-and-mortar retail stores, they have to develop a culture that is well-aligned with squeezing costs out of every area of their operations and managing a large number of retail stores very efficiently and effectively.

  • Those are the primary drivers of their business and that may not align very well with an Agile development approach.
  • If you were to set out to implement an Agile development process inside of a company like Walmart, would you try to get them to give up their entire corporate culture and adopt a different corporate culture that is more suitable for hosting an Agile development process? I don’t think so, but there are some fundamental aspects of any company’s culture that can be dysfunctional are most critical to adopting an Agile development approach.

What Are the Most Important Factors?

Here are a few of what I think are the most important factors in developing a corporate culture that is consistent with Agile:

1. Transparency and Trust

In many large corporations, there is somewhat of a contractual relationship between the business users and the people who deliver Information Technology solutions. The business users may be under intense pressure to reduce costs and want to get firm commitments from the solution providers on the costs and schedules of projects. That is one of the major factors that has can be a big obstacle to implementing an Agile development approach – sometimes it even creates somewhat of an adversarial relationship between the two organizations. The key to getting past that obstacle is:

  • Companies need to realize that this is not an “all-or-nothing” proposition to totally give up all control of projects to become Agile. There are many ways to blend traditional project management principles and practices with Agile principles and practices to develop the right balance of agility and control. See my blog post on a Hybrid Agile framework here:

http://managedagile.wordpress.com/2013/07/22/a-hybrid-agile-development-framework/

  • Developing a spirit of trust, partnership, and collaboration between the two organizations can require some strong executive-level leadership to break down some of the traditional barriers that exist inside of companies. The strongest driving force for making that happen is that it requires a more collaborative partnership approach to focus on rapid innovation.

2. Focus on Continuous Improvement and Innovation

A focus on process improvement and continuous innovation is certainly not new to Agile.

  • It has been around a long time and many companies have successfully adopted continuous improvement approaches based on Six Sigma and other methodologies.
  • I published my first book in that area called “From Quality to Business Excellence” in 2003.
  • What I found was that in the companies that did Six Sigma well, it may not even be noticeable that it was Six Sigma. They may not have a lot of the hoopla like black belts and green belts that are normally associated with Six Sigma and it was so deeply ingrained into the way the company did business, that it may not even have been called Six Sigma.
  • The companies that did it well took a systems thinking approach to adapt it to their business while the more superficial companies simply did it mechanically “by the book” and treated it as just another “Program du jour”.
  • I think a similar thing is happening today with Agile. Companies who take the time and effort to understand Agile at a deeper level and adapt it to their business are probably more likely to do it successfully.

3. Respect for People and Self-organizing Teams

This principle is also not new to Agile. It was a key element of Dr. Deming’s principles that form the basis of the Total Quality Management (TQM) approach and I can remember a strong focus on this when I worked at Motorola in the early 1990’s.

  • It’s another thing like Six Sigma that some companies forget about when the pressure gets intense to deliver business results.
  • They sometimes take a superficial, brute-force approach to try to drive business results rather than taking a systems-thinking approach to understanding the factors that drive business results and the role that people play in achieving those goals.

If you only focus on those three things about a company’s culture, I think you will have a pretty good foundation for implementing an Agile development approach and those three things are somewhat common to all companies regardless of what business they’re in.

An Interesting Footnote

By the way, here’s an interesting footnote to this article: Walmart has recognized the importance of e-commerce to their business and has formed a new division called “Walmart Labs” to address that challenge. Here’s an interesting article on that topic:

http://www.technologyreview.com/news/429589/walmarts-new-high-tech-labs-youre-not-in-arkansas-anymore/

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.