How Would I Know How Badly We Are Losing Out Through Sub-Optimal Software Development?

Scope of this Report

Every company wants to maximize its profits while meeting its customer expectations. The primary purpose of software delivery is to provide a product to the customer that will validate a business idea, and ultimately provide value to the end-user. There must be feedback between the customer and the business, and this iterative process must be performed quickly, cheaply and reliably.1 The real question is how does an organization know whether its software delivery is performing at optimal levels?

This report considers the following topics:

  • What is sub optimal software development?
  • How would you know if your performance is sub optimal?
  • How do we measure for optimal development?

What is Sub-Optimal Software Development?

The purest definition of sub-optimal is “being below an optimal level or standard”. However, in the information technology (IT) organization, the development life cycle is characterized by multiple facets, each having its own ‘optimal level or standard’. Sub-optimal software development delivers less value than possible. Unfortunately sub-optimal, like beauty, is in the eye of the beholder and therefore can be very different based on context.

A sub-optimal development lif cycle is generally characterized by one of more of the following: cost overruns, poor time to market, excessive and/or critical defects, or low productivity. To any particular organization, one or more of these factors would signal sub-optimal software development.

How Would You Know if Your Performance is Sub-Optimal?

A sub-optimal software delivery process can manifest itself in a variety of ways. The most evident from an external perspective is customer satisfaction whether this is based upon an emotional response to the success or failure of the delivered software or an objective assessment based on testing or value for money. Mediocre quality or time to delivery will surely cause a response on the part of the consumer or client regardless of the reasons for the mediocrity. However, from an internal perspective, it has been observed that there are at least three scenarios that apply.

First we have the organization that doesn’t recognize that their software delivery process is sub-optimal. An example of this would be a company who is experiencing a solid bottom line and reasonable customer satisfaction. Or, a company leading the current technology wave and doesn’t see an immediate decline in their near future. In either case, while they may not be ‘sub-optimal’ in the usual sense of the meaning, they may not be the ‘best that they can be’. Since the first step towards improvement is to recognize there is an improvement to be made, there is a level of awareness that much be reached before this type of organizational environment can progress. In these two companies, the “awareness” may be to simply gain or keep the competitive advantage.

This next dynamic shows itself, not so subtly, when management doesn’t really want to address the software delivery process at all; they simply want the software delivered when they want it delivered.

How many times have we seen a situation where senior management has requested a software solution that has a fixed delivery date already attached to it? And they really aren’t interested in any type of response from the project manager unless they are told what they want to hear. In this type of management environment, the IT organization doesn’t invest much time in their delivery process because they don’t realize the power of good governance as a vehicle to properly manage the project and/or their customer’s expectations.

This third perspective involves an organization that wants to improve its software delivery capability but is unwilling or unable to make the resource investment to make necessary improvements.

Experience shows that lifecycle contributing factors can be numerous: an unrealistic schedule, ambiguous user requirements, the availability of appropriate resources, excessive defects and/or testing, etc. However, in this scenario, the visible issues may seem overwhelming or the root causes too obscure to be able to come up with a viable solution.

Regardless of how the sub-optimal performance manifests itself, the best way to determine if it exists or how pervasive it is, is by executing a benchmark. According to Financial Executive, benchmarking is one of the highest used and most successful management tools used by global senior executives. The purpose of a benchmark is to improve decision making and resource management in order to quantifiably impact a company’s bottom line.

“Benchmarking is the process through which a company measures its products, services, and practices against recognized as leaders in its industry. Benchmarking enables managers to determine what the best practice is, to prioritize opportunities for improvement, to enhance performance relative to customer expectations, and to leapfrog the traditional cycle of change. It also helps managers to understand the most accurate and efficient means of performing an activity, to learn how lower costs are actually achieved, and to take action to improve a company's cost competitiveness.”2

According to C.J. McNair and Kathleen H.J. Leibfried in their book, “Benchmarking: A Tool for Continuous Improvement”, some potential "triggers" for the benchmarking process include:

  • quality programs
  • cost reduction/budget process
  • operations improvement efforts
  • management change
  • new operations/new ventures
  • rethinking existing strategies
  • competitive assaults/crises

Any of the triggers above could certainly have been influenced by sub-optimal development.

In IT benchmarking, there are several options, any of which would be appropriate in addressing sub-optimal performance depending on the causal analysis desired. Horizontal benchmarking (across multiple teams), vertical benchmarking (across certain processes or categories), infrastructure benchmarking (data centers, networks, end-user support) or strategy benchmarking (information technology strategy or business-technology alignment) are some of the types used. The most common benchmark is the ADM software development benchmark.

The key factors that are addressed in an ADM benchmark are cost, time to market, quality and productivity. While benchmarking will identify good practices and successes, it is most beneficial at highlighting sub-optimal activities. These include inefficiencies and problems in methodology, staffing, planning, productivity, cost or capability across sizes, types & technologies. In addition, improvement actions are proposed. In many cases, a benchmark can also identify the probability of successful delivery against time, budget & quality targets – and propose alternative scenarios with higher likelihood. Other measures typically provided are your internal rate of return/ return on investment (ROI) and estimated tech debt – how much is being spent on the ratio of development to maintenance. Either can be key indicators of sub-optimal performance.

There are other benefits of benchmarking (listed below). Benchmarking …
... provides an independent, measurable verification of a team’s capability to perform against time and cost parameters by an objective 3rd party;

... signals management's willingness to pursue a philosophy that embraces change in a proactive rather than reactive manner;

... establishes meaningful goals and performance measures that reflect an external/customer focus, foster innovative thinking, and focus on high-payoff opportunities;

... creates organizational awareness of competitive disadvantage; and

... promotes teamwork that is based on competitive need and is driven by concrete data analysis, not intuition or gut feeling.

In summary, benchmarking would:

  • show you how you stack up against others and how you are performing internally;
  • act as a catalyst for change by setting realistic improvement targets; and
  • provide a path for the company toward optimal software practices.

How Do We Measure for Optimal Development?

Ultimately, the benchmarking exercise is to enable executive management to improve the performance of your software development using data-driven decisions to prioritize improvements. While the benchmark provides an evaluation of existing methods and outcomes against industry standard best practices, it also produces a gap analysis, producing recommendations for maximum return on investment (ROI).

The next step in the solution to software process optimization includes using a structured road map which includes the development of strategic goals based upon the benchmark results, and team analytics that are mapped to and support the strategic goals. From the road map exercise, scorecards and dashboards are developed for feedback to management.

The scorecard will combine an organization’s overall business strategy with the strategic goals set by the road map. These factors and the targets associated with them will reconcile to the desired state and alerts can be set up to identify situations whereby targets will not be met to enable future proactive actions. Generally, the scorecard is used to focus on long term solutions.

The formal definition of dashboards includes the identification and management of metrics within an interactive visual interface to enable the continual interaction and analysis of data. A dashboard is suited to a shorter cycle, or snapshot approach by providing varying types of visualizations to enable quicker decision making by showing charts, graphs, maps and gauges, each with its own metrics. A dashboard may be the visualization of the scorecard, or there may be hybrids of both.

Conclusion

Benchmarking and metrics modeling are the primary tools in recognizing and addressing sub-optimal development delivery to enable a company to become or stay competitive. By using the road map approach, the measurement and presentation of data for management use is key to recognizing and supporting optimal development processes.

Sources:

  • 1Dave Farley on the Rationale for Continuous Delivery; QCON London 2015, March 8, 2015.
  • 2Reference for Business, http://www.referenceforbusiness.com/management/A-Bud/Benchmarking.html.
  • “Benchmarking: A Tool for Continuous Improvement,” C.J. McNair and Kathleen H.J. Leibfried, 1993.
  • “Measuring Success - Benchmarking as a Tool for Optimizing Software Development Performance”, DCG Software Value (formerly David Consulting Group), 2015.  “A Closer Look at Scorecards And Dashboards”, Lyndsay Wise; April 27, 2010.
  • “Why Can’t We Estimate Better?” David Herron & Sheila P. Dennis, 2013.
Written by Default at 05:00

Why Should I Have More Than One Technique for Retrospectives?

Scope of This Report

Retrospectives are part of most methodologies, even though there are many different terms. For instance, most waterfall frameworks call them post implementation reviews or postmortems. Each methodology focuses on different nuances. Agile, as a macro set of frameworks, has more aggressively embraced retrospectives than waterfall or iterative frameworks.   

Retrospectives in Agile reflect the adoption of the principle of kaizen (Japanese for improvement, often interpreted as continuous improvement). They should be focused on discovering what will make the team or organization deliver more value.  

Brian Wernham, in Agile Project Management for Government noted the UK DirectGov project used retrospectives to mold how the worked in order to maximize delivery productivity. While many retrospective techniques posit the questions “what worked well” and “what did not work,” the real reason to do any retrospective is to identify, agree on and plan for what can be done better.  
The exact process any team uses is a reflection of the technique the team wants to use, what works in the organization and the specific team situation. For example, the timing of retrospectives varies significantly depending on the framework and the organizational culture.  Most waterfall projects do a retrospective at the end of the project (or release), while Agile projects typically do retrospectives at the end of every sprint, at each release, at the end of the project and occasionally on an as needed basis.  In Agile, retrospectives occur when change can actually be applied to the project to impact the current delivery.

Obstacles

The power of a retrospective to improve a team’s ability to deliver business value is hard to deny. Given the demonstrable power of the technique, why does it occasionally fail to live up to expectations? 

Ritualization:

Ritualization can dramatically affect the value of retrospectives. Ritualization can cause the team or organization to enter a downward spiral of disillusionment that will inevitably end with the abandonment of the technique.

The ritualization of retrospectives occurs when the process becomes more important than (or at least as important as) the results.  There are two typical reasons that cause ritualization: overcommitted teams who don’t have time to reflect and boredom (wake me up when it's over). Gil Broza in The Human Side of Agile notes that” Works Well and Needs Improvement format gets really old quickly.” Teams that are so overburdened and can’t find a mechanism to get un-overburdened will always stay that way (a “Catch 22”). The ritual of the retrospective will usually be fulfilled so that they team can start planning the next sprint or iteration.  In essence, they need to check the process box so they move to the next step.  

The Scrum Master or coach needs to help the team address the root cause of the problem, whether that is team-driven over-commitment (taking too much work) to being told to take too much by management.  If a team is in an over-committed position more than occasionally, the Scrum Master may be part of the problem. That means that outside coaching is needed. If the root of the problem is technique boredom, the Scrum Master or another team member should learn another technique (such as timelines, the Sailboat, de Bono’s Thinking Hats or the 4 L’s).  All Scrum Masters should know at least nine techniques for retrospectives. 

Process:

A basic process for a typical Agile, end-of-sprint retrospective:

  • Set Up: First, create a safe atmosphere (review Norm Kerth’s Prime Directive with the team). Then ground the team by focusing on the current sprint’s results (for example review the Burn-down Chart or have the team develop an annotated sprint timeline). Time box this part of the retrospective to no more than 20 minutes for a two week sprint.
  • Idea Generation: Encourage the team to dig in and capture the details.  For retrospectives focused on process or flow, use sticky notes to brainstorm, followed by mute mapping to group (affinity diagraming). For team or personnel issues, use storytelling. For example, have subsets of the team describe a fictional scenario based on real life problems and how they would solve the problem. Consider direct discussion as an alternative. This step should be time boxed to 30 minutes for a two week sprint.
  • Insight Development: Once the idea generation step is completed, the team reviews the data and comes to a consensus about what it means. One method of analysis is to look for patterns and to determine if there are trends in this stage.  The goal is to recognize if there is a problem so you can start to resolve it.
  • Identify An Improvement Objective: In many cases a team might have identified a number of ideas for improving their productivity. Focus on the top one or two actionable big wins. The rational for not fixing everything is first that the time need to fix the problem will come from the team’s capacity to deliver business value (there is only so much capacity that the team has at its disposal).  Secondly, if the remaining issues are really problems after the one or two most important have been dealt with then the team can decide to address them during the next iteration. Also, trying too many changes at once makes it hard to track cause and effect.  This continuous incremental process improvement is one reason team productivity, aka velocity, typically increases from iteration to iteration.  After the team selects the issue (or issues) to be tackled, have them add it to the next sprint backlog so that it gets addressed.  This step should be time boxed to 30 minutes for a two week sprint.
  • Wrap-up: Spend 5 – 10 minutes reviewing the session so that the next retrospective will be even more effective.

Retrospectives are a tool that the team uses to identify what they can do better.  The basic process - making people feel safe then generating ideas and solutions so the team can decide on what they think will make the most significant improvement - puts the team in charge of how they work.  When teams are responsible for their own work, they will be more commitment to delivering what they promise. The retrospective process is focused on increasing the team’s capacity, rather than trying to generate lessons learned for the next project.

Even though there are many different techniques for executing retrospectives, many teams find one or two techniques they like, and then they ride that horse until it collapses.  Every Scrum Master and team should have a broad array of retrospective techniques, such as the sailboat technique, the Four L’s or the timeline.  This provides at least two benefits. First, knowing many techniques means that you can match the technique to the particular teams. For example, many techniques use physical sticky notes, which are difficult for distributed teams. So, the Scrum Master needs to know that you can substitute an on-line mind-mapping tool for sticky notes.  Second, having a wide range of techniques (and using them) is a formula for beating technique fatigue and the resulting obstacles. 

List Generation Techniques

List generation techniques are the most popular class of retrospective techniques.  The list generation techniques are popular because they take very little set-up, are easy to explain, easy to facilitate and get results. Listing techniques build on well understood brainstorming techniques to ensure the whole team has a voice.  We discussed the basic Affinity Diagraming technique above.
Another technique in the listing category would be the “Sailboat” technique.  This method uses a nautical metaphor.  The boat moves through the water toward a goal (the team delivering functionality), the wind pushes the boat forward.  As the boat moves through the water, it List generation techniques are the most popular class of retrospective techniques.  The list generation techniques are popular because they take very little set-up, are easy to explain, easy to facilitate and get results. Listing techniques build on well understood brainstorming techniques to ensure the whole team has a voice.  We discussed the basic Affinity Diagraming technique above.

Another technique in the listing category would be the “Sailboat” technique.  This method uses a nautical metaphor.  The boat moves through the water toward a goal (the team delivering functionality), the wind pushes the boat forward.  As the boat moves through the water, it encounters resistance which slows its progress. Examples of resistance might include conflicts for needed resources or conflicting organization goals. Here is the process:

Set-up: Start by drawing a picture of a sailboat in the water on your white board or flip chart. Explain to the team that some things push forward, like the wind, and some things slow your progress down, like an anchor.

Idea Generation: Ask the team to identify what those items were.  List one item per sticky note, which are then placed on the boat.  As a facilitator, continue to tweak the seed questions you are using to keep the team thinking about the sprint from different angles.  You are done when the team is done.

Insight Development: Have the team review the data and group ideas based on how they see the relationships between individual ideas. Techniques like Mute Mapping (grouping without talking) help to maximize team participation while minimizing the chance of a single person dominating.  Once the grouping is done, ask the team to name each group. This helps to cement the group’s understanding of the groupings of ideas that they have generated.

Identify An Improvement Objective: Select a group or specific idea to fix.  There are a number of techniques to select the improvement objective. Discussion followed by group consensus is one method (use this when it is apparent that the group is close to consensus).  Another method is to vote using dots or post-it flags. In this method give each member a fixed number of flags and then ask them to vote (they can use all votes on one item or spread them).  The item or group with highest number of votes gets fixed first.

Examples of other listing techniques include:

The Four Ls – Use four categories: liked, learned, lacked, and longed for to generate ideas. Write these titles on four flip charts and place around the room.  Have each person silently generate ideas based on those categories.  When the team is done (i.e. everyone stops writing) have the team place their ideas (written on sticky notes) on the appropriate flip chart. Once the team has come up with their lists, identify the improvement objective, usually from the lacked or longed for category.

What Went . . . – Use four flip charts, put one of the following titles on each flip chart: what went well, what did not go well and what should we do more of and what should we do less of.  Brainstorm ideas to put on each flip chart.  Put one idea or statement on each sticky.  Depending on the group, this method can be done non-verbally (everyone puts their ideas on a set of “stickies” like the Four L’s) or have the team write ideas down and then shout them out (more akin to classic brainstorming). Insight development and identifying the improvement objective would follow a similar path to what was described above.

There are many other listing techniques each using a different set of seed questions (e.g. What worked well? or What would you like to do more of?) or different metaphors (e.g. sailboat, motorboats or trees). The questions or metaphors exist to help the team focus their discussion.  The metaphor or seed questions that are used need to make sense to the team’s culture, and also solicit areas that they are concerned about or can be improved. The Scrum Master or facilitator needs to use their observations about the team to select the retrospective technique that will provide the greatest benefit. All of these techniques can work, selecting which you will use is matter of team culture.

Other Techniques

There are other, more specialized techniques like the Timeline Retrospective, which is useful for long-running releases or in projects were a retrospective has not occurred in recent memory. These techniques deal with more complex issues than can be tackled using simple lists.  These more complex methods can also be used to spice up a more basic fare of listing techniques to keep teams involved and interested in the retrospective process.

These techniques are more complex to execute.  Let’s explore a few examples of this class of retrospective.

The Timeline Retrospective uses the following process:

Goal: The Timeline Retrospective technique develops a visual overview of the events that occurred during the period under investigation.  This technique identifies and isolates the events that impacted the team’s capacity to deliver over a set period of time. It uses distinct colors to identify events (avoid typical red – green colors as color blind participants may have difficulty).

When To Use:  The Timeline Retrospective is useful for refreshing and re-grounding the memories of team. Other circumstances in which this may be a useful technique:

  • If there have not been any intermediate retrospectives;
  • To provide context to program-level (i.e. multiple projects) retrospectives;
  • If the team has not been working on the project over the whole life cycle, and
  • An end of project retrospective.

Set Up: Draw a timeline that represents the period since the last retrospective on a white board (or several pieces of flipchart paper).  Make sure there is room above and below the line.  Secure dry erase markers in a few colors and sticky notes in three colors.  The three sticky note colors will represent:

  • Blue represents good events;
  • Yellow represents significant events that are neither good nor bad, and
  • Red represents problem events.

Use the colors that you feel the most comfortable with and that you have in sufficient supply.

The process is as follows:

  • Have each team member silently write down on sticky notes the major events, from their perspective, using the color code from above.
  • Have each team member put their events on timeline chronologically, placing positive events above the timeline, neutral on or near the timeline and negative events below the timeline
  • Throw out duplicates.
  • Have the team select someone to walk through the final timeline.
  • Using the dot voting technique (provide each team member with three dots) rank the event that slowed the project down the most to date.
  • Identify tasks and actions that could be taken to solve the problems. Pick the top two or three.
  • Have the team tell the story of the project for the next sprint or release, if they took the identified actions. This will help validate the choice of the proposed changes.

Another example of non-list retrospectives is the 6 Thinking Hats Retrospective (based on De Bono’s Six Thinking Hats).  Use this type of approach when the team has experienced significant challenges, has not established norms on how to interact or tends to be dominated by one or two personalities.  In this technique, the team uses a structured approach to discuss the period since the last retrospective.  The team “wears” one of De Bono’s “hats” at a time, which means all participants talk about a specific topic area at a time. Each hat represents a particular way of thinking.  Using the hats forces the team to have a focused discussion (this is called collective thinking in the literature). Until you are comfortable with this type of technique, use a facilitator. The facilitator should ensure that the comments are appropriate to the “hat” that is currently being worn. Here is the order of the “hats”:

1. Blue Hat (5 minutes) – focus on discussing session objectives.
2. White Hat (10 minutes) – discuss or identify FACTS or information since the last sprint (e.g. we had a hurricane during this sprint).
3.  Yellow Hat (10 minutes) – talk only about the good things that happened since the last retrospective.
4. Black Hat (10 minutes) – talk only about the bad things that happened since the last retrospective.
5. Green Hat (10 minutes) – talk only about ideas to solve the identified problems or ideas that would add more significant value in the Product Owner’s perception.
6. Red Hat (5 minutes) – Have each team member come to the white board or flip chart and write two emotive statements about the project during this period. Do this fast and with very little preparation. You want gut reactions.

Finally, have the team review the emotive statements to identify clusters of comments or trends that can be combined with the issues in green group.  From the identified issues pick one or two actions that will improve the ability of the team to deliver to add to the backlog for the next sprint.

Other techniques in this class include:

Emotional Trend Line – This is many times combined with the Timeline technique. It provides an estimate of the team’s emotional state since the last retrospective.

Complexity Retrospective – Draw a complexity radar plot with at least five axes. Engage the team to determine what each axis should be labeled (e.g. data, workflow, code, business problem) and then engage the team to rate each axis.  If an axis is rated as complex ask the team to identify actions to reduce complexity.

Non-list based retrospectives are generally more complicated to apply due to the formal structure they use to guide teams toward discovery.  For example the De Bono’s Six Thinking Hats will require active facilitation (at least until everyone is comfortable with the process).  These techniques are generally used to address special or specific circumstances.  The structure of the techniques has been designed (or in some cases these techniques were adopted from other disciplines) because they help to focus the retrospective participants on a type of problem. The goal of any retrospective, list or non-list, is to help the team to discover how they can learn to be better during the next iteration.

Coaching a Retrospective

Facilitation skills, choice of technique and the tools that are used, in that order, will impact the effectiveness of retrospectives. The degree of team distribution will cause the degree of importance of the attributes to vary. For instance, distributed teams will have to lean on communication tools to a greater extent.

At their heart, all retrospectives are social exercises. Even in well-honed teams it is an ongoing challenge to keep team member talking and sharing in a manner that will convey information without damaging relationships. As Naomi Karten pointed out in her interview on the Software Process and Measurement Cast, there are a relatively high proportion of introverts in IT who need help in order to be drawn out. The facilitator’s skill at getting people to interact is more important as the degree of team is distribution increases. In distributed teams, the facilitator needs to find ways to make the team’s interactions more personal. For example, making sure everyone talks and that location bias does not set in. An interesting technique to defeat this issue is to pair individuals from different locations as homework for the retrospective. In one example DCG facilitated, a Scrum Master asked each pair to collaborate and identify five ideas to improve collaboration, while another time (with different sets of pairs) the Scrum Master asked the groups to do a five minute overview on an upcoming local holiday. The goal was to make sure the locations were talking and that the whole team was exposed to the different cultures on the team, which fosters deeper communication.

Different retrospective techniques will evoke different responses from participants. For example, a timeline retrospective will focus on events. A classic list generation-based retrospective will focus on process. Picking the right type of retrospective gives a facilitator the chance at opening up the team. The technique selected for a retrospective is generally a balance between the focus and technique satisfaction (i.e. how many times you have used the technique as over use causes boredom). When coaching long-term projects, teach the team a variety of techniques and then let them select the technique that they want to use. Remember to add techniques or remove techniques from the team playbook as the situation warrants.

Conclusions

Every retrospective requires some sort of tool. Tools can be as simple as a white board and markers or as complex as mind-mapping and screen-sharing software. When a team is distributed, screen sharing and teleconferencing/videoconferencing tools are necessities. The combination of technique and level of team distribution will influence tool selection. Likewise, tool availability will influence technique selection. For example, use a mind mapping tool and screen sharing when executing a listing retrospective for a distributed team so that each location can see the ideas and participate. If the distributed team could not use those tools, you will have to find a different approach. Generally the technique defines the toolset, but that is not always the case. When everyone is in the same room sticky notes are great but when team members are teleconferencing into the retrospective electronics are required.

The retrospective can’t become ritualized to the point that it lacks meaning.  Each retrospective needs to provide a platform for the Agile team to reflect on their performance and to determine how they can achieve more. This is a team activity that requires a free flow of conversation and ideas in order to maximize effectiveness. That means someone needs to facilitate the process and police the boundary.  No team is perfect and all teams can learn and improve on a continuous basis.  Most obstacles to effective retrospectives are solvable with a bit of coaching and education, if you recognize the obstacles before you abandon the technique. Facilitation skills, retrospective techniques and tools are all important for an effective retrospective. The technique is driven by needs of the team. The coach/facilitator needs to be aware of the needs of the team and the proper tools to facilitate the technique. If they are not available, pick another technique. However once the retrospective begins, facilitation skills are always the most important factor. Even with the best technique and tools, retrospectives are all about the people.

Sources:

  • Agile Project Management for Government, Brian Wernham, Maitland and Strong, 2012, P 195
  • Norm Kerth’s Prime Directive, http://www.retrospectives.com/pages/retroPrimeDirective.html
  • The Human Side of Agile, Gill Broza, 3P Vantage Media, 2012, P. 172
  • The Agile Mind-Set, Gil Broza, 3P Vantage Media, 2015, 149
  • De Bono’s Six Thinking Hats, https://en.wikipedia.org/wiki/Six_Thinking_Hats
  • http://spamcast.libsyn.com/s-pa-mcast-244-naomi-karten-how-to-survive-excel-and-advance-as-an-introvert

Download this Trusted Advisor report here.

Written by Default at 05:00
Categories :

Digital Transformation of the Enterprise for SMAC: Can Scrum Help?

Scope of this Report

In this paper, we consider the impact of the digital transformation on software development and whether the Agile Scrum approach being used by many organizations to help the software development teams respond more effectively and quickly to business demands can be used more widely in the organization for digital transformation.

We focus on what has been termed “SMAC.”  The acronym derived from the names for what many believe to be the driving forces of the latest wave of digital transformation:

  • Social media
  • Mobile
  • Analytics (or “big data”)
  • Cloud

It is our belief that Agile principles and methods can be applied throughout an organization to deliver effective digital transformation. 

Why do we need to change our approach for Digital Transformation?

Today’s software development, heavily influenced by SMAC, is being driven much more by the needs and capabilities of customers (users) who have been empowered to install, try out and accept or reject incremental functionality throughout their day, inside and outside of work.  This is the critical change we see in enterprise software development compared with the last 10 years or more.

Historically, IT has not been focused on delivering value to its customers and though that’s a little harsh, we can certainly say that software development has often been driven by technology and completion date.  Put another way, prioritization decisions within IT departments have been more based on: How difficult is the project?  How many and which resources will the project require?  Who is shouting the loudest to get it?

Organizations don’t have a choice.  As an HMG Research blog post in August 2015 pointed out, “As external customers continue to increase their use of digital touchpoints to research and acquire products, companies need to be where their customers are and provide them with the types of experiences that delight customers and keep them coming back.” It’s simply no longer possible to avoid the need for organizational agility in order to recruit and retain customers.

For digital transformation, software development organizations must prioritize their projects, stories and task by customer value.  They have started to do this.  It is not easy but there are ways to make it easier (e.g. Value Visualization).  HMG quoted Red Hat’s CIO Lee Congdon, "The world is shifting from an industrial age to an information age. It's no longer enough to produce great products. Today, companies need the skills and capabilities to connect with their customers. They need the ability to manage their supply chains in real time. Traditional companies are becoming digital companies, and that's a fundamental change,"   Charlie Asaujo in a private conversation with the authors takes this point further, “… In 5-10 years, 80% of what is in-house today will move out.  The transition will be hard work.  IT as we know it is dead.  Managing the value supply chain will be the future for developers wanting to stay in the business.”

The software development teams in organizations have been able to respond to the need to deliver incremental value to their customers quickly and continuously by adopting the principles of agile and the methodology of scrum.  To quote Alan Cameron of DCG, “… scrum can cut through the ambiguity cloud surrounding many traditional projects to provide a clear, frequently renewed focus on value delivery and customer satisfaction.”  

However, the biggest challenge of implementing Enterprise Agile for software development is the need to change the organization outside software development, so that the whole body becomes focused on customer needs and demands.  Some of the need for change on the periphery of software development, we already knew about.  Something as fundamental to Scrum as daily builds require a significant rethink in some organizations.  In early –stage scrum implementations it’s not unusual to be told that the IT team require, say, 3 weeks notice to set up the hardware for a new test environment.  

How can Agile help Digital Transformation?

So what are the principles that drive an Agile business? We have suggested elsewhere that the Agile Manifesto can be adopted for digital transformation with small changes. Therefore, with due deference to the authors of the original (see “Sources” for attribution), we have amended the manifesto (in italics below) in a way that can be applied to digital transformation, while keeping as much of the original wording as possible:

Manifesto for Agile Digital Transformation
We are uncovering better ways of delivering digital transformation by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working customer value over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

There are twelve principles that support the Agile Manifesto.  These too can be modified for applicability to digital transformation:

1. Our highest priority is to satisfy the customer through early and continuous delivery of customer value.
2. Welcome changing requirements, even late in the transformation journey. Agile processes harness change for the customer's competitive advantage.
3. Deliver working customer value frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and digital transformation agents must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a digital transformation team is face-to-face conversation.
7. Working customer applications are the primary measure of progress.
8. Agile processes promote sustainable digital transformation. The sponsors, digital transformation agents, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to customer value and best practice enhances agility.
10. Simplicity – the art of maximizing the amount of work not done--is essential.
11. The best digital transformations emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

We have discussed this topic before on our website and there has been some justifiable push back against taking too simplistic a view of adapting a methodology developed to solve a set of challenges in one context to solve a different set of challenges in a different context.  For example, on our blog, Ally Gill said, “…When we start talking about business transformation we're onto a whole different topic and a completely different set of people's needs which must be addressed. More importantly, the complexity of an organization needs to be considered as a critical factor - something that is less of an issue in developing software.”  We agree and Arpan Pal has highlighted six areas of complexity (in the context of the “internet of things”) where the needs of digital transformation initiatives overlap with but extend beyond the considerations of simply developing the solution software: 

  • Scalability
  • Privacy
  • Affordability
  • Context-Awareness
  • Ease of Development
  • Security

We believe that the modified manifesto is a valid statement of intent that can be used to drive digital transformation, despite the acknowledged difficulties pointed out above.

Why Scrum?

While the agile philosophy puts customer satisfaction and the delivery of customer value among the highest priorities for the development team, scrum is a great technique for ensuring that things can actually be delivered quickly and often in a changing environment.  This is how the scrum teams in software development can help whole organizations to make these changes.  

Scrum succeeds by establishing a disciplined process around solving just enough of the customers’ needs to enable the customer to give more feedback and who better to coach and mentor the teams doing the transformation in the rest of the organization than the software scrum teams themselves.  

In our current world where customers are continuously exposed to new ideas and new capabilities, the digital transformation within any organization must be driven by fast responses to customer feedback.  Scrum, within the context provided by the agile manifesto, is the ideal controlled, disciplined but highly responsive methodology to implement digital transformation.

Most elements of Scrum can be applied to transformations outside software development.  Product Backlogs (or maybe Transformation Backlogs?), tightly time-boxed Sprints (or iterations), Product
(Transformation?) Owners, Scrum Teams, Sprint Reviews and Sprint Planning Meetings are all pretty much essential.  Daily Standups can be overkill on more strategic initiatives but certainly some sort of progress and impediment reporting is appropriate on a regular schedule during the sprint (weekly on a 4-week sprint works well).  Scrum Masters can be a less important role perhaps combined with Product Owner depending on the team.

For us here at DCG, this is no theoretical proposal because we use scrum techniques ourselves for implementing strategic initiatives.  We use scrum in our consulting contracts to help our clients manage their own transformations.  For example, for a client needing to introduce better IT Governance and Measurement, we used an agile approach to help the senior management team identify and prioritize a program backlog.  We were happy when they concluded that the value delivered in the first six transformation sprints was sufficient and that no further sprints were needed.

Conclusions

Applied with care, digital transformation initiatives can benefit from an approach based on the, slightly modified, principles of the Agile Manifesto and Scrum.  Agile tells us to deliver
working customer value frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.  Scrum establishes a disciplined process around solving just enough of the customers’ needs to enable the customer to give more feedback.   

Customer value-focused organizations, which are Agile throughout are best placed to meet the challenges of digital transformation in the age of SMAC.

Sources:

  • Value Visualization, www.valuevisualization.com.
  • HMG Research, http://www.hmgstrategy.com/blog/article.asp?articleID=213
  • Alan Cameron, blog post Monday May 18, 2015, www.davidconsultinggroup.com
  • Ally Gill May 19, 2015 - responding to Alan Cameron blog post of previous day, cited above.
  • Arpan Pal, writing in IEEE’s IT Pro (May/June 2015)
  • Better IT Governance and Measurement,
    http://www.davidconsultinggroup.com/insights/publications/measurement-program-for-data-based-decision-making/
Written by Default at 05:00

Our Software is Full of Bugs

Scope of this Report

  • What are the potential causes of defects?
  • Process, Culture or Estimation Issue?
  • The Value Tetrahedron
  • Tracking and monitoring defects
  • Conclusion

What are the potential causes of defects?

There are various types of defects discovered in live software and we need to consider the root cause of each. While most people assume that all defects are the developer’s responsibility, this isn’t always true. Typical causes include:

  • Poor coding which could be caused by:
    • Unclear or incomplete requirements – Process
    • Poor or insufficient unit testing – Culture or Poor estimation
    • Lack of peer review – Culture or Poor estimation
    • Poor estimation leading to rushed development – Poor estimation
    • Tight development window – Culture or Poor estimation
  • Insufficient Testing which could be caused by:
    • Insufficient test coverage – Process, Culture or Poor estimation
    • Lack of regression testing – Process, Culture or Poor estimation
    • Unclear or incomplete requirements Process
    • Squeezed testing window - Culture or Poor estimation
  • Unexpected Data in the “Live” system which could be caused by:
    • Corrupted live data
    • Unexpected scenarios
  • Change which could be caused by:
    • Volatile requirements - Process, Culture
    • Late change - Process, Culture

Of the four, only “Unexpected data in the Live System” defects can really be considered outside the development project’s capacity to capture or prevent. Even in that case, there are often disagreements between the developers and the business about whether or not certain scenarios should have been unexpected. We have three common themes for the remainder.

Process, Culture or Estimation Issue?

As we can see above, any of the recurring themes – Process, Culture or Estimation - can have a significant impact on the project’s performance and so impact the quality of the release. The tendency is always to blame the developer or the tester for the quality but it’s often a combination of all three issues.

Process

We need to look at the failure from two perspectives – business and development. From the business viewpoint, we should ask if the following were controlled:

  • Business Change Description - Did the business describe what the new business state will be?
  • The Business Case - Was it clear, quantified, current and did it match the business change?
  • Communication - Did the Business help the Development Team to understand the Business Change so they could both articulate which aspects of the backlog provided highest business value?
  • Backlog Prioritisation and Change Control - Was there a product backlog or its equivalent effectively managed and prioritised using techniques such as Value Visualisation?
  • The Risk Management Process - Were risks documented, prioritized and tracked to resolution?

Constant change always has a negative impact on quality in waterfall projects. Even in Agile, which is designed to accommodate change, excessive re-work of features can inject defects. Agile is a lean process and aims to eliminate defects at source or, at least, at the earliest opportunity (e.g. before the end of a sprint). While this may appear to constrain productivity at the front end, the end-to-end benefits of early defect detection and removal are huge.

In the technical processes, we need to look at how the code was delivered:

  • Were agile principles adhered to with constant communication through the business owner to end users?
  • Is adequate time given for an integration sprint if such an activity is planned or needed?
  • Were peer code reviews performed?
  • Was the team’s unit test robust?
  • Was there any systems integration testing?
  • Are agile code releases managed within a robust architecture with continuous integration managed effectively
  • Is adequate time given for integration testing?

Culture

Now, we need to consider the development project culture. With constant demands for everything delivered yesterday at a cheaper cost, ultimately something suffers and, unfortunately, it tends to be quality.

Unless Service Level agreements or Key Performance Indicators are set with development teams/suppliers around defect rates then the developer cares (quite rightly) more about meeting promised delivery dates than rigorously testing the code. In Agile, where this problem should not manifest itself, we sometimes see the symptom of continually developing the same thing in multiple sprints as the product owners try to get closer to what is actually needed.

Estimating

Unless strong and robust estimating procedures are followed, projects are likely to face schedule pressure as a result of development teams cutting corners as they are driven to meet (unrealistic) cost and/or schedule targets.

Even in the Agile team, there is only a finite resource and unless the estimate is strong, the chances of delivering the minimum viable scope will be small unless corners are cut. Put another way, if the product owners and businesses expectations are not carefully managed in an Agile project then their expectations of what they will receive after x iterations may be unrealistic enough to cause the team to cut validation and verification code rather than functionality.

The Value Tetrahedron

In our careers, we have all come across managers and clients who are obsessed by the “Time, Cost, Quality” triangle when they consider software development and, rightly, insist that it should be possible to strike a balance between the three. There has to be intelligence applied during planning and estimating to get that balance correct.

A great deal of time is spent looking at how one can maintain quality and at the same time reduce cost and shorten duration. For example, costs are often driven down by project teams being made to work unpaid overtime or else to cut corners in order to deliver by unrealistic dates. The software goes live and stays up (more or less). The PM happily moves on to his next project. The commissioning (client) manager moves on to the next step on her career ladder. The maintenance team is paid to try to keep the defect backlog down to a manageable size (usually defined as a reasonable level of complaints from the customers) for less cost and in less time! In short, in many organizations, the people who cause the bugs aren’t held accountable as the defect backlog and problems in the code mount up. One manifestation of this is Technical Debt.

Technical debt is the dimension missed so frequently when we look at software development. Somehow the downstream consequences of business driven decisions are often overlooked in the heat of “getting it done”, and often this is tinged with the knowledge that “It won’t be my problem!” when the decision is made to go for it and to hell with the consequences.

If the volume of the tetrahedron is the TCO (total cost of ownership) then controlling that growth has to be the focus of system support and effective control only happens where programme teams and senior commissioning managers make sure that any decisions they make for enhancements will not inflate the TCO beyond controllable limits.

The price of defects hitting the live system is a high TCO and unhappy clients.

Tracking and monitoring defects

The final area to consider is effective tracking and control of the project and that includes defects. Continuous review of the project’s number of defects discovered or defects outstanding should help determine the testing efficacy and the quality of the deliverables before the software goes “live.”

Consider the Defect Discovery Curve.

Figure 1: Defect Discovery Curve
Defect Discovery Curve

Figure 1 shows a typical (albeit fictional data) s-curve shape we would expect for defects in a delivery project. It is a key metric to monitor and is often a strong indicator of when the code is fit to release. The earlier you release the more defects you would expect in live of course. Estimation toolsets will generate predictive models based on historical data and can predict when a project is likely to have discovered 95% or 99% of all defects introduced.

Finally, it is important to investigate where a defect was introduced and where it was discovered, a design defect not found until acceptance testing is much more costly than if it is found in design review (see comments on Agile above). Defect root cause analysis can highlight process issues in specific areas which can improve future performance.

Conclusions

Improving software project quality requires an organization to commit resources to the development and execution of a well-defined software practice.

Strong causal analysis of defects and their origin helps prevent future problems.

Governance of change is important, if you know what the business is going to look like at the implementation of the project then the project will control change and is much more likely to succeed.

The collection of key metrics and review of the data quality will help reduce project failure.
Strong governance, realistic expectations and close communication between the vendor and supplier will help ensure success.

Written by Default at 05:00

What is a Product Owner and Why Do I Need One?

Scope of this Report
“The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone.” - Ken Schwaber, “Scrum Guide”

Scrum defines three basic roles1 within a Scrum team: developers (including testers), a scrum master/coach and product owner. Each of these roles is critical for delivering value effectively and efficiently. The product owner role is deceptively simple. The product owner is the voice of the customer; a conduit to bring business knowledge into the team. They define what needs to be delivered to support the business (or at least finds out), dynamically provides answers and feedback to the team and prioritize the backlog. From a business perspective, the product owner is the face of the project.
This essay will highlight the role of the product owner and why something that seems so easy is generally the hardest role on an Agile team.

The job description of a product owner is fairly straightforward. Their job is to act as the voice of the customer, prioritize the backlog, answer or get answers to the team’s questions and accept/reject the work that the team generates. However the devil is in the details. Understanding the nuances of applying the role is important to successfully function as part of an Agile team.

The Role: Leader or Drill Sergeant?
A leader directs and coordinates activities based on their vision of the future. In Agile projects the product owner provides their vision to the team what they aren’t is drill sergeants. Leaders also need to ensure that a team’s goals stay undiluted by extraneous priorities. A drill sergeant is colloquially viewed as a micromanager who trains team members by drilling them on exactly how each task is to be accomplished. The role of product owners evolved out of the roles of project manager, business subject matter expert (SME) and project sponsor from the waterfall environment. In the waterfall model of projects, each of these roles provided different levels of direction, management and leadership. The project manager is the administrator. The SME provides information on what is done today and what they will need in the future. The sponsor’s role includes providing resources, framing the scope of the project, providing direction as the project moves forward and to demand that the project delivers. The sponsor and the project manager are generally the outsiders that exhort the team into action . . . they act as drill sergeants. While classic project management techniques often include a role similar to a drill sergeant, Scrum and other Agile frameworks actively eschew this role. The Agile principle that states that “the business and developers must work together daily” suggests shedding the approach of an outsider exhorting the team, and implementing the concept of the product owner as leader within the team.

In an Agile project the product owner’s roles include:

  • Owning and prioritizing the product backlog,
  • Providing product vision2,
  • Involving customers, users, and other stakeholders, and
  • Collaborating with others on the team.

The qualities of a product owner are very different from the attributes of the screaming stereotypical drill sergeant. The most critical behavior is often collaboration with others in the business and with the development team: the act of working together to produce or create an outcome. The behavior of collaboration requires the product owner to abandon the role of drill sergeant and focus on being a leader.

The product owner leads by shaping the backlog and collaborating with their fellow team members. The product owner will be more successful if they embrace the principle of the business and developers working together in collaboration, making them more of a leader than a drill sergeant.

If not a drill sergeant then perhaps the product owner is a tour guide. If you have ever visited a major tourist site you have seen tour guides shepherding groups of camera-toting tourists. It is easy to see the tour guide role as that of a leader. A typical tour guide plans the logistics of the tour, herds the tour group ensuring everyone is moving in the same direction and implements the vision of the tour planner to deliver value. The goal of our tour guide is to make sure the team begins and ends together, that no one gets lost and the goal of the tour is accomplished. The role provides administrative and tactical leadership to the tour group. But, the tour guide is not playing the role of the product owner. The whole team acts as its own tour guide in Agile based on the principles of self-management and self-organization. In Agile projects the product owner provides visionary leadership. Tactical leadership and administration, the tour guide role, is generally diffused across the entire team.

The arrangement of roles is facilitated by the application of two Agile Principles3. The first principle directs the business and IT personnel to work together on a daily basis. The second principle in play here is that of self-organizing teams. For example, one mechanism that spreads the role of tour guide across the team is the backlog prioritized by the product owner. The backlog represents the vision in bite-sized chunks that the team can then plan and execute. Another example of tactical leadership that the team drives is the standup meeting, in which the whole team acts as cat herders. So, on an Agile project, who is the tour guide that herds the team toward the product owners vision? The answer is that role is spread across the team and that Agile techniques facilitate making sure that we start and end in the correct place.

As we have noted, Scrum calls for three macro roles on every Agile team. The concept of a stable team is important in Agile (and should be in EVERY framework and method) in order to build collaborative capability and trust. Members of the team must be part of a team on a consistent basis to
value delivered from the team. Product owners are no different when it comes to team membership and cohesion.

Product Owners Are Part of the Team: Embed Them
The twelve principles of the Agile Manifesto provide the basis for interpreting and implementing any Agile technique. One of the hardest principles for many organizations to adopt is: Business people and developers must work together daily throughout the project.

Many implementation approaches have been designed to minimize the organizational inconvenience of this principal, such as using proxies for the business or abandoning the principle altogether. The goal is to involve the business users (also known as the product owner in Scrum) so they can act as voice of the product. Fully embedding business personnel into the project team is often considered the most radical approach. However, is embedding really an absolute, radical solution or just an extreme statement used to generate a conversation? Embedding is a powerful tool, that changes the balance of power inside of an Agile team and brings business personnel inside the boundaries of IT as active participants rather than just sponsors or reviewers. The change required to embed product owners means changes in both IT and in the business department the product owner typically works in. The benefits need to outweigh the costs.

Embedding removes the product owner from their normal job and makes them part of a project team. This has an organizational cost, which includes the cost of replacement even if replacement just means that other colleagues have to pick up the slack. A second and more personal cost occurs on long-term projects. Embedded business personnel need a return path back to the business, or a path into the more technical world, or they risk career failure. Other costs may well include opportunity costs for work or projects that the product owner might have been involved with if they were not on a project team. For example, in an organization DCG reviewed in the recently, a lead sales person participated on a critical product development project as a product owner. During the period he was involved, sales from his territory were “off” by more than 50%. The cost of his participation was lost revenue.

The costs of embedding can be high, but the benefits are generally equally large. The benefits of embedding the product owner are generally a reduction in development time as the team waits for answers, a greater focus on delivering important functions and features earlier, a reduction in rework based on faster feedback and often a better connection to the business. The benefits on embedding can be summarized as reducing the cost of development, faster time-to-market, improved quality and customer satisfaction.

Should every project have embedded business personnel? No, not every project requires embedded business personnel, however, most important projects should. Striking the balance between cost and value is part of the art of implementation. While this technique should be the default in most organization, programs and projects, DCG would not suggest that it be applied without an evaluation of the cost and benefits.

Getting the balance wrong or failing to implement the product owner role has real consequences.

Why Agile Projects Fail: Lack of Product Owners
Failure to correctly address the product owners role creates a myriad of problems for Agile projects, each of which can and often have led to project failure. The product owners role can be difficult to implement. The potential problems4 include: not adequately integrating business representatives into the team, reinforcing the perceived divide between IT and the business, and substituting proxies for business involvement. Each Agile team needs a product owner, or they risk delivering the wrong functionality.

Not integrating business knowledge and decision-making capacity (i.e. the product owner) into the project will lower productivity, velocity and the quality of any project. Just think of the best projects in which you ever participated. Generally, one of the reasons was that a sponsor, lead subject matter expert or super-user, was always around providing input and making decisions. In effect, they were acting as a product owner. Project teams make many decisions, large and small, on a day-to-day basis. The choice that the team has is either 1) to make the decision using the knowledge at hand and risk being wrong, or 2) to wait until they can gather more information. The pressure to deliver now means that most teams will absorb the risk and the rework. Having a product owner close at hand makes development quicker and increases quality.

Not implementing the product owner role reinforces the divide between IT and the business, thus reducing the efficiency of communication. There are many excuses for why organizations implementing Agile don’t involve the business in projects, but the one that DCG sees the most often is that the project team doesn’t ask. Excuses for not asking we have heard include: “the business won’t participate because they are too busy,” or “they are not interested” or “they don't want to have anything to do with us”. Remember that the goal of any project (or at least any project that should be done) is to deliver tangible value based on a need stated by the business. Therefore business personnel have a concrete reason for participation; they should make sure their investment pays off. The first step in the process to involve the business as a product owners is to ask the potential product owners and their managers to participate, making sure they understand the role and why involvement is so important.

The use of proxy product owners is a copout, and in most cases represents a firm signal that Agile should not be used. Proxy product owners are rarely the right answer, because they can’t commit and make decisions for the business slowing the development process to a crawl. One DCG client implemented a hard and fast rule that if a project did not have a product owner, then the project was put on hold until it could be started using a standard project management framework. Without the infusion of business involvement in the day-to-day operation of the project, the organization decided that a classic deliverable-based framework was more appropriate.

The product owner role is critical to linking Agile development teams to the business. Product owners bring business acumen to the development team. That reduces rework and increases the overall acceptance of the product. Choosing not to implement the concept of product owners or to use proxies is rarely the right answer. Bite the bullet and talk to the business users about how they can integrate into the process. Appeal to the fact that it is their money being spent and their involvement would maximize value. If the business can’t commit to participating as product owners, consider not using Agile mechanisms (like Scrum) and instead begin the lean to Agile transition with techniques like Kanban. Kanban is a flow based method that does not require any process changes (at least initially) or role changes.

The Product Owner Is A Role Unto Itself: Don’t Share It!
The role of product owner is critical for ensuring that the rest of the business and the IT team work together effectively. It also requires significant effort on a daily basis. The product owner provides vision, mentors the team, answers questions, makes decisions about the product, communicates with the broader organization, negotiates resource contentions, coordinates business interaction and serves as a liaison to leaders. In short, the role is difficult and complex. So much so that it has been suggested on more than one occasion that it is the most challenging role in Scrum. The product owner should not play any other role on an Agile team5. There are many potential pitfalls in Scrum, however potentially the most destructive and easiest to avoid is the overworked product owner. Overworked product owners are less effective.

What happens when someone is overworked? Sooner or later they will neglect something and cut corners. Some work gets jettisoned as they try to bring their life back to equilibrium. Overworking the product owner may result in non-attentiveness to the team, neglect of grooming the product backlog, and unavailability or missed meetings. It is possible that the product owner will neglect their day job, however, basic psychology suggests that people tend to focus first on that portion of their job that is most important to their long-term career. Unless product owners are focused specifically on a project they will tend to neglect the product owner role (pleasure/pain response6).

The product owner role is challenging; to perform it in a manner that is effective requires effort and focus. Organizations need to ensure that product owners have enough of their time allocated to the product owner role. Work generally needs to be taken off their plate. The rest of the team needs to support the product owner so that obstacles are minimized. Avoid Overworked-Product-Owner Syndrome and make sure the person that is playing the product owner role has the time needed to focus on the project rather than view the project activities as work they can avoid.

Product owners are an integral part of most Agile teams. They bring their business acumen to the team and act as the voice of the customer. Teams without a product owner who is close at hand will either make decisions based on their knowledge of the situation or wait until they can talk to the product owner or other stakeholders. Time is money both in terms of waiting for a decision and delay in getting feedback. Product owners provide vision and leadership to an Agile team. Vision and leadership are not improved by distance or scarcity, so keep your product owner close at hand.

Conclusion
Product owners are an integral part of most Agile teams. They bring their business acumen to the team and act as the voice of the customer. Teams without a product owner who is close at hand will either make decisions based on their knowledge of the situation or wait until they can talk to the product owner or other stakeholders. Time is money both in terms of waiting for a decision and delay in getting feedback. Product owners provide vision and leadership to an Agile team. Vision and leadership are not improved by distance or scarcity, so keep your product owner close at hand.

Sources
1 http://www.scrumguides.org/scrum-guide.html#team, August 20, 2015
2 Mike Cohn, https://www.mountaingoatsoftware.com/agile/scrum/product-owner, August 20, 2015
3 http://agilemanifesto.org/principles.html
4 https://www.scrumalliance.org/community/articles/2010/april/common-product-owner-traps, August 20, 2015
5 https://www.scrumalliance.org/community/articles/2010/april/common-product-owner-traps, August 20, 2015
6 http://www.intropsych.com/ch09_motivation/pleasure_and_pain.html

Written by Default at 05:00
Categories :

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!