Monthly Archives: June 2013

Reference Information, Scrum, XP and Lean

The Rules of Scrum: I am truthful about the internal quality of my product (technical debt)

Leave a comment

Scrum relies on the truthfulness of Team Members to allow for transparency about the internal quality of the product.  Internal quality is primarily related to the technical aspects of the product: its design, its architecture, lack of duplication in the code, and the level of coverage of the product with automated tests.  Scrum relies on the professionalism of the Team Members for the proper implementation of this rule. Being upfront, transparent, and truthful about the internal quality of the product allows for the Product Owner to understand how much time and effort the Team will allocate to improving the internal quality of the product and how much will be allocated for new features. This also gives the ScrumMaster an opportunity to connect with stakeholders who may be able to help remove technical debt and waste that is continuing to exist.  If Team Members are not truthful about the internal quality of the product, over time the system will become more cumbersome, more complex, and more painful to improve. This will also lead to a culture of hiding problems, which diametrically opposite to the intended use of Scrum: to uncover problems and allow us to solve them.  Another downside is that morale will begin to decrease as Team Members care less about the quality of their work. This, of course, will ultimately lead to external quality problems that result in customers being unhappy and looking for someone else to work with.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: I use Scrum as a tool for product development

2 Comments

Scrum is an Agile process framework that is optimized for product development.  The rules of Scrum are fine-tuned after decades of use to help product development teams become hyper-productive and to maximize business value.  If you use Scrum for product development, then you are applying it to the right problem.  If you use Scrum for some other type of work (e.g. general project management) then you are mis-applying Scrum and it probably won’t give you the ideal results.  Scrum is not simply a collection of best practices.  Therefore, if you are using Scrum by picking and choosing some of its pieces, it is likely that you are using a sub-optimal approach to product development.  In this way, Scrum is like a tool rather than a toolbox with many tools.  When you take a hammer out of a toolbox, you don’t pull the head off and start pounding nails without the handle.  Likewise, if you only use some parts of Scrum, you are missing the benefits of using Scrum as a tool.  As a Scrum Team Member, you should know the purpose of Scrum and be aware of applying it correctly to the right problems.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: The Product Backlog is easily visible to every stakeholder (e.g. cards on a wall or an electronic tool with open access)

Leave a comment

The Product Backlog is a constantly changing artifact, owned by the Product Owner. Stakeholders need real-time visibility into the current state of the Product.  Stakeholders should be able to discuss the state of the Product Backlog with the Product Owner at any time, make recommendations and requests.  Any change resulting from the request of any stakeholder(s) must be visible in real-time to all other stakeholders.  One of the greatest benefits of a highly visible Product Backlog is that it becomes a conversational space for key stakeholders and many others that are connected to or interested in the work of the Scrum team.  Of course, a visible Product Backlog also upholds the Scrum value of transparency which is essential for long-term success with Scrum.  What if my Product Backlog is not easily visible to every stakeholder?  Stakeholders will become disengaged from the work of the Scrum Team, and will forget to give support and/or offer insights into the work.  If the Product Backlog is managed in an electronic tool that requires people to login and/or go into a special space that has restricted access then they are much less likely to view it regularly.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: Any stakeholder (e.g. Team Member, salesperson, client) can suggest a new PBI

Leave a comment

The Product Backlog is a list of potential work to be done for future Sprints.  This list is most vibrant when as many people as possible contribute to it.  Those directly connected (stakeholders such as the Team Members, users of the systems, etc) have a stake in the product’s growth so they also have plenty of ideas that may benefit its value.  Adding a Product Backlog Item (PBI) is like brainstorming where all ideas are welcome.  Then it is the responsibility of the Product Owner through conversations with others to order the list based on the most value for the least effort (and sometimes to reject PBIs if they are too outside the product vision).  If the creation of PBIs is limited to just a few individuals, or even just the Product Owner alone, it is likely that many great ideas will not surface and will be lost.  Also by having all stakeholders contribute PBIs, the Product Owner builds collective ownership in the work of the Scrum Team which helps the team overcome obstacles and become supported by a larger group.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: The Product Backlog is refined to ensure it is ready for every Sprint Planning meeting

Leave a comment

Product Backlog Items closest to the top of the Product Backlog should be small enough for the team to be able to complete at least one potentially shippable slice of the product in the next Sprint.  As well, they should be ready for the Sprint Planning meeting so that the team can plan its work for the Sprint.  To be ready for the Sprint Planning Meeting, each PBI must be estimated.  Generally speaking, Product Backlog Items at the top of the Product Backlog are clearer and more detailed than lower ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed so that at least one item can be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting.  Having too many items in the Product Backlog “ready” for the team is considered wasteful over-planning, although generally the top ten items should be in this “ready” state.  The value of having a refined Product Backlog before the Spring Planning Meeting is that it enables the Scrum team to focus on the purpose of the Sprint Planning Meeting which is to answer these questions: What will be delivered in the Increment resulting from the upcoming Sprint and how will the work needed to deliver the Increment be achieved? Essentially, what is the Spring goal and what are the tasks needed to complete the goal?  Without a ready Product Backlog, the purpose of the Sprint Planning Meeting is difficult to achieve.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: Known defects (external quality) generally are ordered at the top of the Product Backlog to be fixed in the next Sprint

Leave a comment

One of the key benefits of the using Scrum is that it allows the team to quickly identify defects and obstacles.  Now that the team has made these known, the team has the ability to remove and fix these defects.  What is the value of identifying problems in the product when nothing is done to repair them?  The team will become much faster if it can improve the quality on its own by removing known defects and making the software better.  Then the team will be able to take on more audacious goals instead of being weighed down by quality problems.  Moving known defects to the top of the Product Backlog places quality work as a central goal for the team to achieve which directly improves the product, makes customers and users of the software much happier and invigorates the team to continue to become more effective.  Placing known defects away from the top of the Product Backlog causes morale challenges, acceptance by the team of poor quality work and creates an atmosphere of apathy.  These are likely to cause a failure by the Scrum Team to deliver on its goals.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: PBIs are invitations to conversations, not detailed specifications

3 Comments

Product Backlog Items are brief descriptions of a feature or function.  Usually they are short enough that they could be hand-written on a small note card.  This brevity is meant to be just enough information so that the Product Owner and the team can use the PBIs as invitations to conversations.  The resulting conversation (ongoing, evolving and involving the whole team and stakeholders) and the shared understanding that comes from that conversation is where the real value of the PBI resides.  Part of the conversation occurs when the Product Owner initially writes the PBI so that the team can estimate the effort of building it.  Part of the conversation is the actual work being done during a Sprint.  Another part of the conversation is during the Sprint Review when stakeholders see the results of the team building the PBIs.  If one creates PBIs as detailed specifications then we are essentially handcuffing the team into a set path and a prescriptive solution.  The reason we hire qualified people onto our Scrum Team is for their knowledge, experience, and problem solving abilities.  If we lock them into a set path, then we are literally turning them into cogs in a machine to spit out specific code.  PBIs that are invitations to conversations allow them the flexibility to figure out how to solve the problem by engaging in a conversation on what is needed.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: The top PBIs are small enough (effort) that several can fit into a single Sprint

Leave a comment

Product Backlog Items (PBIs) that are at the top of the Product Backlog (in other words, those which are to be done next), need to be small enough that the Scrum Team can comfortably complete all the work for them within a single Sprint.  The Product Owner should be spending a little time every Sprint to split “large” PBIs into small PBIs.  The Product Owner relies on the team to estimate if they are small enough.  If the PBIs are not small enough then large problems can arise.  Probably the most serious problem is that the Scrum Team may be unable to start and finish PBIs in a single Sprint which can seriously hinder the “inspect and adapt” process due to Sprint results that cannot be demonstrated in the Sprint Review.  Almost as bad, incomplete work can leave a mess in the system if the Product Owner for some reason decides to change priorities and not complete work started in a previous Sprint.  Finally, incomplete work dis-empowers the Product Owner from being able to make a business-based decision to ship or deploy the Team’s work at the end of the Sprint.  A smaller problem that can arise from PBIs that are large is that the Team may not be able to fill their Sprint as effectively.  One way to think about this is the difference in how much empty space there is in a cup filled with large pebbles versus a cup filled with sand.  The rule of thumb is that PBIs should be small enough that between five and ten fit into every Sprint.  This is often the right compromise between the effort required on the part of the Product Owner to write small PBIs and the risks mentioned above.

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
Agile Management, How-To Apply Agile, Theory of Agile

Leaving your title at the Scrum team room door and pick up new skills!

1 Comment
Each member of an organization has a title or designation that may reflect their responsibilities or profession.  These titles may include BA, Tester, Developer, QA, PM, and others.  It is normal to be proud of our accomplishments, achievements and titles.  Unfortunately in a Scrum team these titles can limit the individual and adversely effect the team.  These same titles can label the individual as that role (example – as a tester) and only that role.  Within a Scrum team we certainly need the skills, knowledge and abilities that come with that title/role, but we do not want to limit that person to being viewed as only that role.  Each of us is the sum total of our experience, education, values, upbringing and history.  All of this is of value to the team.  We should encourage every member to fully participate on the team, to willingly share their expertise, to contribute to non-traditional tasks and to feel they are valued as a complete person rather than a specifically titled individual.   So if the goal is to leave your title behind, then it is implied you can also pick up other skills.
So how can this be accomplished.  One way is a Skills Matrix.   This is a chart that can be posted in the room to identify the skills needed and the people on the team.   On the left column you list all the team members.  Along the top you list all the various skills you need on the team.  Then each person reviews their row, looking at each skill, and then identifies how many quadrants of each circle they can fill in, based on the range below the chart.  The range is from no skills through to teach all skills in a given column.  After filling the columns and rows, now the work begins.  By using pair programming (an extreme programming method) and other methods like self-study and taking additional courses, the team member can begin to learn other skills.  The objective is to have at least two persons on each team who possess each of the skills at the level of performing all the tasks of a specific skill.  The goal is not to have every one do everything but to have a least enough people with specific skills to cover sicknesses and vacations so that required tasks are performed.  This is a method to capture the full extend of each person’s current knowledge, skills and abilities and expand on it.
Skills Matrix
Since they are hard to see, here are the labels for the number of quadrants:
0: no skill
1: basic knowledge
2: perform basic tasks
3: perform all tasks (expert)
4: teach all tasks

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: PBIs are written as User Stories (“As a ___ I can ___ so that ___”)

Leave a comment

The User Story is a tool developed with Extreme Programming that is almost universally accepted as part of Scrum.  The User Story format is an effective way of communicating end user value to the Scrum Team.  The first blank is a user (a person, not a system), the second blank is the action of the story (unique), and the third blank is the benefit (for any stakeholder, and outside the system).  A User Story is made up of three “C’s”: Card, Conversation and Confirmation.  The Card is the written version of the story (usually a physical card on the wall).  It is considered to be an “invitation to a conversation”.  The Conversation is where the real value resides and potentially involves all stakeholders. The Conversation can cause changes to the Card.  Confirmation is the acceptance criteria that, when tested against, confirms the valuable result of the story.  A User Story is an extremely effective way of creating light and conversational PBIs – this is why many Scrum teams use them.  Another way to view User Stories is that it tells any reader the “who”, the “what”, and the “why” – who cares about this, what is the need/action, and why does the person want this.  This is just enough information to make sure that an effective conversation occurs.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: PBIs are “slices” through our system (features or functions)

Leave a comment

All PBIs completed by the team should be “potentially shippable” increments of complete value.  In order to do this, they must touch all the layers and components of the product so that the functionality produced is truly complete, not just a prototype… a “slice” through the system.  In other words, all of the work that is required for shipping product needs to be completed on all individual PBIs.  Creating slices through our system allows the Scrum team to deliver value each and every Sprint and also allows for the Product Owner to change direction to a new feature if it is more valuable for a future Sprint.  What happens if we don’t create and complete PBIs that are slices through the system?  We risk falling into a pattern of not having a potentially shippable product each Sprint, and, even worse, we may regress into a waterfall type process that produces nothing of value to the customer until the end of the project.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: PBIs are ordered by expected Value (ROI, NIAT, etc)

Leave a comment

Product Backlog Items are ordered into a sequence in the Product Backlog in such a way that the Product Owner is able to maximize the return on investment (ROI) in the team.  The very first PBI in the Product Backlog should be the one with the highest expected value considering the effort to build the PBI.  There are many ways to calculate this expected value including Return on Investment (ROI), Net Income After Taxes (NIAT), Net Present Value (NPV), etc.  The Scrum Team members should be free to ask why one PBI is prioritized higher than another, and the Product Owner should be able to give a reasonable answer. Since the entire Scrum Team is accountable for its work, it is in the best interest of all members of the team to use expected value, so that both the Scrum team and the customer will be committed to the work that is currently being worked on and the upcoming work in the future Sprints.  If we don’t order the PBIs by expected value, then the Product Owner is likely to prioritize them based on dates, feelings, urgency, or other less valuable methods.  These other prioritization methods will diminish the trust of the team in the Product Owner and may lead to morale problems.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: All PBIs are related to a single product (or system)

4 Comments

Scrum Teams work on one product at a time.  The Product Backlog represents all of the work that needs to be done on that single product.  The complete list of Product Backlog Items represents the goal of delivering all of the presently known features of a product.  Multiple teams working on a single product, therefore, work from a single, shared Product Backlog.  Working on Product Backlog Items from multiple Products causes the team to task switch into a different business domain and possibly into a different technical domain.  Task switching creates wasted mental effort and therefore causes a team to be less effective than they could otherwise be.  Having a single product to work on creates focus in both the business and technical domains.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: No two Product Backlog Items (PBIs) have the same position in the Product Backlog (ordered)

Leave a comment

The Product Backlog must be ordered so that the Product Backlog Items can be thought of as a sequence of valuable pieces of software to be built.  There is always a first item (not two or three first items) then a next item, etc. until you get to the end of the list.  The list is “ordered” so that there is a strict sequence with exactly one Product Backlog Item at each position in the list.  The sequence is determined by the Product Owner and is used during Sprint Planning to determine what the team will do.  This ordering helps to create a strong discipline around choosing what should be done next.  It also encourages the Product Owner and the Scrum Team to think about how to break dependencies.  If two or more Product Backlog Items have the same position in the Product Backlog, it means that the Product Owner has not prepared for the Sprint Planning meeting and the team may be less effective in that meeting.  Having two or more Product Backlog Items in the same position in the Product Backlog is, in fact, a slippery slope that can lead to very poor prioritization, and even sub-optimal results from the team.  Minor or occasional deviations from this rule will have a low impact, but categorizing Product Backlog Items into a small set of priority levels (e.g. MoSCoW prioritization – http://en.wikipedia.org/wiki/MoSCoW_Method) will reduce the effectiveness of the Sprint Planning Meeting dramatically.

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
Reference Information, Scrum, XP and Lean

The Rules of Scrum: The Scrum Team does not include any other people (e.g. a manager who doesn’t do tasks)

Leave a comment

Since the Scrum Team only includes three roles: ScrumMaster, Product Owner, and the Team Members, there is no need to have other people on the team. Each of the Scrum roles has a specific function that requires their full-time attention. These roles are all the roles necessary to accomplish the creation of a high-performance Scrum Team.  Adding people to the team who have any other roles will hinder the team from engaging in the requisite amount of self-organizing behaviour.

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
Kanban System Design® (KMPI)
Online
C$1895.00
Mar 22
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 24
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Mar 24
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Mar 29
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1895.00
Mar 29
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Mar 30
2023
Details
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
Win as a Manager (ML-WAAM)
Online
C$895.00
Apr 6
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
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$1610.75
Apr 26
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.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