Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management

Asking Questions: Hints For Improving Your Question Making Skills

Horse Crossing Sign

What is the Question?  Horse Crossing

Questions are a powerful tool for eliciting information, helping people grow, or leading people.  However asking questions often requires more than just opening your mouth and uttering the first words that come to mind.  Asking the right questions at the right time is a combination of art, science, and preparation.

  1.     Have a Goal

Establish what your end game is for asking a question.  For example, are you trying to gather facts, an opinion, or change behavior?  Your goal will affect both how you phrase a question and timing of delivery.

  1.     Develop a Strategy

Depending on the goal, the questioner needs to decide how they interact with the person they are going to ask questions.  I recently provided advice for a leader that wanted to help an employee identify and address a behavior issue.  The set of questions we agreed upon were designed to help the employee identify and then develop a solution to the problem.  The strategy was very different than the questioning strategy I would employ for a guest on the Software Process and Measurement Cast.  The strategy needs to meet the goal of the conversation

  1.     Loosely Script Questions

Based on the goal and strategy, develop a loose script of questions.  For example, if I am trying to gather information or opinions I will put together a set of questions with possible follow-up questions.  Even if you never use the script, game planning the interaction can make it easier to listen rather than concentrate on thinking up the next question. Consider starting by asking broad questions then spinning down into more detailed questions.

  1.     Use Humor and Negative Emotion Carefully

Humor is a great tool to build connections between people. ¬†The problem is that one person‚Äôs humor is not always the same as another’s. When humor doesn‚Äôt click the interaction will tend to shut down. ¬†Anger (real or feigned) makes a great theater in oration, however, embedding anger in a question will tend to shut a conversation down and cause the person answering the question to be very guarded, reducing the value of the answer.

  1.     Open Conversation (if that fits with the goal)

Use questions to facilitate an open conversation. Open-ended questions are often a good tool to get a person to open up and begin talking.  For example, asking a development team to describe the project they are currently working on will illicit more information than asking whether a team made the date they committed to making.

  1.     Listen

Ask a question, then stop and listen to the answer.  Listening is not the same as using the time to create a new question or to answer a text message.  Multitasking is a myth.  Listen first, then react to what you have heard.

  1.     Ask Only What You Need

There is an old maxim, take what you need and leave the rest.  Time is precious: do not abuse the time and attention you get when interacting with people.

These are just a few suggestions for getting better at asking questions.  Some of them, such as having a goal and strategy, are applicable to every scenario. Scripting might not be needed in every situation. However you likely need to consider your approach if asking something more complicated than whether dinner will be in 30 minutes. Even then, I think conscious thought might be needed.


Categories: Process Management

Toward Evolutionary Software Design and Architecture

From the Editor of Methods & Tools - Tue, 05/23/2017 - 16:27
Projects that don‚Äôt change are the ones that get canceled. Any relevant and useful software has to continuously evolve. Agile development greatly emphasizes an evolutionary approach to software design and software architecture. That‚Äôs because big up-front design and architecture are risky. But the evolutionary approach also has risks. This session starts with a quick discussion […]

SPaMCAST 443 ‚Äď Brad Clark, Cost Estimation COCOMO II, COCOMO III

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The next Software Process and Measurement Cast features our interview with Brad Clark.  Brad and I talked about cost estimation, estimation in government and COCOMO II and what is on the way in COCOMO III. Even if you are firmly in the #NoEstimates camp this interview will give you ideas to think about!

Brad’s Bio

Dr. Brad Clark is Vice-President of Software Metrics Inc. ‚Äď a Virginia-based consulting company. His area of expertise is in software cost and schedule data collection, analysis and modeling. He also works with clients to set up their own estimation capability for use in planning and managing. He has also helped clients with software cost and schedule feasibility analysis and cost estimation training.

Dr. Clark received his Master’s in Software Engineering in 1995 and Ph.D. in Computer Science in 1997 from the University of Southern California. He is a co-author of the most widely used Software Cost Estimation model in the world, COCOMO II. This model estimates the effort and duration required to complete a software development project.

Email: brad@software-metrics.com

Re-Read Saturday News

This week we tackle Chapter 5 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 5, Operations, puts the roles and policies defined in governance to work.  Next week we will have some VERY exciting news about the next book in the Re-read Saturday feature!

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations (Current Week)

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes.  Reviews help guide people to the cast!

Next SPaMCAST

The next Software Process and Measurement Cast will our essay re-visiting the product owner role.  The product owner role is hard, often messed up and a great opportunity for improvement.

We will also have columns from Steve Tendon and Jeremy Berriault. This will be an important cast to start the summer season in the northern hemisphere!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 443 - Brad Clark, Cost Estimation COCOMO II, COCOMO III

Software Process and Measurement Cast - Sun, 05/21/2017 - 22:00

The next Software Process and Measurement Cast features our interview with Brad Clark.  Brad and I talked about cost estimation, estimation in government and COCOMO II and what is on the way in COCOMO III. Even if you are firmly in the #NoEstimates camp this interview will give you ideas to think about!

Brad’s Bio

Dr. Brad Clark is Vice-President of Software Metrics Inc. ‚Äď a Virginia-based consulting company. His area of expertise is in software cost and schedule data collection, analysis and modeling. He also works with clients to set up their own estimation capability for use in planning and managing. He has also helped clients with software cost and schedule feasibility analysis and cost estimation training.

Dr. Clark received his Master’s in Software Engineering in 1995 and Ph.D. in Computer Science in 1997 from the University of Southern California. He is a co-author of the most widely used Software Cost Estimation model in the world, COCOMO II. This model estimates the effort and duration required to complete a software development project.

Email: brad@software-metrics.com

Re-Read Saturday News

This week we tackle Chapter 5 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 5, Operations, puts the roles and policies defined in governance to work.  Next week we will have some VERY exciting news about the next book in the Re-read Saturday feature!

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations (Current Week)

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes.  Reviews help guide people to the cast!

Next SPaMCAST

The next Software Process and Measurement Cast will our essay re-visiting the product owner role.  The product owner role is hard, often messed up and a great opportunity for improvement.

We will also have columns from Steve Tendon and Jeremy Berriault. This will be an important cast to start the summer season in the northern hemisphere!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

Holacracy: Re-read Week 6, Chapter 5 ‚Äď Operations

Book Cover

Holacracy

This week we tackle Chapter 5 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 5, Operations, puts the roles and policies defined in governance to work.

Robertson starts Chapter 5 by recalling the adage Рslow down to speed up. We are being exhorted to pull back from the day-to-day work in order to improve how the organization is organized by listening to a diverse group of people.  The use the structure of the organization defined as part of governance to do work is operations. Said differently, everything that does not fall into the responsibility of governance is operations. Operations are about using the structure to find a governance.

The Basics of Operations

Critical Definitions:  In Holacracy, Robertson uses two definitions from the book Getting Things Done (David Allen).  The first is that a project is an outcome to be achieved and second that a next step is a concrete physical action that could be executed now. 

Operations are focused on doing tasks or projects.  Robertson describes a basic behavior pattern for each project or pieces of work.  Begin by defining a clear set of criteria that must be true for the project to compete.  The criteria should be as clear as a true or false question.  Then take the first step. When the step is a complete test whether the project completion criteria has been satisfied.  You are either done or you take the next step.  Those that are familiar with test first development will recognize and be heartened by the pattern.

One of the central values of Holacracy is that people throughout an organization must have clear autonomy to take decisive action. That authority comes with increased accountability to self-manage. Self-management requires the explicit responsibilities of sensing and processing tensions (Robertson’s words for the stress between roles and processes), executing accountabilities, working through and tracking projects, taking next actions, directing attention, people and resources. Except in the very simplest role, every individual needs a system to help them fulfill their responsibilities. ¬†The complexity of roles in an organization makes it impossible to keep everything in your head.

Every circle member has a set of basic duties:

  1.   The duty of transparency.  This duty has four sub-duties; sharing projects and next actions, making sure the order of work (relative priority) is known, making and sharing projections of when work is likely to be done, and providing a checklist of and the metrics needed for tactical meetings (discussed later).
  2.   The duty of processing accountabilities. This duty is subdivided into three sub-duties. For projects and tasks that are part of your role, you have the duty to process it to a next clear action. If you are presented with requests for actions you have the duty to consider the request to take on the task if it fits into one of your accountabilities. And, if a request is made to impact the domain you control you have the duty to consider the request and may accept or decline.
  3. ¬†¬†The duty of prioritization. ¬†This duty can also be sub-decided; you have the duty to prioritize or ad-hoc execution, a request for a tactical or governance meeting takes priority over execution except when there is a delivery constraint (remember that tactical and governance meeting get blockages out of the way), and ¬†it is the duty of the individual to prioritize the circle needs and goals over the goals and needs of the individual’s goals. ¬†Individual goal should be aligned with the circle’s goals

Tactical Meetings

The tool that makes operations work in Holacracy are the tactical meetings. Tactical meetings are for getting help when you don’t know what to do next, enable the circle to discuss operational issues, get updates on projects, find out what other roles are working on, give updates on your project and to ask for help when needed. Tactical meetings vary in frequency, but is often are weekly. ¬†The magic is not in just having a meeting, but rather in the structure and process.

The flow of tactical meetings follows seven steps.

  1. ¬†¬†¬†¬†¬†Check-In Round ‚Äď This round follows the same process defined for the Governance Meeting. ¬†The round is about getting present and no crosstalk is allowed.
  2. ¬†¬†¬†¬†¬†Checklist Review ‚Äď List the recurring actions by discipline. ¬†The review is a simple recitation of yes (if done) or no (if not done). ¬†Checklist items are typically defined by the role; however, any other role can add items to the role if the role needs to know that an action has been taken on a recurring basis. Note‚ÄĒthis is a brilliantly simple approach to making sure a role stays focused. ¬†The facilitator reads the list and the role responds. ¬†Simple explanations are allowed but NO open discussion.
  3. ¬†¬†¬†¬†¬†Metrics Review ‚Äď Metrics, either defined by the role or by the lead link, are reported. ¬†Questions are allowed to make sure the data is understood but NO open discussion or other suggestions.
  4. ¬†¬†¬†¬†¬†Progress Updates ‚Äď This role is focused on changes since the last tactical meeting ONLY. If no progress has been made since the last meeting then the update should be simply ‚Äúno update.‚ÄĚ
  5. ¬†¬†¬†¬†¬†Agenda Building ‚Äď As with the governance meeting, agenda for the issues is built during the meeting. ¬†Each member of the circle can raise the issue and put them on the agenda.
  6. ¬†¬†¬†¬†¬†Triage Issues ‚Äď Agenda items are processed one at a time by giving the owner of the item the time to engage others in the circle until the item is addressed or a next step is identified and accepted. The facilitator listens for the breakpoint and then moves to the next item. The secretary captures resolution or next steps. ¬†When an item change leads to a need to change a role or policy, the item is routed to a governance meeting.
  7. ¬†¬†¬†¬†¬†Closing Round – Each person reflects on the meeting one at a time without discussion. ¬†Depending on the size of the circle I suggest ensuring that the agenda includes 5 ‚Äď 10 minutes to address this step.

One of the important considerations woven throughout Holacracy is the need for transparency and follow through.  When an individual accepts a next step that acceptance represents a form of commitment. The commitment is to consciously track the issue, to consciously review the next step, and to consciously take the action as soon as it becomes the most important item among your possible actions on your backlog.  This feels very much like backlog grooming and management.

Remember to buy a copy of Holacracy (use the link in the show notes to help support and defray the costs of the Software Process and Measurement Cast blog and podcast).

Previous Entries in the re-read:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organization Structure

Week 5: Governance

 


Categories: Process Management

Holacracy: Re-read Week 6, Chapter 5 ‚Äď Operations

Book Cover

Holacracy

This week we tackle Chapter 5 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 5, Operations, puts the roles and policies defined in governance to work.

Robertson starts Chapter 5 by recalling the adage Рslow down to speed up. We are being exhorted to pull back from the day-to-day work in order to improve how the organization is organized by listening to a diverse group of people.  The use the structure of the organization defined as part of governance to do work is operations. Said differently, everything that does not fall into the responsibility of governance is operations. Operations are about using the structure to find a governance.

The Basics of Operations

Critical Definitions:  In Holacracy, Robertson uses two definitions from the book Getting Things Done (David Allen).  The first is that a project is an outcome to be achieved and second that a next step is a concrete physical action that could be executed now. 

Operations are focused on doing tasks or projects.  Robertson describes a basic behavior pattern for each project or pieces of work.  Begin by defining a clear set of criteria that must be true for the project to compete.  The criteria should be as clear as a true or false question.  Then take the first step. When the step is a complete test whether the project completion criteria has been satisfied.  You are either done or you take the next step.  Those that are familiar with test first development will recognize and be heartened by the pattern.

One of the central values of Holacracy is that people throughout an organization must have clear autonomy to take decisive action. That authority comes with increased accountability to self-manage. Self-management requires the explicit responsibilities of sensing and processing tensions (Robertson’s words for the stress between roles and processes), executing accountabilities, working through and tracking projects, taking next actions, directing attention, people and resources. Except in the very simplest role, every individual needs a system to help them fulfill their responsibilities. ¬†The complexity of roles in an organization makes it impossible to keep everything in your head.

Every circle member has a set of basic duties:

  1.   The duty of transparency.  This duty has four sub-duties; sharing projects and next actions, making sure the order of work (relative priority) is known, making and sharing projections of when work is likely to be done, and providing a checklist of and the metrics needed for tactical meetings (discussed later).
  2.   The duty of processing accountabilities. This duty is subdivided into three sub-duties. For projects and tasks that are part of your role, you have the duty to process it to a next clear action. If you are presented with requests for actions you have the duty to consider the request to take on the task if it fits into one of your accountabilities. And, if a request is made to impact the domain you control you have the duty to consider the request and may accept or decline.
  3. ¬†¬†The duty of prioritization. ¬†This duty can also be sub-decided; you have the duty to prioritize or ad-hoc execution, a request for a tactical or governance meeting takes priority over execution except when there is a delivery constraint (remember that tactical and governance meeting get blockages out of the way), and ¬†it is the duty of the individual to prioritize the circle needs and goals over the goals and needs of the individual’s goals. ¬†Individual goal should be aligned with the circle’s goals

Tactical Meetings

The tool that makes operations work in Holacracy are the tactical meetings. Tactical meetings are for getting help when you don’t know what to do next, enable the circle to discuss operational issues, get updates on projects, find out what other roles are working on, give updates on your project and to ask for help when needed. Tactical meetings vary in frequency, but is often are weekly. ¬†The magic is not in just having a meeting, but rather in the structure and process.

The flow of tactical meetings follows seven steps.

  1. ¬†¬†¬†¬†¬†Check-In Round ‚Äď This round follows the same process defined for the Governance Meeting. ¬†The round is about getting present and no crosstalk is allowed.
  2. ¬†¬†¬†¬†¬†Checklist Review ‚Äď List the recurring actions by discipline. ¬†The review is a simple recitation of yes (if done) or no (if not done). ¬†Checklist items are typically defined by the role; however, any other role can add items to the role if the role needs to know that an action has been taken on a recurring basis. Note‚ÄĒthis is a brilliantly simple approach to making sure a role stays focused. ¬†The facilitator reads the list and the role responds. ¬†Simple explanations are allowed but NO open discussion.
  3. ¬†¬†¬†¬†¬†Metrics Review ‚Äď Metrics, either defined by the role or by the lead link, are reported. ¬†Questions are allowed to make sure the data is understood but NO open discussion or other suggestions.
  4. ¬†¬†¬†¬†¬†Progress Updates ‚Äď This role is focused on changes since the last tactical meeting ONLY. If no progress has been made since the last meeting then the update should be simply ‚Äúno update.‚ÄĚ
  5. ¬†¬†¬†¬†¬†Agenda Building ‚Äď As with the governance meeting, agenda for the issues is built during the meeting. ¬†Each member of the circle can raise the issue and put them on the agenda.
  6. ¬†¬†¬†¬†¬†Triage Issues ‚Äď Agenda items are processed one at a time by giving the owner of the item the time to engage others in the circle until the item is addressed or a next step is identified and accepted. The facilitator listens for the breakpoint and then moves to the next item. The secretary captures resolution or next steps. ¬†When an item change leads to a need to change a role or policy, the item is routed to a governance meeting.
  7. ¬†¬†¬†¬†¬†Closing Round – Each person reflects on the meeting one at a time without discussion. ¬†Depending on the size of the circle I suggest ensuring that the agenda includes 5 ‚Äď 10 minutes to address this step.

One of the important considerations woven throughout Holacracy is the need for transparency and follow through.  When an individual accepts a next step that acceptance represents a form of commitment. The commitment is to consciously track the issue, to consciously review the next step, and to consciously take the action as soon as it becomes the most important item among your possible actions on your backlog.  This feels very much like backlog grooming and management.

Remember to buy a copy of Holacracy (use the link in the show notes to help support and defray the costs of the Software Process and Measurement Cast blog and podcast).

Previous Entries in the re-read:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organization Structure

Week 5: Governance

 


Categories: Process Management

Refactoring to Microservices ‚Äď Using a Document as State

Xebia Blog - Fri, 05/19/2017 - 14:12

In a previous installment of our Microservice refactoring effort, I‚Äôve introduced a ShopManager and a Clerk to implement the shopping process (see this blog). I ended up with a JSON document transferred between services. To make life easy for myself I just parsed all of the document using Spring magic. This time I will discuss […]

The post Refactoring to Microservices ‚Äď Using a Document as State appeared first on Xebia Blog.

Asking Questions: Many Types Of Questions

CC Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)

Questions are a critical tool that every coach, mentor or leader uses to help shape and improve the performance of those they interact with. ¬†‘Question’ represents a high-level category that describes many different types of questions. ¬†This is similar to the screwdriver. ¬†If you were to walk into a hardware store and ask for a screwdriver the clerk would ask what kind and/or what you were going to use it for in order to help you find the right kind. ¬†There are¬†different taxonomies of questions which are useful to help practitioners decide what type of question suits which purpose.

Open, Closed and Hybrid Questions:

The first classic categorization typically leveraged when considering which type of question to use in any specific scenario is: open or closed?

 Open questions are queries that have multiple and often conflicting answers.  An example of an open question would be asking someone what the meaning of life (an extreme example).  The primary goal of an open question is to generate a conversation and participation.  Open questions can be used to guide conversations by are not as effective at guiding an interview as a set of closed questions (below).

Closed questions are questions with a limited number of correct answers. For example, a ¬†yes/no question is a closed question. ¬†Another non-yes/no example is the question, Did the sun come up this morning? ¬†The question while yes or noe has one correct answer (unless something very dramatic and bad has occurred and then no one would really care about the answer). ¬†A multiple choice question is another slightly less extreme version of a closed question. Closed questions are good for testing comprehension, but are not very good for generating a conversation. ¬†¬†Another very effective use of closed questions is a tool to guide the direction of a conversation, or a leading question (another taxonomy). ¬†The use of leading questions assumes that the conversion is deterministic, can be mapped, and the person being guided doesn’t react badly to being directed. Lawyers and salesmen use leading questions more often than coaches and mentors.

In many circles when people discuss whether a question is open or closed there is an assumption that open questions are prima facie better than closed and therefore need to be avoided. As with most extremes, this simplification is wrong. Both are useful but their primary purposes are very different.  Using one when the other is indicated tends to yield poor results.

Hybrids that combine open and closed questions try to get the best of both worlds. Asking a yes/no and why is a hybrid approach that is often used to test knowledge while generating a conversation.   I use this type of hybrid approach at the end of every interview I do for the Software Process and Measurement Cast.  I ask the interviewee what are the two (closed) things they would change and why (open). The closed part directs the answerer in a specific direction while the why provides the answerer with an open field to expand on why they think the material is valuable.

ORID Framework

Another method of characterizing questions is the ORID Framework.  ORID is an acronym for:

  • Objective Questions which reveal facts and reality. ¬†These questions are useful for setting the context.
  • Reflective Questions which tease out the relationship between data. Reflective questions tend to focus on the emotional aspect of relationships.
  • Interpretive Questions explore the sense of a situation by promoting critical thinking and analysis.
  • Decisional Questions prompt action. ¬†The questions prompt the person answering the question to examine benefits and the consequences of actions or inaction, and finally to make decisions.

The ORID framework is useful when preparing for a meeting or facilitation session. For example, having a facilitator in a storytelling session for a premortem (a storytelling technique often used for risk management) will need to have a pallet of seed questions developed before the session.  While these questions will be tailored based on the context of the session, having a base to draw from in each category allows the facilitator to focus more on the action than on writing questions on the fly!

Conclusion

In my basement, I have a 10 or 15 screwdrivers.  Each screwdriver is for a specific task, although I have experimented with using many of screwdrivers for other things than what they are supposed to used for.  Sometimes the experiment works, sometimes the experiment fails.  Questions are no different. Every good mentor or facilitator needs to have a pool of questions that can be used in any situation; however just having a pool of questions is not sufficient to be a good interviewer or facilitator.  In order to be sufficient, the questioner needs to know why they are asking the question and the outcome the question is supposed to elicit.

 


Categories: Process Management

Software Development Linkopedia May 2017

From the Editor of Methods & Tools - Thu, 05/18/2017 - 13:43
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about practical Agile, software developers types and interview, giving feedback, error handling for .NET, unfinished user stories, mobile testing with Appium, dealing with pesky people and the product owner role. Web […]

Asking Questions: A Coach’s Super Power or Kryptonite

Asking Questions Imply Listening

As coaches, leaders, change agents and even parents, the act of asking questions can take on an almost magical power to guide and change behavior. As with any powerful tool, when the tool begins to take on magical attributes, the users of the tool begin to forget that a tool is just a tool. ¬†At that point to quote, Ian Brown, ‚Äúthey just become a fool with a tool.‚ÄĚ Questions are a useful tool for a coach because questions:

  1. Show a behavior that can be modeled by others.  When you ask questions, you are showing others that it is valuable to seek information rather than just to provide opinions, knowledge, and information.
  2. Facilitate active learning by encouraging participation. The process of asking questions tends to elicit a response (unless you are talking to yourself) from the people you are interacting with.  Responses can come in many forms ranging from answers to follow-up questions. Regardless of the type of response, a response requires engagement that provides a basis for learning.
  3. Avoid raising barriers due to defensiveness. Making a statement establishes a position; if the listener has a strong opinion, statements can generate barriers between the listener and others.  Questions (constructed correctly Рthere are bad questions) draw out what the listener thinks without raising barriers.
  4. Bust the bias that presupposes knowing the answer.  When confronted with a problem or an issue it is often easy to immediately jump to a conclusion based on our experience or predisposition.  Asking questions allow the asker to challenge what we think we know rather than to accept what we think we know as truth.
  5. Assume uncertainty. Making a statement presupposes certainty, most real-life situations are far from certain. Therefore, asking questions can help to expose the difference between what is known, what is unknown and most importantly what we think we know and really don’t.
  6. Expose boundaries.  Most organizations are a series of boundaries.  Holacracy uses the metaphor of circles within circles.  Asking questions helps the questioner to define where the real boundaries are rather than relying on org charts or blundering around in the dark.  
  7. Expose vulnerability in a controlled manner. One of the most important roles of a coach is to expose and help to disarm team members’ vulnerabilities.  Rather than rely solely on observation or the Vulcan mind meld, questions are a tool to help identify pain and vulnerabilities.
  8. Stop a coach from talking. If you are listening (and not talking), as a coach, you will get in a lot less trouble!

Questions are not an end in their own right.  Every great interviewer Рsuch as Larry King?- understands that the question is important BUT the answer is what counts!  Asking questions is not an end but rather a means to an end!

 


Categories: Process Management

The Career Path of a Scrum Master

Mike Cohn's Blog - Tue, 05/16/2017 - 17:00

I blogged recently on the question of whether a Scrum team can ever get so good that they no longer need a Scrum Master. In this post, I’ll address a closely related topic: Assuming that the role of Scrum Master does not go away, what is the career path for a Scrum Master?

In my experience, a Scrum Master’s career will usually evolve in one of four directions.

Multiple and More Challenging Teams

A typical career path for a Scrum Master will start with serving one team. After a while that team becomes less time-consuming to work with, as issues are resolved and the team takes on more responsibilities itself.

At that point, a good Scrum Master will seek additional challenges. Often the logical next step is to begin working with multiple teams concurrently or from working with more demanding teams or products.

When developing new Scrum Masters, I prefer to put the person in a position to most likely succeed. That will mean working with a team that has neither any difficult personalities nor unrealistic delivery expectations. But, to go from good to great, the Scrum Master will need to learn to work under more complex conditions.

This leads to the philosophy that success is often rewarded with additional challenges.

Mentor

A Scrum Master who has been successful in a variety of different contexts and teams, might choose to move into a role as a mentor to other Scrum Masters. This will especially be true and feasible as the Scrum Master gains skills and experience.

In many organizations, this role would be called an Agile Coach, with the most common job description being that an agile coach coaches Scrum Masters (and their teams).

Personally, I’m partial to such individuals mentoring rather than just coaching. Much of the benefit these experienced individuals provide comes through them offering guidance (“I suggest you do it this way”). Because of this, I think of these individuals as having become agile mentors.

This is an appropriate path for Scrum Masters who have learned that their true passion is the creative act of developing a product--largely independent of whatever the product may be. Some Scrum Masters enjoy the process of enabling creativity among development teams so much that it almost doesn’t matter what the product is.

Think about the radio DJ who just loves being a DJ and doesn’t care if he’s playing classic rock, the current top 40, or classical music.

The Scrum Master who loves the process more than the product is a likely candidate to follow a career path into becoming an agile coach or mentor.

The Scrum Master Becomes a Product Owner

Other Scrum Masters, however, learn that they love what their team is building more than the act of creating it. Those Scrum Masters become good candidates to become product owners.

I don’t want to imply that a product owner role is above the Scrum Master role in an organization. I consider the roles equivalent in a typical organizational hierarchy.

But some Scrum Masters learn that they care deeply about the thing being built rather than the process of building the thing. And from having worked with a team long enough, some of these Scrum Masters learn enough about the product, industry, users and such to become good product owners.

The Scrum Master Becomes a Manager

Scrum Masters are most assuredly not managers themselves. But through their Scrum Masters duties, Scrum Masters often work closely with those who are. And some will find that work intriguing.

Scrum Masters become adept at guiding teams without much authority to say, “Do it because I say so.” Because of this, many can move into management roles where they could demand compliance but because of what they’ve learned from being Scrum Masters, know it usually is best not to.

Especially if a Scrum Master has retained technical proficiency, moving into a role like QA director or development manager can be a fulfilling, logical step.

Scrum Masters often become coaches, mentors, product owners, managers or continue as Scrum Masters in more challenging situations.

A Scrum Master Has Options

There are many paths a Scrum Master may pursue. The skills learned in becoming a great Scrum Master will serve that person well whether they choose to become a mentor, manager, product owner or just work with more challenging teams.

In some ways, asking what is the career path for a Scrum Master is like asking what is the career path of a professional athlete.

Some professional athletes use their former careers as springboards to move into broadcasting. Others use the money they’ve made to start businesses--where I live in Colorado, car dealerships and pizza restaurants seem popular with retired athletes. Some athletes use their fame to enter politics.

Still other professional athletes would find the topic of a career path preposterous. They didn’t become athletes as a path to something else. Becoming a professional athlete was the goal itself.

And so it will be for many Scrum Masters. The role of Scrum Master can be an end itself. Doing it more and better can remain the goal. A professional athlete cannot perfect his or her sport. A Scrum Master cannot perfect that skill either. There is always room to improve. And so, for many Scrum Masters, there may be no career path other than the continuous improvement in themselves that Scrum Masters demand of their teams.

Where Are You Headed?

If you’re currently a Scrum Master, what do you think is next for you? If you were formerly a Scrum Master, what you done since leaving that role? Please share your thoughts in the comments below.

SPaMCAST 442 ‚Äď Capability Teams, Software and Social Systems, Software Quality

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 442 features our essay on capability teams. The use of teams to deliver business value is at the core of most business models.  Capability teams are a tool to unlock the value delivery engine of teams.

Gene Hughson brings his Form Follows Function Blog to the cast this week to discuss his recent blog entry titled, Systems of Social Systems and the Software Systems They Create. We live in a complex world and just focusing on social systems or software systems misses the point!

Our third column is from the Software Sensei, Kim Pries.  The entry this week is titled, Software Quality and the Art of Skateboard Maintenance. This entry is an homage to Robert M. Pirsig the author of Zen and the Art of Motorcycle Maintenance, who recently died.

Re-Read Saturday News

And welcome back!  For those who are interested, The Frederick Half Marathon last weekend was great.  I met my goals: I crossed the finish line, collected my medal and got to hang out with my family in Frederick.  This week, we begin Part Two of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Part Two is titled Evolution At Play: Practicing Holacracy.  In my opinion, Part Two provides readers with the nuts and bolts needed to use Holacracy.  Chapter 4, titled Governance, takes all of the building blocks from previous chapters and starts to weave them together.

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes.  Reviews help guide people to the cast!

Next SPaMCAST

The next Software Process and Measurement Cast will feature interview with Brad Clark.  Brad and I talked about cost estimation, estimation in government and Cocomo II and what is on the way in Cocomo III.

 

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

 


Categories: Process Management

SPaMCAST 442 - Capability Teams, Software and Social Systems, Software Quality

Software Process and Measurement Cast - Sun, 05/14/2017 - 22:00

The Software Process and Measurement Cast 442 features our essay on capability teams. The use of teams to deliver business value is at the core of most business models.  Capability teams are a tool to unlock the value delivery engine of teams.

Gene Hughson brings his Form Follows Function Blog to the cast this week to discuss his recent blog entry titled, Systems of Social Systems and the Software Systems They Create. We live in a complex world and just focusing on social systems or software systems misses the point!

Our third column is from the Software Sensei, Kim Pries.  The entry this week is titled, Software Quality and the Art of Skateboard Maintenance. This entry is an homage to Robert M. Pirsig the author of Zen and the Art of Motorcycle Maintenance, who recently died.

Re-Read Saturday News

And welcome back!  For those who are interested, The Frederick Half Marathon last weekend was great.  I met my goals: I crossed the finish line, collected my medal and got to hang out with my family in Frederick.  This week, we begin Part Two of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Part Two is titled Evolution At Play: Practicing Holacracy.  In my opinion, Part Two provides readers with the nuts and bolts needed to use Holacracy.  Chapter 4, titled Governance, takes all of the building blocks from previous chapters and starts to weave them together.

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes.  Reviews help guide people to the cast!

Next SPaMCAST

The next Software Process and Measurement Cast will feature interview with Brad Clark.  Brad and I talked about cost estimation, estimation in government and Cocomo II and what is on the way in Cocomo III.

 

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

 

Categories: Process Management

SPaMCAST 442 - Capability Teams, Software and Social Systems, Software Quality

Software Process and Measurement Cast - Sun, 05/14/2017 - 22:00

The Software Process and Measurement Cast 442 features our essay on capability teams. The use of teams to deliver business value is at the core of most business models.  Capability teams are a tool to unlock the value delivery engine of teams.

Gene Hughson brings his Form Follows Function Blog to the cast this week to discuss his recent blog entry titled, Systems of Social Systems and the Software Systems They Create. We live in a complex world and just focusing on social systems or software systems misses the point!

Our third column is from the Software Sensei, Kim Pries.  The entry this week is titled, Software Quality and the Art of Skateboard Maintenance. This entry is an homage to Robert M. Pirsig the author of Zen and the Art of Motorcycle Maintenance, who recently died.

Re-Read Saturday News

And welcome back!  For those who are interested, The Frederick Half Marathon last weekend was great.  I met my goals: I crossed the finish line, collected my medal and got to hang out with my family in Frederick.  This week, we begin Part Two of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Part Two is titled Evolution At Play: Practicing Holacracy.  In my opinion, Part Two provides readers with the nuts and bolts needed to use Holacracy.  Chapter 4, titled Governance, takes all of the building blocks from previous chapters and starts to weave them together.

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes.  Reviews help guide people to the cast!

Next SPaMCAST

The next Software Process and Measurement Cast will feature interview with Brad Clark.  Brad and I talked about cost estimation, estimation in government and Cocomo II and what is on the way in Cocomo III.

 

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

 

Categories: Process Management

Holacracy: Re-read Week 5, Chapter 4. Governance

Book Cover

And welcome back!  For those who are interested, The Frederick Half Marathon last weekend was great.  I met my goal; I crossed the finish line, collected my medal and got to hang out with my family in Frederick.  This week, we begin Part Two of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Part Two is titled Evolution At Play: Practicing Holacracy.  In my opinion, Part Two provides readers with the nuts and bolts needed to use Holacracy.  Chapter 4, Governance, takes all of the building blocks from previous chapters and starts to weave them together.

Chapter 4, Governance

In Chapter 3 governance is described as a tool to help transform an organization from the current ‚Äúwhat is‚ÄĚ structure into the ‚Äúwhat could be‚ÄĚ structure. ¬†Governance provides the structure and discipline for work to be completed within the organization and the structure to address scenarios that will arise that cause tension. Robertson quotes David Allen, author and creator of Getting Things Done, on page 64 saying, ‚Äúthere is no freedom without discipline, no vision without a form.‚ÄĚ The governance meetings defined in Holacracy are a forum for teams and organizations to set, embrace, agree to be bound by the rules, so they become habit. ¬†Habit allows roles to interact without having to constantly refer to the rules, which reduces tension and friction between roles. ¬†Robertson uses a number of sports analogies to drive this point home. ¬†More illustrative to me is the game Monopoly. ¬†In my family, we have an agreed set of rules that are at least similar to the rules that were in the box when we bought it a few decades ago. ¬†The same can be said about how Monopoly is played in my brother‚Äôs, sister‚Äôs and sister-in-law‚Äôs house. ¬†The problem is that they are all slightly different. ¬†Any inter-family game requires deciding on whose rules we will be bound by. ¬†Even then there is always at least one discussion when play impinges on the rules a player is used to using. ¬†¬†When rules become habit, they become automatic. When they change, tension is generated that need to sorted out.

Governance meetings. Governance is fundamental (I actually thought reading was fundamental); it is the seat of the organizations power and all authorities and expectations flow from the governance process.  This is the most critical point in the chapter. Governance is actualized through the governance meeting.  The governance meeting process needs to be followed explicitly and typically happens on a monthly cycle (can be varied if needed).

There are two named roles in governance meetings, facilitator and secretary .  The tasks performed by the roles are fairly apparent.  The facilitator keeps the meeting moving and ensures the rules are followed.  The secretary records the actions taken by group.

Governance meetings perform a very specific set of activities:

  1.      Creating, amending or moving roles with the circle (see Chapter 3)
  2.      Creating, amending or removing policies within the circle’s domain.
  3.      Electing circle members to fill elected rules facilitator, secretary and representative link.
  4.      Creating amending or dissolving sub circles.

These four sets of actions are the only things a government governance circle meeting can do. Governance meetings are not a place for dealing with operational questions.

Governance Meeting Process

  1. Check-in Round ‚Äď The goal of this round is to ensure everyone is focused on the present moment. ¬†Round robin, everyone let peoples know what’s on their mind. No discussion, no crosstalk or responses. ¬†‚Äď The facilitator plays a critical role in keeping this round under control until the rules become a habit.
  2. Administrative concerns ‚Äď The goal of this step is to ensure the meeting participants know the administrative constraints. ¬†Administrative constraints include items such as who is on the phone and length of meeting (remember to start and stop on time).
  3. Agenda building ‚Äď This step builds the agenda for the meeting (not predetermined). Any circle member may add an item to the agenda that fit into one of the four set of actions. ¬†Operational issues do not belong in this meeting. ¬†No discussion or elaboration is allowed, just adding items to the agenda. ¬†Note: ¬†This step needs to be understood before performing or participants can become frustrated. The facilitator needs to cut off all discussion during this step..
  4. Iterative decision-making ‚Äď This is where the magic happens. ¬†The iterative decision-making set leverages a sIx-step process (again Robertson indicates that these steps should be followed exactly). ¬†For each agenda item:
    1. Present proposal,
    2. Ask clarifying questions,
    3. Deliver reaction round,
    4. Amend and clarify proposal
    5. Deliver objection round, and
    6. Integration round (deal with each objection revamp proposal for it to be acceptable)
      After the integration round go back (iterate) to the objection round until the proposal is acceptable or withdrawn.  Repeat until all the agenda is dealt with or time for this step expires.
  5. Closing round ‚Äď Each person reflects on the meeting one at a time ¬†without discussion. ¬†Depending on the size of the circle I suggest ensuring that the agenda includes 5 ‚Äď 10 minutes to address this step.

Governance meetings affect roles and policies.  Roles tell us who has the authority to take action and within which domain.  Roles should be documented so they may be referred at any time.  Remember the central tenants of a holacracy is that people and roles are separate and a person can play one or many roles, and those roles can change as demanded by the work.  Documenting roles make this flow of roles easier.  Policies are defined in holacracy as a grant or limit to authority to impact the domain of a circle/role. This means that providing someone outside the circle with the authority to work in your domain would be a policy.  For example, two of the roles in SPaMCAST media empire are content creator and editor.  On occasion one or both of those roles is play by someone outside of the SPaMCAST circle, this transfer of authority is a policy.

Near the end to the chapter, Robertson points out that Holacracy has a rule for how to break the rules so that individual action in times of tension.  Holacracy allows for the rules for decision making expressed as part of role to be broken when:

  1. It is believed the actual result will reduce more tension then it might create, and/or
  2. There’s no time to request permission that would normally required from other roles, and/or
  3. The action does not commit the organization’s resources or assets beyond what you are otherwise authorized to commit to.

After using the ‚Äúbeak the rule‚ÄĚ rule you must inform those that may be affected. ¬†If this pattern of activity happens multiple times it must be taken to the governance meeting to propose addition to the accountability of the role.


Categories: Process Management

Product Owner Role Problems: Part-time and Overly Controlling Product Owners

Control!

The product owner (PO) role is incredibly important in any Agile effort. The product owner leads, manages and prioritizes the backlog and networks with stakeholders, customers, and developers of all stripes.  All sorts of problems can beset the role. However, most of those problems are either self-inflicted or a result of poor organizational design.  A laundry list of problems based on observation and responses from other product owners include:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The next set of difficulties are:

  1. Allowing Part-time Product Owners:

The PO role has a large number of responsibilities. Each of those responsibilities can be decomposed into a larger set of tasks. ¬†For example decomposing the responsibility for ‚Äúprioritizing the backlog‚ÄĚ includes the actions needed to understand the item, then to understand the need for the item, the value of the item and then to document that value (even if that documentation is just to say it out loud in public). Each one of those steps takes time and effort; if a product owner doesn‚Äôt have that time, they will cut corners. ¬†This is often the case as identified by Chris Vedete, Product Owner for The Carlyle Group‚Äô ¬†

‚ÄúThe PO is likely not dedicated to just being a PO. That means they have a day job or other tasks they focus on. This could mean a PO isn’t as engaged as they should be, likely leading to project teams not getting feedback as quickly as they need.‚ÄĚ

Part time product owners are a study in cutting corners UNLESS the team or a team member provides support.  Angela Wick, author, and consultant from QA-Squared, suggested when recently interviewed for an upcoming Software Process and Measurement Cast that the business analyst is perfectly positioned to supplement the product owner when needed.

  1. Failure of the Product Owner to Lead:

A critical component of the product owner role is leadership.  The product owner’s role is critical in articulating and communicating the sponsor’s strategic vision. The vision is molded not only by how the PO talks about the vision but how the PO shapes the backlog, involves outside voices and facilitates collaboration. The product owner’s leadership shapes not only the product but also the culture of the team.  When product owners fail to lead, someone else will step into the gap and the outcome may not be what the organization needs or expects.  Product owner leadership failures are often the cause when teams discover mismatched expectations during demonstrations. The simplest and most effective solution to this problem is to replace the product owner.  Product owners that can’t, won’t, or do not have the time to lead should not be product owners; a better role might a subject matter expert providing expertise to the team. If the product owner can’t be replaced, other team members will need to help prop them up while actively helping them grow as a leader.

  1. Product Owner With A Controlling Personality:

One of the core assumptions of Agile is that team members will provide collaborative input into how the business problems they are committed to addressing are resolved. Product owners that are overly controlling end up talking in a fishbowl.  The team they work with will be a direct reflection of the product owner’s ideas and knowledge base. This undermines the value a team with a diverse knowledge and experience base can deliver. Product owners need to learn to ask questions rather than telling.  The questions need to be both non-self-serving and non-leading questions.  

The product owner role is hard. ¬†Kent McDonald, Product Manager and Writer at Knowledge Bridge Partners, stated that ‚ÄúThe by-the-book description of product owner that requires someone to be all knowing.‚ÄĚ Kent‚Äôs statement could lead us to believe that a good product owner needs to be a denizen of the Marvel Universe, organizations can avoid the nine problems impacting product owners. Part of the solution is awareness, part is ensuring the organization supports good product owner behavior, part is selecting the right product owner and the final SIGNIFICANT part is organizational design. In the end, we don‚Äôt have to make the product owner role any harder than it needs to be!

 


Categories: Process Management

Product Owner Role Problems: Proxies and Split Roles

Accept no substitute.

The product owner (PO) role even when performed as described straight out of the book is difficult.  The role is often even more difficult than it needs to be, with information asymmetries between the PO, the team and stakeholders ranging to ill-defined roles. I asked over fifty product owners about why they thought the role was hard to augment my perception. I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The next set of difficulties are:

5. Proxy Product Owners.
POs come from the business and are the voice of the customer.  As part of the role, POs prioritize the backlog and make far-reaching decisions about what will be built, configured or assembled. Sometimes someone other than the person that should be the PO is tapped to play the role. This occurs for many reasons.  One reason organizations select a proxy is that the PO role requires an amount of time and effort that might not be available from the right person.  A second common reason that IT and the business have not agreed on the need for the role.  Proxy product owners reduce the amount of business acumen available to the team while they are making the myriad of decisions that a team makes daily. Proxies can also reinforce the divide between IT and the business, increases the need for oversight and gate-like reviews, which don’t foster trust, slow decision making and increase cost.  Simply put, each Agile team needs a real product owner from the business, or they risk delivering the wrong functionality The solution for this issue is fairly stark.  Don’t accept a proxy product owner. One quick technique to recognize whether someone is a proxy is to determine if they need to get permission to make decisions.  If a proxy is all that your organization can deliver, leverage the person as a business analyst and leverage classic deliverable sign-offs and reviews to generate important decisions.  Rework will be higher and delivery rates will be slower, but what finally gets delivered will be closer to what is needed.

6. Adopting Both A Technical and Business Product Owner.
This scenario might be considered a special type of proxy product owner.  Organizations that adopt this approach are typically accepting and solidifying the hard boundaries between the IT and the business.  The problem (or at least assumed problem) that this solution addresses are the perception that the product owner cannot speak for or advocate for the non-functional requirements of a piece of work.  For example, I recently heard this approach justified with the explanation that the business product owner did not understand technical debt, coding standards, class structures, interfaces and hardware requirements(it was inferred that they did not want to understand).  No one in the organization wanted to address the underlying behavior.

A product owner must have a grasp of both the technical and functional components of their product.  This is another instance where the project/product conundrum seeps in.  It is easy to ignore or lean on someone else for a specific piece of knowledge if the need for that piece of information will go away sometime in the near future. Remember that projects have a stated completion date, while products do not. Teams and organizations need to educate product owners on the technical aspects of the work they are involved in delivering.  Product owners need to actively seek technical acumen to augment their business knowledge.  Failing a willingness to tackle the knowledge gap by either side having both a business and technical product owner might be the best pragmatic solution, but a solution that is significantly sub-optimal.

We continue delving into the problems that beset the product owner role in our next installment.


Categories: Process Management

Product Owner Role Problems: Proxies and Split Roles

Accept no substitute.

The product owner (PO) role even when performed as described straight out of the book is difficult.  The role is often even more difficult than it needs to be, with information asymmetries between the PO, the team and stakeholders ranging to ill-defined roles. I asked over fifty product owners about why they thought the role was hard to augment my perception. I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The next set of difficulties are:

5. Proxy Product Owners.
POs come from the business and are the voice of the customer.  As part of the role, POs prioritize the backlog and make far-reaching decisions about what will be built, configured or assembled. Sometimes someone other than the person that should be the PO is tapped to play the role. This occurs for many reasons.  One reason organizations select a proxy is that the PO role requires an amount of time and effort that might not be available from the right person.  A second common reason that IT and the business have not agreed on the need for the role.  Proxy product owners reduce the amount of business acumen available to the team while they are making the myriad of decisions that a team makes daily. Proxies can also reinforce the divide between IT and the business, increases the need for oversight and gate-like reviews, which don’t foster trust, slow decision making and increase cost.  Simply put, each Agile team needs a real product owner from the business, or they risk delivering the wrong functionality The solution for this issue is fairly stark.  Don’t accept a proxy product owner. One quick technique to recognize whether someone is a proxy is to determine if they need to get permission to make decisions.  If a proxy is all that your organization can deliver, leverage the person as a business analyst and leverage classic deliverable sign-offs and reviews to generate important decisions.  Rework will be higher and delivery rates will be slower, but what finally gets delivered will be closer to what is needed.

6. Adopting Both A Technical and Business Product Owner.
This scenario might be considered a special type of proxy product owner.  Organizations that adopt this approach are typically accepting and solidifying the hard boundaries between the IT and the business.  The problem (or at least assumed problem) that this solution addresses are the perception that the product owner cannot speak for or advocate for the non-functional requirements of a piece of work.  For example, I recently heard this approach justified with the explanation that the business product owner did not understand technical debt, coding standards, class structures, interfaces and hardware requirements(it was inferred that they did not want to understand).  No one in the organization wanted to address the underlying behavior.

A product owner must have a grasp of both the technical and functional components of their product.  This is another instance where the project/product conundrum seeps in.  It is easy to ignore or lean on someone else for a specific piece of knowledge if the need for that piece of information will go away sometime in the near future. Remember that projects have a stated completion date, while products do not. Teams and organizations need to educate product owners on the technical aspects of the work they are involved in delivering.  Product owners need to actively seek technical acumen to augment their business knowledge.  Failing a willingness to tackle the knowledge gap by either side having both a business and technical product owner might be the best pragmatic solution, but a solution that is significantly sub-optimal.

We continue delving into the problems that beset the product owner role in our next installment.


Categories: Process Management

Quote of the Month May 2017

From the Editor of Methods & Tools - Tue, 05/09/2017 - 15:02
What happens if you intervene and they still don’t fix the stand-up? Remember, the accomplishments and bumps are theirs, not yours. Agile works when they learn how to rely on one another. It has nothing to do with you looking good as a coach. So, if they do not improve, accept it for now, and […]

Why microservices fail

Xebia Blog - Tue, 05/09/2017 - 08:14

Gianna has joined Avidoo Inc., a productivity platform, as a senior software engineer. In a kick-off meeting with the rest of her team, she brings up the subject of microservices and whether the team has adopted them in any way. She immediately gets a strong reaction. ‚ÄúWe have tried adopting microservices, but they don‚Äôt work‚ÄĚ, […]

The post Why microservices fail appeared first on Xebia Blog.