Posted on Fri, Feb 22, 2013
by Steven M. Smith
How do I define leadership?
Leadership is the ability to adapt the setting so that everyone feels empowered to contribute creatively to solving problems.
Leadership is an ability, meaning that a leader has a capacity to do something through talent and skill. Talent is natural ability and skill is proficiency gained through training and experience. Talent certainly helps, but it isn’t required. I know many people whose natural leadership ability was close to zero, but who through training, experience, and most of all, persistence, became great leaders.
Leadership is adaptive, meaning that the leader makes adjustments. A leader who fails to adjust to the territory will lose his or her way. Only fools willingly follow someone who is lost.
Leadership acts on a setting, meaning that a leader adjusts the state of the surroundings and people. A leader carefully observes those states and discerns how to change the setting most effectively.
Leadership empowers, meaning that a leader inspires confidence and self-esteem. That inspiration comes in many flavors. Some leaders inspire by bold talk; others by soft talk; and others by their example. There are many ways to empower.
Leadership acts on people’s feelings, meaning that a leader finds ways to link to people’s instincts or intuition. Leaders help everyone feel empowered, which in many organizations with bad histories is a leap of faith. If a leader can also provide concrete evidence of improvement that helps people feel empowered, wonderful. But the evidence usually comes after the leader’s actions produce the desired results.
Leadership creates contribution, which means that every member gives something. Sometimes that may be sharing an idea; other times that may be holding an idea in reserve and allowing someone else to arrive at, and share, the same idea.
Leadership is about solving problems, which means closing the gap between things as desired and things as perceived. Everyone works on the solution to intermediary problems while keeping in mind the ultimate problem — closing a gap for the client or customer.
Leadership fosters creativity, meaning imaginative use of limited resources. A leader who enables people to use their imagination is a step closer to solving problems more quickly and cheaply.
Leadership is often attributed to a single individual. It’s easier to communicate success stories that way. People like simple stories that contain cause and effect even when they are wrong. But the more complex story reinforces that everyone on a team can be a leader. The most successful teams create chain reactions of leadership. An adaptation triggers long chains of further adaptations that ultimately solve seemingly impossible problems.
§
I owe a deep debt of gratitude to Jerry (Gerald M.) Weinberg for the ideas behind this post. He epitomizes this definition of leadership. His books, workshops, and teaching have deeply influenced me. My definition for leadership is an adaptation of the one he uses in his book Becoming a Technical Leader, which I highly recommend. You will find Jerry’s writing a source of empowerment.
Posted on Thu, Feb 14, 2013
by Steven M. Smith
I have had the good fortune to be a member of many successful teams during my career: But my career hasn’t been all bliss — I have also been a member of unsuccessful teams. In my experience, the recipe for the most successful and satisfying team experiences contained ingredients that were ignored by the unsuccessful teams. What ingredients fostered both teamwork and success?
- Listening to teammates personal desires
- Encouraging teammates to ask for help
- Processing the team experience
At the beginning of a project, explore the desires of the members by using the focus questions: "What would you like to have happen for you during this project? Why?" It’s a question designed to put the desires of team members on the table for consideration. For instance, a teammate may answer the focus question, "I would like to participate in the architecture work. I’m thinking about becoming an architect."
People who haven’t experienced explicitly sharing their personal desires with others may have difficulty answering the questions. They may not trust the process. You can’t force them to share their desires so don’t try to. But you can lead by example by putting your desires squarely on the table to show them it’s okay to share.
The obligation for a teammate is to listen to the desires of another teammate. The team isn’t obligated to satisfy a member’s desires. I am regularly amazed, though, by the power an individual gains by articulating what they desire. And how much more helpful I and other teammates can be in helping satisfy those desires when they are visible rather than invisible.
During the project, encourage your teammates to ask for help. Teammates learn it’s okay to ask for help by being asked for help, so ask them for help. For instance, when I had a family emergency, I asked a teammate to complete one of my tasks. I have found that the following words are particularly powerful, "I need your help" and "I need a favor".
If there is anything that is certain in a project, it’s that the members of a team will need help from time to time. Asking for help fosters a healthy interdependence between teammates. And make no mistake about it — the members of successful teams are interdependent. If they aren’t, it’s not much of a team.
At set intervals, process the team’s experience using a retrospective. I am astonished by how few teams actually process their experience. If all your team is concerned about is the product, you are abandoning one-half of your team’s potential value. Your team’s process is also a product.
If you constantly improve the process, its value to your company will continue to grow. After all, the process used on this project will be the default process for producing the next product. Nurture rather than neglect your process.
When the members of a team can ask for what they want, can ask for help, and can process their shared experience, the team’s recipe contains key ingredients for success.
Posted on Fri, Feb 08, 2013
by Wes Williams
A couple of the benefits Agile has given us is adding visibility to teamwork and moving us away from individual measurements as our primary way of measuring progress and issues. For example, in order to forecast completion, we replaced individual task estimates with team velocity. This visibility into the team’s work and measurements of that work helps direct a team’s focus to improving the ability to deliver value to the customer as often as possible. But measures of a team are not enough to help most organizations transform and learn how to deliver value more often. What we need to solve this issue is visibility into how the organization/system works, and measurements that help management see where the system has issues so that they can show them to the teams and help guide them to make good team adjustments. This is where I see a great benefit in the concepts, principles and practices from Kanban, system thinking, theory of constraints and Lean.
Agile visibility
Scrum/XP/iterative planning helps a team visualize many aspects of their work. By looking at trends and collaborating closely, teams can make incredible improvements. This type of working can also improve communication up and down the business hierarchy. However, many problems are outside the team’s control. Although the impact of these problems is made visible, their exact cause is not made visible and the team does not necessarily fully understand them. Management needs visibility and measurements to help them see where the system is causing organization and team problems.
Another issue is a team improving, yet not understanding its impact on other teams. Sometimes a team improving can slow other parts of the system down, hurting the ability of the organization to deliver value sooner. It is also possible that management does not understand the impact that a 'lower value' product has on a higher value product. Due to the 'lower value' of the product on its own, a lower level investment in the product may actually slow down a higher value product. Management needs visibility and measures that help them improve how they manage the system. It is a change for much of management from managing people to managing workflow (to paraphrase @alshalloway, “manage the workflow, not the people”).
This visibility will help teams understand what they need to do differently as well. If I do X it hurts team Y. How can we deliver and reduce the burden on other teams? How might we help other teams so that the organization can deliver value sooner?
System visibility
Kanban, system thinking, theory of constraints, and Lean ideas are a good way to see this higher level.
A Scrum team may see that their velocity is inconsistent which indicates a problem. Maybe that problem is something the team can fix: unavailable product owner, missing/weak skill set, no automated safety net, etc. However, when these are not the issues they may not know the full cause of the problem. More importantly, managers do not have a good view to the cause of the issue. Add a visualization of the workflow across teams with WIP limits, and management can see that a team is waiting on another team. They can see that a team is producing work with which another team cannot integrate until much later, causing a lot of rework and defects for both teams.
Scrum teams may be effectively delivering each iteration/sprint but they cannot always see the effect of their work on others. If managers and teams are looking at the cycle time of work that goes across multiple teams, they can make decisions to improve how the organization delivers.
Conclusion
Too often managers push teams to improve some metric that is outside their control. This causes frustration and gaming the metric. Scrum gave the team transparency, but the work of the manager needs to be made transparent as well. @agilemanager recently tweeted, "I'd like to end focus on process and refocus on management (training). #Kanban is a management method not a process." Agile/Scrum/XP has visualization mechanisms and measurements that help teams see issues they control and effects of things outside their control. Kanban adds visualizations and measurements that help managers see the cause of the problems outside the team’s control. I would also like us to move away from focusing on process to focusing on managing the work and finding the best way to deliver value. Let’s move past just making teamwork transparent and measuring teams. Let’s make workflow and system issues visible to everyone and use the measurement trends to move us towards a common goal.
Posted on Thu, Jan 31, 2013
by Dan Williams
The role of product owner was introduced by Ken Schwaber and Jeff Sutherland in their creation of Scrum as a lightweight project management method in the mid-1990s. Since then, after literally thousands of Scrum projects, the product owner role has come to be recognized as both the most critical role for the success of the product and the hardest role to do successfully.
In Scrum, project management is divided between the product owner, the ScrumMaster, and the team. These are the three recognized roles in Scrum; there is no one project manager role. The various needs of every project must be understood by one of these three roles, and someone, whether team member, ScrumMaster, or product owner, must take responsibility for management of these needs.
The project manager role has been well defined and is supported by published standards, and it can be used to inform and enhance the role of the product owner. Here are five ways that the product owner can benefit from studying the project manager role as understood by the Project Management Institute.
|
Project Manager
|
Product Owner
|
|
Responsible for delivering the project on time, on schedule, and on budget. The project manager is to work with the team to ensure that value is delivered according to the plan in Traditional Project Management (TPM).
|
Responsible for the delivery of the product. The focus is on value, quality, time to market, and return on investment. The key here is responsibility.
|
|
Manages project scope, including the ongoing change control process to ensure that the scope is contained and that impacts to schedule and budget are identified and made visible to stakeholders.
|
With the help of the team, stakeholders, architects, SME’s and analysts, creates the prioritized product backlog. This is the scope of the project with change management done every sprint through re-prioritization of the features/user stories in the backlog. The key here is scope management.
|
|
Works directly with the team to ensure that it is working on the right items in the right order to accomplish the project goals.
|
Works directly with the team to ensure that it understands and is working on the right features in the right prioritized order to deliver value at the end of each sprint. The key here is close team collaboration.
|
|
Works closely with the stakeholders to ensure that their interests and concerns are balanced against each other, that they feel heard, and that their requirements are part of the project.
|
Engages the stakeholders to ensure that their requirements are a part of the backlog and that they are included in the sprint review when their features are demonstrated. The key here is good communication and stakeholder management.
|
|
Manages the budget and monitors the progress of the project against the expense of both personnel and material resources. Earned Value Management may be used to understand if the project is on track or is slipping.
|
Responsible for managing the project budget and for tracking expense against return. The product owner is always looking to deliver early and often, in line with Scrum’s interactive approach to value delivery.
|
These five areas, which are a part of the project manager’s approach to projects, can help the product owner to perform his or her role more effectively. Some have argued that the product owner role is merely an extension and recasting of the traditional project manager role. That debate will continue, but for now the lessons we can share and learn from each role can enhance our delivery of value to our customers.
Posted on Tue, Jan 22, 2013
by Wes Williams
I think metrics and measurements are good when used in the correct way based on the context and team I am working with. I use metrics to help them see what their issues are. Once they see their issues, we use metrics to help us determine, as early as possible, if the changes we are making are having a positive or negative impact on those issues and the rest of the system.
Measurements ARE necessary to know that we are headed in the right direction.
There are plenty of articles out there about abusing metrics. I thought it well known that all metrics need to be balanced (e.g. code coverage going up and complexity going down), and of course they need to be trended to be useful.
Now I have a request to find one or two metrics to apply to all teams to determine how effective Agile and coaching are at improving the teams. Does someone really think that one or two metrics can be used to determine effectiveness?
All teams do not have the same highest priority issue(s). Teams with terrible user stories and acceptance criteria do not need the same metrics as a team trying to fix high coupling code issues.
Ok, enough complaining! To help me, and I hope others, I want write about 1) the goals of specific metrics, 2) the dangers and abuses of those metrics, and 3) how to balance those metrics against each other.
Average Velocity trend
Goals:
- Predictability!! What can be done by a specific date or when can something be completed.
- Velocity is a capacity measure, NOT a productivity measure.
- Velocity allows a team to know how much business value they can deliver over time.
- Developing a consistent velocity allows for more accurate (i.e. predictable) release and iteration planning.
Possible abuses:
- Calling this a measure of productivity. Focusing on velocity alone could even hurt productivity. Teams can artificially increase velocity in many ways: stop writing unit tests or acceptance tests, increase estimates, stop fixing story defects, and reduce customer collaboration, just to name a few.
- Comparing velocity between teams. Velocity is a team value and not a global value. Many variables affect a team's velocity, including relative estimating base, support requirements, number of defects, political environment of the product or project, and more.
- Calculating velocity by individual. This leads to a focus on individual performance vs. team performance (i.e. sub optimization).
- Using velocity to commit to the content of an iteration when the value is not valid. Velocity is a simple concept and provides a lightweight measure, but it is also a very mature measure. To be useful it requires estimation maturity and the consistent application of this over a period of time by a stable team base. If it lacks these elements, its abuse can come at the hands of management or from the team, the latter occurring when a team makes assumption about the validity of the metric when, without the mature elements in place, it is not usable at all.
Balancing metrics:
- Percentage of rework vs. stories done on average each iteration. This can help a team see how much of their work in each iteration is delivering new value to the team's customers.
- Planned work vs. unplanned work trend. A lot of unplanned work will cause a team’s velocity to be of less value because it hinders the team's ability to plan. Having a low value for unplanned work will make the team’s planning more consistent and accurate.
- Code quality metrics such as code test coverage, cyclomatic complexity, static error checking, and performance. A team that is increasing their velocity by not focusing on code quality is making a short term decision that will have a negative impact over time.
Delivered Features vs. Rework Resolution trend
Goals:
- Makes _waste_ visible so that it can be eliminated.
- Gives the team a good understanding of how much of their iteration capacity is consumed by rework (i.e._waste_).
Possible abuses/issues:
- Lagging indicator of the team quality.
- Story defects are not worked on until a regression period, giving a short term indication of fewer defects.
- Increasing story estimates and/or reducing defect estimates.
- Hiding defects as stories.
Balancing metrics:
- An inconsistent velocity. Delaying defect correction until later will make the velocity trend erratic with large spikes.
- Planned vs. unplanned scope. A team that is delaying defect correction will tend to have more unplanned work due to poor quality issues.
- Number of defects in the backlog. Ideally this number should be on a downward trend. An upward trend of the number of defects in the backlog could indicate the team is delaying defect correction.
- Increasingly long regression periods at the end of each release.
Completed Work vs. Carryover trend
Goals:
- Show how well the team executes the iteration (i.e. delivers on their commitments).
Possible abuses:
- Planning less work than the team is capable of to allow for interruptions or poor estimating.
- Delaying refactoring code to complete work but not keeping the code at a level that makes change cheaper and easier in the future (or other good practices such as TDD/unit testing).
Balancing metrics:
- A velocity trend that is not improving or is going down could be caused by planning less than the real capacity of the team.
- Planned vs. unplanned work can indicate if the team is being interrupted and is causing task switching that could be the cause of the carryover.
- Downward test coverage trend and/or upward cyclomatic complexity trend could indicate that the code is becoming more difficult to change and much more difficult to estimate accurately.
Planned vs. Unplanned Scope trend
Goals:
- Show how good the team is at planning.
- Show how often the team is being interrupted within the iteration to work on something that wasn't originally planned.
Possible abuses:
- Large placeholders to allow unplanned work to come in and appear to be part of the planned work.
Balancing metrics:
- Delivered Features vs. Rework Resolution trend
- Completed Work vs. Carryover trend
Code Coverage vs. Cyclomatic Complexity trend
Goals:
- Reduce the cost of change. Clean code tends to make the application easier to understand and safer to change.
- Indicate that the system is being tested at an accurate level.
- Indicate that the code quality is good: loosely coupled, simple as possible, etc.
Possible abuses:
- Focusing only on one code metric, e.g. 100% code coverage with generated tests will not make the code easier to understand or change.
- Focusing on code quality alone and not focusing on the business goals of the customer.
Balancing metrics:
- Velocity trend
- Delivered Features vs. Rework Resolution trend
- Afferent and efferent coupling trends
- Abstractness trend
- Package dependency cycles
- Number of changes in class(es)
This is far from an exhaustive list of metrics! But I hope the idea helps, of thinking about a metric, what your goal is of measuring a value, and how you can stop yourself or others from gaming the value by balancing it with other methods.
Posted on Fri, Jan 18, 2013
by Ron Quartel
<music src="Pink Floyd - The Wall">
We don't need no constant tracking.
We don't need no micro managing.
Hey – Business – leave those devs alone!
All in all it's just another task off the wall.
</music>
What does a delivery team do? Deliver! They make a commitment and then deliver on it. If they are not going to make a commitment then they promise to tell the product owner the minute they think the sprint is at risk. Given that this is the way a committed delivery team works, why do management – and sometimes product owners – feel that they need to track the day-to-day progress of a team through the sprint? The answer is that the management is still in traditional project management tracking mode, where managers feel that their job is to track task completion and hours remaining. If this is true for your company/project/product – STOP!!!! You are disempowering the team and in effect telling them that you do not trust them.
Some managers use a burn down chart. The burn down chart is an (optional) tool that is used by a team to help them know if/when they are behind on a sprint or likely not to succeed. I personally don't see the need for exposing (or even using) a burn down chart in a committed team that delivers consistently, and I have worked in many such teams. If your team finds it useful – yay! Go ahead and use it. But if you have a method in place that gives you the same result without this tool then – yay! Use that.
So given that the business does NOT need to track the daily progress of sprints (because the delivery teams are meeting their commitments), what tracking is required? The product owner and his or her backlog is the only point of tracking for a project. For enterprise or portfolio tracking (i.e. multiple backlogs), an electronic tool might make sense and help you. If the delivery team finds an electronic tool useful, then let them use a tool. If they do not, do not force one on them because "you need to track their work." That is not using an Agile mindset and you are in fact expressing distrust to your teams.
I've said it before and I'll say it again. I personally dislike electronic tools within teams and much prefer big visible charts from which you can glean a thousand pieces of information at a glance. Keep it simple stupid! (And start trusting your teams.)
Posted on Wed, Jan 09, 2013
by Ambika Patil
SolutionsIQ was recently present at the Agile Scrum International Summit in Bangalore. Witnessing the upcoming advances in the field of Agile and adding flavor to the event were our very own speakers.
The event, conducted by Bacancy Technology, boasted a huge turnout and saw in attendance enthusiasts from around the globe. Speakers from SolutionsIQ covered a wide range of topics at the event. Vibhu Srinivasan and Joe Justice spoke about the pros and cons of the role of team manager, and Joe explained how the WIKISPEED project, a self-organizing team, was able to develop a 100mpg car in three months and win international acclaim. Throughout the day, SolutionsIQ made an impact through various presentations, discussing topics like retrospectives and being a good ScrumMaster.
The highlight of the day was the morning session, in which Vibhu and Joe engaged the participants in activities where they had to come up with reasons why a manager is needed or not needed in a team. The participants came up with many suggestions for being a better manager, including:
- Avoiding micromanagement
- Avoiding many meetings
- Empowering the teams after empowering oneself
- Team rewards instead of individual rewards
To enliven the session, the audience was given a surprise questionnaire where they had to guess the contents of a ScrumMaster’s tool kit on a piece of paper and drop it in a bowl. During a tea break, a raffle was conducted and the two best answers were rewarded with a ScrumMaster’s tool kit from SolutionsIQ.
Naveen Nanjundappa’s session was “Scrum Horoscope”. He entered dramatically like a yogi; the audience was keen on getting their Scrum team horoscopes read and predicting the impending problems in their team.
Jayaprakash Puttaswamy’s session was “Raju bangaya ScrumMaster”, which detailed the journey of a ScrumMaster and the impediments he or she must overcome. JP engaged the audience in activities that taught them how not to be a "dead" ScrumMaster.
The conference was a huge success and was a perfect way to end a year filled with Agile learning throughout India.
Posted on Fri, Jan 04, 2013
Guest post by Linda Merrick of Pivotal Product Management
As more and more software organizations adopt Agile methods, the lack of strong Product Ownership is becoming more acute and is a limiting factor in the success of Agile implementations. Even when you have a competent Product Owner by Scrum certification standards, over the long haul it’s just not enough. Unless the Product Owner is a Product Manager or working side by side with a Product Manager, he or she is missing some key principles that will ultimately limit the amount of value the team can deliver. Here are five key principles that Product Owners need to know to lead their software products to success. They apply whether you’re in an ISV organization, or developing software for internal use.
1. Product life cycles
Similar to living beings, products are conceived, introduced, experience growth, reach maturity, and eventually decline. The key principle in product life cycles is that product strategy changes with each stage of the life cycle. Product Managers understand how and when to change the strategy to focus on maximizing the value of the product over time. So – what is product strategy?
2. Product strategy
At its essence, product strategy is all about saying ‘yes’ or ‘no’ when making product investment decisions. If strategy changes over the product life cycle, then how you prioritize investments and user stories also changes over the product life cycle. Product Owners need to understand these changes so that they can manage stakeholders and manage the backlog to deliver the most value over the life of the product.
Bonus: Product life cycle and product strategy are also the keys to building an effective longer-term roadmap. Here’s what Dean Leffingwell, who I view as the definitive leader in the Agile community when it comes to understanding Product Owner and Product Manager interactions, says about roadmaps in his book Agile Software Requirements:
“The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set. Although it is a simple thing mechanically to represent the Roadmap, figuring out the context for anything beyond the next release is another matter entirely.”
Why is that? Because most product organizations aren’t applying product life cycle thinking and crafting product strategies. These are the missing inputs to a product roadmap that can go beyond the next release.
3. Deep understanding of product vision
Backing up the product strategy is a clear statement of the product’s vision and the reasoning that supports the vision. A strong vision statement contains four elements:
- the problem to be solved
- for an explicit set of users or customers,
- the value customers will receive from solving the problem, and
- the focus for making this product better than all other alternatives solutions.
Product Managers regularly craft this type of vision statement, which they call “positioning.” Each element of the positioning is supported by research. Product Owners and their teams need to understand the vision and the reasoning behind it to ensure that the planned value is realized.
4. Collaborative prioritization
In a recent discussion with a colleague about product management, he was mortified to learn that in the product management realm, nearly every decision is made by committee. To him, this concept could only result in a long series of “Dilbert” moments. Successful product managers only get that way by mastering the art of “buy-in” from the diverse set of team members that we need in order to create a successful product – Sales, Finance, Service, Operations, etc. Product Owners must work with a diverse set of users and stakeholders in prioritizing the product backlog, and so need to have the same skills.
5. Whole product thinking
Those diverse team members we mentioned in #4? They may have specific needs that must be addressed within the software, as requirements, in order to create a successful product or a solution. It has long been understood that one of the biggest points of failure in software projects has been incomplete requirements, and Product Managers know that requirements come from more than just the users and system administrators. Product Owners need to reach beyond their typical user personas to ensure that the team delivers on organization-wide needs in order to fully realize the value of the software product.
Where can Product Owners go to get the Product Management knowledge they need? There are lots of great blogs, books, and workshops out there that will extend Product Owner knowledge and skill in these key strategic areas.
Posted on Thu, Dec 20, 2012
by Dhaval Panchal
Simulations reveal one's default behavior. I have learned a lot about myself and my default settings when I have participated in simulations. (Shout out to AYE conference, PSL workshops, and many other excellent learning opportunities that have immersed me in uncomfortable, simulated project settings, enabling me to recognize and resolve personal dysfunctional traits that I was previously unaware of.)
Working within a distributed context can be challenging. Learning to cope with the physical separation and timezone differences is often a long, extended process wherein many lessons are learned the hard way. The Distributed Agile Simulation workshop simulates your distributed context so experienced coaches can observe your real-life situations unfold and provide specific feedback, coach on relevant distributed scaling structures, and demonstrably amplify your shift towards improved distributed product delivery. This is a 2-day custom workshop, wherein we do a deeper dive to unfold the many people, structure, and dynamic relationship aspects of your distributed delivery experience and provide you with relevant techniques, tools, and thinking models to navigate your product's distributed delivery context.
During the Agile2012 conference in Dallas, Texas, Michael Tardiff and I facilitated a 3-hour Distributed Agile Simulation -- a miniature version of the two-day workshop. We divided all participants into three roles:
- Builders: Those who contribute to planning and delivery of the project.
- Observers: Those who only reflect what they see, hear, and feel, and do not contribute towards building the project in any way. Maximum of 2 per team of builders.
- Managers: One per team of builders.
This group was further divided into four separate geographic locations -- Seattle, Hollywood, Pune, and Hyderabad -- and a timezone difference between the U.S. and India locations was simulated. We executed two full iterations under these conditions. This close-to-real-life simulation revealed many of the typical behavioral patterns, contrasts, and subcultures that we often see in real-world, scaled, distributed Agile delivery systems.
Many people who participated in the simulation expressed that it was realistic, and that it revealed to them how difficult scaled and distributed delivery can be. While there are no quick fixes for complex and dynamic human systems, in retrospect the debrief revealed what worked and what didn’t.
Process for processes sake?
At the start of the simulated iteration, the team in Seattle began crafting well-formed user stories with acceptance criteria, and struggled a lot. During the debrief they revealed how they abandoned user stories and started having high-bandwidth Skype conversations with other remote teams.
The team based in Hyderabad searched deeper and consciously abandoned user story writing since they were able to work out an agreement with their product owner that she would be available to provide the why and what aspects of any requirement, and be willing to negotiate the how with the team.
While one team was frustrated that their adherence to “best practices” of user stories did not work out, another team in the same simulated setting tailored aspects of a “good practice” –- user stories -- to suit their context.
Managers – Who?
Manager meeting (black pinnies)
In the simulation, managers were assigned to each location, and almost all them at first struggled to find their function within an Agile context. While a couple sidelined themselves to inactivity and checking emails on their handhelds, the other two went above and beyond -- one protected the team members, keeping the distributed telecommunication infrastructure up and running, while the other outdid everyone by demonstrating outstanding service to his team.
In the final debrief, the teams with dysfunctional managers viewed management as a roadblock, while the teams with serving and supporting managers viewed their managers as integral to their success.
Emergent Issue handling
Skype Box (green tape box) coordination meeting
Scrum of Scrums or similar late night coordination meetings to align work coordination between teams are common in a distributed context. During the simulation, a couple of teams had their representative stay online (on the Skype box) during all working hours to field emergent integration and coordination issues.
Such continuous attention to managing communications between distributed teams is crucial, and was an outcome of retrospectives from the first of the two iterations that the teams participated in.
Busy work –> Integration issues
Navigation??
Landing pages
A lot of work was completed by the end of two iterations -- pages and pages of Web content. It was easy to see four distinct color schemes, four different layout patterns, and a hodgepodge of Web prototypes. With four different geographically-separated locations, the final product was pulled in four different directions.
This attention to busyness (local optimization) is often rampant in distributed contexts. Lacking a coherent mechanism to coordinate, throttle, and iterate on work produced by many locations often leads to an incoherent final product.
Scrum of Scrums, a coordinating mechanism between teams, is a scaling building block. But this simulation revealed that talk is cheap, often borne out in reality. Simple verbal communication is not enough -- coordination around substance is also crucial. In real scaling situations, being able to merge, compile, unit test, and pass the full CI cycle every night/day with software from all distributed teams is the only validation of coherent product.
Observer Notes and Charts
Agile 2012 Distributed Agile simulation observers charts
Since our session at Agile 2012, many people have reached out to me for details around facilitating this session. Preparations for this are elaborate. If you are interested in facilitating this session or would like to amplify your team’s awareness and learning about their distributed context, please connect with me via email.
Finally, before I leave, I must thank my friend Tom Perry for his generous dedication of time, spirit, and energy.
Tom Perry
Posted on Wed, Dec 12, 2012
by Dan Williams
The role of the product owner is understood as critical to fulfilling the goal of delivering products of value to the customer. Since the official beginnings of Agile, this role has also been one of the major pain points in actually providing that value.
To explain, the product owner is one of the three original roles identified in Scrum, along with the team and the ScrumMaster. The role is analogous to that of customer in eXtreme Programing (XP). But what is the purpose of the product owner role? What problem is the introduction of this role, identified as a critical part of both Scrum and XP, trying to solve? [1]
The role of product owner was put forward as a solution to the problem of poor and changing requirements from multiple stakeholders, which sometimes makes the production of quality software next to impossible. The product owner would become the representative of the stakeholder community. He or she would gather and communicate requirements to the team, representing the stakeholder community with a ‘single voice’. This would remove ambiguity and foster improved communication between the business and the developers. Great idea – but what happened?
The role has generally not materialized in businesses attempting to implement Agile software development techniques. The role of product owner ideally combines a development team-facing perspective and a stakeholder/customer-facing perspective. Attempting to combine these two perspectives has been shown to present herculean issues for the person trying to actually perform the role – namely empowerment and representing the voice of the customer.
The first issue is that of empowerment. When describing the role in the first book on Scrum, Ken Schwaber and Mike Beedle state that the product owner is fully empowered to select and prioritize the features making up the product backlog. [2] It turns out that this proposal, which on the surface sounds like a good idea, often doesn’t work out well.
Empowerment sounds good because it reduces the number of communication channels and invests one person with the authority to make decisions quickly. This increased simplicity in communication and speed of decision-making is welcome news to development teams, which need quick turnaround on questions of prioritization and details concerning work in progress.
But it doesn’t work out well due to the number and complexity of stakeholders needing to provide input to the development team and due to conflicts over feature prioritization and design. This short explanation will be expanded in another blog article, but the facts are that, with few exceptions, the empowerment of the product owner is sadly lacking and so the development team is still, often, receiving mixed messages regarding design and priorities.
The reality is that the product owner, or customer proxy, as the role is sometimes called, must still meet with and coordinate multiple internal stakeholders as well as attempt to understand the marketplace and the external customer if applicable.
In the next post, I will discuss the second issue concerning the product owner role: representing the voice of the customer.