Blog


From Scrum Master to Product Owner: A Journey

Many of us have transitioned from either a sofware engineer role or a QA engineer role to a Scrum Master. This is a natural path for those who want to become a servant leader, working with the teams/stakeholders, coaching people and leveraging agile/Scrum across the organization. Furthermore, it requires a different mindset with more focus on soft skills.

It’s also common to see software engineers and QA engineers turning to a product owner role.

Therefore, how difficult is it to be a product owner when you are a Scrum Master? Well, there are a lot of challenges, due to the fact that these two roles have different perspectives and skill sets.

Scrum Master: Abandoned and Chosen

Once upon a time, a company I worked for as a Scrum Master decided to get rid of all Scrum Masters for various reasons—the most critical being budget.

Consequently, the role of the Scrum Master merged with the engineering manager, and the engineering manager took over the Scrum Master’s responsibilities. As usual, some of the engineering managers weren’t prepared to assume this new role because either they were toxic to the teams or hadn’t been trained enough in Scrum.

At the same time, all Scrum Masters were laid off by the company due to major cuts on the budget, my boss asked me if I would like to become a product owner once the team I was acting as a Scrum Master for didn’t have a full-time product owner.

I was already doing part of the product owner duties: working with the stakeholders to gather the requirements, writing and prioritizing the user stories, digging into the product and envisioning its growth, working close with the teams, and being the voice of the customer.

The team’s product owner was so busy with another priorities that she didn’t have enough time to focus on that particular team. I took the initiative and action on behalf of her.

A desire to deliver a delightful product to my customers was always on my mind. With a lot of excitement and anxiety, I finally accepted the challenge of officially taking on the role of the product owner.

New Journey: Ups and Downs

Several Scrum Masters like me have faced many challenges with their product owners and sometimes they become the impediments for the team. As a Scrum Master, we should address and remove them.

As the first time as a product owner, I didn’t want to be the impediment and cause of the difficulties for the team. As a product owner, I wanted to create the user stories using the INVEST model, write good acceptance criteria, groom the user stories with the team, prioritize the backlog, be available to the team, define a goal for every sprint, and so on.

I was doing my part, however how about the Scrum Master (in fact, the engineering manager) for the team and product? Well, she became the impediment, because she was not doing her part.

I was frustrated due to the fact Scrum was not being implemented as it should be and the whole benefits were being lost. The team was still looking to me, waiting for me to remove this impediment, but I wasn’t supposed to take action anymore, only concentrating on the product.

On the other hand, I was the Scrum Master before, so I still had the ability to coach the new Scrum Master, no excuses. However, the engineering manager didn’t want to follow coaching and I was reprimanded when I was told I was on the product side and couldn’t influence the engineering process anymore.

This is the hardest part of converting from a Scrum Master to a product owner role: your brain has to do a mind-shifting and move away from the old habits and responsibilities.

For several months, I continued facilitating the sprint planning and review, because the Scrum Master didn’t want to do that or didn’t know how to do it, but the product had to be delivered anyway.

Resilience and Working Hard for the Team and the Customer: Reward

It might take time, but you can adapt yourself to the new norm from Scrum Master to product owner. In the beginning, the path seems long: our focus is different, more on the business side, staying closer to our customers, and understanding their pain points.

If you’re faced with this challenge, don’t give up, make all your efforts to switch gears and mindset, and the reward will come.

What did I learn? Make the team feel part of the product, and they can help you to drive the results and goals of the company. The team will support you in the process for a while if you are open, transparent and trust them.

Be present in every retrospective and ask how you can improve in a very honest conversation.

Be humble and listen. Change your attitude, demonstrate that you’re working hard not only for the success of the product, but for their success as well.

As a new product owner, learn every piece of the business rules, talk to the stakeholders, create effective roadmaps and be the “CEO of the product.”

Last, but not least, go to conferences, training, read books about product management, be involved in the agile community. It’s now time to focus your knowledge and strengths in the product ownership.

New Hope: Continuing the Journey

New challenges appear every day and this is a good sign because the world keeps evolving and each challenge is an opportunity to grow in your career and as an individual.

Improve the method of creating the user stories, leverage the product, streamline the process of delivering the features continuously, go outside of the building and listen to your customers, experiment new things and finally delight your stakeholders with innovative products.

The path and the migration from a Scrum Master to a product owner can be complicated; however, it’s rewarding and valuable for several reasons: business model understanding, value proposition creation, industry standards and terminologies in practice, customers and partners relationship, channels and segments applied, generating revenue by different methods, applying innovation and open new markets, and the list goes on.

Are you also transitioning to a product owner role and need some help? Feel free to leave your comments or questions and I’ll be glad to help you out.

How to Get Your Teams to Estimate Better

“We need to get better at estimating,” an experienced member of a Scrum development team once told me. “Management is getting concerned that we keep coming up short on our commitment.”

“Really?” I responded. “What have you been committing to?”

“Thirty story points” she said. “We get there about 50% of the time. In a couple of recent sprints, we’ve even exceeded thirty points, but the last sprint marked the third time this quarter that we fell short of our target.”

“Why was your forecast off target, do you think?” I asked.

“Well, things come out of left field occasionally. You know, stuff that couldn’t be anticipated in sprint planning,” she answered.

“So, why are you estimating effort if you can’t predict what will happen in the sprint?” I said.

Now, at this point I want to make clear that I am not one of those who say that development teams should not estimate effort. For me, the ability to estimate independently is an important part of the autonomy of teams. What I was trying to do in this particular conversation was to get the team member to consider why teams estimate in the first place, and what “commitment” means in that context.

It is not just a matter of those doing the work being the only ones who are able to estimate effort, which I believe to be true. I recently participated in a large multi-team project of effort being estimated by a centralized systems analysis unit. In that project, the development teams were involved in estimating, but it was the systems analysts’ forecast that was being communicated to the customer. The result was massively inflated customer expectations, and retrospection revealed that the teams’ estimates were about four to five times larger—and thus far more accurate--than those of the analysts.

Why Estimate Effort?

So, development teams make the best and most accurate estimations. That’s all well and good, but it still doesn’t answer the question of why estimates are necessary in the first place.

Scrum is a “pull” system in that it balances demand with the team’s capacity to do work by giving the team control over how much work is brought into the sprint. No one can tell a development team how to do its work, or how much work it must do.  Effort is estimated – in story points, in the number of stories or in person-hours – so that a judgement can be made about how much work can be pulled in from the product backlog in order to meet the sprint goal.

When either team members or their managers start to fret about the team’s commitment in terms of its target velocity, it is a sure sign of old muscle memory kicking in. After all, the velocity is a forecast, not a commitment. The team’s commitment is not to its velocity but to the goal that was agreed upon in the sprint planning. And, in any agile environment, commitment means that, given the information we have right now, the resources we have at our disposal and our judgement about our capacity to do work, we think we can get to a certain point by the end of the sprint, and we are going to do everything in our power to get there.

Therefore, a commitment can never be equated to a guarantee. It is akin to the moment a football team walks onto the pitch: the team is committed to winning the game, but there are too many variables in play (not the least of which is the opposing team!) for victory to be guaranteed from the start.

When managers ask me questions about the target velocity of the teams, my first response is to ask them why it should be any concern of theirs. They typically mumble a reply about making sure the team is working to plan, or being efficient. A brief chat normally follows in which I point out that management’s concern should be with business outcomes and with making sure the teams have the environments and tools they need to deliver them, not with the team’s tasks.

Target Velocity and the Sprint Goal

So, at this point we’ve established that target velocity is a concern of the development team and no one else (OK, the product owner needs to know about velocities so he or she can make trade-offs in the ordering of the product backlog, but that’s another story entirely). Estimates simply need to be accurate enough for the team to confidently identify the items at the top of the product backlog that can be worked on to meet the sprint goal.

A good product owner will give the developers extra wriggle room by articulating the sprint goal to customers and stakeholders independently of the product backlog items (PBIs) or the stories that might constitute it. By giving the upcoming increment a named state, or by describing the expected value in a few sentences, the product owner can work with the team if a mid-sprint descoping of the forecast is needed, without compromising the sprint goal.

All of this means that while the team’s estimates do not demand the same precision as task estimation in waterfall-based planning, they do still need to be accurate. Actual velocities that go up and down like a roller coaster help no one, and some level of predictability is needed. I’ve seen teams agonize over what a 13-point story should look like, and have even been shown handbooks in which reference PBIs are described for each number in the Fibonacci series. In my experience, this type of overly complicated approach never works.

"Smaller" is More Predictable

There is only one way to improve the estimate of effort for PBIs: breaking them down into smaller PBIs. Think for a moment about the values most often used in planning poker, for example: 1, 2, 3, 5, 8, 13, 20, 40 and 100. They loosely follow the sequence in which each number is the sum of the previous two.

This raises the question, why “20” instead of “21”? Simply, because “21” would be too precise. In effect, we are saying that anything more than 13 can be considered large, and will probably need to be decomposed.

The larger numbers in the sequence and, more specifically, the larger gaps between them, reflect a corresponding level of uncertainty. Suppose the team thinks a PBI is bigger than an 8, but is probably not big enough to be a 13. In that case, it might “precisely” be a 9, 10, 11 or 12. However, they can only categorize the PBI as either an 8 or a 13. Essentially, the larger a PBI is, the greater its possible variation from its predicted effort. On the other hand, if all the stories are, say, a 5 or smaller, then it is only when a PBI sits between a 3 and a 5 that you begin to see significant variance.

It doesn’t really matter whether the team uses stories and story points or not, as long as the underlying goal is still the same: to break the PBIs down to the smallest size they can be and fit a number of them into the sprint. In my view, this is the only way that a team can reliably improve the accuracy of their estimations.

5 Signs Your Team is on the Path to Agility

Some of the comments on my previous article, Mixing Roles in a Scrum Team, explored the idea that the successful mixing of roles is dependent on a team’s maturity level.

However, this begs the question: how can we accurately assess a team’s maturity?

In the article Agile Self-Assessments, Ben Linders gathers many tools which any team can use to assess its maturity. Based on the results of such assessments, agile leaders can make informed decisions on how to proceed with team structuring.

Since I’ve already shared some of the signs that a team is lacking an agile mindset, I would now like to share five signs that an agile team is on the right track.

1.       A Release at the End of Each Sprint

The ability to release at the end of a sprint indicates several positive team traits, the most important of which is that the team understands and adheres to the definition of done. That is to say, all user stories which were finished in the sprint are in a releasable state. In these situations, “releasable” usually indicates that the product is suitable to be released to an internal integration environment, not to the end customer. However, an internal release is still a release nonetheless.

2.      A Staircase Burndown Chart

Having small user stories which can be finished in a short amount of time is a talent acquired by both the product owner and the team as they move upwards on the agility ladder. A staircase burndown chart showcases the team’s understanding of prioritization as well as the importance of delivering the product in small chunks rather than as a full-blown application.

3.      Gathering to Solve Problems

If you see the team sitting together around one computer and problem solving as a group, this reveals that the team is sharing knowledge, brainstorming, seeking a solution and, most importantly, that they are truly working together as a team.

4.      A Prioritized Backlog

Developing an estimated prioritized backlog is the main responsibility of the product owner, and he or she can’t do so without the help of the rest of the team. For a backlog to take shape, the product owner will need the team to estimate and clarify user stories, ask the proper questions and form adequate acceptance criteria.

5.      Short Planning Meetings

In general, the shorter the planning meetings, the more mature the team. This is because short meetings typically mean that many of the team’s uncertainties were already clarified during the backlog grooming session or via frequent communication with the product owner.

These are just a few of the many signs that a team is mature, but they are the ones which can be most easily spotted by agile leaders of any level.

Do you know about any other indications that a team is on the path to agility?

I would love to read about them and any other thoughts you may have in the comments section below.

3 Necessary Conditions for “Going Agile”

In the terrain of agile software development, there are three rivers - Trust, Ownership and Vision - which flow and converge into a confluence that helps to create the necessary conditions for a high performing, self-managing team. A team that adapts quickly to what its customers want, delivers great business value at a sustainable pace and is filled with happy people. In short, the ideal agile team.

This is true regardless of the industry, the geographic location and the organizational size. And, if you’re in the software development field like me, it makes no difference whether you’re using  SAFe, LeSS, DaD, XP, Scrum, Kanban, Scrumban or some new framework of your own.

Sure, at times the waters can be choppy and the currents unpredictable. But one thing is certain: a disruption of any of the three rivers will result in a true storm. Either the crew will start thinking about mutiny, or the boat will run aground on one of two shallows: command_control or anarchy_chaos

Beware the Twin Sirens:  Command and Control

The biggest challenge for leaders in a transformation is often that of leaving command and control behind. While they can easily articulate a clear vision of where to go, leaders  tend to have a hard time refraining from telling people how to get there.

In my experience, many of the difficulties these leaders face result from the fact that the leader can no longer play the old role of the hero with all the answers.

In his great book "Humble Inquiry", Edgar Schein says:

“Our culture emphasizes that leaders must be wiser, set direction and articulate values, all of which predisposes them to tell rather than ask.” (emphasis is mine)

The simple task of coaching and encouraging leaders to ask the right questions instead of providing the answers begins to catalyze them at every level. This reaction will in turn multiply the speed at which decisions can be made and new learning can take place. (For more on change, see my previous blog post: Personal Change: Unlock Successful Organizational Transformation)

Trust Above All Other Things

The transfer of power, which allows for rapid inspect and adapt cycles, requires great trust in individuals as well as in teams. Trust can be the difference between success and failure, especially as the boat heads into the rapids. In those inevitable whitewater situations, the importance of trust should not be underestimated. As Stephen M.R. Covey says in his book "The Speed of Trust":

“It [trust] is the one thing that changes everything. If you promote a high-trust environment where you have capable people who do what they say they are going to do, in my experience, anything is possible. If there is not a high-trust environment in place, virtually everything, including the most mundane activities, can feel like an ordeal for the group and impede progress. Over time, I have found that trust, based on competence and character, trumps all other attributes.”

Is Your Organization a High-Trust Environment?

A lack of trust in an organization can manifest itself in a multitude of artifacts and patterns:

Deadlines and forced commitments (instead of targets and goals) Roadmaps are created but hardly ever updated (instead of product visions that are combined with inspect and adapt) Waterfall over the wall / it’s not my job / us and them / barriers / silos (instead of collaboration / cross functionality / build / measure / learn) Individual KPI’s imposed from above (instead of team-selected accountability systems) Manager / subordinate performance reviews and stacked ranking (instead of 360º feedback and team / peer reviews) Small “Inner Circle” of communication / information / lack of transparency in “leadership" (instead of transparency and a circle of safety which extends to the “outer edges” of the organization) Focus on performance by numbers, burndowns and velocity (instead of a people-first approach which focuses on inner work life, team happiness/morale, OKR's, delivery of value and outcomes instead of outputs) Lack of mutual respect & transparency / leadership relying on “authority” / back channel communications / disengaged workforce / fear (instead of individuals and teams giving it their all with no holds barred)

Observations on the presence of the above artifacts and patterns are generally qualitative. If you’re more of a quant, take a look at the following two-part assessment that any organization or team can conduct. It comes from Pollyanna Pixton’s book "Agile Culture".

Assessment Part 1: Leadership

The first part of the survey measures leadership’s trust in their team.

Prompt: As a leader, indicate a score between 1 and 10 which response best reflects where you are for each row in the table:

Low (1-3)

Medium (4-7)

High (8-10)

Score

I trust no one on my team.

I trust some of my team.

I trust my entire team.

 

I require that everything must be defined before the team can do anything.

The big things, such as cost, schedule, and scope, must be defined before the team can do anything.

I honestly accept and allow genuine ambiguity and uncertainty from my team.

 

My team cannot take risks without my approval.

I let my team take risks – but only when the risks are low.

I encourage my team to take risks in order to deliver value more effectively.

 

 

 

Average (total / 3)

 

Results: Average individual scores, and then average those across the organization. This will tell where leadership believes it is on the Scale of Trust (max = 10)

Assessment Part 2: Team Members

The second assessment gets to the roots of how team members feel about the level of trust coming from leadership.

Prompt: As a team member, indicate a score between 1 and 10 that best reflects how you feel about each row in the table:

Low (1-3)

Medium (4-7)

High (8-10)

Score

I have to get permission to do anything.

Managers and processes sometimes get in my way.

I am trusted to do my work.

 

I am told what to do and how to do it.

I can sometimes find my own solution.

I am trusted to always be able to find my own solution.

 

If I don't do things the approved way, I am at risk.

There are certain low-risk things I can do.

I can take chances without feeling at risk.

 

I always must give the organization exact numbers.

I sometime can tell the organization when I am uncertain.

I can honestly tell the organization when I am uncertain without risk.

 

 

 

Average (total / 4)

 

Results: Average individual scores, and then the scores across all team members. This will reveal the team’s position on the Scale of Trust. (Max = 10)

What is Revealed? Compare both the leadership and the team member overall averages. Is there a gap? (If leadership and team scores are identical, then congratulations, everyone shares the same view!) How close to “10" are the final scores? Is there anything the organization can do to raise the score?? (If your scores are all at 10, share the secret sauce, please!)

If there is a gap between the averages of Part 1 and Part 2, this indicates a cultural disconnect honesty and openness.

On the other hand, low scores on both Part 1 and 2 indicate a different kind of problem: a known lack of trust on an organizational level.  As Ricardo Semler asks in his book "The Seven-Day Weekend" 

“If you don’t trust the people on your team, why are they on your team? For that matter, why are they in your organization?”

Running Pixton’s assessment will require a leap of faith. After all, agile doesn’t promise to fix anything, it just promises to bring the organization’s issues to light.

Point the Boat in the Right Direction

If there is a significant gap between the team and leadership assessments, or if the overall level of trust is low, ask yourself the following questions:

Can folks have an open discussion about causes for conflict that center around trust? Can leaders and team members develop a shared understanding of their expectations around trust? Can anyone generate new practices and agreements regarding trust? Understand What Trust Looks Like

Here’s the good news: there are various tools and exercises that can help guide the way by showing teams and leadership how to paint a picture of what “trust” means to them. 

Alexey Pikulev has run numerous divergent exercises over the years with agile teams to explore elements that influence trust. He has identified the following most frequently occurring themes:

Clarity Connection Compassion Value Competency Commitment Contribution Consistency Paint a Picture

Pikulev has put the above themes together in the form of a “canvas” that teams can use to paint a portrait of what trust means to them:

To get started, participants can begin adding items to each theme. They can fill out of the canvas in a couple of different ways:

Silent brainstorming on all the themes Rotating flip charts with one group per theme

I’d like to add two of my own suggestions to Pikulev’s approach. The first comes by way of Jurgen Appelo and his ideas from Management 3.0: as the participants are filling out the canvas with specific items in each theme, they should consider four discrete aspects for each theme:

Trust from leader(s) to the team (Part 1 assessment) Trust from the team to leader(s) (Part 2 assessment ) Trust among team members Trust in oneself

The second suggestion I’d like to add is that participants label each item with either a “+” or “-,“ thus creating a force field analysis where “+" indicates driving factors (catalysts/nourishers) and “-" indicates restraining factors (toxins/detractors) with regard to trust.

Once the canvas or flip charts have been populated with ideas, the participants can group and converge the items. They then run a voting/ranking exercise based on two characteristics:

Importance: Rank the relative importance of each converged item via dot voting Influence: Rank the team’s ability to impact a change in each converged item

At this point, participants will have constructed a pretty clear image of what “trust” means to them. They should have a firm grasp on the following:

Things that add to trust and things that take it away What factors are collectively important for creating trust What the team feels is within their current sphere of influence to change, and what they feel is outside their control Avoid Scylla and Charybdis via Ownership

In light of the results of both the trust assessment (which shows where things currently are) and the trust canvas (which shows where things could be), what kind of picture emerges? Have areas of current or future conflict reared their heads?

Often, the important issues need to be resolved through a change in delegation and a realignment of ownership. However, big gaps in ownership and trust are likely to change only with intervention from powerful allies within the organization. Instead, explore things through the lenses of “start, stop and continue” or “keep, add, less and more” (or any other retrospective technique). Collectively come up with safe-to-fail experiments,  gradually nudge the delegation levels deeper and deeper into the team, ensure continuous feedback, honor the prime directive and always inspect and adapt.

In short, don’t be afraid to set sail the agile way -- you're sure to make it past the treacheries of a transformation without losing any crew.

Enjoy the Journey

The right kind of organizational environment – one that is filled with mutual and ever-growing trust, ownership and vision – creates a palpable flow of energy and innovation. It fosters teams that can respond quickly to changing currents and obstacles, and enables a voyage where everyone knows and owns the results of their efforts.

It results in a productive and joyful journey that delivers delight not only to an organization’s customers but to all members of its crew as well.

And that is the promise of truly embracing agile.

 

Agile Tips for Working with Non-Agile Teams

During agile training, we’re taught that everyone in our team should operate within the agreed upon agile framework. However, the question remains: how should we operate when interacting with less predictable teams outside of our own?

Once we get into the agile groove, it’s easy to feel complacent. After all, we’re pushing along at a productive pace and delivering shippable features iteration after iteration. Having all our team members working together with the same principles, methods and frameworks is very comforting – so comforting, in fact, that we might be afraid to operate in any other way.

On the other hand, the world beyond our nice little agile haven is a terrifying, stagnant realm filled with waterfalls leading nowhere and rigid, outdated plans that bend the laws of time. It’s easy to fear interaction with the scary, non-agile world, and it’s also easy to get frustrated when our colleagues or customers don’t have the same liberating habits that we do.

However, for many of us it’s impossible to avoid working with non-agile teams completely – and, as a matter of principle, we shouldn’t refuse to work with others before giving them a fair shot. I’d be willing to bet that almost all of us have, at some point, been required to collaborate with an internal or external party that has little to no agile training, let alone any kind of certification.

While you may be unlikely to suddenly convert the other side to an agile framework overnight, there is still hope. To help you smooth the edges of these sometimes-difficult interactions, here are a few simple, agile tips for working with non-agile teams.

Try Simple Prioritization

If I had to prioritize my advice, I’d prioritize prioritization. The internet is filled with prioritization templates and agile prioritization templates, but you might want to start with something simpler.

If you’re working with an external customer, chances are you can’t afford to exclusively accept agile customers while telling the rest to find someone else to throw their money at. Similarly, if you’re working with a non-agile party internally, you may be equally unable to control their level of agile training.

One of the most common problems faced by non-agile teams is unmitigated scope creep in the form of numerous concurrent requests with limited direction in regards to priority. In this environment, almost everything seems important, and by the way, why didn’t you finish this other important task over here?

Well, as we all know, the answer to that question is that we were busy finishing a more important task that had a higher priority. But, can we pinpoint how that priority was determined in the first place? If the customer isn’t prioritizing their own requests, then your team will be doing most of the decision-making independently (with some level of external input, of course). The more your team prioritizes on its own, the less customer collaboration takes place – and, as we already know, customer collaboration is an important value in agile.

When dealing with a non-agile customer or colleague who does a poor job of conveying the priority of a task relative to other concurrent requests, it’s usually easy to quickly summarize a bulleted list of the current requests and ask the customer or colleague to rearrange them in order of priority. Without realizing it, they’ll start forming their own prioritized product backlog.

Want to take it a step further? Try using one of the many agile prioritization matrix templates available on the internet. I personally like to keep things as simple as possible, but for a larger project and a larger scale of requests, having additional structure may be helpful to some teams.

Emphasize Progress in Iterations

Some people get spooked when you show them early iterations designed to tackle shippable increments. For many non-agile folks, their instinctual reaction may be something along the lines of, “where’s the rest of it?” or “yes, but we still need x, y and z…” and so on.

In these situations, it’s important to explain the advantages of delivering through iterations. Remember, these colleagues or customers may have never used iterative approaches in their careers, so what seems obvious to us may be an uncomfortable shock for the uninitiated.

The advantages of iterative approaches are numerous, but here are some highlights which might help you to convince non-agile colleagues or customers of its practicality:

Frequent demonstration of features and progress Frequent feedback and communication, which improves subsequent iterations Less likely to deviate from desired outcome Product can adapt to change quickly A cross-functional team can quickly shift resources as needed

You might not be able to get the non-agile party to obey a Scrum Master without question, but explaining the value of iterative and incremental development can plant the seeds of agile and ultimately pay off in the long run.

Suggest User Stories Before Solutions

Another pitfall for many non-agile colleagues and customers is the tendency to jump to a lengthy, prescribed solution without clearly and thoroughly explaining either the actual user need or the problem that needs to be solved. Rather than putting forth well-defined user stories that lead to constructive collaboration, this approach can often lead to the dreaded iterative waterfall that isn’t agile at all.

However, before you can expect a non-agile collaborator to write well-conceived user stories, you’ll first need to explain what user stories are and what their value is to the customer. Since the agile team needs to know what problem their work should be solving before they can build an effective solution, it’s in the customer’s best interest to write user stories that answer the “why” as extensively as possible before getting into too much of the “how.” Starting to develop the solution without clearly understanding the problem at hand is rarely a good idea in any setting, and the same holds true for your colleague or customer’s planning process.

Notice a Pattern?

When it comes to working with non-agile collaborators, the best way to ensure buy-in is to explain the value of agile processes. After all, why should someone be expected to adopt your methods if they haven’t yet seen how those methods can benefit them?

Prioritization, delivering over iterations and writing well-crafted user stories are just a few of the ways you can make your collaborative process more comfortable and effective when working with non-agile folks.

What are some of the challenges and solutions you and your team have noticed while collaborating with non-agile parties? What worked, and what didn’t work? Share your story in the comments section below.

 

 

The Role of a Product Owner (Part 4): Pragmatic Considerations

In this series of posts, I have covered responsibilities, characteristics, daily activities and anti-patterns of product owners. In this final post, I wish to summarise a few pragmatic considerations of the role.

The product owner is the single neck on the block, and is responsible for setting the direction for development as well as making hard decisions in the interest of driving value creation. They work in close collaboration with stakeholders, customers, the Scrum Master and the development team daily.

Filling the Product Owner Role

Unfortunately, experienced product owners are hard to come by in many organizations. For this reason, existing employees will typically be expected to fill the role. The two employees who are most likely to make that transition are:

Project managers: PMs can serve as effective product owners by using their financial, people, planning and organisational skills to oversee domain knowledge and product backlog management. The ability to shed any command and control tendencies in exchange for a “one-team, one-dream” mentality will also help to smooth the transition. They will usually require assistance from a business analyst to manage the product backlog.

Business analysts: With their strong product knowledge and solid customer relationship skills, BAs also tend to transition well into a product owner role. They will often require a project manager’s support, particularly when it comes to stakeholder management and financial modelling.

Developing as a product owner takes time, so a “product owner team” comprised of both a project manager and a business analyst is often employed to provide the project with a secure foundation. This allows both the PM and BA to learn from each other for the duration of a project (or product development life cycle), and thus develop more rounded skills than they would have otherwise.

A Careful Balance

A product owner must carefully balance customer outcomes against business value while simultaneously considering both technical debt and team morale. This requires deliberate coordination between many elements within the project, including other teams, suppliers, business departments, customers and users.

Another necessary consideration is the widespread organisational change required to support agile development. Although this change begins with small Scrum teams, it quickly expands to encompass the entire concept-to-cash life cycle of a product. Of course, changing the finance, legal, HR and PMO departments of an organization can be a lengthy process, but agile requires--or perhaps causes--rapid cultural transformation.

Conclusion

Thank you for reading this series of posts. It has been an interesting exercise to open my thoughts on Scrum roles to challenge and discussion, and I hope they have proven useful to you in some small way. If you have any opinions or observations on this series, please feel free to share them in the comments section below.

If you’re interested in learning more about product ownership, I recommend the following five books:

“Succeeding with Agile” by Mike Cohn  “Strategize” by Roman Pichler  “Agile Product Management with Scrum” by Roman Pichler  “Essential Scrum” by Ken Rubin  “Product Mastery" by Geoff Watts 

Is Kanban Always a “Pull” System?

The pushmi-pullyu (pronounced “push me-pull you”) is a fictional creature in “The Story of Doctor Dolittle,” which is described as a cross between a gazelle and a unicorn.

Recently, I was talking with a fellow software professional about some issues he was having implementing Kanban, and the pushmi-pullyu came to mind. Allow me to explain why.

Kanban’s Popularity

Kanban is the most popular agile approach after Scrum, according to the most recently published State of Agile Survey. Scrum is, of course, massively dominant.

Only 5 percent of respondents described their teams as Kanban teams, while three-quarters used either Scrum, a Scrum hybrid or Scrumban. However, when asked what techniques they used, nearly four in every 10 teams said that they use Kanban boards.

This is might be an exaggerated figure since, in my experience, many people confuse Kanban boards with Scrum boards. They look similar, but have very different purposes.

While a Kanban board maps a value stream for the lifetime of the product, a Scrum board is a visualization of a sprint backlog, and is reset at the beginning of every new sprint.

Additionally, the Scrum board is owned by a single Scrum development team, while Kanban is agnostic about who owns the board. These differences turned out to be at the heart of the issue that my colleague raised with me.

Origins

Kanban means “signal card” in Japanese, but it was by observing the processes at work in U.S. supermarkets in the 1940s that Taiichi Ohno was inspired to include the technique in what later became the Toyota production system.

From there, the Toyota production system gave birth to lean manufacturing, which spawned lean software development.  Kanban in software emerged from this bloodline.

The core idea of Kanban is that no downstream process is sent additional work from upstream unless it has displayed a visual signal that it has the capacity to handle that work. 

Kanban signals are weapons used to eliminate the waste of inventory, such as work items that are queued or waiting to be processed.

WIP

Kanban (in software) implements this approach through the use of explicit work in progress (WIP) limits for each value-added stage in the workflow. These WIP limits are shown on Kanban boards, and are their most recognizable characteristic.

If, for example, there is a WIP limit in testing of five tickets, then whoever is responsible for testing should not accept a sixth ticket unless and until the number they are currently working on drops below five.

As a result, anything that is blocked tends to clog the entire pipeline. If enough tickets get blocked, then the entire value stream will grind to a halt. Then, everyone in the process gets involved in unblocking the pipeline and restoring flow. At least, that’s the idea.

Used properly, a Kanban system is a “pull” system where demand and capacity are balanced using explicit WIP limits. Scrum is also a “pull” system, in which a development team pulls a small batch of work into the sprint based on its estimate of how much work it can complete in the given timebox.

Scrum works because the team is self-organising. No one can tell the team how to do its work, or dictate how much work will be completed in a sprint.

Push vs. Pull

However, Kanban does not demand that a team be self-organising, and each value-adding stage (each column on the Kanban board) might reflect the work of a different team. So, the question is: Who sets the WIP limits? Again, Kanban leaves that open to interpretation.

In my colleague’s case, management set the WIP limits on the board. When the workflow got blocked in one particular area, managers came up with the “solution” of raising its WIP limit.

Of course, this solved nothing. In effect, management just told the team concerned to work harder. Thus, what was intended to be a “pull” system instantly transformed into a “push” system.

Now, this isn’t to say that I’m knocking Kanban. I’ve worked with a number of Scrum teams that use Kanban boards to good effect. But, in every case, it was the teams that set the WIP limits, which removed the temptation of managers to bully the team into doing an inordinate amount of work.

There’s no magic involved in Kanban boards, or in Scrum boards for that matter. Both tools simply serve as a visualisation of the work in progress. It is what you do as a result of what you see on the board that matters.

To me, the idea that you can achieve genuine agility without self-organising teams is just as fictional as Dr. Dolittle’s pushmi-pullyu.

 

 

 

 

 

Agile Transition Strategy

In May 2015, I attended Jeff Sutherland’s “Getting to Done” presentation at the DC Scrum Users Group meetup. During his presentation, two things really grabbed my attention.

The first was the Standish Group’s 2011 CHAOS Report, which revealed the percentage of successful, challenged and failed projects using either waterfall or agile methodologies. The second was Sutherland’s statement that “as larger companies adopt Scrum, the percentage of successful agile projects will drop.”  

For the purposes of their report, the Standish Group defined project success as being delivered on time, staying on budget, and reaching completion with all planned features intact. In their 2015 CHAOS Report, they published their findings on the state of waterfall and agile projects that were conducted from FY2011 through FY2015. The results of that report are shown in the table below.

Overall, successful agile projects only dropped by 3 percent, while challenged projects increased by a corresponding 3 percent. However, the more startling statistics begin to become apparent when looking at the success and failure rates of small projects versus those of large projects. 

Small agile projects were approximately three times as successful as large projects, while the failure rate of large agile projects was almost six times greater than that of small agile projects.

In light of this data, the question remains -- why is this happening?

My thoughts are (1) large organizations are feeling the pressure to adopt agile methodologies and do it quickly for fear of being left behind by their competition, (2) large organizations tend to underestimate the level of commitment and effort it takes to successfully transition to an agile environment and (3) they fail to realize that a successful transition is not going to happen overnight.

So, if small agile projects are three times more successful than large agile projects, why not incorporate the advantages of small projects into your organization’s agile transition strategy? Why not transition to an agile environment using a series of small transitions and rolling wave planning?

The advantages of doing so include not taking on the entire organization all at once, spreading out the cost over a longer period and having the freedom to make initial mistakes on a smaller scale with little to no large-scale repercussions. And, as you learn more, each subsequent transition will naturally progress more smoothly than the one before it.

When planning the transition series, consider the composition of your organization’s population. Every organization has three major profile types within its population. 

Those three types are:

Early adopters: These are the kindred spirits who are most receptive to moving forward with new and innovative methods. The silent majority: The mainstream folks who need to see solid evidence of success before embracing a new way of working. The Resistance: Those who are decidedly in favor of the status quo and are neither interested in nor comfortable with change. Their favorite quote is likely to be, “But we’ve always done it this way!”

Execute your strategy in the same order, starting with the early adopters. As you execute your transition, make sure to capture pre- and post-transition metrics as well as the user experience for each project. Then, make sure each project success is widely publicized and that the people who worked on those projects are recognized. 

Repeat this process for each profile type. This will give you the opportunity to build your case for transitioning to an agile environment while simultaneously fostering ground swell.

Using a transition strategy that incorporates this approach lets the organization publicize the fact that they are successfully transitioning to an agile environment, while doing so in a manner that will allow both the organization and its people to truly reap the benefits of a real agile environment rather than an environment that is “agile in name only.”