The Dutch: Total Soccer, Compensatory Movement, and T-Shaped Skills

With the World Cup taking over the headlines, we couldn’t miss an opportunity to bring two of our favorite topics at CC Pace together: sports and Agile. As Team USA gears up to take on the Netherlands, here’s a little history on the unique style of soccer the Dutch created and what Agile teams can learn from their success.

In the 1970s, the Dutch dominated their international counterparts by using a style of soccer they called totaalvoetbal or total football. Total football requires each player on the team to be comfortable and adept enough to switch positions with any other player on the field at any time. The Dutch required the goalkeeper to remain in a fixed position, but everyone else was fluid and able to become an attacker, defender, or midfield player when the play dictated it. Whenever a player moved out of his position, they were replaced by another player. Successively, all other players on the team shifted their positions to maintain their team structure. In modern soccer, we call this collective team behavior compensatory movement. All teammates compensate and adjust to each other’s actions.

This philosophy helped create teams without points of weakness that their opponents could exploit.

Totaalvoetbal only worked because players trained to develop the skills needed to play all positions. Each player was a specialist in a certain position or role, such as striker or center defense, but was also quite competent playing other roles on the team.

In the Agile world, this can be applied to the makeup of scrum teams. Scrum teams that are self-sufficient because of their fluidity are always the most productive and dependable. If scrum teams are comprised of team members with “T-shaped” skills, then there will always be team members that can fill in for others when needed.

People with T-shaped skills have a deep level of skill and expertise in one area and a lower level of expertise across many other areas. When scrum teams are comprised of team members with T-shaped skills, it helps to ensure that all work can be completed within the team. It also means that productivity is less likely to drop when a team member is out of the office because others can roll up their sleeves and help get the job done.

Cross-training and pair programming are great ways to help develop team members with T-shaped skills.  Pair programming is an Agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

T-shaped skills are not developed by accident but rather intentionally. Careful planning and a thoughtful, proactive approach by the individual and their manager are crucial. A manager must understand the value of investing in the development of people. Cross-training, stretch assignments, training opportunities, shadowing, and pair programming are all excellent methods for developing additional skills that allow for compensatory movement and fluid teams, yet, in some ways, represent short-term reductions in individual productivity. Managers must make this short-term investment to see the long-term value and score more goals.

Does your Agile Transformation feel like it is stuck in mud? Maybe it is facing one of the many challenges organizations must navigate as part of their transformation. 

According to the 15th State of Agile Report  the top 10 Agile Challenges (Digital ai, 2021) are: 

The impact of each of these can be detrimental to any Agile Transformation. The report suggests that some organizations face many of these challenges at once. The survey notes that these results have been unchanged over several years. As we look across these top 10, we find most of them relate to the organization’s cultural aspects which means that trying to improve a team’s specific use of an Agile method like Scrum, is less important than trying to improve the overall Agile Culture of the organization. 

For a different view into why Agile transformations are challenged, we find the article, How to mess up your agile transformation in seven easy (mis)steps (Handscomb et al., 2018) by a McKinsey team as yet another way to look at the challenges organizations face. The seven missteps are: 

1. Not having alignment on the aspiration and value of an agile transformation 
2. Not treating agile as a strategic priority that goes beyond pilots 
3. Not putting culture first over everything else 
4. Not investing in the talents of your people 
5. Not thinking through the pace and strategy for scaling up beyond pilots 
6. Not having a stable backbone to support agile 
7. Not infusing experimentation and iteration into the DNA of the organization 

If your organization is facing any of these challenges, or you’ve made any of the “missteps” identified by the McKinsey team, your Agile adoption may be at a stall. If you’re experiencing multiple challenges, it may be time to get some help.   

When things aren’t going well with your transformation the impacts are felt at the team and organization levels. Next, we’ll look at some of these impacts. 

Team Impacts 

• Team members feel frustrated and demotivated about working in an Agile environment when they aren’t supported through the transition by managers, each other, and the culture of the organization. 
• Team members are unable to deliver quality increments of work due to a lack of consistent processes and tools.  
• Team deliveries are hindered by defects.  
• Team members struggle to learn and implement new Agile methods, or what they learn does not stick. 
• Team members don’t go beyond process and learn delivery practices to improve quality, like TDD, or DevOps. 
• Team members don’t work cross-functionally and instead keep silos of expertise. 
• Team members struggle to coordinate across teams to remove dependencies.  
• Team members burn out due to working at an unsustainable pace. 
• Team member turnover is high. 
• Stakeholders don’t see the value in their participation with the Team members doing the work, hindering the team’s ability to get real-time feedback and continuously improve. 
• Management fails to let the team self-organize taking away from team ownership and accountability for the work. Or even worse, they micro-manage the team, their backlog, or even how they do the work 
• Teams find it difficult to release rapidly hampering innovation and increasing time to market. 
• Team members aren’t engaged in learning new ways of working. 

In addition to the team impacts, there are several organizational impacts that can occur. 

Resolving the challenges 

In looking at the data, it is imperative that organizations address these challenges head-on. If you’re seeing any of the impacts listed above, you may wonder what to do to alleviate them.  One of the biggest mistakes is not incorporating change management as part of an Agile Transformation. Leadership needs to help everyone in the organization understand the new culture underlying how they all work together. It requires leaders and doers alike to learn about Agile values and behaviors. Organizations must invest in training and education at all levels so that learning becomes part of the culture. How do we expect people to become Agile if we don’t teach them what Agile really is?  

“What Are the Greatest Contributors to Success When Integrating Change Management and Agile?” According to Tim Creasey (Creasey, n.d.), they are: 

1. Early engagement of a change manager 
2. Consistent communication 
3. Senior leader engagement 
4. Early wins 

Regardless of the Agile Methods you are trying to implement, an organization must start with changing its organizational culture, and the best way to do this is to start with change management. All the efforts of teaching and coaching will fail without the culture change to support the new Agile ways of working. Finally, engage the entire organization, not just IT, in the adoption of Agile practices and behaviors. While a pilot team will help test out a specific Agile method, their work with other members of the organization requires everyone to understand what it means to be Agile. Agile is for everyone, not just IT. A comprehensive change management program will help ensure the entire organization becomes focused on becoming Agile.

Watch for future blogs where we delve into these challenges and what CC Pace can do to help you solve them.

Over the past several years, I’ve worked with many organizations as an Agile Coach and Scrum Master. Through this experience, I’ve noticed there is often misunderstanding at varying levels within the organization around the difference between Agile Adoption and Agile Transformation.

My goal through this blog will be to share my thoughts around Adoption and Transformation and to articulate the basic differences.

First, let me start by defining what I mean by Adoption and Transformation. We find that many organizations think they are Agile when they adopt different Agile practices and begin to check these boxes daily, like having a Daily Standup, working in Sprints, or creating a Kanban board. Organizations may see some benefit in the early stages of a Transformation when Adoption is on the uptake; however, Adoption is just one of the factors that will help a Transformation be successful. A Transformation is about more than adopting a methodology and checking a box. A Transformation changes how the entire organization behaves; it changes the organization’s culture. This change may include aligning along value streams to create virtual teams focused on the same outcome delivery. And it should also involve getting business partners to engage with the IT delivery teams to provide regular input and feedback on the work. And Transformations may see new ways of budgeting around product delivery rather than project delivery. The bottom line is that an Agile transformation is about more than having teams adopt an Agile method.

Before we dive deeper into the differences between Agile Adoption and transformation, let me draw your attention to the 15^th Annual State of Agile Report on company experience in practicing Agile.

The Annual State of Agile Report is the longest continuous annual survey of Agile techniques and practices as identified by over 1300 global respondents.

https://digital.ai/resource-center/analyst-reports/state-of-agile-report

Most of the respondents report their company has been practicing Agile. Quite clearly, Agile is the new buzzword, and corporations want to ensure that they don’t miss the bus. Many think it’s a plug-and-play kind of solution, and things improve overnight. It IS NOT!!

But what really is Agile Adoption, and how is it different from Agile Transformation?

In simple terms, Agile Adoption is changing the way a team does the work, whereas an Agile Transformation deals with changing the way an organization gets the work done. It’s about Doing Agile vs. Being Agile.

Sounds interesting?? Look at the 5 key differences as illustrated by Anthony Mersino.

1. Speed of Change

Adoption can be quick and even measured in days or weeks. After a day or two of training, teams can agree on a tool, set up their board and events, and start following an Agile method like Scrum. I would refer to it as kind of a jumpstart. Transformations, on the other hand, can only be measured in years since the goal is about continuous improvement and cultural changes. In my previous blog, I defined the different levels and timelines as to when an organization can be transformed. While organizations might see Agile Adoption happen quickly, culture change across the organization is needed for a Transformation. And without question, culture change takes longer to come to fruition than team Adoption.

2. Planning Timeframe

Agile Adoptions can be short—as the speed of change is quick compared to Transformations. Projects are temporary; thus, teams on projects can switch from Waterfall to Agile methodologies and be seen as adopting Agile. The planning timeframe for getting teams to adopt Agile can be short since we are simply changing how people work. Transformations, however, require long-standing and stable, Agile teams that take time to build. As you plan your Agile Transformation, the timeframe is much longer than that of simple Adoption, and it should include learning opportunities for everyone in the organization around the Agile mindset and how Agile organizations work differently. Change Management plays heavily in a Transformation plan.

3. Productivity Gain

Researchers show a gain between 20% – 100% when it comes to Agile Adoption. In other words, just by teams following simple steps such as the PO setting priorities, focusing on a prioritized backlog, teams working together cross-functionally, etc., an organization will see gains in productivity. However, in a Transformation, one of the most significant benefits comes from developing T-shaped skills to become a cross-functional team. Transformation is more about empowering employees by encouraging them to be creative, understanding and accepting risks, and negating management layers allowing for more transparency. As an organization transforms, they decentralize decision making, advocate for innovation, focus on team outcomes over individual performance, engage business partners more readily, to name a few, and thus as a whole, may experience a productivity gain of close to 300%.

4. Org Structure Change

Minimal-to-no structural change is required while a team adopts Agile methodologies. A Team of employees from different functional areas can come together to complete a project and may even move back to previous projects post completion. While together, they practice and adopt Agile methods. However, there can be chances of teams working in silos which can lead to significant inefficiencies. Team members reporting to different managers and having multiple hierarchies within a team can even delay decision-making.

Agile Transformation can have a significant impact on the organization. In a Transformation, the focus is on shifting from functional silos to more long-standing cross-functional stable teams, thereby reducing inefficiencies. While the reporting structure can remain matrixed, the team bond comes first in a Transformation. People managers in a Transformation shift their focus to employee enablement and engagement and less on directing daily work.

5. Change in Culture

Have you ever heard the saying, “Culture eats strategy for breakfast?” As Adoption focuses on changing the way the team accomplishes work, a culture change may be seen solely within the group. One or more teams adopting Agile can lead to a Transformation, but it is unlikely to impact the culture significantly.  When an organization sees the value from a team’s Adoption of Agile principles and practices, it may pave the way for a greater Transformation. I recommend engaging with a change management expert to help the organization’s culture change. This culture change is key to a Transformation and will bring customer satisfaction and respect for people.

In summary, both Agile Adoption and Transformations will bring value to your organization.

It all depends on the organization as to what path they follow; there isn’t a right or wrong here.  I’m a strong believer that anything, when done the right way, will yield results. Its more about the process and believing in the process. What I think we can see here is that while organizations can derive value from an Agile Adoption, the true benefits come from the longer Agile Transformation.

What is the bottom line? Adoption is fast and easy, while Transformations take longer and require more planning and culture change, but without question, the benefits are worth it.

As a Senior Scrum Master, I’ve worked with many organizations, and I’m frequently asked by leaders one common question: how long will it take for my team to be Agile? The answer is never easy; developing an Agile mindset can be complex. From senior executives to developers, everyone in the organization must be open-minded and willing to change. Of course, there will always be resistance, but this can be handled through open dialogue and continual conversation.

I’d like to walk through a staged representation depending upon the maturity levels that each team goes through in becoming Agile. The information you can gather from the maturity levels is an important metric that organizations are intrigued and excited to see because they show progress in their Agile journey. I have used the maturity levels extensively with teams, and it’s always great to show progress; but remember, it’s just a tool.

So, with that being said, let’s get started. I will review each maturity level a team goes through, and along the way, I’ll share my perspective and lessons learned.

Level 1 is a Learning Phase. As teams get started on their Agile journey, it’s essential to introduce and establish an Agile mindset. From my experience, an Agile Boot Camp is a great way to create this awareness and introduce some initial concepts. It’s also an opportunity to see the team composition, make introductions, and begin a new way of working together. While Level 1 focuses on awareness, you can’t short-change the importance of this initial step; it sets the foundation for the beginning of the journey and the team’s future success.

To reach Level 2, teams must have a solid understanding of what it means to be Agile, and they must also recognize there is a difference between Agile and Scrum/Kanban. Frequently, I hear teams using words like Agile and Scrum interchangeably; and it’s important everyone understands that Agile is a methodology, whereas Scrum and Kanban are different frameworks of Agile. The Agile ceremonies or events should be scheduled with a set agenda and teams should practice story card-based requirement gathering.

Once the team has a firm grip on what it means to be Agile, they’re practicing the events, using terms correctly, and understanding the different frameworks; it’s time to move to Level 3, where the focus is on proper planning, practicing trade-offs, backlog management, and inspect/adapt principles. Better planning is your key to executing a sprint well. Having a solid backlog and adopting inspect/adapt principles will play a crucial part in a team’s success. The team should be encouraged and start to practice trade-offs.

As a Scrum Master and coach, I continually talk with my teams about embracing change. As they transition from Waterfall to Agile, the team should practice the “yes, I can, but…” phrase. For example, the Product Owner issues a new requirement, but the team already has a full plate of work. At this point, the team should be willing to practice a trade-off, accepting the requirement but be open to a conversation with the Product Owner to reprioritize existing items. Through this process, we ensure change is embraced and simultaneously practice trade-offs to not burn out the team.

As we move up the ladder, Level 4 is about the team starting to self-organize. In the planning session, there is a discussion about the sprint goals and stories, and the team should be able to self-organize and pick up the tasks that will help them achieve the sprint goal. Remember – it’s team commitment, not individual commitments, that matter. The team should be able to start measuring the process and looking at ways to improve, such as introducing some automation in the form of testing.

Level 5 focuses on improving T-Shaped skills, which can be attained by having a buddy-pair system within the team. Through this process, knowledge is gained and shared across teammates, thereby ensuring the team becomes cross-functional as time progresses. Teams will now be experienced looking at extreme automation techniques like RPA and AI, developing CI/CD pipelines, and eventually working in a DevOps model.

In conclusion, an Agile Transformation begins with a people mindset. While we looked at the Agile Transformation Maturity levels, it’s important to understand the effort put in by all players within an organization. From developers to Product Owners to Agile sponsors, everyone plays a role in achieving a successful Agile Transformation. As your organization moves through the different levels, remember, it’s going to be a bumpy ride. There will be forward momentum as well as setbacks; hence, it takes time. But as a Scrum Master who has worked with teams on their transformation journey, moving through the different maturity levels is a process, but the result is worth it.

If you missed Philippa Fewell’s Meet Up where she speaks about how Agile 2 came about – you are in luck, we have it here! Philippa shares with us how she and a group of 14 other Agilists reflected together over a period of 8 months to create a new set of values and principles called Agile 2. We invite you to listen, learn and enjoy her lively discussion!

Everyone says you should use Agile. The call for Agile has reached the CEO level: I myself have heard CEO announcements stating that the organization must use “Agile”—whatever that is, because I wonder how many actually know.

On the other hand, how many Agile proponents actually understand what Agile is? As I wrote in a recent article, Old Versus New Agile, Agile has changed—and changed a lot. Thus if you bring in “Agile” consultants to help, are they using “old Agile,” or “new Agile”?

Old Agile is arguably very limited, and does not acknowledge the realities of a large organization. What I refer to as “new Agile”—and I believe it is described well by Agile 2—is completely focused on the general problem of agility, and how that plays out in the broad range of situations, including and especially large organizations. Because to do big things—profitable things at scale—you need a very sophisticated model. Agile 2 provides that.

I have seen IT managers make tragic and far-reaching mistakes in their attempt to follow “old” Agile. For example, in more than one case an IT SVP eliminated all roles pertaining to testing. I wrote in an article why that is a tragic error that eventually results in terrible quality issues and actually impedes agility.

Old Agile is not all bad. It broke the grip of rigid approaches being pushed at the time by PMI and the procurement school of thought. In a fast-changing market, custom market-facing software cannot be “procured”: it must be seen as something that evolves over time. Agile made us face that. Some of the ideas that it brought into the forefront were:

• Phase-based (requirements, design, implementation) software development does not usually work.
• Business users often do not know what they want or need.
• It is almost impossible to fully design software up front
• Documents alone are not effective for communicating things
• Don’t build something entirely in one go
• Big teams do not work
• Don’t micromanage how developers work
• Don’t trust anything until you see it running
• Build quality in
• More effort ≠ better; automate to avoid effort
• Continuously reflect and improve

These are all good things, especially if one views them as reminders rather than absolutes. But the Agile community also came to espouse some extreme and ultimately toxic viewpoints—again, especially if one views them as absolutes (which is often the case). I consider these views to be part of “old” Agile. These include:

⚠️ Teams do not need leaders, except to “remove impediments”.

⚠️ Always trust the team.

⚠️ A team must be completely autonomous.

⚠️ Multiple teams will collectively self-organize.

⚠️ Written communication is not important.

⚠️ Everyone must sit together.

⚠️ Most challenges pertain to individual contributor team behavior.

⚠️ Teams can resolve technical issues if leaders merely “get out of the way.”

⚠️ If Agile does not work at scale, it is the organization’s “fault.”

⚠️ Specific technical practices such as pair programming and TDD are always “best.”

In contrast, “new” Agile ideas are markedly different. A tiny sampling of these authors includes Klaus Leopold, Nicole Forsgren, Jeff Dalton, David Marquet, Matthew Skelton, Manuel Pais, Mirco Hering, Mark Schwartz, and Gary Gruver, as well as some “old Agile” authors who have evolved a mature view over time (or had one from the beginning) such as Johanna Rothmann, Diana Larsen, as well as myself and the 15 members of the Agile 2 team.

You probably see now that the peril of bringing in Agile consultants is that you might not know if they embrace “old” Agile ideas or “new” Agile ideas. But that is not all. “New” Agile includes many additional narratives that are critical for achieving agility at scale. The Agile 2 team attempted to summarize these through its principles, but a very abbreviated summary is as follows. Note that these are considerably at variance with “old” Agile, but are well aligned with the “new” Agile that Agile 2 and many of the above authors advocate:

On leadership:

• The predominant forms of leadership are the most determinant factors of success.
• Someone usually needs to coordinate things, and be the organizer.
• On any team, one wants a “missionary, not mercenary”—someone who values the organization’s success first and foremost.
• There are many forms of leadership: team focused, advocate focused, technically focused, and maybe others; as well as individual leadership.
• The organization needs to explicitly focus on encouraging benign and effective forms of leadership, and take steps to avoid giving the wrong people authority—avoiding people who “seem like leaders,” and instead selecting (actively or passively) those who are the “missionaries” and the helpers.
• Leadership is needed at every level of an organization, and the same principles apply.
• Leaders of tech-focused organizations not only need to understand outcomes, but they also need to understand how the work is done, because the “how” is often strategic.

On a systems approach:

• Don’t be extreme, unless the situation is extreme.
• Always think holistically—in terms of the whole system.
• Product design is an essential element, apart from product implementation; yet the two are intertwined.

On products:

• Direct feedback from customers and stakeholders is the only way to measure success.
• Product implementation teams must be partners with business stakeholders—not mere order takers.

On data:

• Data is strategic, and it must not be treated as an afterthought.

On collaboration:

• Collaboration is essential, but so is deep thought. People often need quiet and isolation in order to think deeply.
• People work, communicate, and collaborate best differently. A one-size-fits-all approach is not effective.
• Team autonomy is an essential aspiration; but for a complex endeavor, full autonomy is seldom fully realizable.
• Some people want to be experts. Some people want to be generalists. Some are in between. All are valuable.
• Both teams and individuals matter. Don’t over-emphasize one over the other.
• A team should collectively decide how to approach its work; but then individuals perform the work and interact as they need to.

On transformations:

• Transformations are mostly a learning journey—not a process change.
• Never use a framework as defined: treat it as a source of ideas—not an Agile-by-numbers process.

Conclusion

Agile is not a single theory or approach. There is great diversity of thought within the Agile community. When choosing consultants or an approach for adopting Agile methods, be thoughtful about who you choose. Ask yourself, are they interested in putting people on the ground to deliver a commodity service? Or are they deeply thoughtful about what they do, and represent mature and effective viewpoints? And will the people they provide be as up-to-date and astute about the nuances of old versus new Agile ideas as those who have had conversations with you? Because it matters.

Click here to download this white paper.

To learn more about Agile 2, visit the website here.

A look at Agile 2’s values and why we need both sides of the coin to create value.

While the values of the original Agile Manifesto have helped shift the way software is developed today, it is very much left to the interpretation of the individual applying them as to how it should be done.  This interpretation can often be dogmatic to focus solely on the left, sometimes at the total exclusion of those on the right, even though it clearly states  “That is, while there is value in the items on the right, we value the items on the left more”.

Agile 2 consists of six values and 43 principles. It comprises a deep and nuanced set of ideas, and all of its ideas are supported by the thoughts that led to them. In this article I am going to provide a view into Agile 2’s six values and why we chose the word ‘and’ instead of ‘over’.  Agile 2 seeks a balance of both the left and the right, both are needed, and both are useful. Also, Agile 2 seeks to speak to a broader range of activities beyond only software, including product development in general, and in fact any collaborative human endeavor.

The Values of Agile 2

Let’s take a look at them one by one.

1. Thoughtfulness and Prescription.

Frameworks are good and useful.  They often give us a place to start and help us to solidify an approach.  But they should not be followed blindly without considering your own context – where are you and what can and can’t you do in the context of your organization.  Many variables are at play to construct the perfect environment for a framework to succeed, including organizational structure, culture, compliance regulation, and leadership support to name a few.  A practice that is best for one organization may not be the best or have a chance of succeeding in another.  That is not to say that you can’t move towards an ideal, but it very often isn’t the place you can start.

This contextual variability is why thoughtfulness is essential when applying a framework, or any practice or methodology. However, there are cases when one should start with a well-defined practice and follow it precisely. For example, if one is replacing a component of a complex machine, such as a blade on a jet engine, following procedure is often essential for ensuring that it is done right. Lives and safety might depend on following the procedure rather than improvising.

Still, judgment is sometimes required. Surgeons often have procedures for specific types of operations, but they need to be able to improvise, using their own judgment, when things do not proceed as expected; their experience and judgment are key, and the patient’s life might depend on it.

There is a place for prescription; and there is a place for thoughtfulness. Knowing the right balance is a matter of context.

2.  Outcomes and Outputs

In the course of product development, outputs are the things that get produced by the development teams. These are usually design artifacts: digital files that define the product and its fabrication (hardware) or deployment (software).

Outputs are important – they help us measure our progress using metrics such as the team’s throughput, number of defects, quality of the software etc.  These are mainly what you might call activity-based measures.  But ultimately, we are building products or creating a service for our customers using Agile to achieve some business outcome.  Sure, the customer will care about the quality, no one wants a product that is not stable, and the organization may not achieve its revenue target or market share if the product is not released on time.  But the product also needs to be what the customer wants and will use. It must be the right product and someone or some group needs to be accountable for directing that vision to achieve the desired outcome, which is the true measure of success for the organization.

So, outputs matter: they are essential elements of any process; but they are not the end goal. The end goal is the outcome.

3. Individuals and Teams

We often hear there is no ‘I’ in ‘Team’ and much of what is written about Agile is written regarding the practices of the team.  Teams are necessary to accomplish much of what we do, as no one person has the knowledge or capacity.  But Agile often advocates for the team’s preference over the preference of the individual, be it with team norms, communication style, and even the team environment.  This can be to the detriment of the individual, which can then cascade into the detriment of the team reaching its goals.

Balance is needed so as not to stifle creativity or alienate team members simply because they do not think, learn, or process information in the same way.  It is necessary for teams to have norms but sometimes allowing someone to operate outside of the majority’s norm is needed too to accomplish the team’s goal.

4. Business Understanding and Technical Understanding

We often hear that business is the driver, and that technology is the enabler, that the business is responsible for the “what” and that IT is responsible for the “how”.  This thinking has led to many structures where development teams are led by product managers who have a great understanding of their domain but very little understanding of how it will be implemented and vice versa.  But knowledge of both is necessary to make optimal decisions.

Technical decisions have financial and future business impact, and business decisions have financial and future architectural impact.  Not every person can have a deep understanding of both, but they should not entirely shift the accountability of understanding to someone else.  Instead, they should seek to understand as much as possible and collaborate closely.

5.  Individual Empowerment and Good Leadership

Self-organizing teams is one of the first things people often talk about when discussing Agile.   Two of the principles behind the original Agile Manifesto state:

“Build projects around motivated individuals.  Give them the environment and support they need and trust them to get the job done” and

“The best architectures, requirements, and designs emerge from self-organizing teams.”

These are often translated into “leave the teams alone and don’t tell them what to do”.  Yet not all teams are ready for that level of autonomy and authority.

Empowering teams, or individuals for that matter, is a great motivator.  It can bring about better outcomes, and it can help to build future leaders within the organization.  But to empower people without some level of supportive leadership and assessment is to set them adrift.  Borrowing from a talk by former Captain David Marquet, teams need to have clarity of purpose to set direction and competency and the capability and skills necessary to get the job done .  Good leadership will assess the level of oversight and direction that the team needs and help them navigate while teaching them how to make good decisions on their own. 

6. Adaptability and Planning

One of the original values of the Agile Manifesto contains the phrase “…responding to change over following a plan”.  I do not think anyone would disagree that planning can be useful, or that if there were a significant change that would cause the goal to not be achieved then adapting the plan would not be a good idea.  The point is that both the act of planning and the ability to adapt that plan are valuable.

The planning in and of itself helps us to think through the variables that would have us choose one option, course of action, timeline, etc. over another.  It helps us think through the constraints we must work under and the risks we face if we come up against them.  Keeping these things in mind with respect to what is occurring while executing the plan gives us useful information, we can use to adapt the plan for a better outcome.

Conclusion

Both sides of the coin, heads and tails, are necessary to create value.  Agile 2 believes that both sets of values are necessary to achieve agility.  Balance is needed and consideration for the context of your situation when applying practices that might favor one over the other.  I do not believe the Agile Manifesto meant to infer only one side of the coin either, and that the word ‘over’ has led to misinterpretation and rigidity on how to apply it.  I could be wrong in my view and understanding also.  Therefore Agile 2 has provided interpretation and insight as to how the values were derived, so as not to be misinterpreted.  There is a lot of thought and experience behind them from the original authors.  However, we expect Agile 2 to evolve and develop with input from the community.  We hope that you take some time to review Agile 2 and add to the ideas and content that comprise it.

Agile 2 is here!

I was fortunate to be included in a group of exceptional Agile leaders and practitioners, led by Clifford Berg, to retrospect on Agile and improve upon what it has become over the last 20 years.  Each of us began by citing issues and problems we have encountered over the years, drawing on our unique experiences.  Not all of us experienced the same issues, but it was eye opening to discover what others came up with because of the diversity of the group both in practice and expertise.

We then discussed why we felt the problems occurred and what could be done to change them.  This led us to revisiting the values and principles of the Agile Manifesto and many of the frameworks we use today.  While I am vested in many of these, having become certified in them myself and trained others on them as well, I have seen where lack of clarity or difference of interpretation, as well as too much emphasis placed on prescription, leads to less than successful outcomes.

It is this clarity and thoughtfulness that Agile 2 seeks to deliver.  It is a set of values and principles based on common problems that we believe will resonate with you, the Agile practitioner.  My colleagues and I are proud of Agile 2 and the potential impact we believe it can have on the current state of Agile.  Have we gotten it all right?  Undoubtedly there is room for debate. Have we missed some valuable principles?  Perhaps. And that is why we want Agile 2 to be open to ideas from the community, and there will be an Agile 2 version 1.1.  We respect and welcome your input and ideas.  We want Agile 2 to be constantly improving on what it is today so that it stays relevant.  There will be Agile 2 community forums, and to begin that, there is a LinkedIn group. A book is on the way. The Agile 2 website is at https://agile2.net. Check it out!

Are you a seasoned Agile Practitioner interested in expanding services beyond yourself while providing strategic guidance to a variety of clients?

CC Pace is currently looking for a dynamic Agile Thought Leader who is ready to make an immediate impact and drive our Agile transformation services. The ideal candidate is local to the DC metro area, is comfortable making decisions and implementing innovative ideas. CC Pace will provide a flexible working environment and support interest in growing a personal reputation in the global Agile community, in addition to a competitive, comprehensive suite of benefits.

 What will an Agile Thought Leader at CC Pace do?

• Set the direction for our Agile transformation services, drive strategic imperatives, define Agile offerings, establish priorities and grow our Agile business
• Represent CC Pace at conferences, through independently orchestrated thought leadership and by guiding client engagements
• Provide strategic guidance to clients through enhancing, producing and delivering Agile training and coaching both in person and via alternative delivery modes
• Build and mentor a team of consultants to deliver the services both with internal staff and business partners
• Define and brand CC Pace while developing new relationships in the Agile community

Position Requirements:

• Current certified Agile credentials or equivalent level of experience
• Strong communication and presentation skills – must be versed at public speaking and a capable writer
• Proven experience leading Agile engagements, including developing training materials and coaching at both the enterprise and team level
• Ability to demonstrate leadership experience in IT delivery, including building and sustaining high-performing teams
• Strong leadership skills that will support setting the direction for our Agile practice, managing a team of resources and driving the Agile offering and delivery strategies
• Ability to provide ample thought leadership to further our footprint in the Agile community
• Strong business acumen that will assist in supporting the sales & marketing efforts involving Agile transformation services

At CC Pace we have a strong referral program and encourage not only our employees but even those who don’t work for us to take advantage of it – so if you know someone who would be a fit for this position please refer them!

For more information regarding this Agile Thought Leader position, please contact Rechelle Card, rcard@ccpace.com

Many people ask, what is the distinction between an Agile adoption and an Agile transformation? The former being the adoption of an Agile method and tools, and the latter encompassing those plus the people, culture and mindset shift that must accompany the adoption for an organization to fully realize the benefit.

The real difference between adoption and transformation is that adoption fails and transformation sticks. You don’t really choose one over the other – people that fail to see the difference often do the adoption because they don’t realize that culture is what makes it really stick. Most organizations start with the adoption of a method at the team level within IT. Some will also covey the message to ‘do Agile’ from the top. However, this type of adoption rarely sticks. Middle management is lost in the shuffle, often just waiting out the change and expecting it to fail. The focus is on processes and tools – not people and interactions. The mindset of transparency, adaption and continuous improvement is misplaced in favor of mechanics and metrics.

A true transformation requires the organization to think and ‘be Agile’.  It requires the organization to look at their people, organization and culture, as well as their process and tools.  An organization will move through stages improving and absorbing changes in these areas.  Typically, an organization will begin with a pilot with one or more teams.  This allows the organization to best see how Agile will affect the current process and roles, and help to uncover gaps and potential areas of conflict, such as, central versus decentralized control.

It takes time to move through all the stages that are mapped out for the process, and much depends on the attitude and behaviors of leadership. Does leadership model the behavior they seek in others? Do they look to break down barriers to value delivery? Do they reward the team and system success rather than individual or functional success? Another important factor is that the organization knows what it is driving towards. This vision and accompanying goals are what will drive the pilot and future transformation activities. This alignment is the first step. As CC Pace continues to work with companies through this process we see the positive effects gained throughout each organization.

If you are interested in learning more about Agile Transformations, join us on Tuesday, June 13, for a free webinar on the topic! Click here to register.

Have you heard that not all Agile Transformations are successful? Have you wondered what makes some transformations more successful than others? Are you wondering if your organization can be successful?

Here is a little analogy to think about. I recently lost 40 pounds on an eating transformation plan, or more simply a diet. I don’t like to call it a diet, because if I ever go back to my old way of eating I’ll likely gain my weight back. Also if I don’t follow the basic guidelines of the diet, I may not lose weight at all.  So what does this have to do with being successful at Agile?

When organizations pick and choose what principles to follow in Agile, it’s like low carb dieters choosing to still eat potatoes, or white bread on their diet. While they may see some improvements, overall they are not setting themselves up for success on this plan. The diet gets blamed rather than how the dieter chose to implement the diet.

When preparing for a transformation, the first step is to get the foundational pieces right. Learn about the plan. Prepare your house by cleaning out your cupboards and fridge, and shop for the good stuff to replace the bad stuff. Learn what the rules of your plan are, and set a date to begin. Note, a new eating plan works better if everyone in the house is on the same plan! Then measure the results, and make corrections as needed.

In an Agile transformation, the steps are much the same. Identify what method you want to follow within the Agile framework. Get everyone onboard by helping them learn about the methodology. Prepare your “house” by looking at the organizational structure and identifying what will work within the transformation and what won’t. Make a decision to replace the practices that don’t fit in the transformation with practices that will support a successful transformation. Inspect and Adapt to keep improving and making course corrections along the way.

So what if your organization doesn’t want to follow the plan to the letter? It’s OKAY… BUT the organization needs to know the impact of alterations in the plan. If I can’t give up my potatoes what does that mean? Will I see the same success rate? How can I compensate for keeping my potatoes?

Some Agile principles are more easily adapted than others. I can counteract teams not being co-located for “face-to-face” interactions, by providing great tools for them. I can bring those team members together for planning sessions, or other occasions to help build the team rapport, and offset the lack of co-location. Other principles aren’t so easily adapted. A poor company culture where trust and empowerment are lacking, may prove to be too much to overcome, leaving the organization with unmotivated and un-empowered teams.

If your transformation has hit a plateau, or doesn’t seem to be working. It may be time to take a look at how you are following the new plan, and where your potato-eating cheats are causing you bloat, and derailing your success. It may not be the method, but rather how you are following it.

I’m just returning to work after Spring Break in Cancun. I’ve met some lovely people while enjoying the sunshine. As I chatted with those beside me at the beach and alongside the pool, two common questions are asked: What is your name? and What do you do for a living? The answer to the first question is easy, but the answer to the second question is much longer. Why? Because I can’t just stop with “I’m a trainer”. I enjoy talking about Agile and Scrum, and explaining the basic framework. I enjoy sharing with others how they can apply what I teach to just about anything. I enjoy sharing Agile stories because Agile works, and I like talking about how companies can adopt an Agile mindset.

When I start talking to someone about Agile, I begin by explaining first how past processes have fallen short. The trials and tribulations of a 1 or 2 year project plan, managing risk, reaching or missing milestones, and change requests to re-baseline the plan for any number of reasons come to mind. All with a real concern of delivering something that misses the mark in “delighting the customer”.  Waterfall projects often have cost overruns, extended delivery dates, and a plethora of change requests that aren’t discovered until near the end of the project during User Acceptance Testing (UAT).  For these reasons, Waterfall just doesn’t feel like the best choice to deliver software anymore.

I then move on to talk about why I, and so many others, choose Agile processes to build software today. So here is a little of what I talk about:

• Continuous engagement with the customer and other stakeholders is key
• Seeing progress through continuous delivery enables better feedback
• Reduced risk and waste, which can save money and heartache
• Adapting to change quickly, which allows for the customer to respond to market changes
• Better quality deliveries by testing early and often
• Happier employees as a result of practicing the 12 Agile Principles

It isn’t magic, and it isn’t necessarily an easy transition to make. To become a truly Agile organization takes a true shift in how we and everyone else in our organization thinks about how work is performed both internally, and externally with our customers.

Yes, I am a bit of an evangelist. Sometimes I want to shout from rooftops “people get it together, follow Agile principles”, “walk the talk”, “quit being stuck in the past”. Our world is evolving every day. To keep pace with our competitors, we need to evolve too. Agile is an umbrella term for a number of methodologies including Kanban and Scrum. Today we find that Agile isn’t just for software anymore. The principles and methods can be followed just about anywhere to greatly improve our ability to deliver just about anything. That’s why I’m not just a trainer, but a believer.

No matter what kind of work we do, we look for feedback from our customers, our co-workers and our peers. Why do we do that? To improve and to get better at what we do.  The same thing applies to Agile teams and programs, no matter what methodology the team is following: Scrum, Kanban, XP, SAFe, LeSS or DAD.

A good retrospective is the key to helping teams improve what they are doing. It helps them identify and streamline processes which can create efficiencies and get them to that next level of maturity.  Hard to believe, but this is the event which is most commonly ignored or is taken lightly. Teams often feel they are too busy and do not have time to retrospect.  This makes the team get into a Plan and Do – Plan and Do vicious cycle. They never stop to reflect and adjust and then they complain Agile doesn’t work.

An Agile Methodology isn’t magic and it doesn’t solve all problems by itself.  It makes the problems transparent and clear and appear sooner in a project’s lifecycle. But to identify the problems and to find out what can be done differently to improve the processes, the teams need to retrospect.

So why don’t the teams do retrospectives?  Here are some of the reasons they give:

• Don’t have time just to talk, it’s a waste of time
• Retrospectives are boring
• No one takes any actions from the retrospectives so why bother
• Same monotonous technique
• Unplanned meeting
• High performing team already, nothing more to improve on
• No participation

So how do you make retrospectives interesting, add value to the team and make them a place where the team members can express their opinions without any repercussions?

First of all, the retrospectives should follow the Vegas Rule – What happens in Retrospectives stays amongst the team members.  All of the information is shared in this container of trust and all team members and facilitators should respect the container.  Information or data in the retrospectives is collected with the sole purpose of making the team better and improving processes.  The information should not be used as performance management feedback.

Secondly and most importantly, it is not intended to be a finger pointing session or to point out the skill or knowledge gaps in any individual team member. Retrospectives should always be respectful and be conducted professionally by a skilled facilitator (usually a Scrum Master).

Thirdly, the retrospectives should be done by selecting interesting activities that engage all team members.  The activities should be relevant to what is happening in the team. Retrospectives should enable the entire team collect data, learn the insights and decide on what actions they can take together to improve.

Fourthly, the retrospectives should be made exciting. The team which asks the same dreaded questions – what did we do well, what did we not do so well and are there any suggestions for improvements at the end of every sprint usually don’t get to the crux of the matter.  The retrospectives get boring and monotonous.

Create an environment of trust and honesty and make room for some creative insights.  Retrospectives should be planned in advance so the team feels like it is a pleasure being part of the retrospective after all the hard work in the sprint. It should allow the team to think about innovative ways in which they can adjust and make themselves and the processes better. A book by Ester Derby on ways to use creative exercises in retrospectives is an excellent resource and so is the website Tastycupcakes.org.

Next, what about the findings and action items from the retrospectives? Many tools like Version One have a section wherein the retrospectives can be created, stored and referenced in the next retrospective. The best thing is to prioritize the items, assign them owners and place the list both in the online tool for distributed team members and on the Physical board as an Information Radiator. Do a check-in on the retrospective action items and see if they are completed.  Retrospective items can be added to the team’s backlog and be accepted by the team’s PO.

Just collecting feedback and forgetting about the retrospectives is what makes most people discouraged from holding retrospectives.  When people feel that no action is taken and nothing changes, they wonder why they should keep on wasting time with this retrospective exercise.

Participation from all team members is key.  Especially if you have some very quiet team members and others who have a lot of ideas and take over the meeting. Good facilitation skills come in handy to address this concern. If the facilitator knows that some team members will not jump in and be part of the conversation, they can ask direct questions to engage those team members so that everyone is heard and valued.

Lastly, no team is so high performing that they cannot retrospect or find anything else to improve.  They might have found other mechanisms of inspecting what they are doing and how to adjust, that they do not wait until the end of the sprint for this formal retrospective session.  These teams have learned that improvement is always something to look forward to.

A colleague recently reached out for suggestions to help a new client whose teams are having trouble adapting to using story points.

Here are 10 tips to keep in mind when helping teams in their transition:

Change the Language – Are We Estimating Effort or Estimating Size
Story points are intended to reflect relative size.  And while they are loosely correlated to effort (e.g., the bigger something is, the more effort it takes to do it), they are not meant to represent a precise measure of effort.

If your teams are grappling with estimating-in-story-points, try changing your language to sizing-in-story-points.  It’s a subtle difference for those of us familiar with the concepts, but can ease the transition for those new to it.

Create New Language – Stay Away from Numbers
Historically, we think of size in terms of how-long it will take to do it.  Break that strong association by using a non-numeric, relative scale such as t-shirts, dogs, boats, planes, fruits, vegetables, candy, or planets.

Clarify Language – Are We Talking Effort or Duration
Let’s take a simple example…..I have a friend who can drive across country in 3 days by herself.  It takes me a week.  Assuming we’re taking the same route, and driving the same speeds, why is there a difference?  It turns out that my friend can drive 12-13 hours a day with minimal stops.  Whereas I start falling asleep after 2-3 hours and have to stop frequently.  So it takes me longer (duration) to do the same amount of work (effort).

Duration is the time it takes to complete something from start to finish and is stated in “duration-units” such as hours, days, weeks, or months.   Work (effort) is the amount of work required to complete something and is stated in “work-units” such as man-hours or man-days.  Because these both have a “time” component, we often mingle them together inappropriately, causing problems if there’s not a clear, shared understanding.

For instance, when I estimate a task to be 40 hours, what I mean is “it will take me 40 man-hours to do this, if I have the information and decisions I need in a timely manner, if tools are available when I need them, and if I’m not working on anything else”.  What others often hear is “it will take someone a week to do this”.  I’m talking about effort; others are hearing duration.

The teams my colleague observed used the following definition when estimating their stories:
1 SP = 3-4 days
2 SP = 1 week
3 SP = 2 weeks
5 SP = 4 weeks
8 SP = 6 weeks
They are tracking actual hours worked on each story and are expecting that a 2-point story equates to a consistent number of hours.  But their definition is expressed in duration-units rather than work-units, and the actual effort to complete a 2-point story can vary widely depending on whether one person can finish it in a week or it takes 4 people to complete it.

Don’t define story points in duration-units and expect it to correlate to effort.

Skip Estimation, Go Directly to Work
If your teams are thrashing because of estimation, then don’t estimate.  Use commitment based-planning and have them track their story throughput rather than points or hours.  As they become more comfortable with this, stories will begin to creep smaller and smaller naturally.  Check out more about the #NoEstimates movement.

Compare to a Baseline
Have the team select a story that is representative of the type of work they do, assign a size to it, then compare all other stories relative to the baseline.

Practice Often
The more the team does what’s uncomfortable for them, the more practice they get, and the better they will get at it.  Opt for shorter iteration lengths, as this will offer more opportunities to practice.

Value First
If teams are thrashing, there may be too many changes happening at once for them to absorb.  We’re looking for the creativity and speed that comes from being on the edge of chaos, not in the middle of it.

Focus efforts on improving the ability to create vertical slices of value.

Then Flow
Once teams can craft valuable slices, focus on reducing the variability in story sizes rather than thrash about estimating.  Strive for small stories using story-splitting techniques.  Smaller slices are easier to size, easier to finish, make mistakes visible sooner, and allow for quicker feedback.  Smaller stories also improve the flow of work.

As stories become small, uncertainty and dependencies decrease, and effort and duration can be good approximations of each other.  A rule-of-thumb is a story should be small enough to be completed in less than 1/3 the length of your iteration, e.g., no longer than 3-4 days in a 2 week iteration.  Mature teams will often have stories that take around one day, and all their stories are of similar size.

Remember – it’s the Conversation that’s Important
The magic about relative estimation is not in getting to an answer, but in the conversation that leads to shared understanding.

And…don’t Over-Stress the System
No matter what anyone thinks, pressuring a team to accept 800 hours of “planned” work when they only have 500 hours of capacity is not reasonable, and it will never work.  Forget the “if you challenge them, they will rise to the occasion” call to arms.  After a certain point, that’s just a bunch of malarkey.

As my grandma used to say, “You can’t get blood from a turnip”.

I spend a lot of my time coaching individuals, teams, and organizations interested in reaching higher levels of performance through the use of Agile methodologies like Scrum, Kanban and SAFe. Some clients expect me to tell them what to do step by step, while others are interested in learning how methods work so they can determine what practices to use as their circumstances evolve. The approach that leadership teams prefer usually reflects the problems they are trying to solve, as well as their domain of expertise, their size, their culture and their organizational purpose (for-profit, non-profit, government, etc).

In conversations with leadership teams, we discuss patterns and practices they could help institute or amplify in order to sustain their Agile transformation journey.  Our message, reinforced by all success stories in the industry in the last 15 years is clear: The success of an Agile transformation, regardless of the practices adopted, is directly proportional to how well people in leadership roles at all levels understand, exercise, and constantly improve their Agile mindset.

Leading with an Agile mindset means letting go of the traditional notion of leadership as strategy and control from the top according to a pre-determined plan of action. In times of rapid change when high levels of complexity and uncertainty are the order of the day, leaders can no longer assume they can know or control what goes on. Individuals at all levels must adapt constantly to changing conditions using their best capabilities and judgments in the moment.

In these circumstances, the role of leadership in Agile organizations is to shape the understanding, development, and learning of team members so they can act both independently and in concert with the goals of the whole organization. Leaders need to become coaches, coaching across the organization as well as individuals:

• Individual Coaching: You institute a style of leadership that is participative, servant, transparent, and unleashes the intrinsic motivation of a workforce that seeks mastery in their respective skills
• Organizational Coaching: You focus on understanding and managing the organization as a whole, optimizing the interdependence of teams and departments in order to minimize waste and maximize effectiveness

In practice, we observed that effective leaders in Agile organizations are also effective coaches. I constantly meet people who have a natural coaching mindset and they don’t even think of what they do as coaching. Here are three definitions and models of coaching that have emerged in recent years:

• Coaching is a process that enables learning and development to occur and thus performance to improve. To be a successful Coach requires knowledge and understanding of process as well as of the variety of styles, skills, and techniques that are appropriate to the context in which the coaching takes place.– Eric Parsloe, The Manager as Coach and Mentor
• Coaching is unlocking a person’s potential to maximize their own performance. It is helping them to learn rather than teaching them. – John Whitmore, Coaching for Performance
• Coaching is an interactive process through which managers and supervisors aim to solve performance problems or develop employee capabilities. The process relies on collaboration. – Richard Luecke, Coaching and Mentoring

Leaders in Agile organizations understand that coaching creates a learning environment where individual and collective challenges are the first priorities. Coaching skills enhance their management tool-set in a way that benefits themselves, their staff (those who are coached), and their organizations.

Trust – The Foundation of a Coaching Relationship

Trust has been defined by some as the ability to be vulnerable (Schooman, Mayer, and Davis, 2007). Implicit in this definition is the assumption that when you trust someone, you’re willing to be open, less guarded about your weaknesses and more candid about your opinions and ideas.

In his 1993 dissertation, A Construct of Trust,  Dr. Duane C. Tway, Jr. defines trust as “the state of readiness for unguarded interaction with someone or something.”

And in Rhetoric, Aristotle, 384-322 BC), suggests that Ethos, the Trust of a speaker by the listener, is based on the listener’s perception of three characteristics of the speaker: competence (correctness of opinions), character (reliability – a competence factor, and honesty – a measure of intentions), and the goodwill of the speaker (favorable intentions towards the listener).

When a manager uses a supervisory approach, the relationship between the manager and their subordinates is based on expertise. Boundaries are strictly maintained. Trust, while relevant, is not a key component. The relationship is embedded in the hierarchy of the organization.

When managers coach, the relationship between them and their subordinates is based on both expertise and on abundance of trust. Subordinates trust their managers to do the right thing for them, for themselves, and for the organization.

Samuel B. Bacharach, director of Cornell University’s Institute for Workplace Studies conducted extensive research and wrote over twenty books on management, organizational behavior, and industrial relations. His research indicates that organizations that do not embrace a coaching culture perpetuate a static culture of inertia, bureaucracy, and control. In contrast, coaching is a characteristic of organizational cultures that value innovation, creative thinking, problem solving, growth, and change.

Bacharach points out that “a coaching relationship requires that the protégé (the person being coached) views the coach as someone who possesses the expertise of a good supervisor, but who is simultaneously as trustworthy as a good friend. This combination of expertise and trustworthiness composes the personal integrity of the coach. The more your protégés believe in your personal integrity, the more committed they will be to you, and the greater the likelihood of your success as a coach.”

In another study, C. Ken Weidner, an assistant professor at the Center for Organization Development at Loyola University Chicago, found that trust in the supervisor is associated with better individual performance.

You don’t need to be a trained professional coach in order to include coaching in your set of Agile leadership skills. You have to be able to tell your employees “I know how to do it,” or, “I’ve been there and done that,” without giving them the impression that you think you know it all. To establish or amplify trust, Bacharach recommends you let your protégés know that:

• Confidentiality is the golden rule
• You have their interests in mind when making decisions in the workplace
• They have the ability to speak freely to you
• You are open to learning new things and some of those things can be learned from them

Trust is the foundation for coaching relationships. It is also the foundation for what you want your organization to become.

The Supervisory and Coaching Mindsets

Both coaching and supervisory relationships exist within the hierarchical dynamics of an organization, yet they are fundamentally different.  A coaching relationship temporarily suspends the hierarchical structure, and is a partnership based on the candid, free-flowing transition of ideas and information between coaches and their protégés, which serves to support, reinforce, and motivate both.

Coaching holds that employees potentially possess the best answers to the problems they are faced with, and that the coaching process helps them discover the sources of those answers within themselves.

Leading involves both supervising and coaching. As a proactive manager or leader, you perform each of these two different roles, and each is characterized by its own mindset. Moving between these roles requires a subtle mind shift. Here are several examples:

Let’s look at several examples of how a supervisory mindset or a coaching mindset can influence the way we communicate with others:

• “I suggest you complete your work in the order that you receive it.” – The supervisor focuses on coordinating work rather than facilitating it.
• “Since our last scheduled meeting, you’ve been doing a good job. Keep up the good work.” – This statement is an evaluation of job performance and is characteristic of a supervisory mindset. There is no suggestion of a plan to develop skills together or of a partnership, both hallmarks of the coach-employee relationship.
• “I understand the tight deadlines, the constant pressure from customers to provide the best service, and the intense competition that are all a part of your job. How do you think we can continue to improve the organization and ourselves given these conditions?” – This is a coaching statement. The speaker is empathetic and shows expertise regarding the current situation. The speaker indicates an interest in partnering with the direct report.
• “Working closely with you is very helpful, because not only do you improve on your abilities, but working with you also enables me to isolate those areas that seem problematic in general for employees in your position.”  – The sense of partnership communicated here indicates a coaching relationship.
• “I appreciate your coming to me for assistance. It takes a lot for people to recognize their limitations and to know when they need to seek advice from others. In my experience, there are a few different ways we can approach solving this problem, so let’s work together to think of a feasible, realistic, and desirable solution.” – The sense of partnership communicated here indicates a coaching relationship.

Next Steps

Mindsets like Agile Leadership and Coaching are critical to the success of an Agile transition in your organization.  It takes practice to be good at them, and that means you have to go out there and do it. If, in the process of coaching, questions or challenges come to mind, we’d be delighted to hear from you.

If you read this far, you probably enjoyed this article and I hope it stimulated ideas you can start using at work.   I greatly appreciate your curiosity, and hope you stay in touch! Let me know if we should expand on this topic or if there are other topics that you would like to read about.

In a prior post, Getting Ready for Your Technical Transformation, I defined technical transformation and why it is so important.  Now, I’d like to dive a bit deeper into some tips on going about it…

To begin to transform your technical ‘world’, you need to first make sure your organization’s environments are aligned. As a start, the technical experts in your organization should decide what environments are necessary to deliver the value to the customers; sometimes it could mean as few as 3-4, and sometimes 10-12 may be more like it.  The idea here is to build only the environments which are required and leave the others behind; the more environments your organization has, the more attention and costs that will need to be given to them.  When you have more environments, you vastly increase your costs in areas such as physical hardware, bandwidth, cloud storage, software platforms, which also calls for an increase in cost to administer and configure these environments.  It is wise to plan out the environments carefully!

From what I have seen, and know from my experience as a developer, organizations can usually get by with 4-7 environments, such as “Development”, “Testing”, “User Acceptance Testing”, “Staging”, and “Production”.  A couple of these may be combined or broken out in some organizations, depending on who is doing the acceptance, if there is training to be done, or if there is any beta-type testing needed, but remember that the more you have, the more work they require!

The point is to have the environments, regardless of how many you have, be aligned with the delivery, meaning “Development” would be used for team member to write code, write test scripts, etc., while “Testing” would be used to run stable code, execute test scripts, etc., with a constant set of data to check for bugs, “Staging” would be used to smoke test everything before it is put into “Production”, and so on.

Once the environments are established, the next question is what to do with them and how to move the product through them to “Production”.  There are numerous ways to do this, and the ‘go-to’ way is by manually copying the product between them or even rebuilding the product in each environment.  However, by doing these manual processes, the move is prone to errors—anytime you insert manual, people-driven processes, you introduce error.

In order to eliminate as much error as possible, it makes sense to have machines do the moving.  This process is referred to as “Continuous Delivery”.  You can make this happen by utilizing tools that are out there to help with this very thing.  Some of them you may want to explore are: Jenkins, TFS, Ant, Gradle, Bamboo, or Puppet.  While these are a start, there are many, many others tools to choose from.  The selected tools will depend on your preference, i.e. if you are a person comfortable with scripting/coding or someone who feels better about checking boxes and clicking buttons.

These tools will help you move the product through the environments to “Production”, but they will also help you with another key aspect of transformation:  continuous delivery of each product increment.  To complete an Agile transformation, including the technical ‘stuff’, you really need to be able to deliver continuously to each environment.

Any organization that feels it has truly become Agile will hold to the true nature of Agile:  iterative and incremental delivery.  If this is the case, then it stands to reason that you need to be able to continuously deliver product, pretty much on demand.

If you get stuck and are not sure what to do, you can always call upon a Technical Agile Coach—they can help you align your environments, choose the right tools, and even get you delivering continuously!

In my last post, I talked about what a “Get It Done” (GID) pattern looks like in organizations.  Today I’ll talk about another cultural pattern.

“JUST DO IT”

Many of us are familiar with “Just Do It” as a Nike ad campaign, which began in 1988…egad! I can’t believe that was over 25 years ago!

Although Nike (which, go figure, is the name of the Greek Goddess of Victory) got inspiration for their famous slogan from the final words of a serial killer (“Let’s Do It”), their ads resonated positively with the public because the simple words and imagery reflect our uniquely American values and spirit.

Be strong. Be bold. Be first. Be victorious. Do something. Do anything. Start now.

That spirit is at the heart of a JDI culture, a culture that focuses on and rewards starting.  A culture that plays to our passion, our confidence (some would say arrogance), our desire to win, and our innate belief that we will prevail under any circumstances.  Success and the American Dream are ours if we take action, work hard enough, and persevere.  This is where we come from, it’s in our national DNA.

So what’s wrong with that, you say?

Well, there’s nothing wrong with it, exactly.  It’s as American as baseball, mom, and apple pie.  But is it a good fit for Agile?

I’ve worked in many JDI environments; it was exciting, I enjoyed it, and I learned a lot.  Most first-responder and mission-critical jobs depend on people just-doing-it.  It requires the ability to adapt and make quick decisions while not having all the facts.  It’s fun, challenging, risky, and satisfying to plunge right in and get your hands dirty.  What’s not to like?

But it can also be stressful.  There’s an expectation to try harder, to do more, even to be perfect.  There’s often an element of competition, and a feeling that if we stop to rest, we’ll fall behind.  Adrenaline pumps through our body in response to the challenge of walking an ever finer edge, ready to spring into action, climb that next mountain, turn around that troubled project, or conquer the world.  We have the freedom to move fast, but not the freedom to fail.  Always, there’s the awareness that if we’re not up to the challenge, we’ll be seen as weak.  And as President Lyndon Johnson once said, “The American people will forgive you anything except being weak.”  While some of us can thrive in this kind of environment forever, for most of us it’s not sustainable for the long haul.  We burn out, or wear out, over time.

Lest I be misunderstood….starting things IS important.  As is passion, confidence, and the ability to adapt quickly and act in the face of uncertainty, to not be paralyzed by indecision.   These characteristics of a JDI culture are also essential to Agile delivery.

It’s just that in a JDI culture, the scale tips toward the un-Agile characteristics.  Like runaway WIP, because it’s more exciting to start the next new thing than it is to finish what’s already in progress.  Like fatigue, because the pace is not sustainable. Like an obsession with success, because there’s a low tolerance for failure. And like an emphasis on “I can do” over “we can do”.

An Agile change initiative would certainly start with a bang in such an environment; and would likely lose momentum before finishing.  An appropriate balance is needed to create change, respond to change, and sustain change.  And a JDI environment is out of balance.

So that’s my story and I’m sticking to it…..what do you think?

As your organization prepares to transition to an Agile one, you will most likely want to know all that the transformation entails.  One of these things will be transforming your technical practices to better align with the Agile Engineering Practices…so how can you make it a success?

Plan For It 
Organizations typically will look at the process, the teams, and the projects they will transform in their move to Agile.  However, they often forget a key piece of the puzzle: the technical ‘stuff’.

In the scheme of things, it is fairly easy to change the process that one is doing from process A to process B.  It’s also relatively easy to choose the projects that will move to Agile and the teams that will work on them.  The hiccup is that they almost always forget about the changes that must be made to the technical architecture they have in order to ensure the complete transformation.

Identifying the technical changes that need to be made and ensuring they are part of the transformation plan are keys to making your agile transformation a success!

Architecture on the Brain
In most organizations, the technical architecture is one that is usually aligned with projects or, sometimes, aligned with what was pushed and when.  The architecture is most likely not aligned with the various applications or features that the organization produces.

When this is the case, the teams most likely will have a difficult time aligning themselves in a way that they can concentrate on any specific application or feature.  This concept produces issues for teams’ ability to work on a defined backlog, and even worse, creates barriers to them completing anything of value during a sprint.  This type of architecture is steeped in dependencies and blurry lines.

In order to ensure the architecture is set up to allow for the Agile Engineering Practices, it is imperative that the architecture be examined and plans be made to make the necessary shifts in the alignment of the architecture to match.

What About Environments?
Environments are another aspect that can cause issues when attempting to institute Agile Engineering Practices.

There are usually multiple environments, like DEV, QA, SIT, UAT, and PROD, that the team will move their completed increments through.  The biggest concern with this is that most of the time, the environments do not match up and they have varying states of the application and data.  This poses numerous obstacles to the team being able to produce effectively.

To deliver value effectively, teams need to be able to accurately test the stuff they are producing.  In order to accurately test, they need to have a “clean” environment to move their increments into.  When environments are not in sync and/or are not aligned correctly, teams will have issues creating successful builds and testing them.

When the environments are not correctly aligned and/or they are not working properly, there are major consequences that can result.  These consequences can range anywhere from not completing a sprint’s increments to producing low quality results to ending up with unwanted value.

A Couple Things to Think About
If an organization doesn’t identify and plan for the technical architecture changes they will need to support their Agile transformation, they will most likely cause more delays and, more importantly, pose more barriers to the team’s effectiveness.

Examine what your team has in its way when it comes to developing, testing, and deploying code.  What kinds of measures do you feel your team needs to take in order to deliver value on an incremental, consistent basis?

Stay tuned for the next installment where we will look at ways to make the technical transformation a reality…