BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Book Review and Q&A on Being Agile: Your Roadmap to Successful Adoption of Agile

Book Review and Q&A on Being Agile: Your Roadmap to Successful Adoption of Agile

Bookmarks

The book Being Agile: Your Roadmap to Successful Adoption of Agile by Mario E. Moreira aims to help organizations adopt an agile mindset and culture to deploy agile methods and practices. It provides a roadmap that can be used to consider, understand, deploy and adapt agile in organizations and explains how you can empower teams and incorporate customer feedback using agile practices.

You can download a sample of the book Being Agile which includes two chapters from the book.

InfoQ did an interview with Mario about being agile, crossing the agile chasm, business benefits of being agile, customer and employee engagement, deploying agile, and governance of agile.

InfoQ: What makes your book "Being Agile" different from other books on agile?

Mario: My book “Being Agile: Your Roadmap to Successful Adoption of Agile” is unique in that it primarily focuses on helping a team or organization make a successful change to an Agile mindset and the cultural shift that is needed to “be Agile” and much less on the mechanical elements where you “do Agile”. It does this in an innovative manner by introducing the reader to the Ready, Implement, Coach, and Hone (RICH) deployment model. The emphasis is on readying the mind by focusing on the Agile values and principles and planting the seeds that are needed for a sustainable and successful transformation to Agile.

InfoQ: In your book you wrote about crossing the agile chasm. Can you elaborate on that, what is it and what makes it so difficult?

Mario: I suggest that applying a few of the Agile practices, does not mean you have crossed the chasm. Crossing the Agile chasm means that you have embraced the mindset of Agile values and principles. This means moving away from cost and schedule and moving toward a more value-driven way of building product. The reason why this is so challenging is that a cultural mindset shift is very difficult and can take a company a couple of years to do this and only then, when they are really committed in doing so. It also requires that the whole organizational scope (whole company or business unit) adopts the Agile mindset.

InfoQ: What happens if an organization has not crossed the agile chasm?

Mario: When an organization does not or cannot cross the Agile chasm, they will continue to live primarily in their traditional and cost and schedule driven way of building products. They may mechanically apply Agile practices but will not embrace the mindset of adapting to an incremental and continuous model of building and delivering products.

InfoQ: Often organizations want to know about the business benefits of being agile. Can you name some of them?

Mario: The primary business benefit of being Agile is that you begin to truly understand what customer value looks like. You will become hyper-focused on understanding what is of value to the customer and using smaller increments to build, validate, and improve the product so that what you delivery will be directly aligned with what the customer finds as valuable. If you achieve this (directly aligning what you build with what the customer finds as valuable), the company will ultimately make more money. This may be Agile’s dirty little secret.

While delivering something that the customer finds valuable and making more money are the outcomes, these are also what I term as lagging indicators. To supplement lagging indicators, you need leading indicators that give you current visibility as you are building the product. With this in mind, I recommend building what I term as a Lagging to Leading Metric Path. This is a framework where for every lagging indicator, you need to establish at least one leading indicator that provides visibility and information for current decision making to ensure you are moving in the direction to meet your outcomes.

InfoQ: In your book you mention that engaging customers and employees are both important. Why these two?

Mario: Engaging customers allows you to understand and build what the customer finds as valuable (build the right product). The importance of engaging employees is that when an employee is engaged and feels ownership of their work, then they are much more willing to commit their total brainpower to the work and ultimately build a high quality product (build the product right).

InfoQ: Can you give examples of what agile teams can do to engage their customers?

Mario: Within my book, I recommend that each team (specifically the PO) establish a Customer Validation Vision. This helps the Product Owner probe how well they understand the customer. Who are they? In this case, I suggest establishing customer Personas. This is a representation of a customer, who they are, and their motivations. Since most products have groups of folks who use it differently, they will have multiple personas. The key is to ensure that each persona is represented by functionality that they will need. The second step is how to get customers engaged. The key here is to get them to attend and provide feedback in the Review or Demo. Of course the question is how do you get customers to attend. I usually suggest asking them to attend just one Demo. This limits their perceived commitment and then gives you the opportunity of showing the value of the Review. Once they attend, then solicit their feedback and suggest that some of these changes may manifest in the next Demo. This often hooks them in.

InfoQ: What can organizations do to increase the engagement of their employees?

Mario: This is the beauty of Agile. If you align your organization with Agile values and principles, and in particular with the principle of “self-organizing” teams, then you are on the right track. It is important to understand that employees are the key element to a successful company. Manifesting self-organizing teams into action helps get us there.

Employees are critical assets for an organization. When employees are disengaged, they take long lunch hours and leave “at the stroke of 5”, not staying a moment longer than they have to. More important, they will not fully engage their minds to solve problems effectively and can even impede their company's success. However, when they are engaged, they bring motivation, innovation, and willingness to go the “extra mile” to get the work done. In this case, they can be a company’s greatest assets.

InfoQ: In your book you described Lean and Value Flow Quality, two frameworks that can help to focus on customer value. Can you elaborate on them?

Mario: Value Flow Quality (aka, VFQ) is an education framework and product that helps connect the Agile values and principles to the practice. VFQ is geared to achieve results in ensuring you are delivering customer value, establishing optimal flow, and achieving high-quality working solutions. Often Agile practices are implemented without a real connection of putting those Agile principles into action and rely heavily on practices that may not be well understood. VFQ provides an education-led approach that includes well-researched content, case studies, activities, and more to help the individual, team, and organization become educated in a number of topics. This can help you bridge that gap between principles and practices with the primary focus helping you achieve successful outcomes. The education in VFQ can help you apply Agile and, in general, strong business practices.

Lean software development presents the traditional Lean principles in terms that relate to software development. Often when Lean is discussed, there tends to be a strong focus on eliminating waste and rightly so. However the real focus of Lean is the identification of value to the customer: delivering what they want, when they want it, and with the minimum amount of effort. To be sure, what is considered “valuable” also becomes a driver for what is considered wasteful. As folks think about Agile principles, I suggest that they also consider the Lean software development principles to help them in their Agile journey.

InfoQ: Can you describe some of the approaches that organizations can use to deploy agile?

Mario: My book primarily focuses on what I term the RICH deployment model. The RICH deployment model promotes a focus on Ready, Implement, Coach, and Hone as activities that can help you in an Agile transformation. The emphasis of my book is on the Ready or readiness activities.

The RICH deployment model provides a strong focus on realizing an Agile mindset and their behaviors in order to achieve the business benefits of a successful agile transformation. This model and my book goes beyond the methodical approach to mechanically apply Agile practices.

Readiness is the beginning of the process of acclimatizing the mind toward Agile values and principles and what they really mean. It includes making decisions on the elements for your implementation. Although it is important to lead with readiness, this framework may be used iteratively depending on whether you plan for a more holistic deployment or iterative deployment of certain elements.

Readiness starts the moment someone asks the question, "Is Agile right for me?” The goal is to work through this question, understand your context, and figure out how Agile might be deployed. Readiness can start weeks and even months before you really get serious about moving down the agile path. However, it can also begin when you are ready to commit. Readiness shouldn’t be taken lightly. It is important to understand the ‘what’ and ‘why’ prior to discussing the how and when.

Once you believe Agile is a direction you would like to take, then aspects of readiness activities are akin to acclimatizing the soil prior to growing the seeds. It is good to take a long hard look at the conditions of the fields, equipment, and people. Strengthening the soil helps improve the physical qualities of the soil, especially in its ability to provide nutrition for plants. They can make poor soil more usable and rebuild soil that has been damaged by improper techniques. This analogy applies to strengthening the mind toward an Agile mindset.

InfoQ: My experience is that it is important to have middle managers involved in an agile transformation to make it successful. Can you give some advice on how to get their support?

Mario: Yes, it is important to understand that middle management are critical to the success of an effective Agile deployment because they are the lynchpin between the executive’s vision for Agile and middle management's willingness to allow Agile to thrive on a team. Even when executives and senior management buy in, if middle management does not do likewise, they can block a team's ability to succeed with Agile.

Probably the two vital elements to help middle managers make the transition are providing them Agile education focused on the values and principles to gauge if they feel they are aligned with Agile. Next, help them understand what their role may look like within their group.

Several key questions to have them consider are:

  • Are you allowing for self-organizing teams while still providing servant leadership?
  • Are you supporting the Agile values and principles starting with marshaling a culture toward delivering value?
  • Do you remove the language of false certainty, big-up-front, and big batches?
  • Do you remove the significant roadblocks that hinder an agile team’s progress?
  • Do you help the teams when they have external team dependencies in order to get their work done?
  • Are you fostering a continuous learning organization?

InfoQ; You mentioned that it is important to know the level of agility before starting a transformation program and during the program. How can you determine this?

Mario: Within the book, I provide several ways to understand an organization’s level of agility. I suggest two primary approaches and several assessment levels. The two primary approaches are having an Agile Coach conduct interviews and the second is having those in the organization (including teams) perform a self-assessment. The assessment levels would include assessing at the practice level, the culture level, and the business level. The practice level assessment would ask if the mechanics of the practice are in place and are people following them. The culture level assessment would ask if the Agile values and principles are embraced and if people are exhibiting the expected behaviors. I term this an Agile Mindset Values and Principles (Agile MVP) evaluator. The business level assessment would look to see if the business benefits of Agile are being seen. A combination of approaches and assessment levels would help you determine your organization’s level of agility. Within my book, I provide these frameworks.

InfoQ: Can you share some of your ideas on how to do agile education?

Mario: First I start with the premise that Agile education is much more then a training class on Agile. Instead, education is the accumulation of education elements at different points in time that will provide the comprehensive focus to help you, your team, and your organization. I recommend that your goal is to construct an Agile Education Plan for your Agile transformation. This Education Vision is a continuously evolving plan that aligns with what elements of education the organization or teams need as they understand and experience Agile. Education elements can include training, coaching, mentoring, experience, giving back, and much more. Ultimately you want to create a self-organizing educational culture with many elements and the most mature level is when employees are willing to give back to their community by sharing their experience.

InfoQ: Teams sometimes find it difficult to formulate a definition of done. How do you help teams with this?

Mario: First I start with introducing the team to a Definition of Done Starter Kit. This provides a high-level understanding of what a definition of done is, how it promotes quality, and what engineering areas (e.g., design, development, code review, unit test, configuration management, etc) may be part of a definition of done. Then, instill the idea that a definition of done does not have to be initially perfect. Instead, I introduce them to the idea of trying an experiment by constructing a definition of done and then testing it for an iteration or two. Continue to adapt it over time to ensure it is something the team can do. I also advise the team to understand that any engineering area that isn’t initially part of the definition of done, leads to an increase of technical debt. This ensures teams consider the balance of quality and quantity in relation to the functionality.

InfoQ: How can organizations govern an agile way of working? How does agile impact governance?

Mario: Many organizations expect to see the dimensions of scope, schedule, and cost defined and fixed up front for the project to be approved and move forward. This rigid approach to locking in these dimensions is unrealistic because change inevitably occurs in one or more of these dimensions. Some organizations have very loose governance where change is made in a chaotic manner. My suggestion is to apply a balanced and collaborative approach that embraces change toward customer value where change is made for the right reason.

For those applying a rigid approach today, the natural adaptation is to make the iron triangle flexible so that if one of the dimensions changes, the other dimensions change with it. I call this the flexible trapezium. (A trapezium is a quadrilateral that has no parallel sides.) The intent is that at any one time on a project—the relative position of a corner and thus the length of the sides may vary depending on the importance of the dimension at that time. If a change occurs, it will naturally impact the position of the corner and length of the size. The emphasis, however, should to be methodically adapting toward customer value.

Another recommendation I provide in regards to governance is to promote much more of a collaborative governance approach. This unites the brainpower of a governance board and an Agile Team in a collaborative way. Governance discussions regarding the progress of the project should be a balanced and transparent dialogue between the governance board and the Agile Team with a strong focus on customer value and feedback. Depending on how rigid or ad hoc your governance is, you may need to adapt it to gain the benefits of Agile.

Collaborative governance is defined by having the right people making the decisions—not just on the basis of their job titles but because they have the best insights into the change, opportunity, or problem under consideration and willingly gain customer feedback to adapt their decisions as appropriate.

Finally, if there is a form of IT governance in your organization, make sure they attend the Sprint Review. The Sprint Review supplements the discussion that occurs in an IT governance session with a view of the working software and feedback from the customers.

About the Author

Mario Moreira is a Master Agile Coach and enterprise change agent. He focuses on enterprise-level Agile transformations, building coaching circles, applying Agile business practices, and coaching teams. He is a Client Principal for Emergn Limited.   

Rate this Article

Adoption
Style

BT