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.

by admin

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.

by admin

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.

by admin

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.

by admin

Key Themes at IPM Day 2019

By J. LeRoy Ward, IIL Executive VP of Enterprise Solutions and Sander Boeije, Program Manager – IIL Online Conferences 

On November 7, 2019, IIL will celebrate the 16th anniversary of International Project Management Day, also known as IPM Day. Initially conceived by Frank P. Saladis, and made possible by IIL, this important day recognizes the incredible and valuable work that project managers do every day. IIL’s IPM Day event is one of the project management industry’s largest and most popular online conferences. It brings together the best minds in the business to speak on today’s most relevant and pressing topics. This year is no different.

In this article, we outline the key themes that emerge at IIL’s IPM Day 2019. So, let’s dive right in.

Benefits and Value

As project managers, we need to “Focus on What Matters.” There is a reason that this statement is the theme of IPM Day 2019. Today, projects take up an incredibly important role within a business and, as discussed by Sunil Prashara, President and CEO of Project Management Institute (PMI), this will only increase as we further evolve into the Project Economy. Therefore, project managers not only need to deliver the project, but they also need to ensure that the project achieves its intended business benefits. The need for project managers to focus on Benefits and Value is an overriding theme at IPM Day 2019.

This will be discussed in the keynote sessions by Dr. Harold Kerzner, Kasia Grzybowska and J. LeRoy Ward. It is also a recurring topic in many other presentations as well.

Agile Project Management

In the past decade, Agile has finally established is rightful place in Project Management. One example of this is PMI’s acquisition of Disciplined Agile and FLEX. Yet, there are still many questions to be answered regarding its application on various projects. For example, how do you manage risk on an agile project? How could an Agile PMO function and does that even make sense in the first place? And what about leadership in an agile organization, how does that work exactly?

Experts including Roy Schilling, Rubin Jen, and Mayo Clinic’s Wale Elegbede, as well as our other speakers, provide you with the answers to these questions and more.

Digitalization

As Industry 4.0 continues to take shape and impact many organizations, we see an exponential increase in complexity, data, digital solutions, and more. How can we make sense of all the information and technology that is available to us, make the right decisions, and successfully manage our projects?

Thought leaders such as Microsoft’s Melissa Bader, Laila Faridoon, Leon Herszon, Carla Fair-Wright, and many others will help you navigate the digital world.

Change Leadership

Today’s business landscape changes fast. At the same time that companies are going through a number of major transformations (think Agile and Digitalization), mergers and acquisitions, and other game-changing scenarios, it seems the world uncovers one disruptive innovation after another. Businesses need strong leadership to stay relevant and prosperous moving into the future. This requires companies to be adaptive and always in a position to redefine their course.

Watch the sessions by Ben Chodor, Heidi Helfand, Jennifer Hurst, and Jimmy Godard to learn about how you can prepare yourself, your team, and your organization for unavoidable and constant disruptive change.

Soft Skills become Power Skills

Soft skills, as important as they are, will become even more so. In fact, some experts have redefined the concept of soft skills, preferring to label them “Power Skills.” Although we’re not sure who deserves the credit for coining this term, it is becoming more and more obvious that it is soft skills that make project managers successful. Accordingly, organizations need to focus on developing competencies in such areas as empathy, influencing others and grit.

Don’t miss the sessions with PMI’s Sunil Prashara, Diane Hamilton, Sean Hearne, and Ulli Munroe who all discuss key Power Skills for the Project Manager.

Still need to register for IPM Day? Sign up here.


J. LeRoy Ward (PMP, PgMP, PfMP, CSM, CSPO) is IIL’s Executive Vice President of Enterprise Solutions and a recognized thought leader, consultant and adviser in project, program and portfolio management. With more than 39 years of experience in the field, his insights, perspectives and advice have been sought by hundreds of companies and government agencies around the world.

by admin

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.

by admin

Stephen Denning on Business Agility

Stephen Denning is a former director of the World Bank, renowned speaker and author (his most recent book, The Age of Agile, has 4.5 stars on Amazon). As a keynote speaker at IIL’s Leadership & Innovation 2019 Online Conference, he gave a fascinating take on how to adopt an Agile Mindset through what he calls the “Three Laws of Business Agility.”

We received so many great questions during the 15-minute Q&A that we didn’t have time to get to them all. Thank you to Stephen for taking the time to answer each and every question. This blog post is a compilation of some of our favorites.

The recording of Stephen’s keynote, and all other speaker presentations, are available to watch on demand through June 9. Log in or register here.

To implement the Agile mindset seems to require change in processes etc. How to overcome the “fear of change”?

In general, the fear of change is fear of being changed, not change itself. If the change is good, and well communicated, and introduced in an inspiring way, change isn’t difficult. Most people want to make things better.

What is your advice for people/organizations that are reluctant to share knowledge?

In general, it’s an issue of distrust, which must be solved at an institutional level.

Can you elaborate more about customer focus vs. customer obsession? What should be the goal for organization: focus or obsession? 

There was much talk of customer focus in the 20th Century but it was mainly talk. The customer’s needs were secondary to the firm’s. Obsession means putting the customer as the real #1.

Please explain the concept of network team in more detail? Are these teams able to function independently as well as a together if need be? 

Yes. They must be able to do both.

Agile is necessary, but not sufficient: what would be, if to choose, one key ingredient besides Agile, to change the culture of the organization into a human-centered one?

Leadership storytelling is an important change tool. Human values like honesty and integrity are obviously also important. Being a good citizen must also come into the picture.

Do you know if there is a relation between human-centered organizations and revenue? 

You can certainly go broke focusing only on being human-centered. What is now possible though is to be both profitable and human-centered.

How do mid to senior-level managers get the agile buy-in from the top if it is not there?

They need to become leaders with their own inner compass and values.

Construction comes to mind as another field to apply agile. Not too much word on the success of this yet. 

I know of one construction firm that is on an Agile journey. Agile will happen in every sector.

Given cultural differences, is Agile as effective in countries where perhaps the customer is not the center of focus?

Agile is an inexorable global movement that will eventually reach all countries. You can embrace it now or embrace it later. It’s when, not whether.

What is the main characteristic of “fake” agile?

It’s parroting the words of agile without the belief, the values or the actions.

Is Agile applicable for small teams working online from different places?

Separating teams physically has obvious problems, but it has been done. Co-location is much easier.

Since leaving the World Bank, have they managed to stay agile?

They were not Agile in my day. They were very bureaucratic. There is a movement now to introduce Agile, and it has quite a bit of energy, but it is still early days. This is a marathon, not a sprint.

How would you handle the reliability-assurance of knowledge in an era of fake news and artificial intelligence?

Honesty, intellectual rigor, examining the evidence, doing the analysis—none of this is new. The Ancient Greeks spelled it out very clearly. It’s just with technology, there’s more of it to deal with.

Is storytelling like lessons learned?

Storytelling is a vast subject. You can find out more in my book, The Leader’s Guide To Storytelling.

I am not a natural storyteller. But I have heard twice today that is perhaps a skill I should develop. Any tips?

You can find out more in my book, The Leader’s Guide To Storytelling. Or for a more lighthearted look at it, my book, Squirrel Inc.

You mention agile is NOT a methodology but there are a lot of institutes giving certification training. How do you measure agile “mindset” in people and in organizations?

(This question was answered during the live Q&A.) Well, mindset is in one sense an ethereal thing and it can be hard to grasp but at the same time when you see it you can recognize it. When you see managers who are focused on enabling their staff to do things rather than controlling them, when there is trust in organizations vs. distrust. And you can sense immediately there is a difference; a different way of thinking and feeling and acting in the workplace. The measurement is more on the consequence or the result of the mindset and you see that in the way the teams flourish and the benefits for customers and the way the organization flourishes. It is one of the more difficult aspects of the whole transition is for people to realize that it is a mindset and to understand the elements of the mindset and to learn to embrace them and live them. It becomes second nature to you.

Because of the popularity of Stephen’s keynote, it will also be featured at our upcoming Agile & Scrum Online Conference. Learn more and see the speaker lineup here.

by admin

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
Contact Us

by admin

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.

by admin

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.

by admin