An Agile Coach’s Guide to Managing Pride, Ego and Personal Growth
An Agile Coach’s Guide to Managing Pride, Ego and Personal Growth
As a ScrumMaster and Agile Coach, one of my favorite tools to use is Mural. Mural is a digital whiteboard designed for engaging collaborations. It’s a creative outlet for me; it’s like scrapbooking for a job. I like to think that I’m pretty good at using the application. If I’m being honest, I think I’m really good at using Mural. I usually get compliments on my creativity, layouts, and functionality of my Mural boards. I pride myself on being knowledgeable and helpful in Mural, which is a part of my Personal Brand.
Recently I was in a Thursday ScrumMaster Community of Practice (CoP) where we were discussing Mural and I shared some of my examples. An Agile Coach said, “Tracy – if you want to help me dress this one up, I’d be happy to see what you can do!”. I felt honored and excited, especially since I had only been consulting at the company for less than 2 months. I had the drive and desire to do my best work and build a positive reputation for myself as an informed, helpful, and creative resource.
That night I reworked his Mural. I created a Lego Theme that focused on Building Foundations Together. I created colored Lego Brick Backgrounds for different topics. I was really excited about what I had made. I shared right away in the morning, expecting to get positive feedback. The instant gratification! However, the Agile Coach was out of the office that Friday.
On Monday, I received his response. “You were using Areas and Shapes inconsistently.”. “Wait, what?!?!”. It wasn’t the reaction I was expecting, and a meeting was scheduled. I didn’t even know what he was talking about with “Areas”. My ego definitely took a hit.
I prepared myself for a meeting with the Agile Coach. I felt like I was a student in detention. I felt like I was in trouble. I expected him to be upset with me because, after all, I ruined the functionality of his Mural.
Instead of a meeting, it was a working session. I learned about functionality I never knew existed. He showed me where, when, and how to use Mural Areas. He was not upset at all in the working session; he knew I had the best intentions.
We learned that even though we’re both passionate and knowledgeable about Agile, it was also easy to see how quickly we fell back on old patterns. We needed to align first with what we were trying to accomplish. We also brainstormed from different personas which created a variety of solutions. Those perspectives made the Mural and instructions more valuable and understandable.
I was humbled by this experience.
I can be, and still am, proud of the work I did.
If I wouldn’t have changed my defensiveness to a Growth Mindset, I wouldn’t have gotten the gift of learning something new.
If I would have gone into the meeting with negativity, I wouldn’t have seen the Coaching Demo that happened right in front of my eyes.
In my reflection, I realized I needed to put my ego aside to grow.
I did that by:
Change to a Growth Mindset. Embrace challenges and learn from feedback.
Think of every opportunity as a coachable moment.Imagine what your day would look like if you went into every situation thinking, “What am I going to learn here?”. How would the atmosphere and culture change?
Give grace. Give grace that everyone was trying to do the best they could at the time – Including yourself.
Have Gratitude.Gratitude greatly reduces negativity and anxiety. It shifts a focus from thinking of yourself to others. When we have gratitude, what we appreciate grows.
Pay it forward.Paying it forward is the greatest compliment you can give your mentor. Don’t just share the information that you received but pass on the learning environment. Create a space of psychological safety, patience, and understanding.
In conclusion, I still pride myself on being knowledgeable and helpful in Mural. I’m practicing a Growth Mindset and trying to embrace every situation as a coachable moment. Be grateful for being mentored, and in return, become a mentor. But what I really learned in the experience and reflection was:
You can have pride in your career, but to continue your growth journey you need to practice removing the ego.
Another great part of this story is that the mentor/mentee relationship didn’t end at that working session. We continue to collaborate, asking for opinions, and sharing knowledge. We continue to learn together. Now that’s what I call Building Foundations Together.
Pt 1 of a two-part series
Effective communication remains at the very heart of team efficiency. Entire business models are based on improving team communications, look no further than SalesForce’s acquisition of Slack. Microsoft Teams, BaseCamp, Sharepoint, Zoom, Webex, instant messenger, and text are just a few of the frequently used communication tools in the workplace. Meeting facilitation is now a ‘service offering’ – take a moment and search LinkedIn… perhaps you’ll get more than the 7,700 results that I returned!
Yet here we are in this post-COVID, hybrid/remote work environment, and one of the most effective and proven communication channels has been cast aside. COVID brought most technology work into the home somewhat permanently, and the overscheduling of meetings proliferated, where thanks were provided to higher powers when a meeting was gracefully ended 50 mins after the hour, allowing a few minutes to check on the kids, feed the whining dog, or run to the bathroom—really anything other than staring at an array of faces staring back at their screens. What this also brought was the feeling that since schedules were so solidly stacked, the last thing that made sense was to just call someone. It felt intrusive and presumptuous.
While COVID remains in circulation, the work world is transitioning with some firms fully remote forever, others hybrid with overlap day mandates, and others fully back to pre-pandemic norms. At CC Pace, we remain convinced that flexibility is critical to our employee’s success, but we are also strong believers that face-to-face time is time well spent. I’m reminded of my first job in technology working for one of the Big 4 firms; at my first project, if I hadn’t had the opportunity to strategically place myself at a senior developer’s desk as his day started to ask a few questions and get a few answers, I’d have been sunk. The informal communication channel is critical—and I couldn’t imagine posting my question to him on Teams (even if it had existed back then), nor would he have answered! So how can that experience be replicated within the modern hybrid/remote work environment?
Virtual stand-ups remain useful. Pair programming has its place. Yet we see questions left overnight, where there is a desire not to bother a fellow developer. One of the most basic behaviors that our Agile coaches are pressing on is to push developers to ‘pick up the phone and call’. This deference has a huge cost on team productivity as “stuck developer time” ticks away to no effect.
This is Sachin, picking up with the perspective of a Sr. Scrum Master and Agile coach, I have seen a shift in mindset with team members content with completing their part in a user story. It’s more of a “throw it over the wall” kind of mindset. I usually relate it to a very popular British party game we used to play as kids, i.e., “Pass the parcel.” The parcel, which is the user story, is passed on from one person to another until the music stops, which is when the sprint ends. The result is an incomplete story that just moves on from one sprint to another. The concerning part is team members are not willing to take responsibility for a user story. A simple question, such as “can you finish the user story in a sprint?” goes unanswered. Take, for example, a backlog refinement session: this session is productive when team members communicate and ask questions. But when you consider them as a waste of time and just want to get done with them, assumptions are made without proper analysis, leading to improper sizing and stories remaining “not done”. To some extent, teams and programs have started to blame the very process for missing a deadline.
Effective interactions remain paramount for Agile teams. The efficiency of text, email, and other one-way transmissions is not always effective.
In Part II of this series, Mike Wittrup will talk about a framework that CC Pace uses to assess and improve team communication protocols in the co-working world that we all live in.
In the meantime, we remain at your service in providing tailored approaches to driving business agility. For over 20 years we’ve earned clients’ trust across all stages of the Agile journey. Give us a call!
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:
Teams do not get enough support from management when delivery challenges manifest
Management puts a greater emphasis on following the practices and mechanics than the mindset
There is a lack of psychological safety in the organization
Management overvalues Agile metrics and dashboards, leading to an increase in Agile antipatterns
Agile coaches struggle to maintain a coach and influence teams
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:
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.
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.
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.
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.
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.
Does your Agile Transformation feel like it is stuck in mud? Maybe it is facing one of the many challenges organizations must navigate as part of their transformation.
The impact of each of these can be detrimental to any Agile Transformation. The report suggests that some organizations face many of these challenges at once. The survey notes that these results have been unchanged over several years. As we look across these top 10, we find most of them relate to the organization’s cultural aspects which means that trying to improve a team’s specific use of an Agile method like Scrum, is less important than trying to improve the overall Agile Culture of the organization.
For a different view into why Agile transformations are challenged, we find the article, How to mess up your agile transformation in seven easy (mis)steps(Handscomb et al., 2018) by a McKinsey team as yet another way to look at the challenges organizations face. The seven missteps are:
Not having alignment on the aspiration and value of an agile transformation
Not treating agile as a strategic priority that goes beyond pilots
Not putting culture first over everything else
Not investing in the talents of your people
Not thinking through the pace and strategy for scaling up beyond pilots
Not having a stable backbone to support agile
Not infusing experimentation and iteration into the DNA of the organization
If your organization is facing any of these challenges, or you’ve made any of the “missteps” identified by the McKinsey team, your Agile adoption may be at a stall. If you’re experiencing multiple challenges, it may be time to get some help.
When things aren’t going well with your transformation the impacts are felt at the team and organization levels. Next, we’ll look at some of these impacts.
Team Impacts
Team members feel frustrated and demotivated about working in an Agile environment when they aren’t supported through the transition by managers, each other, and the culture of the organization.
Team members are unable to deliver quality increments of work due to a lack of consistent processes and tools.
Team deliveries are hindered by defects.
Team members struggle to learn and implement new Agile methods, or what they learn does not stick.
Team members don’t go beyond process and learn delivery practices to improve quality, like TDD, or DevOps.
Team members don’t work cross-functionally and instead keep silos of expertise.
Team members struggle to coordinate across teams to remove dependencies.
Team members burn out due to working at an unsustainable pace.
Team member turnover is high.
Stakeholders don’t see the value in their participation with the Team members doing the work, hindering the team’s ability to get real-time feedback and continuously improve.
Management fails to let the team self-organize taking away from team ownership and accountability for the work. Or even worse, they micro-manage the team, their backlog, or even how they do the work
Teams find it difficult to release rapidly hampering innovation and increasing time to market.
Team members aren’t engaged in learning new ways of working.
In addition to the team impacts, there are several organizational impacts that can occur.
Resolving the challenges
In looking at the data, it is imperative that organizations address these challenges head-on. If you’re seeing any of the impacts listed above, you may wonder what to do to alleviate them. One of the biggest mistakes is not incorporating change management as part of an Agile Transformation. Leadership needs to help everyone in the organization understand the new culture underlying how they all work together. It requires leaders and doers alike to learn about Agile values and behaviors. Organizations must invest in training and education at all levels so that learning becomes part of the culture. How do we expect people to become Agile if we don’t teach them what Agile really is?
“What Are the Greatest Contributors to Success When Integrating Change Management and Agile?” According to Tim Creasey (Creasey, n.d.), they are:
Early engagement of a change manager
Consistent communication
Senior leader engagement
Early wins
Regardless of the Agile Methods you are trying to implement, an organization must start with changing its organizational culture, and the best way to do this is to start with change management. All the efforts of teaching and coaching will fail without the culture change to support the new Agile ways of working. Finally, engage the entire organization, not just IT, in the adoption of Agile practices and behaviors. While a pilot team will help test out a specific Agile method, their work with other members of the organization requires everyone to understand what it means to be Agile.Agile is for everyone, not just IT. A comprehensive change management program will help ensure the entire organization becomes focused on becoming Agile.
Watch for future blogs where we delve into these challenges and what CC Pace can do to help you solve them.
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!
In today’s digital business landscape, businesses are looking for solutions to be more competitive. Some digital businesses have found the Scrum Framework to be that competitive edge with its foundation of empiricism. Empiricism uses knowledge based on experience to make decisions. Scrum framework empiricisms reflect in three pillars of transparency, inspection, and adaption. Scrum’s Evidence-Based Management (EBM) is an empirical approach that supports organizations in demonstrating business outcomes, organizational capabilities, and business results. In the simplest terms, the EBM helps organizations navigate through complex problems by intentional small steps and adapting through continuous feedback loops. (For more on complexity, see the Scrum Theory section of the Scrum Guide at https://www.scrumguides.org/scrum-guide.html)
Scrum’s Evidence-Based Measurement approach allows organizations to avoid traps like metrics turning into milestone deliveries or project task activities. EBM offers an opportunity for the digital organization to experiment and move to their next step to value through these areas:
Key Value Areas – Unrealized value, Current Value, Time to Market, and Ability-to-Innovate.
Scrum.org, 2020
Let’s look at them and see if your organization might benefit from using them.
First Value Area – Current Value
What is the purpose?
The organization reflects on the current value they bring to the customers or stakeholders. It is in its current state. It is not a future state at all.
How does an organization identify it?
EBM shares this value indicating the happiness of customers, stakeholders, and employees.
It can be very simple: measure how happy the customers, stakeholders, and employees are. Is their happiness up or down? The important aspect here is to get a baseline and then, at regular intervals check-in that the current state is moving towards the desired state.
Potential examples:
Second Value Area – Unrealized Value:
What is the purpose?
The organization reflects on what future value they could provide to their customers, stakeholders, or employees. Based on the current value, what is the difference? That difference is the potential unrealized value.
How does an organization identify it?
EBM shares this value is about understanding ALL the desired needs or future state that our customers, stakeholders, and employees would like to have to be very, very happy. It allows the organization to evaluate where finances are being expended.
Potential examples:
Third Value Area – Time to Market:
What is the purpose?
The organization determines how quickly it can deliver something new to its customers or stakeholders.
How does an organization identify it?
EBM shares this value is about understanding how the organization does things, how the organization learns, and how quickly the organization applies what they learned.
Potential examples:
Fourth Value Area – Ability to Innovate:
What is the purpose?
The organization determines how good they are at developing new ideas that might deliver value to meet customer needs.
How does an organization identify it?
EBM shares the ability to innovate the organization by looking for blockers and dependencies and addressing them. What are the “gotchas” that prevent customers from being happy about the delivered solution?
Potential examples:
Gathering the information for EBM’s 4 values provides the organization with a baseline and is a great first step. However, the biggest secret to success the Scrum’s Evidence-Based Measurement guidance offers is to be intentional with small steps of change to move the needle in each of the four value areas. EBM supports using the PDCA model derived by W. Edwards Deming to accomplish this.
https://deming.org/explore/pdsa/, n.d.
Deming’s approach is built on:
Plan: What is the organization trying to do? (What is the problem they are trying to solve?)
Do: What are the intentional, time-boxed steps the organization will use to solve it?
Check: What are the outcomes?
Act: If the outcomes are great, then continue with that process. If the outcomes are not as expected, what changes does the organization make?
Scrum’s EBM guidance has been applied in various industries.
In one great case study, a Real-Estate Software Provider shared that after one year of using the EBM, the company had its’ largest revenue growth in over 10 years. Its success was also reflected in its EBITDA and Net Promoter score.
Scrum.org, 2018
This case study is only one example. Has your organization used this approach? If so, what were your results?
Appendix:
The sample below shares an approach that might be synthesized from the Scrum Evidence-Based Measurement.
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 15th 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.
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.
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.
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.
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%.
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.
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.
Insufficient preparation
Inviting only a subset (team leads)
Lack of focus on dependencies
Risks not addressed effectively
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
Provide Continuous Feedback
Deliver Value to the Customer
Enable Face-to-Face Communication
Have Courage
Keep it Simple
Practice Continuous Improvement
Respond to Change
Self-Organize
Focus on People
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.
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.
When I was first introduced to Agile development, it felt like a natural flow for developers and business stakeholders to collaborate and deliver functionality in short iterations. It was rewarding (and sometimes disappointing) to demo features every two weeks and get direct feedback from users. Continuous Integration tools matured to make the delivery process more automated and consistent. However, the operations team was left out of this process. Environment provisioning, maintenance, exception handling, performance monitoring, security – all these aspects were typically deprioritized in favor of keeping the feature release cadence. The DevOps/DevSecOps movement emerged as a cultural and technical answer to this dilemma, advocating for a much closer relationship between development and operations teams.
Today, companies are rapidly expanding their cloud infrastructure footprint. What I’ve heard from discussions with customers is that the business value driven by the cloud is simply too great to ignore. However, much like the relationship between development and ops teams during the early Agile days, a gap is forming between Finance and DevOps teams. Traditional infrastructure budgeting and planning doesn’t work when you’re moving from a CapEx to OpEx cost structure. Engineering teams can provision virtually unlimited cloud resources to build solutions, but cost accountability is largely ignored. Call it the pandemic cloud spend hangover.
Our customers see the flexibility of the cloud as an innovation driver rather than simply an expense. But they still need to understand the true value of their cloud spend – which products or systems are operating efficiently? Which ones are wasting resources?
I decided to look into FinOps practices to discover techniques for optimizing cloud spend. I researched the FinOps Foundation and read the book, Cloud FinOps. Much like the DevOps movement, FinOps seeks to bring cross-functional teams together before cloud spend gets out of hand. It encompasses both cultural and technical approaches.
Here are some questions that I had before and the answers that I discovered from my research:
Where do companies start with FinOps without getting overwhelmed by yet another oversight process?
Start by understanding where your costs are allocated. Understand how the cloud provider’s billing details are laid out and seek to apply the correct costs to a business unit or project team. Resource tagging is an essential first step to allocating costs. The FinOps team should work together to come up with standard tagging guidelines.
Don’t assume the primary goal is cost savings. Instead, approach FinOps as a way to optimize cloud usage to meet your business objectives. Encourage reps from engineering and finance to work together to define objectives and key results (OKRs). These objectives may be different for each team/project and should be considered when making cloud optimization recommendations. For example, if one team’s objective is time-to-market, then costs may spike as they strive to beat the competition.
What are some common tagging/allocation strategies?
Cloud vendors provide granular cost data down to the millisecond of usage. For example, AWS Lambda recently went from rounding to the nearest 100ms of duration to the nearest millisecond. However, it’s difficult to determine what teams/projects/initiatives are using which resources and for how long. For this reason, tagging and cost allocation are essential to FinOps.
According to the book, there are generally two approaches for cost allocation:
Tagging – these are resource-level labels that provide the most granularity.
Hierarchy-based – these are at the cloud account or subscription-level. For example, using separate AWS accounts for prod/dev/test environments or different business units.
Their recommendation is to start with hierarchy-based allocations to ensure the highest level of coverage. Tagging is often overlooked or forgotten by engineering teams, leading to unallocated resources. This doesn’t suggest skipping tags, but make sure you have a consistent strategy for tagging resources to set team expectations.
How do you adopt a FinOps approach without disrupting the development team and slowing down their progress?
The nature of usage-based cloud resources puts spending responsibility on the engineering team since inefficient use can affect the bottom line. This is yet another responsibility that “shifts left”, or earlier in the development process. In addition to shifting left on security/testing/deployment/etc., engineering is now expected to monitor their cloud usage. How can FinOps alleviate some of this pressure so developers can focus on innovation?
Again, collaboration is key. Demands to reduce cloud spend cannot be a one-way conversation. A key theme in the book is to centralize rate reduction and decentralize usage reduction (cost avoidance).
Engineering teams understand their resource needs so they’re responsible for finding and reducing wasted/unused resources (i.e., decentralized).
Rate reduction techniques like using reserved instances and committed use discounts are best handled by a centralized FinOps team. This team takes a comprehensive view of cloud spend across the organization and can identify common resources where reservations make sense.
Usage reduction opportunities, such as right sizing or shutting down unused resources, should be identified by the FinOps team and provided to the engineering teams. These suggestions become technical debt and are prioritized along with other work in the backlog. Quantifying the potential savings of a suggestion allows the team to determine if it’s worth spending the engineering hours on the change.
How do you account for cloud resources that are shared among many different teams?
Allocating cloud spend to specific teams or projects based on tagging ensures that costs are distributed fairly and accurately. But what about shared costs like support charges? The book provides three examples for splitting these costs:
Proportional – Distribute proportionally based on each team’s actual cloud spend. The more you spend, the higher the allocation of support and other shared costs. This is the recommended approach for most organizations.
Evenly – split evenly among teams.
Fixed – Pre-determined fixed percentage for each team.
Overall, I thought the authors did a great job of introducing Cloud FinOps without overwhelming the reader with another rigid set of practices. They encourage the Crawl/Walk/Run approach to get teams started on understanding their cloud spend and where they can make incremental improvements. I had some initial concerns about FinOps bogging down the productivity and innovation coming from engineering teams. But the advice from practitioners is to provide data to inform engineering about upward trends and cost anomalies. Teams can then make decisions on where to reduce usage or apply for discounts.
The cloud providers are constantly changing, introducing new services and cost models. FinOps practices must also evolve. I recommend checking out the Cloud FinOps book and the related FinOps Foundation website for up-to-date practices.
Have you heard of OKRs? Is your organization considering adopting OKRs? If so, this post is for you.
OKR stands for Objectives and Key Results. Andy Grove created them while at Intel, and they’ve been growing in their use ever since. The Objective equals the “what” we will achieve, and the Key Result is the benchmark we use to measure how we are doing.
OKRs have been working for organizations like Google and Intel for years. Implementing them for your organization can help drive focus and alignment around working on the right things. While anyone can read the book Measure What Matters, by John Doerr to learn how to write OKRs, it is by following a tried-and-true implementation plan that OKRs truly help organizations achieve the desired focus.
According to Scaled OKRs, Inc. the following key steps should be included:
Build the team
Communicate
Train
Execute the OKR cycle
Calibrate Regularly
Continue to the next OKR cycle
Step 1: Build the team
Build a team to lead the implementation of OKRs. Identify a sponsor and champion. These leaders should understand how keeping OKRs visible throughout the organization will lead to success. As with any change, practicing good change management is important. Introducing OKRs is no exception. Be sure to include a change manager in your team. In addition, your team should include someone familiar with how to write OKRs to guide and mentor those new to writing them.
Step 2: Communicate
Once you have identified the team that will lead and support implementing OKRs, the next step is all about change management communications. Your first communication should occur about two months before roll-out. In your communication, be sure and answer the questions, Why OKRs? And why now? Aside from creating a sense of urgency to adopt, create a vision for the change and share it out too. Have the communication come from Leadership to show the importance of implementing OKRs. Our change manager follows the Prosci ADKAR Model. The next message should come about one month prior to the roll-out and should be the formal kick-off announcement of the OKR process. Followed shortly by sharing the company level OKRs, and training workshops schedule.
Step 3: Train
Next, you’ll need to do some training. While OKRs may seem easy to write, putting pen to paper and coming up with the right OKRs can be a daunting task. A training workshop with a writing exercise will help attendees get orientated around what makes good OKRs. Here they will learn that the objective is qualitative, and the Key Results are quantitative. You may need a train-the-trainer session to enable others to assist teams in writing their OKRs. I like to share John Doerr’s “Super Powers” of OKRS as a reminder. These include:
Focus & commit to priorities
Align & connect teamwork
Track for accountability
Stretch for amazing
Step 4: Execute the OKR Cycle
With company OKRs in hand and training underway, the next step is to start the OKR Cycle.
In this cycle, teams write and share their OKRs to ensure vertical and horizontal alignment.
The Enterprise Context grounds teams to the highest level OKRs that were developed by leadership. This gives everyone something to tie their OKRs to and sets the direction for the organization. This allows teams to work on co-creating the localized OKRs.
The OKR Cycle looks like this:
The next step is for individual teams to write their localized OKRs. When it comes to writing OKRs, one of my favorite tips for writing OKRs is that you should be able to read them in the following format:
We will achieve (objective), as measured by (Key result).
Before everyone starts writing OKRS, you may want to think about how they will be kept. If you haven’t picked a tool to manage your OKRs, writing them in a shareable manner can become difficult. It’s easy enough to share across one or two verticals and even one or two horizontals. However, the more widely your OKR implementation, the more imperative a tool becomes.
Once the teams have created their OKRs, it’s time for them to develop their “Action plan,” or backlog of epics they will use to accomplish their OKRs. As part of an action plan, identify key result owners, and the frequency of review huddles. You’ll want a regular cadence of review. This step can be done at Scrum events, like the Sprint Review. The worst thing that can happen is to write OKRs and then forget about them. Finally, identify what scoring mechanism will be used.
Around the second month of the OKR cycle, check-ins and scoring occur. Many organizations follow Google’s lead when it comes to scoring. In their system, 0 is a failure, and 1 is a success. Here is a view of what the scores look like:
You can see from this scale that a .7 is green. It is considered a success. This is especially true for OKRs that are ambitious and represent a real stretch for the team. A team that consistently gets a 1.0 could be considered as not creating ambitious enough OKRs.
In the timeline above, we allocated four weeks to work on the first set of OKRs and two weeks for subsequent quarters. The first draft of OKRs tends to take the longest. Be sure and allocate plenty of time for creating your first set of OKRs.
One last comment about this cycle, tracking and sharing progress is an ongoing effort. All-hands meetings are great places to talk about progress. This will keep them from being just another goal-setting activity and keeps them at the forefront of everyone’s work plans.
Step 5: Calibration
Calibration reviews should happen quarterly. This is where you gather the data and identify if anything has changed before we move on to creating our next quarter’s OKRs. Calibration is a great time to do a retrospective on the OKRs. It is also a good time to ask questions like has the company level OKR’s changed? Before you start a new quarter of OKRs, calibrate where you ended on the current quarter and what, if anything, do you need to update or change before writing new OKRs for the upcoming quarter.
Step 6: Continue to the next OKR cycle
Repeat Steps 4 and 5 as part of your ongoing OKR program.
As you can see, rolling out a successful OKR program takes a bit of effort, but it is well worth it. When you incorporate your OKR roll-out into a program that is well planned, you are sure to get the entire organization on board. Once in place, you can use your OKRs to measure the outcomes the organization is striving to achieve, and everyone will be aligned. You can use your OKRs to determine the right things to be working on and say no to things that don’t align with your OKRs. With a good tool, everyone can see how their work aligns with the big picture. Regular check-ins give you the opportunity to see ongoing progress or make course corrections. Most importantly, your organization will be on the path to measuring progress towards desirable outcomes. If you have questions or want to know more, just reach out to me: jbrace@ccpace.com
As a Senior Scrum Master, I’ve worked with many organizations, and I’m frequently asked by leaders one common question: how long will it take for my team to be Agile? The answer is never easy; developing an Agile mindset can be complex. From senior executives to developers, everyone in the organization must be open-minded and willing to change. Of course, there will always be resistance, but this can be handled through open dialogue and continual conversation.
I’d like to walk through a staged representation depending upon the maturity levels that each team goes through in becoming Agile. The information you can gather from the maturitylevels is an important metric that organizations are intrigued and excited to see because they show progress in their Agile journey. I have used the maturity levels extensively with teams, and it’s always great to show progress; but remember, it’s just a tool.
So, with that being said, let’s get started. I will review each maturity level a team goes through, and along the way, I’ll share my perspective and lessons learned.
Level 1 is a Learning Phase. As teams get started on their Agile journey, it’s essential to introduce and establish an Agile mindset. From my experience, an Agile Boot Camp is a great way to create this awareness and introduce some initial concepts. It’s also an opportunity to see the team composition, make introductions, and begin a new way of working together. While Level 1 focuses on awareness, you can’t short-change the importance of this initial step; it sets the foundation for the beginning of the journey and the team’s future success.
To reach Level 2, teams must have a solid understanding of what it means to be Agile, and they must also recognize there is a difference between Agile and Scrum/Kanban. Frequently, I hear teams using words like Agile and Scrum interchangeably; and it’s important everyone understands that Agile is a methodology, whereas Scrum and Kanban are different frameworks of Agile. The Agile ceremonies or events should be scheduled with a set agenda and teams should practice story card-based requirement gathering.
Once the team has a firm grip on what it means to be Agile, they’re practicing the events, using terms correctly, and understanding the different frameworks; it’s time to move to Level 3, where the focus is on proper planning, practicing trade-offs, backlog management, and inspect/adapt principles. Better planning is your key to executing a sprint well. Having a solid backlog and adopting inspect/adapt principles will play a crucial part in a team’s success. The team should be encouraged and start to practice trade-offs.
As a Scrum Master and coach, I continually talk with my teams about embracing change. As they transition from Waterfall to Agile, the team should practice the “yes, I can, but…” phrase. For example, the Product Owner issues a new requirement, but the team already has a full plate of work. At this point, the team should be willing to practice a trade-off, accepting the requirement but be open to a conversation with the Product Owner to reprioritize existing items. Through this process, we ensure change is embraced and simultaneously practice trade-offs to not burn out the team.
As we move up the ladder, Level 4 is about the team starting to self-organize. In the planning session, there is a discussion about the sprint goals and stories, and the team should be able to self-organize and pick up the tasks that will help them achieve the sprint goal. Remember – it’s team commitment, not individual commitments, that matter. The team should be able to start measuring the process and looking at ways to improve, such as introducing some automation in the form of testing.
Level 5 focuses on improving T-Shaped skills, which can be attained by having a buddy-pair system within the team. Through this process, knowledge is gained and shared across teammates, thereby ensuring the team becomes cross-functional as time progresses. Teams will now be experienced looking at extreme automation techniques like RPA and AI, developing CI/CD pipelines, and eventually working in a DevOps model.
In conclusion, an Agile Transformation begins with a people mindset. While we looked at the Agile Transformation Maturity levels, it’s important to understand the effort put in by all players within an organization. From developers to Product Owners to Agile sponsors, everyone plays a role in achieving a successful Agile Transformation. As your organization moves through the different levels, remember, it’s going to be a bumpy ride. There will be forward momentum as well as setbacks; hence, it takes time. But as a Scrum Master who has worked with teams on their transformation journey, moving through the different maturity levels is a process, but the result is worth it.
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.
Metrics are vital to a team. They give us a starting point, just like choosing “my location” on your GPS. Then metrics tell us where we are headed. They help us know whether our team is winning at continuous improvement. They tell us how our journey is going, and where we might be off course.
The stability of metrics demonstrates that teams are predictable and can forecast future work. Many times, it is a combination of metrics that give us the real picture though.
One measure that can demonstrate a team’s stability is velocity. A team made up of dedicated members should have a stable velocity over time, which helps them better determine how much work to commit for a given sprint. So, measuring velocity over a number of sprints is a great Scrum metric. You might think that a rising velocity is good. However, a rising velocity along with rising escaped metrics tells us we haven’t reliably sped up at all. In fact, if escaped defects are rising, we need to fix something else in our process. We may need to slow back down. In contrast, a rising velocity and a decreasing or stable number of escaped defects would be a good team goal.
Another metric for a Scrum team is Committed vs Delivered %. Rather than just focusing on velocity, add a measure of Committed vs Delivered for velocity to see how your team is doing at being predictable. Teams that frequently have a low percentage of Committed to Delivered are committing to too much work in the sprint. If this is happening to your team, it is time to figure out why. Sometimes, we will know exactly what has impacted our metrics, while other times we may need to have a retrospective to discuss why. Escaped defects are important to consider, as a high percent Committed to Delivered is good, lots of rework is not.
While Velocity and Committed vs Delivered % are end-of-sprint metrics, throughout the sprint, a team’s burndown gives us a view into progress during the sprint. It’s important to look at a team’s burndown every day to assess whether the team is likely to complete all the work they committed to. Burn-down gives us the point-in-time view of the work to be completed within the sprint. If the remaining work is far above the ideal burndown line, we may need to have a conversation with the Product Owner about stories that won’t be completed. On the other hand, if the burndown is far below the ideal line, we may be able to bring another story into the sprint.
Some teams go a step further and measure Cycle Time for stories. Cycle Time starts when a team member starts work on the story and continues until the story is moved all the way to the team’s done column. Cycle time can help us determine if we are right-sizing our stories. For Scrum, stories are right-sized to just a couple of days of work or less. If Cycle Time for stories is extending well past a couple of days, you may need to try and break your work down into smaller pieces.
Using a combination of metrics and charts for a Scrum team can help the Scrum team spot problems and see if their experiments are working. These internal team metrics are just the start and give an even fuller picture when customer outcome metrics are added, but that is a topic for another post. Do not let your team meander along. Get them metrics to see where they are and where they are heading.
If you missed Philippa Fewell’s Meet Up where she speaks about how Agile 2came 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:
Systems thinking: always consider the whole rather than just the part.
Use feedback loops to learn and refine one’s artifacts and processes over time.
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.
Recently, I read an article titled, “Why Distributed Software Development Teams Work Infinitely Better”, by Boris Kontsevoi.
It’s a bit hyperbolic to say that distributed teams work infinitely better, but it’s something that any software development team should consider now that we’ve all been distributed for at least a year.
I’ve worked on Agile teams for 10-15 years and thought that they implicitly required co-located teams. I also experienced the benefits of working side-by-side with (or at least close to) other team members as we hashed out problems on whiteboards and had adhoc architecture arguments.
But as Mr. Kontsevoi points out, Agile encourages face-to-face conversation, but not necessarily in the same physical space. The Principles behind the Agile Manifesto were written over 20 years ago, but they’re still very much relevant because they don’t prescribe exactly “how” to follow the principles. We can still have face-to-face conversations, but now they’re over video calls.
This brings me to a key point of the article -” dispersed teams outperform co-located teams and collaboration is key”. The Manifesto states that building projects around motivated individuals is a key Agile principle.
Translation: collaboration and motivated individuals are essential for a distributed team to be successful.
You cannot be passive on a team that requires everyone to surface questions and concerns early so that you can plan appropriately.
You cannot fade into the background on a distributed team, hoping that minimal effort is good enough.
If you’re leading a distributed team, you must encourage active participation by having regular, collaborative team meetings. If there are team members that find it difficult to speak above the “din” of group meetings, seek them out for 1:1 meetings (also encouraged by Mr. Kontsevoi).
Luckily, today’s tools are vastly improved for distributed teams. They allow people to post questions on channels where relevant team members can respond, sparking adhoc problem-solving sessions that can eventually lead to a video call.
Motivated individuals will always find a way to make a project succeed, whether they’re distributed, co-located, or somewhere in between. The days of tossing software development teams into a physical room to “work it out” are likely over. The new distributed paradigm is exciting and, yes, better – but the old principles still apply.
CC Pace’s Philippa Fewell and Agile 2 Academy have co-authored a white paper “Is Your Agile Journey Evolving?”. Here they discuss the evolution of Agile and help you identify if your organization’s Agile adoption has kept up. We would love to hear your thoughts on your Agile journey!
To learn more about Agile 2, visit the website here.
A look at Agile 2’s values and why we need both sides of the coin to create value.
While the values of the original Agile Manifesto have helped shift the way software is developed today, it is very much left to the interpretation of the individual applying them as to how it should be done. This interpretation can often be dogmatic to focus solely on the left, sometimes at the total exclusion of those on the right, even though it clearly states “That is, while there is value in the items on the right, we value the items on the left more”.
Agile 2 consists of six values and 43 principles. It comprises a deep and nuanced set of ideas, and all of its ideas are supported by the thoughts that led to them. In this article I am going to provide a view into Agile 2’s six values and why we chose the word ‘and’ instead of ‘over’. Agile 2 seeks a balance of both the left and the right, both are needed, and both are useful. Also, Agile 2 seeks to speak to a broader range of activities beyond only software, including product development in general, and in fact any collaborative human endeavor.
The Values of Agile 2
Let’s take a look at them one by one.
1. Thoughtfulness and Prescription.
Frameworks are good and useful. They often give us a place to start and help us to solidify an approach. But they should not be followed blindly without considering your own context – where are you and what can and can’t you do in the context of your organization. Many variables are at play to construct the perfect environment for a framework to succeed, including organizational structure, culture, compliance regulation, and leadership support to name a few. A practice that is best for one organization may not be the best or have a chance of succeeding in another. That is not to say that you can’t move towards an ideal, but it very often isn’t the place you can start.
This contextual variability is why thoughtfulness is essential when applying a framework, or any practice or methodology. However, there are cases when one should start with a well-defined practice and follow it precisely. For example, if one is replacing a component of a complex machine, such as a blade on a jet engine, following procedure is often essential for ensuring that it is done right. Lives and safety might depend on following the procedure rather than improvising.
Still, judgment is sometimes required. Surgeons often have procedures for specific types of operations, but they need to be able to improvise, using their own judgment, when things do not proceed as expected; their experience and judgment are key, and the patient’s life might depend on it.
There is a place for prescription; and there is a place for thoughtfulness. Knowing the right balance is a matter of context.
2. Outcomes and Outputs
In the course of product development, outputs are the things that get produced by the development teams. These are usually design artifacts: digital files that define the product and its fabrication (hardware) or deployment (software).
Outputs are important – they help us measure our progress using metrics such as the team’s throughput, number of defects, quality of the software etc. These are mainly what you might call activity-based measures. But ultimately, we are building products or creating a service for our customers using Agile to achieve some business outcome. Sure, the customer will care about the quality, no one wants a product that is not stable, and the organization may not achieve its revenue target or market share if the product is not released on time. But the product also needs to be what the customer wants and will use. It must be the right product and someone or some group needs to be accountable for directing that vision to achieve the desired outcome, which is the true measure of success for the organization.
So, outputs matter: they are essential elements of any process; but they are not the end goal. The end goal is the outcome.
3. Individuals and Teams
We often hear there is no ‘I’ in ‘Team’ and much of what is written about Agile is written regarding the practices of the team. Teams are necessary to accomplish much of what we do, as no one person has the knowledge or capacity. But Agile often advocates for the team’s preference over the preference of the individual, be it with team norms, communication style, and even the team environment. This can be to the detriment of the individual, which can then cascade into the detriment of the team reaching its goals.
Balance is needed so as not to stifle creativity or alienate team members simply because they do not think, learn, or process information in the same way. It is necessary for teams to have norms but sometimes allowing someone to operate outside of the majority’s norm is needed too to accomplish the team’s goal.
4. Business Understanding and Technical Understanding
We often hear that business is the driver, and that technology is the enabler, that the business is responsible for the “what” and that IT is responsible for the “how”. This thinking has led to many structures where development teams are led by product managers who have a great understanding of their domain but very little understanding of how it will be implemented and vice versa. But knowledge of both is necessary to make optimal decisions.
Technical decisions have financial and future business impact, and business decisions have financial and future architectural impact. Not every person can have a deep understanding of both, but they should not entirely shift the accountability of understanding to someone else. Instead, they should seek to understand as much as possible and collaborate closely.
5. Individual Empowerment and Good Leadership
Self-organizing teams is one of the first things people often talk about when discussing Agile. Two of the principles behind the original Agile Manifesto state:
“Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done” and
“The best architectures, requirements, and designs emerge from self-organizing teams.”
These are often translated into “leave the teams alone and don’t tell them what to do”. Yet not all teams are ready for that level of autonomy and authority.
Empowering teams, or individuals for that matter, is a great motivator. It can bring about better outcomes, and it can help to build future leaders within the organization. But to empower people without some level of supportive leadership and assessment is to set them adrift. Borrowing from a talk by former Captain David Marquet, teams need to have clarity of purpose to set direction and competency and the capability and skills necessary to get the job done . Good leadership will assess the level of oversight and direction that the team needs and help them navigate while teaching them how to make good decisions on their own.
6. Adaptability and Planning
One of the original values of the Agile Manifesto contains the phrase “…responding to change over following a plan”. I do not think anyone would disagree that planning can be useful, or that if there were a significant change that would cause the goal to not be achieved then adapting the plan would not be a good idea. The point is that both the act of planning and the ability to adapt that plan are valuable.
The planning in and of itself helps us to think through the variables that would have us choose one option, course of action, timeline, etc. over another. It helps us think through the constraints we must work under and the risks we face if we come up against them. Keeping these things in mind with respect to what is occurring while executing the plan gives us useful information, we can use to adapt the plan for a better outcome.
Conclusion
Both sides of the coin, heads and tails, are necessary to create value. Agile 2 believes that both sets of values are necessary to achieve agility. Balance is needed and consideration for the context of your situation when applying practices that might favor one over the other. I do not believe the Agile Manifesto meant to infer only one side of the coin either, and that the word ‘over’ has led to misinterpretation and rigidity on how to apply it. I could be wrong in my view and understanding also. Therefore Agile 2 has provided interpretation and insight as to how the values were derived, so as not to be misinterpreted. There is a lot of thought and experience behind them from the original authors. However, we expect Agile 2 to evolve and develop with input from the community. We hope that you take some time to review Agile 2 and add to the ideas and content that comprise it.
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.
In the first installment of our Product Owner Empowerment series, we talked about the three crucial dimensions of ‘Knowledge’ that affect a Product Owner’s effectiveness. This post is going to take a deeper dive into the impact Empathy has on a Product Owner’s ability to succeed.
Empathy: Assuming positive intent, empathy is something that comes naturally to a person. However, environmental factors can influence a person’s ability to relate or connect with another person or team. Let’s explore some aspects of empathy and how they may impact a Product Owner’s success.
Empathy towards the team(s): To facilitate an empathetic relationship between a Product Owner and the team, the PO must be able to meet the team where they are (literally and figuratively). Getting to know the team members and building a rapport requires the Product Owner to extensively interact with the team and proactively work to build such relationships. Organizations should facilitate this by making sure Product Owners are physically located where the team is and is empowered to not only represent the team to the business but also play the role of protector from external interruptions, so that team can function effectively. As alluded to above, having a good understanding of what it takes to deliver, helps tremendously with the ability to place themselves in the team’s shoes and see things from their perspective.
Empathy towards the customer(s): It is easy to assume that a Product Owner acting on behalf of the business will automatically have empathy and an understanding of their needs to adequately represent their business interests. However, organizational culture can sometimes influence how a Product Owner prioritizes work. If it is only the sponsors directing the team’s scope and prioritization, a critical element of customer input is missed. Product Owners should place sufficient emphasis on obtaining customer opinion and feedback to inform the direction of product development.
Empathy in the Organization: This factor relates to the organizational culture. As companies embrace Agile and expect its benefits to be equally realized, more emphasis on the desire to be lean begins to form. While being lean is a goal every organization should have, it is important to understand what kind of impact a lean organization has on individual teams or team members. A systemic push to be lean, in combination with less than optimal Agile maturity and the presence of antipatterns, can lead to teams being held against unsustainable delivery expectations. This problem is more common than you would think. Most organizations are going through some level of Agile transformation, but leadership expectations of benefits realization are always a few steps ahead of where the organization truly is on the Agile journey. Having the right set of expectations and the empathy necessary to reset them based on continuous learning and feedback is needed at an organizational level.
Check back next week to see how a Product Owner’s success is tied to psychological safety for themselves and the teams they are working with.
If you are a Product Owner or your Agile team struggles with this role, you won’t want to miss our upcoming webinar on Product Owner Empowerment. This webinar will be held on December 15th and you can register today here! Space is limited and on a first-come basis.
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:
Knowledge
Empathy
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.
Agile 2 is here!
I was fortunate to be included in a group of exceptional Agile leaders and practitioners, led by Clifford Berg, to retrospect on Agile and improve upon what it has become over the last 20 years. Each of us began by citing issues and problems we have encountered over the years, drawing on our unique experiences. Not all of us experienced the same issues, but it was eye opening to discover what others came up with because of the diversity of the group both in practice and expertise.
We then discussed why we felt the problems occurred and what could be done to change them. This led us to revisiting the values and principles of the Agile Manifesto and many of the frameworks we use today. While I am vested in many of these, having become certified in them myself and trained others on them as well, I have seen where lack of clarity or difference of interpretation, as well as too much emphasis placed on prescription, leads to less than successful outcomes.
It is this clarity and thoughtfulness that Agile 2 seeks to deliver. It is a set of values and principles based on common problems that we believe will resonate with you, the Agile practitioner. My colleagues and I are proud of Agile 2 and the potential impact we believe it can have on the current state of Agile. Have we gotten it all right? Undoubtedly there is room for debate. Have we missed some valuable principles? Perhaps. And that is why we want Agile 2 to be open to ideas from the community, and there will be an Agile 2 version 1.1. We respect and welcome your input and ideas. We want Agile 2 to be constantly improving on what it is today so that it stays relevant. There will be Agile 2 community forums, and to begin that, there is a LinkedIn group. A book is on the way. The Agile 2 website is at https://agile2.net. Check it out!
CC Pace is ready for AgileDC! We are looking forward to hearing some great speakers and meeting with other Agile practitioners in the DC area. As a sponsor this year, we’re excited to be a part of what is always a great local event for the Agile community. Don’t forget to stop by our booth to meet our team and enter our drawing for your chance to win a $500 Amazon Gift Card!
See you at AgileDC!
CC Pace spent an informative day at the Center for Innovation Technology (CIT) event in Herndon, VA: Lean Agile DC. Jason Velentino (Director, Digital Reliability Engineering at Capital One) kicked off the conference with a great presentation on DevOps and his journey through incorporating cloud and a DevOps culture at such a large organization. It is rewarding for CC Pace to have been a part of the Agile adoption at Capital One, providing Agile Coaching and Training over the past five years and to see the evolution of Agile, which Capital One has made part of their everyday culture.
Another great presentation and discussion on Agile Engineering was lead by Jose Mingorance, and Carlos Rojas of Fannie Mae. They have pulled together a lot of ideas from Agile leaders to provide Fannie Mae with an exciting assessment and plan to drive business value throughout their organization through advancing Agile engineering practices. It was interesting to see their plans and the excitement surrounding this initiative.
Finally, Dean Chanter, also from Capital One, lead a great discussion on Joshua Kerievsky’s Modern Agile principles. Dean spoke about his journey towards ‘modern Agile’ at Capital One and how those principles are at the cornerstone of their advancement in their Agile transformation as an organization. As Capital One continues their trajectory into being Agile leaders in the Financial Services market, this will be an interesting case study to keep an eye on! We look forward to next year and seeing how everyone has progressed.
A long while ago, the Boston Consulting Group (BCG) pushed its limited and ill informed conception of Lean by focussing on waste elimination. It defined what most of us believe Lean to be to this day.
Six Sigma, with relatively good mathematical science – but not perfect according to Donald Wheeler – jumped on the bandwagon of certifications with its famous – and no less dogmatic & command and control – belt structure. Although Six Sigma always quotes chapters and verses from the statistical work of the likes of Donald Wheeler, we never heard the likes of Wheeler endorse ‘Sick Stigma’ (a term borrowed from Dave Snowden) ! (Having read all of Wheeler books, I never saw a reference to Six Sigma anywhere)
A recent study from QualPro, a consulting firm that advocates an alternative quality process, points out that 53 of 58 large companies that use Six Sigma have trailed the S&P 500 ever since they implemented it. As if on cue, once-mighty proponents of the program have begun to scale back their involvement, if not abandon it outright. Two of the most recent dropouts: 3M and Home Depot. In fact, Robert Nardelli, the former CEO of Home Depot, was forced out in part because his Six Sigma program was blamed for plummeting customer satisfaction and employee morale. At 3M, management is rolling back many Six Sigma initiatives: The program, it decided, was not compatible with the spirit of innovation that had once made 3M great. Invention is an inherently risky, wasteful and chaotic process—exactly the sort of stuff Six Sigma seeks to eliminate
Coming back to software development, those 7 wastes were the focus of the earlier book by Mary and Tom Poppendieck, where both merely transposed the 7 wastes as it were to software development. Later books proved to be better aligned with the essence of value creation, which is the foundation of Lean.
The essence of Lean, as depicted by David Anderson’s lean decision filter, is where we should stand : a) Value trumps flow, b) Flow trumps waste elimination, c) Waste elimination trumps economies of scale.
Waste elimination is a distant third focus. But neither BCG nor Six Sigma truly understood the spirit of Lean.
Lean Kanban University’s teachings focus on Value first where the flow of work is visually illustrated with the dominant knowledge activities driving product development. Waste is of course addressed in a system’s thinking approach inspired from the scientific work of Goldratt and Demings.
Daniel Doiron is an Accredited Kanban Trainer (AKT) who works closely with CC Pace to deliver Kanban training and coaching to our clients.
“Once I started looking around behind the port frames, I figured I could just….”
And so began a summer of endless sailboat projects and no sailing. One project lead to the start of another without resolving the first. What does this possibly have to do with software development and Agile techniques?
My old man and I own and are restoring an older sailboat. He is also in the IT profession, and is steeped in classic waterfall development methodology. After another frustrating day of talking past each other, he asked how I felt things could be handled differently in our boat projects.
“Stop starting and start finishing!”
It is the key mindset for Agile. Take a small task that provides value, focus on it, and get it done. It eliminates distraction and gives the user something usable quickly.
Applying this mindset outside of software may not be intuitive, but can pay dividends quickly. On the boat, we cleared space on the bulkhead, grabbed a stack of post-its and planned through the next project, rewiring the boat. The discussion started with the goal of the project. “We’re just to tear everything out and rewire everything.” Talk about ignoring non-breaking changes! I suggested that we focus on always having a working product – a sail-able boat – and break the project into smaller tasks that can be worked from start to finish in short, manageable pieces of time.
Approaching the project from that angle, we quickly developed a list of sub tasks, prioritized them, and put them up on our make-shift Kanban board. This was planning was so intuitive and rewarding on its own that we did the same for other projects we want to tackle before April.
So stop starting, start finishing, and start providing value quicker for your stakeholders.
Outside of my work at the MSRB for CC Pace, I enjoy working with community organizations in Fairfax County. After eight years of running the Jefferson Manor Civic Association, I was named Chairman of the Lee District Assoc. of Civic Orgs (LDACO). This is an organization focused on improving communications between residents in the Lee District section of Fairfax, and the elected officials and staff of the county. I have been involved with the board of directors for several years, and was bursting at the seams with ideas on how to build on the foundation I had inherited.
The nearly unlimited options quickly brought about a familiar end result – paralysis. Ideas ranged from simple house-keeping to epic public festivals. It was, to be honest, complete chaos.
Thankfully, at the time I was working on my understanding of Agile techniques and how they applied to my work situation. A key source for this was ‘The Nature of Software Development” by Ron Jeffries. As the pages flew by, the point of always prioritizing value became clear. How could this perspective be focused on running an advocacy group for civic associations? The clouds parted and the way forward became clear.
Prioritize by what would provide immediate value to the organization and its members. Again referring to Jeffries, I used the “Five Card Method” to determine what our first ‘epics’ to tackle would be. The idea is pick three to five big ticket items that will provide immediate value, and focus on breaking those down into manageable pieces.
How do we determine what our members find valuable? Ask them. A review of LDACO’s contact list showed that it was incomplete and in some cases, outdated. We had no social media outreach, either. Improved, direct communication became epic #1.
Talking with leaders in other communities, as well as long standing members of LDACO, I learned that folks needed a longer lead time to plan on attending our meetings. Epic #2 was to provide a calendar of events with at least 90 days out.
Lastly, LDACO learned that our members wanted a district and county-wide focus for meetings and speakers. While having a very narrow topic may provide value for a single community, it did not translate to the diverse group as a whole. Epic #3 was to aim for big, broad topics with speakers who were involved in the decisions that impacted the largest number of communities.
These became the main focus of LDACO’s work for the past year. These were broken down into smaller, achievable pieces, then worked on and completed. In the past year, we have grown our communication list, begun to grow on social media, and increased our attendance and membership through meetings with important stakeholders. All because we kept the focus on what provided value for our customers.
Have you heard that not all Agile Transformations are successful? Have you wondered what makes some transformations more successful than others? Are you wondering if your organization can be successful?
Here is a little analogy to think about. I recently lost 40 pounds on an eating transformation plan, or more simply a diet. I don’t like to call it a diet, because if I ever go back to my old way of eating I’ll likely gain my weight back. Also if I don’t follow the basic guidelines of the diet, I may not lose weight at all. So what does this have to do with being successful at Agile?
When organizations pick and choose what principles to follow in Agile, it’s like low carb dieters choosing to still eat potatoes, or white bread on their diet. While they may see some improvements, overall they are not setting themselves up for success on this plan. The diet gets blamed rather than how the dieter chose to implement the diet.
When preparing for a transformation, the first step is to get the foundational pieces right. Learn about the plan. Prepare your house by cleaning out your cupboards and fridge, and shop for the good stuff to replace the bad stuff. Learn what the rules of your plan are, and set a date to begin. Note, a new eating plan works better if everyone in the house is on the same plan! Then measure the results, and make corrections as needed.
In an Agile transformation, the steps are much the same. Identify what method you want to follow within the Agile framework. Get everyone onboard by helping them learn about the methodology. Prepare your “house” by looking at the organizational structure and identifying what will work within the transformation and what won’t. Make a decision to replace the practices that don’t fit in the transformation with practices that will support a successful transformation. Inspect and Adapt to keep improving and making course corrections along the way.
So what if your organization doesn’t want to follow the plan to the letter? It’s OKAY… BUT the organization needs to know the impact of alterations in the plan. If I can’t give up my potatoes what does that mean? Will I see the same success rate? How can I compensate for keeping my potatoes?
Some Agile principles are more easily adapted than others. I can counteract teams not being co-located for “face-to-face” interactions, by providing great tools for them. I can bring those team members together for planning sessions, or other occasions to help build the team rapport, and offset the lack of co-location. Other principles aren’t so easily adapted. A poor company culture where trust and empowerment are lacking, may prove to be too much to overcome, leaving the organization with unmotivated and un-empowered teams.
If your transformation has hit a plateau, or doesn’t seem to be working. It may be time to take a look at how you are following the new plan, and where your potato-eating cheats are causing you bloat, and derailing your success. It may not be the method, but rather how you are following it.
I’m just returning to work after Spring Break in Cancun. I’ve met some lovely people while enjoying the sunshine. As I chatted with those beside me at the beach and alongside the pool, two common questions are asked: What is your name? and What do you do for a living? The answer to the first question is easy, but the answer to the second question is much longer. Why? Because I can’t just stop with “I’m a trainer”. I enjoy talking about Agile and Scrum, and explaining the basic framework. I enjoy sharing with others how they can apply what I teach to just about anything. I enjoy sharing Agile stories because Agile works, and I like talking about how companies can adopt an Agile mindset.
When I start talking to someone about Agile, I begin by explaining first how past processes have fallen short. The trials and tribulations of a 1 or 2 year project plan, managing risk, reaching or missing milestones, and change requests to re-baseline the plan for any number of reasons come to mind. All with a real concern of delivering something that misses the mark in “delighting the customer”. Waterfall projects often have cost overruns, extended delivery dates, and a plethora of change requests that aren’t discovered until near the end of the project during User Acceptance Testing (UAT). For these reasons, Waterfall just doesn’t feel like the best choice to deliver software anymore.
I then move on to talk about why I, and so many others, choose Agile processes to build software today. So here is a little of what I talk about:
Continuous engagement with the customer and other stakeholders is key
Seeing progress through continuous delivery enables better feedback
Reduced risk and waste, which can save money and heartache
Adapting to change quickly, which allows for the customer to respond to market changes
Better quality deliveries by testing early and often
It isn’t magic, and it isn’t necessarily an easy transition to make. To become a truly Agile organization takes a true shift in how we and everyone else in our organization thinks about how work is performed both internally, and externally with our customers.
Yes, I am a bit of an evangelist. Sometimes I want to shout from rooftops “people get it together, follow Agile principles”, “walk the talk”, “quit being stuck in the past”. Our world is evolving every day. To keep pace with our competitors, we need to evolve too. Agile is an umbrella term for a number of methodologies including Kanban and Scrum. Today we find that Agile isn’t just for software anymore. The principles and methods can be followed just about anywhere to greatly improve our ability to deliver just about anything. That’s why I’m not just a trainer, but a believer.
When our yacht club saw membership dropping and was looking for a change, I called our Chairmen of the Board and suggested… a Kanban board.
Lucky for me, our Chairmen works in software for a well know online travel site. He knew just what I was talking about. After a short discussion, we decided to introduce the ideas of Scrum to the board. At our next Board of Directors (BoD) meeting I turned up, white board and 3 x 5 cards in hand.
Together we introduced the BoD to the idea of using a Scrum board to track our work. We started by brainstorming ideas in two key categories supporting the club’s 2015 goal of Membership retention and growth. Our two categories are membership activities and building improvements. After creating quite a backlog for the club, we discussed priority, and arrived at a commitment to working on a subset of the backlog for the upcoming sprint. Our sprint cycle was easy to determine as there are two meetings a month at the club, providing approximately 2 weeks in between each meeting. Board members signed up for stories listed in the backlog to get us off and running. At our general membership meeting, the visual board with our sprint and “product” backlog were introduced to the club.
Being “Agile” is a way of thinking. Core ideas like transparency, prioritizing, and collaboration can be incorporated into our everyday lives. I often suggest using a visual board for household chores when I’m doing training. No more nagging your partner, or kids. Just keep a board with 3×5 cards or post-its to identify upcoming work. Identify priority, acceptance criteria, and limit your work in progress by identifying a sprint length (one – two weeks work well). This helps to keep from feeling overwhelmed. Everyone is happier knowing what is expected. I’ve tried this at home with good success which is what led me to suggesting this for our club.
In taking these same principles and applying them to our club, we’re able to benefit from being Agile. The club members are our customers. They get visibility and input into the work being done. Members can make suggestions for new work, and volunteer to help. The club’s budget helps identify what can be afforded, and expected ROI helps us prioritize. Our initial work is underway, and I look forward to seeing our long-term projects lead us to sustaining and even growing our membership.
A colleague recently reached out for suggestions to help a new client whose teams are having trouble adapting to using story points.
Here are 10 tips to keep in mind when helping teams in their transition:
Change the Language – Are We Estimating Effort or Estimating Size
Story points are intended to reflect relative size. And while they are loosely correlated to effort (e.g., the bigger something is, the more effort it takes to do it), they are not meant to represent a precise measure of effort.
If your teams are grappling with estimating-in-story-points, try changing your language to sizing-in-story-points. It’s a subtle difference for those of us familiar with the concepts, but can ease the transition for those new to it.
Create New Language – Stay Away from Numbers
Historically, we think of size in terms of how-long it will take to do it. Break that strong association by using a non-numeric, relative scale such as t-shirts, dogs, boats, planes, fruits, vegetables, candy, or planets.
Clarify Language – Are We Talking Effort or Duration
Let’s take a simple example…..I have a friend who can drive across country in 3 days by herself. It takes me a week. Assuming we’re taking the same route, and driving the same speeds, why is there a difference? It turns out that my friend can drive 12-13 hours a day with minimal stops. Whereas I start falling asleep after 2-3 hours and have to stop frequently. So it takes me longer (duration) to do the same amount of work (effort).
Duration is the time it takes to complete something from start to finish and is stated in “duration-units” such as hours, days, weeks, or months. Work (effort) is the amount of work required to complete something and is stated in “work-units” such as man-hours or man-days. Because these both have a “time” component, we often mingle them together inappropriately, causing problems if there’s not a clear, shared understanding.
For instance, when I estimate a task to be 40 hours, what I mean is “it will take me 40 man-hours to do this, if I have the information and decisions I need in a timely manner, if tools are available when I need them, and if I’m not working on anything else”. What others often hear is “it will take someone a week to do this”. I’m talking about effort; others are hearing duration.
The teams my colleague observed used the following definition when estimating their stories:
1 SP = 3-4 days
2 SP = 1 week
3 SP = 2 weeks
5 SP = 4 weeks
8 SP = 6 weeks
They are tracking actual hours worked on each story and are expecting that a 2-point story equates to a consistent number of hours. But their definition is expressed in duration-units rather than work-units, and the actual effort to complete a 2-point story can vary widely depending on whether one person can finish it in a week or it takes 4 people to complete it.
Don’t define story points in duration-units and expect it to correlate to effort.
Skip Estimation, Go Directly to Work
If your teams are thrashing because of estimation, then don’t estimate. Use commitment based-planning and have them track their story throughput rather than points or hours. As they become more comfortable with this, stories will begin to creep smaller and smaller naturally. Check out more about the #NoEstimates movement.
Compare to a Baseline
Have the team select a story that is representative of the type of work they do, assign a size to it, then compare all other stories relative to the baseline.
Practice Often
The more the team does what’s uncomfortable for them, the more practice they get, and the better they will get at it. Opt for shorter iteration lengths, as this will offer more opportunities to practice.
Value First
If teams are thrashing, there may be too many changes happening at once for them to absorb. We’re looking for the creativity and speed that comes from being on the edge of chaos, not in the middle of it.
Focus efforts on improving the ability to create vertical slices of value.
Then Flow
Once teams can craft valuable slices, focus on reducing the variability in story sizes rather than thrash about estimating. Strive for small stories using story-splitting techniques. Smaller slices are easier to size, easier to finish, make mistakes visible sooner, and allow for quicker feedback. Smaller stories also improve the flow of work.
As stories become small, uncertainty and dependencies decrease, and effort and duration can be good approximations of each other. A rule-of-thumb is a story should be small enough to be completed in less than 1/3 the length of your iteration, e.g., no longer than 3-4 days in a 2 week iteration. Mature teams will often have stories that take around one day, and all their stories are of similar size.
Remember – it’s the Conversation that’s Important
The magic about relative estimation is not in getting to an answer, but in the conversation that leads to shared understanding.
And…don’t Over-Stress the System
No matter what anyone thinks, pressuring a team to accept 800 hours of “planned” work when they only have 500 hours of capacity is not reasonable, and it will never work. Forget the “if you challenge them, they will rise to the occasion” call to arms. After a certain point, that’s just a bunch of malarkey.
As my grandma used to say, “You can’t get blood from a turnip”.
As I mentioned in the introductory post in this series, an issue I frequently see with underperforming Agile teams is that work always spills over from one iteration into the next. Nothing ever seems to finish, and the project feels like a waterfall project that’s adopted a few Agile ceremonies. Without completed tasks at iteration planning meetings (IPMs), there’s nothing to demo, and the feedback loop that’s absolutely fundamental to any Agile methodology is interrupted. Rather than actual product feedback, IPMs become status meetings.
In this post, let’s look at how a Product Owner can help ensure that tasks can be completed within an iteration. As a developer myself, I’m focusing on the things that make life easier for the development team. Of course, there’s a lot more to being a good Product Owner, and I encourage you to consider taking a Scrum Product Owner training class (CC Pace offers an excellent one).
First and foremost, be willing to compromise and prioritize. An anti-pattern I observe on some underperforming teams is a Product Owner who’s asked to prioritize stories and replies, “Everything is important. I need everything.” I advise such teams that when you ask for all or nothing, you will never get all; you will always get nothing. So don’t ask for “all or nothing”, which is what a Product Owner is saying when they say everything has a high priority.
As a Product Owner, understand two serious implications of saying that every task has a high priority.
You are saying that everything has an equal priority. In other words, to the developer team, saying that everything has a high priority is indistinguishable from saying that everything has medium or indeed low priority. The point of priority isn’t to motivate or scare the developers, it’s to allow them to choose between tasks when time is pressing. You’re basically leaving the choice up to the developer team, which is probably not what you had in mind.
You’re really delegating your job to the developer team, and that isn’t fair. You’re the Product Owner for a reason: the ultimate success of the product depends on you, and you need to make some hard choices to ensure success. You know which bits of the system have the most business value. The developers signed on to deliver functionality, not to make decisions about business value. That’s your responsibility, and it’s one of the most important responsibilities on the entire team.
The consequence of “everything has a high priority” is that the developers have no way to break epic stories down into smaller stories that fit within an iteration. Everything ends up as an epic, and the developer team tends to focus on one epic after another, attempting to deliver complete epics before moving on to the next. It’s almost certain that no epic can be completed in one 2-week iteration, and so work keeps on spilling over to the next iteration and the next and the next.
Second, work with the developer team to find out how much of each story can be delivered in an iteration. Keep in mind that “delivered” means that you should be able to observe and participate in a demo of the story at the end of the iteration. Not a “prototype”, but working software that you can observe. Encourage the developers to suggest reduced functionality that would allow the story to fit in an iteration. For example, how about dealing only with “happy path” scenarios – no errors, no exceptions? Deal with those edge cases in a later iteration. At all costs, move towards a scenario where fully functional (that is, actually working) software is favored over fully featured software. Show the team that you’re willing to work with the evolutionary and incremental approach that Agile demands.
Third, be wary of stories that are all about technical infrastructure rather than business value. Sure, the development team very often need to attend to purely technical issues, but ask how each such story adds business value. You are entitled to a response that convinces you of the business need to spend time on the infrastructure stories.
At the end of a successful IPM, you as the Product Owner should have:
Seen some working software – remember, fully functional but perhaps not fully featured
Offered the developer team your feedback on what you saw
Worked with the developer team to have another set of stories, each of which is deliverable within one iteration
Prioritized those stories into High, Medium, and Low buckets, with the mutual understanding that nobody will work on a medium story if there are high stories remaining, and nobody will work on low stories if there are medium stories remaining
A clear understanding of why any technical infrastructure stories are required, and what business problem will be addressed by such stories
Finally, make yourself available for quick decisions during the iteration. No plan survives its first encounter with reality. There will always be questions and problems the developers need to talk to you about. Be available to talk to them, face to face, or with an interactive medium like instant messaging or video chat. Be prepared to make decisions…
Developer: “Sorry, I know we said we could get this story done this iteration, but blahblah happened and…”
You: “OK, how much can you get done?”
Developer: “We would have to leave out the blahblah.”
You: “Fine, go ahead.” (Or, “No, I need that, what else can we defer?”)
Be decisive.
Next post, I’ll talk about what developers should concentrate on to make sure some functionality is delivered in each iteration.
In previous posts, I talked about what the “Get It Done” (GID) and “Just Do It” (JDI) patterns look like in organizations. Today I’ll talk about another cultural pattern.
“MAKE IT SO”
If you’re a fan of “Star Trek: The Next Generation”, then you’re familiar with this phrase. I can see it now….Captain Jean-Luc Picard standing on the bridge of the U.S.S. Enterprise, facing a situation requiring action. He asks for options, listens to recommendations, and conveys a decision to move forward by telling the crew to Make-It-So. His decision communicates “what” needs to happen, but he trusts the crew to figure out “how”. This is the essence of a Make-It-So (MIS) culture, a pervasive attitude of leadership throughout an organization, resulting in an environment that supports growth, encourages exploration, demands excellence, and emphasizes accountability.
In an MIS culture, everyone has a place in the fabric of the organization….they are valued and valuable, and they know it. Everyone has an important part to play….and they are expected to play it. People are skilled and competent….and because they are, they’re confident. People are empowered, they are “granted permission” to contribute ideas, to make decisions, to take risks…to “make it so”.
Ten characteristics I’ve experienced in an MIS culture include:
Possibilities
“When nothing is certain, everything is possible.” – Margaret Drabble
We are informed by, but not tied to, what was. We are grounded in the here and now, yet remain open to what could be. We don’t drag ourselves down with visions of doom, but maintain a sense of hope and optimism.
Focus
“Concentrate all your thoughts upon the work at hand. The sun’s rays do not burn until brought to a focus.” – Alexander Graham Bell.
When vision and purpose are visible and shared, it provides us context. We know the direction and why, so we can act and make decisions accordingly.
Interdependence
“No man is an island, entire of itself; every man is a piece of the continent, a part of the main.” – John Donne
We know it “takes a village” and we can’t do it alone. Success depends on the combined strengths and contributions of everyone.
Trust
“The key is to get to know people and trust them to be who they are. Instead, we trust people to be who we want them to be, and when they’re not, we cry.” – David Duchovny
We trust in each other’s positive intent, and believe everyone does the right thing at the right time with the information they have. We act, make decisions, and move on. While we reflect on what we learn from experience, we don’t undermine confidence by second guessing ourselves or others.
Integrity
“It’s not what we profess, but what we practice that gives us integrity.” – Sir Francis Bacon
We seek to know ourselves, to be ourselves, to be proud of ourselves, our organization, our place in it, and our contributions. Our actions are congruent with who we are, our beliefs, our passions, and our strengths. We own our decisions and choices, and their consequences.
Discipline
“Talent without discipline is like an octopus on roller skates. There’s plenty of movement, but you never know if it’s going to be forward, backwards, or sideways.” – H. Jackson Brown
We strive for excellence, and excellence requires discipline in little things on a daily basis.
Encouragement
“There is no such thing as a “self-made” man. We are made up of thousands of others. Everyone who has ever done a kind deed for us, or spoken one word of encouragement to us, has entered into the make-up of our character and of our thoughts, as well as our success.” – George Burton Adams
We grow through support and encouragement, which helps us spread our wings, improve, gain confidence, and reach our potential.
Diversity
“We need to give each other the space to grow, to be ourselves, to exercise our diversity. We need to give each other space so that we may both give and receive such beautiful things as ideas, openness, dignity, joy, healing, and inclusion.” – Max de Pree
We know that too much sameness stagnates an organization, so we explore and leverage differences to open the door to possibilities.
Courage
“Courage does not always roar, sometimes it is the quiet voice at the end of the day saying “I will try again tomorrow.”” – Mary Ann Radmacher
The rewards are greatest when we take chances, risk exposure, and step outside our comfort zone. Leaders nurture and reward courage.
Resilience
“The secret of life, though, is to fall seven times and to get up eight times” – Paolo Coelho
It’s not just a matter of having the will to get back up and keep on going. We must also have the “health” to do that. As an organization and as individuals, we take care of ourselves so we can continue to bounce back.
An organization which cultivates an environment like this, is one where people are important. And when people are important, they collaborate, they innovate, they adapt quickly to change, they “dare greatly”…..and amazing things happen.
Gee, that sounds an awful lot like an Agile environment!
What do you think?
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 6th 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 6th 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?
Being always busy does not always mean being productive
As often happens at the end of a calendar year, many people reflect on the past and start thinking about what would make sense to do different in the future.
Recently, I was having such a contemplative conversation with a client. He asked me if I am seeing any trends with management practices that, while put in place with good intentions, have unexpected consequences or side effects. He wanted to understand if his organization’s challenges in meeting delivery date commitments and accelerating time to market are rooted more in something they do versus something they don’t do.
Utilization Vs Throughput While there are many trends I could talk about, there is a common pattern I have seen not only in the past year, but for the past twenty years. This pattern is prevalent in silo organizations and is usually a result of good managers doing what they are expected to do: keep systems running and control or minimize costs, while maintaining organizational commitments. If managers do these things, they are “managing well”.
One way to minimize cost is to minimize waste. What do we consider one of the biggest wastes in our environments? Idle resources. We don’t want idle resources because it feels like we’re wasting money, like we’re paying them “for doing nothing”. So, managers often aim for departmental efficiencies by focusing on maximizing utilization of people in their department. In knowledge work fields like software engineering and information technology, this practice is frequently used to minimize costs within a department.
While controlling personnel costs is managed at the department level (e.g. Product Management, Project Management Office, Development, Test, Operations, Support, etc), maintaining organizational commitments can be achieved only through synchronized efforts across departments.
Although not readily apparent, this creates a conflict because the organization’s throughput is deeply affected by the flow of work through the whole system and has nothing to do with local, departmental efficiencies.
Stop Managing Locally, Start Managing Globally Maximizing resource utilization at the local level does not necessarily support an enterprise or systemic (i.e., global) optimization of getting products or services to market as quickly as possible. Quite often there will be departments with minimal slack time because the people are fully utilized, yet they are creating long delays for other departments. While everyone is very busy (and that makes us feel good), projects seem to take forever to be completed, or are completed so late that market opportunities are missed.
As long as we manage a complex production system such as an IT organization by breaking it down into department subsystems, and we manage these subsystems individually, we’ll continue to find it difficult to achieve significant jumps in throughput or profit within a relatively short time (months). The fact that each subsystem is optimized does not mean that the flow through the system is optimum.
Managing departmental costs means making management decisions according to local efficiencies, whereas managing commitments and reducing time to market requires management decisions according to global efficiencies. In other words, to manage, improve, and predict the output of an organization, we must be able to understand and optimize the flow of work through the whole organization and NOT the local efficiency within each department.
A Fundamental Shift
The shift in thinking required to manage globally vs locally is significant for many organizations, and starts with the leadership team.
However, the inability to make this change throughout an organization is a common cause of failure when trying to increase throughput, improve adaptability, and achieve enterprise agility.
Does your organization have a lot on their plate?
Are resources spread too thin?
Have you heard the phrase “stop starting, and start finishing”, but aren’t sure how it applies to your organization?
If you answered yes to any of these questions, here is an analogy to help you describe why prioritizing and concentrating on fewer projects first is important. It’s okay to not start everything at once.
In Detroit entire blocks of houses sit empty.
Imagine we have formed a consortium to buy a cul-d-sac of houses. We have a fixed budget. The houses all require work before they can be rented or sold. Our vision is to do the work, and start receiving an ROI on our investment by selling, or renting the houses. Our budget includes money for the initial purchase, and repairs.
Option 1:
We divide and conquer. We look at each house and identify everything the houses will need to make them wonderful homes. Each of is assigned one or more houses to work on. We utilize our skills, and hire contractors to backfill our team to get the work done. We have more houses than project managers/leads, so we must spread ourselves out across many houses. It is a slow process, but all houses should be done in 12 – 13 months. Then our inspectors (QA’s & PO’s) will need to sign-off on all the houses, we will need to remediate any issues, and then finally we can start to do something with everything we finished.
While we are working on the houses, our specialist like plumbers and electricians are spread thinly across the project too. It is hard to schedule their time, and we have down time while waiting for them. Even worse than the down time, is the fact that while they are running from house to house trying to get things done, they aren’t as thorough as they should be. We find ourselves calling them back, cleaning up after them, or just don’t know that something was missed until the property is inspected. They suffer from task switching and trying to make everyone happy at the same time.
Everyone is stressed, progress is hard to see. Leadership pushes for more, and the teams become dissatisfied with their job.
Option 2:
We rank the houses by Return on Investment (ROI) or Weighted Shortest Job First (WSJF – considering job size, sunk costs, and cost of delay), and all of us begin work on the house(s) with the biggest ROI/WSJF. When the first house is finished we can immediately sell or rent it, moving on to each subsequent house completing them with dedicated resources until all houses are complete. Worst case, the last house is not complete for 12 or 13 months, however we have been receiving money from the first house for 10 months, and each subsequent house as completed. By the time we get to the last house, we may decide just to bulldoze it and build a park.
We welcome change. More importantly, we can choose to change. We haven’t wasted any work identifying what will be done ahead of time. We identify what we need for each house “Just-in-time”. If there is a new “green” lighting system available, we can choose to change the plans and use it. If we decide to add heated flooring in a particular area of the next house, we can. Furthermore, we can decide if it makes sense to include these items in other houses based on the impact to just one house.
Our rework on each house is minimal. Our teams get faster at doing their work the longer they work together as a team. Everyone sees constant progress towards a shared end goal.
We have our supporting infrastructure in place. We know who is responsible for the work, and can trust everyone to do their best. The team gains positive momentum, and direct feedback. Everyone sees progress. We follow Lean and Agile Principles to ensure our teams are happy and fulfilled with their job.
One of the hardest things for companies transforming to Agile to accept is the idea that team members are to be dedicated to the teams to which they are members. When it comes down to it, it is really about the cultural shift.
In order to better understand what the cultural shift is, you must first ask yourself: “do I know what a team really is?” A team is defined as “a small number of people with complementary skills, who are committed to a common purpose, performance goals, and an approach for which they hold themselves accountable[1].” Teams that are geared toward the same goals are much more productive and are said to be able to accomplish more together than individually— “T.E.A.M. = Together Everyone Achieves More!”[2]
Traditionally, when we discuss teams, we talk about them in the context of project teams. However, there are a few things about ‘project teams’ that cause us to pause as we refer to the definition of what a team really means.
One of the things about ‘project teams’ that cause some dread is the fact that project team members are not fully dedicated to the efforts of the one project team. In most cases, each member ends up being a member of multiple project teams. As members become members of multiple teams, their focus is interrupted and therefore undermines their commitment to each of the ‘teams’ they are a member of. It becomes hard to hold yourself accountable when you feel an obligation to commit to multiple teams, which usually will have different goals!
Another thing about ‘project teams’ that poses some stress is that they are only together for a short period of time then the members disperse and join other teams. When this happens, they now have to build their commitment and goals, as a team, all over again. If teams must continually come together then are broken apart, sooner or later the commitment to the team means nothing. Each time the team dynamic changes, the productivity of the team goes down and very seldom has time to recover before there are more changes.
How does this change with Agile, you ask…
As organizations move toward a more Agile-driven one, how they ‘build’ teams becomes very important. One of the main goals of Agile teams is that they are geared toward a specific backlog, which is centered around a particular product. Once the team is set with the members, they have the ability to rally around the backlog and focus on that.
When building teams around a specific backlog, or product, it is easy to have them focus on the single team that they are members of. Using this idea, the members that are on the Agile team are all dedicated to the same goals and outcome. When this happens, the members have a higher level of commitment because they are dedicated to the one team and can focus on the goals of that team and none others.
Agile teams that are geared toward a specific backlog, or product, have no reason to be dispersed at the end, because there is no end. Because a backlog, or product, is for all purposes, never-ending, the team keeps working on the backlog and the organization, in some way, keeps the backlog full with things that the product needs to have or do.
As the culture shifts from one geared toward the traditional definition of team to the Agile team concept, their focus and commitment shifts. It is the organization’s job to support the change in the team structure and help to keep the team focused on the idea that “T.E.A.M. = Together Everyone Achieves More!”[3] holds true!
Tune in next time, when we talk about what it means to be a cross-functional, dedicated team…
Metrics are vital to a team. They give us a starting point, just like choosing “my location” on your GPS. Then metrics tell us where we are headed. They help us know whether our team is winning at continuous improvement. They tell us how our journey is going, and where we might be off course.
While Velocity and Committed vs Delivered % are end-of-sprint metrics, throughout the sprint, a team’s burndown gives us a view into progress during the sprint. It’s important to look at a team’s burndown every day to assess whether the team is likely to complete all the work they committed to. Burn-down gives us the point-in-time view of the work to be completed within the sprint. If the remaining work is far above the ideal burndown line, we may need to have a conversation with the Product Owner about stories that won’t be completed. On the other hand, if the burndown is far below the ideal line, we may be able to bring another story into the sprint.
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.”
Herndon, VA: Lean Agile DC. Jason Velentino (Director, Digital Reliability Engineering at Capital One) kicked off the conference with a great presentation on DevOps and his journey through incorporating cloud and a DevOps culture at such a large organization. It is rewarding for CC Pace to have been a part of the Agile adoption at Capital One, providing Agile Coaching and Training over the past five years and to see the evolution of Agile, which Capital One has made part of their everyday culture.
