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.

In a previous blog post, we covered the top 10 challenges organizations face when adopting Agile. In this article, we’ll dive deep into one of these challenges: “Inadequate management support and sponsorship.” We will explore why organizations face this challenge and what can be done to address it.

Lack of management support is one of the most widespread and yet hard-to-uncover challenges. Agile transformation requires an enterprise-wide shift in mindset and culture and this requires buy-in from all levels of the organization, otherwise, it can cause the entire effort to lose alignment.

With Agile transformations, middle management is usually caught, well, in the middle. While expected to embrace the significant amount of change they will be experiencing in their own roles and responsibilities, they are also expected to be the torchbearers and lead their teams through the transformation.

Traditional management in a non-Agile culture operates largely in a command-and-control mode. It’s how they make decisions, forecast, and get work done. Agile principles strive to decentralize some of that control in favor of building self-organized and autonomous teams. This factor directly threatens management’s perception of control and can make them feel a loss of power. The root of this problem can sometimes trace back to a poorly executed change management strategy, or lack thereof. Agile is not just a small incremental change in the way organizations plan and deliver, but a fundamentally different way altogether that requires careful planning and execution to accomplish.

Below are some of the indicators that show management is not fully aligned and supportive:

1. Teams do not get enough support from management when delivery challenges manifest
2. Management puts a greater emphasis on following the practices and mechanics than the mindset
3. There is a lack of psychological safety in the organization
4. Management overvalues Agile metrics and dashboards, leading to an increase in Agile antipatterns
5. Agile coaches struggle to maintain a coach and influence teams
6. Key Agile tenets get ignored in favor of the sponsor’s wishes, e.g., artificial deadlines

To prevent this issue from becoming a challenge in the first place, it is important to acknowledge and plan for it while developing the transformation strategy. Here are a few ways to address this challenge:

1. Address the “why”. Organizations can prevent resistance from happening by making sure management understands the “why” behind the change. Leadership needs to invest in and sponsor education and awareness campaigns to make sure people managers understand and align with the spirit of agile and are able to effectively articulate the value expected from the transformation.
2. Engage and recruit management as advocates of change: Change is hard, and advocating change requires skill. If we want our management to be those advocates, it is necessary to ensure they have the right knowledge and training to play their part. Key members of management should be strategically identified and trained for advocacy, early in the transformation.
3. Answer “What’s in it for me?”. While it might be well understood that Agile helps organizations deliver value early and often, it is human nature to seek personal benefit. Ensure they get a clear understanding of their future, feel secure from a career and work-life standpoint, and are able to see the benefits they stand to receive if the transformation goes well.
4. Let managers know that you have their back. Agile transformations are always full of ups and downs. And the ‘downs’ ideally should be learning opportunities. However, if management is held to their old expectations and they feel they will be penalized for failures as a result of the new delivery approach, they will be less inclined to support the transformation because of potential negative impacts. Leadership needs to understand and acknowledge how ‘fail fast’ manifests itself when using Agile, and ensure management understands that they won’t be penalized when failures do occur.
5. Create a ‘Growth Roadmap’. Just like ‘what’s in it for me,’ in the short term, it is important to address long-term personal benefits. As part of change management, ensure there is a clear understanding of how people will advance in their new roles in the next 3-5-8 years, what resources they will have to gain, new knowledge and credentials to consider, and which career paths they can pursue. Leadership should explain to middle-management how to be successful in an Agile culture, and ensure they recognize and reward managers for the new behaviors they want to see in them.

There is a lot that can be discussed about this challenge, and I would love to hear more from you. Have you faced similar challenges? What did you do to address them? At CC Pace, we love to engage with the community and provide value wherever possible. Reach out, we’d love to help.

Are you building the right product? Are product discovery team members sharing what they’re learning with the rest of the development team? If you’re not sure, then maybe Dual Track is for you.

So, what is Dual Track? Simply put, Dual Track is about bringing light to product discovery by focusing on generating and validating product ideas for the team’s delivery backlog. It does this by bringing the product Discovery work into visibility.

You may be thinking like me, what’s the big deal? When we practice Scrum, we have the Product Owner work with stakeholders, including UX, to build a backlog. The problem is that they often do this work in a silo and only share their stories with delivery team members at Sprint Planning. If your team sees stories for the first time at Sprint Planning, it’s too late. So, in Dual Track, we have visibility into the work the PO and the discovery team members are doing, and this work is shared on a regular cadence with the rest of the team in refinement, or through team members working together.

Dual Track is nothing new. The original idea was published in 2007 by Desiree Sy, and Marty Cagan wrote about it in 2012. While there are many instances of writings about Dual Track, Jeff Patton and Marty Cagan are two of the most well-known advocates for what Marty has coined Dual Track Scrum. In its simplest form, Dual Track provides visibility and best practices to the discovery work that must occur before a team ever sees a user story. A good article to read more by Jeff Patton can be found here.

While researching Dual Track, I found that it fits nicely with what I believe the Product Owner, Business Analyst, and UX people on the team should be doing anyway. That is working with stakeholders and the team to discover the best product. Dual Track emphasizes team engagement and focuses on not letting people work in silos. It provides guidance and structure to ensure the entire team builds the right products at the right time, together as one team. So here is one of the first things I discovered about Dual Track – the team performs as one team. Read on to see what else I discovered.

One Team, One Backlog, One set of Scrum events

According to Jeff Patton, Dual Track is “just two parts of one process”. It focuses on maximizing the value delivery of your entire team by having discovery team members working a Sprint ahead of the development (delivery) team members and including them in the work.

This approach to embracing one team is important; as Jeff Patton says, “the whole team is responsible for product outcomes, not just on-time delivery”. When we keep the entire team engaged in product discovery, the developers, and testers will have more context, and they may also surprise us in ideation with great problem solutions. Finally, not all ideas in the backlog should be implemented, and developers can help Product Owners see where ideas will be problematic.

Jeff outlines how to incorporate the product design team members into each Scrum event without disruption. The team works as one, from the Daily Standup to the Sprint Retrospective. A benefit of following a Dual Track is better engagement from developers and faster learning.

Below is a good video link I found on how to set up a single backlog in Jira for Dual Track boards that enables teams to visualize the work they are doing in the two tracks:

Progress on both tracks happens simultaneously

The Discovery Track represents teamwork through product ideation via stakeholder interviews, developing personas and stories, and market research. Once complete, the discovery team members share their findings with the rest of the team. The design team members utilize design sprints to make progress on stories for Sprint N+1, while the development team members are working on Sprint N in delivery sprints. The output from product discovery becomes the input for product delivery. At the same time, feedback from product delivery informs product discovery.

Benefits of Dual Track

The Discovery Track is always a few steps ahead of the delivery team. This approach leads to:

• Better Products – Allowing only validated product ideas into the backlog leads to better products for your customers.
• Less Wasted Time – Breaking the barrier between product design and development means the whole team better understands what they are building, reducing the back-and-forth conversations that occur.
• Lower Development Costs- Teams will not pursue product features that haven’t been validated or are well-thought-out.

Summary

Dual Track increases the odds that you will deliver high-quality products that your customers will love.  It does this by bringing visibility to what Product Owners are doing to prepare for a Sprint. It requires high collaboration between the people responsible for ideation and the people responsible for development. If you decide to incorporate Dual Track and design Sprints, you’ll be in good company. Jake Knapp wrote about Google Ventures utilizing design Sprints, and now we have the likes of Uber, Slack, and Facebook embracing this way of working.

I like what I’ve read about Dual Track and hope I have piqued your curiosity.  I would love to hear about your experience with Dual Track if you have tried it.  Please feel free to share in the comments!

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.

PI planning is considered the heartbeat of Scaled Programs. It is a high-visibility event, that takes up considerable resources (and yes, people too). It is critical for organizations to realize the value of PI planning, otherwise, leadership tends to lose patience and gives up on the approach, leading to the organization sliding back on their SAFe Agile journey. There are many reasons PI planning can fall short of achieving its intended outcome. For the purposes of quick readability, I will limit the scope of this post to the following 5 reasons which I have found to have the most adverse effect.

1. Insufficient preparation
2. Inviting only a subset (team leads)
3. Lack of focus on dependencies
4. Risks not addressed effectively
5. Not leaving a buffer

Let’s do a deeper dive and try to understand how each of the above anti-patterns in the SAFe implementation can impact PI planning.

Insufficient Preparation: By preparation, I don’t mean the event logistics and the preparation that goes along with it. The logistics are very important, but I am focusing on the content side of it. Often, the Product Owner and team members are entirely focused on current PI work, putting out fires, and scrambling to deliver on the PI commitments, so much so that even thinking about a future PI seems like an ineffective use of time. When that happens, teams often learn about the PI scope almost on the day of PI planning, or a few days before, which is not enough time to digest the information and provide meaningful input. PI planning should be an event for people from different teams/programs to come together and collaboratively create a plan for the PI. To do that, participants need to know what they are preparing for and have time to analyze it so when they come to the table to plan, the discussions are not impeded by questions that require analysis. Specifically, this means, that teams should know well in advance, what are the top 10 features that teams should prioritize, what is the acceptance criteria, and which teams will be involved in delivering those features. This gives the involved teams a runway to analyze the features, iron out any unknowns, and come to the table ready to have a discussion that leads to a realistic plan.

Inviting only a subset: As I said in the beginning, PI planning is a high-cost event. Many leaders see it as a waste of resources and choose to only include team leads/SMs/POs/Tech Leads/Architects and managers in the planning. This is more common than you might think. It might seem obvious why this is not a good practice, but let’s do a deep dive to make sure we are on the same page. The underlying assumption behind inviting a subset of people is that the invitees are experts in their field and can analyze, estimate, plan, and commit to the work with high accuracy. What’s missing from that assumption is, that they are committing on behalf of someone else (teams that are actually going to perform the work) with entirely different skill levels, understanding of the systems, organizational processes, and people. The big gap that emerges from this approach to planning is that work that is analyzed by a subset of folks tends not to account for quite a few complexities in the implementation, and the estimate is often based on the expert’s own assessment of effort. Teams do not feel ownership of the work, because they didn’t plan for or commit to it, and eventually the delivery turns into a constant battle of sticking to the plan and putting out fires.

Lack of focus on dependencies: The primary focus of PI planning should be the coordination and collaboration between teams/programs. Effectively identifying the dependencies that exist between teams and proper collaboration to resolve them is a major part of the planning event to achieve a plan with higher accuracy. However, teams sometimes don’t prioritize dependency management high enough and focus more on doing team-level planning, writing stories, estimating, adding them to the backlog, and slotting them for sprints. The dependencies are communicated, but the upstream and downstream teams don’t have enough time to actually analyze and assess the dependency and make commitments with confidence. The result is a PI plan with dependencies communicated to respective teams but not fully committed. Or even worse, some of the dependencies are missed only to be identified later in the PI when the team takes up the work. A mature ART prioritizes dependencies and uses a shift-left approach to begin conversations, capture dependencies, and give ample time to teams to analyze and plan for meeting them.

Risks not addressed effectively: During PI planning, the primary goal of program leadership should be to actively seek and resolve risks. I will acknowledge that most leaders do try to resolve the risks, but when teams bring up risks that require tough decisions, change in prioritization, and a hard conversation with a stakeholder, program leadership is not swift to act and make it happen. The risk gets “owned” by someone who will have follow-up action items to set up meetings to talk about it. This might seem like the right approach, but it ends up hurting the teams that are spending so much time and effort to come up with a reasonable plan for the PI. There is nothing wrong with “owning” the risks and acting on them in due time, however, during PI planning, time is of the essence. A risk that is not resolved right away, can lead to plans based on assumptions. If the resolution, which happens at a later date/time, turns out to be different from the original assumption made by the team, it can lead to changes in the plan and usually ends up putting more work on the team’s plate. The goal should be to completely “resolve” as many risks as possible during planning, and not avoid tough conversations/decisions necessary to make it happen.

Not leaving a buffer: We all know that trying to maximize utilization is not a good practice. Most leaders encourage teams to leave a buffer during the planning context on the first day. But, in practice, most teams have more in the backlog than they can accomplish in a PI. During the 2 days of planning, it is usually a battle to fit as much work as possible to make the stakeholders happy. For programs that are just starting to use SAFe, even the IP sprint gets eaten up by planned feature development work. One of the root causes for this is having a false sense of accuracy in the plan. Teams tend to forget that this is a plan for about 5 to 6 sprints that span over a quarter. A 1 sprint plan can be expected to have a higher level of accuracy because of a shorter timebox, less scope, and more refined stories. However, when a program of more than 50 people (sometimes close to 150 people) plans for a scope full of interdependencies, expecting the same level of accuracy is a recipe for failure. In order to make sure the plan is realistic, teams should leave the needed buffer and allow teams to adjust course when changes occur.

As I mentioned at the start of this post, there are many ways a high-stakes event like PI planning can fail to achieve the intended outcomes. These are just the ones I have experienced first-hand.  I would love to know your thoughts and hear about some of the anti-patterns that affected your PI Planning and how you went about addressing them.

Are you new to Agile testing?

I’ve been reading Agile Testing, by Lisa Crispin and Janet Gregory. If you are new to Agile testing, this book is for you. It provides a comprehensive guide for any organization moving from waterfall to Agile testing practices. The “Key Success Factors” outlined in the book are important when implementing Agile testing practices, and I would like to share them with you.

Success Factor 1: Use the Whole Team Approach

Success Factor 2: Adopt an Agile Testing Mind-Set

Success Factor 3: Automate Regression Testing

Success Factor 4: Provide and Obtain Feedback

Success Factor 5: Build a Foundation of Core Practices

Success Factor 6: Collaborate with Customers

Success Factor 7: Look at the big picture

Success Factor 1: Use the Whole Team Approach

In Agile, we like to take a team approach to testing. Developers are just as responsible for the quality of a product as any tester; they embrace practices like Test-Driven Development (TDD) and ensure good Unit testing is in place before moving code to test. Agile Testers participate in the refinement process, helping Product Owners write better User Stories by asking powerful questions and adding test scenarios to stories. Everyone works together to build quality into the product development process. This approach is very different from a waterfall environment where the QA/Test team is responsible for ensuring quality software/products are delivered.

Success Factor 2: Adopt an Agile Testing Mind-Set

Adopting Agile starts with changing how we think about the work and embracing Agile Values and Principles. In addition to the Agile Manifesto’s 12 Principles, Lisa and Janet define 10 Principles for Agile Testing. Testers adopt and demonstrate an Agile testing mindset by keeping these principles top of mind. They ask, “How can we do a better job of delivering real value?”

10 Principles for Agile Testing

1. Provide Continuous Feedback
2. Deliver Value to the Customer
3. Enable Face-to-Face Communication
4. Have Courage
5. Keep it Simple
6. Practice Continuous Improvement
7. Respond to Change
8. Self-Organize
9. Focus on People
10. Enjoy

Success Factor 3: Automate Regression Testing

Automate tests where you can and continuously improve. As seen in the Agile Testing Quadrants, automation is an essential part of the process. If you’re not automating Regression tests, you’re wasting valuable time on Manual testing, which could be beneficial elsewhere. Test automation is a team effort, start small and experiment.

https://www.cigniti.com/blog/agile-test-automation-and-agile-quadrants/

Success Factor 4: Provide and Obtain Feedback

Testers provide a lot of feedback, from the beginning of refinement through to testing acceptance. But keep in mind – feedback is a two-way street, and testers should be encouraged to ask for their own feedback. There are two groups where testers should look for feedback. The first is from the developers. Ask them for feedback about the test cases you are writing. Test cases should inform development, so they need to make sense to the developers. A second place to get feedback is from the PO or customer. Ask them if your tests cover the acceptance criteria satisfactorily and confirm you’re meeting their expectations around quality.

Success Factor 5: Build a Foundation of Core Practices

The following core practices are integral to Agile development.

• Continuous Integration: One of the first priorities is to have automated builds that happen at least daily.
• Test Environments: Every team needs a proper test environment to deploy to where all automated and manual tests can be run.
• Manage Technical Debt: Don’t let technical debt get away from you; instead make it part of every iteration.
• Working Incrementally: Don’t be tempted to take on large stories; instead break down the work into small stories and test incrementally.
• Coding and Testing Are Part of One Process: Testers write tests, and developers write code to make the test pass.
• Synergy between Practices: Incorporating any one practice will get you started. A combination of these practices, which to work together, is needed to gain the advantage of Agile development fully.

Success Factor 6: Collaborate with Customers

Collaboration is key, and it isn’t just with the developers. Collaboration with Product Owners and customers helps clarify the acceptance criteria. Testers make good collaborators as they understand the business domain and can speak technically. The “Power of Three” is an important concept – developers, testers, and a business representative form a powerful triad. When we work to understand what our customers value, we include them to answer our questions and clear up misunderstandings; then, we are truly collaborating to deliver value.

Success Factor 7: Look at the Big Picture

The big picture is important for the entire team. Developers may focus on the implementation details, while testers and the Product Owners have the view into the big picture. Aside from sharing the big picture with the team, the four quadrants can help you to guide development so developers don’t miss anything.

In addition, you’ll want to ensure your test environments are as similar as possible to production.  Test with production-like data to make the test as close to the real world as possible. Help developers take a step back and see the big picture.

Summary

At the end of the day, developers and testers form a strong partnership. They both have their area of expertise. However, the entire team is the first line of defense against poor quality. The focus is not on how many defects are found; the focus is on delivering real value after each iteration.

From the title of this post, it might seem that we are going to beat up on the ‘status reporting’ aspect. Let me clarify here, both are equally important and convey critical pieces of information to the audience.

What I want to highlight in this post is how inefficiencies are caused due to one replacing the other. In organizations using Agile, adapting to the changing landscape is a central tenet to its way of working. How people communicate is a significant factor in the success or failure of an organizations’ ability to adapt to change.

Before we explore how organizations struggle with effectively using the two ways to communicate, let’s first align on what they are.

Status reporting: The primary intent of this interaction is for one stakeholder to provide information to other stakeholders about the current state of progress. It is a one-way conversation with the information primarily flowing from the status update provider to the listener. There might be some interaction for clarification or instruction, but it is not built into the central idea of the interaction.

Inspect and Adapt: The primary purpose of this interaction is for the stakeholders to examine the progress towards the end goal, identify risks, acknowledge impediments and figure out actionable takeaways that will resolve or mitigate any challenges towards progress. Most Agile ceremonies share this primary intent and should be facilitated as such to achieve the aforementioned outcome.

What really happens: No matter how mature an organization is in its Agile journey, organizational factors such as psychological safety and human psychology influence how people contribute to the ceremonies. Let’s take a closer look at a couple of factors:

• FOMO: Fear of Missing Out. When there are no efficient ways to know the latest status of work, people tend to gravitate towards asking for status-related information during Agile ceremonies. If the status is made transparent and highly visible to the stakeholders, it will greatly reduce the desire to discuss it during discussions that should really be inspect and adapt. In Agile organizations, the use of BVIRs (Big Visible Information Radiators) such as Scrum Boards and relevant Agile metrics can accomplish this. It is critical to make the BVIRs readily accessible and easier to consume to get better user adoption.
• Perception and Recognition: Human behavior is often affected by how your actions will make you look. A status report allows a person to state what they have worked on so far and how it will make them look in the eyes of the audience for their progress. Inspect and adapt discussion makes people state the problems they are or could be facing and ask for help. It is a natural human tendency to try and not be the bearer of bad news. Especially in public forums, such as the Agile ceremonies. If people are getting enough recognition for their work and are made to feel safe for opening up and expressing concerns during the inspect and adapt discussions, the Agile ceremonies can become highly effective.

Tactically speaking, standups and scrum of scrums are typical examples of Agile ceremonies that should be heavily focused on inspect and adapt aspects. What ends up happening on most teams and programs is the ceremony turns into a status reporting session, leading most participants to not get true value out of the interaction.

If you would like to get some tactical advice on how to make these ceremonies more effective, please join us in a free webinar on November 3rd at 12pm EST, where I will discuss the topic in more detail with a fun story about chicken curry, draw the parallels and then do a deep dive into some effective techniques you can implement right now to improve the inspect and adapt aspect in your organization. Click here to register.

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!

According to Deutsche Bank CIO Frederic Veron, “enterprises that wish to reap the potentially rich rewards of getting IT and business line leaders to build software together in agile fashion must also embrace the DevOps model.”^[1]

Why is that? It’s simple: DevOps is necessary to scale Agile. DevOps practices are what enable an organization to rapidly deploy changes to many different parts of their product, across many products, on a frequent basis—with confidence.

That last part is key. Companies like Amazon, Google, and Netflix developed DevOps methods so that they could deploy frequently at a massive scale without worrying if they will break something. DevOps is, at its core, a risk management strategy. DevOps practices are what enable you to maintain a complex multi-product ecosystem and make sure that everything works. DevOps substitutes traditional risk management approaches with what the Agile 2 authors call real-time risk management.^[2]

You might think that all this is just for software product companies. But today, most organizations operate on a technology platform, and if you do, then DevOps applies. DevOps methods apply to any enterprise that creates and maintains products and services that are defined by digital artifacts.

DevOps methods apply to any enterprise that creates and maintains products and services that are defined by digital artifacts.

That includes manufacturers, online commercial services, government agencies that use custom software to provide services to constituents, and pretty much any large commercial, non-profit, and public sector enterprise today.

As JetBlue and Breeze airlines founder David Neeleman said, “we’re a high-tech company that just happens to fly airplanes,”^[3] and Capital One Bank’s CIO Rob Alexander said, “We’re a founder-led, 20-year-old technology company.”^[4]

Most large businesses today are fundamentally technology companies that direct their efforts toward the markets in which they have expertise, assets, and customer relationships.

DevOps Is Necessary at Scale

Scaling frameworks such as SAFe and DA provide potentially useful patterns for organizing the work of lots of teams. However, DevOps is arguably more important than any framework, because without DevOps methods, scaling is not even possible, and many organizations (Google, Amazon, Netflix…) use DevOps methods at scale without a scaling framework.

If teams cannot deploy their changes without stepping on each other’s work, they will often be waiting or going no faster than the slowest team, and lots of teams will have a very difficult time managing their dependencies—no framework will remedy that if the technical methods for multi-product dependency management and on-demand deployment at scale are not in place. If you are not using DevOps methods, you cannot scale your use of Agile methods.

How Does Agile 2 View DevOps?

DevOps as it is practiced today is technical. When you automate things so that you can make frequent improvements to your production systems without worrying about a mistake, you are using DevOps. But DevOps is not a specific method. It is a philosophy that emerged over time. In practice, it is a broad set of techniques and approaches that reflect that common philosophy.

With the objective of not worrying in mind, you can derive a whole range of techniques to leverage tools that are available today: cloud services, elastic resources, and approaches that include horizontal scaling, monitoring, high-coverage automated tests, and gradual releases.

While DevOps and Agile seem to overlap, especially philosophically, DevOps techniques are highly technical, while the Agile community has not focused on technical methods for a very long time. Thus, DevOps fills a gap, and Agile 2 promotes the idea that Agile and DevOps go best together.

DevOps evangelist Gene Kim has summarized DevOps by his “Three Ways.”^[5]  One can paraphrase those as follows:

1. Systems thinking: always consider the whole rather than just the part.
2. Use feedback loops to learn and refine one’s artifacts and processes over time.
3. Treat everything as an experiment that you learn from, and adjust accordingly.

The philosophical approaches are very powerful for the DevOps goal of delivering frequent changes with confidence, because (1) a systems view informs you on what might go wrong, (2) feedback loops in the form of tests and automated checks tell you if you hit the mark or are off, and (3) if you view every action as an experiment, then you are ready to adjust so that you then hit the mark. In other words, you have created a self-correcting system.

Agile 2 takes this further by focusing on the entire value creation flow, beginning with strategy and defining the kinds of leadership that are needed. Agile 2 promotes product design and product development as parallel and integrated activities, with feedback from real users and real-world outcomes wherever possible. This approach embeds Gene Kim’s three DevOps “ways” into the Agile 2 model, unifying Agile 2 and DevOps.

Download this White Paper here!

^[1] https://www.cio.com/article/3141577/true-agile-software-development-requires-devops.html

^[2] Agile 2: The Next Iteration of Agile, by Cliff Berg et al, pp 205 ff.

^[3] https://www.businessinsider.com/breeze-airways-pushing-back-launch-until-2021-what-we-know-2020-7

^[4] https://www.youtube.com/watch?v=0E90-ExySb8

^[5] https://itrevolution.com/the-three-ways-principles-underpinning-devops/

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.

Organizations with internal cultures that are aligned with their strategies are far more effective than those without aligned cultures. Decades of data prove this.^[1] For example, over the last 50 years, culture specialist Human Synergistics has compiled data on more than 30,000 organizations and it clearly shows strong correlations between specific organizational culture attributes and business performance. Yet it is common for organizations to ignore culture when trying to implement their strategies.

Agile 2 is a more mature version of Agile, and it relies on having a supporting healthy culture. In fact, analysis that Agile 2 Academy has done with Human Synergistics shows that Agile 2 ideas strongly align with what Human Synergistics calls a Constructive culture, which is the most effective kind.

When an organization decides to adopt Agile 2 (or any Agile) methods, it is common to define a set of “practices” that development teams must follow. This is an essential step, but there are some great perils in assuming this approach is enough:

1. Many, if not most, practices require people to learn new skills, make new judgments, and behave in new ways. Practices alone are not enough.
2. Most of the obstacles to using Agile 2 (or legacy Agile) methods actually exist outside of the development teams. These obstacles are widespread and manifest as management behaviors, lack of supporting systems that Agile teams need, and processes and procedures that make it nearly impossible for teams to operate with agility.

Peril #1 means that people will not be able to execute the practices. They will “go through the motions”—but Agile 2 (agility) is, in its essence, a replacement of step-by-step processes with just-in-time contextual decision-making. If people follow practices and make poor judgments, then the organization will suffer from ongoing bad decisions and poor outcomes. But if the organization’s culture is one that encourages people to seek safety through following procedure, rather than relying on their judgment, then they will not be willing to make judgments: they will copy what others do, and perhaps do the wrong thing.

Peril #2, that most obstacles to agility originate from beyond the teams, is seldom appreciated by organizations beginning an Agile journey. Senior leadership often views Agile as something that development teams and individual contributors do. They don’t realize the extent to which Agile—having agility—relies on having the right support systems in place and the right kinds of leadership supporting the teams.

If the organization has a culture of hands-off leadership, then people who find themselves in a leadership role will not know how to behave when leadership is needed. For example, a common situation is when managers have learned the Agile practice that teams “self organize” but do not realize that that is just a placeholder or reminder. Most teams cannot self-organize well; they need leadership. Self-organization is an aspiration, not a starting point.

The need for leadership is even more acute when one has many teams, and they need to coordinate, and resolve issues such as “How will we design the product? How will we involve real users? How are we going to integrate? How will we manage quality? How will we support our product? How will we agree on branch and merge strategies for the product as a whole?”

When people in a non-Agile organization implement Agile practices, they look for a rule book or procedure to follow, because that is what they are used to, but there isn’t one. If you were to create one, it would not work everywhere, because every Agile decision and judgment is contextual. It always depends; that is what yields agility and makes it possible for people to select the shortest path for each situation.

The above are aspects of the organization’s culture: the ability to discuss issues openly and honestly so that they can be resolved, the willingness to take risks when making a decision, and the patterns of leadership that people have learned. There are many other dimensions of culture that are essential for agility, such as the inclination to learn, the tendency to try things on a small scale before scaling up, and the acceptance of things not going perfectly the first time.

As Peter Drucker said, “Culture eats strategy for breakfast,” and that certainly is true for Agile transformations. If you don’t address your organization’s culture, your agile strategy with its new practices will fail to yield the desired outcomes, and Agile will become a source of problems instead of a driving force for business agility. The good news is that culture can be changed, with the right commitment and the right approach. Agile 2 Academy considers culture improvement to be an important element in business agility. An Agile transformation strategy that includes analyzing and improving your organization’s culture is far more likely to succeed than simply adopting a set of agile practices or frameworks and hoping for the best.

^[1] The best-selling book Accelerate documents research that makes this connection in the context of Agile and DevOps.

In the first installment of our Product Owner Empowerment series, we talked about the three crucial dimensions of knowledge that a Product Owner’s effectiveness is measured on. We looked at how various aspects of empathy influence a Product Owner’s ability to connect with the team, client and organization in our second post. In our third and final post in this series, we are going to look at the impact that psychological safety has on a Product Owner’s success.

Psychological Safety: Psychological safety is a state of mind and a cultural aspect that is created and fostered by someone or something other than the subject themselves. When people in the organization are afraid to make difficult choices and shy away from having tough conversations, it is generally due to a lack of psychological safety. Various factors contribute to how safe people feel psychologically in an organization. Empathy, as discussed above, at all levels plays a big role in this. If the culture, in general, is more empathetic, there will be a higher level of psychological safety. However, it is not the only factor. Let’s dig a little deeper on this factor and see how PO’s success is tied to psychological safety for themselves and the teams they are working with.

• Psychological Safety for Teams: In the case of teams, it is usually the leaders that are responsible for ensuring that team members feel psychologically safe to work in challenging situations with often unpredictable outcomes. Agile requires teams to be flexible and collaborative in their approach to address the ‘just-in-time’ nature of work. Innovation, exploration, and taking risks is a necessity to succeed in such an environment. This comes with the possibility of teams running into occasional failures that should be treated as learning opportunities. But, if the organizational culture is not forgiving of failures, it leads to teams not feeling safe enough to take the risks and challenges they may need to, to optimize value delivery. Leaders should actively address the topic of psychological safety and ensure that they foster a culture that encourages innovation and taking calculated risks.
• Psychological Safety for the Product Owner: The Product Owner is in a unique position having a tremendous influence on a team’s psychological safety, but in turn, are equally or proportionally affected by the psychological safety afforded to them by their leadership. A Product Owner who is well engaged with the team will need to make decisions regarding priority, scope, and timelines. An empowered Product Owner will be able to make such decisions with appropriate communication, keeping the team working at a sustainable pace. However, we often see organizations where such pivots must go through multiple levels of approvals, often surrounded by process constraints and red tape. This causes the organization to see change as undesirable and anyone bringing the change is viewed as the bearer of bad news.

Having leadership that welcomes change, is key to providing psychological safety to the Product Owner and the team. It is not sufficient for leadership to merely say that they support and welcome change. They need to look at systemic and cultural aspects of the organization that might be working against this mindset and actively work to realign them to an Agile way of working. It may not be the norm in some organizations to have leadership unsupportive of change, but a delay in the ability to pivot can lead to periods of unsustainable workload on the team while the Product Owner is negotiating upwards. To truly support psychological safety, allowing for making difficult choices and having tough conversations, organizations need to embrace decentralization decision making and empower the Product Owner and teams as much as possible.

Conclusion:
I hope you enjoyed this series. Throughout these three posts, we explored various factors that impact the ability of a Product Owner to work effectively in their role and serve the purpose they are meant to. They must be empowered with knowledge of not just the business domain, but also the delivery and process knowledge to successfully operate in the organizational context. Empathy at different levels of the organization and towards the customer, whether they are internal or external, is crucial to move the product in the right direction. Psychological safety is often an unmeasurable and underlying factor that should be proactively managed by leadership and ingrained in the culture and processes of the organization to truly empower their Product Owners.

As a final thought, if you’ve enjoyed this series or have additional questions on how to truly empower your Product Owners, join me for a FREE webinar on Product Owner Empowerment. We have a few seats available (on a first-come basis) and invite you to register today.

The Product Owner plays a crucial role in the success of a team and subsequently the organization. Most organizations consider the Product Owner to be a person with sufficient business knowledge such that they can communicate the business needs to the teams for implementation. While this is an important qualifier for a Product Owner, other factors must be present to have a truly empowered Product Owner.

The following 3 factors have the biggest impact on a Product Owner’s ability to succeed:

1. Knowledge
2. Empathy
3. Psychological Safety

These factors are not just applicable to the Product Owner, but also the surrounding environment. This includes the organization, processes, culture, teams, the product itself, stakeholders, and customers. Let us dig a little deeper.

In this post, we are going to focus on the first influencer: Knowledge. Next week, we’ll take a deeper dive into the impact Empathy has on a Product Owner’s ability to succeed, and we’ll round out the series with defining Psychological Safety and looking at the effect it has on a Product Owner.

Knowledge: The knowledge aspect is the most obvious and widely analyzed and assessed factor to evaluate the effectiveness of a Product Owner. However, there are several dimensions of knowledge that are required.

• Domain Knowledge: This dimension doesn’t need explaining and is probably the most obvious one of all. The Product Owner must have a good understanding of the domain they are working in, to effectively lead product development. While it may seem comfortable to assume that industry-wide it is common practice to have Product Owners with sufficient domain knowledge, some Agile antipatterns have led to the emergence of roles such as proxy Product Owner, or technical Product Owner. The primary culprit for organizations gravitating to this antipattern is a lack of understanding of the Product Owner’s role. Organizations assume that as long as there is a communication path to transfer the business needs to the teams, it is ok to have layers between the customer and the team. This creates dysfunction in Agile teams that are supposed to collaborate with the Product Owner in discovering and delivering value, but don’t have an empowered Product Owner who can make decisions and pivot when needed effectively.
•  Process Knowledge: When it comes to a PO having knowledge and understanding of the Agile approach, best practices, and antipatterns usually takes a back seat. To clarify, we are not talking about just having your PO take a 2-day certification class and call it a day. Yes, it is necessary to have formal learning as part of role development, but, the learning should not remain at this minimal level. An effective Product Owner should have lived the process, learned from the challenges, successes, and failures, so they understand what it takes to deliver the product they are helping build
• Knowledge of PO role across in the organization: We talked about knowledge that a PO should have, but, to have a truly empowered Product Owner, an organization needs to know what to do with such a role. As mentioned before, a Product Owner role is different from a mere subject matter expert. To empower a Product Owner to make decisions, the organizational stakeholders need to understand how the Product Owner role works in an Agile context. Product Owners are not only the primary source of information on business needs for the team but are also one of the key roles influencing the pace of value delivery.

If the organization doesn’t understand what it takes for an Agile team to receive business needs Just-in-Time, iterate on requirements, let design emerge, deliver value and allow for slack time and innovation, It will make a Product Owner’s job quite difficult if they are still held to traditional expectations from leadership. These expectations may include providing inflexible delivery commitments, obtaining buy-in from a myriad of stakeholders before any scope changes are made, or worst of all, ensuring maximized utilization from the team. The organization’s stakeholders must be trained and knowledgeable about the basics of Agile if they are new to this way of working. Additionally, leadership must know the common pitfalls, assumptions, and antipatterns that organizations fall into and actively work to avoid or mitigate them.

If you are a Product Owner or your Agile team struggles with this role, join me for a free webinar on Product Owner Empowerment. This webinar will be held on December 12th and you can register here! Space is limited and on a first-come basis.

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

In part 1, we discussed how a new team could help lay out the foundation of a social contract between itself and the larger organization.  While that works at the macro level, what about the micro, day-to-day interactions within a team?  The focus on a social contract can be a powerful tool in helping a team to perform at its peak.  At its core, this commitment between team members strengthens trust, set expectations, and lets the team push beyond a previously understood comfort level.  Both sides of an interaction must be dedicated to fulfilling their part of the equation.

What are some way this could look like on a day to day basis?

Take the simple act of a code review.  At a surface level, the developer running the review would go over a high level overview of the card being worked.  They would walk through the basic coding that was done, and do a brief demo of the new functionality.  The reviewer nods along, perhaps pointing out an item or two regarding coding standards, and moves along without a deeper probing of the work done.  In a scenario with a strong social contract defined, this would be seen as falling well short of what is expected of both team members.  The developer running the review would do a fuller explanation of the goal of the card, and tie it into the larger picture of the application or the organization’s goals.  The reviewer would ask more intensive questions, including, for example, how test-driven development concepts were used to work the card.  The demo of the new functionality would not only show the happy path, but push at the edge cases that were considered.  The reviewer would prod on the design and maintainability of the code.  The goal of the exercise would be understood to not just check a box, but to provide value to each member of the team, and to the overall team itself.  There would be increased confidence in the quality of the code and the product.  There would be increased knowledge-sharing amongst the team leading to less stove piping of expertise.  Lastly, team members would be building trust between each other so that they could feel more comfortable communicating questions or out-of-the-box ideas.

The same idea can be applied to team-wide activities.  Does your team do a daily stand-up and regular retrospectives?  This is an area where muscle memory can set in, and team members can start to just go with the flow.  If they follow the concepts of the social contract, team members know that they are responsible to make sure the team is generating value from these.  Put down the phone during the meeting.  Make eye contact when addressing the team.  Commit to putting into action the steps generated to make the team work better.

The big picture with the social contract is to ensure team members are fully engaging in the tasks of the team.  Confidence and respect, a sense of responsibility to each other and the larger team builds organically over time.  Only then can teams truly hit the “perform” staging of “Form-Storm-Norm-Perform”, and deliver the full value to the organization and its customers.

It’s a scenario we’ve all been a part of before.  To shake things up, your Agile teams are being restructured.  After the initial shuffle, the team gets together for a first meeting to figure out how it is going to work.  Introductions are made, experiences are shared.  Maybe a team lead is named.  It’s a heady time full of expectations.  Following the cycle of Forming-Storming-Norming-Performing, phase one is off to a good start.

At the first team retro, a better understanding of what everyone brings to the team starts to take shape.  Relationships and communications within the team, as well as other players within the organization, take root.  The team also starts to get a sense of where there are some gaps.  Maybe it’s a misunderstanding of how code reviews work, or how cards are pointed.  Storming has happened, and the team is ready to begin the transition to the Norming phase.

I’d suggest that team norms, which tend to be prescriptive in nature, falls short of what the stakeholders are hoping it will.  Instead, I’d suggest that a social contract is a better concept to work towards.

A social contract is a team-designed agreement for an aspirational set of values, behaviors and social norms.  They not only set expectations but responsibilities.  Instead of being focused on how individual team members should approach the work of the team and organization, it lays out the responsibilities of the team members to each other.  It also lays out the responsibilities and expectations between the team and the organization.

What would this type of contract look like?  It should call out both sides of a relationship.  An example of part of a social contract may look like this:

• The Team promises to place value through deliverable software as the highest goal to the organization, as defined by the Product Owner
• The Team promises to raise any obstacles preventing them from delivering value immediately
• The Organization promises to address and remove obstacles in a timely manner to the best of their ability
• The Organization promises to maintain reasonable stability of the team so that it has the opportunity to mature and reach its highest potential

In the spirit of the social contract, this should be discussed and brainstormed with open minds and constructive dialog with both sides of the social equation.  In truly Agile fashion, it should also be considered an iterative process, and reviewed from time to time to ensure the social contract itself is providing value.

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 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, 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. They should let 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 teams which asks the same dreaded questions – what did we do well, what did we not do so well or any suggestions for improvements at the end of every sprint really gets boring and monotonous, not only for the team but for anyone facilitating the retrospective as well.

Create an environment of trust, honesty and make room for some creative retrospective ideas.  It should be planned in advance so the team feels like it is a treat being part of a retrospective after 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. The book by Ester Derby on making retrospectives great is an excellent resource and so is the website Tastycupcakes.org for activity ideas.

Next, what about the findings and action items from the retrospectives? Many tools like Version One have a section wherein the output of  retrospectives can be created, stored and referenced in next retrospective. The best thing is to prioritize the resulting action 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.  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 are reticent to 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, such that they do not wait until the end of the sprint for this formal retrospective session.  But they are still doing a retrospective, even if it’s all the time.

When I am out providing Agile classes, the topic of what Scrum Masters do all day comes up pretty frequently. Attendees ask questions like; “How many teams can a ScrumMaster be part of?”, and “Do Scrum Masters just run meetings?”. As a veteran of Scrum, I am still surprised at how little organizations understand about the ScrumMaster role. But let’s face it, attending a 2 or 3 day Certified ScrumMaster course provides only an introduction to the Agile Framework, Scrum Events and Roles. Experience and a desire to truly understand what it means to be Agile and how Scrum embraces these principles takes time. It’s an ongoing learning that extends beyond just getting certified.

So let’s start with the basics. The single word most often used to describe the ScrumMaster role is “Facilitator”. Here is the Merriam-Webster’s definition

Definition of Facilitator:

one that facilitates; especially: one that helps to bring about an outcome (as learning, productivity, or communication) by providing indirect or unobtrusive assistance, guidance, or supervision <the workshop’s facilitator kept discussion flowing smoothly>

How does a ScrumMaster facilitate while being “indirect or unobtrusive”? First, you need to understand where your team and organization fit on a scale from just starting their journey to practicing best practices as a highly performing team. I say this because new teams do need a little more “hand holding”, than teams that have been together for a while, and are experienced following Scrum. The ideal goal is to get the teams to work via self-organizing, while motivating them by ensuring they have the right tools and support. ScrumMasters promote the team’s work, not their own work.

The Scrum Guide (see http://www.scrumguides.org/scrum-guide.html) lists three groupings of work for the Scrum Master: 1. Service to the Product Owner 2. Service to the Development Team 3. Service to the Organization. This requires that the ScrumMaster have several skills they can call on at any time depending on where the need is. Nowhere in the Scrum Guide does it say the ScrumMaster is the boss, the secretary, or the project manager of the team.

So, let’s go back to what it means to be a facilitator by looking at a scrum event. ScrumMasters do typically organize getting all the scrum events set up. Ideally scrum events are on a cadence to occur at the same time, and in the same place whenever possible. ScrumMasters facilitate events by ensuring the space is appropriate for the job at hand, all needed supplies are available, and that the appropriate attendees have been invited. The following is an example of how Sprint Planning is facilitated by the ScrumMaster:

Sprint Planning
The goal of Sprint Planning is to identify what can be delivered and how the work will be achieved.

The Scrum Master ensures all stories being presented in Sprint Planning meet the Definition of Ready by working with the Product Owner in advance of the meeting.

The ScrumMaster provides the container for the meeting, and turns it over to the Product Owner to work with the team providing the sprint goal and a conversation to promote a thorough understanding of the stories proposed for the upcoming sprint.

The team moves on to designing how they will do the work and tasking the stories, while the ScrumMaster listens and watches to ensure there is a shared understanding and that the team members have an equal voice. The ScrumMaster can facilitate by ensuring the team stays focused and doesn’t get stuck by asking questions, inviting others with specific technical expertise to join the conversation, and managing the time box of the event.

The final step is when the ScrumMaster calls for the team to commit to delivering the work.

There are many great web articles that list things a Scrum Master does. Here are a couple of good ones:

https://www.mountaingoatsoftware.com/agile/scrum/scrummaster
http://agiletrail.com/2011/11/14/42-tasks-for-a-scrum-masters-job/

Aside from facilitators, ScrumMasters are also the team’s protector, an overall evangelist and enforcer of the Scrum method, and a coach.

Surprised? What does the ScrumMaster do in your organization? Are there improvements that can be made? I welcome your feedback, questions and comments.

In my personal experience working on various software development projects, the concept of team energy often appears to be either undervalued or benignly ignored by management teams. The reasons are many. First of all, the term may be confused with “team velocity” which is a relative measurement of a team’s average output or productivity. If the velocity appears to be at either predictable or positive levels, the management team may choose to believe that team energy is also at satisfactory levels. Organizations may attempt to boost employee morale by putting together team-building exercises and outing events. This macro approach may result in generating a perceived positive effect on team energy, thus obscuring the need for focus on individual teams.  So, what is team energy and why should managers consider devoting some attention to it?

When thinking in terms of team energy, one can look at it as building credit with each individual team. One can also look at it from an analogy of having a rainy day fund. From a management’s standpoint it is important to keep team energy in the positive territory. This helps ensure that the team will likely empower themselves to exceed expectations, as well as step up during times of crisis or high pressure situations. I have worked in high energy teams, in which members voluntarily pushed themselves past regular working hours to produce deliverables. These cases did not involve any direct increase in compensation or promotion. People naturally wanted to succeed because they possessed enough energy to do so. I have also witnessed the opposite, where a team’s energy was low, deliverables were in a perpetual state of tardiness and the backlog was steadily accruing bugs. Developers and testers did not feel empowered to succeed and entered a cycle of doing the absolute bare minimum to “get the management off their back”.

Science behind building teams 
Agile methodologies, whether Scrum or Kanban, prescribe various techniques that are focused on continuous improvement that may positively affect team energy. Regardless of whether an organization has truly embraced Agile, it is difficult to find managers that would oppose efforts in improving a team’s processes of delivering faster and at a higher value. After all, who is against a boost in productivity? There is a hidden psychological component to continuous improvement that has a causal effect on team energy. This component is more associated with the experience of individual team members.

Studies of team dynamics such as ones conducted by MIT’s Human Dynamics Laboratory, and documented in Harvard Business Review suggest that there is a science to building high performing and high energy teams. One of the keys is to focus on the human brain and social dynamics of a group. Your teams may be composed of introverts as well as extroverts and a wide range of personalities, but there is a common factor that seems to persist. The studies show that humans feel good when they achieve their goals and overcome obstacles. A human brain actually rewards its owner with extra levels of dopamine when a goal is achieved. When the team feels good more often than not, the team energy goes up. When the opposite occurs, team energy goes down. Therefore, focusing on small achievable goals not only helps the organization to shift focus of deliverables, but it also fosters this psychological benefit of achievement for each individual team member.

Measurements 
An organization may choose to periodically measure team energy. One way to achieve such measurement is through anonymous surveys. Usually this is done at a more enterprise level to gauge the overall organization energy. There is certainly value in doing that, but the effort is not focused and may not necessarily apply to teams. Small teams may not produce very accurate results. There may be disincentives to be frank when answering a survey because team members may feel singled out and fear reprisals from management. In addition, more introverted team members may choose not to “rock the boat”.  A more effective and team-focused approach is to have an Agile coach periodically take team energy measurements. An opportune time may be during team retrospectives, when a team is usually more receptive to be candid.  Most importantly, these measurements do not need to be secretly stored in a manager’s vault but should be shared with the team. Adding transparency to the team building and management process will not only increase team energy, but also foster leadership skills among the more proactive and extraverted team members.

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.

Face to Face is the best method of communication and that’s the method that Agile promotes.  The benefits of Co-located teams are numerous-  streamlines product development, promotes trust , accelerates communication among the team members, provides opportunities to collaborate, promotes reliability, fosters closer working relationship and the list of benefits can go on and on…..

Teams should co-locate as often as possible, because of the benefits of Osmotic communication.  Osmotic communication was coined by Alistair Cockburn, one of the originators of Agile.  “Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work”.

But in reality, not many of us have the luxury of working with our entire team in a single location. For most of the organizations I work with, the teams are all over the world. Many of these teams work with team members not only in different locations but sometimes in different continents.

So how do these Agile teams communicate and work with each other effectively?

Here are some simple ways to engage the entire team and not let any team members go in dark:

• Establish team core hours for facilitated discussions and working sessions. The team can establish a certain time of day when the entire team is available for group discussions: talk about the backlog, have design reviews or delayed discussions on any topic and dedicate that hour or two hours just for the team. The team members can be available on tools like Skype, or phone, and they can work on different things if the team doesn’t have any discussion items for the day. The idea is to have all team members available and ready to talk as if they are in the same room.

• Establish Team norms or working agreements. The team must decide on rules for working together and communicating with each other and these rules or working agreements should be followed by all team members and fair to all team members.  So for example, don’t have meetings that require one group in a certain time-zone to always be the ones to get up early or stay late.  Switch it around and make it fair.  Include things like phone etiquette in your norms.

• Utilize the Scrum of Scrum technique. A technique to scale Scrum up for large groups, consisting of dividing the groups into Agile teams of 5-10. Each daily scrum within a sub-team ends by designating one member as “ambassador” to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums. This same technique can be used when the team members are across continents and time zones and therefore cannot be available for Daily team ceremonies.  Each holds their own daily Scrum and then participates in a Scrum of Scums later on.

• Involve the entire team for Ceremonies. As much as possible, always involve all locations for ceremonies, such as Sprint planning, review, retrospectives, and daily stand-ups. Daily stand-ups or handoffs between remote teams bridge communications and establish a framework for frequent synchronization and collaboration.  If you have access to video conferencing, great!  If not cheap portable cameras attached to a chair and a laptop make a great improvisation.

• Rotate members around – cross pollinate. Rotate team members between various locations, this might be expensive but leads to a cross trained and fungible team. Even sending one person from each location to work with other groups will help build stronger working relationships and create cultural understanding.

• Use On-line collaboration tools. In the absence of co-location, teams will have to rely heavily on automated tools for collaboration and to create a single repository that keeps the efforts of the teams in full view for all team members.  The osmotic communication flow can be somewhat replicated for the distributed team using the virtual tools such as IM, Skype, Webex, and other on-line collaborative tools.

At  a team-level, use automated tools like Jira, Planbox, LeanKit, other shareware or low-cost options to maintain synchronization and visibility into work.  At the cross-team or program level, tools like Version One, Rally, other enterprise-level options can be used.

• Use a common document repository (ex. Sharepoint, Knowledgelink) for sharing information.
• Develop a shared team vocabulary and a team website
• Hold in person team meetings at regular cadence. Team members should meet others in person at regular intervals. While sometimes costly, this investment is worthwhile. People are the most important part of the team, they work really well together when they know and understand the person they work with just not a name. So setting up a regular cadence of team members meeting face to face helps improve the distributed team dynamics.
• Establish Clear Sprint goals and expectations. The team members should have clarity on the work they have to complete to meet the team’s objectives. Daily Scrums can be used by the team members to be mutually accountable and to set clear expectations for each other.
• Over communicate – When the team members are distributed sending in a quick summary of the discussions makes sure that everyone is on the same page.
• Be knowledgeable and respectful of the different cultures making up your distributed teams, such as holidays and working hours.

Lastly: Be patient.

If the team members are in different time zones being respectful and cognizant of the time difference is extremely helpful. Unless a decision needs to be made immediately, the team members should be given time to respond because they might be working on a different schedule or in a different time zone.

I’ve been working with large organizations where team members are in multiple locations quite a bit lately. This environment can be challenging, especially in ensuring everyone is engaged and not multitasking during Sprint Events. While there are a number of things I’ve covered in my blog “The Reality of Distributed Teams”, here are 4 specific things you can do to help build better agility with your remote teams.

1. Encourage team members in similar locations to meet in a room, and not just “dial-in” from their desk.

• Builds team continuity
• Reduces the urge to multi-task
• Follows the Agile Principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

2. Follow Sprint Event Agendas

• Ensures the team keeps on task and is not sidetracked
• Ensures we have a clear outcome to strive to for each event
• Keep to a time-box, and don’t create extra meetings to make up for not reaching the desired outcome at the end of a prescribed Sprint Event

3. Use a tool like planningpoker.com to size stories

• Simultaneous Pointing – reduce influence by more senior members
• Encourages discussion to get complete understanding of stories
• Supports “team sizing” instead of “individual” sizing

4. Allow for silence

• Creates an opportunity for the team to talk
• Product Owner and Scrum Master should not be doing all the talking, especially during planning. In Sprint Planning or Story Grooming/Refinement once the PO has introduced a new story, turn the meeting over to the team for questions and discussion amongst themselves. If there is awkward silence for a bit, it’s OK. Before moving on, be sure and ask if the team needs more time to discuss.

Whether your team has been together a long time or is just starting out, creating an environment for success by actively addressing remote issues is sure to add value to your team. Give these suggestions a try and let me know your successes!

Over the course of this three-part blog series, I will cover all of the 12 Principles. In this second installment I hope I’ve peeked your curiosity. As I said in Part-1, I believe following these principles is the core of being “Agile”.  Is your organization embracing the fundamental principles of Agile? Are you open to culture change?

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

OK, we’ve hired good people, who want to do a good job. Now we just have to show them we believe in them. If it were only that easy. Too many times fear drives an organization. Too many project failures, a culture of distrust, or simply a mindset of “this is how we’ve always done it” leads to micromanaging and difficulty in enabling teams to take ownership of their work.

I’ve personally been a part of many organizations who falter when trying to motivate teams. Or, even worse they totally fail in the trust arena. Is it scary to start moving away from micromanaging and micro-reporting? I’m sure it is. With Agile we have built in controls to help us manage teams at “arms-length”. We can listen in on Daily Scrums, and must attend the Sprint Review to see the teams’ sprint accomplishments and provide feedback. Yes, a team may “fail”, but what have you lost? In a two week sprint, you may have lost a little time. Do you think the team will have learned from the Sprint? Will they try harder to succeed next time? Is a two week loss better than a year of micro-managing and still not getting the desired results? You bet!

Organizations need to ensure the teams are supported appropriately with dedicated team members, regular involvement by the business, access to information, and ownership of delivery. Motivate the team with small rewards and acknowledgement of successes, and watch them deliver!

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation 

Most of us recognize that when we are together face-to-face communication flows. Spontaneous questions are raised, and connections are made.

This principle may not be so easy to follow if the teams are not collocated. Put a little extra effort into the use of technology to emulate face-to-face communication whenever possible. Team members will form stronger bonds. The benefits include stronger and more motivated teams, as well as reducing risk of miscommunication including errors regarding the intent of user stories and acceptance criteria.

Lead by example, and allow introverts to have their privacy, but don’t miss this opportunity to build team that becomes highly performing.

 7. Working software is the primary measure of progress 

I was once told “watch the runner, not the baton”. Too many times, organizations focus on hours worked (or sat in the office), rather than actual outputs. This principle reminds us that what we really want to watch is the outcome.

Agile measures velocity of the teams’ completed work. If a team is struggling to meet their commitment, then look at root causes. It is likely there are other issues that need to be addressed. Are the user stories actually “ready” to be accepted into the sprint? Is someone trying to get the team to commit to more work than they can deliver? Start with small steps and build on successes. It is a success when the team delivers what they commit to. Then ask the team to identify process or people improvements during their retrospective to help grow velocity.

Place your emphasis on seeing quality deliverables at Sprint Reviews, not on how long the team works, or how busy they look.

 8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

We’ve all had those moments where we feel staying just a little bit late at work, or skipping lunch will help us meet our deliverables. After all, it’s just “this time”… if only that were true! Instead, working late and skipping lunches becomes a habit. Next thing you know, it isn’t just one team member; it’s the majority of the team. While some leaders jump for joy, there are repercussions.

Even outside of software development workers engaged for more than 50 hours a week open themselves up for health issues, and may not actually be as productive as they would working a standard week. See http://www.cnbc.com/2015/01/26/working-more-than-50-hours-makes-you-less-productive.html

 When it comes to software, the idea of working at a sustainable pace originates in XP practices. Over time implementation of all the principles enable us to create an environment where all teams can work at a sustainable pace. See http://www.langrsoft.com/articles/sustainablePace.shtml

 Work-life Balance isn’t just a cliché. Put working at a sustainable pace into practice, and watch the results.

With just one more installment left, I look forward to your comments. Let me know how your organization incorporates the Agile Principles into their culture, or struggles you face in following Agile Principles.

You’re driving along on a four-lane freeway.  For a football field’s length in front of you, there are no cars.  And behind you, a similar distance is free of traffic.  It’s like you’re all alone – I know, I know, for some of you that seems an impossibility, but go with me here.

It’s about 10 o’clock on a bright, sunny Monday morning and you’re headed up the east coast for a business meeting a few hours away.  There are big fluffy clouds in the sky, you’ve got the sun roof open, your music is blaring, and you’re singing along – not well, but nobody can hear or see you, so who cares?

The speed limit is 70 mph, and you’re in the third lane from the right going between 72 and 74, making sure not to go over that magic 5 mph “speed-safe” window.  You’re alert to the situation around you, not rushing to overtake the cars in front of you, yet staying ahead of those behind you.  You’re relaxed, and content with the progress you’re making.  You check the rearview mirror, and suddenly.…

BOOM!

There’s a car in the lane behind you.  Barreling down on you.  Going 15, 20, maybe even 25 miles faster than you are.

What’s your first reaction?

DANGER!! Don’t Move!
My first reaction is….danger, stay alert, don’t move.

I watch what the car’s doing.  It’s approaching so fast, there’s no way for either of us to safely recover if we both make a move in the same direction.

So I maintain my speed, stay my course, and watch to see what happens.

The car comes right up behind me, so close I can’t see the head lights in my rearview mirror.  And sits right on my tail.

O.K., buddy
Really?

With all this space to go around me, you’re going to sit right on my tail!?!

And what’s with the wiggling back and forth, is that a signal for me to do something?  Maybe a sign that you’re a madman?

What do you expect me to do, move over?

Why should I?  After all, you had, and still have, plenty of room to safely get around me.  It’s not like I’m going slow, it’s just not fast enough for you.  Well, I’m not gonna move over.

But maybe I’ll slow down juuust-a-bit.

A Common Response
My reaction above is considered “passive-aggressive”.  A passive aggressive response is a way of indirectly retaliating or resisting demands made by others.  It’s a subtle way of expressing irritation, anger, or resentment, when we can’t communicate directly with others or don’t know how to express those feelings.

Passive-aggressive behavior is expressed in many ways including pouting, sulking, forgetfulness, stubbornness, procrastination, not providing input, the “silent treatment”, resisting or evading requests, creating confusion, purposeful inefficiency, and passive obstruction.

Any of these sound familiar?  They’re are common responses, ones we all exhibit from time to time because they’re easier than confrontation, and require less skill than more positive, assertive ways of expressing ourselves.

While passive-aggressive responses are not the healthiest type of response, as long as it’s not the only way we behave, it can be helpful in the short term especially if there’s a need for acceptance, fear of conflict, dependency, power inequity, or perceived threat.

Consider This
In every organization, there are people who are content where they are, satisfied with the progress they’re making.  They look up one day to check the rearview mirror, and suddenly.…

BOOM!

The change car is right behind them.  Barreling down on them.  Going 2, 3, maybe even 5 times faster than they are.  Urging them to move faster or move to the side.  And you’re driving it.

What’s their reaction?

DANGER!! Don’t Move!
Voila!  There you have it, resistance to change…behavior “that serves to maintain the status quo in the face of pressure to alter it”.[1]

Do you have stories about resistance to change?

Please share…I’d love to hear them!

[1] Zaltman, G., & Duncan, R. (1977). Strategies for planned change. New York: Wiley Interscience

Velocity, the measure of total story points completed in a sprint, is often misunderstood, and used as a “stick” against teams rather than a “carrot”.

I was once asked about trying to prevent a dip in velocity during team member vacations. Today I saw a post in LinkedIn titled “Tips and Techniques for Maintaining Velocity during vacation times”.  The very question of how to keep velocity the same during vacations represents a gap in understanding of both why we use velocity and what velocity is measuring. Velocity is expected to dip when team capacity drops. Otherwise, we are falsely trying to use velocity as a prediction of what can be accomplished in a sprint. Where “management” stresses the need to have a steady velocity regardless of what is going on in a given sprint, it is like using a “stick” to motivate the team. It also encourages “gaming the system”, creating a false sense of security and velocity. We use delivery of quality software as our main measure of success. We use velocity to predict how much work we can commit to in order to become reliable, predictable, and consistent.

Most teams use points to estimate stories, the number of points completed is the teams velocity. The goal is to become predictable and consistent. Velocity is not normalized across teams, and cannot be compared across teams. Once you realize this fact, then it is easier to accept an explainable dip in velocity. Note: If you are following SAFe (Scaled Agile Framework) and trying to normalize points see http://www.scaledagileframework.com/iteration-planning/  In Safe, a 1-point story is normalize, but story points vary from there. A SAFe teams’ velocity should not be compared to any other.

Given a team has been together for at least five sprints, and story points are being used for relative sizing of stories in a consistent fashion, the team’s velocity will begin to stabilize. Good Retrospectives will provide insight into improvements activities that may help increase the team’s velocity a point or two each sprint.

With a stable velocity and team, we can predict what velocity can be achieved for any sprint. If Monday is a holiday, or if one team member is on vacation for the entire sprint, ScrumMasters can help guide the team to not over-commit. Thus supporting a sustainable pace, and exhibiting the true value of velocity as a measure.

Let’s take a look:

Team Wolf

Team Wolf has 6 members, and a velocity of 40 for a two week sprint. I calculate capacity (the number of hours available to work in a sprint) at 6 hours per person, per day. For Team Wolf, a 10 day sprint has 360 capacity hours.

One bank holiday during a sprint

Capacity is 324 hours, (6 * 6 * 9) resulting in a 10% lower number of hours in which to complete the sprint’s work. I would encourage the team to commit to approximately 10% less work and aim for a velocity of 36 points.

One member on vacation for the entire sprint

Capacity is 300 hours (5 * 6 * 10) resulting in a 17% lower number of hours for a sprint. I would encourage the team to commit to approximately 17% less velocity, or 33 points.

Velocity dips can happen anytime for a number of reasons. A planned dip is not something to beat a team up over. Achieving the teams’ committed velocity is an excellent carrot. Reward teams, and celebrate successes.

I’m often asked how to create empowered teams.  The question usually includes the exclamation “I told them they’re empowered, but they’re not acting like it”, and an expectation that I’ll be able to provide a successful formula or recipe that can be replicated.  Well, I don’t have a specific formula, but here are some important concepts I’ve learned.

Empowerment is a two-way street
It’s not enough to anoint people or teams as “empowered”, they need an environment that is congruent with empowerment, and they have to accept the mantle of being empowered.

Providing an empowering environment is the responsibility of leadership, top-to-bottom in an organization; accepting the mantle of empowerment is the responsibility of each individual and team.

As individual team-members go, so goes the team
Even in exactly the same environment, different teams will likely exhibit different levels of empowerment, because each individual team members’ level of acceptance is different.  Personal style, culture, history, experience, values, comfort with ambiguity, and risk tolerance all affect an individual’s willingness to “be empowered”, and the extent to which they exercise that empowerment.

While you and I will vary in how we embrace empowerment, we both need the same conditions to be met.  To feel and act empowered, we need:

Clarity – I am clear about what needs to be accomplished (intent), and why it’s important (value), even if the how is uncertain.  I understand the purpose and what success looks like.

Ability – I have the knowledge and skills to do it, even if I don’t have specific experience.

Agency – I have the authority to make decisions about how I do it.

Safety – I feel safe to do it. To make decisions and act; to fail so I can learn; to communicate honestly and openly.

Belief – I believe I can do it. I have self-confidence and self-efficacy.

Interest – I am interested in doing it.

Creating an Empowering Environment
Julian Rappaport, in “Studies of Empowerment” (1984) said “it is easy to define empowerment by its absence, but difficult to define in action as it takes on different forms in different people and contexts.”

Regardless of how it’s accomplished, successful empowering environments satisfy the conditions identified above, and actively encourage and support individuals to grow in these areas.  There are underlying themes that work from one organization to another, including:

• Don’t solve people’s problems – help them learn how to solve their own
• Change the language – thoughtfully replacing key phrases can have a huge impact
• Truly believe in the good intent of others – people don’t set out to do the wrong thing
• Make learning important – not training, although that’s a component, but learning by doing
• Give permission to fail –we learn the most when we’re free to fail
• Provide opportunities to succeed – it builds confidence
• Decisions are choices, accept the consequences of yours – and show others how to do the same
• Be curious – but don’t question, it erodes confidence
• Become story tellers – stories inspire and provide context and clarity
• Set reasonable boundaries – and help others learn to expand them to broaden their sphere of control
• Expect honesty – not compliance
• Walk your talk – be visible and show how it’s done
• Help them learn to walk – challenge people to step outside their comfort zones, and support them

For a story of what Stephen R. Covey calls “the most empowering organization I’ve ever seen”, check out the book Turn This Ship Around by L. David Marquet.

I’d love to hear your thoughts….how do you help create a sense of empowerment?

Last month I had the opportunity to attend my first ever Coaches Retreat. The retreat was made up of about 80 participants. Preparation for the retreat started months in advance, even for us participants. First we were requested to send in an introduction poster. Second, we were asked to suggest topics for the retreats. As I had never been to a retreat like this before, I didn’t exactly know what to expect. So I thought I’d share my experience of the event.

One of the first things we did after the retreat got going was to form teams around topics. There were plenty to choose from, after all the customers (us attendees) had sent them in. We “self-organized” in teams around topics we were passionate about. I became part of a team organized around the topic of Virtual Teams. Next we set off to plan for three 180 minute sprints. Our team was awesome. We picked a team name; stormed a little, formed a little… We created a vision, a backlog, and committed to sprint 1. Of course we did all the ceremonies for each sprint. Each team’s sprint review was in front of the entire group which provided an opportunity for feedback from customers!

Three days of working with peers from near and far led to each team providing a “product” related to their selected topic in 180 minutes. Wow, what an experience! What a result!

My experience of the retreat was not only a learning experience, but a growing experience. I experienced true team self-organization, and boy was it cool. Within my team, I learned that utilizing Scrum Values (Focus, Courage, Openness, Commitment, and Respect) are as important as the Principles and Manifesto. As our team went through storming to norming, we demonstrated these values. We talked about the work ahead of us, and how we were feeling. Yes, feeling! Our volunteer Scrum Master wasn’t sure she was in the right role; I wasn’t sure I was with the right team. I felt that our team more than any other practiced what we preach as ScrumMasters, Coaches and Trainers. I credit each one of us with following Scrum Values to get through storming quickly. In seeing everything the other teams delivered I gained a set of tools I can utilize anytime. I grew in my sense of belonging to the Agile community, and pushed through my fear and lack of control by exhibiting Scrum Values, and being engaged with my team. The retreat was an opportunity for me to continue a journey of learning and growing, all while making new friends.

Here’s to Team Dysfunction!

In Part 1 of this blog series, I presented a high-level summary of the many different opportunities that Business Analysts (BA) can pursue in an Agile BA role, often resulting in new and exciting experiences. I also highlighted some of the differences between today’s “Agile BA” and the traditional “Waterfall BA”. Finally, I presented an interesting metaphor for today’s Agile BA, one of a Major League Baseball “utility player” (in this case, Jose Oquendo – a player who accomplished the rare feat of playing at every position during his 12-year MLB career.)

Part 2 of this blog entry focuses on the five key functional areas (aka “opportunities”) where I feel Agile BA’s can contribute or take outright ownership of a certain project task or responsibility. A key point to remember is that in order for these opportunities to present themselves, circumstances need to exist which ultimately depend on the dynamics of a project and the makeup of the particular team. Surely we don’t want to step on any toes or introduce team conflict. But if the opportunity is presented and a need has clearly been established, take the bull by the horns and run with these five opportunities:

• Project Management
• Product Management (aka the Product Backlog)
• Testing
• Documentation
• Collaboration (with Project Stakeholders and Team Members)

PROJECT MANAGEMENT – WORK WITH (OR AS) THE SCRUMMASTER

On today’s project teams, Agile BA’s are usually best-suited to provide project management/ScrumMaster support whenever the need arises. And let’s be real – with PM’s and ScrumMasters constantly being pulled in several different directions, the Agile BA can tackle a numerous amount of responsibilities associated with this role.

In all likelihood, Agile BA’s have the experience necessary to handle many of the day-to-day responsibilities of a PM or ScrumMaster. The Agile BA can facilitate any of the recurring “events” as needed – the daily scrum (or “standup”), sprint planning, sprint review and sprint retrospective.

In many cases, the Agile BA is as close to (or even sometimes more engaged) with the project’s product backlog than the actual PM. This knowledge of the past, current and future state of the product backlog enables the Agile BA to assist with several project-related artifacts – for example, sprint and release burn-up/burn-down charts.

Successfully leading and delivering on many of these crucial project events and tasks not only contributes to the success of the team, but it also provides valuable on-the-job training. For Agile BA’s who want to eventually move into a PM or ScrumMaster role, this experience is invaluable.

THE “PROXY PRODUCT OWNER” – TODAY’S “PRODUCT OWNER” REALITY

Lately, it seems that a fully-engaged Product Owner is more of a luxury than a norm on today’s Agile projects. Agile BA’s can benefit from the potential subject-matter knowledge gained and added exposure by bridging this gap and acting as a “Proxy Product Owner”. In cases where a truly-dedicated Product Owner is not a reality, no one is better suited to step into this role than the Agile BA.

BA’s usually develop a solid rapport with the customer and can act as a liaison between the customer and the project team whenever needed. And as stated earlier, the Agile BA probably has the most experience working with the project’s user stories and backlog. On fast-moving development projects, many decisions are needed real-time, and waiting for answers from an absent Product Owner usually hinders the team’s progress.

TESTING – AFTERALL, WHO KNOWS THE STORY BETTER THAN THE BA?

Many Agile teams have already moved to this model, but for teams which have not, here is another opportunity. As previously mentioned, BA’s handing their work over to testers ‘waterfall-style’ is an outdated and inefficient practice. I have seen that 2-3 fully engaged Agile BA’s can efficiently handle the workload of 2-3 full-time BA’s and 2-3 full-time testers. Instead of separating requirements and functional testing tasks for a particular piece of functionality (e.g. user story), Agile BA’s focus on the user story as a whole – from origination (story creation) through implementation (fully-tested, potentially shippable product.) This is not to say that other methods of specialized testing aren’t needed, but in many cases, the best person to drive a user story to “done” is the Agile BA.

Automated testing has also become an invaluable practice on software development projects and provides yet another opportunity for Agile BA’s to contribute in the testing arena. With working knowledge of the current state of the application and product backlog, Agile BA’s have the capability to define and develop a project’s ongoing automated testing suite. Depending on the testing tools employed by the team, BA’s can “pair” with a technical resource (e.g. java developer). In this scenario, the developer handles the technical components of the automated testing suite while the BA designs, builds and manages the suite from a functional perspective.

COLLABORATION – BEFORE YOU KNOW IT, YOU’RE THE PROJECT’S “GO-TO” PERSON

I have included “collaboration” as an opportunity for Agile BA’s because collaboration, indeed, leads to opportunities. In my previous Waterfall experiences, BA’s didn’t collaborate much. In today’s Agile world, the Agile BA can really become a project’s “go-to” person. The collaboration piece also closely ties in with the previously mentioned PM/ScrumMaster and Product Owner opportunities.

For example, facilitating a sprint review or presenting a product demo provides invaluable experience and exposure. Sprint review meetings often include executives and/or stakeholders whom otherwise do not participate at all towards the project (basically, you see them once every two weeks). Leading these sessions provides direct communication with the “customer”, providing valuable feedback which can be relayed back to the team. Since entire project teams rarely attend these informational sessions, the team will start looking to you to provide the important feedback that we all value working on Agile projects. Personally, I have always looked forward to returning to the team room and have always appreciated team members asking, “so, how did it go!?”, after each sprint demo. At the same time, I am always glad to be able to provide that feedback to the team which we can use for future success.

DOCUMENTATION – CHANGE DOCUMENTATION FROM A TEDIUS TASK TO A VALUABLE COMMODITY

Even in today’s Agile world, most software development projects require some essential “dirty work”. The BA role has certainly evolved, but we should not completely abandon our roots. While we’ve all heard repeatedly (sometimes to our detriment) that the Agile Manifesto preaches valuing working software over comprehensive documentation, certain documentation can be critical to the success of projects.

I have seen that, if applied effectively, this basic Agile tenet not only reduces redundant documentation, but it helps teams focus on where documentation actually adds value to a project. Instead of documenting a requirement or process as part of an extensive list of deliverables promised six months ago (which will never be read or will become irrelevant), we document exactly what is needed, today. Most likely, information and processes which need to be documented aren’t even known at the outset of the project. Due to the fact that writing is a core skillset possessed by most BA’s, Agile BA’s are well-positioned to accomplish many of the documentation deliverables needed over the duration of a project.

NOW, GET TO WORK!

You’ve just finished reading this blog entry and your new sprint starts next week. It’s not entirely unrealistic that you can begin working in each of the areas mentioned in this blog over the next two weeks (if you haven’t been already). Offer to facilitate your upcoming sprint planning or review session. Ask the PM if you can contribute to the upcoming metrics reports (e.g. sprint/release burndown). If you aren’t already, start testing user stories – start at a high-level, ensuring that all acceptance criteria is met. Take a few hours, dive into and familiarize yourself with the product backlog. Offer to facilitate the sprint review and invite stakeholders who have become disengaged. And finally, document that process flow which has been taking up valuable whiteboard real-estate for the last several weeks (and really needs to be erased)!

Before you know it, you’re pursuing five completely new opportunities in a matter of two weeks. It might be similar to trying out three completely new positions on a baseball diamond. More importantly, you may even finally be able to explain exactly why Jose Oquendo was such a valuable player to have on a Major League Baseball team.

Teams that are using the Scrum framework to become more Agile usually use velocity as a metric to help them understand how much value can be accomplished in a given sprint—which also gives a good idea of what value the release can hold.  This metric is something each team strives to improve through continuous improvement of their processes and teamwork.  However, the meaning is not altogether taken at face value…

When you think of velocity, what do you think of?  Do you think about the higher the number, the better or equating velocity to the amount of work the team does?  Does your team strive for high velocity?  If so, why?

Teams use velocity for a multitude of reasons; few of which are actually valid.  These valid reasons usually include improving themselves, using it for planning purposes, and sometimes for proving their abilities as a team.

When you remove the valid reasons, there are many other reasons that velocity is used as a metric, and some of them are not so ‘friendly’ to the team, or to being Agile.  A few I have heard or seen include: measuring the team’s pace, using it to force the team to do more than they are really capable of, using it to mix up teams, having it prove that “Agile fails”, apply it as a way to show risk to the project, and, maybe the worst, using velocity as a way to push the team into a ‘death march’ to completion.  I have seen many teams that end up failing because someone, who may not understand the purpose of velocity, pushes the team over the edge and they “storm” over how they should be working.

When we look at velocity, it is indeed meant to measure the throughput of the team in a given sprint—how much the team completed during the sprint.  The original intent of this measurement is to assist in planning the amount of work that the team can accomplish in a sprint, and therefore how much scope can be accomplished in a given number of sprints, or a release.

By looking at the definition and the original intent, you can clearly see how the intent can be morphed or twisted into some other purposes, like those listed above as the ‘not-so-friendly’.  This is not unlike many large companies in their infancy of an Agile transformation—they are not sure what to do with this new metric and so they use it as they see fit, even if it’s not the purpose.  When this happens, it tends to cause riffs inside the teams and across teams.  The worst scenario is when organizations that do not have the proper training or coaching in Agile attempt to ‘read between the lines’ and begin to infer things about the team, such as how hard they are working or even whether they are working at all.

It is important to understand that numbers do not tell the whole story, but merely start the conversation.  The conversation is worthwhile so that the team, and the organization, can better recognize what is happening with the team and how they are attempting to become more Agile.

Another murky side to how some teams’ velocities are used is to compare team to team—as if a higher velocity by one team over another means there is a better team.  The idea that teams can be compared by simply comparing velocities is a bit absurd—there are so many reasons that one team’s velocity may be higher than another’s, which is more evidence that numbers do not tell the whole story.  When velocities are used to compare team against team, you find that it creates friction between teams.  As the relationship between teams is strained, the value that the teams produce begins to dwindle or be of less quality.

Velocity is one thing that a team should never compromise; their velocity is what helps to keep them on a more sustainable pace and helps prevent them from getting burned out.  The biggest thing that velocity gives a team is a way to keep from committing to more than they can realistically deliver.

After reading this, would you change how you measure your team’s, or teams’, velocity?  Does it change how you interact with other teams?  Feel free to comment on how you use, will change, or see velocity.

As I write this blog entry, I’m hoping that the curiosity (or confusion) of the title captures an audience. Readers will ask themselves, “Who in the heck is Jose Oquendo? I’ve never seen his name among the likes of the Agile pioneers. Has he written a book on Agile or Scrum? Maybe I saw his name on one of the Agile blogs or discussion threads that I frequent?”

In fact, you won’t find Oquendo’s name in any of those places. In the spirit of baseball season (and warmer days ahead!), Jose Oquendo was actually a Major League Baseball player in the 1980’s, playing most of his career with the St. Louis Cardinals.

Perhaps curiosity has gotten the better of you yet again, and you look up Oquendo’s statistics. You’ll discover that Oquendo wasn’t a great hitter, statistically-speaking. His career .256 batting average and 14 homeruns over a 12 year MLB career is hardly astonishing.

People who followed Major League Baseball in the 1980’s, however, would most likely recognize Oquendo’s name, and more specifically, the feat which made him unique as a player. Oquendo has done something that only a handful of players have ever done in the long history of Major League Baseball – he’s played EVERY POSITION on the baseball diamond (all nine positions in total).

Oquendo was an average defensive player and his value obviously wasn’t driven from his aforementioned offensive statistics. He was, however, one of the most valuable players on those successful Cardinal teams of the 80’s, as the unique quality he brought to his team was derived from a term referred to in baseball lingo as “The Utility Player”. (Interestingly enough, Oquendo’s nickname during his career was “Secret Weapon”.)

Over the course of a 162-game baseball season, players get tired, injured and need days off. Trades are executed, changing the dynamic of a team with one phone call. Further complicating matters, baseball teams are limited to a set number of roster spots. Due to these realities and constraints of a grueling baseball season, every team needs a player like Oquendo who can step up and fill in when opportunities and challenges present themselves. And that is precisely why Oquendo was able to remain in the big leagues for an amazing 12 years, despite the glaring deficiency in his previously noted statistics.

Oquendo’s unique accomplishment leads us directly into the topic of the Agile Business Analyst (BA), as today’s Agile BA is your team’s “Utility Player”. Today’s Agile BA is your team’s Jose Oquendo.

A LITTLE HISTORY – THE “WATERFALL BUSINESS ANALYST”

Before we get into the opportunities afforded to BA’s in today’s Agile world, first, a little walk down memory lane. Historically (and generally) speaking – as these are only my personal observations and experiences – a Business Analyst on a Waterfall project wrote requirements. Maybe they also wrote test cases to be “handed off” and used later. In many cases, requirements were written and reviewed anywhere from six to nine months before documented functionality was even implemented. As we know, especially in today’s world, a lot can change in six months.

I can remember personally writing requirements for a project in this “Waterfall BA” role. After moving onto another project entirely, I was told several months down the road, “’Project ABC’ was implemented this past weekend – nice work.” Even then, it amazed me that many times I never even had the opportunity to see the results of my work. Usually, I was already working on an entirely new project, or more specifically, another completely new set of requirements.

From a communications perspective, BA’s collaborated up-front mostly with potential users or sellers of the software in order to define requirements. Collaboration with developers was less common and usually limited to a specific timeframe. I actually worked on a project where a Development Manager once informed our team during a stressful phase of a project, “please do not disturb the developers over the next several weeks unless absolutely necessary.” (So much for collaboration…) In retrospective, it’s amazing to me that this directive seemed entirely normal to me at the time.

Communication with testers seemed even rarer – by the very definition, on a Waterfall project, I’ve already passed my knowledge on to the testers – it’s now their responsibility. I’m more or less out of the loop. By the time the specific requirements are being tested, I’m already off onto an entirely new project.

In my personal opinion the monotony of the BA role on a Waterfall project was sometimes unbearable. Month-long requirements cycles, workdays with little or no variation, and some days with little or no collaboration with other team members outside of standard team meetings became a day to day, week to week, month to month grind, with no end in sight.

AND NOW INTRODUCING… THE “AGILE BUSINESS ANALYST”

Fast-forward several years (and several Agile project experiences) and I have found that the role of today’s Agile Business Analyst has been significantly enhanced on teams practicing Agile methodologies and more specifically, Scrum. Simply as a result of team set-up, structure, responsibilities – and most importantly, opportunities – I feel that Agile teams have enhanced the role of the Business Analyst by providing opportunities which were never seemingly available on teams using the traditional Waterfall approach. There are new opportunities for me to bring value to my team and my project as a true “Utility Player”, my team’s Jose Oquendo.

The role of the Agile BA is really what one makes of it. I can remain content with the day to day “traditional” responsibilities and barriers associated with the BA role if I so choose; back to the baseball analogy – I can remain content playing one position. Or, I can pursue all of the opportunities provided to me in this newly-defined role, benefitting from new and exciting experiences as a result; I can play many different positions, each one further contributing to the short and long-term success of the team.

Today, as an Agile BA, I have opportunities – in the form of different roles and responsibilities – which not only enhance my role within the team but also allow me to add significant value to the project. These roles and responsibilities span not only across functional areas of expertise (e.g. Project Management, Testing, etc.) but they also span over the entire lifetime of a software development project (i.e. Project Kickoff to Implementation). In this sense, Agile BA’s are not only more valuable to their respective teams, they are more valuable AND for a longer period of time – basically, the entire lifespan of a project. I have seen specifically that Agile BA’s can greatly enhance their impact on project teams and the quality of their projects in the following five areas:

• Project Management
• Product Management (aka the Product Backlog)
• Testing
• Documentation
• Collaboration (with Project Stakeholders and Team Members)

We’ll elaborate – in a follow-up blog entry – specifically how Agile BA’s can enhance their role and add value to a project by directly contributing to the five functional areas listed above.

Scrum purists will tell you co-located teams are the way to go. If only it was that easy!

As large organizations adopt scrum, they find themselves struggling with how to be more Agile when many of their teams are distributed. As coaches and trainers, it is our responsibility to support this reality.

There are many blogs and articles like this one on the web that talk about working with remote teams.

Many of the articles I see offer common sense tips like:

• Make the most of tools for instant messaging, video conferencing, and shared content.
• For ceremonies, use video conferencing whenever possible.
• Ensure Team Agreements, Definition of Done, and Definition of Ready are in a shared location.
• Team Agreements need to include core hours when everyone will be on instant messaging.

Here are some of my own more unique suggestions:

• Dealing with time zone differences – Although ceremonies should be at the same time/place whenever possible, consider alternating times by month, or sprint. For example, on odd months favor east coast times, while in even months favor west coast times.  Don’t do too small of an increment (like daily).
• Time for a celebration – Ensure everyone on the team, regardless of location, goes out and celebrates. Schedule an extra 15 minutes post scrum to discuss what everyone did. Get creative….hold virtual “coffee breaks” or “pot lucks”; celebrate personal events (such as birthdays, births, leaving, etc) as well as team accomplishments.
• Tracking Sprint Progress – Utilize your tools’ dashboard during daily scrums to show the teams burn-down. Don’t micro-manage tasks. Insist team members keep tasks up-to-date reducing ETC to keep burn-downs current.
• Product Owner – As a Product Owner (PO), engage fully with the team to ensure collaboration leads to comprehensive understanding of each story. Ask questions. Update stories in real-time during team grooming to clarify understanding. It is easy to leave PO acceptance of stories until it is too late for developers to make changes. Instead keep an eye on story progression, review stories as soon as they are ‘done’.
• ScrumMaster as team facilitator – As a Scrum Master (SM), your role is especially important with distributed teams. Pay attention to how members interact. Is everyone participating in ceremonies like grooming and planning? Ask questions to draw out quiet members. Also, just because you are the facilitator, doesn’t mean you have to “be in charge”. Don’t forget to turn items like tasking stories over to developers. Just sit back and listen while they do the work.  Consider a SM for each location (e.g., if you have part of the team together on the east coast and another part together on the west coast, use a SM in both places).

There’s no doubt about it…..it’s harder for remote teams to achieve the same collaborative environment that co-located teams can. But it’s not impossible….with a little elbow grease and TLC, your distributed team will shine!”

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 the first installment of this blog entry, we laid out a scenario which portrays an unhappy software development team. It has become obvious that developers are wasting time fixing and re-fixing bugs (and in many cases, becoming increasingly frustrated) and not contributing to the team’s true velocity. Testers are also becoming frustrated as they are seemingly wasting time retesting and tracking easily identifiable defects, therefore increasing risk by minimizing the time they have to test more complex code and scenarios.

At this point, if they haven’t already, the daily stand-up meetings and/or retrospectives, have most likely taken an on an ornery tone. It’s become obvious that time is being wasted and team members are unhappy.

One potential solution? The post-deployment demo.
I have seen in MANY cases that a significant amount of these issues can be identified up-front – before the retesting effort even begins – by simply scheduling an informal “post-deployment demo”. The format is similar to the aforementioned sprint demo, yet in this case, the “presenter” of this demo is the developer(s) who have worked on the fixes, and the “customer(s)” are the testers actually testing the fixes. The goal of the demo is simple and also similar to the sprint demo – the “customer” should leave the demo confident that the foundation of work which was completed to fix each defect is complete and satisfactory.

Basically, we can attempt to answer two important questions – first, “have we truly fixed what we said we’ve fixed? Second, “have we fixed what actually needed to be fixed and not clearly broken something else in the process?” The second question is obviously a lot more difficult to answer.

It’s important to keep the deployment demo as informal and efficient as possible, yet consistent. Ideally, if accepted by the team as a valuable practice, it should become a team norm, thereby making it repeatable. Usually, QA deployments are on a set schedule; in this case, the demos should adhere to that schedule. Demos should not be considered “painful” because over the course of a project, significant time and effort is saved when issues are uncovered and agreed on between testers and developers before the issues are even retested. Here are some helpful hints and ideas to get started:

• Keep things as simple and efficient as possible – no PowerPoint slides or agenda needed. All the demo requires is a meeting room, a laptop (or even better, a projector), a listing of defect fixes (along with high-level descriptions) and the essential team members.
• Include essential team members (ideally, those developers and testers associated with the functionality contained within the deployment) as often as possible. My teams have referred to this meeting in the past as a “DAT Session”. “DAT”, you may ask? Developer, Analyst, Tester. (Sometimes, it really is that simple.)
  • If applicable, why not include Business Analysts for clarification or feedback?
  • Even better, if you have an eager and co-located customer or client (i.e. Product Owner), why not solicit his or her feedback to save time? Non-complex scenarios or questions can be answered directly, saving even more time (and helping to avoid additional subsequent time-consuming meetings!)
  • Again, while the goal is to keep this as efficient a meeting as possible, at the same time, the possibilities really are endless. A forum for direct, face-to-face collaboration goes a long way and the team should take advantage of the opportunity.
  • Similar to another oft-practiced Agile concept – the “daily stand-up meeting” – try to “time box” the demo as much as possible, stick to topic and do not attempt to resolve issues. This is not a requirements meeting or a story-writing workshop. Yes, simple questions or clarification points can be agreed on and action taken. But if requirements are questioned or further clarification is needed, take it offline. The demo is not the forum for solving these issues.
  • Obviously, not every defect/fix needs to be demoed – usually, high-level demonstrations of simple functionality are adequate, and you’ll find they can uncover numerous issues before they are moved over to “ready to test”, which saves valuable time over the life of a project.

The Post-Deployment Demo – Team Acceptance
One final point – the first few iterations of a deployment demo can potentially have a risk of morphing into a “he said, she said” (or, more to point, “Testers” vs. “Developers”) conflict within the team. Employing this type of feedback session in practice poses a bit more risk to newly-formed teams who are unfamiliar with each other and still striving to progress through the “Forming and Storming” stage of “Tuckman’s Stages of Group Development”.

The reality is that in this forum, names are tied to tasks (in this case, names are tied to bugs) and people’s work is more times than not questioned (and sometimes indirectly criticized). Every effort should be made to avoid being overly critical when addressing issues when one person thinks something has been fixed while another person believes the functionality is still incorrect. Remember, it’s a team effort and everyone is in this together with a common goal of team and project success. I feel this simple yet valuable practice is a great tool to help get you there!

One of the basic Agile tenets that most people agree on – whether or not you’re an Agile enthusiast or supporter – is the value of early and continuous customer feedback. This early and often feedback is invaluable in helping software development projects quickly adapt to unexpected changes in customer demands and priorities, while concurrently minimizing risk and reducing ‘waste’ over the lifetime of a project.

Sprint Demo
In the Agile world, we traditionally view this customer feedback in the form of a formal product demonstration (i.e. sprint demo) which would occur during the closeout of a Sprint/Iteration. In short, the “team” – those building the software – presents features and functionality they’ve built in the current sprint to the “customer” – those who will be users or sellers of the product. Even though issues may be uncovered and discussed – usually resulting in action items for the following sprint – the ideal end result is both the team and the customer leaving the demo session (and in theory, closing the sprint) with a significant level of confidence in the current state and progress of the project. Sprint demos are subsequently repeated as an established norm over the project’s duration.

This simple, yet valuable Agile concept of working product demos can be expanded and applied effectively to other areas of software development projects:

• Why not take advantage of the proven benefits of product demos and actually apply them internally – within the actual development team – before the customer is even involved?
• Let’s also incorporate product demos more often – why wait two weeks (or sometimes even a month, depending on sprint duration)? We can add value to a software development project daily, if needed, without even involving the customer.

Expand the Benefit of Demos
One of the common practices where I have seen first-hand the effectiveness of product demos involves daily deployment of code into a testing or “QA” environment. Here’s the scenario:

• Testing uncovers five (5) “non-complex” defects (i.e. defects which were easily identified in testing – usually GUI-type defects including typos, navigation or flow issues, table alignments, etc.) which are submitted into a bug-tracking tool. Depending on the bug-tracking tool employed by the team, this process is sometimes quite tedious.
• Defects 1-5 are addressed by the development team and declared fixed (or “ready to test”) and these fixes are included in the latest deployment into a QA environment for retesting.
• Defects 1-5 are retested. Defects #1 and #2 are confirmed fixed and closed.
• But there is a problem – it’s discovered EARLY in retesting that Defects #3 and #4 are not actually fixed and additionally, the “fixes” have now resulted in two additional defects – #6 and #7. For purposes of explanation, these two additional defects were also easily identified early in the retesting process.
• At this point, Defects 3-4 need to be resubmitted, with new Defects – #6 and #7 – also added to the tracking tool.

Where are we at this point? In summary, all of this time and effort has essentially resulted in closing out one net defect, and we’ve essentially lost a day’s worth of work. Not to mention, developers are wasting time fixing and re-fixing bugs (and in many cases, becoming increasingly frustrated) and not contributing to the team’s true velocity. Simultaneously, testers are wasting time retesting and tracking easily identifiable defects, therefore increasing risk by minimizing the time they have to test more complex code and scenarios.

So there is our conundrum. In a nutshell, we’re wasting time and team members are unhappy. Check back for a follow-up post next week, which will provide a simple yet effective solution to this unfortunately all-too-common issue in many of today’s software development practices.

In a previous blog, “The Reality of T.E.A.M”, I talked about Agile teams being dedicated, or part of a ‘permanent’ team that focuses on a single solution and remains together over time.  Another big factor of an Agile team is that they are cross-functional in nature.

What is a Cross Functional Team?    
When the topic of cross-functional teams comes up, there seems to be varying opinions that come out.  What does it mean when I refer to teams being cross-functional?  Does everyone on the team have to be able to do every job?  Do all team members have to know every detail of everything that goes on inside the team?  Does the team have to ensure that they can complete their solution?  Let’s look at what cross-functional means for Agile teams that I work with.

If you want to define it, you will most likely find that it means something like “a group of people with different functional specialties or multidisciplinary skills, responsible for carrying out all phases of a program or project from start to finish.”[1]  If you stick with this definition, you may find that you do not have to have a team where everyone on the team knows how to do every job on a team, but more that it is meant to keep members focused more on their role in moving the product forward than on their title.

Now that you’re on a Cross Functional Team
When the members of a team hear they are to be cross-functional, I’ve seen them get a little uneasy thinking they have to become something they may not want to be or learn to do things they don’t want to do.  I call this their ‘mini identity crisis’ because these team members are so centered around their title defining what they are supposed to do, they lose sight of what it means to be a team.

Team members will hopefully come to understand that becoming part of a cross-functional team means they will be focusing more on their role as a team member than on what their title is on their HR file.  Being a cross-functional team member is about ensuring you chip in whenever necessary and do as much as you can to ensure the solution is complete, and as good and valuable as it can be.

It’s not necessarily important that all team members know how to do everything, but it is important they work together, embracing common Agile principles from the Agile Manifesto and Principles, as well as principles that are found in Agile methods, such as “’Collective Code Ownership’ in Extreme Programming, which ensures the entire team owns the code and ‘Self-Organization’ in Scrum, where the team organizes themselves to get the job done.

Where does an Agile Coach fit in?
When coaching cross functional teams, I try to support and help them understand they won’t be losing their identity, but they are going to become part of a larger solution.  I emphasize that they’re not ‘against each other’, or ‘apart from each other’, but ‘for each other’.  I’ve found it’s important for team members to communicate and collaborate so they feel like part of a team instead of a pool of resources thrown together and asked to feel and behave like a team.

For all you sports fans—A Sports Analogy
Cross-functional teams remind me of football teams.  In football, there are multiple positions, both on the offense and on the defense.  While each member of a football team is most likely drafted onto the team to play a specific position, such as protecting the quarterback, the skills they possess for that position may also translate to other positions on the team.  For example, the player that protects the quarterback can use those same skills to get around the protection of the other team’s quarterback and sack him.  Just like a football team has players who are able to move to different positions in order to win the game, Agile teams use the same idea to produce the best possible solution!

Agencies around the government are beginning to see more and more of their employees teleworking and going to modified work weeks.  There are a number of employees that work enough so that they can modify their schedules to be off every other Friday or Monday, or even every Friday or Monday.  Due to a number of factors, many employees are also teleworking, or working from home.  Sound like you or someone you know?

What does this have to do with Agile?

I hear very often that one of the most talked about, and even controversial, things about an Agile transformation is the idea that teams must all be in the same room in order to satisfy the 6^th principle of the Agile Manifesto “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

If we take this principle into account, then we find that the telework and modified schedules turn this upside down and cause some confusion and concern on whether or not an agency can actually transition.  I have had a number of federal employees, especially leadership; ask if they can really transition to an Agile culture.  The actuality is “yes” – an agency in this situation, can most certainly transition to an Agile environment!

The biggest question for any agency is not “can we?”, but “how do we?”.  The agency needs to start with the understanding that the 6^th principle says that face-to-face is “the most efficient and effective…” way to communicate; it does NOT say that it is the only way to communicate.  It is so very important to encourage face-to-face communication for those that are in the office on a daily basis, but not so important that they relinquish the teleworking or modified schedules.

The key is to have the agency give the teams as much encouragement and support as they can to help create an atmosphere that fosters communication and collaboration in many different ways.  The agency will need to enable team members to communicate through means that may not have been ‘the usual’ in the agency.  Many government agencies have never had to put a lot of effort into ‘unusual’ modes of communication and collaboration because either the employees have been in the office all the time and/or the employees have worked fairly independently.  The more independently employees work, the less they need ways to communicate and collaborate outside of the ‘usual’ means of phone and email.

Agencies that need to step out of the ‘normal modes’ of communication are most likely very skittish of doing so for a multitude of reasons.  Some reasons I have been told that agencies may be skeptical is the level of security that needs to be maintained in the agency; most agencies will admit their security levels are much higher than those of private industry.  Because of the level of security that needs to be supported, many obvious communication mechanisms are overlooked or pushed aside without fully investigating the overall options.

However, in today’s technological age, there are many options that are available.  Any agency that is looking to transition to a more collaborative environment, one in which Agile can flourish, needs to look beyond names and find what works.  They should start by understanding the needs of the teams and work with the teams to find solutions, such as Office365, webcams, bridgelines, etc.

The one thing that agencies should never assume is that they cannot transition to an Agile environment simply due to these modified schedules or teleworking situations.  It all comes down to support and encouragement of teams made of people that are not all sitting in the same location…something that many agencies have not had to deal with before now!

Have you been in this situation?  Do you know some that are?  What do you, or they, think can be done to be more collaborative?