Tag Archives: Hybrid Agile

What is a “Hybrid Agile” Approach? Is There Such a Thing?

What is a hybrid Agile Approach? Is there such a thing? I recently came across an article on the Internet that was posted in several places entitled “The Moment of truth: There Is No Hybrid Agile“.

  • This article is so full of stereotypes and misconceptions about “Agile” and “Waterfall” that I felt that I had to respond to it. 
  • It is typical of many articles that position “Agile” and “Waterfall” as two binary and mutually-exclusive alternatives with no middle ground between the two.

What Are the Flaws in This Thinking?

Treating Agile and Waterfall as Discrete, Binary Opposites

The biggest flaw in this thinking is that this article and many others like it treat “Agile” and “Waterfall” as if they were individual, discrete methodologies. They also position “Agile” and “Waterfall”  as diametrical opposites of each other.  That’s not very accurate.

“Agile” and “Waterfall” are not really discrete, individual methodologies at all and both of those terms are used very loosely.  In common usage. Neither of those are individual, discrete methodologies:

  • Many people  may think of “Agile” as being synonymous with Scrum but that is not really accurate.  “Agile” is much broader than Scrum – it is a way of thinking defined by the Agile Manifesto
  • “Waterfall” is also not a single, discrete methodology. In today’s world, many people use the term “Waterfall” for any plan-driven methodology that is not Agile.  What about RUP and other iterative approaches that probably wouldn’t be considered to be Agile?  Is that “Waterfall”?

A Better Way of Thinking

Instead of thinking of what people commonly call “Agile and “Waterfall” as individual discrete methodologies, it is more accurate to see it as a continuous spectrum of approaches from heavily plan-driven at one extreme to heavily adaptive at the other extreme like this:

What is a hybrid agile approach?

If you think of it in that way, it is much easier to see the possibility for lots of approaches in the middle of that spectrum that blend the right level of plan-driven principles and practices with more adaptive principles and practices to fit a given situation.

Here’s what some methodologies would look like plotted on a spectrum of heavily plan-driven versus heavily adaptive:

Adaptive vs Plan-driven

As you can see from this diagram:

  • “Agile” is not a single approach and there is not just one way to do “Agile”:
    • Kanban is more adaptive than Scrum, and
    • Even within Scrum you will find different styles of implementation from
      • Simple team-level projects which may tend to be more adaptive to
      • Larger more complex multi-team projects which may tend to be somewhat more plan-driven

Putting It Into Practice

The most important point to get out of this is that there is not a clear and well-defined boundary line between “Agile” and “Waterfall” as many people seem to think.

Fitting the Approach to the Nature of the Problem

Many people make the mistake of performing a methodology mechanically. They think they need to do it religiously and “by the book”(That’s true of both Agile and other non-Agile methodologies)

  • The right approach is to fit the methodology to the nature of the problem rather than force-fitting all problems to a given methodology (Agile or non-Agile)
  • It takes more skill to do that but it definitely can be done.
  • It requires understanding the principles behind the methodology and why they make sense in a given situation rather than doing a given methodology mechanically

If you think of methodologies as being rigid and prescriptive,

  • It will be difficult to see how two seemingly disparate methodologies could be blended together in the right proportions to fit a given situation.
  • On the other hand, if you understand the principles behind the methodologies at a deeper level, it is much easier to see how they could be complementary to each other rather than competitive.

Learning to be a “Chef”

It can take a lot more skill to learn how to blend different approaches together in the right proportions to fit a given situation. In my book on Agile Project Management, I use the analogy of a project manager as a “cook” and a project manager as a “chef”.

A Good “Cook”

“A good ‘cook’:

  • May have the ability to create some very good meals, but
  • Those dishes may be limited to a repertoire of standard dishes.
  • And, his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook”.
A “Chef”

“A ‘chef’, on the other hand,

  • Typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases.
  • His/her knowledge of how to prepare those meals is not limited to predefined recipes, and
  • In many cases, a chef will create entirely new and innovative recipes for a given situation
  • The best chefs are not limited to a single cuisine. They are capable of combining dishes from entirely different kinds of cuisine.

That’s the challenge for project managers and agile practitioners in today’s world – we need more chefs and fewer cooks.

What is a Hybrid Agile Approach?

In simple terms, a hybrid Agile approach is one that blends the plan-driven principles and practices with Agile (adaptive) principles and practices in the right proportions to fit a given situation.

Managed Agile Development Framework

An example of that is the Managed Agile Development framework that I created. It simply wraps an outer layer of project-level planning around an Agile development process.

Managed Agile Development Framework

The outer layer can be as thick or thin as necessary to fit the situation.

The Origin of This Approach

I originally developed this framework when I was managing a very large government program for a US government agency.

  • The government agency had to have some level of predictability over the costs and schedules of the program.
  • The program was so large that it actually had some level of congressional oversight so some level of predictability and control was essential
  • However, within that outer envelope, the government agency customer wanted to have flexibility in many of the detailed requirements.
  • We were able to find the right balance of control and flexibility to satisfy both needs.

What Are Examples of Hybrid Agile Approaches?

Some of the most common examples of hybrid Agile approaches are:

Agile Contracts

  • The government program I mentioned is a good example
  • I also have a case study in my book on General Dynamics UK, Ltd. They successfully used a hybrid Agile approach to manage a large defense contract for the ministry of defense in the UK
  • I just finished building a new house. I naturally had a contract with the builder that defined the cost and schedule for the home. However, the builder offered a lot of flexibility to make changes even as the construction of the house was in progress (He charges for changes, of course)

Large, Enterprise-level Projects and Programs

It’s almost impossible to successfully implement some large complex enterprise-level projects and programs without integrating some level of project and program management.

  • A good example of that is the Harvard Pilgrim Healthcare case study that is written up in my latest book.
  • The project involved over 100 Agile teams and involved replacing almost everyone of HPHC’s most critical business systems over a period of time
  • The whole effort involved a lot of moving parts that had to be carefully planned and synchronized. It’s impossible to imagine how that could be done without a sufficient level of project and program management to guide and manage the overall effort

Other Business-driven Initiatives

Many people have the mistaken belief that you need to force the entire company to be agile in order to adopt an Agile development approach. That isn’t necessarily true.

Fitting the Approach to the Business

A business has to be designed around whatever critical success factors are most important for the business that they’re in. Becoming agile may not be the only factor and may not even be the most significant factor.

  • For example, some companies are in very cost-competitive industries and succeed primarily based on operational excellence to lower their costs as much as possible
  • Becoming more agile may play an indirect role in that but it isn’t necessarily the most important factor
Product Development Companies

On the other hand, in a company that is technology-driven that succeeds on bringing leading-edge products to market as quickly as possible, it’s much easier to see how a pure Agile approach might be a very strong and direct driver of the business

  • Agile was originally developed for companies that do product development and that’s where it works best.
  • In companies whose primary business is not developing products per se, there is typically more of a project-oriented approach.
  • The company has to typically evaluate a potential portfolio of projects to determine what mix of projects and programs is going to have the greatest impact on their business.
  • Then they need to monitor the execution of those projects and programs to determine if it is really delivering the expected returns.

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.

Product Development versus Project Development

Agile has been most widely used in “product” development environments and less widely used in “project” development environments.  The difference between product development versus project development is not widely-recognized.  Of course, this is not a totally universal, black-and-white distinction; but, in general, here are some key differences:

Product Development versus Project Development

General Characteristics

AreaProduct DevelopmentProject Development
Objectives
  • Products typically have broadly-defined objectives
  • Products are less deterministic and the business model is usually a little more open-ended
  • Projects generally have more clearly-defined expectations and requirements
  • Projects are typically more deterministic and the business model is more closed-ended
UncertaintyProducts are generally somewhat speculative and might require a significant amount of innovation particularly if it is something that has never been done beforeProjects are generally less speculative
DurationFor many products, it’s an effort that simply goes on-and-on without end to provide ongoing support and enhancements for the life of the productProjects typically have a well-defined beginning and end and are completed as soon as the project objectives have been accomplished
ExamplesFor example, a company might say that:
  • We want to develop a product to satisfy “X” market need (where that market need may only be generally defined and might need to be validated) and
  • We’re going to invest $X to fund a team for ongoing development to support that product development initiative
For example, a company might say that:
  • We want to implement a project to install and implement a new CRM system with the following requirements
  • The project needs to be completed in six months and is expected to cost $X

Budgeting, Business Model, and Decision Process

AreaProduct DevelopmentProject Development
BudgetingThe budget for a product development effort may have some slack in it depending on the level of uncertainty associated with the product development effortVery few development teams are given a “blank check” to do some kind of project without having some expectations of what the project will accomplish, what it’s going to cost, and what the schedule will be
Business ModelThe business model behind a product development effort is typically based on a projected return on investment (ROI) that the decision to invest $X in the ongoing development effort will provide an acceptable return from the profitability that the product will generate over the life of the productThe business model behind projects is typically very different. A company typically has a given amount of funding to invest in projects and some kind of project portfolio management approach is generally needed to determine the appropriate mix of projects that will provide the greatest overall benefit
Decision ProcessThe decision process associated with a product development effort is generally focused on prioritizing what features should be added to the product to provide the highest level of customer satisfaction and profitability
  • In order to make the decision of what projects to fund, something may need to be known about the expected results, costs, and schedules of the projects in that portfolio
  • There is also an ongoing need to monitor the performance of those projects to see if they really are going in the right direction to provide the return that was expected

Overall Summary

There is a big difference between the business model and decision process in a product versus project development environment. 

Agile is very well-suited for a product development environment. Applying Agile principles and practices in a “project” development environment can be a bit more challenging but it definitely can be done. 

  1. Agile works best where there are limited constraints on costs and schedules and the primary goal is to add features to maximize market acceptance and customer satisfaction
  2. When you introduce constraints on costs and schedules in a project development model, a hybrid agile approach may be necessary to meet the competing demands of:
    • A highly flexible and adaptive development approach, and
    • The predictability of meeting cost and schedule constraints that is often demanded in a project environment.

The Hybrid Agile Development Approach is an example of how this can be done.  It involves wrapping a “shell” around an Agile development process. That “shell” can be as thick or thin as you want it to be. The approach can balance the need for planning and predictability with some level of flexibility and adaptivity.

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.

Agile Project Manager Job Description

I was recently asked by a company I am working with to create an Agile Project Manager job description. Here’s what I came up with:

Introduction

The Agile Project Manager (APM) is responsible for planning, leading, organizing, and motivating Agile project teams. The goals are to:

  • Achieve a high level of performance and quality, and
  • Deliver agile projects that provide exceptional business value to users

The APM may be responsible for managing several concurrent high visibility projects using agile methods in a fast-paced environment that may cross multiple business divisions.

Potential Agile Project Manager Roles

The APM may play a number of different roles in actual practice:

Enterprise-level Role

At an enterprise level, potential roles include:

  • Leading and managing large, complex enterprise-level projects
  • The projects may consist of multiple Agile teams and require integration with other activities outside the scope of the Agile teams

Team-level Role

At a team level, potential roles include:

  • Playing a consultative role to put in place the appropriate people, process, and tools, to improve team efficiency and effectiveness
  • Coaching members of the team as needed to optimize the efficiency of the project team

Hybrid Agile Role

In situations that require a hybrid Agile approach, potential roles include:

  • Using good judgment and skill to develop a project management approach that is suitable for planning and managing the effort
  • Achieve the project goals within designated project constraints

In performing these roles, the APM will be expected to use a high level of knowledge and experience in blending traditional project management principles and practices with an Agile development approach in the right proportions to fit large, complex, mission-critical, enterprise-level projects and with the appropriate level of planning and provide the right balance of agility and predictability.

Essential Job Requirements

AreaRequirement
Project Planning and ManagementDefine project scope and schedule while focusing on regular and timely delivery of value; organize and lead project status and working meetings; prepare and distribute progress reports; manage risks and issues; correct deviations from plans; and perform delivery planning for assigned projects
Team ManagementAssist in team development while holding teams accountable for their commitments, removing roadblocks to their work; leveraging organizational resources to improve capacity for project work; and mentoring and developing team members
Product Owner SupportSupport the Product Owner in managing customer expectations for project deliverables, managing stakeholder communications, and helping to implement an effective system of project governance
Process Management and ImprovementDefine and manage a well-defined project management process and champion ongoing process improvement initiatives to implement best practices for Agile Project Management
Team BuildingPromote empowerment of the team, ensure that each team member is fully engaged in the project and making a meaningful contribution, and encourage a sustainable pace with high-levels of quality for the team

Qualifications

  • Solid understanding of software development life cycle models as well as expert knowledge of both Agile and traditional project management principles and practices and the ability to blend them together in the right proportions to fit a project and business environment
  • A proven track record of successfully implementing software or web development projects using Agile methodologies including 8+ years of experience as a Project Manager managing large, complex projects in a high-tech development environment with multi-function teams. PMP preferred
  • Prior experience with SCRUM/Agile methodologies with enterprise-level application development projects. PMI-ACP, CSM, or equivalent preferred
  • Experience overseeing multi-function project teams with at least 10-15 team members including Developers, Business Analysts, and QA Personnel
  • Balanced business/technical background:
    • Sufficient level of technical background to provide highly-credible leadership to development teams and to be able to accurately and objectively evaluate complex project risks and issues
    • Ability to provide leadership to business analysts and collaborate with customers and develop strategies and solutions of high business value

Skills Required

  • BA or BS or equivalent experience is required; MA or MS is a plus
  • Very effective interpersonal skills including mentoring, coaching, collaborating, and team building
  • Strong analytical, planning, and organizational skills with an ability to manage competing demands
  • In-depth knowledge and understanding of business needs with the ability to establish/maintain high level of customer trust and confidence
  • Proven ability to lead software development projects and ensure objectives, goals, and commitments are met
  • Solid understanding of and demonstrated experience in using appropriate tools:
    • Agile Project Management tools such as Jira/Greenhopper, Rally, VersionOne or equivalent
    • Microsoft Project, Visio, and all Office Tools
  • Excellent oral and written communications skills and experience interacting with both business and IT individuals at all levels including the executive level
  • Creative approach to problem-solving with the ability to focus on details while maintaining the “big picture” view

Additional Resources

This is a new and rapidly evolving field. For more insight into the role of an Agile Project Manager, check out the online training curriculum below:

Agile Project Management Training Curriculum

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.

Managed Agile Development Framework – A Hybrid Approach

I’ve seen many people ask a question like “should I use Agile or Waterfall for a project? That excludes the possibility that there is a hybrid approach that provides the benefits of both approaches. The Managed Agile Development Framework is an example of a hybrid approach that is very easy to implement

Background

A few years ago, I was responsible for managing a large government project.

  • The project required meeting some defined cost and schedule milestones
  • However, the customer wanted to take an Agile approach to defining the requirements.

In response to that project, I developed an approach which I call “The Managed Agile Development” framework that would satisfy those two seemingly inconsistent goals. The framework consisted of two levels:

LayerDescription
Macro LevelThe “Macro” level was the outer envelope of the project. It was focused primarily on managing overall contractual requirements
Micro LevelWithin that “macro level” envelope, we were still able to implement a fairly flexible Agile development approach at the “micro-level”
Managed Agile Development Framework

How Does It Work?

There are two layers in the framework as shown in the diagram above. The “Macro” layer is plan-driven; but it can be as “thick” or “thin” as you want it to be. The “Micro” layer can be any Agile development approach such as Scrum.

  • The macro-level framework is a plan-driven approach. It is designed to provide a sufficient level of control and predictability for the overall project. It defines the outer envelope (scope and high-level requirements) that the project operates within
  • Within that outer envelope, the micro-level framework utilizes a more flexible and iterative approach based on an Agile/Scrum approach. It is designed to be adaptive to user needs

Trade-offs to Consider

Naturally, there are tradeoffs between

  • The level of agility and flexibility to adapt to change at the “micro-level” and
  • The level of predictability and control at the “macro-level”.

It is important that both the client or business sponsor and the development team need to agree on those trade-offs. The framework provides a mechanism for making those trade-offs by making the “macro-level” as “thick” or “thin” as you want to fit a given situation.

Increasing Predictability and Control

Increasing the level of predictability and control requires:

  • Beefing up the macro-level,
  • Providing more detailed requirements at that level, and
  • Implementing at least a limited amount of change control

Increasing Agility

To increase the level of agility:

  • You can simply eliminate the macro-level altogether or limit it to only very high-level requirements
  • Other elements of the framework can be easily customized or eliminated depending on the scope and complexity of the project and other factors

Change Control

A question that often comes up is “How do you handle change control?”. The answer to that question is that:

  • You have to design enough slack into the milestones at the “macro” level to allow detailed elaboration of requirements to take place in the “micro” level.
  • However, when there is a significant enough change in the “micro” level that would impact achievement of the requirements in the “macro” level, that should trigger a change to the “macro” level milestones.

General Approach for Agile Contracts

This general approach can be used on almost any project. Check out this article for more detail on Agile Contracts:

Agile Contracts

Additional Resources

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

Agile and Lessons Learned From the Martial Arts

I was engaged in a discussion on LinkedIn that made me think about the relationship of Agile and lessons learned from the martial arts like Karate.

What Is the Similarity?

In theory, there should be a lot of similarity:

  • Techniques – There are a wide range of Martial Arts techniques that can be applied in different situations
  • Finesse and Skill – Most Martial Arts require finesse and skill; it’s not just a brute force approach
  • Levels of Skill – There are different levels of skill associated with Martial Arts and it is an ongoing journey to become a “master”

How Does It Compare to Actual Practice?

In actual practice; however, I think that Agile principles and practices are at a very low level of maturity compared to Martial Arts (that’s perfectly understandable given that Martial Arts have been around for thousands of years); however, there is a lot we can learn from martial arts that can be applied to Agile:

Techniques

Agile has become synonymous with Scrum as the primary methodology for implementing Agile and our knowledge of implementing Agile successfully is heavily defined by the “mechanics” of how to implement Scrum. Surely, there must be more to Agile than that. That’s equivalent to saying that Karate is the only Martial Arts practice when there are many, many others.

Finesse and Skill

I’ve seen many companies take a very superficial approach to Agile. They will do a few Agile practices like holding Daily Standups and putting up Kanban Boards and call it Agile. In many cases, if you look under the surface, it’s still just a brute force approach to get things done. They haven’t really fully implemented Agile principles and practices and they haven’t mastered the skill and finesse needed to do it well.

  • People may not be dedicated to Agile teams
  • The company may still rely on overtime, weekend work, and pressure to meet unrealistic deadlines
  • There may be no Product Owner role and the business side may not be well-integrated with the project
Levels of Skill

Many people don’t seem to realize that there are different levels of skill associated with Agile (some of those levels aren’t even fully understood yet).

  • There is a wealth of knowledge about how to do almost every aspect of Scrum at the team level but very little is understood about how to scale Agile to an enterprise level and how to integrate it with a business environment that isn’t necessarily well-suited to Agile.
  • There are also still very wide gaps in our understanding of how to blend Agile principles and practices with more traditional project management principles and practices which are often seen as competitive rather than complementary with Agile.

Shu-Ha-Ri

There’s a particular concept from Martial Arts that is helpful to understand the level of maturity we are at in Agile. The concept of “Shu-ha-ri” is a Japanese concept to define different levels of proficiency in Martial Arts:

“Shu” Stage

“Shu” means to keep, protect, keep or maintain.

  • During the “Shu” phase, the student builds the technical foundation of the art.
  • In “Shu”, the student should be working to copy the techniques as taught without modification and without yet attempting to make any effort to understand the rationale of the techniques of the school/teacher.
  • In this way, a lasting technical foundation is built on which the deeper understanding of the art can be based

“Ha” Stage

“Ha” is the second stage of the process.

  • “Ha” means to detach and means that the student breaks free from traditions to some extent.
  • In the “Ha” stage, the student must reflect on the meaning and purpose of everything that s/he has learned and thus come to a deeper understanding of the art than pure repetitive practice can allow.

“Ri” Stage

“Ri” means to go beyond or transcend.

  • In this stage, the student is no longer a student in the normal sense, but a practitioner.
  • The practitioner must think originally and develop from background knowledge original thoughts about the art and test them against the reality of his or her background knowledge and conclusions as well as the demands of everyday life.
  • In the Ri stage, the art truly becomes the practitioner’s own and to some extent his or her own creation.

(Source: Shu-Ha-Ri http://www.aikidofaq.com/essays/tin/shuhari.html)

Where Do You Stand?

If you think about our current level of knowledge of Agile as it exists today,

  • I think many people are still struggling with the “Shu” level to understand the mechanics of how to do Scrum and have a long way to go to really get to higher levels of mastery.
  • I’m not sure how many people realize how big this gap is between where we are now and where we need to get to.
  • I think there are many people who seem to think that all there is to know is the mechanics of how to do Scrum at the team level and I think we have hardly scratched the surface of the knowledge that is needed to be known about how to successfully do Agile Project Management.

Martial Arts have been around for thousands of years and there’s still a lot to be learned so its very understandable that our level of knowledge about Agile is at a fairly low level of maturity. For example, here is a very good article written by Patti Gilchrist on the innovations that Bruce Lee has brought to Martial Arts that has some similar thoughts to this article that I really liked:

http://www.projectmanagement.com/articles/278838/Of-Martial-Arts-and-Methodology

Overall Summary

There’s a lot to be learned from the levels of maturity in the martial arts that are directly relevant to Agile. It provides a good way of understanding the level of maturity of Agile teams.

Additional Resources

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

Using an Adaptive Leadership Style in Agile

I’ve been a Project Manager for many years and, over the years, I’ve gone through a lot of job interviews, particularly as a consultant where you might change roles every 3-6 months. One of the questions I’ve been asked in interviews is “What is your leadership style?”. My answer to that is I use an “adaptive leadership” approach; that is, I think that’s there’s not just one leadership style that works all the time and that is particularly true in an Agile environment. You have to adopt an adaptive leadership style in Agile that is appropriate for the situation.

Adaptive Leadership Style in Agile
Leadership Business Management Teamwork Motivation Skills concept on the hexagons and transparent honeycomb structure presentation screen. Man pressing button on display with word in modern office

How does that apply to Agile Project Management?

  • There is a popular stereotype in the Agile community that all project managers are only capable of operating in a “Command and Control” leadership style. I’m sure that is an exaggeration, but it is true that many project managers have a tendency to assume a somewhat directive leadership style.
  • For years, that has been an essential characteristic of many project managers – you can’t just sit on the sidelines and let a project run its course without some kind of direction and leadership.
  • Agile changes that paradigm dramatically by emphasizing self-organization and empowerment of the team and positions the Scrum Master in the role of a “Servant Leader” to support the team rather than leading and directing the team.

What’s the Impact on Project Managers?

So, where does that leave the project manager? What value does he/she provide to an Agile team? I think the appropriate answer to those questions is that “it depends”.

  • A lot of people will say that a project manager can’t possibly play the role of a Scrum Master because the roles are so different. I don’t necessarily agree with that perspective…that perspective is based largely on the stereotype that all project managers are only capable of operating in “command and control” mode.
  • I believe a good project manager has learned over the years to develop an adaptive leadership approach that’s appropriate for the situation and I think that’s very appropriate in an Agile environment.

There is an idealistic Agile view that all Agile teams are totally self-organizing, completely empowered, and require little or no direction or leadership.

  • The team, as a whole, should function on its own without much direction at all – that’s true to some extent, but a more pragmatic view is that all teams aren’t necessarily at that level of maturity and some leadership is needed to help them get to that point.
  • “Adaptive leadership” is an important skill in this kind of environment…a good Project Manager or Scrum Master should be capable of providing a sufficient level of leadership to get the team to a level of self-sufficiency and progressively back out as the team reaches that level.

“Adaptive Leadership” or learning to adapt your leadership style to the situation is a very important characteristic for project managers to be successful in an Agile environment.

Additional Resources

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