Pseudo Agile, Hyper Agile – Isn’t Plain Agile Enough?

By Dr. Willis H. Thomas, PMP, CPT

This article discusses approaches that are being used by some organizations who are utilizing agile principles in an ad hoc fashion in an attempt to realize its benefits. It stresses the importance of agile maturity, which can be segmented in five stages:

Familiarizing Emerging Embracing Applying Optimizing
Project teams begin to see the benefits of Agile as they compare it to other methods of project management, i.e., Waterfall, they may be currently using. Project teams receive basic training on agile principles and understand how, where and when it can be implemented in the organization. Project teams become certified or qualified in agile and are now able to convince key stakeholders that agile will work effectively and efficiently and gain their support to champion key initiatives where agile can be used. Project teams who have been certified or qualified are utilizing agile methods based upon industry guidance and best practices. Project teams have advanced their certification or qualification to agile job descriptions and organizational structures. They are now in a position to promote continuous improvement.

As you consider the maturity model represented above, it is important to keep in mind that this is only one way to look at how an organization’s adoption of agile will become stronger over time. The important thought here is that project teams must keep in mind that agile principles require patience and change management as the culture of an organization will likely change.

Many organizations have embraced Agile and are convinced it has:

  • Enhanced project coordination, i.e., streamlined documentation
  • Improved project communication, i.e., faster stand-up meetings (huddles)
  • Streamlined project cycle time, i.e., working in sprints to allow for changing requirements
  • Strengthened project teams, i.e., empowered self-directed work teams
  • Encouraged best practices, i.e., modernized development approaches

Because some organizations have not realized formality in their agile approach, they will utilize terms such as pseudo-agile to indicate where they are on the agile maturity scale. The term pseudo actually means false, pretentious and not real, but in the concept of agile it has been redefined as partial, somewhat or interim. In other words, pseudo-agile is not perceived as negative by some critics, but rather a natural evolution in transitioning from waterfall to agile.

Technically, it is preferable to avoid this terminology of pseudo-agile when referring to where your organization is at in its adoption of agile simply because it can be misinterpreted or confusing. Other terms that may be more appropriate to describe adopting agile include:

  • Being at an interim stage in transitioning to agile
  • In the initial stages of agile implementation
  • Intermediate knowledge of agile principles
  • Established and follow basic agile principles
  • Hybrid approach to software development

It is important to remember the concept of pseudo-agile might have a negative connotation:

  • Being wishy-washy in the commitment to adhere to agile principles by training team members
  • Using some agile processes, but really preferring to adhere to a waterfall model
  • Meeting infrequently in stand-up huddles, but usually electing to gather in sit down meetings
  • Documenting some aspects of the project extensively and others barely to reduce overall size
  • Taking short cuts in testing and development instead of optimizing the project life cycle

As one author expressed it, “Pseudo-Agile is a slow poison to Software Quality. Pseudo-agile is a dangerous practice for the Software industry. It impacts both the Software design & testing effectiveness. It’s a slow poison whose effects are not immediate.”

This has become increasingly important, especially for software developers who are experiencing increased pressure from their clients to keep up with the times and start utilizing agile approaches in software development to reduce cycle time. These software developers cannot afford to risk their credibility and state that they are pseudo-agile.

On the flip side of the coin, there are critics who have embraced agile and are excited about new advancements in agile methodology. Despite the obvious benefits of agile, the question remains – how do we make things (products, services and results) even “Better – Faster – Cheaper?”

In search of improving agile leads to some interesting philosophical discussion and an attempt to arrive at new terminology. Some people might refer to this as hyper-agile. In an article by Kayleigh Bateman, she talks about “speedy innovation” as a must for survival and says hyper-agile is the next big leap forward for larger organizations. Mike Chang has a completely different perspective on hyper-agile, calling it a term for “an agile organization that has become so obsessed with rapid prototyping and iterating that its processes start falling through the cracks.”

So the real key to the success of hyper-agile, should you choose to pursue it, is balance.

Hyper-agile can be thought of as:

  • Agile on steroids
  • Vitamin-based agile
  • Agile using templates
  • Agile with shortcuts
  • Agile probiotics

Essentially, the thought of hyper-agile is to enhance available tools and techniques to make agile more efficient. It may also incorporate the use of mobile apps that can streamline processes.

Reasons why some project teams struggle to properly adopt agile:

  • Organization has not embraced agile
  • Team members are not trained on agile
  • The development model, i.e., software has not been formalized with agile principles
  • They have not evaluated agile return on investment (ROI) or return on quality (ROQ)
  • They did not anticipate the challenges and key learnings when transitioning to agile

There are no firm statistics on how long it takes an organization to transition to agile. Some reliable estimates that can be considered include the length of time that it takes to certify or qualify project team members and how long it takes the project team to become comfortable with agile principles, i.e., stand up meetings in the form of huddles vs. traditional sit down meetings. Note: This is not to say that every agile meeting should be a stand-up huddle.

In summary, agile in and of itself is enough. Project teams do not need to be pseudo-agile, nor is hyper-agile going to enable a project team to see enhanced performance. Looking at agile concepts in stages of maturity is a better indicator on how to link project performance. This statement is supported by industry experts who support agile maturity models through research.

IIL can support your organization on its journey to agile maturity.
Contact Us to Learn More

About the Author

Willis H. Thomas, Ph.D., PMP, CPT has worked for large corporations and academic institutions in the areas of human resources, learning and development, quality assurance, project management, sales and marketing, measurement and evaluation, and operations. He has been in senior management for life sciences companies for the past 15 years. Dr. Thomas is a member of adjunct faculty at the Lake Forest Graduate School of Management, International Institute for Learning and Institute of Validation Technology.

His publications have received global recognition from associations such as the Project Management Institute (PMI) where he received the Cleland Award for “The Basics of Project Evaluation and Lessons Learned.” This book was an 8-year effort that enhanced the framework for the evaluation of projects using the PMBOK® Guide. He has been a featured speaker on an international basis and has received the Apex Publication Excellence Award for implementing useful tools for project management, evaluation, and training.

Transforming to an Agile Enterprise

By Sandeep Shouche

Most executives will hear the Agile buzzword and ask their teams to “do this agile thing.” For many executives, Agile only means: Do it even faster than before. Deliver whenever I want it. Don’t question when I want to change it.

True “Agility” is a much deeper change and most enterprises will underestimate the amount of change they will experience when they adopt Agile. There are several deep-rooted habits that have to be kicked and some new ones have to be embraced.

While there are many organizations that claim to be an Agile enterprise, very few actually behave like one. But what exactly goes into making an Agile enterprise? An Internet search reveals a lot of marketing pitches, but not a lot of guidance about how to become one.

In our observation, there are a number of characteristics that go into the successful making of an Agile enterprise. So here are some views about what an Agile enterprise looks like.

It all starts at the top. The senior executives understand what Agility means and lead by example.

Some of the ways in which this manifests itself are:

The portfolio of the organization is dynamic. They recognize that change is the only constant and there is no such thing as “certainty.”
They will not hesitate to make strategic decisions whenever the time is right and not just in “strategy summits” where a chosen few executives make plans for the rest of the organization for a year or more.
They make clear priority calls whenever required. They do not start several initiatives all at once, keeping the amount of work in the system at a reasonable level.
Prioritization is always based on potential to create customer value. Other considerations (like preferences of the team, opinions and political pulls) play second fiddle.
They understand that nothing is delivered perfectly the first time. They encourage teams to experiment. Rather than bully teams into building the perfect product with ridiculous deadlines, they encourage them to unlock value quickly by delivering incrementally.
They realize the final solution and product can only be arrived at through a process of experimentation and use of iterative methods. They encourage their teams to take risks and make it safe to fail sometimes.

The organization focuses on products rather than projects.

Instead of focusing on project-centric measures like schedule variance and cost variance, they focus on product-centric measures like “value delivered.”
They don’t try to optimize for project delivery. Instead, they focus on the product-related business case (because products will last several years, whereas projects are ephemeral).
They frequently question the business case of the product even during the projects that occur during its life-cycle. They will gracefully exit products which no longer make business sense.

The organization embraces a Lean culture.
They apply Lean principles and embody the philosophy of continuous improvement.

They frequently stop to fix problems, rather than quickly apply band-aid fixes.
They encourage the teams to look for improvement opportunities to reduce “waste”. Most of the incremental improvements come from the team, rather than top-down.
They work on a few things at a time and complete them, rather than leave too much work on the table.

Their teams are cross-functional, able to cut across silos and truly collaborate to unlock value for their customers through high quality products and services.

Disagreements and conflicts are always resolved by focusing on “how does this increase customer value?” rather than political positioning.
Before demanding something from other departments, each department first focuses inwards and comes up with constructive suggestions.
Everybody’s incentives are governed more by their contribution to overall customer value rather than their individual output.

They are completely transparent with their stakeholders, especially their employees who feel empowered and valued.

Across the organization, everybody is aware of what “customer value” really means and they strive to maximize it.
Their plans are realistic rather than aggressive. They know that keeping everybody busy is less important than ensuring that they all contribute to building value.
They do not lull the customer into false sense of security. They willingly share information about potential risk factors. They offer a high-level roadmap and a detailed, short-term plan to recognize the uncertain nature of the business.
They never hide bad news from their customers. They willingly admit mistakes or slippages and always offer a plan to make it better rather than blame others or the environment.

Many of the above might seem to be platitudes – “motherhood and apple pie” statements. To ensure that they do not just remain in policy documents or on the walls, it is important to develop indicators and measures for each statement that will prove that either you are meeting the requirements or that you are not.

What we are talking about is a “balanced scorecard” for an Agile enterprise. Of course, each organization is unique and the scorecards will be different for each organization.

For more information about how to build one for your organization, do get in touch with us.

About the Author
Sandeep Shouche (PMP, PgMP, PMI-ACP, CSM, CSP, [ASM.EN], ITIL Expert, PRINCE2) is an expert in the areas of project, program management, Agile methodologies and IT Service Management. He has over 24 years of project management experience in different industries and geographies. Sandeep has been on the Board of the Project Management Institute – Pune Chapter. He has authored and been featured in several articles and conferences related to project and program Management. Outside of work, Sandeep is deeply committed to voluntary work for social causes and has a profound love of the mountains.


IIL Onsite Learning Solutions – Contact us today to request a free consultation


The Agile Transformation Challenge All Organizations Face

By Erik Krisko, Enterprise Transformation Coach and Consultant

I feel very fortunate to have the opportunity to present at this year’s 2018 Agile and Scrum Online Conference, hosted by the International Institute for Learning (IIL). In my session “From Freight Train to Airplane: The Automotive Transformation”, I discuss Enterprise Transformation efforts taking place to prepare one of the World’s largest automakers for the ‘Consumer of Tomorrow’, and the challenges in doing so.

One challenge that every transformation in every organization is subject to is psychology, and it is one that is frequently overlooked. The impact of expansive change is dealt with in different ways, by different folks. If not taken seriously, there is a very good chance of a dark cloud hanging over the entire effort. Transformation is not driven by strategy, it’s driven by people. To build a support system that you will need to achieve sustainable success, people’s feelings and concerns require the respect and attention that is too often trivialized.

Here are a few recommendations to help people deal with these changes:

Be a Leader, not a Manager

Contrary to the beliefs of some in positions of authority, these two are not the same. Simply pointing to the X’s and O’s from an ivory tower does not inspire people. I have worked with individuals clueless about the intricacies of their business and yet were still able to succeed. This success wasn’t because of their acumen, but a result of their ability to inspire, and their willingness to check their ego at the door. Regardless if you are in an ‘official’ leadership position or not, humility, selflessness, emotional intelligence, and confidence are some of the key strengths of effective leaders. These traits are what people look to rally around as they walk into the unknown.

Be aware of your influence on others

I’m always surprised at the lack of awareness people have in how their emotions and attitude affect others around them. Emotions are contagious, attitude is infectious, and both can work either for you or against you. The continuity of a high performing team hinges on the dynamic of those in it, and even a small amount of toxicity can be detrimental. Displaying calm in the face of adversity, confidence in making decisions, and having the courage to take accountability and accept constructive criticism can go a long way in how people interact with you, and each other.

Future Shock is Real

For those who don’t know what ‘Future Shock’ is, basically it’s a natural inclination to psychologically withdraw out of fear when too much is changing too fast. Because of the substantial fiscal investments organizations can make in their transformation, it can come with very aggressive timing expectations. This means “change a lot, and change it fast.”

While I certainly can’t blame an organization for wanting to see a speedy ROI, psychologically it doesn’t work like that. To get people out of their comfort zone, and achieve some momentum, people need to be presented with reasonable expectations and measures of success. Set goals that are realistic, attainable, and easily applicable in performing their work. Once they experience success, and start to understand the benefits of continuous improvement, the odds of sustaining that success increase substantially.

These suggestions are just…suggestions. If you’re looking for a silver bullet, good luck finding one. I can say with a high degree of confidence that if you do not respect the psychological ramifications of change, you are playing with fire. Adversity already has a head start, why give it more?

About the Author
Erik Krisko is an Enterprise Agility Coach and Consultant that has worked with some of the world’s largest brands, specializing in Holistic Agility and Enterprise Transformation. Currently engaged in the Automotive Industry, he resides in suburban Detroit with his wife and two children.

How to achieve the Agile Transformation — Part 2

As mentioned in the previous article, Agile involves moving to a new way of working on projects; therefore, it brings its own set of issues that must be dealt with. Here are a few of the more common ones:

  1. Organizational Culture

Organizations are typically top-down in nature, meaning there is a clear chain of command, a clear hierarchy. This manifests itself in projects to the extent that the project manager is in charge of running the project and team members report to him or her, even if only for that project.

Agile turns this paradigm on its head. For starters, there is no project manager as such. It is commonly believed that the Scrum Master is just a renamed PM. But that is not true as the Scrum Master’s job is to facilitate, to remove impediments. It is not his or her job to tell the team what to do and when to do it.

So who does that? Well, this is the second issue that traditional organizations have to deal with in the Agile Transformation – teams are self-organizing and responsible for their own work.

So you can see that this creates problems for (at least) three entities

  • The Project Manager who may now be a Scrum Master and is used to giving orders.
  • The team who is used to being told what to do.
  • The product owner who may not be entirely comfortable with this brave new project world.

One possible solution to this is education. By education, I don’t necessarily mean that everyone on all teams must go to class. But on-the-job training and informal sessions, preferably run by an Agile coach, that consist of executive briefings and team training.

  1. Resistance to change

“it’s how we always did business” or something like that that was viral 1-2 years ago.

As touched upon in the first post, organizations (and people) tend to be resistant to change. If it isn’t broke, they will tell you, don’t fix it. The problem is that “it” is often broken and they still don’t want to fix it.

Numerous studies along with anecdotal evidence over the years have demonstrated that people resist change for any number of reasons – comfort with the status quo; fear of what will happen to their job; concern about whether the change is really necessary or will do any good.

It will take a deep behavioral research to analyze the reasons behind the reluctance to change, but some of the most common questions heard include: What does this mean for me and/or my job?

  • Every time we have a change, it just means more paperwork
  • There’s always a new flavor-of-the-month we have to learn. Agile will fall by the wayside too

So the reaction to change isn’t just because people don’t like it, there’s also an emotional component. According to one study, “directed change is driven from the top of the organization, relies on authority and compliance, and focuses on coping with people’s emotional reactions to change.1

  1. Misunderstanding or subverting the process

I went to an Agile networking session a short while back. It was clear to me that a lot of people in the room were new to Agile and were trying to get their arms around it.

As part of an exercise we were asked to do, I discussed the challenges of implementing Agile with a gentleman from a manufacturing company. When he told me they were having trouble establishing the backlog of requirements, I asked him who the product owner was. He shrugged and said, “I guess I am.”

And that to me signifies much of the problem with Agile implementations that are currently ongoing. Someone either decides to use Agile or is directed to use it. But they learn a few key terms, maybe time-bound their work in sprints, never get any real training and then dive right in.

Agile is meant to be nimble, not chaotic. The fact that it’s not as process-driven as waterfall does not mean anarchy should be the order of the day. It has certain rules, guidelines, and precepts. Scrum has a 17-page document of rules and guidelines which, based on anecdotal evidence alone, not too many people are aware of, much less have read.2

By subverting the process, we mean that organizations try to bring command-and-control techniques to a process that does not work well with them. Asking Jen to become a Scrum Master because she “really knows how to crack the whip” is not what is called for. What Agile needs is a good facilitator who listens to people, knows how to remove impediments and can coach teams.

So if you’re planning an Agile implementation, here are some ideas:

  • Realize that it’s all about change and bring in change agents to guide you through the process
  • Get an executive briefing and bring in an Agile coach to train the team
  • Run a pilot project of 4-6 months. Don’t make it a “bet the farm” project but be sure it has at least some importance to the company
  • Put a mixture of enthusiasts and even naysayers on the team. You are going to want to roll this out to the larger organization or enterprise and you need a laboratory of sorts to simulate what it’s like

The Agile Transformation is not something to be taken lightly. Like all new methods or processes, you can introduce it methodically and respect its guidelines or do so haphazardly and hope for the best. As someone wiser than me once said, hope is not a strategy.

  1. Rethinking Organizational Change: Reframing the Challenge of Change Management. Kenneth Kerber, Anthony F. Buono. Organizational Development Journal. Fall 2005.
  2. The Scrum Guide. Ken Schwaber and Jeff Sutherland.

Jim Stewart PMP, CSM  has over twenty years’ experience in managing projects in IT, financial services and pharmaceutical. A PMP since 2001 and Certified Scrum Master since 2013, he frequently helps organizations increase their project maturity by incorporating best practices.

How to achieve the Agile Transformation — Part 1

By: Jim Stewart PMP, CSM

What pushes organizations to embrace Agile and what projects waterfall won’t serve.

Organizations that run projects are increasingly looking at transforming the company toward using the Agile methodology. For one example, GE – who is heavily involved in the “Internet of Things” – is having not only developers but also managers trained in . But before we can define exactly what the Agile transformation is, a little background is in order.

For years and years, companies that run projects have done so using the classic ‘waterfall’ methodology, so-called because the phases cascade down from one to the other like a waterfall.

But increasingly, organizations are looking for ways to demonstrate business value faster, to adapt to changing requirements and to deploy teams that are more nimble and self-organizing.

In short, they are considering the Agile methodology. There are several variants of Agile including Lean, Scrum, Extreme Programming, etc. But most Agile adopters are considering using the Scrum methodology.

There are certain types of projects for which Agile is especially well-suited. (And not always software projects. IIL’s sales team and marketing department use Agile to manage their workload and have daily stand-ups for their regular meetings.)

Good options for going Agile include projects where:

  • Requirements are not well-understood or cannot be articulated
  • There is a high degree of complexity and uniqueness
  • There is a high degree of uncertainty
  • The greatest potential benefit is for complex work involving knowledge creation and collaboration, e.g., new product development

Scrum has certain tenets or guidelines that must be met for the project to even be considered Agile. It must:

  • Use time boxes sprints, typically of 2 – 4 week duration
  • Have short daily meetings (scrums)
  • Use a Scrum Master who facilitates rather than a project manager
  • Employ self-organizing teams who decide what to work on and how to do it
  • Be guided by a concept called servant leadership

The concept of servant leadership was developed by a management expert Robert K. Greenleaf. Having spent many years at AT&T, he felt that the authoritarian methods of managing in organizations were not meeting the needs of either management or workers.

Greenleaf discusses the “need for a better approach to leadership, one that puts serving others — including employees, customers, and community — as the number-one priority. Servant leadership emphasizes increased service to others, a holistic approach to work, promoting a sense of community, and the sharing of power in decision making.” (Italics mine.)

Greenleaf’s characteristics of the servant leader include listening, empathy, healing, awareness, persuasion, conceptualization, foresight, stewardship, commitment to the growth of people, building community.”1

And so those companies that are looking to ‘Go Agile’ are looking at what has come to be known as an Agile Transformation. (The scope of this article concerns itself largely with companies that are making a wholesale shift. Some companies are adopting Agile only in departments, not at the enterprise level.)

So what do we mean when we say Agile Transformation? This definition is as good as any:

“The Agile transformation definition is an act of transforming an organization’s form or nature gradually to one that is able to embrace and thrive in a flexible, collaborative, self-organizing, fast changing environment. The Agile Manifesto2 values and principles can be taught and exercised throughout any type of organization as it does not just apply to development teams.

The entire organization needs to understand the definition of an agile transformation and the value of it in order to benefit from the rewards of achieving true, healthy agility. The complete cultural and organizational mindset must change to one that embraces a culture of self-organization and collaboration.”3

Note that the definition of Agile Transformation does not say something like “project teams will learn to be self-organizing using Scrum Masters” or “there will be daily Scrums and time boxes called Sprints.” Sure, as noted above, those are true.

But note the last sentence of the definition. It speaks of a “complete cultural and organizational mindset change.” It should be obvious to anyone who has spent more than five minutes working for an organization that effecting change is one of the most difficult things you can do.

But like it or not, the hallmark of any Agile transformation is change. Unless companies that are considering doing transformations are open to the idea of change, the effort is doomed to failure and they might just as well stay with traditional project management techniques.

So it seems to me that the first prerequisite to any Agile Transformation within companies is for its leaders to be open to a new way of doing business.

In the next post, we’ll talk about the challenges inherent in an Agile transformation and how to deal with them.

  1. The Art And Science Of Servant Leader In Agile Scrum World. Sreedhar Khoganti. PM Times.
  2. The Agile Manifesto. A formal proclamation of four key values and 12 principles to guide an iterative and people-centric approach to software development.
  3. Agile Transformation: Understanding What it Means to be Agile. Cast

Jim Stewart PMP, CSM  has over twenty years’ experience in managing projects in IT, financial services and pharmaceutical. A PMP since 2001 and Certified Scrum Master since 2013, he frequently helps organizations increase their project maturity by incorporating best practices.