FAQ on Career Path of Scrum Product Owners for Management

complex-product-backlog-product-ownerAs Agile and Scrum grows deeper into the market it is valuable for Management to communicate the rewarding and desirable career path that a Scrum Product Owner can have… even beyond just leading single Scrum Product Teams.

Before you go through this, it may be very helpful to first understand the following:

Eventbrite - Certified Scrum Product Owner Course (CSPO) - Get Certified in Atlanta, GA

Career Paths for Scrum Product Owners

Q. Are there multiple types of PO?  If so how are they different and how do they work together?

A. See earlier questions under “Product Owner Role & Organization” that describe how Release Product Owner and team Product Owner roles work as a team with a “single voice” on priority and acceptance decisions.

Q. What are possible steps in Product Owner career path?

A. A PO may start out working as part of a PO team as team Product Owner, or they may begin as PO for a single team product.

  1. Product Owner I – Trained Entry Level Product Owner
  2. Product Owner II – Experienced w/ Continuing Ed (From Score Card requires 12 months)
  3. Senior Product Owner – Release PO responsibilities for a major product; typically leading a PO team and/or working with multiple Scrum Teams. Should be both trained and experienced and meet continuing education requirements. 3-5 years combined program management, Agile/Scrum, and Product Owner experience.
  4. Principal Product Owner – TBD.  5-8 years combined project, program, Agile/Scrum, and Product Owner experience.

Q. What is difference in job title for RPO vs team PO roles?

A.  See Career path steps above

Q. What is the next step in the Career Path for a product owner? Is it to Product Management?

Q. What are some possible stepping off points into other jobs or roles?

A. Product Owners could potentially transition either to or from Development Management or Product Management. There are multiple paths to and from a Product Owner position. It could also be back to a prior contributor job or another professional position, or leadership role.

Q. What qualifies as continuing education and who needs to approve it?

A. Example Continuing Education Activities include:

  • Internal, onsite, or public Agile training classes
  • Agile topic meetings at local professional organizations
  • Agile workshops and seminars
  • National or International Agile software development conferences such as Agile 20xx

Management has budget approval of the individual’s costs for attending continuing education. The company’s Director, Agile Methods publishes guidelines for qualified continuing education activities and may review and revise these from time to time with input from Scrum Masters and management.

Q. What professional certifications are applicable to a Product Owner?

A. The Scrum Alliance offers one level of certification:

Q. Should the company support and pay for people to be certified?

A. Not necessarily, the company will pay for Product Owners to maintain membership and certification for approved professional organizations, but not necessarily to obtain CSPO certification.

Q. Is Certified Scrum Product Owner (CSPO) required to become and serve as a Product Owner?

A. No, Certification is not required for Product Owners but CSPO or equivalent training is.  See “What training is required…” question below under Inputs section.

Q. How is the pay scale determined for a Product Owner?

A. HR should determine market value for common industry jobs that are similar to product owner responsibilities

Q. What recognition and reward do I receive as a Product Owner?

A. Compensation and recognition for Product Owner position should reflect the level of responsibility and market value.


Q. Who is eligible to become a Product Owner?

Q. Who selects / approves Product Owner candidates?

A. Development Executives will ultimately determine who is eligible based on their confidence in an individual’s leadership abilities for Product Owners. Key stakeholders such as Product Managers should be involved in selection.

Q. Where would candidate Product Owners come from?

A. May come from BA’s, Developers, Development Manager, Product Manager, Project Managers etc. where Some have more industry experience and some have more technical experience.

Q. How does someone start out? What training or accreditation is a prerequisite?

Q. What training is required to become a Product Owner?

A. CSPO training or equivalent is required.  This may be satisfied by The company on-site courses taught following a CSPO based material, or by completing Certified ScrumMaster training plus one day of internal The company Product Owner training.

Q. Why should managers encourage their most qualified people to consider the Product Owner role?

A. For people who are seeking a challenging leadership growth opportunity this is a good opportunity for development. Product development quality and effectiveness is highly dependent on product owners to drive requirements through completion and is therefore a critical role for succeeding with Scrum.


Q. What are my options when I no longer want to be a PO?

A. See Pathways above, “There are multiple paths to and from a Product Owner position. It could also be back to a prior contributor job or another professional position, or leadership role.”

Good questions to pursue through training, self directed learning, and continuing education:

Q. How should product owners get input from stakeholders?

Q. How do product owners work across products to see that functionality syncs up & integrates properly?

Q. How do you blend customer commitments with feature work?

Q. How do management stakeholders get input into the backlog?

Q. How do PO’s work with UX/UI?

Q. How does the Product Owner engage with the UI/UX Teams on Customer Needs & Requirements?

Q. How does a PO develop acceptance criteria?

Q. How do Product Owners work across products together, especially if work done in different sprints for different teams?

Q. Are Product Owners focused on the current release, future releases, gathering customer feedback, etc?  Is that multi-tasking successful?

Q. Are there tasks Product Owners do today that would be better suited for a separate role such as Business Analyst or usability lead?

Q. How do you blend customer commitments with feature work? (Item we already had…suggestion was to include ‘and technical debt’.

Q. How does product owner deal with individual performance as an impediment?

Q. How does Scrum team give input to PO?

Q. What should a scrum team do if their PO is not fulfilling their part of the deal?

Agile Testing Days 2013 – Pure Joy @agiletd

2013.10.29-agile-testing-days-2013-2 2013.10.29-agile-testing-days-2013

It is 110% complete joy that I’m filled with whenever I come to Berlin to speak at this conference. I spoke in Berlin at Agile Dev Practices earlier this year and it was an honor to come back.

What is so unique about this conference is that in many regards it’s like returning to a family. Great people. Wonderful conversation. Unique venue. Awesome talks.

I’m already looking forward to seeing many of these people again… and we’re not even done yet!

What agile brings is a great culture of people. A community. If, for no other reason, the value of Agile is it’s vast community of caring people. What else matters?

FAQ on Most Common Product Owner Questions for Management

complex-product-backlog-product-ownerAs Agile and Scrum grows deeper into the market it is valuable for Management to communicate the rewarding and desirable career path that a Scrum Product Owner can have… even beyond just leading single Scrum Product Teams.

Before you go through this, it may be very helpful to first understand the following:

Eventbrite - Certified Scrum Product Owner Course (CSPO) - Get Certified in Atlanta, GA

Frequently Asked Questions on the Product Owner Role & Organization

Q. What is the Product Owner Role?

A. Product Owner is one of the key roles in Scrum that acts as the “single voice” for priority and acceptance of what to work on for a Scrum Development Team

Q. What is a Product Owner responsible for?

  1. Creates and Maintains the Product Backlog showing visible progress towards forecast results
  2. Prioritizes and sequences the Backlog according to business value as expressed by roadmap and stakeholder needs
  3. Prepares for each sprint and release planning session by working with team to elaborate Feature Stories into Minimal Marketable Features that deliver increments of value and User Stories that are appropriately sized for each sprint.
  4. Conveys the Vision and Goals at the beginning of every Release and Sprint.
  5. Represents customer and stakeholder interests. Engages and solicits their feedback to validate priorities and compromises.
  6. Participates in daily standup Scrums, Sprint Planning Meetings, Sprint Reviews, and Retrospectives.
  7. Accepts User Stories during the sprint to confirm implementation meets intent of acceptance criteria.
  8. Re-negotiates Sprint priorities and commitment when team communicates new discoveries that impact size or value of work.
  9. Communicates status to stakeholders including use of Visible Product Backlog for forecasting release content and dates.

Q. What is definition of Release PO versus Feature PO?

A. When a Scrum Product Team includes more than 2 Scrum Teams we have found that it’s more than one Product Owner can handle. In this case we suggest adding a Release Product Owner as a Product Owner Team lead.  The PO team covers all the responsibilities and activities of a Product Owner divided into RPO and team PO roles. 

Release Product Owner leads the PO team and is first and foremost responsible that the PO team presents a Single Voice

  • Clear statement of vision, direction, release purpose and goals
  • Managing overall Product Backlog and publishing the Product Backlog
  • Show alignment w/ product roadmap
  • Getting stakeholder buy-in on Product Backlog
  • Prioritization of Product Backlog
  • Prepare appropriate Product Backlog to drive release planning
  • Ongoing release plan forecasting
  • Deployment & release readiness checklist
  • Market launch split out to PM

Team Product Owner (or just PO) is a member of the Scrum Team responsible for working with the team from sprint to sprint and grooming the breakdown of Features into sprint sized User Stories so that they are prepared for Sprint Planning

  • Prioritize user stories to drive Sprint Planning
  • Acceptance criteria of stories in sprint
  • Day to day available to team for conversations about stories in sprint
  • Accepting stories in sprint

Q. When do we need this distinction versus having a single PO for smaller product teams?

A. Any time we have more than one PO assigned to a Scrum Product Team.

In some cases the RPO may also act as team PO for one of the Scrum Teams with assistance from additional team PO’s on other Scrum Teams.

Note that we recognize there is overhead incurred by introducing a layer with a Release PO as well as the team POs but have found it is worth it to avoid spreading a PO too thin across more than two Scrum Teams.

Q. If a product has a single PO are they also the RPO?

A. In as sense, Yes. When there is a single PO for a product they span the responsibilities of both RPO and team PO.

Q. Is the product owner a member of the Scrum Team?

A. Yes, Product Owners are considered to be a member of the Scrum Team.  See the definitions for “Scrum Team” and “Scrum Development Team” above.

Each Scrum Team should have a single Product Owner responsible for prioritizing work items for the Sprint backlog along with the corresponding acceptance criteria.  A Product Owner may be a member of up to 2 Scrum Teams. Conversely, each Scrum Team will have a single Product Owner as their input for what work to work on.

Q. Who is responsible for staffing the Product Owner role?

A. Product development quality and effectiveness is highly dependent on product owners to drive requirements through completion. Therefore, development management is responsible to staff a sufficient number of qualified Product Owners to satisfy the needs of each Scrum Team.

Q. Who should Product Owners report to?

A. Leadership over product lines and those who can help influence changes in products depending on market/client needs.

Q. What department should Product Owners report to?

A. Often this is business, and can look like the Product Management Group, sales, or even marketing.

Q. What reporting structure should Product Owners follow?

A. Release level Product Owners should report at an equivalent level to their development management peers. If the development manager(s) for people on the team(s) the PO works with report at Director or VP level, then the PO should report at the same level. Regardless of reporting structure, development management must have the authority to address any impediments. The preferred approach is for people acting as Release Product Owners to report into the Product Development organizational structure.

Q. Who should team Product Owners report to?

A. Team level Product Owners should report into the same department as their RPO.

Q. PO Role vs. full time position?

A. Full time role. It’s one of the most important and can easily take up 100% of their time to do it right.

Q. Is Product Owner a job title or a role that someone with an existing job title fills?

A. To be a release level Product Owner is a full time job that includes coordinating with stakeholders and managing dependencies in addition to working closely with the development team.

Q. Is team PO a full time job?

A. Yes, a team PO is also a full time job dedicated to success of their Scrum Team(s)

Q. How much time should a person expect to spend on Product Owner activities?

A. Full time job for both RPO and team PO’s.

Q. How many Scrum teams would we expect a full time Product Owner to handle?

A. A Product Owner should have no more than two Scrum Teams.

Q. Can one person be a PO for multiple products?

A. Not recommended

Q. Handling “Part Time Product Owners”?

A. Not recommended

Q. Handling “Distant Product Owners”?

A. PO’s assigned to teams should be co-located or at least be in a compatible time zone with their Scrum Team

Q. What is value of technical product owner versus a business focused product owner (and vice-versa)?

A. While in practice we recognize that people come to the PO role with different strengths, we don’t distinguish in the PO role based on their background; these are not recognized types of PO’s.

Q. If you are Product Owner what title would you have?

A.  Product Owner, (we’ll cover career paths next)

Q. What is common industry job title for product owner responsibilities?

A. Some typical job titles used in software development include: Program Manager, Technical Program Manager, Technical Product Manager, Product Analyst, or Product Owner

Q. What are the “lines” between the different roles, where does one stop and the next role start – PM/PO, PO/Business Analyst

A. Product Managers are responsible for a product roadmap that is detailed and aligned to corporate strategy. Product Owner is responsible for ensuring their product backlog is aligned to the roadmap.

Q. How much customer interaction is expected from a Product Owner? How is their interaction different from Product Managers?

A. Product Owners communicate with customers in a listening role to share backlog and results for checking understanding, and in order to solicit feedback. Sales and account management calls should be minimized, and are not considered a primary responsibility for the Product Owner role.

Product Managers communicates externally and across the company. Product Managers are responsible for the market message and communicating commitments and promises to customers.

Q. Where is management support to product owner role & backing their decisions?

A. In addition to coaching and budgeting for professional development and skill building activities management should:

  • Provide feedback on product backlog content, priorities, and dates with clear purpose
  • Support acceptance decisions the PO makes during each sprint
  • Management will route all work for teams through product owner to support single voice for work priorities
  • Manage consistent and qualified staffing for teams from sprint to sprint with minimal changes throughout a release
  • Key Stakeholders will provide clear direction on prioritizing to achieve corporate strategy and product management objectives shown in product roadmaps
  • Development Executives will support the PO in helping Key Stakeholders to understand and accept the necessity for making tradeoff decisions on dates and/or feature content consistent with actual team capacity

Q. Who are PO’s are accountable to?

A. Product Owners are accountable to the Key Stakeholders who make the financial commitments:

  • Business Unit President
  • CTO
  • Product Manager

Product Owners negotiate agreement to backlog priorities with these Key Stakeholders and keep them informed of any significant impacts or deviations from forecasts.

Q. What defines success for a for a product owner?

A. Profitable products and satisfied customers.

  • Product releases deliver great value as perceived by customers and stakeholders
  • Balances feature delivery with sustainable software development
  • Stakeholder and team members understand rationale for prioritization and forecasting is visible and transparent
  • There are no surprises on progress, feature content and dates, or priority changes made along the way
  • Scrum Team members feel meaningful accomplishment from delivering “winning” features
  • Continuously learning and improving use of agile principles and practices
  • Deliver a product that is aligned with the roadmap

Product Owner Competencies

Q. What are the qualifications to become a Product Owner?

Q. What levels of experience would they have?

Q. What ‘behavioral skills’ would they demonstrate?

A. The following Starting Competencies are needed to become a Product Owner:

  • Relevant background
    • Industry and/or application domain knowledge
    • Or experience in some parallel or related business field
    • Experienced in customer interactions
    • Excellent listening, verbal and written communication skills
    • Negotiation skills with ability to compromise and balance tradeoffs among multiple interests
    • Proven leadership and decision making
    • Professional presentation skills
    • Familiar with Agile and Scrum principles and practices

Q. What skills and experience do I gain as a Product Owner?

Q. What are the skills we need in a Product Owner?  Must those skills be in one person?

Q. What competencies should a Product Owner demonstrate?

A. The following Performing Competencies are needed to do the Product Owner job well:

  • Subject matter expertise and sufficient market knowledge to understand customer wants and needs
  • Manage product backlogs with priority decisions that mitigate risk and maximize value while showing steady progress towards forecast results
    • Manages backlog content consistent with priorities agreed to with key stakeholders
    • Provides a visible forecast and notifies stakeholders of any significant changes in effort or risk
    • Create Feature and User Stories that represent “vertical slices” of value
    • Collaborates effectively with Scrum Master and Scrum Development Team
    • Engage both team and stakeholders to collaborate in release planning
    • Inspires commitment by communicating clear vision, direction, purpose, and goal for each release and sprint
    • Approachable and available to team members to answer detailed questions about requirements
    • Understand and represent the interests of customers and stakeholders such as: customer service, sales, development management, and executives
    • Engages and solicits their feedback to validate priorities and compromises
    • Constructive Conflict Resolution
    • Demand / assure accountability
    • Effective planning and forecasting in spite of the inevitable uncertainty and unknowns
    • Understands and applys Agile and Scrum principles and practices

Balances new feature delivery with high quality software while minimizing creation of additional technical debt for sustainable software development.

[Next we’ll cover Product Owner Career Paths]

FAQ on Career Paths of ScrumMasters for Management

scrummasters As Agile and Scrum grows deeper into the market it is valuable for Management to communicate the rewarding and desirable career path that a ScrumMaster can have… even beyond just leading single Scrum teams.

See our first post on ScrumMaster basic FAQ for Managers

Before you go through this, it may be very helpful to first understand the following:

Eventbrite - Certified ScrumMaster Course (CSM) in Atlanta, GA - Bring a Friend = iPad!

Frequently Asked Questions on the ScrumMaster Career Path


Q. What are possible steps in ScrumMaster career path?

A. There is more than 1 step on a ScrumMaster path including:

  1. No title appended – Entry level working ScrumMaster with CSM training < 12 months experience
  2. ScrumMaster appended – Qualified working ScrumMaster with > 1 year experience plus 2 days of continuing education per year of experience (per Scrum Score Card)
  3. Senior ScrumMaster – Full time ScrumMaster position handling multiple teams, often also acts as ScrumMaster for a Scrum of Scrums.  Demonstrates learning additional knowledge and greater experience than #2. ScrumMaster
  4. Coach ScrumMaster – Full time ScrumMaster who is booked on a regular basis to coach and train other teams, sites, and/or groups.  Demonstrates additional coaching qualifications beyond #3. Senior ScrumMaster

Q. Does this career path include the Senior ScrumMaster?

A. Yes, but it’s not a necessary step to the Coach ScrumMaster level

Q. Do we need a different career path to get to be a Senior ScrumMaster?

A. No, that is one possible step on the ScrumMaster path

Q. How does this relate to other careers in Product Development?

A.  ScrumMaster may be an add-on role to another product development job such as Software Engineer and may be considered favorably for advancement to other positions such as management.

Q. What are some possible stepping off points into other jobs or roles?

A. Some possible stepping off points include other leadership roles such as a manager job or Product Owner role.  Someone may also choose not to continue as a ScrumMaster and continue to progress in their chosen position as a development contributor.

Q.  How does Certified Scrum Developer fit into ScrumMaster career path?

A.  CSD fits into Software Engineer Career Path rather than this ScrumMaster path.  It would be a definite plus for a Certified ScrumMaster who is also a programmer to become a Certified Scrum Developer.

Q. Does a ScrumMaster career path lead to a management position?

A. Maybe.  Excellence as a ScrumMaster requires good leadership and people skills which are also critical in a management role. The ScrumMaster career path has multiple possible outcomes and we don’t suggest that any of them indicates greater success than another outcome. One possible outcome is accepting the challenges of a management position instead of ScrumMaster.  Note that it is considered a conflict of interest for a ScrumMaster to at the same time hold a manager position.

Q. Will experience in a ScrumMaster role be a requirement for progress into Management?

A. No.  It’s not a necessary pre-requisite to management.


Q. Who is eligible to become a ScrumMaster?

A. Really anyone. But look here for best ScrumMaster characteristics.

Q. Who selects / approves ScrumMaster candidates?

A. Development Managers will ultimately determine who is eligible based on their confidence in an individual’s leadership abilities and their enthusiasm for improving agile development. Our biggest concern first is always putting the right people on the right teams, including a ScrumMaster. We use Team Science to do this. Find out more here.

Q. Where would candidate ScrumMasters come from?

A. People can volunteer to be ScrumMasters or be nominated by management

  • Needs to be voluntary, even if Management suggests or nominates a person.
    • Individuals volunteer or express interest (manager can decline)
    • Managers can identify candidates with skills (individuals can decline)

Q. What levels of experience would they have?

A. ScrumMasters should have experience in a software development job such as programmer, tester, or business analyst.  Ideally they would already have some experience as a Scrum team member.

Q. What ‘behavioral skills’ would they demonstrate?

A. Some of the more important behavioral traits include:

  • leadership
  • good communication
  • good people skills
  • facilitation
  • organizational skills
  • conflict resolution
  • negotiation
  • courage
  • assertive
  • coaching

Q. How does someone start out? What training or accreditation is a prerequisite?

A. The first step on a ScrumMaster path requires CSM training and a 6 month commitment to serve as a ScrumMaster after management approval

Q. Why should managers encourage their most qualified people to consider the ScrumMaster role?

A. ScrumMaster is a crucial role for succeeding with Scrum. A highly qualified person who has both the respected technical skills and behavioral traits can raise the performance of the whole team in the ScrumMaster role.

Q. What about people who are trained and qualify as ScrumMasters but are not currently assigned to a team.

A. People may also be qualified and ready to serve but working as a regular team member until they are asked to serve as ScrumMaster on a new or different team.  Qualifications and “active reserve” status will be documented for backup ScrumMasters in the on-line list of company ScrumMasters.


Q. What will happen if I want to go back into the team?

A. It is OK for people to decide they don’t want to continue in the ScrumMaster role.  However, new ScrumMasters should commit to serving in the role for at least 6 months.

Q. Who “pulls” a ScrumMaster if they are unsuccessful in the role; team or management?

A. ScrumMasters need the trust and confidence of both management and their team.  ScrumMasters serve the team and a team can ask for a different ScrumMaster if the entire team agrees.

FAQ on Most Common ScrumMaster Questions for Management

scrummaster-retrospective-management-agileAs Agile and Scrum grows deeper into the market it is valuable for Management to communicate the rewarding and desirable career path that a ScrumMaster can have… even beyond just leading single Scrum teams.

Before you go through this, it may be very helpful to first understand the following:

Eventbrite - Certified ScrumMaster Course (CSM) in Atlanta, GA - Bring a Friend = iPad!

Frequently Asked Questions on the ScrumMaster Role

Q. Is ScrumMaster a job title or a role that someone with an existing job title fills?

A. It is first and foremost a role in Scrum but may also be used as a title where a person is filling that role for multiple teams and it becomes a full time job.

  • ScrumMaster is a role that may be appended to a regular job title

Such as: “Sr. Software Engineer – ScrumMaster”

  • And in the case of a “full time” ScrumMaster it may be their entire job title.  Such as: “ScrumMaster”

Q. Can it be a role and still have a career path?

A. Yes, today a typical “career path” at looks something like: I – associate, II – junior, III – senior. The ScrumMaster “path” looks more like steps or supplements added to other job title oriented career paths.  It may have options and branches rather than just a “ladder” with various levels.  A ScrumMaster could also start as backup for primary on a team.

Q. How do you add it to your tile on email, business card etc?

A. Yes ScrumMasters who meet the qualifications outlined for this career path may append “- ScrumMaster” to the regular job title.  They may also show CSM or other certifications from recognized professional organizations.

Q. What models for ScrumMaster and team should we consider?

A. Valid options for ScrumMaster working with a team include:

  1. Full time ScrumMaster who fills the role for one or two teams and/or Scrum of Scrums
  2. Part time working ScrumMaster added to responsibilities of functional job title (not ideal as a SM should be focused primarily on one team.

Q. Is a ScrumMaster on the team – are they considered a team member?

A. The ScrumMaster is a team member. They could contribute either as:

  1. A working member of the same team where they contribute work in addition to filling the ScrumMaster role. This is currently the predominant pattern at the company: “I like a ScrumMaster to be a working team member.  I believe it gives them better insight to the problems/impediments that exist and a closer relationship, which builds trust, with the team itself.”
  2. A facilitator on the Team.  This is the case for “full time” ScrumMasters, and it’s also possible they could fill the role for one team while working as a contributing member of another team. Note that some people suggest that this allows the ScrumMaster to be more objective and impartial in coaching the team.

Q. What is a ScrumMaster responsible for?

A. “While a ScrumMaster does not assume responsibility for the success of the project -that remains with the team – a ScrumMaster does assume responsibility for the team’s adoption of Scrum and practice of it.”

Q. How much time should a person expect to spend on ScrumMaster activities instead of primary job title activities?

A. A ScrumMaster should make this role their top priority to focus on benefits to the overall team. Their load will vary from sprint to sprint depending on what impediments and issues the team is dealing with. Newly formed teams typically take more ScrumMaster time; 50%-100%, while experienced ScrumMasters with established well functioning teams might spend 50% or less of their time on the ScrumMaster role.

Q. How many Scrum teams would we expect a full time ScrumMaster to handle?

A. One or at most two teams.  See question above about how much time.

Q. If you were a “full time” ScrumMaster what title would you have?

A. “ScrumMaster” when not appended to another title would mean that it is a full time responsibility.

Q. Would the title for a Scrum of Scrums ScrumMaster typically be a Project Manager?

A. Not necessarily.  Only if the person previously had Project Management qualifications and experience in which case they could have a “Project Manger – ScrumMaster” title, otherwise their title would just be “ScrumMaster”.

Q. What skills and experience do I gain?

A. ScrumMasters exercise and develop their leadership and interpersonal skills along with training and continuing education in scrum and agile development.

Q. What qualifies as continuing education and who needs to approve it?

A. Example Continuing Education Activities include:

  • Internal, onsite, or public Agile training classes
  • Agile topic meetings at local professional organizations
  • Agile workshops and seminars
  • National or International Agile software development conferences such as Agile 2010

Management has budget approval of the individual’s costs for attending continuing education. The company publishes guidelines for qualified continuing education activities and may review and revise these from time to time with input from ScrumMasters and management.

Q. What professional certifications are applicable to a ScrumMaster?

A. The Scrum Alliance offers several levels of certification:

  • Certified ScrumMaster CSM – required to serve as a ScrumMaster
    • 6 month commitment to serve as a ScrumMaster at the company
  • Certified Scrum Professional CSP – 3 year of experience to qualify
    • 12 month commitment to serve as a ScrumMaster
  • Certified Scrum Coach CSC – > 5 years of experience to qualify

Q. Should the company support and pay for people to become certified?

A. Yes, The company will support and pay for Scrum related certifications based on the ongoing commitment from the individual to apply the certified skills as outlined in the prior question on applicable certifications.

Q. How does this affect desire for certification in other jobs and roles?

A. In the future we should answer this question as we define career paths in other areas based on the value and relevance to each role or position.

Q. Is certification required?

A. CSM is required to become and serve as a ScrumMaster.  Additional Certification is not required but is supported and encouraged. Continuing education is required for active ScrumMasters to spend at least 2 days a year on improving their knowledge and skills for agile software development.

Q. Will the company pay for advanced certifications?

A. Yes, based on individuals continuing commitment to serve as ScrumMaster using the certified skills

Q. What recognition and reward do I receive?

A. Opportunities for recognition and reward include:

  • Recognition from management and team members
  • Extra Career Development & training opportunities
  • Participation in the company ScrumMaster Community
  • Resume building
  • Certification

Q. Should there be a financial reward for being a ScrumMaster?

A. Additional financial compensation for ScrumMasters who take on this role in addition to an existing job title may be appropriate to recognize the added commitment and responsibility expected from ScrumMasters. Development management and HR should consider their existing position and compensation to determine the appropriate amount.

Note opinions are split on this point. There is value in this to consider that; being a ScrumMaster “feels like a thankless job” and also to make the management’s commitment to the role more tangible.  The counter argument was “is this necessary?” This would be a plus but was not necessary.

[In our next section, we cover Career Paths]

Being an Agile Coach – Making Effective Decisions

change-ownership-agile-decisionsMAKING EFFECTIVE DECISIONS

Decision-Making is obviously one of the major functions of the Agile coaching process.

Myths of Decision-Making:

  1. The higher up the decision is made the better it is. So, if the President makes the decision it is obviously a better decision than a decision made by a Vice-President. This is not better because we will be moving back to centralization where one person dominates everything. Decisions tend to naturally go up the organizational chart eventually anyway.
  1. The longer we consider a decision the better the decision will be. This is not always the case. But decisions can grow stale and stagnate if dwelt upon too long. The more complex the issue, though, typically more time needs to be allotted… not to think… but to experiment!
  1. A good decision made late is better than a mediocre decision made early. A decision that will really benefit a team needs to be made early rather then last minute. Precious time is often wasted in the lollygag scenario. Time factors often dictate that a decision must be made. And even if the best decision is not made, at least a decision was made in time.

Causes of Ineffective Decision-Making:

  1. The lack of clearly-defined goals and objectives. People don’t act because they don’t know which direction to go. Decisions can’t be made to do things that haven’t been previously decided to do.
  1. Insecurity of position or authority. Decisions are postponed because the leader  is afraid of the possible consequences.
  1. Lack of information – no alternative seems clear OR all alternatives seem viable.
  1. Desire to retain the status quo or simple fear of change – there is comfort in the comfort zone. But still, because things change and the team needs to develop and change as the market changes.

The Problem-Solving Process of Decision-Making:

Decisions are made, typically, to solve problems:

  1. The orientation to the situation – we get familiar with the background of the problem. Analysis, experience, training, skill, and administrative intuition are helpful in determining the truth of the situation.
  1. The identification of key facts – we will never have all the facts but we can get the facts that truly identify the reality. Utilize effective questioning. We want to ask “open” questions that will give us information rather than a simple yes or no. Carefully sift through the information and deduce logically
  1. The identification of the major problems in the situation: Look for the causes of the effect that have been seen or demonstrated. Why are things happening the way they are? What caused this issue? Again, carefully sift through the information and deduce logically. Get insights from others who can give information from another perspective.

Often, the unique situation you are in requires you to do a lot more research and problems solving to help leaders make good decisions… At the end of the day though, I would suggest, always taking an empirical approach. Experimentation is key. The more you experiment… the more you can learn quickly!

Being an Agile Coach – Dealing with Conflict


The word “conflict” tends to stir up emotions in corporate America. Few companies want to find themselves in conflict. Most employees will view conflict as a bad thing and something to be avoided at all costs. But some conflict can actually be healthy. The reality is that disagreements do not have to turn into fights. We can keep our differences in check if we have a few basic understandings regarding conflict. Conflict occurs when two or more people with mutually exclusive viewpoints attempt to solve a problem.

Two kinds of Conflict (healthy and unhealthy)

Conflict is unhealthy when it negatively impacts the company or team by hindering or limiting their ability to do productive work.

Conflict is healthy when the opposite occurs. When conflict is viewed and handled appropriately.

We know conflict is unhealthy when:

  • People no longer calculate their remarks to edify or change others. Instead, they plan their remarks (often unconsciously) to hurt, demean, defame, or even destroy another
  • People begin to question whether their relationships can weather the storm of difference
  • People feel rejected by those who were once considered friends
  • People feel they have no control and the odds are against them
  • The pain of the competition is greater than the exhilaration of the challenge
  • People make accusations, and it seems that “others” want to destroy or split relationships down the middle.
  • People use words that have violent connotations

Conflict is healthy when:

  • The people involved feel confident they can manage the differences
  • Those involved adhere to firmly to decision-making processes authorized by the team and working agreements of the company
  • People operate within the specifically stated, generally understood rules of appropriate behavior in the company
  • People cooperate in the process suggested by the leadership

Reactions to conflict

  • Conflict is wrong.

Some individuals believe that conflict is always wrong. The mindset is that people in a copmany should be in agreement and live in harmony. They become nervous when team members express differences of opinion. They “lovingly” try to encourage people into one opinion. The attitude does not acknowledge that legitimate differences can exist among different people.

  • Conflict is an opportunity to exercise power.

Some people view any discussion as debate and any issue as a time to win at any cost. These people get their thrills in the competition of the moment. Winning the issue is oftentimes far more important than the issue itself.

  • Apathy (this doesn’t involve me)

Some people do not care much about the outcome of the issues involved. The apathetic spirit comes from several sources including burnout, fatigue, stress, a defeated spirit, or a different set of priorities.

  • Personal affect (this does involve me)

Some people do have a considerable stake in the outcome. These often include the leader, staff, board members, managers, and other directly involved individuals. People often believe that the outcome will affect their reputation and/or their feelings of self-worth. Oftentimes the emotional involvement clouds an individual’s reasoning and judgment surrounding an issue.

  • Conflict might split a company

Some people become nervous when any disagreement occurs in a company or team because they believe it will divide the team needlessly. These individuals many have vulnerable feelings left from past conflict that was handled in a hurtful way. Whatever the reason, they tend to sweep all controversial issues under the rug and hope they go away. They would rather stay in a bad situation than risk the unknown.

Responses to Conflict Continue reading “Being an Agile Coach – Dealing with Conflict”

Dallas Scrum Meetup – October 9 – Come for Free Loot (and some fun)!

team-science-company-exampleThe Science Behind High-Performance Teams

  • 6:30 PM

  • Active Network

    6363 N State Highway 161
    4th Floor (Conference Center)
    Irving, TX (map)

The scientific evidence is quite clear: To enable high-performance, you have to look at leveraging human capital and optimizing human potential. Let’s take a deeper look at the science behind creating high-performing teams by looking into behavioral science, neuroscience, and social psychology.

  • *What is a High-Performance Team?
  • *Self-Organization – Not what you think …
  • *Behavioral Science
  • *Neuro Science
  • *Social Psychology
  • PETER SADDINGTON owns a successful research and analytics consultancy and has been integral in multi-million dollar Agile Transformation projects with some of the biggest Fortune 500 companies, including Cisco, T-Mobile, Capital One, Blue Cross Blue Shield, Aetna, Primedia, and Cbeyond. He is a sought-after speaker at many industry events and is a Certified Scrum Trainer (CST). He has also received three master’s degrees, one of which is in counseling, and provides life-coaching services in addition to his consultancy.
  • Peter loves giving away free stuff. He will be giving away:
  • – Copies of his book The Agile Pocket Guide – http://amzn.com/1118438256
  • – Apple Gift Cards!
  • You can find Peter Saddington in Dallas every other month doing public courses in Dallas. His next courses are October 10/11 and December 5/6 – https://dallas-scrum.eventbrite.com/

Make a 15 Minute Daily Scrum Pure $1,500 Cash (Whaaaat???)

daily-scrum-giveaway-1500-3d-printerIf you haven’t already taken the 2013 State of Agile Survey, definitely check this out…

Now in the final 2 weeks’ stretch, VersionOne is trying to get at least 1,000 more people to take the survey. In doing so, they just announced an expanded prize offer – For the first time ever, the grand-prize winner of the drawing can choose to win this 3D printer OR just take the cash – $1,500. Plus lots of other cool swag.

The idea is this: the bigger the data sampling, the more value peeps will get from the report, which has become the largest and most cited survey in the agile community. The State of Agile Survey helps software professionals (that’s YOU) make tough decisions and get the most from their agile initiatives.

Take the survey before it closes on Oct. 16th and your email address automatically goes into the drawing.  While you’re at it, try passing it on to at least 5 of your software peers (don’t worry; if you don’t forward it, nothing bad will happen to you!)   #StateofAgileSurvey.

Agile – Preparing to Make it Work for Your Organization – From Agile Practitioners

v-for-vendetta-agile-UK-parliamentThe term “Agile” is fast becoming a more common word within the software development community. It’s growing, morphing, being attributed to successful projects, and also being blamed for unsuccessful ones. What comes to mind, for many, when considering Agile as a tool to be used for teams, companies, projects, and products alike, is whether there truly is enough hard evidence around the value of adopting Agile methods.

I would believe it fair to say that there are a lot of doubts and misconceptions around Agile. Do any type of search for examples of Agile success on Google and you’ll find the web short of concrete evidence to support their claims. More often than not, you’ll find success stories that are very specific to a particular demographic, team, company, environment, and situation. Moreover, you’ll find critics of Agile methods and their viability. There seems to be no real foundational 12-Step program to implementing Agile successfully, and there will never be one.

This paper is not going to have all the answers for you. It is not intended to be that. Rather, this paper is an opportunity to take a deeper dive into how you can get started with resources that can help you take your first steps into Agile. Prepare yourself to plan for the change you desire in your team or company, and eventually, help you have the right types of conversations with your management.

I’ve recruited 4 other thought-leaders within the Agile space to help me take in the fuller picture of Agile and what considerations we need to have as we progress towards Agile. I’ve chosen practitioners, not theorists. People who are in the deepest trenches of Agile transformations and adoptions. It is from this lens that I want to people to view this paper. Much has been written about things to consider when adopting Agile to the enterprise and this paper does not belong to that group. This is a view from practitioners, giving you only what is applicable, and executable.

It is fair to say that Agile CAN work for your organization, but it isn’t easy. Let’s take a deeper look into what practitioners of Agile have to say and dive into the deep end with us.

Our contributors:

Agile – What is it Anyway?

An easy click over to the Agile Manifesto tells us pretty clearly what the guiding principles are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

But what about applying these principles? How do you execute within a complex organization? Some light research has been done around what Agile means to many people. It was found that at the end of the day, Agile, to many, is collaboration and cultivating culture within an organization. Derek Huether would agree with this, saying that, “Agile is the embodiment of empowerment and responding to change.” Meaning, that Agile is simply a term for what businesses and even individuals should strive for: A continued state of being flexible and enabled to change accordingly.

For Don Gray, “Agile is what I call, A high order of abstraction. You cannot put a pound of Agile in a wheelbarrow. Agile can be understood by the Manifesto. That’s a good place to start.” It would seem that many organizations are adopting some facets of Agile at this point. You may not even need to call it “Agile.” In reality, it may be just improving something. Mike Cottmeyer agrees with this an states that, “Agile is a set of principles, 4 principles in the Agile Manifesto expressed through family of methodologies from which the methods are derived from principles. In the end it’s about the Manifesto.” It would seem that how you apply that is a different matter.

“Agile in a lot of ways, represents two different things, approaching and developing projects and products. The belief system from the Agile Manifesto: Being flexible, and being open to how you approach projects. Secondly, Agile is new way of thinking of how to develop projects. Prior to Agile, there wasn’t a codified method. I believe there still is a lot of evolution that needs happening. People will learn and new things will be added to Agile-thinking,” – Chris Goldsbury

Bottom Line Around the Term “Agile”

Agile  is a set of principles, a way of considering approaching projects differently, being flexible, and creating a culture of collaboration. In a sense, Agile is all about being open to new ideas.

Adoption or Transformation? – Should Your Company “Adopt” or be “Transformed?”

Often times we hear about “Agile Adoptions” or “Agile Transformations.” Is there a difference? Our practitioners say yes. “People don’t agree on what Agile means because often they don’t have a common definition of how to apply it,” Don states. “For me, adoption of Agile is taking on principles. Transformation is a more embedded process.” Mike adds to this in that, “Adoption is about the things you do. gaining benefit is the transformation. Transformation is a look into the total organization as a whole and more importantly, the cultural transformation that needs to happen.”

It’s apparent that “adoption” and “transformation” are not the same thing. While the term “Agile” may be a mindset of openness and collaboration, how you undertake that in your business, enterprise, or team is a matter of what you’d like to see happen.

In regards to adopting Agile. “Absolutely yes,” Mike states. “There are certain principles and constructs behind Agile that are inarguable. Most organizations can benefit from doing some parts of being Agile. It really is a matter of whether your company can you do the right things in your org to make Agile successful.” One has to be mindful about the current reality of your organization or situation. Take a good look at where things are. “Be flexible,” Chris adds, “You generally get better success when you’re flexible and open to change.” 

Derek adds some noteworthy insight to this and comments that “Yes, absolutely, try Agile. But it starts on an individual level. There are people that want to be Agile, or be naturally Agile, but then there are individuals who don’t desire for that. There are people who don’t want to be autonomous, but want to be the cog. You don’t have to respect it, but have you have to accept it.”

Individual Readiness Is A Part of Change

“The first step is transformation of the individual…The individual, transformed, will perceive new meaning to his life, to events, to numbers, to interactions between people.” – Edward Deming – System of Profound Knowledge

As an individual reading this paper, you probably want positive value-add change to your organization. First and foremost, change starts with you. Communicating Agile principles and practices are great, but it really takes a servant leaders attitude to be the conduit for positive change from yourself out to your environment. Chris says that you should always look into your situation clearly, and see what is really needed. Be flexible and be prepared for tough questions, pushback, and a potentially long road ahead. If you are dogmatic about your approach then it will not work. Chris has seen a lot of people doing this, pushing a philosophy. Not taking the time to understand the business culture, readiness, and even how it will impact the customers.

Derek adds that he enjoys seeing small wins happen over time, than no wins at all. “Is it a full Agile adoption? No. Usually there are constraints on an environment that will not allow full adoption or areas of the environment that are conducive to being Agile.” In a lot of ways it is about perception. How you effectively communicate value is so important. “Small businesses are more conducive to Agile. Less overhead, less process, and less governance you’re working against. The larger the enterprise, if you are dealing with that as a standard, the harder it can be. But not as the exception.” 

“Never attribute to malice or stupidity that which can be explained by moderately rational individuals following incentives in a complex system of interactions.” – Hubbard’s Corollary to Hanlon’s Razor

As you prepare, remember that you are interacting within a complex system of people. “To create something new is where Agile lies. That creates discontinuity.” Don states. You are on the cusp of something new and fantastic. To become a change agent is exciting, but it can also be daunting.

Chris adds that you need to be sometimes painstakingly cautious about your approach. Meaning, you will have to take baby steps in some organizations. “Lead by example. Demonstrate Agile. If you are a manager, that may mean giving up the empire underneath you.” What Chris is talking about is referent power: The power that doesn’t come from people that directly report to you. “When people want to be led, they choose who they want to follow.” How this may apply in your organization is to raise up internal champions for Agile. Whenever you come upon a new problem or consideration, it may not be you who needs to fix it! A different leader may need to be chosen. “If you find yourself making all the decisions all the time, then there is something wrong with that.”

 Bottom Line: Do Adopt Agile, Transformation is the Long Road

All our practitioners agree that all companies should adopt the mindset of Agile. Any and every organization can benefit from being open, flexible to change, and creating a better collaborative place to work. One could agree that all of these are great ideas. Now, how do you apply or transform an organization? We’ll jump into that next.

Should Your Company Adopt Agile to be Transformed?

This is where the rubber meets the road, and where many companies have failed. Giving lip service to a set of methods, ceremonies, artifacts, and practices will have you driving down a long road of disillusionment, burn-out, negativity, and suffering. Sounds harsh? Probably because it’s true.

 “The righter you do the wrong thing, the wronger you become.” – Russell Ackoff, Organizational Theorist, Author and Co-Author of 31 books

I was very encouraged to hear from all four of our guest contributors the same question: “Why?” – Any good beginning starts with the question of why you are doing it: “Why would you want to do Agile? Increase customer satisfaction? Increase quality? How are you measuring these things? Let’s start with some fundamental assumptions around change. When you adopt Agile you are talking about how we change the way we do something,” Don asserts. “So the real question is what do you want to do? If I’m looking at improving time to market, quality, and increasing customer satisfaction, that is something we can measure.”

“An improvement program must be targeted at what you want, not at what you don’t want.” – Russell Ackoff

If a company truly begins to look at the reasons around why they want to become more Agile, the more focused they will be in their strategy to know it, apply it, and internalize it as a business culture. Start by understanding where your company is today and ask tons of questions. Questions like:

  • Why do we really want to change?
  • What does success look like?
  • What data will be able to support value-added changes to our business?
  • What problem are we trying to solve?
  • What is the goal we are trying to achieve?
  • What is the target we are trying to hit?
  • Does our company desire increased transparency throughout the business?
  • Is our company environment and culture support increased collaboration?
  • Does management and leadership support change?
  • Does our company culture support more flexibility?
  • Is our company organizational structure and culture in alignment?

These are tough questions to ask, but our coaches agree that if you don’t ask these types of questions before you embark, you may find yourself in a place that was neither helpful for your company, nor valuable for your customers.

“You have to build a culture, or have a culture that supports ‘being Agile.'” Derek says. “There may need to be a leadership change, and a cultural change, meaning that there need to be people to support that change.” Chris adds that if you go into a company and think that you can to push something down their throats it won’t work. If you’re dogmatic about your approach you won’t succeed.” He goes on to say that: “I see a lot of people doing this. pushing a philosophy. Not taking the time to understand the business and their customers.”

Agile Isn’t a Good Fit If You’re Not Willing to Change

“Creativity is a discontinuity.” – Russell Ackoff

Agile in total is creating something new. Agile is a new way of thinking. Agile is introducing change into a system. “Anytime to introduce change into a system, things can get all messed up. People go through a period of chaos, and until it becomes normalized, things are going to be weird. A good coach normalizes the experience of change in a company” says Don. Mike adds that “Certain principles of Agile that are transcendent. I think that Agile is a good fit when you are delivering some tangible product or a good fit when you’re dealing with problem domains where either you don’t know the direction your heading, or you need to figure it out as you go. It may be that it’s not even valuable to figure it out up front because you need feedback. If you have brutal top down organization with heavily matrix’d projects structures… it might not work.”

Some organizations are already Agile because they are already set up in a way conducive to Agile. Meaning they fully embody the culture of collaboration, communication, flexibility, empowerment of teams and individuals, and try to do the best they can for their customers and get out of the way.

Bottom Line on Agile Consideration for Your Company

When thinking about whether your company should adopt Agile or not, take into consideration: Culture, the type of projects, products, or services your company builds, and even regulatory issues. Ask the tough questions: What problem are we trying to solve? Are we ready for change? Is our culture ready to bend, stretch, and ache a little to get there?

What to Prepare to Communicate to Management About the Value of Agile Implementation

You are ready. You are prepared. You have taken a look at your current environment and see that it is ripe for Agile opportunity. You know where you can find small wins. You know how to measure success in them. You have asked the tough questions and have received enough positive feedback from management and stakeholders on the potential. You are ready to roll. So what next?

“One never becomes a leader by continuously improving. That’s imitation of the leader.” – Russel Ackoff

At the end of the day, we need to back to the question: “What problem are we trying to solve?” Don asserts, “If we are trying to solve a simple problem, why are we taking on Agile? That may not be the best course of action.” Consider thinking about what sort of change you want to plant into your organization.

Define the Problem First, Then Ask How Agile Adoption Will Resolve That Issue

“When a system is taken apart, it loses its essential properties. The system behavior is not the sum of its parts, it’s the product of their interactions.” – Russel Ackoff

Take into consideration who your management is. Your message may just depend on where you management comes from. In terms of Personality Theory – People who come from development side are generally intuitive in nature. The business side? Data oriented. Don suggests that a healthy combination between showing data and describing what it means is a good approach.

Derek, speaking from his experiences, suggests looking at and preparing to discuss what we can deliver now. “You don’t need to ask for the kitchen sink every time. I want to give you the most important thing the quickest. The pain point often is the long duration of delivering value. Focus on the highest priority and problems we need to solve. From there your strongest critics can become your strongest allies.” 

Demonstration of successes can often help win over management. Chris suggests doing an assessment of the current environment, system, or processes. From there, one can easily see where some universal Agile practices make sense. “You also have to consider their context. Some care about how you improve things, some don’t care about that type of detail. Do they have to show stockholders? Do they need to be able to communicate risks and management overhead?”  

For Mike, he is cautious about what to communicate to management: “Very rare that management even cares whether you are using Agile or not. You may not even want to talk about team culture, retention, or happy developers. To me it’s about business value and predictability. Is the business getting the outcomes they desire or want?” 

Bottom Line for Communicating to Management About Going Agile

There are several factors we need to consider before we communicate:

  1. Data – Show measures of potential change and value of those changes
  2. Small wins – Sometimes bootstrapping small areas within your control can show demonstrable value
  3. Management Speak – Communicate to management about things they care about: Business value and predictability


Agile can work for you and your organization. It takes patience, resilience, and even a bit of gumption. There are a lot of misconceptions around Agile and where it works and where it doesn’t. We agree that it can work in all companies, but your companies milage may vary on its environment, readiness for change, and management style. True Agile transformation is the goal. Take incremental steps towards that goal and exposure yourself to others who have faced the challenges you are facing. There is a whole community out there ready to help you.