The Disciplined Agile Mindset

By Scott Ambler | Vice President, Chief Scientist of Disciplined Agile at Project Management Institute

 

[This post is a supplement to Scott’s upcoming keynote at IIL’s Agile & Scrum 2020 Online Conference]

The DA tool kit supplies straightforward guidance to help you, your team, and your enterprise increase your effectiveness. The DA tool kit shows you how to apply and evolve your way of working (WoW) in a context-sensitive manner with this people-first, learning-oriented hybrid agile approach.  We describe DA in terms of four views: Mindset, People, Flow, and Practices.  In this blog I describe the mindset behind PMI’s Disciplined Agile (DA) tool kit, overviewed in Figure 1.  PMI’s approach to describing the DA Mindset is straightforward: We believe in these principles, so we promise to adopt these behaviours and we follow these guidelines when doing so.

Figure 1: The Disciplined Agile Mindset.

 

The Principles

The principles of the Disciplined Agile mindset provide a philosophical foundation for business agility.  The eight principles are are based on both lean and flow concepts:

 

  1. Delight customers. We need to go beyond satisfying our customers’ needs, beyond meeting their expectations, and strive to delight them.  If we don’t then someone else will delight them and steal our customers away from us. This applies to both external customers as well as internal customers.
  2. Be awesome. We should always strive to be the best that we can, and to always get better. Who wouldn’t want to work with awesome people, on an awesome team for an awesome organization?
  3. Context counts. Every person, every team, every organization is unique.  We face unique situations that evolve over time.  The implication is that we must choose our way of working (WoW) to reflect the context that we face, and then evolve our WoW as the situation evolves.
  4. Be pragmatic (reworded from Pragmatism). Our aim isn’t to be agile, it’s to be as effective as we can be and to improve from there.  To do this we need to be pragmatic and adopt agile, lean, or even traditional strategies when they make the most sense for our context.
  5. Choice is good. To choose our WoW in a context-driven, pragmatic manner we need to select the best-fit technique given our situation.  Having choices, and knowing the trade-offs associated with those choices, is critical to choosing our WoW that is best fit for our context.
  6. Optimize flow. We want to optimize flow across the value stream that we are part of, and better yet across our organization, and not just locally optimize our WoW within our team. Sometimes this will be a bit inconvenient for us, but overall we will be able to more effectively respond to our customers.
  7. Organize around products/services (new).  To delight our customers we need to organize ourselves around producing the offerings, the products and services, that they need. We are in effect organizing around value streams because value streams produce value for customers, both external and internal, in the form of products and services.  We chose to say organize around products/services, rather than offerings or value streams, as we felt this was more explicit.
  8. Enterprise awareness. Disciplined agilists look beyond the needs of their team to take the long-term needs of their organization into account.  They adopt, and sometimes tailor, organizational guidance.  They follow, and provide feedback too, organizational roadmaps.  The leverage, and sometimes enhance, existing organizational assets.  In short, they do what’s best for the organization and not just what’s convenient for them.

 

The Promises

The promises of the Disciplined Agile mindset are agreements that we make with our fellow teammates, our stakeholders, and other people within our organization whom we interact with.  The promises define a collection of disciplined behaviours that enable us to collaborate effectively and professionally.  The seven promises are:

 

  1. Create psychological safety and embrace diversity. Psychological safety means being able to show and apply oneself without fear of negative consequences of status, career, or self-worth—we should be comfortable being ourselves in our work setting. Psychological safety goes hand-in-hand with diversity, which is the recognition that everyone is unique and can add value in different ways. The dimensions of personal uniqueness include, but are not limited to, race, ethnicity, gender, sexual orientation, agile, physical abilities, socioeconomic status, religious beliefs, political beliefs, and other ideological beliefs. Diversity is critical to a team’s success because it enables greater innovation. The more diverse our team, the better our ideas will be, the better our work will be, and the more we’ll learn from each other.
  2. Accelerate value realization. In DA we use the term value to refer to both customer and business value. Customer value, something that benefits the end customer who consumes the product/service that our team helps to provide, is what agilists typically focus on. This is clearly important, but in Disciplined Agile we’re very clear that teams have a range of stakeholders, including external end customers. Business value addresses the issue that some things are of benefit to our organization and perhaps only indirectly to our customers. For example, investing in enterprise architecture, in reusable infrastructure, and in sharing innovations across our organization offer the potential to improve consistency, quality, reliability, and reduce cost over the long term.
  3. Collaborate proactively. Disciplined agilists strive to add value to the whole, not just to their individual work or to the team’s work. The implication is that we want to collaborate both within our team and with others outside our team, and we also want to be proactive doing so. Waiting to be asked is passive, observing that someone needs help and then volunteering to do so is proactive.
  4. Make all work and workflow visible. DA teams will often make their work visible at both the individual level as well as the team level. It is critical to focus on our work in process, which is our work in progress plus any work that is queued up waiting for us to get to it.  Furthermore, DA teams make their workflow visible, and thus have explicit workflow policies, so that everyone knows how everyone else is working.
  5. Improve predictability. DA teams strive to improve their predictability to enable them to collaborate and self-organize more effectively, and thereby to increase the chance that they will fulfill any commitments that they make to their stakeholders. Many of the earlier promises we have made work toward improving predictability.
  6. Keep workloads within capacity. Going beyond capacity is problematic from both a personal and a productivity point of view. At the personal level, overloading a person or team will often increase the frustration of the people involved. Although it may motivate some people to work harder in the short term, it will cause burnout in the long term, and it may even motivate people to give up and leave because the situation seems hopeless to them. From a productivity point of view, overloading causes multitasking, which increases overall overhead.
  7. Improve continuously. The really successful organizations—Apple, Amazon, eBay, Facebook, Google, and more—got that way through continuous improvement. They realized that to remain competitive they needed to constantly look for ways to improve their processes, the outcomes that they were delivering to their customers, and their organizational structures.

 

The Guidelines

The guidelines of the Disciplined Agile mindset help us to be more effective in our way of working (WoW), and in improving our WoW over time. The eight guidelines are:

 

  1. Validate our learnings. The only way to become awesome is to experiment with, and then adopt where appropriate, a new WoW. In guided continuous improvement (GCI) we experiment with a new way of working and then we assess how well it worked, an approach called validated learning. Being willing and able to experiment is critical to our process-improvement efforts.
  2. Apply design thinking. Delighting customers requires us to recognize that our aim is to create operational value streams that are designed with our customers in mind. This requires design thinking on our part. Design thinking means to be empathetic to the customer, to first try to understand their environment and their needs before developing a solution.
  3. Attend to relationships through the value stream. The interactions between the people doing the work are what is key, regardless of whether or not they are part of the team. For example, when a product manager needs to work closely with our organization’s data analytics team to gain a better understanding of what is going on in the marketplace, and with our strategy team to help put those observations into context, then we want to ensure that these interactions are effective.
  4. Create effective environments that foster joy. Part of being awesome is having fun and being joyful. We want working in our company to be a great experience so we can attract and keep the best people. Done right, work is play. We can make our work more joyful by creating an environment that allows us to work together well.
  5. Change culture by improving the system. While culture is important, and culture change is a critical component of any organization’s agile transformation, the unfortunate reality is that we can’t change it directly. This is because culture is a reflection of the management system in place, so to change our culture we need to evolve our overall system.
  6. Create semi-autonomous self-organizing teams. Organizations are complex adaptive systems (CASs) made up of a network of teams or, if you will, a team of teams. Although mainstream agile implores us to create “whole teams” that have all of the skills and resources required to achieve the outcomes that they’ve been tasked with, the reality is that no team is an island unto itself. Autonomous teams would be ideal but there are always dependencies on other teams upstream that we are part of, as well as downstream from us. And, of course, there are dependencies between offerings (products or services) that necessitate the teams responsible for them to collaborate.
  7. Adopt measures to improve outcomes. When it comes to measurement, context counts. What are we hoping to improve? Quality? Time to market? Staff morale? Customer satisfaction? Combinations thereof? Every person, team, and organization has their own improvement priorities, and their own ways of working, so they will have their own set of measures that they gather to provide insight into how they’re doing and, more importantly, how to proceed. And these measures evolve over time as their situation and priorities evolve. The implication is that our measurement strategy must be flexible and fit for purpose, and it will vary across teams.
  8. Leverage and enhance organizational assets. Our organization has many assets—information systems, information sources, tools, templates, procedures, learnings, and other things—that our team could adopt to improve our effectiveness. We may not only choose to adopt these assets, we may also find that we can improve them to make them better for us as well as other teams who also choose to work with these assets.

 

Whence the Agile Manifesto?

Until recently, we described the DA mindset as the combination of the DA Principles and the DA Manifesto.  The DA Manifesto in turn was described in terms of five values and 17 principles behind the manifesto.  The DA Manifesto was based on the Manifesto for Agile Software Development, or more colloquially known as the Agile Manifesto.  But, as you can imagine, people were confused by two levels of principles.  We also found the Agile Manifesto to be constraining, mostly due to the cultural baggage that has built up around it for the past two decades.  And most importantly, we realized that we could describe the mindset in a far more robust and understandable manner as you’ve seen in this blog.

The DA Mindset provides conceptual background required for business agility and is an important part of the foundation of the DA tool kit.  I will describe how to apply the DA tool kit in my keynote presentation, Disciplined Agile Strategies for Greater Innovation, at IIL’s Agile and Scrum 2020 Online Conference. I hope you choose to attend this great event.

 

[To learn more on this topic, click here to register for IIL’s Agile & Scrum 2020 Online Conference]

 

References

For further reading about the details behind the Disciplined Agile Mindset, please read Chapter 2 of Choose Your WoW! A Disciplined Agile Delivery Handbook for Choosing Your Way of Working.

About the Author Scott is the Vice President, Chief Scientist of Disciplined Agile at Project Management Institute. Scott leads the evolution of the Disciplined Agile (DA) tool kit and is an international keynote speaker. Scott is the (co)-creator of the Disciplined Agile (DA) tool kit as well as the Agile Modeling (AM) and Agile Data (AD) methodologies. He is the (co-)author of several books, including Choose Your WoW!, An Executive’s Guide to the Disciplined Agile Framework, Refactoring Databases, Agile Modeling, Agile Database Techniques, and The Object Primer 3rd Edition. Scott blogs regularly at ProjectManagement.com and he can be contacted via pmi.org.


Capture More Agility by Tailoring Practices

[This post is a sneak preview of Jesse Fewell’s talk at IIL’s Agile & Scrum 2020 Online Conference, and is based on his upcoming book Untapped Agility]

We’ve been told that to achieve more innovation, more collaboration, or more agility, we need to adopt modern practices. Unfortunately, many of those practices seem fundamentally incompatible a team’s reality on the ground. If the experts say we have to use stable teams, product-based funding, but our current state won’t allow for it, what do we do? Short answer: We adapt. The path forward is to be agile with your agile, to transform your transformation.

Be Agile with your Agile
Transform your Transformation


Tailoring is management common sense

Much has been written in the project and product worlds about “tailoring” processes and practices, based on the work being done. Let’s pause for a moment to take a look at some key points. The idea of the PMBOK® Guide – Sixth Edition officially defines tailoring as follows:


Determining the appropriate combination of processes, inputs, tools, techniques, outputs, and the life cycle phases to manage a project is referred to as “tailoring” the application of the knowledge [of project management].

That’s a fancy way of saying that each organization should customize its approach to delivering work based on the specific dynamics and demands of the environment.

Moreover, these adjustments are not optional. The guide goes on to say:


Tailoring is necessary because each project is unique; not every process, tool, input, or output identified is necessary.

Ironically, if your PMO, Center of Excellence, or other standards group has defined their process playbook by merely copy-pasting a textbook approach from PMI, from Google, or from Spotify… they are violating the ASNI standard for project management.


Tailoring was always core to Agility

Now if you think that point is only for traditional project management and has nothing to do with Agility, then you would be mistaken. The original Agile Manifesto closes out its declaration of values and principles with this very topic, saying:


At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

That’s the conclusion, the climax, the final word. Kind of important.

So whether you come from a formal standards perspective (project management) or a more informal values-based perspective (Agile Manifesto), the expectation is the same: modify how you do your work, based on the situation at hand.

Put another way, if you believe in continuous improvement, then by definition whatever practices you are using are not optimal. If you are still using that fancy new devops method strictly out of the box, then you are simultaneously neither compliant with international standards nor consistent with the spirit of agility. Not adjusting your practices is a double-fail.


Okay, but HOW do we Adjust?

Unfortunately, there is almost zero guidance on how to go about tailoring effectively. Much of the literature in place today strongly advises that you do it but offers no filters, guardrails, or tips for doing so. That’s a problem, because if we don’t make the right adjustments we can get some very unwelcome side effects, such as:


  • If we don’t adjust enough, we still struggle unnecessarily.
  • If we adjust it too much, we lose all the benefit we’re trying to get.

How do we customize our practices without diluting their potency or even making things worse? We need to offer people a viable alternative beyond all-or-nothing.


The 3P Tailoring Technique

To do that, we can walk through a simple set of questions to figure out some degree of doing things better:


  1. Listen to their PAIN. Ask the team what is the specific frustration, difficulty, challenge they would face if we were to use a given technique.
  2. Explain the PURPOSE. Share the underlying principle of why we recommend that technique. What is the in- tended benefit?
  3. Design a PIVOT. Ask the team how might we adjust the technique so that we could get at least some of that benefit.

Here is how the process works in real life.



Tailoring Example for Documentation

Let’s say Maria the Manager wrestles with the excessive documentation generated in regulated, life-critical environments. Here’s how her team might approach that topic in their transformation.


  1. Maria’s Pain. “Experts say documents are wasteful. But we build medical devices. Those documents are how we pass compliance audits, never mind the rigor they foster to prevent tragic mistakes. ”
  2. A colleague explains the Purpose. “Remember, the emphasis of ‘working product over comprehensive documentation’ is to avoid distractions that waste time. I’m sure you can think of how to adjust your documentation practices to save time, without compromising the safety of the work you do.”
  3. Maria’s Pivot. “Well, much of our time is spent using our specifications to convey designs to the builders. But talking is faster than typing. We could accelerate knowledge sharing by including the designers and auditors in our meetings more frequently. Then writing the compliance documents will be more focused on the final product, rather than directing intermediate work. That might improve quality and speed, without losing any of the documentation the government requires. Let’s try this as an experiment for one subset of the overall product.”

That’s how it works. When moving on a journey towards new ways of working, leaders often get confused on how to adopt things like automation, stable teams, or prototyping. By making appropriate adjustments to established practices, you can help your transformation move forward, rather than getting stuck in the false choice of all-or-nothing.


[To learn more on this topic, click here to register for IIL’s Agile & Scrum 2020 Online Conference]

Jesse Fewell’s latest book, Untapped Agility, is a balanced guide to agility that gets past the hype and frustration to help frustrated leaders transform their agile transformations. Pre-order Untapped Agility today to join the movement of this groundbreaking book. After preordering, email taylor@jessefewell.com to receive the following benefits:

  • A FREE digital copy of the book
  • Exclusive Q&As with Jesse about the book
  • Autograph bookplate for your physical book copy

About the Author Jesse Fewell is an author, coach, and trainer who helps senior leaders from Boston to Beijing transform their organizations to achieve more innovation, collaboration, and business agility. A management pioneer, he founded and grew the original Agile Community of Practice within the Project Management Institute (PMI), has served on leadership subcommittees for the Scrum Alliance, and written publications reaching over a half-million readers in eleven languages. Jesse has taught, keynoted, or coached thousands of leaders and practitioners across thirteen countries on 5 continents. His industry contributions earned him a 2013 IEEE Computer Society Golden Core Award.


Key Themes at IIL’s 2020 Agile & Scrum Online Conference

By Sander Boeije

June 4th, 2020 will mark the opening day of IIL’s 5th annual Agile & Scrum Online Conference. In the past years, this conference has grown into a community of agile enthusiasts, with participants coming from all over the world and all kinds of industries. This year is no different, as #AgileCon2020 promises to be an outstanding learning experience once again. As is to be expected, the current health crisis has influenced many of the presentations this year; however, it’s rarely the main topic of a session because even amid a pandemic, agile is about adapting to change and delivering value.

This article will take you through the key themes that will emerge at Agile & Scrum 2020. Let’s dive right in.

Agile Transformation and Disruption

If there ever was a time for business agility, it is now. Organizations in all industries and across the entire globe have been forced to make radical changes in how they operate. This, of course, is due to the disruption caused by the current ongoing global health crisis which is impacting the way we interact with the world and each other. The ability to pivot and continue to deliver value to your customers has never been so important to the success of your organization. It seems that ‘Being Agile’ has become a must and it is imperative to understand how to make this Agile Transformation happen.

For more on this theme, be sure to watch the keynote presentations by Dean Leffingwell from Scaled Agile Inc., and Darrell Rigby from Bain & Company, as well as the presentations by Avi Schneier, Jesse Fewell, and Dave Sharrock.

Culture and Innovation

A second emergent theme is the need to have a strong Agile and Innovative culture within the heart of your organization. During a time of major disruption, such as we are experiencing today, applying a certain framework, running sprints, doing daily standups, or other agile events might help your team to navigate this crisis (see also the last theme discussed in this article). However, it’s the underlying widespread belief in Trust, Communication, Innovation, and Continuous Improvement that truly moves the organization forward.

Join the keynote sessions by Scott Ambler, Vice President and Chief Scientist of Disciplined Agile at PMI,  and Corgibytes’ Andrea Goulet, as well as the presentations by Shaaron Alvares and Oscar Roche to learn ways in which you can build an innovative agile culture into the core of your team or organization.

Personal Agility

A third theme that is surfacing at this year’s event is Personal Agility. Where the emphasis of Agile is mostly on teams and organizations, the individual can oftentimes be overlooked – strange, since it is these individuals who make up those same teams and organizations! And especially during a time where people might become disconnected from others, a check-in with oneself and one’s agility is incredibly relevant.

This is a central theme in the sessions by Betsy Kauffman and Louria Lindauer, and it is mentioned in several other presentations as well.

Agile Methods & Techniques

The final theme is perhaps more miscellaneous, as it relates to various kinds of agile methods and techniques that help teams to be high-performing, work with stakeholders, and deliver value to the customer. For example, keynote speaker Patricia Kong from Scrum.org will explain how you can measure the value of the outcomes that you deliver using metrics that work for you. Renee Liken, Product Owner at FordLabs of Ford Motor Company, will provide a practical way on how you can get meaningful feedback from your users. Keith Wilson will give you a comprehensive overview of Kanban. Andrea Fryrear and Jamie Champagne provide insight in agile marketing and agile analysis, respectively. And Tom Friend discusses several excellent techniques on how to manage conflict. In each case, you’ll walk away from the session with fresh ideas for yourself, your team, and your organization.

Agile & Scrum 2020 goes live on June 4th, 2020. Full on-demand access to all content will be available through December 31st, 2020. Sign up here today and get 40% off the registration price.

We are grateful to our sponsors for making this event possible. These organizations include AXELOS, Cisco, Sabre, SITA, FordLabs, Scrum Inc., Scaled Agile Inc., APMG, PDUs2Go, Steven’s Institute of Technology, ModernAnalyst, TWI Institute, AgileSherpas, Corgibytes, Champagne Collaborations, Success Agility LLC, and more.


The Grateful Agile Leader

By Susan Parente, PMP, PMI-ACP, CSM, CSPO, PSM I, CISSP, CRISC, PMI-RMP, RESILIA, ITIL, GL®CP, MS Eng. Mgmt. | Risk Management Guru – Agile Specialist – IIL Senior Instructor

We know that servant leadership is an excellent match for Agile methods. For example, in Scrum, the Scrum Master is a servant leader of the Scrum Team. What other leadership styles have a home in the Agile approach? Grateful Leadership is a style of leadership that is somewhat newer than other styles of leadership. It speaks to the fundamentals of providing acknowledgment for people on your team, what they do, and how they contribute. This article makes a connection between this style of leadership and Agile project management.

“Like Judith W. Umlas (the founder of Grateful Leadership), Robert Greenleaf (the founder of Servant Leadership) knew that you cannot build community, much less earn trust, without acknowledging colleagues, expressing gratitude and offering recognition. If Greenleaf was alive today, I believe he would say that you cannot be a servant leader without being a grateful leader.”  (Don M. Frick, Ph.D., Author of the authorized biography Robert K. Greenleaf: A Life of Servant Leadership)

There is a well-supported place for Grateful Leadership in Agile project management. For example, in the team retrospectives, where the project team members are trying to understand what they did well and what could be improved. How can you use Grateful Leadership for both of these topics, so the team can know how they improved, and how can they learn and move forward? Grateful Leadership is clearly a great match for team members to use in the retrospective, to acknowledge team members and their contributions.

Servant Leadership is also very important in Agile. The Scrum Master should be a servant leader and a grateful leader, not a delegative leader or a directive leader. When I first learned about Grateful Leadership, I immediately thought of how well it blends with Servant Leadership and serving the team. This is so fundamental to Agile and, even in traditional project management, Servant Leadership is one of my preferred ways of leading people. One of the reasons for this is that I am sometimes leading somebody who makes more money than I do, or someone who knows more than I do about the work they are doing. How could I possibly lead a subject matter expert in any sort of directive way? For example, saying, “I’m in charge and this is what you’ve got to do.” If you know somebody makes more money than you and they know more than you about the work they are doing, then Servant Leadership makes more sense.

What servant leadership looks like is, “I can’t do what you do and we need your support and efforts, so how can I help you be successful, so that you can be successful?” Unfortunately, this is lacking in many environments, but it’s very supportive in Agile, and I think bringing Grateful Leadership to the project team is also important. Anywhere one is doing stakeholder management, is an appropriate place for gratitude and acknowledgment. For example, saying “Thank You” to the product owner for being there to ask questions, being involved, being engaged, and for wanting to know how things are going with the project. There is so much to be grateful for when working on a project!

Through personal growth and development via leadership training, I realized that when acknowledgment is missing, there is something major lacking for me. If I don’t feel acknowledged, or if I don’t acknowledge others, when acknowledgment is missing, I am not motivated. I am one of those people who will stay up to 2 a.m. to complete a task or a deliverable, if needed by my client; however if I don’t feel appreciated or acknowledged for the work I do, I don’t have the drive to work extra time or even on my own time. I can work my way through something, if I feel I am appreciated. I am clear about how important acknowledgment is for me, so I recognize that it is likely important for others.

In summary, it’s difficult to do work when you don’t feel appreciated. Have you ever felt that way? Both Servant Leadership, as well as Grateful Leadership allow one to influence without authority. These leadership styles are critical for Agile projects where you may be a team member, Product Owner, or even a project manager.

To learn more about Grateful Leadership, see the Center for Grateful Leadership site, where you may obtain much more information. Membership is free, and it is priceless!

If you are interested in learning more about leadership and how it relates to Agile and the PMI-ACP certification, please email me at parente@s3-tec.com or susan.parente@iil.com, or connect with me on LinkedIn.

About the Author
Susan Parente (PMP, PMI-ACP, CSM, CSPO, PSM I, CISSP, CRISC, PMI-RMP, RESILIA, ITIL, GL®CP, MS Eng. Mgmt.) is a senior instructor at IIL, an Associate Professor at Post University, Adjunct Professor at Montclair State University, and a Lecturer at the University of Virginia. She is an author, mentor and teacher focused on risk management, along with traditional and Agile project management. Her experience is augmented by her Masters in Engineering Management with a focus in Marketing of Technology from George Washington University, DC, along with a number of professional certifications. Mrs. Parente has 25+ years’ experience leading software and business development projects in the private and public sectors, including a decade of experience implementing IT projects for the DoD.


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

Agile for Traditional Projects

By Susan Parente | Risk Management Guru - Agile Generalist - Instructor and Consultant, IIL

“Can Agile practices be incorporated with traditional project management?” This is a very common question today, and the answer is yes!

In this blog, I’ll cover two great Agile practices that teams have found to be valuable to incorporate on traditional projects, and which may help your team make the shift from traditional to Agile project management: A Daily Stand-up meeting and a Kanban board.

The daily stand-up meeting

The daily stand-up is used in Scrum, one of the most popular frameworks for implementing Agile. In this meeting, the project team members answer the following three questions:

  1. “What have I completed since yesterday that supports the iteration goal?”
  2. “What do I plan to complete today to support the iteration goal?”
  3. And lastly, “What are the barriers or impediments that are getting in my way in completing the work I have to do to support the iteration goal?”

This truly is a stand-up meeting, where all participants are standing. The meeting is time-boxed which means that it must end at the allocated time, generally 15 minutes. This forces people to prioritize what they talk about and to make sure they are efficient with the use of meeting time. (If you decide to have a daily stand-up meeting and let it run over 15 minutes, you're not actually doing the practice of a daily stand-up, as it is a time-boxed event).

What you will likely find is in the first few daily stand-up meetings, not everyone will have an opportunity to speak; however, after a few meetings, people will figure out how to be succinct so that everyone has an opportunity to speak. It's important for the Project Manager (PM), team lead, or facilitator in a traditional project to allow the team to work through this, as it is a part of the process of team development.

It is also important for the PM to take the lead and provide meeting support, but only to remind team members to focus on the three questions they need to answer (as noted above) and remind them if they're getting off-topic with doing so.

Keep in mind that the purpose of the daily stand-up meeting is for the team to provide status to all team members, not to report to the project manager or the customer. Of course, it is valuable for the project manager to attend this meeting as the team facilitator; however, their role is more focused on listening and enforcing process than leading the team.

The Kanban board

A project Kanban board, or task board, is used by agile team members to work through project tasks. The project sponsor need not know that you are using an Agile method, and neither do your team members. In some organizations, it can be worrisome to customers and team members to use ‘Agile’ if they don’t know much about it. It can be an intimidating change. Using the Kanban board has been very effective for teams that I have coached or led because the teams had multiple tasks that changed every week. It is an easier way to manage these tasks and to make sure they get completed in a prioritized order while being able to track who is working on which tasks.

As designed, a Kanban board minimizes the project work-in-process and allows the team to complete all of the project work, not knowing necessarily how long each task would take. As each task is completed, the team member who completed it updates the board and assigns themselves to the next prioritized task.

Other Agile practices that teams have found to be valuable to incorporate for traditional projects include:

  • Information radiators
  • War rooms (collocation of the team)
  • Team retrospectives
  • Burndown charts
  • Relative sizing/estimating
  • And others

What is nice about incorporating Agile practices while doing traditional project management is that you may receive some benefit from using these practices while your organization may not be ready for an Agile project management approach. As a PM, you probably have some authority as to how your development team works and are able to use some of these tools even without agreement from senior management, or from your customer.

By incorporating Agile practices into traditional project management, you can reap the benefits of these practices and also, in the meantime, educate your team and your customer on Agile practices so they are more comfortable with using them. 

Related Courses from IIL:

Courses can be tailored to meet your organization’s needs. Request a free consultation

 

Susan Parente (PMP, PMI-RMP, PMI-ACP, PSM I, CSM, CSPO, CISSP, CRISC, RESILIA, ITIL, MS Eng. Mgmt.) is an instructor and consultant at IIL, an Adjunct Professor at the University of Virginia, Post University (CT), and Montclair State University (NJ). She is an author, mentor and teacher focused on risk management, traditional and Agile project management. Her experience is augmented by her Masters in Engineering Management with a focus in Marketing of Technology, from George Washington University (DC), along with a number of professional certifications. Ms. Parente has 18+ years’ experience leading software and business development projects in the private and public sectors, including a decade of experience implementing IT projects for the DoD.


The Nuts and Bolts of Agile and Scrum

By J. LeRoy Ward,  PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL

Agile and Scrum: What’s the difference?

It seems like almost every company, regardless of their industry, is practicing Agile and Scrum in some way and at some level of proficiency. If you’re new to Agile and Scrum, you may be scratching your head wondering first, what are they? And, second, what’s the difference between the two?

What is Agile?

First and foremost, Agile is a philosophy, an approach to work (think producing software or some other product) that says we will have more satisfied customers if we break up our project into iterations than try to do the whole thing at once. As we complete each iteration we have a workable increment of the product. The customer will examine it and provide feedback that we can use for the next iteration. We continue with this iterative, incremental approach until the customer is completely satisfied. An Agile approach significantly reduces the risk of customer dissatisfaction.

This is markedly different from the Waterfall approach where requirements are collected at the outset and then the team, with very little customer interaction, builds the entire product which is then delivered to the customer for acceptance. The Waterfall approach, while useful for certain projects, has proven completely unsatisfactory for projects where a high level of customer interaction is required because of the uncertainty inherent in the end product.

The Agile philosophy is best described in the Agile Manifesto, written in 2001.

Because Agile is a philosophy, it can be implemented in many different ways. One of those is Scrum. Let’s take a look

What is Scrum?

Scrum is the world’s most popular way to implement Agile. It’s not a methodology; rather it’s a framework, but with some very specific “rules of the road,” which you can find in The Scrum Guide, written by Sutherland and Schwaber. Here’s how Scrum works.

The Scrum Team is comprised of a Scrum Master, Product Owner, and the Development Team. (Note: there are no Project Managers in Scrum!) The Scrum Master is a servant leader who makes sure the Development Team follows the Scrum process. The Scrum Master also provides interference for the Scrum Team from outsiders. One important point: the Scrum Master is not the boss!

The Product Owner (PO) is responsible for maximizing the value of the product the Development Team is producing. The PO works very closely with the Development Team, helping them understand what’s important by managing the Product Backlog which is a rank-ordered list of all features, functions, requirements, enhancements, and/or fixes related to a specific product.

The Development Team does the work! They are self-organizing and make all the decisions regarding how to do the work and define what “Done” means. Each backlog item is accomplished in a series of Sprints, or iterations, which last no longer than 4 weeks. A Sprint Review is held at the end of a Sprint where the PO reviews the results.

Each day of the Sprint, the Scrum Team meets for fifteen minutes in a “daily standup,” where they answer three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. What obstacles are in your way?

The Team is not briefing the PO or Scrum Master. They are briefing each other.

Scrum is very easy to understand but is difficult to master because of the organizational change that needs to occur to implement it. Thousands of companies are using Scrum with very impressive results. Yours may find it helpful as well.

About the Author
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.


Effectively Using Product Roadmaps for Agile

By Betsy Kauffman, Organizational Coach, Agile Pi

What is an Agile Product Roadmap?

A product roadmap is essentially an action plan for how a product will evolve to completion. Product roadmaps can be incredibly useful to outline your product functionality and showcase a timeline for when new features will be implemented.

Multiple agile teams can utilize a shared product roadmap. When employed in agile development, a roadmap equips your product with the essential framework for a team’s daily tasks and should be reactive to developments in the competing landscape.

Many agile professionals have turned to product roadmaps as a plan of action to resolve managements need for documentation, but is your roadmap a valuable project tool or just a required artifact created and then cast aside? If you create it and never look at it again, then you’re probably struggling with lots of issues like missed deadlines, frustrated stakeholders, bad/slow decisions and mediocre solutions.

How does a Product Roadmap Improve Projects?

When done well, the Agile product roadmap is the foundation and facilitator of solution delivery. The process to create and periodically update the roadmap generates meaningful conversations that create confident teams who are able to meet their commitments. A good roadmap process helps teams manage expectations, facilitate decision making, and most importantly, estimate and deliver valuable solutions.

A useful and predictable roadmap requires a consistent focus on three things:

  • Transparency
  • Data-Driven Forecasting and Decision Making
  • Reflection

Agile teams who focus on transparency and engage stakeholders in meaningful discussions need to build a sturdy framework for the Agile product roadmap.

The framework should include:

  • Business Capabilities
  • Technical Dependencies
  • Other Project Impacts
  • Market Events
  • Risks/schedule constraints

When teams establish this solid framework across a timeline and commit to frequent recasting, the product roadmap becomes an essential communication and trust-building tool. Leaders and stakeholders understand the product/project plan, and the team becomes confident in their ability to deliver!

About the Author
Betsy Kauffman (CSM, CSPO, PSM, PMP, PMI-ACP, SPC4, ICP-APM, ICP-ACC, ICP-ATF) is a passionate Organizational Coach and Trainer with more than 18 years' experience working with high performing teams. She has held various roles working as a Business Analyst, Project Manager, Program Manager, Scrum Master, Senior Scrum Master, and Agile Coach across several sectors including healthcare, retail, entertainment and financial. As an Organizational Coach, she is responsible for coaching, training, and implementing best practices at the executive, program and team levels for several Fortune 500 organizations.

Betsy was also selected by Agile Alliance to be one of seven authors for the Agile Practice Guide published in conjunction with the Project Management Institute (PMI)® in September 2017. Betsy is actively involved in the community and enjoys presenting on a range of topics regarding agile transformations, agile management, and agile values.

PMI is a registered mark of the Project Management Institute, Inc.


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.