Agile Challenges: How Critical is Management Support and Sponsorship

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

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

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

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

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

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

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

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

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

Are you new to Agile testing?

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

Success Factor 1: Use the Whole Team Approach

Success Factor 2: Adopt an Agile Testing Mind-Set

Success Factor 3: Automate Regression Testing

Success Factor 4: Provide and Obtain Feedback

Success Factor 5: Build a Foundation of Core Practices

Success Factor 6: Collaborate with Customers

Success Factor 7: Look at the big picture

Success Factor 1: Use the Whole Team Approach

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

Success Factor 2: Adopt an Agile Testing Mind-Set

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

10 Principles for Agile Testing

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

Success Factor 3: Automate Regression Testing

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

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

Success Factor 4: Provide and Obtain Feedback

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

Success Factor 5: Build a Foundation of Core Practices

The following core practices are integral to Agile development.

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

Success Factor 6: Collaborate with Customers

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

Success Factor 7: Look at the Big Picture

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

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

Summary

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

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

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!

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

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

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

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

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

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

Welcome to the final part of my 12 Principles series where we’ll cover the final 4 Agile Principles. (In case you missed it, here’s a link to Part 1 and Part 2). If you utilize all three parts together, you will have a great resource for working with your teams’ Agile growth.

9. Continuous attention to technical excellence and good design enhances agility.  
We may be working in short sprints, but this is not an excuse to let technical excellence slip. Potentially deliverable means the code is tested and passes.

Technical debt is dealt with on a regular basis, and not left until the very end of the project.

This isn’t one and done, so support your teams to be the best they can be. Allocate approximately 20% of each sprint to “technical excellence” https://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).aspx. Some basic things you should be doing are planning for Test Driven Development (TDD), pairing and refactoring. Developers create simple designs, and look for constant improvement through regular feedback.

One final thought, Technical Excellence is about more than developer’s code. It is also about the organization becoming more Agile. Think about working with all members of the organization to improve their skills by cross pollinating, training, and mentoring.

10. Simplicity–the art of maximizing the amount of work not done–is essential.
 The phrase to remember is not to “gold-plate” your features. One best practice here is to follow TDD. By developing to the story and its acceptance criteria until the test passes, and no more.

Some developers may feel they could do more, but what if what they create won’t be used? Then we have wasted time, and a potentially untested item. It’s great to have ideas, so write a story and pass it to the Product Owner for prioritization in the backlog. Remember it’s easier to create complicated solutions, harder to create simple solutions… but simple solutions last longer, increasing quality and decreasing total cost of ownership.

11. The best architectures, requirements, and designs emerge from self-organizing teams.
Change can be difficult, and moving from a waterfall environment to an Agile environment is no exception. In order for team members to identify the best design during Sprint Planning, they must be knowledgeable about the environment and system they are creating. This means we can’t treat them like mushrooms (keeping them in the dark, and feeding them “fertilizer”).

If your organization is working with complex systems, ensure the architectural runway is in place. Expect some ramp-up time for team members to become familiar with the environment. Ensure that there are resources assigned from the “systems” team to support each scrum team. Create domain models, physical models, etc. as needed to ensure sufficient information is available to the team. Then allow sufficient time for the team to discuss and build on their designs during Sprint Planning.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Welcome to the Retrospective! Agile is an empirical process. Based on the results, we adapt and improve. When I hear that teams are struggling with retrospectives, I suggest they rethink how they think about this ceremony. It isn’t a gripe session. It is an honest introspection of our performance.

Following this principle means we need to take a look at how we are doing, and commit to experiment to create small improvements. Each and every sprint allows us to try something out, and to look at the results at the end. If the results are positive, great. We can decide to run with the change. If the result isn’t positive, we can choose a different approach for the next sprint. There are great resources out there to keep Retrospectives from becoming dull and boring. If you are struggling, take a look at the book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen.

It is easy for an organization to be “Scrum-but”. The risk in staying “Scrum-but” is not truly getting all the benefits of being Agile. Read all three parts of this blog and evaluate how your organization is doing. I invite you to add your comments and experiences, as we share in the Agile Community any ideas for continuous improvement!

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

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

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

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

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

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

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

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

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

 7. Working software is the primary measure of progress 

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

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

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

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

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

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

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

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

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

Over the course of this three part blog, I will cover all of the 12 Agile Principles. In this first installment I implore you to stay tuned for all 12, and get to know how principles can impact your team. I believe following these principles is the core of being “Agile”.  It is a topic I am always excited to discuss. How does your group follow the 12 Principles? Is there room for improvement?

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 
Let’s face it, if we aren’t delivering something of value, what are we doing?

Everyone on the team must understand the value of what they are delivering. As a team, we become “one” focused on our delivery. The value we provide binds us together, and gives us purpose.

Product Owners can provide the team with a Vision to help guide the team to value delivery. Each sprint delivery supports the vision.

We aren’t all lucky enough to work on feature teams delivering software. If you fall in this category, just replace the word “software” with what you do deliver.

Find your value, and deliver small pieces like building blocks.

2. Welcome changing requirements, even late in development. Agile processes harness change for customer’s competitive advantage. 
While this principle seems to invite disastrous changing of scope at any time, this is not the intent. We do not interrupt sprints once they are started, unless it is a dire emergency. There are ways to stop a sprint, which is a topic on its own. What this principle asks us to do, is keep our backlog up-to-date.

If a new feature is requested, it can easily be added to the backlog. If a feature in the backlog is considered to be out-of-date, it can be removed or updated.

As development progress, and more of the backlog is completed, everyone is learning and discovering together. This principle allows us to change, reminding us that the backlog is fluid.

Organizations need to adapt their policies to embrace these changes, or they miss out on a fundamental benefit of being Agile.

Teams should not feel mad, angry or bad because requirements have changed. I often see negative reactions to change, when just the opposite should happen. Through the teams’ continuous delivery, we learn and therefore we adapt.

I like to tell leadership, through your Product Owner we enable the team to build the highest value features at any time. Don’t get locked into years of work in the backlog. Stay engaged, work with Product Owner, keep the backlog alive. Remember the motto “just enough, just in time”, as it will reduce waste by not documenting requirements too far out in the future, that could end-up being changed, or cut altogether.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. 
You’ve decided to follow Agile. You have a backlog, and a team ready to work. Now you just have to get everyone focused on frequent delivery. Organizations like Netflix deliver continuously (see http://venturebeat.com/2014/03/10/continuous-delivery/). However, the rest of us may be still trying to adapt to delivering at the end of a 2-week sprint.

The reason for short time scales is important to understand. Short time scales reduce risk and waste. We test smaller chunks, we get feedback sooner, and overall can react to change easily when we are working in small increments. A short sprint cycle provides plenty of practice, and opportunities for skill and process improvements.

The team needs small stories. Without stories small enough to be built and tested during the sprint, the team will not be able to fit work into shorter time scales. How small? Half a day to two days of effort. Do you shudder at the thought? Developers don’t always like this concept at first, but it is important to try smaller pieces of work. The benefit of small stories outweigh the fact that developers may have to touch code more than once.

Many Agile organizations aim for two week sprints. Some successfully, but new Agile organization may allow teams to work on just a couple of stories that take the entire two weeks; when complete, these stories may be handed over to a QA team. If you are falling into the latter category, there is still improvements to be done to truly benefit from Agile.

In the Scaled Agile Framework, we are introduced to the phrase “Develop on Cadence, and Release on Demand” http://scaledagileframework.com/develop-on-cadence-release-on-demand/. Supporting the notion that the teams’ developed work may sit until the organization is ready for the release, although it is considered “delivered” by the team. Delivery by the team, means the work passed test and is done. Completed work is ready for Sprint Review. The work is demonstrated and feedback is gathered.

4. Business people and developers must work together daily throughout the project.
Oh how I long to click my heels together, and be transported wherever I want. As an Agile organization, you are lucky if everyone is collocated. It is a desire many of us share. The reality is Agile has moved beyond start-ups and web-dev groups. Agile is embraced by organizations large and small; located centrally as well as all over the world.

Using good communication tools can help us feel like we work together, even when we aren’t collocated. The idea of working together daily, allows everyone involved to participate in the Daily Scrum; it allows us to have easy access to each other. No longer are requirements written and “thrown over the wall” to be developed. Developers can share their screens with us, ask questions, get feedback, and quickly resolve issues when Product Owners and business users are readily available. Don’t wait until the Sprint Review to touch base with your team. You will find you have another way to reduce risk and waste.

Use Team Agreements or Team Norms to identify practices for working together. Collocate teams whenever possible. Invite business users to Sprint Reviews. Include times when Product Owners will be available to everyone, as well as when developers can work uninterrupted.

Let me know your comments, and stay tuned for Part-2 where I’ll will discuss the next four Principles.

Being a Product Owner is a really hard job. I have been hearing this for a long time and it has come out in almost all of the retrospectives in one way or the other over the years.  Here are a few recurring themes I hear:

Product Owners and decision – making
I often hear things like – “My Product Owner doesn’t make decisions quickly enough or by themselves. It feels like they have to check with their leaders even before making even the most trivial decisions.”

My questions or thoughts revolve around – is it really a person thing, or is it pointing to the management not providing Product Owner the authority to do so? Is it the management’s mandate for the Product Owner to seek approvals before making any decisions?

If that’s the case then not getting the questions answered in timely manner can impact the completion of work and eventually has a significant impact on Time to Market. It is probably how the organization is structured and the organization probably needs to shift from a Do Agile to a Be Agile mode.

Product Owner is not technical
When did the requirement to be a Product Owner become technical?  A Product Owner doesn’t need to be technical. They need to answer the team’s what’s not really the how’s.

Going back to the Agile Principles: The best architectures, requirements, and designs emerge from self-organizing teams.

Product Owners should not be the ones providing teams the technical direction. They should be able to provide the vision to the teams.

Teams are the ones who make the technical decisions around the design and architecture. The entire team and the Product Owner can look into the various design options and discuss the trade-offs but it is the team that is responsible for the how the implementation will take place and how long would it take.

Product Owner is not available to make the decisions
Being a Product Owner is a full time job. A Product Owner should have ample time to sustainably carry out their responsibilities. If the individual is overworked, the team’s progress suffers and the resulting product may be suboptimal.

At a workshop this week many of the Product Owner attendees were overwhelmed with the length and breadth of the Product Owner role.  They said things like, “As a Product Owner should I be making all the decisions?”, and “Are they really a single- wringable Neck…..but why??”

This role is by no means is an easy role. They have to be constantly engaged in conversations with the stakeholders, keeping a check on the pulse of the market, looking at trends and innovation but at the same time be available with the team to answer all the questions.

I feel very strongly about the Product Owner making the decisions – at a team level the Product Owner is expected to make the decisions. They are responsible for providing the answers to the team. Be the single point of query or decision making body for the team. The Product Owners should be available to the team at least for some dedicated team time or core hours every day.

You should be that leader for the team so the Team does not have to look any further.  The Team can just ask questions of you and get an answer and be sure what is required off them to fulfill the commitment that they made during the sprint planning or the PI planning.

But in all honesty is it Team Vs Product Owner….not really
The memories of best teams that I carry in my heart are the ones in which all of us worked together. We were open enough to call out ‘hey, need you for this and that,” or “I need …….this from you,” and “you need to show up for this meeting and be available at this time…”.

The team (onsite and distributed), Scrum Master and Product Owner all were available during core hours and would address things as they came. Does the level/seniority of Product Owner in the organization matter in the quality of decisions they make? Or is it how much confidence and trust their team and leadership places on them?

Before we start to worry if we have the best Product Owner in the whole world, or if we can be the best Product Owner, it’s important to remember that Product Owners, like the rest of the team, need time and support to acquire the necessary skills.

Everyone has their unique strengths and weaknesses and that’s what we bring to the team. A Product Owner might be great at providing the vision for the product, interacting with the team and stakeholders, but may not be the best at writing user stories.  In areas of inexperience or weakness, the team would pitch in, helping with the work and enabling Product Owner growth.

So, ultimately what matters is the ‘We’ as in team not ‘I’ as a Product Owner.

I found Mike Cohn’s posting Don’t Blindly Follow very curious because it seems to contradict what many luminaries of the Agile community have said about starting out by strictly following the rules until you’ve really learned what you’re doing.

In one sense, I do agree with this sentiment of not blindly doing something.  Indeed, when I was younger, I thought it was quite clever of me to say things like “The best practice is not to follow best practices.”  But then I discovered the Dreyfus Model of Skills Acquisition and that made me realize that there’s a more nuanced view.  In a nutshell, the Dreyfus model says that we progress through different stages as we learn skills.  In particular when we start learning something, we do start by following context-free rules (a.k.a., best practices) and progress through situational awareness to “transcend reliance on rules, guidelines, and maxims.”  This is resonates with me since I recognize it as the way I learn things and when I can see it in others when they are serious about something.  (To be fair, there are people that don’t seem to fit into this model, too, but I’m okay with a model that’s useful even if it doesn’t cover every possibility.)  So, I would say that we should start out following the rules blindly until we have learned enough to recognize how to helpfully modify the rules that we’ve been following.

Cohn concludes with another curious statement: “No expert knows more about your company than you do.”  Again, there’s a part of me that wants to agree with this, but then again…  An outsider could well see things that an insider takes for granted and have perspectives that allow them to come to different conclusions from the information that you both share.

I find myself much more in sympathy with Ron Jeffries’ statements in The Increment and Culture: “Rather than change ourselves, and learn the new game, we changed Scrum. We changed it before we ever knew what it was.”  This seems like it would offer a much better opportunity to really learn the basics before we start changing this to suit ourselves.

On January 28, CC Pace and the Potomac Forum collaborated once again to present their latest in the series, Agile Development in Government Training Workshops.  In addition to CC Pace’s presentations and training sessions, speakers and panelists included officials from the Department of Homeland Security (DHS), the National Geospatial-Intelligence Agency (NGA), and the Government Accountability Office (GAO).  Several other Federal agencies were represented in the audience.  The workshop participants were challenged to take a fresh look at what agility, “being agile”, really means.  One top Federal official posed five questions for us to consider:

1. Can we have a Lean bureaucracy? If you had one more incremental dollar for your project, what would you spend it on? Right now we’re spending that dollar on oversight and documentation instead of valued results.
2. Shouldn’t we be looking at best practices, cutting edge approaches instead of arguing about Waterfall vs. Agile?
3. Why not benchmark to leaders in Industry like Netflix and Amazon?
4. Why doesn’t top IT talent think the Federal government is the best place to work?
5. Why is it acceptable to spend billions of dollars and take forever to build software?

One of the key Agile principles that was emphasized throughout the day, both by CC Pace and the government officials, was the value of empirical learning.  By building software incrementally and taking advantage of short feedback loops facilitated by continuous communication with end users and other stakeholders, the developers can apply what has been observed and commented on to improve the process and more accurately inform the schedule, requirements and production as they go forward. This approach greatly reduces project risk while improving quality and usability of the finished product.

Officials from some agencies that are successfully implementing Agile practices already, cited recent initiatives like the publication of the TechFAR, and the Digital Services Playbook, as well as the establishment of GSA’s 18F (a Federal Agile services group), that are beginning to remove some of the roadblocks to agility in the Federal Government.  Since there were a number of workshop participants who were new to Agile and Lean Thinking, CC Pace included an excellent session on Agile Basics, laying the foundation for our working lunch session,  What challenges will your agency face when trying to implement Agile?  The working groups came up with five common challenges: 1) Cultural resistance to change, 2) Regulatory issues (all the way up to Congress), 3) Old measures that may not be relevant in the new environment (EVM), 4) Need for training of executives and middle managers, and 5) Inability to attract top talent to government from the private sector.

Our panel discussion included comments on these five issues as well as on the fact that Waterfall project failures have soared into the billions of dollars over time.  There has to be a better way.  However a note of caution was sounded since many vendors are claiming “agile” when there is nothing agile at all about their approach. Agile is not a “silver bullet”.  Agile is not going to fix a poorly managed project.

CC Pace wrapped up the day with a presentation by their Federal Practice Director on cutting edge practices in Lean and Agile in the session What’s on the Agile Horizon and Why it is Important for Government, followed by the final presentation Putting it All Together – An Agile Roadmap, by CC Pace’s Managing Director.  The workshop received excellent evaluations from the participants.  We hope you can join our next Agile in the Federal Government Workshop at the Potomac Forum this coming spring.

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

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

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

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

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

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

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

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