Agility: Knowledge Generation and Beauty

Compromised Agility

The authors of the Manifesto for Agile Software Development expound a set of values and principles that define “Agile Software Development”. These values and principles, written in 2001, became the focal point of a revolution in how software developers work.

In the last several years, that revolution has spread beyond software development to encompass other aspects of technology, and beyond technology into operations, management, engineering, business development, sales, marketing and even outside of for-profit organizations into education, health, government, community and charitable organizations. Originally written in the context of software, we can easily generalize the values and principles to other types of work. For example, the Manifesto refers to valuing “working software over comprehensive documentation.” We can easily generalize this to a more abstract statement that we value “results over bureaucracy.” The other values and principles can be similarly abstracted.

As the revolution has spread, unfortunately, the values and principles have also become compromised or selectively applied. Perhaps most obvious is how Agile Lifecycle Management tools such as Jira have often been substituted in place of the first value of the Manifesto: “we have come to value individuals and interactions over processes and tools” [emphasis added]. The irony of this substitution seems to be lost on those selling and buying these tools. Many other compromises or selective applications are common, and they are usually unique to each organization’s circumstances.

This evolution of the application of the Manifesto’s values and principles can be understood negatively or positively. I’m an optimist; yet we need to look at the negative, critical side before we can see the positive.

Cargo Cult Agility / No True Agilist

There are two common ways to understand the failure of organizations to do “true Agile”. Both are negative in the sense that they are criticisms without a reasonable solution to help an organization out of the situation into a better situation. As a consultant seeing many organizations, as a trainer hearing about many organizations, and as an active member of the global community of Agilists, I hear these criticisms quite regularly.

The first approach to understanding this partial agility is by comparison to the cargo cult mentality:

A cargo cult is a millenarian movement first described in Melanesia which encompasses a range of practices and occurs in the wake of contact with more technologically advanced societies. The name derives from the belief which began among Melanesians in the late 19th and early 20th century that various ritualistic acts such as the building of an airplane runway will result in the appearance of material wealth, particularly highly desirable Western goods (i.e., “cargo”), via Western airplanes.

In this approach to understanding an organization’s failure to embrace true Agile, the critic asserts that the leaders and employees of the organization do not really understand true Agile and are only practicing the obvious ritualistic aspects such as daily stand-ups (from Scrum), note cards on a wall (from Kanban), or user stories (from Extreme Programming). This criticism has some merit: many people are told to “do Agile” without proper training and coaching to understand the theory or the contextual applicability of various practices. The critic continues to compare this approach to Agile as a belief in magic: that the benefits of Agile can be gained through an application of the rituals without an understanding of, and more importantly adoption of the values and principles.

The “cargo cult” criticism does not offer a solution. When asked, the critics themselves will say, effectively, “well, you just need to really understand it!” This criticism also suffers from the inherent notion of the superior position of the critic: “I understand it… you don’t.” Not particularly helpful, especially for the staff in an organization who depend on executives and other leaders to support true Agile. And, not particularly helpful for the executives who often do not have the skill to support such a deep change.

The second common approach to understanding the failure of organizations to achieve real agility is the “No True Scotsman” comparison. This is a bit more challenging to describe because it is actually a criticism of other critics. Wikipedia describes No True Scotsman this way:

No true Scotsman or appeal to purity is an informal fallacy in which one attempts to protect a universal generalization from counterexamples by changing the definition in an ad hoc fashion to exclude the counterexample. Rather than denying the counterexample or rejecting the original claim, this fallacy modifies the subject of the assertion to exclude the specific case or others like it by rhetoric, without reference to any specific objective rule (“no true Scotsman would do such a thing”; i.e., those who perform that action are not part of our group and thus criticism of that action is not criticism of the group).

The starting point of this criticism is actually the reciprocal of the cargo cult criticism: the critic conflates true agility with the compromise happening at an organization and then accuses agility of being a failure. This criticism is often brought up in the following style of discussion:

Person A: Agile sucks because Big Corp is trying Scrum but it is really just an excuse for executives to micro-manage every little bit of work.

Person B: But Scrum and Agile are against micro-management! Big Corp isn’t really doing true Agile.[NOTE: this is the cargo cult criticism in brief.]

Person A: That’s just an excuse. You’re using the no true Scotsman argument and it’s a logical fallacy. Agile is what people are actually doing, therefore Agile sucks.

Person B: !

Interestingly, this argument style is often used between competing brands of agility. Leaders of both the Scrum and Kanban approaches to agility are well known for this approach to argument, particularly about each other’s chosen approach: “method X doesn’t work, as clearly seen by all the organizations doing X badly, therefore you should try my method Y which does work.” Again, this is ironic given the first value of the Manifesto for Agile Software Development “…over processes….”

Like the cargo cult criticism, the no true Agilist criticism does not offer a solution, other than reverting to a non-Agile approach to work (or more rarely, another approach that suffers the same imperfect implementation in organizations). And, like the cargo cult criticism, there is some truth in the no true Agilist view: legitimately, many organizations are doing a very very poor job of applying the values and principles (and associated practices). The conclusion that Agile sucks and therefore we shouldn’t even be trying is forgivable. However, the people online proclaiming this problem tend to be loud in their conclusion: let’s go back to our halcyon bygone days where the wind was fresh, the sun was bright, and we were all bucolically happy with our defined roles, our rigid processes, and our tools we could blame for every failure of our efforts (ironic hyperbole intended).

Both criticisms, reciprocal as they are, leave a gap. They don’t offer a full explanation of what is happening, nor do they offer a positive path to improvement. For that, we need to change our perspective just a bit.

Knowledge Generation and the Benefit of Time

I have been working with Agile methods for over 20 years. As a programmer and then enterprise architect, I adopted agile methods relatively early – even before the term “Agile” was applied to software development and these methods were referred to as “lightweight” methods. I mention this not to tout my expertise or even my experience, but rather my perspective. I’ve “been around” enough to know with a fair degree of certainty the following important points:

  1. There is no large organization that has successfully “transformed” from a non-Agile state to an enterprise-wide Agile state. By “large”, I mean at least 5000 total employees.  By “transformed” I mean that it grew up using traditional techniques and has fully switched over to Agile management techniques throughout the total employee population. And by “successfully” I mean that it has sustained the use of Agile management techniques at the organizational level through at least one boom/bust economic cycle, and one change of C-Level leadership. (If you are reading this, and you know of such an organization, I would be excited to hear about it!)
  2. Large organizations that have high levels of agility typically started as small organizations with high levels of agility. Google, Amazon and Facebook come to mind. Their level of agility includes a high level of technical agility in addition to their management agility. I’m not sure, but I suspect that these two types of agility go hand-in-hand; certainly the Manifesto for Agile Software Development suggests they do go together.
  3. The only proof of transformation is in the sustainability of that transformation through existential crisis.
  4. Partial or compromised agility is the only kind of agility that is, so far, successfully sustained in a few rare cases of large organizations. Capital One is an example of this. They have been trying to adopt Agile methods and approaches since 2001. They have tried many techniques, and had many ups and downs in their journey. In 2017 at the Lean Kanban North America conference, two senior Agile coaches from Capital One asserted that they still have a long way to go for full enterprise agility – after working at it for 17 years already.

How does this compare to other management philosophies? The history of the Toyota Production System and Lean manufacturing, at least 50 years in the making so far, has shown us that revolutionary changes in the way work is done, can take many decades to become normalized. In the 1980’s and 90’s many organizations adopted “lean” as a management fad.  We saw a swift rise and then fall in the popularity of lean. But the core principles and ideas of lean survived, and have continued to spread throughout many industries. Now, many organizations are “culturally” lean: they won’t revert to other methods of working even in crisis situations… and many others are not yet there.

With a timeline of 50+ years, perhaps we can consider our efforts to transform organizations to a greater level of agility in a more positive light.  Human society at large is learning about agility though many many experiments run in thousands of organizations. Sometimes these experiments are motivated by wise and considered thought, but often, they are motivated by the faddish popularity of Agile methods such as Scrum, SAFe, and Kanban. Regardless of the motivation, the compromises organizations are making as they attempt greater levels of agility are part of a larger process encompassing all of human society in which knowledge generation is the primary outcome.

There is still one more problem to address: that individuals and organizations continue to try to improve agility even when they have experienced it done badly or seen it fail to take hold. One of my favourite authors and a prominent figure in the Agile community is Ron Jeffries. In the last couple of years, he has started to call out “Dark Scrum” as a blight in organizations that is causing suffering. I believe there is also “dark kanban”, “dark SAFe”, “dark extreme programming”, etc. These dark implementations of the various paths to agility, aren’t actually paths to agility for the people, teams and organizations implementing them. So again, why do people keep coming back to these methods?

Motivation to Try Again and Beauty

Let’s return to the Manifesto for Agile Software Development and here quote the four values. If you have read them before, even many times, I encourage you to read them again, slowly, and savour them:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I would like to assert that anyone who has read these values, and further, read the principles behind the manifesto has been attracted to the inherent beauty of these ideas. This beauty is the source of the motivation to try again. This beauty is the source of the influence of the manifesto. This beauty is the reason why so many want to “own” it through the creation of their own brands, methods, schemes, and promotions. And, this beauty, while it is constantly struggling against corrupting influences, is powerful enough to inspire people to come back to it even when they have seen the dark side of agility.

Real agility is a culture founded on the beauty that inspires these principles. It’s not any particular method, it’s not a formula, it’s not merely a set of laudable or effective practices. Rather, this beauty is inspired by the Spirit of the Age in which we live. As individuals, teams and organizations, we will rarely live up to that beauty, rather we will experience it in moments, greater or lesser, strung together by our efforts to increase humanity’s collective knowledge. And as that knowledge grows, our patience for the partial, incomplete agility of many organizations will also grow for it is the source of our new-found knowledge.


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

Selling Organizational Transformation – Part II

In Part I, I highlighted the basic importance of proper preparation in anticipation of an impromptu CxO meeting. The aim, of course, is to move up the organizational structure to the decision-makers who are most likely to require a greater portfolio of my services. My background is rooted in helping organizations achieve business agility so that they can better provide services that their customers desire.

If we pick up from the end of Part I, let’s assume I’ve piqued Sarah’s interest. There is a very strong possibility now that CEO Sarah will have an unscheduled, casual ‘elevator’ discussion with Christine about her efforts and perhaps even the work she’s contracting me for.

VP’s, like other Executives, hate surprises. Not knowing their relationship, there is a high probability that things will go south at this point, largely because I’ve potentially introduced risk to Christine and her career. The probability that something is going slightly ‘wrong’ in her portfolio is likely high. And she’s now on the CEO’s radar.

Next steps are obvious – it is imperative for me to speak with Christine, preferably face-to-face. Positioning the conversation is key now. In my experience, this is a “build trust” or “destroy trust” conversation. Prior to that face-to-face, I need to prioritize my talking points, which should be as follows:

  • Confirm the positive impact my team is having with respect to the organizational goals “to drive effectiveness and efficiencies”. Collect the “Yes”.
  • Determine the relationship, if any, she has with her CEO and determine the hierarchy between her and the CEO and, if possible, determine the alignment of their efforts to the CEO’s mandate (there is always a ‘black sheep’ in that mix and it could be Christine’s SVP, or even Christine herself, for instance)
  • Reduce the perceived risk by specifically reiterating the connection between my efforts, Christine’s efforts, and the corporate strategy. Collect the “Yes”.
  • Then, and only then, discuss the brief, impromptu elevator discussion I had with her CEO – and this takes tact and professionalism, and must be delivered with maturity.

My approach and the questions I’d propose, likely would take the following direction:

  • “Christine, what’s your overall ‘take’ on my teams efforts to….? [reiterate the mandate]”.
  • “Does your SVP share those thoughts, and is your leadership in the corporate strategy recognized?”
  • “And are your successes recognized outside of this channel?” [collect the “Yes”]
  • “Christine, you understand the corporate structure here, is there any risk that this project can be derailed, and is it important enough to thrive? Because, I am speaking in hypotheticals right now, but it has to look good for you, correct?” [collect the “Yes”]
  • [This is the tricky part] “Christine, you know part of my role is to champion you, your team and your efforts [insert mandate]. I wanted to meet today because I had the unplanned opportunity to speak briefly with Sarah about this particular project and she was quite keen about the positive work you are doing here. And specifically how it is in-step with the corporate mandate and her strategy. She was fully supportive of such efforts and I wanted to put this on your radar, should the conversation come back to you [pause].
  • “The other part of my job, of course, is to look for additional ways that we can help this organization. If I can help you, help your SVP and help Sarah in this process, then I’d like the opportunity to take a greater role and do so [stop].

I’m not going to walk away with a multi-million dollar contract today, but hopefully I achieved my objectives: clear the potential minefield of risk with Christine, deepen our relationship, gain further understanding of the organizational structure, continue to build trust, show that I am indeed talking with her peers and that I have the best intentions in doing so with her in mind, and I asked for further business.

In sales, we are always looking for that “inside champion” to help our deal move forward. In addition to this, I believe that in building better business relationships, the road goes both ways. I try to equally be that champion for my client. Because it serves so many purposes to do so, and it is the right thing to do as it aligns to the deeper principles I believe in, which are:

To create unity in diversity, and to help people orient their work lives towards service. To engage with people, and customer-focused organizations that seek to continually learn and grow. To work in the spirit of truthfulness, teamwork, and transparency, as this is the foundation of improvement.


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

An Analogy Between a Consultant/Coach and Paratrooper. Information and Adaptability is Key!

“Paratroopers are used for tactical advantage as they can be inserted onto the battlefield from … any location[. This] allows paratroopers to evade emplaced fortifications that exist to prevent an attack from a specific direction”

Excerpted from Wikipedia

I believe there are certain analogies between being a Paratrooper and being an Agile Coach or Consultant, including having strategic objectives, a purpose of infiltration, a sense of opposition, and a goal or cause that you believe in. However, I am not asserting that, a) implementing Agility at an organization is a declaration of war, b) Agility is a tactical warfare technique, or, c) being an Agile Coach or Consultant is synonymous to or nearly as dangerous a job as a Paratrooper.

Having said that, depending on the environment an Agile Coach or Consultant may sometimes feel like they are actually entering a corporate or political war zone. They are often viewed as outsiders posing a clear threat. They are often in the minority. They are often dropped in to unfamiliar territory. They often have incomplete or incorrect information. They are often surrounded by opposing forces. They are often made a target, either passively or aggressively. They often start with plans, but what makes them successful is their ability to adapt their plans and react to situations. In other words…be agile!

Like a Paratrooper, a Coach or Consultant is often “parachuted” or “inserted” in to an organization or foreign group with a specific mission. It is often to provide a “tactical advantage” and doing so helps a Coach or Consultant “evade emplaced fortifications [well established norms or strong opposition] that exist”, so they can get the job done from the inside and with less opposition.

A Paratrooper should always enter the field with a good understanding of the landscape, environment and situation. Similarly, a Coach or Consultant should also become familiar with the working environment and culture they are about to interface with. Without critical information both would risk the success of their mission and perhaps more. For a Paratrooper a lack of information could be life threatening, but fortunately the threat is not usually life threatening for organizational change agents.  It just might be professionally damaging to their career as well as others and their business.

 

Perform Reconnaissance

To that effect, I believe if you are a Coach or Consultant then you should still perform advance research for your intended mission in order for you to be successful, provide value and create an opportunity for learning and improvement. This means you will need to have conversations with both the leadership of their target (organization) and also with the people doing the work. Here’s why.

Leadership (usually the “paying customer” is management in the organization) should have specific and measurable outcomes they want achieved, and it is critically important for you to identify what those are up front and how they are expected to address their business problems. Meanwhile, the employees (usually the workers or teams) are often directly associated with and intimately familiar with the true needs and system issues, so you must also become familiar with their understanding for perspective. Unfortunately, the first battle is often that workers and their leadership do not align on their expectations and outcomes, and without their alignment you have little hope of true customer satisfaction and helping them collectively solve their real business problems.

As such, to manage expectations and increase chances for success it is critically important for a Consultant or Coach to investigate and identify both the needs of the leadership AND the needs of the employees, and then work to align them before any substantial work takes place. The best approach is to have face-to-face conversations with all the leadership and employees but that can take considerable time in a larger organization. So how do you get a realistic pulse of the company without talking to absolutely everyone?

 

Assess the Team

If the team(s) are using Scrum as a framework then one option is to use a Scrum team assessment tool like Scrum Insight. This tool provides objective coaching advice tailored specifically to a Scrum team as it is designed to detect how aligned the team is to Scrum practices and methods. The free version of this tool provides access to the basic report which contains the team’s overall scores, a “quick win” recommendation that identifies and provides suggestions that can be made to provide the biggest improvement on the team, and a list of support resources. The paid service provides everything in the basic report as well as a detailed Scrum Score Card, a Team Environment Score Card, a relative industry ranking, other education and support resources available for consideration, and it is usually followed up with a personal call to provide you with detailed explanation on the results.

Here is a sample Team Environment Score Card from Scrum Insight. Detailed descriptions for each bar/category are provided in the report:

SI Team Environment Score Card
Scrum Insight – Team Environment Score Card

 

Here is a sample Quick Win Report from Scrum Insight A more detailed description is provided in the report, and it is tailored to the team’s specific challenges and opportunities.

Scrum Insight - Quick Win
Scrum Insight – Quick Win

 

If you would like more information, you can also view a full sample report from Scrum Insight.

 

Assess the Organization

Another option is to conduct a REALagility assessment – either for a team, a group or an entire organization. The assessment is a 10 minute online survey conducted by every individual, and it is designed to uncover the misalignments between what leaders think and what employees think in an organization. The resulting report reveals the soul of the current culture, and it is grounded in real, actionable data to improve on the problem areas unique to the organization. As a Consultant or Coach these insights can be invaluable in helping you prepare for the engagement, identify opportunities, create alignment, and elicit real, meaningful and sustainable change for the organization.

Here is a sample diagram from a REALagility assessment, showing the relative rankings for an organization around five cultural measures. Detailed descriptions and insights for each cultural score are provided in the report.

Real Agility Assessment - Cultural Scores
Real Agility Assessment – Cultural Scores

 

Conclusion

In summary, I find it immensely helpful to “arm” myself with information prior to a Coaching or Consulting engagement, and these tools have been pivotal in filling that gap. Having early access to information such as this enables insights that might otherwise not be detected until I am on the ground helping the individuals, teams, and leadership tackle their business problems, which saves time, frustration, and money. An additional advantage with leveraging these electronic evaluations is that they provide an opportunity for people to provide ideas, feelings, agreements or disagreements that they may hesitate to share in a face-to-face interview.

There are certainly other tools that are designed to provide insights and information, but I’ve chosen these two because of my familiarity with them, and because of their effectiveness.

Of course, I would never replace good, valuable conversation with tools or data, but I do find these tools provide additional contextual information that further enables me to ask the right questions and have the right conversations early in an engagement. Finally, these tools can also be used as a benchmark for comparison of progress after a period of time has elapsed, which allows you as a Coach or Consultant to measure and be accountable for success.

 

Main Image – Paratrooper

Public Domain Image

http://www.acclaimimages.com/_gallery/_pages/0420-0907-2418-1546.html

Stock Photograph by Department of Defense Public Domain

Image Number: 0420-0907-2418-1546

 

 

 

 

 


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

Six Rules for CHANGE – Notes from a Talk by Esther Derby

Hired to help change and grow a business? These ideas are a guide for agile coaches and consultants, when you’ve been asked by a company to make them “agile.”

Esther Derby began by noting that traditional ideas of change can get in the way of real change. For example, ideas such as “Driving the change” or, “Installing Agile” or, “Evangelizing Agile” are not helpful.

What is helpful is to NURTURE complex change in complex environments.

Her Six Rules are:

1.Work from a stance of congruence.

Congruence is a place from which empathy is possible. Consider your own internal state, the context, and the situation of the people who are facing change. Think about what legitimate reasons they may have to keep things as they are!

2. Honour what’s valuable about the past and what is working now.

Don’t force people to admit they’ve been wrong. Shift your language, i.e. “This served you well when…” People don’t change because of data, but only because of what they value!

3. Assess the current situation and the current system.

How is the system working now? What holds the current pattern in place? What might shift the pattern? Who benefits from the status quo, and who will benefit from change?

4. Work by attraction.

Find those who are willing to work with you, i.e. try pair-programming with someone. Find your allies and follow the energy. Don’t rely only on the formal hierarchy. Analyze existing networks, activate and enhance them. Those who cross silos can influence others and change people’s norms. Ideas can be contagious.

5. Guide the change, and work by successive approximation.

Everything (and everyone) thrives in different conditions. Not every scrum team needs to work in the same way. Consider where global principles apply, and what can evolve locally. “When people get their fingerprints on something, it becomes theirs.” Ask for more of this, and less of that – scrum teams aren’t necessarily standardized.

6. Use experiments.

Big changes scare people. Experiments help people practice and learn. Insert at least 3 ideas – not more – then observe, evaluate and adjust.

7. (Esther tacked on this extra…) Use your own curiosity, generosity, patience and self-care. Use yourself. Change is often stressful.

These are my notes from the Regional Scrum Gathering, Toronto, March 2018, and any misunderstandings of Ms. Derby’s presentation are mine.

See also http://www.agileadvice.com/2015/02/10/referenceinformation/retrospective-technique-what-did-you-learn/


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
Coach Skills for the Agile Workplace (3-day)
Toronto
C$2018.00
Dec 10
2018
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1095.00
Dec 12
2018
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Dec 19
2018
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$2495.00
Jan 4
2019
Details
Certified Agile Leadership® (CAL1)
Toronto
C$2200.00
Jan 10
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jan 15
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Jan 18
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Jan 22
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Jan 24
2019
Details
Team Kanban Practitioner® (TKP)
Ottawa
C$930.75
Jan 30
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jan 30
2019
Details
Kanban System Design® (KMPI)
Ottawa
C$1440.75
Jan 31
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Feb 5
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Feb 6
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Feb 12
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Feb 19
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Mar 6
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Mar 12
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Mar 14
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Mar 25
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Mar 26
2019
Details
Kanban Management Professional® (KMP II)
Toronto
C$1355.75
Mar 28
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Apr 2
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Apr 16
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Apr 17
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
May 8
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
May 15
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Jun 4
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Jun 5
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Jun 18
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Jul 3
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Jul 4
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 9
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Jul 11
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Jul 30
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Jul 31
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Aug 1
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Aug 28
2019
Details