Top ScrumMaster + Scrum Product Owner Questions from Training – FAQ

scrum-alliance-challenges-donna-farmerScrum is easy to understand.

It can be the hardest thing to actually do.

Below are some of the most common questions we see in ScrumMaster and Scrum Product Owner courses.

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!
Eventbrite - Certified Scrum Product Owner Course (CSPO) - Get Certified in Atlanta, GA

FAQ on Most Common and Top Questions from ScrumMaster or Scrum Product Owner Training

How can Agile/Scrum be applied to Hardware or Solution projects?

Scrum Development doesn’t really work well in hardware development except in the aspects of hardware development that are done using software. Agile as a philosophy, though, works EVERYWHERE.

For example, the modeling and planning of the hardware can be done iteratively. The creation of simulation software (if applicable) can be done iteratively. Beyond this, however, much of hardware development is a task flow that must be followed and can be easily mapped out.

Scrum, however, can be used by people creating hardware. There’s still a Product Backlog. People can still commit to a certain amount of work in the Sprint. Daily Scrums can still be done to improve synchronization and communication.

Does Scrum conform to PMI standards? If so, how?

By definition, Scrum can’t confirm to PMI. PMI is a project management method. Scrum is a framework for managing people and workflow. It’s kinda like asking about the difference between apples and oranges. They’re just two different things. Not much else can be said.

What is a typical implementation of change from waterfall to Scrum?

  1. Start with understanding your culture. Period.
  2. Create a transition team to set vision, milestones, goals.
  3. Pick a pilot project —OR — a piece of a larger project
  4. Provide the proper training for the proper personnel
  5. Run several Sprints — adjust as needed
  6. Evaluate your results, adjust as needed
  7. Move on to a larger group (e.g., another product development group) and repeat steps 3-6.

In Agile/Scrum, how do we deal with people working across multiple projects in parallel?

Well, pretty much the same as you do now. The detrimental impact to your projects before Agile/Scrum will still be there after. Working on projects in parallel is not an issue of development method. This is not a question of looking for the development method that WILL allow you to work on multiple projects at the same time. The answer we’re looking for is to find a way to work on one project at a time in such a way that all projects get done faster and with higher quality.

How many Scrum teams can a Scrum Master realistically run?

That has everything to do with the ScrumMaster, the teams, and the product. Experienced teams don’t need ScrumMasters as much. Experienced ScrumMasters can work with more teams efficiently. Difficult products can make both teams and ScrumMasters work harder to accomplish the same thing. In my experience, I’ve never seen a ScrumMaster work with more than three teams at one time (and not very successfully).

Driving efficient and simple solutions in Sprints – can Scrum design and work complex solutions effectively?

I frequently hear concern that Agile Development can handle complex problems because it doesn’t try to solve the entire thing up front before building it. The reality that I’ve experienced shows that complex problems cannot be solved in detail up front because there are too many variables and too many assumptions made about the complex problem when working out a solution. Thus, we end up spending a bunch of time up front to build a solution that ends up changing in large ways during the development effort. Agile Development, on the other hand, encourages looking at a complex problem at a high level and then solving the parts one at a time. Does this mean that Agile Development might make some mistakes in solution during the development effort? No. However, because you will spend so much less time up-front trying to create a solution, you will have some time during development to build a solution and even some time to make mistakes.

So, Agile Development solves complex problems “efficiently,” if not “effectively.”

Role of wikis or collaboration tools in Scrum?

Can be useful in allowing Scrum teams that are non-co-located to communicate. They don’t replace face-to-face communication, however, and should not be used as a complete replacement.

Where does Scrum track risks and major impediments?

Impediments are generally tracked, per Scrum, in the organizational or team impediment list. Beyond Scrum, project risks are generally handled in some form of project risk tracker or document. Backlog related risks are handled within each backlog item in the form of notes and other documentation and in larger story point estimates to account for the impact of the risk.

Does Scrum state that teams must use User Stories or are Use Cases acceptable as well?

Scrum does not make any assumption about the construction of a Product Backlog item (PBI). It can be anything from a task, to a feature, to a scenario, to a defect ID.

How to handle high priority fires/opportunities in the middle of a Sprint?

Per Scrum, high priority fires (defects) may pass directly into the Sprint. The team should address the defect and then determine the impact to their commitment to the Product Owner and adjust accordingly. Per Scrum, high priority opportunities either wait until the next Sprint or cause an injection of change so that a new Sprint can be planned around the high priority. In reality, teams and Product Owners will often remove a lower priority PBI in favor of a new, high priority PBI (the catch is to remember to solve and plan the new PBI — that’s why Scrum measures the change, to force the replan and conversation that must take place when (not if) change happens).

Are key decisions in Scrum tracked in non-functional requirements & stories?

That depends on the nature of the decision. Decisions that affect NFRs are frequently captured in PBIs or as a separate part of the DONEness definition.

When do you do functional testing, performance testing, volume testing, ADA testings, and deployments to test environments?

As often as possible. Daily if you can (which means that the testing needs to be automated). Deployments to test environments are completely dependent on your frequency of testing. Deferring testing creates technical debt.

At what point do you plan for the next Sprint since planning will take away team time from the current Sprint?

Yes, its true that planning takes time away from building, but we have to do it anyway, so NOT doing it isn’t the solution (nor is only having certain individuals do the planning — that just takes your developers out of the loop at a critical juncture). I use backlog grooming workshops scheduled for 60-90 minutes once or twice a week to allow the team to discuss what’s coming up in the next Sprint (and get it ready for solving). This allows the team to think about what’s next without being interrupted too often to do it. Teams that do this can accomplish more and more preparation in less and less time. Then, when Sprint Planning comes along, we spend the proper amount of time (1 day for a 4 week Sprint, 1/2 day for a 2 week Sprint) doing an effective job of planning because the PBIs are now nice and small and everyone understands much of the functional requirement of the PBI.

Any pointers to good books or websites about QA within Scrum?

Lisa Crispin, Brian Marick, Janet Gregory. Lisa and Janet have a good book out there called, Agile Testing: A Practical Guide for Testers and Agile Teams.

In your experience, what techniques have you used to recognize top performers? Is it recommended?

This is a loaded question at best. Scrum is all about teams and teamwork. Going out of your way to identify individuals could hurt those who are really trying, but aren’t the ones recognized. I think the question you have to ask yourself is, “why are you looking for top performers?” What is it you want to do? Do you want to recognize them for high performance? Yes? But why would you want to do that in an organization that is looking for high performing teams, not high performing individuals. See, the trap you can easily fall into is the setting of individual performance over that of your team. This is counter-productive. Individuals that have their eyes set on that particular trophy start setting their own agenda and worry less about their teammates.

If you want to recognize high performers, make it a peer-recognition. Let the team members identify that one person who really made it happen, but don’t get carried away with the award. Make it a lunch, honoring the individual. Something relatively small in cost.

The real awards should be based around high performing teams.

Should team members provide estimates on tasks they have no or limited expertise with?

They should be involved in the discussion, even if they can’t provide a realistic estimate.

What metrics are generally used to assess a ScrumMaster’s performance?

I can’t speak to “generally used,” but I can tell you how I would do it as a 23-year manager. When you are trying to evaluate an employee’s performance (not something I recommend getting carried away with — performance evaluation should be part of the normal coaching, not part of the compensation package), I look at it in terms of the roles that the individual plays. For example, a ScrumMaster can be described as:

  1. ScrumMaster
  2. Scrum Team Member
  3. Software Engineer (or perhaps, Software Analyst, Systems Analyst, etc.)
  4. Individual – career aspirations, goals
  5. Employee

Now, what are this individual’s responsibilities with regard to each role?

  1. ScrumMaster – e.g., Keep the team fully functional and productive. Did she do that? How does the team see it?
  2. Scrum Team Member — e.g., Stay focused, get PBIs to DONE. Did she help with that? How? How does the team see it?
  3. Software Engineer – e.g., learn new techniques, stay technically current, etc. Did she do that? How? How does the team see it?
  4. Individual — e.g., is she trying to achieve a new role? Was there something specific she wanted to do this year? Did she do it? Was she effective?
  5. Employee – e.g., did she follow company policies? Is she a contributing member of the organization? How? How does the organization see it?

If you do what most organizations do and claim this is linked to compensation, you will likely garner excessive disappointment when compensation and salary grades do not truly line up with the level of the performance offered by the employee. Instead, we need to keep our focus simply on being the best that we can be and profiting from the organization’s success in whatever way the organization can realistically afford to do so. The organization that skimps on sharing their success will end up with people who aren’t interested in success, just employment. The organization that shares their success with their employees ends up with people banging on their doors trying to get in. These are two separate issues and should be kept that way.

How to project a final product picture to customer if the project requirements keep changing?

The question answers itself. If the requirements keep changing, the final product picture will change as well. The best you can do is base your picture on what you know and change it as the product requirements change. If your customer is the one suggesting the changes, that should be enough.

If a team is running well with no obstacles, does the ScrumMaster run out of things to do?

Unlikely. Even with everything is beautiful for the team, there’s still the organizational impediment list that needs to be addressed. Beyond that, there’s the question, “Can my team’s performance be raised? How?”

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.

Inputs

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.

Exits

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?

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

Pathways

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.

Inputs

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.

Exits

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]

Agile Coach Leadership Traits

scrummaster-agile-leadership-servant-job-description

What is Leadership? 

Three Styles

  1. Autocratic – Has to do with a totalitarian approach to leadership. This is more of an attitude than a leadership style.  This leader demands instant obedience, no discussions from underlings are desired. This is NOT a desirable leadership approach.
  2. Free-rein – The opposite of autocratic. This is more of a “hands off” approach. This is a good approach when dealing with highly skilled and expert individuals (professionals). Some of the more “blue collar” type individuals actually do not desire a free rein approach. They are told what to do and when to do it at work, they almost expect similar treatment at church.
  3. Participatory – Typically the best approach. Group decision-making, multiple leadership. There is, however, a leader at the head.

 Three Components

  1. PersonThe particular personality traits and leadership attributes the leader brings to the table. There are different personality types and individuals will respond differently and accordingly to this personality depending upon his or her personality.
  2. Group – The question is: “What kind of leader does this group actually need?” AM I WHERE I NEED TO BE?
  3. Situation – Leadership is situational. We can take the same leader who was successful in one scenario and place him or her in another scenario and NOT have the same exact results. Happenings may be slower, faster, not at all. Rather than success, failure could be more commonplace.  This could be related to any number of factors: geographical, cultural, social issues, political differences, phraseology, management approaches, leadership styles, etc.

Three Terms

  1. Leader – Really comes down to what a person is. He or she IS a leader. Generally a leader is one who has the ability to influence individuals to follow a particular direction or pursue a particular goal. John Maxwell, “Leadership is influence, nothing more, nothing less.” Leaders are goal-oriented.
  2. Administrator – These are more result-oriented. They strive for order, to correct failures, and operate systems.
  3. Manager – same as administrator.

Leaders inspire people, but managers depend on systems. Managers attempt to adjust to change, while leaders attempt to produce it.

Leadership Check Up Continue reading “Agile Coach Leadership Traits”

Ideas on Managing Distributed Teams Using Agile [3/3] – Review and Conclusion

globalization-agile-distributed-teams

Things to be followed by Distributed team in Sprint review meeting:

  • Keeping Track of the Stakeholder Comments -During the sprint meeting, the distributed team needs to capture these comments so the Product Owner and the development team can decide which ones they will act on.
  • Effects of Distance – The facilitator of a distributed retrospective needs to understand the cultural differences in the team. SM needs to understand how different cultures interact when they want to change something
  • Or have issues they want to talk about that can help the facilitator encourage participation from all team members.
  • Release Planning –The number of Sprints to map out and use with “Look ahead Planning Technique” will depend on Sprint length, dependencies, and needs of the teams involved.
  • Engaging Stakeholders – At enterprise level environments, to address the diversity of data by the Scrum team, the PO can help identify which customers are representative of different markets.
  • Resolving Blockers – The SM should create a list of blockers and assign them to team members or managers. The SM should also ensure the team is burning through the blocker list.
  • Handling New Requests in the Middle of a Sprint – In Distributed Scrum, it becomes mandatory that the team commits to sending requests through the Product Owner(s), who will decide the priority of the request in the Product Backlog.
  • Demos May Provide a False Sense of Completion – Add a DRAFT watermark on any screenshots or to use data that is clearly not real, to avoid false sense of completion to the stakeholders. Setting Expectations – The facilitator, for distributed teams, should talk to the team ahead of the first retrospective and explain the expectations for the retrospective.
  • Remote Demonstrations – Network Delays and Poor Performance – Distributed Team should test their tools ahead of time to be sure the distributed meeting will run smoothly, without network poor performance

The team can also consider making the recordings available for download before the demonstration meeting and discussing them through a teleconference.

Understanding the Team Members’ Personalities

Team have a different combination of personalities, and the facilitator of the retrospective needs to understand the personalities of team members to lead the meeting effectively.

  • Teleconference Meeting – Distributed teams with overlapping work hours should use a teleconference call to the same phone number every day to hold their Daily Scrum meetings.
  • Videoconference Meeting – The main advantage of this approach is that team members get to see one another, so there is less nonverbal communication loss. Dealing with Defects – Distributed team may want to consider creating a user story with a certain number of story points in the Sprint to deal with the problems, OR, they can set a priority for the maintenance tasks as per the customer log OR create a subteam to focus only on handling these issues during the Sprint OR depending on the skill set of the technical support team team to make the necessary code changes
  • Services May Vary by Location – Set up a single machine with a standard configuration that everyone uses during the demonstration meeting. Before the start of the meeting, distributed team members can access the machine (remotely or locally) to bookmark links, set up scripts, and do a quick dry run of their presentation.
  • Respecting Cultural Differences – SM needs to make sure cultural difference should not be taken lightly during the retrospective meeting in distributed teams
  • Managing Dependencies within the teams – Agile teams will not try to account for every possible dependency at the start of the project, but will look ahead two or three Sprints to ensure that teams are ready to deal with dependencies, using INVEST model
  • Gaining Commitment – With a distributed team,team members who are sensing that other team members have unspoken issues need to take responsibility for drawing attention to the issues to SM because of this, the SM needs to rely on the whole team to take responsibility for ensuring good communication.

Approaches to Handling Time Zone Issues

Distributed Teams can use four different methods to deal with distributed Daily Scrums where the team has members with no overlap in their work hours, as follows:

  • Daily Scrums through documentation
  • Liaison approach
  • Alternating meeting times
  • Share the pain Disruptions at the Team Member Level – Handling Stories the Team Cannot Complete During the Sprint – Before working toward the solution, the team first needs to identify the work they need to do to complete the story through meetings between team members or with the Product Owner.
  • Asking for Comments Before the Retrospective Meeting – What Went Well and What Can We Improve?
  • Ask the team for comments about issues or problems they noticed since the previous
  • Sprint retrospective and summarize them for team discussion. The result is still an action plan and a list of behaviors the team needs to change or continue in the period until the next Retrospective.

Risks

During the Release Plan, the PO will want to identify the risks associated with the project and teams, when possible, the mitigation plan for each of them Note: No one should interpret silence as agreement. Team members should phrase questions in a way that needs a verbal response to improve the understanding within the team. Precautions to be taken while conducting Distributed Scrum meeting

  • Increased distraction – Background noise can be distracting on a teleconference so teams should chose a room to conduct the meeting.
  • Handling Blockers During the Sprint – In the large scale enterprise transitioning to agile, the SM needs to hear from Distributed Scrum Team members who are facing blockers and dealing directly with inhibitors will help increase the velocity of the team over time, as well as the velocity of other teams as they transition to Scrum.
  • Provide Questions to Focus the Discussion – In distributed setup, team members respond to a set of questions developed or selected by the team. The purpose is to focus on a few issues and address them effectively instead of trying to address a lot of issues and address them poorly.
  • Coordinate Multiple Product Owners of different teams – Product Owners meet regularly to discuss Product Backlogs, dependencies, and links between and boundaries between user stories w.r.t. different teams
  • Release Plan Check or Update: Enterprise Scrum Teams often begin providing tasks for high-priority user stories before the Sprint Planning meeting. All team members discuss the tasks because it helps with communication for distributed and scaled teams and provides opportunities to find better ways of completing the user stories. Silence on a teleconference is not a commitment.
  • Keeping the Team Engaged – Possibly the best way to stay engaged and to make sure that others on the team stay engaged is: Awareness. Build awareness of what the team is working on.
  • Advertising. Advertise for collaboration.
  • Attack blockers. The team and SM should strive to fix all blockers within one hour of the Daily Scrum
  • Responding to Questions During the Sprint – For enterprise product development, the PO should look for ways to match representative stakeholders with the teams’ working hours and to be available during that time as well. For applications the team is developing for a specific client, the Product Owner may not have the flexibility to choose stakeholder representatives available during the full working day of the client.
  • Discussing Reported Issues – During their retrospective, the team reviews the reported issues and, if others feel strongly enough, the team addresses them, creates their action plans, and log them as actions they will revisit in follow-on Sprint retrospectives to evaluate their success.
  • Facilitating the Meeting – In a distributed environment, as individuals come into the call, they will identify who they are. The SM calls each person and asks for their response. They may respond in the order they arrived at the teleconference or the SM may choose to call on each person
  • Sharing Time Zone Challenges – One approach to help manage such cases is to make sure that distributed teams in different time zones are fully self-sufficient and the team spreads the work to minimize dependencies.
  • Managing Time Effectively – Limit the discussions to a limited set of issues, it is important for the team to agree, this is the right set to be talking about in the meeting. The meeting facilitator may want to keep a window of time open for unplanned issues that come up during the retrospective.
  • Invest in Smarter Development – Test automation and continuous integration help agile teams to complete user stories within a Sprint, working together or for distributed teams.
  • Taking Daily Scrum Notes – Helps the distributed team members to overcome language problems, plan and learn. Chat Tools & Wiki help distributed teams to do Daily scrums.
  • Continuous Integration – Continuous integration is the key to delivering stable, high-quality code consistently and quickly, which results in reducing time to market for any distributed agile team Release Retrospectives – The team talks about the project, and then defines and records the milestones in the project like initial training, team formation, Stand -up Meetings, start of development, middle of release, deployment etc.

Coordinating Agile and Non-Agile Teams

Making sure the non-agile team is aware of the priorities of the agile teams and keeping dependencies visible can help to prevent blockers between the teams. Scrum of Scrum can solve distributed team road blocks, future dependencies, commitments to other team members, issues with integration, and other points that impact one another.

  • Reports Any Build Failures to the Team – Allows the Distributed team to know the current state of the code in the integration branch of the source control system, generating a notification email for build success or failure.
  • Face to Face Collaboration –SM should reduce the amount time spent each day on project setup tasks, which will extend the duration of the project startup tasks and enables to build trust and relationships needed in distributed development efforts.
  • Reduces the Risk of Integrating Code – Continuous integration ensures a build runs regularly and allows the distributed team to identify integration issues earlier when they are less costly to fix. This practice helped the team to identify design problems and avoid introducing defects in scenarios we did not cover. These smaller testable deliverables allow the team members testing the feature to start their work in parallel with the development.
  • Establishes Greater Confidence in the Product – When developers are doing the unit testing of their code, they should also create automated unit tests as continuous integration certifies every build, developers can make changes with more confidence and the entire team can remain in sync with the latest build.
  • Reduces the Time to Find Integration Issues – Developers receive the build status by email, so they can see and fix problems. The next time the build runs, the build status changes from fail to pass automatically.
  • Improves the Efficiency of the Team – Distributed Teams efficiency can be improved by automating once and then reusing as much as possible. This removes human error, provides consistency, and frees up people to do higher-value work.
  • Builds Can Run at Different Frequencies – Setting up the hourly build helps the distributed team to know about a failure closer to the time of the code integration, and team members can take action on it earlier.
  • Test Automation – To streamline the testing and help the distributed team to get as much done as possible within a two week Sprint, teams should automate time-consuming manual processes where possible
  • Dedicated Automation Teams- The developers in distributed teams should tell what is ready to be automated to allow testers to closely couple with the product. And other testers in the distributed team doing manual executions and informs their highest-priority items for automation as well.
  • Identify High-Value Automated Tests – Testing installation and configuration of the operating system, regression tests, as well as acceptance into testing tests all have a high rate of return because the distributed should often repeat and in different environments.
  • Automate What Is Stable – Automated test cases should be created for parts of the project that are stable will help teams improve their effectiveness and avoid rework.
  • Test-Driven Development – For distributed teams, if someone is working on code written by a developer in another geographical location, having the built-in documentation in the code helps reduce their dependency on the author and enables them to work with the code faster. Working directly with the source code provides a common language for the developers and removes languages barriers.
  • Helps Reduce the Time to Fix Defects – By using such tests and fixing the area where the problem is occurring, the developer in distributed teams can save the time needed to create a full build, start the application, get to the right place, and test the fix manually.
  • Helps Improve Code Quality and Provides a Safety Net for Changes – As the distributed team should write the unit tests first, providing test coverage for all or most of the code, thus, provides an early defect detection process where developers can improve the code knowing the existing set of tests will detect any problems.

Conclusion

Distributed team needs to go for mandatory training to run into full fledge agile teams so that they could understand the potential impact of making the change. Although the project teams are undergoing through while adjusting to be a distributed agile teams, it becomes more important for them to understand and adhere to Scrum, rather than immediately thinking that Scrum needs to be changed.

I believe that collaboration becomes very important in distributed teams as they collectively responsible for delivering on their commitments. One important key to having success in managing distributed team is to have a high commitment level from all team members, and the best way to get that is to give them ownership over how they will work.

Another key to embrace self-managed distributed team is valuing the entire team and not having an “us versus them” atmosphere between different Scrum Teams on the project. The best ways to build relationship within teams is to find ways to share the pain of being a distributed team, to get to know each other as people, and to foster frequent, quality communications between team members.

Another way to introspect the distributed team management is to use their Sprint Retrospectives to see what they are doing and how they are communicating is working for them; when they need to adjust, they should do so as fast as possible.

I must say the teams with members distributed across sites can enhance code ownership and improve autonomy essential to team self-organization. Automated communication of Product and Sprint backlogs throughout the organization combined with upward reporting of teams’ status to management can tightly align the team distributed teams together.

Ideas on Managing Distributed Teams Using Agile [2/3] – The Retrospective

globalization-agile-distributed-teams

Retrospective Timings :

To be effective and timely, distributed teams should call joint retrospectives as soon as possible after having their own team meeting. Depending on the no. of teams involved in a joint retrospective, teams may want to limit the number of participants from each Scrum Team to keep the meeting productive.

  • Team Composition – Teams >=9 people should consider geographic closeness and proper distribution of skills as well as team size so as to build self-organizing teams
  • First level of Sprint Planning – The PO, SM will use a screen-sharing tool to display the vision, sprint goal, user story, the estimates the team provided, and the acceptance conditions for the user story.
  • Answering the 3 questions: Team members should communicate information that brings value to others on the team. They should also try to identify team members that can help them resolve their issues.
  • Documentation helps to Overcome Distance: Because of language barriers, distributed teams often need more written documentation than collocated teams. Another approach is to record the demonstration before the meeting to allow the developers to create the recording at their own pace in the language of the meeting or to have a fluent speaker speak over the recorded demonstration.
  • Hold Joint Retrospective – The Distributed Teams working together will conduct their individual
  • Sprint retrospectives at the end of each Sprint and then will conduct a joint retrospective.
  • The benefit of this approach is that it promotes communication between the various teams involved in a project
  • Individual Scrum Teams should aim to have the lowest distribution level possible encouraging feature teams over component teams.

Dealing with Incomplete Stories

The PO takes the impact of dependencies into consideration when reprioritizing the Product Backlog due to work the team did not complete during the Sprint, highlighted in Scrum of scrum Coordinating the Team on a Daily Basis – Priorities can change daily. The Daily Scrum meeting provides a daily synchronization point for the team and allows them to revise their plans regularly. Using the Right Tools : In a distributed environment, tools and good practices can help team members communicate more effectively, but it is more important to make sure the tools the team introduces will help them get the job done.

Scheduling for Teams with Overlapping Work Hours – Make sure all team members of distributed team, regardless of the time zone, can complete their work and prepare for the demo within overlapping work hours.

Larger Retrospectives

Distributed team members can reflect and comment on release quality and capability. The team talks about the project, and then defines and records the various milestones within the project to improve on or continue in future releases.
Enterprise planning tools for distributed team members, PO & SM to develop more than one feature to address a single solution so as to disaggregate the higher-priority features into user stories that can fit within a Sprint.

Checking Estimates from Preplanning Teams

In scaled environments where teams send representatives to help with preplanning, it is important
the teams who are going to be doing the work revisit the estimates

Committing to the Team

Team members are making a verbal commitment to their team when they state what they are going to do today, creating an opportunity for the rest of the team to confirm they met their commitments yesterday.

Valuing the Whole Team

SM should focus on an “us” versus “them” attitude in the distributed team, due to more delays in communications & fewer opportunities to work together Scheduling for Teams with No Overlapping Work Hours.

Alternate meeting time

The distributed team holds one Sprint Review meeting during the normal workday for part of the Scrum Team and holds the other Sprint Review meeting during the normal work hours of the other part of the Scrum Team.

Building Trust

SM needs to develop a sense of trust and honesty with one another, which in turn will lead to a wider degree of openness.

  • Single Backlog for Multiple teams – The different skill sets in the team needs to deliver user stories that are available across each distributed location
  • Separate Backlog for Multiple teams – The Scrum teams work independently from one another and have their own individual Sprint backlogs, but the Sprint dates are the same marking their interdependencies and risks in the Sprint preplanning sessions or in a Daily Scrum of Scrums.
  • Reviewing Changes Based on Stakeholder Feedback – The team would review changes made since the preplanning meeting, and the PO would confirm the priorities of the Product backlog.
  • Verifying Progress – Tasks not opening and closing regularly are an early sign the team may be going off track. Team members not showing regular progress may be facing outside distractions the SM should reduce or remove.
  • Transparency – Distributed agile teams should use project management tool to identify tasks that are open, in progress, and completed so everyone is aware of the current status.

More on the Sprint Review and Conclusion next!

Ideas on Managing Distributed Teams Using Agile [1/3] – Introduction and Ceremonies

globalization-agile-distributed-teams

Today the businesses are shifting to emerging economies due to reduced business operations cost and easily available workforce, like Russia, China, India, Philippines etc. If I put it more precisely, tomorrows business would be more virtual and distributed with distributed as its key element. Hence forth, the need for better managing the teams, using right tools and process become critical day by day for any enterprise company.

Shift and Need of having Distributed Agile Teams

  • Globally distributed teams reduce costs
  • Reaching Market more quickly with the “follow the sun’ Model
  • Distributed Teams Expand Access to New Markets
  • Acquisitions as a result of consolidation resulting in companies working together to integrate their business
  • Expanding for Innovation and Thought Leadership
  • Telecommuting gives options to communicate with their teams more effectively
  • Collaboration Tools – Improved tools for distributed communications and server-based, multiuser tools for product development are removing barriers, and more teams view distributed collaboration as an alternative.

Handling Distributed Agile Teams

Distributed teams heighten the need for clear, timely communication between sites. You might be thinking of some questions as the complexity increases with distance as time zones, language barriers, and cultural differences get in the way, let me resonate it for you:

  • Are distributed teams difficult to manage?
  • Are they failing to meet some expectations?
  • Are they having trouble working as a team?
  • Is team morale a problem?

Agile can’t fix every problem, but it can bring them out into the open where the team can evaluate and correct them. Agile puts challenges under a magnifying glass. As the image under the glass grows larger, they scream for attention, and your team’s performance will improve after they address the challenges and correct dysfunctions. Continue reading “Ideas on Managing Distributed Teams Using Agile [1/3] – Introduction and Ceremonies”

Outside In Perspective (Series 5/5)

The 3 B’s of Going Global: Beliefs, Behaviors, Benefits

Beliefs and behaviors are the hard part. Behavior can get to beliefs, which is cultural. – Brad White, Partner, Prophet, formerly (r)evolution

This is the last of the series “Something Innovative happened at KO HQ this Thursday”

Operating Globally? First, understand the point of view (aka needs) of consumers and then the shareholders’ point of view. The two are linked, products cannot have market success without both needs met. Continue reading “Outside In Perspective (Series 5/5)”

An Hypothesis is Really a Prototype [Series 4/5]

Agile as the Innovator

Thought bytes

Don’t think research is a phase, it is really ongoing. Prototyping is the way you learn. You learn so much by watching how people learn. It’s OK if the prototype is really rough.

Rapid prototyping your guesses* is an iterative process. You learn just enough to feed into building a better prototype. Then you go out and learn more, build again.

Launching is validating how much more solving is needed. If not solving the problem, re-calibrate.

Service design seems similar to product design – but it is harder to prototype an “experience.”

Product design creates an experience. ID the real issues.

Key is have a clear objective of what you are trying to find out.

Think about the smallest thing you need to do to get the most learning – throughout the entire life-cycle.

Storyboards! Stories describe a type of interaction.

Always design for people.

 

* My note:  a simple word for hypothesis?

 

Next up:   Outside in Perspective

 

Innovation by Immersion [Series 3/5]

 Experience is the Message

People have experiences about product, products don’t have experiences.  – Marcelo Marer, Chief Creative Director, Intel Media

What sells well in the U.S. many not be a benefit to anyone elsewhere. If you sell globally, it’s critical to design products for the new markets you plan to enter. Doing so requires research and an honest/thorough analysis of the information you have collected.

User Stories and User Personas

In the previous blog, the product teams hypothesized their customers and prospects need to collaborate – on demand, from anywhere – with their partners and other growers, in order to be more productive and to reduce risk. Continue reading “Innovation by Immersion [Series 3/5]”

From Iron to Cloud – Customer Driven Innovation [Series 2/5]

Customer Driven Innovation: A Global Perspective

Changing iron by using the cloud

Growers (Matt rarely called his customers “farmers”) are a uniquely tenacious and optimistic group. They have to be risk takers too, so many out-of-their-control environmental factors impact outcomes.  You might never guess that this group is well set to innovate/change how they farm.

The head of  Product Management explained that today’s growers, in order to feed the many billion of us, must find ways to limit their risk and increase their yield. They’ve already teased out most of their farming costs from fuel (which impacts feed, fertilizer and other necessary items on the farm). More was needed to be done – there are hungry people to feed.

Continue reading “From Iron to Cloud – Customer Driven Innovation [Series 2/5]”

Going Global – PDMA Georgia [Series 1/5]

Something innovative happened again at KO HQ this Thursday

The PDMA| Georgia chapter held it’s 9th annual Summit – topics were global in scope but personal in focus. Much shared learning and best practices offered. A very good reason to step away from desks/deliverables and come together with like-minded product professionals.

Innovators may already be intuitively using Agile

Top-line takeaways from the Round Table

  • Get a handle on things that bite in your planning stage, not during execution (import laws, regulations)
  • RESONATE! – don’t just BE in the chosen markets (do provide consistency, quality, awesome user experience)
  • Create RELEVANCY- use everything around your product to do this
  • LISTEN, partner with a local  –  help your prospects ARTICULATE their unique drivers Continue reading “Going Global – PDMA Georgia [Series 1/5]”

Getting back online: Agile, PMI, Volunteering and Me

*** Disclaimer: I am an active volunteer with PMI’s Agile Community of Practice as one of the 5 official leads. Views expressed here (and related future posts) are my own and not an endorsement by Project Management Institute ® (PMI) or Agile Community of Practice (CoP) leadership team.***

If you know me, I have been pretty active (as a volunteer, lead and contributor) in PMI + Agile space. I volunteer as:

  • PMBOK® Guide 5th edition – contributor (engagement just wrapped up)
  • PMI Atlanta Agile Interest group – Program Manager for Agile Interest Group
  • PMI Agile CoP – Knowledge Management lead

These opportunities have allowed me to connect with lots of people – amazingly talented, some famous agilists, practitioners and gurus. There’s a common thing we all share – desire to learn coupled with the passion to share!

I have learnt a lot, have actually got hands on experience (tools, technology, principles, practices etc.),  mentored a lot of people and I am still enjoying the journey!

What do we share? Knowledge. Of course about Agile, primarily.

I have seen a lot of questions that follow an agile presentation or discussion, ranging from:

  • What is Agile?
  • Where do I start? (There are so many places to start with)
  • What is different at Agile CoP? (from other valuable sites, groups and resources)
  • What does a Project Manager do in Agile projects?
  • What is PMI’s – Agile Certified Professional (PMI-ACP®)  certification? Is it for me?
  • Whom do we trust as good training companies?
  • What are good books, blogs, sites to start/continue building my knowledge about agile?

and many such questions. Continue reading “Getting back online: Agile, PMI, Volunteering and Me”

The 8 C’s of Agile Coaching

The 8 C’s of Agile Coaching

  1. don’t compare (with others)
  2. don’t compromise (Agile foundational truth)
  3. don’t be critical (of anything or anyone)
  4. don’t centralize (on self)
  5. don’t be careless (give your best)
  6. don’t over-commit (know your limits)
  7. don’t conform (be yourself)
  8. don’t be cynical (pessimism is a no-win deal)

Becoming an Agile Coach – 5 Tips for Agile Workshops and Communication

Me, doodling…

Part of coaching often includes putting the coach in a ‘trainer position’ in that we hold workshops or scheduled learning opportunities for clients.

The essence of training is not that we necessarily teach, but rather communicate effectively. This includes more than just ‘telling’ people, but rather engaging, involving, and working with the students to learn.

On Organizational Communication:

  • Sender – puts a message into words through encoding
  • Receiver – decodes the messages and attempts to understand it.
  • Feedback – helps us determine whether communication is actually taking place

Three aspects in the communication process: Communication is …

  1. Mutual – communication always involves more than one person
  2. Present – communication is always going on existentially (the real here and now)
  3. Simultaneous – communication is always going on both tracks at the same time. It is not like tennis where one ball is bounced back and forth. It is more like tennis being played with two balls. There is more than one idea or opinion involved.

 5 Tips for Communicating your Agile Workshop Effectively Continue reading “Becoming an Agile Coach – 5 Tips for Agile Workshops and Communication”

Agile Coach – 5 Tips for Building Relationships at a Client

Why is it that human relations problems are more difficult… the larger an organization gets? Is it simply a function of not being able to ‘touch’ everyone? Or is it deeper?

I believe as businesses grow, the ability for people to define what the business-culture is, becomes an exponential exercise. Let’s take a look at some of the reasons relationship building is tough at large clients (or any client) for that matter:

5 Roadblocks to Positive Human Relationships

1. The Words We Use

“I didn’t mean that” or “that came out wrong” are things hate to say in the ‘real world.’ The last thing we want is for that to happen in business-relationships. Since (most) people try to be as tactful as they can in the workplace, we, as coaches, need to be super aware of the words we use, how we use them, and the conciseness of their usage. We’re not consultants who say:

“That depends…” – Average Consultant Lingo

We are here to give effective advice and guidance based on our background and experience. Your clients expect it. Fulfill it.  

2. Ineffective non-verbal communication Continue reading “Agile Coach – 5 Tips for Building Relationships at a Client”

Becoming an Agile Coach – 5 Tips for Multiple Coaches at a Client

Squatting at a free area… for now…

Agile Coaching isn’t an easy sport to play… and when you have an entire group of Agile Coaches working together at a client, it can get even more hairy.

Leading a group of Agile Coaches is like herding cats… cat’s with a lot of expertise, knowledge, and even a bit of ego. A couple of tips when working with multiple coaches.

Multiple Agile Coaches – 5 Tips

  1. Ego Aside – Put your ego aside, we’re all here to do one thing: Service the client and help them deliver. At the end of the day, delivery is key. “Servant Leadership” comes to mind here…
  2. Coach Alignment on Engagement– Spend some intentional time with the other coaches to align on how to engage with the (common client). Last thing you want are “turf wars” or “religious wars” around how best to estimate, do planning, etc. etc. Make it a pizza and beer night. Get all the coaches together and go through a list of common themes/ceremonies/artifacts and get everyone playing by the same book. I did this with multiple coaches [SEE EXAMPLE BELOW FOR WHAT WE AGREED ON] Continue reading “Becoming an Agile Coach – 5 Tips for Multiple Coaches at a Client”

Becoming an Agile Coach – Get a Mentor! + 6 Tips for Mentors

Skype Mentoring!

Over half of all the Nobel Prize winners were once apprenticed by other Nobel laureates.

As a volunteer counselor and passionate about growing other great talent in our Agile community, I often take on opportunities to mentor others. I believe in the power of mentoring others. I believe in the power of helping people grow and begin to taste their potential. It is so very exciting for me to help others. Isn’t this what servant leadership is all about?

Let’s talk about mentoring for a bit…

What exactly is mentoring?

  • To help mature someone in a practice or discipline
  • To show them how you walked the path and to lead them through their own path
  • To teach them to mentor someone else, what you are doing to them.
  • Make a distinction between mentoring and teaching. If you’re teaching, you’re telling. If you’re mentoring, your walking with them through it (high-touch).

What mentoring is NOT primarily concerned with:

  • A methodologies and exact praxis of how to do something. Not prescriptive. Who you are mentoring… is NOT your disciple.
  • Mentoring isn’t a two way street like friendship. Mentoring isn’t accountability, but it is focused, unlike friendships.
  • Personal agendas.
  • You. The focus is on them, not you. We are to pour our life into someone else.

6 Tips for Mentors

1 – A mentor takes time to know people and reveal to them new possibilities and realities

  • Mentors are good listeners and they have the ability and willingness to step over familiar ground to get to know people and bring them into the circle.
  • If you’re mentoring someone for a particular role, help an individual by inviting them into communities of that practice. Always try to bring people not in the inner circle into the circle.

 2 – A mentor gets excited when good things happen to others. Continue reading “Becoming an Agile Coach – Get a Mentor! + 6 Tips for Mentors”

Becoming an Agile Coach – 7 Tips for Client Engagement

I recently spoke with an aspiring Agile Coach the other day and spent a couple hours coaching him through taking on work as an Agile Coach and beginning his next path into coaching. *An exciting process indeed!*

He had a great list of questions queued up for me, but as we moved into the conversation it quickly became apparent to me that we needed to do was set a few ground rules… (a framework that I personally follow) with my clients.

Below are 7 areas to consider when beginning your trek into Agile Coaching and for any of us in the coaching realm, a healthy refresher of how to engage with a client!

7 Tips for Agile Coaching

1.  Don’t “jump” at the first offer (or what may seem to be the best offer) when a client comes knocking… or a recruiter comes knocking 🙂

  • ask a ton of questions – About the environment, culture, and nuances of the client or engagement.
  • seek wise counsel – know people that have worked there? Other Agile Coaches? Get the skinny before you dip.
  • what are “your” motives for considering it – Is this a strategic client to go after, or a paycheck?
  • don’t force your family and spouses to accept this new reality – A personal anecdote from a guy who has been traveling for over 10+ years, and… over 400,000 hotel points (@ 1000 points/stay). If you’re jumping into this and it includes travel. Get support for it :)… as you would with any career choice!

2.  Show up as a servant, not a savior Continue reading “Becoming an Agile Coach – 7 Tips for Client Engagement”

Scrum Plus: Agile Heresy No More!

SIX YEARS A SCRUM HERETIC

Old habits die hard.  Useful habits die harder.  

Six years ago, I earned my CSM from the ScrumAlliance. Another six years before then, I had already been baptized as an evangelical apostle of FDD (Feature Driven Development), christened by Jeff De Luca and Peter Coad. Yet another six years before, I was already teaching the “Baseball Model” of agile, concurrent development processes…but that’s another story. (Yikes! A “6-6-6” pattern? Naw, probably just intervals in my learning curves.)

Agility and FDD were woven into our collective DNA at TogetherSoft. Our business cards were tagged with our mission statement:

Improving the ways people work together TM

My card displayed a “Senior Coad Certified Mentor” title. Mentor to our customers. Mentor to other mentors. Helping others learn FDD was part of my job. That was a remarkable privilege. I got to share the love!

So, as a newly minted Scrum Master in 2006 did I renounce my faith in FDD?

Continue reading “Scrum Plus: Agile Heresy No More!”

Know an Obscure Agile Voice?

Looking for 100 Agile Voices…

That was the first half of the headline Tuesday.  There was more to it.

Mark Levison is looking for “lesser known” agile voices. More obscure bloggers, authors, etc. Not the ones you’ll already find on someone else’s “Top 100” list.  As Mark headlined it,

…voices we should hear more from

Hmmm… Sounds a bit like that new NBC TV show, The Voice, doesn’t it?

Mark wants your nominations.  Maybe you can help…

Continue reading “Know an Obscure Agile Voice?”

It’s Not Small Change (Series 4 of 4)

Part 4 of Agile Product Marketing Series:

  1. Product Marketing Becomes Agile
  2. What’s a Product Marketer Doing with a Roadmap?
  3. The Launch Queen Speaks
  4. It’s Not Small Change

This is the last of a series written to help Agile and B2B Marketing teams understand each other’s conversations and methods.  Previously, we discussed how Agile practices can integrate within traditional product launch management and commercialization.

Change

It’s the people- the human element– that we’re talking about.   Continue reading “It’s Not Small Change (Series 4 of 4)”

The Launch Queen Speaks (Series 3 of 4)

Part 3 of Agile Product Marketing Series:

  1. Product Marketing Becomes Agile
  2. What’s a Product Marketer Doing with a Roadmap?
  3. The Launch Queen Speaks
  4. It’s Not Small Change

A series written to help Agile and B2B Marketing teams understand each other’s conversations and methods. Previously we discussed how real-time dialog between Agile and Marketing teams drive Business Value by creating need-to-have features. This time we’re in a product launch.

Like adventure?

Try running a global product launch. I’ve described it as building a rope bridge while crossing a raging river filled with hungry alligators and sharp rocks.  Don’t look down and failure is not an option.  Not much time to recover from a botched job.

“Product commercialization and product launch requires a rigorous program strategy and execution.” – Found scribbled in my study notes, author is unknown.

Sounds Like We Need to Get Agile

No matter how you dice it, product launches are complex.  It’s all about teams, communication and performance… and successful transition. A launch isn’t a success until the product steps out into the cold, new world of Life Cycle.

Let’s back up to launch. Do all the teams:

  • Know the goals
  • Know the roles
  • Know the priorities
  • Commit and collaborate

In a traditional launch, stakeholders proceed within their own swim lanes. When done with their piece, over the wall! #FAIL

I Feel a Strong Need for Agile Advice

Marketing will take care of setting the market’s/analysts’/customers’ expectations of the product. Seeking Agile advice on continuous delivery, keeping teams collaborating and with how to integrate all the moving parts.

Keep on keeping on!

On the Tee:  It’s Not Small Change (Series 4 of 4)

 

 

What’s a Product Marketer Doing with the Roadmap? (Series 2 of 4)

Part 2 of Agile Product Marketing Series:

  1. Product Marketing Becomes Agile
  2. What’s a Product Marketer Doing with a Roadmap?
  3. The Launch Queen Speaks
  4. It’s Not Small Change

A series designed to help Agile and B2B Marketing teams understand each other’s conversations and methods.  Previously, we discussed how marketing teams gain insight about current product features before release by being part of the “Agile dialog.” Marketers generate user benefits from these features and need time to do this well.

“Incremental Improvement” Impacts Marketing Process

Agile development produces new product features often and incrementally, which is important in a changing marketplace. Marketers don’t want Agile Teams to slow down, lose the rhythm, or delay incremental improvements but we urgently need to know where you’re heading.

Being included real-time in Agile planning and reviews is pretty critical for us. A great deal of what marketing does is communicating the product strategy to different audiences, both internal and external. We are always being asked, “When’s the new XYZ being launched?”  and “What’s in it?” We’ve have to see the bigger picture, the roadmap, or BIG #Fail.

Agile Teams Can Provide Real-Time GPS

Share the Product Backlog with the Marketing Team. Show us in which Sprints features will release; offer timelines, priorities and updates.  We will use this information for product messaging/positioning and to update our marketing plan. We also need to build our own “roadmap” for marketing. We could use your help in designing this. Continue reading “What’s a Product Marketer Doing with the Roadmap? (Series 2 of 4)”

Product Marketing Becomes Agile (Series 1 of 4)

Part 1 of Agile Product Marketing Series:

  1. Product Marketing Becomes Agile
  2. What’s a Product Marketer Doing with a Roadmap?
  3. The Launch Queen Speaks
  4. It’s Not Small Change

This post is the first in a series designed to help Agile and B2B Marketing teams understand each other’s conversations and methods.

Attention Scrum Master or Product Owner!

Are you working with a Marketing Team and hoping they don’t think Agile practices mean another form for Yoga? Actually, we marketers know about Agile and are cautiously curious and optimistic.

You can be absolutely sure that marketers working with Agile development teams wonder how they’ll be able to Sprint faster, while shaping, communicating and testing the product’s market message, value prop – in time for successful commercialization.

Provide a Bridge

Invite your PMM to join in the Stand-up. Share your Backlogs. Collaborate.  Marketers must be plugged into product information as real-time as possible in order to understand the product as it is now defined. With your help, we’ll do a much better job working our magic. Continue reading “Product Marketing Becomes Agile (Series 1 of 4)”

An Agile Virtual Office? Beam Me Up, Brody! – Sococo Virtual Collaboration

HOW TO WORK REMOTELY WITHOUT BEING ISOLATED

If you really work alone, without collaborators, then you can skip the rest of this post. It probably won’t matter much to you.

I value agile collaboration. I work with others, at various times and places. If you do, too, then please continue reading…

When you can’t be in the same room or building with your team and others, how can you work together?  Sococo Team Space!  That’s how. You can be remote…yet visibly present and connected…very much so!

Sococo, where were you when I needed you?

I spent most of my past three years working remotely…

I was a full-time member of an awesome organization (NASA), staffed with amazing people (engineers and, yes, rocket scientists!) who engaged in plenty of collaboration around the work (Independent Verification & Validation). I was hired to work from home, with travel as needed to various locations.

To be sure, we made good use–heavy use–of our phones, conference lines, screen sharing apps, content management systems, file sharing, secure virtual private network, messaging and email. That technology stack was good enough that some people would “dial in” to a meeting from the same building! If you are working from a wheelchair, you already know how valuable that technology can be, especially on a hilly, ice-and-snow-covered campus of several buildings! (West Virginia is known as “The Mountaineer State” for good reason!) Continue reading “An Agile Virtual Office? Beam Me Up, Brody! – Sococo Virtual Collaboration”

Who is Lord of the Backlogs?

LORD OF THE BACKLOGS

One Backlog to list them all, One Backlog to find them,
One Backlog to prioritize them all and in the Sprints deliver them
In the Land of Agile where the Stories lie.

Copyright (c) 2003-2012, K.C. Ritchie, Classmaker(SM), with gratitude to J.R.R. Tolkien for the inspiration. Permission granted to distribute with attribution.

Do you work in the Land of Agile?

  • In your Land, where you labor, where do the Stories lie? How are Stories listed, found, and prioritized?
  • Are there many Backlogs? Is there One Backlog, a Master-Backlog to list them all?
  • How is it that you lay hold of your Stories, tasks, or assignments? Are there any Technical Stories there?
  • Are Stories delivered in Sprints or Releases?

Who is the Lord of the Backlogs in your Land?

You need not reveal the Land in which you now labor. But please, do tell about your Stories, Sprints, and Backlogs… And who is their master?

The Road goes ever on and on… perhaps through Lands in which our Agile Scouts have not yet traveled.  Yet, through your eyes, we hope to gain a glimpse of other worlds beyond The Shire

Will you tell us, please?  Thank you, my Precious… Thank you!

-K.C. Ritchie 😉