Tag Archives: featured

Super-Hard ScrumMaster Quiz – Test Yourself!

For a little while last year I was using a quiz in my Certified ScrumMaster courses that was deliberately designed to be super hard.  Why?  Because if anyone could answer it correctly before the end of the class, I would give them their certification early and allow them to leave.  Not a single person out of several hundred was able to do it.

So… want to give it a try?  I’ve got two files here.  One is the quiz without answers.  The other is the answer key.  Let me know if you have any questions!!!

CSM Class Test – Super Hard! (PDF, 1 page)

(Please, give it a try before you even download this next piece!!!)

CSM Class Test – Answer Key (PDF, 1 page)

This test was first created by me and one of my close colleagues, Julien Mazloum from Outsofting.  We were trying to make the CSM class something that the Chinese audience would really appreciate culturally.  It worked well, up to a point.  The main problem was that some of the questions were too subtle for people for whom English was their second language.  That said, when I used it in my North American courses, still no one passed it!  In fact, the best score I ever saw was 25 correct out of 30.

Have fun!


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

24 Common Scrum Pitfalls Summarized

Scrum is the most popular agile method… if you count all of the teams doing “Scrum Butt”.  Doing Scrum really well is much harder and much rarer.  Here is a list of 24 common Scrum pitfalls or bad behaviours of Scrum teams:

  1. Excessive Preparation/Planning: Regular big up-front planning is not necessary with Scrum.  Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans.  Even the Product Backlog can be created after the first Sprint has started.  Read more about the Excessive Preparation  Scrum Pitfall here.
  2. Focus On Tools: Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well!  Use manual and paper-based tracking for early Scrum use since it is easiest to get started.  Finding a tool is usually just an obstacle to getting started.  (And besides, check out what the Agile Manifesto says about tools.)  Read more about the Focus On Tools Scrum Pitfall here.
  3. Problem-Solving in the Daily Scrum: The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised.  Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested.  The ScrumMaster facilitates this meeting to keep it on track.  Read more about the Problem-Solving in the Daily Scrum pitfall here.
  4. Assigning Tasks: Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should assign tasks to team members.  It is better to wait for someone to step up than to “take over” and assign a task.  Read more about the Assigning Tasks pitfall here.
  5. Failed Sprint Restart: Although cancelling a Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting.  Teams should immediately re-start after cancelling a Sprint.  Read more about failing to re-start a cancelled Sprint here.
  6. ScrumMaster As Contributor: The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle.  Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions.  Read more about the problems of having a ScrumMaster as contributor here.
  7. Product Owner Doesn’t Show: The Product Owner is a full member of the team and should be present at all Scrum meetings (Planning, Review and Daily Scrums).  As well, the Product Owner should also be available during work time.  Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.  Read more about the pitfall of the Product Owner not showing up.
  8. Stretch Goals: The team decides on how much work it will do in a Sprint.  No one should bring pressure on the team to over-commit.  This simply builds resentment, distrust and encourages low-quality work.  That said, of course teams can be inspired by challenging overall project or product goals.  Read more about the pitfall of setting stretch goals for Scrum teams.
  9. Individual Heroics: Individuals on a Scrum team should not do excessive individual overtime, or in any other way try to be the “hero” of the team.  Scrum helps us build great teams of people, not teams of great people (quote from Barry Turner).
  10. Team Organizes Product Backlog: The team does not have proper insight into the needs of users and instead should be focused on solving technical problems.  The Product Owner needs to be accountable for ROI and therefore should resist any pressure from the team to do things in a particular order for “technical” reasons.
  11. Product Owner Specifies Solutions: The Product Owner must allow the team full freedom to come up with solutions to the problems presented in the Product Backlog.  PBIs should be free of technical specifications unless they can be tied directly to a customer or end-user request.
  12. Urgent Interruptions: Urgent interruptions should not be allowed in a Sprint… instead, if it is urgent enough, the team should cancel the Sprint.  Otherwise, the interruption should be put on the Product Backlog and deferred until the start of the next Sprint.
  13. Making Assumptions: Often team members will fail to ask the Product Owner about details of the work they are doing.  A team member solves problems, but it is critical to know about constraints.  The feedback between PO and Team Member should be ongoing throughout every day of the Sprint.
  14. Not Getting Done: This is hard to prevent from happening from time to time, but it can become a habit for a team to over-commit.  Make sure that a team that is doing this is using burndown charts effectively and is holding demos even when they have not completed all their work.
  15. Demo Not Ready: Sometimes a team forgets that it will take time to prepare for a demo: cleaning the team space, setting up a demonstration environment, getting scripts ready, and ensuring that critical stakeholders are prepped.  These activities can be part of the tasks in the Sprint Backlog.
  16. Prototype Not Shippable: A Scrum team should attempt to produce production-quality, “potentially shippable” software right from the very first Sprint.  Building prototype code just delays the inevitable need to write production code.  Similarly, wireframes, detailed designs and other similar tools should also be avoided.
  17. Distributed Team: Although Scrum does not officially require team members to be collocated in a “war room”, the reality is that any distribution of team members (even just into separate cubicles) has a huge negative impact on transparency and communication, which in turn has a huge impact on productivity and quality.  Here is a YouTube video on distributed Scrum teams.
  18. Directive ScrumMaster: The ScrumMaster needs to be a facilitator who supports the team in learning self-organization, and the Scrum rules.  The ScrumMaster should never succumb to the temptation to suggest how a team member does his or her work, nor what task next to work on.
  19. Changing Team Membership: Scrum is a framework for creating high-performance product development teams.  If the membership of a Scrum team changes, it forces that team to re-start the Forming-Storming-Norming-Performing sequence.  If the team is in Norming or Performing, then changing team membership for any reason is a waste of quite an investment.  Here is a YouTube video on changing Team Membership.
  20. Non-Scrum Roles on the Scrum Team: It is very common for an organization to create a Scrum team without changing the official title and duties of the people who are members of that team.  For example, a person who is a Project Manager might be given the responsibilities of the Product Owner without an official change of title.  Scrum teams should only have a ScrumMaster, a Product Owner, and Team Members.  Our video about the roles on a Scrum team explains why!
  21. Giving Up On Quality: Scrum has very high demands on teams regarding the quality of their results: “potentially shippable software”.  It is easy for a team or organization to fall back on the crutch of defect tracking software instead of maintaining extremely high levels of quality at all times (due to pressure to release features).
  22. Imposed Deadline Scope And Resources: Scrum is reality-based.  If an external stakeholder wants to impose a minimum scope, a deadline and constrain the resources available to the team then they must allow that quality will slip… which in turn is against the principles of Scrum.  The reality is that no-one can predict the future so any such imposition is simply a fantasy.
  23. Definition of “Done” Imposed:  There is confusion between the concept of the definition of “done” and “standards”.  Managers and other stakeholders often incorrectly impose standards on a team as its definition of “done”.
  24. ScrumMaster Not Present: I once saw an organization that had created a room for a “team” of ScrumMasters.  They worked there together most of the time!  The only time the ScrumMaster should be away from the team is when he/she is working on removing an impediment that is outside the team.  Otherwise, the ScrumMaster should be in the team’s room.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Mentoring, Coaching and Training – What is the Difference?

Over the years working with clients, I’ve discovered that there is often confusion about what are the differences between mentoring, coaching and training.  We all know that these are ways for an expert or experienced individual to help people do something more effectively.  That’s the similarity.  But the differences…

Mentoring

Mentoring is generally an informal relationship between two people.  A mentor will do many of the same things as a coach or even someone who is a trainer, but there is no formal obligation on the part of either party.  A mentoring relationship often develops gradually from a friendship or a professional association, intensifies as the mentor discovers he has valuable insight and experience to share, and as the person being mentored discovers his desire to learn from the mentor.  The two people will at some point recognize the special nature of their relationship, but may not name it.  And as life circumstances change, the relationship will gradually de-intensify.  It will often turn into a friendship of peers.

Coaching

In working on this article, I read a number of other articles about the differences between coaching and mentoring.  All of them talk about how a coach does not provide solutions or answers.  I beg to differ.  Think of an athletic coach.  An athletic coach definitely does not simply ask the athlete questions and help them bring out their own solutions to problems.  An athletic coach helps point out problems, makes very definite suggestions, and sometimes even intervenes physically to help the athlete do the right thing.  So what is coaching?  The main difference is in terms of formality.

A coach is a coach from the start of the relationship with the person being coached.  The person being coached has a specific goal to achieve.  It can be long term or short term, but it is specific.  The coach is there to help that person meet their goal.  Once the goal is met, the relationship is re-evaluated.

Here are some of the ways that coaching can happen (actually, mentors do these things too):

  • The Socratic Coach – asks lots of probing questions.
  • The Hands-On Coach – shows people a way to solve a problem, but leaves it to the individual to mimic or do something different.
  • The Intervention Coach – mostly observes and at key moments intervenes to help an individual choose a specific path of action.
  • The Guiding Coach – provides constant (usually gentle) reminders to help an individual keep withing a specific path of action (guide rails).

Training

Classroom training is the type of training we most often think of, but it is not the only kind.  There is also on-the-job training and of course all sorts of e-learning methods of training.  Training is very formal, should have well-defined learning objectives, and is often relatively brief as compared to coaching or mentoring.

Training can also include many of the types of interaction that are found in a coaching environment, but there is a very strong focus on the trainer being a subject matter expert.  The trainer has extensive experience or knowledge in the subject that is being delivered in the training.  It is expected that the participants in the training learn from the trainer – there is knowledge transfer.  How this happens can be very flexible, of course, and good training is never just a speaker standing at the front of the room and lecturing for the whole time.  Discussion, simulations, case studies, and other forms of interaction are critical for an effective training experience.

Some other links:

Workplace Coaching and Mentoring – Some Key Differences to Maximize Personal Development

Coaching is Not Mentoring, Training or Counselling

What are the Similarities and Differences Between Coaching and Other Things?

Are You Coaching Mentoring or Training Your New Employees?  Distinctions New Managers Need to Know.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Seven Core Practices of Agile Work

Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.

Self-Organizing Team

Any group of people that wish to be an Agile Team need to take the initiative to determine for themselves how they are going to work (process) and how they are going to do the work (product). The term “team” really applies quite broadly to any size group of people that are working together towards a common goal.

Teams go through stages of development as they perform their work. The most important result of team development is the team itself, and not the specific skills and abilities that the individuals learn.

If the team is part of a broader organization, that organization must give the team the authority, space and safety to learn to be self-organizing. The organization’s leadership is responsible for determining the “why?”, some constraints on “how?”, and then letting the team respond to the need as best as it can.

Also Known As: Whole Team (Extreme Programming), Cross-Functional Team (business management).

Deliver Frequently

Agile Work uses short fixed periods of time to frame the process of delivering something of value. Each of these iterations or timeboxes is structured so that the team or group actually finishes a piece of work and delivers it to stakeholders. Then, the team builds on what has previously been delivered to do it again in the same short amount of time.

The sooner that valuable results can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction.

There is an explicit tradeoff: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one’s retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.

Also Known As: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).

Plan to Learn

Every type of work is governed by a Horizon of Predictability. Any plan that extends beyond this horizon of predictability is bound to fail. Agile work uses an explicit learning cycle tied in with the planning of work to accomodate this inevitable change.

First, a goal is required. This goal can be long-term. Teams using Agile Work then create a queue of work items to be done in order to reach this goal. Each iteration, some of these items are selected, finished and then the queue is adjusted. The changes in the work queue are based on external factors, and learning that the team does as it goes.

One of the most effective methods for the team to learn about how it is doing its work is the retrospective. After each delivery of results, the team holds a retrospective to examine how it can improve.

Also Known As: Inspect and Adapt (Scrum), Kaizen (Lean), Adaptive Planning (generic).

Communicate Powerfully

A team needs to have effective means of communicating, both amongst team members and also to stakeholders. To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication.

The results of failing to communicate powerfully include wasted time for waiting, misunderstandings leading to defects or re-work, slower development of trust, slower team-building, and ultimately a failure to align perceptions of reality.

The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time.

Some types of work do not lend themselves to this approach (e.g. creating a documentary video), but every effort should be made to improve communication.

Also Known As: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).

Test Everything

Defects are one of the most critical types of waste to eliminate from a work process. By testing everything, by driving all the work of a team by creating test cases to check the work, a team can reach extremely high quality levels. This ability to prevent defects is so important that only an executive level decision should be considered sufficient to allow defects into a work process. Quality is not negotiable.

In Agile Work, removing a defect is the only type of work that takes priority over any new features/functionality/production. If the end result desired is to maximize value, then removing defects is an important means to that end.

A team has an ethical duty to discover new ways to effectively test their work. This can be through the use of tools, various feedback mechanisms, automation, and good old problem-solving abilities.

Also Known As: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).

Measure Value

Since Reality is Perceived, it is important for an agile team and organization to have a clear method of describing and perceiving what is important for the organization. Measuring value is a critical method for describing and perceiving what is important.

A single metric can be used to drive all the measurement and goal-setting and rewards in an organization. All other measurements are secondary and must be treated as such: limited in use and temporary.

There are many things which are easier to measure than value. It is often easy to measure cost, or hours worked, or defects found, or estimate vs. actual… etc. However, all of these other measurements either implicitly or explicitly drive sub-optimal behavior.

Also Known As: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).

Clear the Path

Everyone in an organization using Agile Work takes responsibility for clearing the path, removing the obstacles that prevent work from being done effectively. Clearing the Path doesn’t just mean expedient, quick fixes to problems, but rather taking the time to look at an obstacle and do the best possible to remove it permanently so that it never blocks the path again.

In the Agile Work method, the Process Facilitator is the person who is responsible for tracking obstacles and ensuring that the path is cleared. To do this, the Process Facilitator maintains a Record of Obstacles.

Clearing the Path is sometimes painful work that exposes things we would rather not deal with. As a result, it is critical that people build their capacity for truthfulness and work to develop trust amongst each other. Building a capacity for truthfulness is not something that can be done by using an explicit process.

Also Known As: Removing Obstacles (Scrum), Stopping the Line (Lean).


Remember also, that these practices must always be viewed and implemented in the context of the Agile Axioms. These axioms provide a check to ensure that the practices are not being applied blindly, but rather applied appropriately to the given situation.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 31
2023
Details
Real Agility Management Track - Practitioner I (RA-MT-LA)
Online
C$7950.00
Apr 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 4
2023
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1795.00
Apr 5
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1895.00
Apr 11
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 14
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 17
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Apr 18
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Apr 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 25
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1895.00
Apr 26
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 28
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 28
2023
Details
Advanced Certified Scrum Product Owner® (ACSPO)
Online
C$1525.75
May 3
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
May 10
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 12
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1100.75
May 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
May 16
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
May 17
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
May 17
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 19
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 26
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 26
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jun 7
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 9
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 9
2023
Details
Kanban System Design® (KMPI)
Online
C$1610.75
Jun 13
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jun 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 16
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jun 20
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jun 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jun 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 30
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 30
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jul 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
Jul 11
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jul 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jul 19
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Aug 15
2023
Details