Category Archives: Theory of Agile

Memory and Mystery

My father, Garry Berteig, recently took a trip to China to visit my brother in Beijing. Garry is an artist and an educator of great skill and insight. While there, he had the following insight:

Memory (traditional forms) is undone by Mystery (abstract forms). The next step is to combine the two into new forms in a postmodern sense… unity through diversity.

I believe this can be related to the idea of levels of mastery which I first encountered in Alistair Cockburns excellent book “Agile Software Development”. Since I don’t have the book in front of me, I have to go from memory. First there is rote learning, memorization of predefined forms. Then comes understanding of why the forms are the way they are. Finally comes the wisdom and experience to innovate on the forms.

If anyone else has any ideas about this, I would love to discuss them!


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Broadcast Mode Communication

The book “The Mythical Man-Month“* discusses some of the reasons that larger teams are inefficient. The main concern is with the number of possible connections between team members. If you have two team members, there’s only one channel of communication. However, if you have n team members, then you have n(n-1)/2 channels… which grows quickly (order n^2) as n becomes larger. If one is required to work with a large team, say more than 10 to 12 people, it becomes imperative to find ways to improve communication efficiency.

One of the best ways to do this is to use broadcast mode communications. Information radiators are a simple broadcast mode tool. In a subtler way, having the team co-located** also takes advantage of broadcast mode communication: if everyone can overhear all the conversations that are going on in a room, then people can tune in when they hear something of relevance.

It is important to note that there are several other forms of broadcast communication that are useful in certain circumstances: e-mail, blogs with RSS or Atom feeds, analog radio, television (if you can think of others, please let me know in the comments). These tend to be more useful for very large communities. Radio and television have severe limits: they are not easily used in a communal fashion.

Some forms of communication may seem to be broadcast, but in fact are not. A simple web site is not because it requires that people poll it to see if it has been updated. Conference calls are marginally broadcast in that while they are occuring, everyone participating hears everyone else. However, a conference call requires active synchronized attention on the part of all the participants.

The subject of media and communication is a vast one. Some of the best writers include Marshall McLuhan and Gregory Bateson. However, there are many many more.

*Highly recommended!

**A search on dictionary.com for collocation indicates that three spellings are all correct: collocate, colocate, and co-locate, this latter spelling being the most common on the web.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Applicability Matrix Tool for Iterative Delivery

Notes:

1. Iterative Delivery is a specific way of managing queues of work. As such, rote work is generally better served by other applications of queuing theory.

2. There is one universal condition under which iterative delivery is awkward, if not inadvisable. If one’s horizon of predictability is longer than the size of a work package by some substantial amount (e.g. 2:1 ratio), it can be more natural to use queuing theory and a pull system to flow work through the team. The actual ratio between the horizon of predictability and work package size that is used to switch over to a queue system must be determined empirically in your own circumstances. This empirical analysis can be done using a regular process reflection meeting.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The True Cost of Software

From the Link: Calculating the True Price of Software by Robert Lefkowitz — Businesses have long viewed support and maintenance as essential components of software. Open source business models often focus on charging for support and customization. Is there an economic model that can demonstrate the true worth of a piece of software and the option for support, maintenance, and upgrades? Robert Lefkowitz argues that open source exposes the true value of software itself as, essentially, worth less in comparison to support and maintenance.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Waste and Value: Basic Lean Concepts

In assessing a process, it is important to understand what activities in the process actually add value to the end result. All other activities are wasteful.

Continue reading Waste and Value: Basic Lean Concepts


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Why Should Business-People Care About Continuous Integration?

Continuous integration, and for that matter, TDD, FDD, and other Agile practices and methods can be obscure to someone who hasn’t run across them before. Since some Agile approaches really relate to engineers more directly than to their managers and executives, I have been asked why business-people should care about some of them?

The question might be examined from the other side – how do things that are important to the business side relate to things happening on the technology side. Put yet another way, is the whole organization in-sync and harmonious, or is the left hand interfering with the right. Finding consistency of vision and values across disciplines within an organization can be very difficult, but there are good examples of business’ values being reflected in engineering practices.

Kaizen, for example, is an increasingly common business watch-word. It’s philosophies of waste-reduction, orderliness, and continuous improvement have radically affected Toyota’s much-vaunted production system, for example. This philosophy, and other principles have influenced Total Quality Management, Lean analysis, Six Sigma, and other value-oriented business management practices. Kaizen is often translated as meaning a continuous improvement in small increments, and in practice is almost a micro-quality-control. The idea that a single defect can bring a production line to a halt, so that the defect is caught early and fixed when it is cheap springs from this approach. (Kaizen is much more than this, and often also refers to a short high-value problem-solving session that uses related principles. Kaizen, in this context, refers to the process philosophy and the practice thereof, cf. Kaizen.)

Continuous integration is a software engineering practice that is quite similar. When combined with test-driven development, it forms a kind of Toyota-style production line scenario. Continuous integration basically means that all changes to the software are integrated with the rest of the software as soon as the developer submits the change to the central repository. At that point, or at very near intervals, the whole system is run through unit and integration tests to see that it is still healthy. If a defect arises, either through a mistaken submission, or the submission of something that breaks something else, the system alerts the developer, and possibly relevant management. The system “goes red”, as the jargon goes, and the developer rapidly fixes whatever is out-of-sync. This is quite analogous to Toyota’s “stop the production-line” approach to quality management.

Assigning power so close to the ground can be frightening to both executives and technical employees alike. This is understandable. People used to controlling everything often find it hard to delegate to the “shop floor”, and people who are used to possessing little power are often afraid to wield it once it is granted. Both the arenas of technology and business, however, have established, through volumes of evidence, that defects caught early can be orders of magnitude cheaper to fix. Toyota leapt ahead in its reputation of quality very soon after implementing such a system. Businesses that use Kaizen or other related approaches to quality management and process evaluation on the business side can see these principles at work in their software development organizations.

As with most good things – simple principles, broadly applied to specific disciplines, work to the overall benefit of the organization. They provide confidence and common vision and value across disparate specialties. Business stakeholders who make these high-level decisions can then have increased confidence that what they’re defining, marketing, and selling won’t fail them in execution in the customers’ hands.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Some Comments on the Three Agile Axioms

People are Creators

When people are creating, they feel fulfillment. If a person can increase the quality, speed, quantity, or uniqueness of their creation without reducing any of those, then that person will feel increased fulfillment.

Joint creation (people creating something together) develops strong relationships among the people doing the creating. And in a very nice feedback loop, strong relationships among people empower exceptional creation.

Reality is Perceived

We can increase perceptual ability in order to understand reality more completely. In the sciences, this is done by creating tools such as telescopes. For teams, this can be done with coaching and training as well as communication tools and practices.

A team can use a common vision to align perception. Perception that is aligned can create harmonized beliefs. Harmonized beliefs allow a team to work in a united fashion.

People can choose what they perceive. For example, a person can choose the value of some work that has been created. People can also choose how they perceive change.

People disagree because they have chosen to perceive different aspects of reality.

Change is Constant

Stasis, the lack of change, is death.

Responding to change is our natural state. For example, our eye and the neurological system for sight is designed to be attracted to changes in our visual field. Our minds have the capacity to learn which is based on exposure to new experiences or ideas (and new experiences are another sort of change).


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Enterprise Reference Model

There is a very interesting paper online that presents an Agile Enterprise Reference Model. From the paper:

Sponsored by the Agility Forum, this 1996 reference model project had two principal goals: 1) design a reference model structure that effectively captures and displays the essence of enterprise-wide competency at both proactive and reactive change; and 2) validate the design with a rich, comprehensive example that provides an instructive reference case for an entire enterprise. The purpose is to provide a defining profile with examples for business managers and executives responsible for strategic planning, operational management, and reengineering.

One very interesting part of the reference model is a Change Proficiency Maturity Model. In this model, an organization can be described by its level of maturity in adapting to and creating change. The levels of maturity are as follows (again quoted from the paper):

0: Accidental – Stumble through change, recognition but no awareness.
1: Repeatable – A set of rules for acheiving change become understood.
2: Defined – Rules broadened and performance metrics put in place.
3: Managed – Objectives clarified, rules refined, accountability in place.
4: Mastered – No longer rule based – principles guide action.

There is a logical correlation between these levels and the various aspects of the Agile Work framework. The Repeatable and Defined levels of Change Proficiency match up with the various Agile Work Practices such as Maximize Communication, Self-Steering Team, and Adaptive Planning. The Managed level of maturity matches up with the Agile Work Disciplines of Empower the Team, Amplify Learning and Eliminate Waste. Finally, the Mastered level of maturity corresponds to the Agile Work Axioms: People are Creators, Change is Constant and Reality is Perceived.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Engaging the Environment

In a recent discussion I had with someone about the Agile Work Axioms, he mentioned that he thought that “people are lazy by nature”. Here is my brief response:

I don’t totally agree. Those who are motivated for whatever reason to do something will be “not-lazy”, and those who aren’t motivated will be “lazy”. But the fact is, that I don’t think laziness is a fundamental truth about human nature. I think it’s a consequence of how engaged we are with our environment, which in turn is a result of both our internal state, and how attractive our environment is. Television is a great example: it is so engaging that we will sit around doing nothing even if it becomes physically quite uncomfortable. Normally, laziness is associated with avoiding discomfort.

In terms of engaging with our environment, the three Agile Work Axioms define a system of engagement:


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Reality is Perceived – So What?

Results are necessary to reach a goal. Work is done to produce results and reach a goal. Therefore, any work done that does not produce results that contribute to the goal is wasteful. The degree to which a result of work contributes to the goal is the degree to which that work is valuable. However, since reality is perceived, it means that the stakeholders’ perception of the results is of paramount importance. If a team produces a result that the stakeholders do not find valuable, then at that time, it is not valuable. This is both obvious and subtle. If the stakeholders have an articulated set of values, then it is easier for the team to produce results that satisfy those values. However, it is often the case that stakeholders will also have unarticulated values. These unarticulated values are just as important. Agile Work attempts to use various disciplines and practices to elucidate, draw out and make explicit the values of the stakeholders so that the team can produce results that are satisfactory.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum Evolution: What’s it all about?

Love it or hate it, the Agile 2005 Conference reviewers thought the paper below was either a major innovation or a gross violation of the principles (dogma) of Scrum. It’s motto is innovate or die and only the paranoid survive in the global economy. Does it show the future of Scrum? Well the paper was accepted for presentation at Agile 2005 and many people have asked for the real bits (all 27 pages) before I chop it down to the required 10 page IEEE paper. It could take you to CMM Level 4 or beyond. Decide for yourself whether this paper should be burned or nailed on a door somewhere!


Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects

Jeff Sutherland, Ph.D.

Certified ScrumMaster Training

Patientkeeper, Inc., Brighton, MA, US

Abstract

Scrum was invented to rapidly drive innovative new product to market. Six month releases used to be a reasonable time from for an enterprise system. Now it is three months for a major new release, one month for upgrades, and one week for maintenance releases. The initial version of the Agile Scrum development process was designed to enhance productivity and reduce time to market for new product. In this paper, one of the inventors of Scrum goes back to Scrum basics, throws out preconceived notions, and designs Advanced Scrum using multiple overlapping Sprints within the same Scrum teams. This methodology delivers increasing application functionality to market at a pace that overwhelms competitors. To capture dominant market share in 2005 requires a metaScrum for release planning, variable length Sprints, overlapping Sprints for a single team, pre-staging Product Backlog, daily Scrum of Scrums meetings, and automation and integration of Product Backlog and Sprint Backlog with real-time reporting. A practical example of Advanced Scrum describes how mobile/wireless product teams implemented Scrum process automation during 2000-2005. Administrative overhead for over 45 enterprise product releases a year was less than 60 seconds a day per developer and less than 10 minutes a day for a Project Manager. While Advanced Scrum is not for the uninitiated, the future of Scrum is still Scrum, just faster, better, and cooler.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

A Little Something from The Theory of Constraints

The Theory of Constraints or (ToC)[Google] is introduced in the book “The Goal“>The Goal” by Eli Goldratt. At its most basic level, the theory of constraints posits that there is only one thing right now preventing your team from going faster. It is the weakest/slowest link in a process or procedure.

How do you find that one thing? There are various possibilities depending on the sort of work environment. One way, that is appropriate to a manufacturing-like process is to identify the Work in Process (WIP) pileup. If you are working in a more human-skills based process, then ask “if you can only hire one skill set, what would it be?”

In an agile process framework like Scrum, there is constant discovery of the constraints (although possibly not the one specific constraint that is slowing the overall process). This discovery is encouraged by the Scrum Master and is exposed by team members as they participate in their daily “scrum” status meeting. An important feature of this meeting is that the team members identify any barriers to the performance of their work. The Scrum Master is then responsible for removing the barriers that are identified.

In organizations that are very paper-documentation oriented, often approval gates are one of the worst constraints in a process. Those who must approve the team’s movement to the next step must receive the documentation they need, then find the time to read it, then find the time to formulate their decision, and then find the time to communicate it to the team. I have been in environments where this can take a few months (I’m sure some organizations are worse, and many are better than this). During this time, the team is essentially idle.

Another typical problem exists in organizations that have gone through several rounds of layoffs in a short time period. In this situation, often the constraint is due to an unbalanced skill distribution. The organization may have very few people with a specific critical skill. The only way to remove the constraint (and speed up) is to add more people with the skill either by hiring or by training.

In general, because of their short iterations, and the resulting amplification of learning, agile teams tend to expose many constraints in the organizational environment. This can be a cause of backlash against the agile team.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum and its Relationship to Other Management Techniques

(On relationships of Scrum,TOC, BPR, Systems’ Thinking, Knowledge Management, TQM, Complexity, Manufacturing, New Product Development, etc.)

Although there are great synergies between TOC and Scrum, there are also vast differences. Both provide patterns to resolve systemic problems akin to those described in Systems’ Thinking by Senge, but TOC resolves systemic problems that are more akin to process improvement ala TQM, rather than complete overhauls as in BPR, which I argue, is closer to what Scrum does – it reengineers the process from scratch, by implementing high performance patterns altogether.

For the most part, TOC, and The Goal, assume a somewhat repeatable business process, where the process of removing constraints, exploiting constraints, finding new ones, etc.; is an ongoing process in a somewhat stable, repeatable process.

Scrum, on the other hand, generalizes this technique in the absence of a repeatable process, it simply removes *any* constraints constantly, with no assurance that the constraints removed will remain so the next day, and that the particular constraint optimized
“has been removed”, and that we can move on to new ones at that point. It is usually the case, however.

Another important difference is that a Scrum team is already an organizational structure that avoids process anti-patterns like handoffs, iteration and re-work (among different organizational structures, between an “analysis” team and a “design team” for example, or between an organizational structure building component A, communicating with another one building component B, in a Conway’s Law configuration i.e. where Organization Follows Architecture.

In that sense, a Scrum team is a true “Case Team”, as termed in Michael Hammer’s BPR, i.e. an organization structure that is *completely responsible* for the success of a process or project, where the ScrumMaster is the “Case Manager* ala Hammer, that responds to the Product Owner.

From the Knowledge Management perspective, TOC optimizes the process and therefore, more knowledge of the processes themselves are more valued, while in the Scrum (Case Team) perspective, the individual contributor’s knowledge is more valued.

On the other, and to make things slightly more complicated, Scrum sits atop a number of processes, that as more applications of the same kind are built, tend to be more repeatable, like configuration management, testing of certain components, vertical slice development or new applications on top of reusable architectural services.

The interesting thing to note, is that in Scrum, smaller reusable processes develop underneath as a base of knowledge but they don’t drive development, while the Scrum process, acts as a “work generator/work management” “process envelope” (a superprocess, or meta-process, if you prefer), that drives the work. (In Complexity terms, it is the Maxwell Demon that provides the autocatalytic cycles to drive self-organization, ala Kaufman’s “Origins of Order”.

Curiously, manufacturing is turning more and more to the original BPR patterns to build things. However, New Product Development always requires one meta-level more of work organization to handle the variability of “building something new every time”. In software development this difference evolves into a more continuum spectrum. The first application in a domain is New Product development, but as new ones get added, only a percentage is New Product development, the other percentage is more like manufacturing, and therefore more repeatable.

But don’t worry – no one needs to understand all the above gibberish for Scrum to work. On the other hand, it is nice to understand these things to properly understand Scrum in the context of other management techniques,

– Mike Beedle


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

People are Creators – Effectiveness

Our effectiveness as creators depends greatly on our knowledge and our skills. Less obviously, our effectiveness as creators also depends on our emotional and mental state, and even what some would call our spiritual state. Finally, our ability to create can be greatly magnified or greatly reduced by our environment, particularly the other people who are around us. Which is interesting, because our creative nature affects our environment.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Reality is Perceived

Our senses and the devices we create to extend our senses, are filters through which we perceive reality. We don’t get to sense all of reality. Then, our minds take in the streams of information from our senses, and filter them further. Our attention or focus, our preconceptions, our mood, all determine the way we filter information from our senses. If we are feeling guilty, we may be more likely to hear other peoples’ conversation as criticism. If we are feeling proud, we may be more likely to hear those same conversations as praise.

If our perceptions are wrong then no amount of logical excellence will give the right answer. So it is a pity that almost the whole of our traditional intellectual effort has been directed at logic and so little at perception.

Logic will not change emotions and feelings. Perception will.” (Edward de Bono, Textbook of Wisdom, 1996)


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Team Kanban Practitioner® (TKP) [Virtual Learning]
Online
C$1195.00
Aug 10
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online
C$1595.00
Aug 11
2020
Details
Real Agility Series Workshop: How Agility Helps Overcome Bias in the Workplace
Online
C$45.00
Aug 13
2020
Details
Certified Scrum Product Owner® (CSPO) [Virtual Learning]
Online
C$1795.00
Aug 18
2020
Details
**NEW** Kanban Maturity Model (KMM) {Virtual Learning]
Online
C$2495.00
Aug 24
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online
C$1595.00
Aug 25
2020
Details
Advanced Certified ScrumMaster® (A-CSM) [1-Day Accelerated]
Online
C$1695.00
Aug 27
2020
Details
**NEW** Kanban Coaching Practices (KCP) [Virtual Learning]
Online
C$2495.00
Aug 27
2020
Details
**NEW** Advanced Certified Scrum Product Owner® (A-CSPO)
Online
C$1599.00
Aug 28
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online
C$1355.75
Sep 9
2020
Details
Kanban System Design® (KMP I) [WEEKEND Course]
Online
C$1525.75
Sep 12
2020
Details
Advanced Certified ScrumMaster® (A-CSM) [1-Day Accelerated]
Online
C$1440.75
Sep 16
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online
C$1355.75
Sep 22
2020
Details
Team Kanban Practitioner® (TKP) [Virtual Learning]
Online
C$1015.75
Sep 24
2020
Details
Certified Scrum Product Owner® (CSPO) [Virtual Learning]
Online
C$1525.75
Sep 29
2020
Details
Kanban System Design® (KMP I) [Virtual Learning]
Online
C$1525.75
Sep 30
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online
C$1355.75
Oct 6
2020
Details
Kanban Systems Improvement® (KMP II) [WEEKEND Course]
Online
C$1525.75
Oct 10
2020
Details
Advanced Certified ScrumMaster® (A-CSM) [1-Day Accelerated]
Online
C$1440.75
Oct 14
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online
C$1355.75
Oct 20
2020
Details
Team Kanban Practitioner® (TKP) [Virtual Learning]
Online
C$1015.75
Nov 2
2020
Details
Certified ScrumMaster® (CSM) [Virtual Learning]
Online
C$1355.75
Nov 3
2020
Details
Advanced Certified ScrumMaster® (ACSM) [1-Day Accelerated]
Online
C$1440.75
Nov 10
2020
Details
Kanban System Design® (KMPI) [Virtual Learning]
Online
C$1525.75
Nov 19
2020
Details
Kanban Systems Improvement® (KMPII) [Virtual Learning]
Online
C$1525.75
Nov 26
2020
Details