Enterprise wide Agile adoption

Our definition of EAD differentiates enterprise-class from enterprise-wide. Across the organization (enterprise-wide), organizations might be doing many self-contained/independent agile development projects that are totally unrelated and that meet specific tactical needs. Or, the projects may be first iterations of agile development projects intended to help organizations gain understanding and insight into how the application solution could subsequently be grown into a more complete solution, which will subsequently be integrated into the current application solution portfolio. Most of the agile development projects we see start out without real concern for the longer-term impact on the application ecosystem and broader solution architecture. They generally fail to scale to the needed enterprise-class solution characteristics we identify in this research, even though the project may consist of hundreds of developers and be classified as enterprise-wide.

Enterprise class Agile adoption

Enterprise-class AD includes assessing the impact on the current and future enterprise solution architecture for the organization to make the right business decisions.

One of the key finding presented by the authors is that:

Agile development methods are increasingly being used within organizations as business differentiators, which is raising their profile from tactical project level to a more strategic enterprise level.

And as such, one of their recommendation is that:

Enterprise-class agile development cannot be driven only by the CIO and application development (AD) teams. Strong business commitment is essential. Don’t attempt to drive enterprise agile from an IT perspective, as it will fail.

In their research, the authors have identified seven key elements that collectively, positively impact enterprise wide software development processes. Taken together, these key elements help organizations achieve an enterprise class Agile adoption.

• Customer-Centric: Exceeds the notion of the business project sponsor to include the corporate strategies and organizational goals. The product owner and team members need to fully understand and be aware of the impact of the solution and its architecture on the overall corporate goals.
• Collaborative and Cooperative: This is not just cooperation between IT and the business, but also within IT departments across the various sections of the organizations, including teams that are not co located.
• Constant Feedback:  Though lengthy planning is often eliminated from Agile projects, due to organizational constraints it should not (and possibly cannot) be completely removed. This doesn’t mean to overly invest time and efforts but “just good enough” planning should allow projects to get started. As such, constant feedback isn’t limited to the communication between the IT and Business units but similarly with all support departments and various stakeholders.
• Heterogeneous Environment: There is no magic formula for success, and adaptation is required for a successful adoption.
• Throughout the Software Life Cycle: Agile practices, such as refactoring, applied throughout the life cycle, can extend the useful life of the application.
• Continuous Delivery: Speaks to the need of continuous collaboration between IT and the Business units in the development of a product.
• Adaptive Solutions: Discusses a compromise between a complete top-down architecture and an emerging architecture.

• An intervention approach within the organization;
• A model allowing to lessen the impact of an Agile transition.

PATH is an acronym for Process-Added value-Technologies-Human, the 4 dimensions of software development.

Processes: Efficiently deliver value with a simple process adapted to the project’s needs (lowest cost within time).

Added value: Deliver functionalities and maximize their business value (prioritization and flexibility).

Technologies: Deliver quickly and consistently with appropriate engineering practices (sustainable pace and skills development).

Human: Deliver at a sustainable pace and in harmony while promoting team work (collaboration and communication).

In addition to the dimensions, the PATH model introduces 3 influence levels—vision, funnelling and emergence—that, when applied to all 4 dimensions, produces 12 intervention areas.

Vision

The ‘Vision’ level shows the orientation to meet established objectives. This level is generally linked to the strategic vision of the organization. The vision represents the objectives to achieve.

For instance:

Maximization of return on investment:

• Connection between the IT group and business units, and globally between all stakeholders
• Development of inter-project synergies in order to adopt best practices and pool them
• Management of simple and adaptable projects in order to reduce administration fees
• Capacity to innovate in order to be equipped with the tools required for the organization to evolve
• Capacity to anticipate in order to gain a competitive edge
• Greater respect for budget allowance

Maximization of a cooperation and collaboration culture:

• Better team organization
• Evolution of the strategy and change culture
• Adaptation of the leadership model

Performance:

• Quick project execution compared to traditional approaches
• Quality improvement of software delivered
• Establishment of parameters allowing to measure performance
• Adaption of the competency model and expertise development
• Process implementation to select initiatives

Funnelling

The main objective of the ‘Funnelling’ level is to implement mechanisms promoting collaboration (e.g. communities of practice, wikis, and blogs).

This level:

• Allows to implement a communication approach in order to make the vision visible
• Allows to make sure the field practices (emergence) are aligned with the objectives established at the ‘Vision’ level

Therefore, funnelling allows the emergence of the best practices arising from development teams as well as the dissemination of these practices to all groups that may benefit from them. Therefore, the ‘Funnelling’ level acts as an information catalyst and aggregate.

Globally, the objective of this level is to ensure reuse of:

• Tools
• Practices
• Experience acquired by stakeholders

Emergence

The ‘Emergence’ level is the level for project teams developing software solutions. It is important to implement new development processes and train team members on how to apply Agile principles.

At this level, transformations imply:

• New ways of doing
• A behaviour oriented towards collaboration in order to achieve established objectives
• The implementation of methods allowing to obtain best results

This presentation is introductory level as it introduces some of the most common reasons why organizations choose to adopt Agile approaches. It presents some high level statistics on software development project success (and failure) to demonstrate why the traditional project management approach may not always be the best approach to successfully deliver projects.

The presentation introduces what Agile is (and isn’t) and the reasons justifying its adoption. Once the Agile concepts have been presented, the material introduces the Scrum approach by giving a walk through of a typical process.

The presentation ends with the main impacts on people managers within organizations who are adopting Agile.

I hope you will find the presentation useful to help you move your transition in the right direction. Feel free to circulate the material.

• Scrum exposes and makes visible the organizational issues in project delivery, which are not necessarily exclusive to agility (non-dedicated projects resources, difficulty of co-locating project members, etc.);
• Positive impact on the role of the managers by moving from a command-and-control mode to coach-leader mode;
• Not just doing things right but doing the right things;
• Increased mobilization of project participants;
• Better team synergy – increased synergy between Business and IT;
• Puts the business needs at the center of the project team’s focus – business needs understood and shared by the team members;
• Brings back the “common sense” in carrying out the project;
• Better communication and transparency within teams;
• Better visibility on the business value generated by the project;
• Optimization of the investment;
• Ability to “test” the feasibility before fully developing the solution.

These are only a handful of benefits. What benefits have your team witnessed since starting Scrum?

During the meeting, the client explained that now that they had experience with 10 pilot projects, they no longer needed help coaching other project teams in the organization. They recognized the benefits of working with coaches to quickly develop the rights skills and abilities but they could now do it all by themselves.

Let me state it clearly, I believe the end goal of external consultants is to ensure their client can become fully independent and autonomous.

That being said and before I go on with this post I need to say (to be truly candid and transparent) that I have told the client – in person – what you are about to read.

The client’s objective is to successfully complete over 20 Agile projects in 2011 and then 200 in 2012. In itself, that sounds like an aggressive but feasible plan but here the catch: the client believes in magic!

Magic? You be the judge.

The client explained that they had to cut back on the budget for the coming year – which I fully understand – but despite the set back, they were continuing their organizational wide Agile transition. “We have everything we need”, they said.

• “We are heavily recruiting Agile coaches” – considering the size of our market, it is doubtful they will find all the people they need;
• “We are putting the heads of the various PMO (project management office) bureaus in charge” – having worked with some of these traditional individuals, it is difficult to see how they could lead an Agile transition;
• “We have produced a detailed guide to adopting Scrum” – I asked if they remembered Individuals and interactions over processes and tools;
• “Our people managers are already Agile” – I wondered what that meant;
• “We have hired a change management expert to document the roll-out process” – Individuals and interactions over processes and tools;
• “We expect each project team to go out and get the help they need to transition to Agile” – Why not help them?.

“Are you involving the teams and people who will be impacted?”, I asked.

“No need”, they answered. “They only need to execute on the plan we will give them”.

Granted, everyone around the table was already sold to Agile so everybody was working toward the same objective. The question was how to bring traditional organizations to switch their ways of doing things in order to adopt a more Agile approach? The debate was “Should we use a big-bang approach where all the energy is put toward getting the organization to take a quantum leap?” or “Is it preferable to use small steps in an effort to bring the organization toward the desired state?”.

Some people around the table argued that to quickly gain acceptance and shock the system, it is better to take somewhat of an extreme position and avoid deviating from the goal and as such, implement the Agile practices without consideration to the context.

Others (including myself) believed that the hard position and extreme approach doesn’t help much. It typically polarizes positions and creates an environment where conflicts are frequent. Personally, I believe that small steps taken in the right direction are much better than attempting to quantum leap forward when it comes to large scale transitions.

As consultants we are called in to help organizations transition from a current state to a future and hopefully better future. We bring our expertise and our convictions to the table in the hopes that we can influence these organizations. What happens when the consultants’ perspective collides with the organizational culture, values, processes and people? Of course, it depends.

Needless to say implementing change is a difficult task and if it was easy, nobody would need help (i.e. consultants). But when consultants adopt the following approach:

• I need to change the organization;
• The best way to accomplish this objective is to stick to my position – no matter what – until the organization realizes that I am right (i.e. they are wrong);
• I will be successful for as long as I can hold my position.

What comes next is usually a dead coach…

Granted, the other extreme is no more useful when the organization thinks something like this:

• What we have been doing is exactly what needs to be done;
• We have all the answers and we will stick to our position – no matter what – until everybody accept the current situation;
• We will be successful for as long as we can hold our position.

What comes next is an organization that will be less (and less) adapted to its environment and a Darwinian (survival of the fittest) consequence will happen.

So what is the right thing to do?

If you are a consultant, it is always a difficult balance between sticking to your position and completely letting go. The answer obviously varies by organization but sticking to a hard position is rarely (i.e. never) a good approach to actually change an organization.

The soft-minded man always fears change. He feels security in the status quo, and he has an almost morbid fear of the new. For him, the greatest pain is the pain of a new idea. – Martin Luther King Jr.

Do you ever face resistance when attempting to implement a new idea or a new concept? I often notice interesting behaviors when helping teams and individuals transition to Agile. In fact, I notice strange reactions whenever there is a change management initiative underway.

In such circumstances, the first question that comes to mind is “Why is this individual afraid?“.

In my opinion, people are typically afraid for 2 reasons: they have had a bad experience in a similar situation in the past or they anticipate that the change will cause unwanted results. Either way, my approach is the same.

Being afraid is normal and is not limited to humans (for sake of this post, let’s limit ourselves to humans). As babies we learn through experience and the recommendations of our parents – the stronger the initial experience is, the longer it remains encrusted in our brain.

Let’s admit that many change initiatives have led to very negative impact for people. Remember enterprise re-engineering? What about outsourcing? Do you think people who lost their job as a result might be afraid of other organization-wide initiatives??

As change agents, it is our role to dig into the reasons behind the fears. I’m not talking about psychology, I’m simply talking about root cause analysis of the situation in an attempt to properly address the concerns. To do so, coaches must ask powerful questions and keep silence to make room for valuable information to be shared.

Once we understand the motivation or the source of the fears, we then need to be truthful and honestly tell if the situation will (or won’t) lead to the feared consequences. In the cases where it may actually lead to the expected consequences, we should engage the individuals into finding potential solutions or way to mitigate the unwanted conclusions.

How agile you are doesn’t matter. Whether you are 50 per cent agile, 90 per cent agile or agile through and through (what ever that means), doesn’t matter. What does matter is that your company is satisfying its customers, stakeholders, and employees. (Achieving Agility: Means to an End, or End in Itself)

But let’s face it, people like to know where they stand compared to others. Starting at a very young age, we have been raised and trained to compare our results to others in an attempt to reach the next level – whatever the next level may be.

We get into such comparison as:

• Are my grades better than Tommy’s?
• Can I run faster than Carl?
• Am I stronger than black belt Anna?
• Did I earn more frequent flyer miles than Frank?

It’s the same thing with Agile. People – managers and executives mostly – really have the need to know they are headed for the top of the maturity model. It may not make much sense but they have been raised and trained to measure, to compare, and to brag when comparing favorably or to adapt when comparison isn’t positive for them.

As I already stated, I agree with Esther when she says that it doesn’t really matter how Agile you are. What matters are the results. So along those lines, I believe it is important to associate the level of maturity and the related results which I believe exist and can be demonstrated.

Unfortunately, there isn’t much hard data to demonstrate that achieving a certain level of maturity provides x% of improved performance or y% cost reductions but most of us who have been implementing Agile within organizations would agree that that higher the maturity, the better the results. So it is based on these observations that I decided to present yet another Agile Maturity Model.

As recently reported by Forrester, Scrum being the most adopted Agile approach these days, the proposed maturity model heavily relies on the adoption of Scrum practices with a lesser consideration to other practices such as: Agile Modeling, Feature-driven development – FDD, Test-driven development – TDD, eXtreme Programming – XP, etc. By no mean I am rejecting or considering those other approaches non-important. I built this model mostly on Scrum because this is the comparison organizations are asking us to be evaluated on at this time.

The Agile Maturity Model

Level 1 – Team Level Maturity

At this level, team members have decided to adopt Scrum and/or software engineering practices without asking for approval from their manager. Some of the well known practices are used but without consistency.

Team

• A Scrum Master is in place
• The Team has adopted some of the Scrum practices and artifacts but may not use them consistently
• The process isn’t documented and tends to vary by project
• Agile practices have been self-taught
• Process is limited to the solution team
• The team doesn’t understanding the language used by the business representatives

Department

• Outside the team, almost nobody has heard or understand what Agile means
• Other teams are unaware or not interested in the approach used by the Agile team
• Mostly business as usual

Business

• Unaware or not interested in the approach used by the team
• Business as usual
• Complains that what the information technologies team delivers is not what is needed or asked for
• Misunderstanding of the language used for the development team

Project Managers

• Unaware or not interested in the approach used by the team
• Follow the traditional project management approach

Managers

• Unaware or not interested in the approach used by the team
• Business as usual

Results

• Team is slightly more productive
• Moral is slightly improved
• Much friction with project managers, people managers and the business as the team members try to teach people outside the team what Agile is and what it can do for them

Level 2 – Department Level Maturity

At this level, the practices adopted by the team members have started to be imitated by other teams within the software development department. Some of the managers have noticed the positive results of adopting the Agile approach and are tempted to replicate what they observed.

Team

• A Scrum Master is in place
• Some of the teams have adopted some of the Scrum practices and artifacts and are starting to use them consistently
• Consistency across the teams is uneven and mostly depends on the leadership and perseverance of a few individuals
• Some of the process is documented but it tends to vary by team
• Agile practices have been self-taught or a coach was hired to help the team launch their initiative
• Process is limited to the department

Department

• Mostly business as usual
• Agile is sometime discussed in departmental meetings with some interest from people outside the team immediately impacted
• An increasing number of teams are adopting Agile practices

Business

• A business analyst acts as the proxy for the business representative
• Unaware or not interested in the approach used by the team
• Collaboration between the development team and the business side remains mostly unchanged except maybe for increased interaction between the 2 groups
• Business decision are still mostly made by business analysts or architects

Project Managers

• Starting to be aware of the new practices used by some of the teams
• Mostly resistant to change since they are lacking information about the new process
• Follow the traditional project management approach
• Do not consider the Agile approach to be very solid for large scale projects

Managers

• Unaware or not interested in the approach used by the team
• Business as usual

Results

• Teams that have adopted the Agile approach are slightly more productive
• Moral is improving
• Productivity varies from one team to the next
• Some teams’ productivity is decreasing since they have hit important hurdles
• Some teams have abandoned the new approach and have gone back to their traditional approach
• Some friction between the development and the business teams in light of the new approach

Level 3 – Business Level Maturity

At this level, the solution teams have integrated the business people in the model. Collaboration (and trust) has increased and a partnership relationship is increasing.

Team

• Scrum Masters are in place
• The 3 Scrum roles are well understood and respected
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• External help has been used to achieve this level of maturity
• Team members are attending Agile conferences

Department

• There is confusion around the roles of: business analyst, architect, database administrators and project managers
• The process is documented and tends to be consistent across projects
• External help has been used to properly implement the Agile practices

Business

• A Product Owner is clearly identified and may be dedicated to their project
• The concept of incremental and iterative development is gaining more acceptance from the business representatives
• Process is slowly expanding within the business side
• Product Owners bring some of their colleagues to end-of-sprint demonstrations

Project Managers

• Starting to be aware of the new practices used by some of the teams
• Mostly resistant to change since they are lacking information about the new process
• Follow the traditional project management approach
• Do not consider the Agile approach to be very solid for large scale projects

Managers

• Awareness is increasing at the director level within IT and Business of the new Agile approach
• Many assumptions and misunderstanding remain
• A strong evangelist is in place to promote the new approach and bring together the IT and business side of the organization

Results

• Project teams using the Agile approach are more productive
• Moral of the people using Agile is much higher than those outside the Agile teams
• Some friction with project managers and people managers remain where most people tend to fall back to their traditional paradigms

Level 4 – Project Management Level Maturity

At this level, the project management approach is modified to include some of the Scrum practices. Although the department still mostly relies on the traditional PMBOK recommendations, Scrum has been integrated in the project management approach.

Team

• There is a clear segmentation between the role of the Scrum Master and that of the project manager
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• Interference with the team’s activities is almost eliminated
• The team is autonomous and the Scrum rituals and artifacts are respected and standardized

Department

• The department has adopted many of the Scrum practices and artifacts and are using them consistently
• Much of the confusion around the roles of: business analyst, architect, database administrators and project managers have been eliminated
• The process is documented and is consistent across projects
• External help has been used to properly implement the Agile practices

Business

• Product Owners are clearly identified and are dedicated to their project
• The project manager is well accepted and is part of the Product Owner team
• The concept of incremental and iterative development is fully accepted from the business representatives
• Process is expanding to the business side

Project Managers

• Projects managers are fully aware of the new practices used by the teams
• Resistance to change has been replaced with adaptation of the traditional approach to include a more Agile approach
• Agile is accepted as a solid approach for large scale projects

Managers

• Awareness of the new Agile approach is increasing at director level and above within the IT, Business, and Project Management organizations
• Some assumptions and misunderstanding remain for managers
• Training initiatives have begun for management and attendance is high
• A strong evangelist is in place at the management / executive level to promote the new approach

Results

• Project teams using the Agile approach are more productive
• Moral of the people using Agile is much higher than those outside the Agile teams
• Friction between traditional roles are being handled

Level 5 – Management Level Maturity

At this level, managers have adapted their management style to support an Agile organization. Organizational structures and reporting mechanisms are better adapted for collaboration and improved for increased performance.

Team

• Scrum Masters are in place
• The 3 Scrum roles are well understood and respected
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• External help has been used to achieve this level of maturity
• Team members are attending Agile conferences

Department

• The department has adopted many of the Scrum practices and artifacts and are using them consistently
• There is no confusion around the various roles surrounding the projects
• The process is documented and is consistent across projects

Business

• Product Owners are clearly identified and are dedicated to their project
• The project manager is well accepted and is part of the Product Owner team
• The concept of incremental and iterative development is fully accepted from the business representatives
• Process is expanding to the management level of the organization

Project Managers

• Projects managers are fully aware of the new practices used by the teams
• The traditional project management approach has been adapted to include a more Agile approach
• Agile is accepted as a solid approach for large scale projects
• Review the best practices to adapt to changing realities

Managers

• Have fully transferred the authority and responsibility to the teams to allow them to do their job properly
• Avoid interference and micromanagement
• Promote collaboration and teamwork
• Support continuous learning and do not systematically penalize failures
• Adapt their management style to the context of their team

Results

• The various projects using Scrum are more productive than those using a traditional approach
• Moral is high all around
• Friction around the new approach has disappeared
• Strong collaboration between all parties involved
• Organization is able to quickly react to changes in its environment
• Management is considering implementing Agile to projects that do not require software development

Level 6 – Corporate-wide Level Maturity

Utopia or the nirvana? At this level, the entire organization – the people, the processes and the tools are aligned with the Agile principles and values. As I haven’t had the opportunity to witness such an organization (yet), I am unable to describe the criteria to be used to qualify for this level.

Other useful Links

• The Agile Maturity Model (AMM) posted on April 1, 2010.
• Does Agile Need Its Own Process Maturity Model? posted on June 1, 2009.
• Scott Ambler Revisits Agile Process Maturity Models posted on April 27, 2009.
• Agile CMMI: Complimentary or Oxymoronic? posted on December 19, 2008.
• The Agile Maturity Model posted on August 2, 2008.
• Does the Agile Community Need a Maturity Model? posted on October 16, 2007.
• An “Agile Maturity Model? posted on June 7, 2006.

As such, we have decided to implement a strategy for those “out of transition” teams. Below is the approach we selected in order to make the transition successful without negatively impacting the performance (and the workload) of those directly involved in the transition. Based on our experience, we felt it was important to have a strategy (albeit minimal) to support other projects to be implemented using an Agile approach.

The reasons why it is important to have a strategy for those “out of transition” projects are as follows:

• To maintain a unifying vision of what we are trying to accomplish with Agile;
• To maximize our efforts in the development and selection of tools supporting Agile;
• Not to ‘abandon’ the projects that were not deemed highest priority;
• For other projects to be executed successfully in an Agile mode even if they are not part of the intial selection.

Therefore, we suggested having a reduced service catalog for the “out of transition” projects. Examples of services that can be offered are:

• Training courses offered to the selected projects could also be attended by “out of transition” participants;
• A simple audit of the “out of transition” projects’ practices and high level recommendations for improvement;
• Limited support;
• Access to the corporate wiki for information, knowledge sharing and best practices.

So far, the recommendation has been well received by the “out of transition” projects. In the months to come, we will be able to determine if we made the right decision.

• We are hoping to improve productivity;
• We aim to decrease time to market;
• Turn over has been high and we wish to implement an approach that will increase employee morale;
• We need to reduce costs;
• Etc.

And then, I get what I would call “wrong answers”. Those answers address my question at face value but also show that the decision has not been evaluated for more than thirty seconds. Here are 7 “wrong reasons” to adopt Agile. Go ahead – share yours!

1. We recently attended a conference and Agile is becoming more popular. If others are doing it, so should we.

2. Because Gartner and Forrester say so.

3. Because employees asked us to do so.

4. Some of our people are available to experiment with a new approach.

5. Our competitor is gaining market share and they are using Agile. We need to use the same approach if we want to be able to compete.

6. We produce too much documentation.

7. Because our boss told us to do so.

Other interesting articles:

Destination: Agile Top Eight Reasons Why Organizations Are Making the Switch

3 Reasons Why I Would Not Do Agile Project Management

Introducing Agile Methods: Mistakes to Avoid

Why Agile doesn’t sell with Management ?

11 Ways Agile Adoptions Fail