Tag Archives: scrum

Agile coaching, coaching, culture, focus

The Perils of Meeting-Driven Culture

Leave a comment

Does your organization have a meeting-driven culture? Not sure? Ask yourself how much time you spend in meetings. Are they effective? Search the Internet and you’ll discover that we spend way more time in meetings than we’re comfortable admitting. The Harvard Business Review claims that the figure has doubled in the last 50 years.

The designers of Scrum recognized this and deliberately kept the formal meetings to the bare minimum. It adds up to around 12-15% if you use the entire time box. Contrast this amount to many organizations and you will discover that Scrum is quite efficient.

Many organizations I’ve consulted for don’t have deliberate rules on how to conduct meetings. They’ve allowed the meeting culture to evolve on its own. As such, meetings are not very productive.

However, practising Scrum doesn’t automatically make you immune to this meeting burden. Teams still operate within the same office and with the same people. Scrum and Scrum Masters can help teams have better meetings.

Here is a typical example of the transition from meeting-driven culture. I was coaching a Scrum team and worked in the team room alongside the development team. On several occasions (over several weeks) I asked the team to review the product backlog and make estimates. They brushed it off and refused to do this work. Instead, they did this at Sprint planning, despite complaining that it made the session long and exhausting.

I wondered if the ‘familiarity’ of the team room discussions made the backlog work appear less important. So I created a meeting outside the team room and sent an invitation via Outlook. Everyone accepted.

I kept the meeting as a regular occurrence, and the backlog review work got done ahead of Sprint planning. The team was much happier.

Why did this work? It succeeded because the organization had a meeting-driven culture—that is, planned events sent a signal that important work requires a meeting. The extra meeting clearly wasn’t necessary, but it succeeded.

This exercise helped me realize that organizations have so many meetings because they have few ways to engage.

Many office cultures don’t promote face-to-face meetings. Could it be the desk arrangement? They don’t value the serendipity of impromptu meetings. In the absence of frequent, short, high-quality meetings, people are forced to meet in rooms away from their desks.

If you see this meeting-driven culture in your organization, it’s likely an expression of what it values. Improving it will require discussions on what you value more. Shall we plan a meeting?

When I train Agile classes (Scrum, Kanban), I ask the attendees to make a list of activities that they can start right after the class. Number one on that list is co-location. That is, move your team to the same space so that they are sitting beside each other.

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
Scrum Master

9 Ways to Identify the “Perfect” Scrum Master

3 Comments

Preamble

Is there such a thing as a perfect Scrum Master? Likely not, because of course we are all human and not perfect beings. However, we can make a case for skills that contribute to becoming a perfect Scrum Master.

In 2017, Ken Schwaber and Jeff Sutherland updated the Scrum Values document, and in a video that same year discussed the changes they were making. They talked at length about the Scrum Master role. To quote Ken Schwaber, “It’s a very tough job”.

The 2018 new Scrum Guide states:“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide”.

In short, the Scrum Master (SM) serves the Product Owner, the Development Team, and the Organization. This involves facilitating Scrum events, coaching and educating, removing impediments, and much more. It is safe to say that successfully undertaking those relational interactions requires good people-oriented behaviours, or soft skills.

We may not normally think of Scrum Mastering in the same breath as soft skills, but a discussion lead me to consider this. A colleague stated that a good Scrum Master must understand 4 things: the business s/he works in, the technology s/he works with, Agile and Scrum principles, and, most importantly, people! Based on his experience, he was adamant that Scrum Master certification is not enough – that soft skills should be part and parcel of their training.

How can some of these soft skills be taught?

The Certified Scrum Master Training

The first thing a CST can do is model soft skills in his/her training class: treat all the attendees with respect, be clear about the goals of training, listen and be attentive to questions and concerns, create a safe learning environment, demonstrate honesty and trustworthiness. Modelling these behaviours is one way a CST can teach without words.

But in two days, is role-modelling enough? Let’s look at the Scrum Guide for clues. “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” http://www.scrumguides.org/scrum-guide

How much are these values discussed in training? What does “courage” or “openness” look like? In-depth discussion, with examples/activities of each of those values/ skills, could go a long way in teaching soft skills.

Scrum Masters can be guided through specific exercises that help them understand and practice the Scrum Values of courage, openness, respect, commitment, focus. As well, specialized skills can be taught, including leadership, negotiation, conflict resolution, compassion and more.

I recommend a video called “Agile and Scrum Soft Skills Needed to Drive Process Success” which provides helpful guidance:
https://www.youtube.com/watch?v=owa1fftIfzA&t=7s

9 Best Skills for the “Perfect” Scrum Master

After polling the readers of the REALagility Newsletter, I’ve put together this list of skills that many of us believe every Scrum Master should strive for:

  1. Listening well – to your team, your organization and especially your stakeholders
  2. Empathy, friendliness and respect – builds a collaborative culture
  3. Trust – you do what you say, walk the talk, and create safety
  4. Openness and transparency
  5. Identify and help solve problems
  6. Create a learning environment – for continuous learning and improvement
  7. Show courage – remember Schwaber’s “It’s a very tough job!”
  8. Support team, team members, PO and CEO! – why the CEO? S/he has to be on board with the changes and growth.
  9. Be service-oriented/team-first attitude – it’s not about you; it’s about serving the people and the process. This is why Scrum Masters are often called “servant-leaders”.

Post Script

Additionally traits that readers added: “Altruistic”, “has humor/fun-loving”, “proactive”, “easy-going & strict”, “can cheat”!

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 Engineering

Customers Don’t Pay Me to Write Tests: The Importance of Tests

Leave a comment

As a technical agile coach and trainer, I help teams discover ways of testing. Some teams ignore tests altogether, while others write every possible test possible, wasting valuable time and not being able to deliver at a good pace.

My first question is always this: How much does the customer pay for tests?

Nothing.

That’s right! Not a dime. I don’t even ship my product to them with any tests. They aren’t even compiled into bytecode for them. They are not going to pick up my application and open a debugger to make sure I’ve written tests that pass. They don’t care how many tests I’ve written or my code coverage ratio. They don’t care about unit, integration and acceptance tests, or how much time I spent on mocking and stubbing to isolate my functions. They only pay for working software.

So why write them?

I don’t write tests for the user. I don’t write tests for management. I write tests for me. I write tests for my future self. I write tests for my team members and any other developer that will need to change my code.

I write tests to prove that what I have written is what I have intended. I write tests to make my code manageable, to help me refactor when, inevitably, a new feature or change request arrives. I write tests so that I can fearlessly alter a system and know what I will break, and to find and repair bugs quickly before they are pushed into production.

I write tests so that my team members can feel a sense of code ownership, so that they too can alter, improve and remove my code and be able to predict the outcome. I write tests so that it becomes a form of documentation of the capability of the system.

Certainly they take time to write, but they save all kinds of time when it comes to changing things later. They allow me to do the one thing that software needs to do in the rapidly evolving market: adapt. I can adapt quickly to the needs of my customers to deliver quality features rapidly.

I write as many tests to make myself and my team feel confident that we can continuously develop a quality product at a sustainable pace, responding to the changes of the market and the needs of our customers. I write enough tests that I am releasing nearly bug-free code and I write as many tests as needed to satisfy just that!

In my Agile Software Developer training events, I help developers learn ways of writing tests to improve the quality of their work, so that they are able to spend more time developing new features rather than debugging old ones.

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
Kanban, Scrum, XP and Lean, Uncategorized

The Real Relationship Between Scrum & Kanban

3 Comments

(Image: Cover image of the book Essential Kanban Condensed by David J. Anderson and Andy Carmichael.)

Many people I interact with seem to believe that Kanban is another Agile methodology for helping Agile teams manage their work. The aim of this post is to help people see how Kanban can be so much more.

I am aware that there are some who believe that a high performing, self-organizing, cross-functional Agile team is as good as it gets and that it is the job of Leadership to change the organization such that this kind of team becomes a reality. This is a belief that I also held for many years, during which time I actively advised my clients to pursue this lofty goal and I invested a great deal of time and effort towards helping them achieve it. I understand this belief. It is very powerful, so powerful that it shapes identity. Therefore, it was a big part of my own professional identity and this was not easy for me to change. I empathize with those who struggle in similar ways as I have.

I could go on with my personal story, but I’ll get back to my opening statement. Kanban is so much more than just another Agile methodology. So what does this mean? How can it be so?

In my own experience helping businesses improve for over a decade and from the many stories I’ve listened to of the people I’ve met in my consulting engagements, training classes, conferences and meetups, the ideal of fully cross-functional teams is not a reality, not even a feasible possibility for their organizations and this reality is causing them pain and harm.

Let’s be clear about what we mean by cross-functional teams: According to the Scrum Guide (paraphrasing), a cross-functional team is a team that possesses all the skills required for starting and delivering potentially releasable product increments in a Sprint. A Sprint is a complete project that must be completed in one month or less. Many organizations add to this the idea of establishing stable teams (membership does not change) and Sprints of 1-2 weeks in duration. For many organizations, integrating all of the above is simply not realistic.

Most people I meet who are working with Agile teams (mostly Scrum teams) have already done everything they can to create the conditions for their teams to realize this ideal. Teams are already as “Agile” as they can be under the current constraints. Leaders have already done everything in their power to remove the constraints.

Some would describe this as a “failed Agile transformation”. But it need not be so. Rather, I have begun to see it as a natural stage in some organizations’ maturation process. Perhaps at an organizational level it is analogous to the “Storming” stage of the Tuchman maturity model: “Forming”, “Storming”, “Norming” and “Performing”. Regardless of the best analogy, the important point is that an apparent failed transformation does not have to be a bad thing. It also doesn’t mean you need to start all over again (with another re-org) in the hopes that you will “get it right” the next time. Rather, it is a natural stage of organizational maturation and the frustration, pain and conflict you are experiencing are telling you that your organization has an opportunity to evolve.

Kanban helps organizations move beyond this difficult stage. The Kanban principles of service orientation and evolutionary change help organizations focus on improving survivability of the business and the sustainability of the work. All of the Kanban practices are evolutionary stimulants for whole-organization improvements and they all scale naturally to all levels of an organization.

Kanban can help Scrum teams. Kanban can help with project, program and product management. Kanban can help with portfolio and enterprise services planning and management. Finding ways to implement the practices, little by little, at all levels of your organization will enable your organization to become fitter for the purposes of your customers, fitter for survival.

The Kanban Method, as opposed to other approaches, has built in double loop learning feedback loops. This makes it always contextually appropriate to help any organization. -Martin Aziz

The Kanban Principles:

Change Management Principles:

  • Start with what you do now;
  • Agree to pursue evolutionary change;
  • Encourage acts of leadership at all levels;

Service Delivery Principles:

  • Understand and focus on customer needs and expectations;
  • Manage the work, let people self-organize around it;
  • Evolve policies to improve outcomes.

The Kanban Practices:

  • Visualize the work;
  • Limit work in progress;
  • Manage the flow of work;
  • Make policies explicit;
  • Implement system feedback loops;
  • Improve & evolve with data, models and the scientific method.

 

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
Introduction To Agile

Agile Blog: Scrum vs Open Agile vs Kanban (Visual Summary)

3 Comments

Welcome Agilist…whist we focus on ‘Being’ Agile, ‘Doing’ Agile goes hand in hand towards achieving a common goal…here is a quick visual comparative summary of 3 closely related but unique systems (Scrum, OpenAgile and Kanban) to get started…

  1. Origin
  2. Domain Application
  3. Time Availability for Change
  4. Roles
  5. Workflow
  6. Frequency

Ref:

https://www.scrum.org

http://www.openagile.com/

https://leankanban.com/

 

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
Theory of Agile

Agility: Knowledge Generation and Beauty

1 Comment

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:

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 coaching, coaching, culture, How-To Apply Agile, Miscellaneous, Scrum Master, Scrum, XP and Lean

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

1 Comment

“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:

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
Kanban, Scrum Master, Uncategorized

Slaying Hydra: The Story of A Business Agility Coaching Partnership

Leave a comment

Part I of III

Summer 2014. The IT group of “Big Data Marketing” was in the full throws of an Agile transformation spearheaded by the new CTO. I was brought in as a Scrum Coach. My initial objective was to launch a couple of Scrum teams and serve as their Scrum Master. Around the same time, the firm’s head of PMO had been re-assigned as the Agile Practices Lead (APL) and he and I began working together on supporting the new Scrum Master community of practice, populated by his new reports. Our work gradually evolved into much more than what either of us could have imagined at the time. This 3-part series is my first attempt at putting down the story of that partnership.

In addition to serving as the initial Scrum Master for some of the teams, I was also trying to help existing team members transition into the Scrum Master role. I wanted to develop internal capacity so that I could focus on supporting a growing program of multiple teams. As the number of Scrum Masters and teams I was supporting increased, so too did the need for collaboration with the APL.

At the time, senior IT leadership was focussed on getting those doing the work of creating value (the teams) to fundamentally change the way they were working. That is, into self-organizing teams with Scrum Masters as “servant-leaders”. This included the reassignment of project managers as Scrum Masters and business analysts as Product Owners and staff into cross-siloed teams.

Chaos and confusion ensued. It was a deliberate strategy of senior leadership: Disrupt the culture of complacency. Force people to transform by throwing them into chaos. Throw everyone into the deep end and the right people will learn to swim.

A great deal of pressure was placed on the Scrum Masters to measure and improve team performance (based on pseudo-metrics such as story point velocity). They were essentially told to create a new identity for themselves and this was painful. Similarly, the APL was on the hook to support all these people in their new roles – to be a “servant-leader of the servant-leaders”. This concept of servant-leadership was front and centre in the conversation: “What is it, and how do we make it work here?” My role was to help create a shared understanding of the desired new culture.

I discovered months later that the day after I started the engagement, around 50 people had been fired. This had nothing to do with me, but naturally people thought that it did. Even years later, this day was commonly referred to by the survivors as “Bloody Monday”. Because of the timing of the mass-exit, unprecedented in the company’s 25-year history, staff understandably regarded me as the consultant who advised the cull. It’s not exaggerating to say that it instilled terror, was emotionally coupled with the transformation as a whole and implicated me as an individual. I thought of myself as one contributing help, but I was regarded as one contributing to harm. I saw myself as a Hippocrates but I was known as a Procrustes. I only learned about this months later, after I had finally managed to cultivate a bond of trust with some folks. A consequence of this fear was that I found myself in many one-on-one sessions with new Scrum Masters who were struggling to adapt and afraid of being the next victim to lose their jobs. Rather than providing Scrum Master therapy, I should have been helping the company to improve its delivery capabilities.

The theme of this first stage was the deep, broad and painful disruption of people’s lives caused by this deep Satir J-curve transformation model deployed by senior management. What I didn’t fully appreciate at the time is that emotionally, people experience change the same way they experience pain. The human brain literally responds the same. Not only were these human beings experiencing deep, chaotic change, they were also experiencing deep pain. And I was complicit in this.

The other contract coaches and I attempted to bring the crisis to the attention of senior management. We believed that it was a leadership problem, they believed that it was a staff complacency problem. The standoff lead to the coaches losing access to the leaders we were trying to help. This was a deep crisis for the group of coaches and the staff. The staff were beginning to see us as their advocates and we failed. For many Agile coaches, their part in the story ends here. In fact, some of the coaches on our team soon decided to move on to other opportunities. Others were not asked to extend their services beyond their initial contract term. Fortunately for me, the story didn’t end here. I will share more about this in Parts II & III of this series.

A teaser: These days, I advise and coach senior management to take responsibility to deliver services to customers, to understand what makes their services fit for the purposes of their customers and to design and evolve service delivery systems the fitness criteria of which are transparent to all those involved in the work. Then, allow people to truly self-organize around how the work gets done. In other words, manage the work not the people.

To be continued…

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 in Theatre-making

Agile and Scrum in Directing a Play

Leave a comment

Before learning about and working within an Agile framework, I was a theatre arts professor, and directed countless play productions, large and small, modern and classical. I believe I took to the way of Agile quite naturally because it aligned with so much of my creative processes as a theatre-maker.

Recently, I had the opportunity to direct a newly-written script of a play called AfterWhys, which was commissioned by the Suicide Awareness Council of Wellington Dufferin. My BERTEIG colleagues supported me taking this on amidst my regular responsibilities.

After a five-year hiatus from theatre-directing work, I became extremely conscious of the natural alignment between Agile and Scrum principles and practices, and my style of directing. Here’s some of the principles and processes I used:

  • Cast actors that you can determine to have the capacity to play a variety roles – in other words, they have “cross-functional” skills as actors.
  • At first rehearsal, behave like a Scrum Master with a “team” – the director’s role is to encourage, support, and remove obstacles that may prevent them from doing their best.
  • At the first rehearsal, be vulnerable about who I am and how I work, and invite them to share their experiences and hopes as well, as in “individuals and interactions over processes and tools.”
  • In the first read-through of the script, invite the actors not to act – to just feel their way through the text and the scenes without pre-judging how they should be. Many directors pre-plan every movement and how every character should behave, sound and look before even starting rehearsals – I don’t, as in “responding to change over following a plan.”
  • Give them “the tools they need” to realize the truth of their characters and embody them – “teach if necessary,” ie. I taught the cast a new way to analyze their scenes which they found was very helpful.
  • Create the space and the environment necessary for experimentation, i.e. an environment of trust and safety, of failing fast, and learning and discovering.
  • Direct the scenes, scene changes, and costumes in response to the expressed needs of the stakeholders; in this case, the play would tour and be performed in a variety of venues, therefore simplicity of props, costumes and scene changes was a necessity.
  • Use the days and weeks of rehearsals as “sprints;” what is the desired outcome of each sprint? Rehearsals were time-boxed, and we had a four-week “delivery” goal.
  • Be transparent about progress – what’s working, what’s not, and how can I help each and all work better?
  • Hold a time of reflection (retrospective) at the end of each week or sprint – allow for the expression of feelings, concerns, questions, needs, etc. This created greater transparency, trust and unity in the “team.”
  • When actors change a direction or try something new that is not in the script (plan) and it works to enliven the play and make it more meaningful, I encourage them to keep that, as in “responding to change.”
  • The stakeholders (those who commissioned the play and organized their performances) came into the rehearsals twice to give their feedback on what we were creating. They were extremely pleased with the “product.”

To sum up, although this was clearly not a technical situation or a business, many of the Agile principles were used to create a finished product – a social issue play on elder suicide that went before appreciative audiences!

When I think about so many realms of life that we all work in, it is clear that Agile principles can be used in a variety of scenarios and endeavours to ensure a positive outcome.

What endeavours have you been involved in where Agile and Scrum were useful?

 

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 teaching, agile training, Introduction To Agile, Scrum Master, scrum team improvement, Scrum, XP and Lean

A Litmus Test for Agility

3 Comments

Being Agile seems to be the rage these days and everyone has an opinion on what Agility means and how to do it “right”.  This article doesn’t make process recommendations, but it does provide a quick, effective way to help your team and organization get on track with being Agile (primarily a mindset measurement) and not just doing Agile (primarily a practices measurement).  Presented below is a simple and lightweight test that can be applied by almost anyone; it provides clear steps for improvement, and it is geared for alignment with the core Agile Principles and Values.

The Need

CoachThere are lots of Agile practitioners, coaches and trainers out there claiming to be experts.  Some are genuinely skilled while others have a few key certification letters beside their name and yet little to no in depth, real-world experience.  Although most have a genuine intent to help and they might actually succeed at it, others might inadvertently do more damage and provide harmful guidance.  How can you help them help you?

FrameworkThere are also numerous frameworks, methodologies, and practices that claim they are well suited to help an organization become more Agile.  Some of them are simplistic, process-based approaches that may not account for your environment, culture, or specific business needs, while others are more complex and pragmatic.  Depending on your situation it can be tricky to know what will work best.  How can you find a suitable fit?

MeasurementThere are also many tools and approaches to measure a team’s Agility, the leadership’s alignment with Agile, or the organizational maturity.  Some of these simply measure the number of practices (i.e. are you doing Agile), others account for an in depth assessment of cultural factors (i.e are you being Agile), and some are based on scenarios that are idealistic given common real world business challenges.

Indeed there are a wide variety of indicators of varying complexity, so you might be challenged to determine if they are simply vanity measures, helpful health indicators, or suitable fitness criteria, and more specifically if they appropriately measure for the outcomes you are looking for.  How can you ensure they are providing valuable insights and actionable results so you may make data driven decisions?

Keep it Simple and Focused

Given all these complexities, how do you know what it really means to be Agile, how can you align the effort, and how do you know how successful you are?

The answer is keep it simple and focused, and be outcome driven. Specifically, start with the foundations of Agile and then evaluate Agility from your perspective, your organization’s business needs, your employee’s needs, and most importantly from your customer’s needs.  Then, use that information to measure and steer improvement towards your real desired outcomes of Agility.

In the spirit of keeping it simple and focused, I’m sharing a “quick” and lightweight Agility Litmus Test and Procedure below to measure how you are doing and to ensure you, your stakeholders and your approaches are all headed in the right direction.

A Straightforward Procedure

1) Align With The Agile Manifesto

Read the Agile Manifesto.  I don’t mean gloss over it on the train on the way to work, or over lunch, or during your kid’s sports game.  I mean READ it, focusing on the twelve guiding principles AND the four value statements.

If it helps, boil each of the twelve principles down to two or three key words to provide clarity.  Then, when reviewing each principle ask yourself what you think it really means, and why you think it was important enough for the signatories to explicitly call it out in the Manifesto (what the intent was).  To ensure everyone has a similar frame of reference you may find it useful to host a time boxed, focused discussion on each principle.

2) Choose Key Agile Measures

Of the twelve principles ask yourself which ones (pick 3 or 4 at most) are core, or most important to you and your stakeholders (your organization, your leadership, your customers and your team).  Don’t just speculate or guess what the answers are; you will likely need to facilitate several workshops with the appropriate people to get to the truth to those questions.

This activity in itself is a test.  If there is not close alignment on what the most important principles are then stop right here.  Do not proceed until you align on what those key principles are.  If you proceed without alignment you risk working against one another and not towards a common goal or outcome.  Note that getting alignment might prove contentious so you may need a series of facilitated sessions to hash it out.

Once you align on several core principles they become your key indicators for the Litmus Test for Agility.  These are also your defined Agile outcomes, because they encapsulate what it specifically means for you to be Agile (where you want to be).

3) Perform a Critical Assessment

Starting with your key indicators, honestly answer the question how close or how far away are we” for each one.  Use a scale of 1 to 7, where 1 means “not close at all” and 7 means “we are totally nailing it”.  I chose 1-7 because it gives just enough range to differentiate measures.  That, and it is exactly 1/2 of the pH range for a proper Litmus test!

Be sure to seek fair and equal participation in this evaluation, as it is important to help reduce bias and ensure perspectives are accounted for.  This means you should ensure you have adequate representation from as many groups as is practical.

Honesty and transparency are also extremely critical here so you may require a facilitated session.  You may also need to provide a safe environment to encourage honesty in responses, so anonymous scoring and evaluations would be an appropriate technique to use.

4) Determine Actions

Critically review the summary of evaluative responses for your key indicators.  If the average is less than 6 out of 7 then hold a strategic planning session to determine actions to get you closer to achieving those outcomes.  Note also if there is a wide dispersal of the individual responses for a key indicator that would strongly suggest there is a large misalignment amongst the respondents, and you need to address that gap.

One question to ask would simply be “what would it take…”, or “what would we need to do to get us to a 6 or higher?   When following this line of reasoning be sure to account for the coaches, practitioners and experts you are relying on by asking “What can or should they be doing to align with our key indicators and Agile outcomes?”

Also, look at the frameworks and approaches you are using and ask “How can we switch, change or improve our ways to improve Agility?”

Finally, look at the tools and measures you are leveraging and ask “Are these vanity measures or are they really meaningful?” and “How can we improve these measures (not just the values, but the metrics themselves) to provide more meaningful insights and help us better realize our defined Agile outcomes?”

As a group then choose at least one and no more than three specific actions that came out of the discussion above, implement them, hold one another accountable for them, and measure on the next round if your actions had the desired effect of improving the scores for your key indicators.

5) Learn and Refine

Repeat steps 3 and 4 of this procedure at frequent and regular intervals, being sure to not only measure but also define and take new action.

6) Reassess and Pivot as Needed

If time permits or if your key indicators all show consistent strength, consider switching to some of the other Agile Manifesto Guiding Principles.  If it seems logical you may even want to go back and repeat the entire process as your needs and outcomes may have changed.

Conclusion

The core value this Litmus Test for Agility provides is a) in its simplicity, b) in it’s inherent alignment with the Agile Values and Principles, and c) in its focus on what matters most for you and your stakeholders.  It uses the Manifesto as a foundation, and then allows you to focus on what is most important to you.

Like all tests and models this approach has some inherent strengths and weaknesses.  For example, it is lightweight, cheap, easy to implement, and aligned with core Agility, however it is not an extravagant or in depth test so it may not account for complexities.  As such it should never replace sound judgement.

Meanwhile, if you sense or feel there is something deeper going on that may be impeding your organization’s ability to become more Agile then be sure to investigate thoroughly, work with others to obtain nonpartisan assessment, and provide clarity along the way on intent, outcome, and learnings.

If you are practicing Scrum, using a more sophisticated tool such as Scrum Insight (a virtual “Coach-in-a-Box”) can provide much richer, deeper feedback and insights, including recommended actions.  Even the free version of the tool provides keen insight.

Depending on circumstance you might also find it advantageous to call in expert facilitation, advisors or coaches to either conduct an Agility test such as this or even help your team or organization get to the heart of their issues and challenges.  Organizations such as BERTEIG are not only Agile teachers but they are also hands-on practitioners that can coach your team and organization to reaching new levels of Agility, either with a lightweight touch or a fully immersive engagement.

Coincidentally, reflecting, collaborating, providing transparency, and adopting a continuous learning and improvement mindset are in and of themselves indicators of Agility.  So identifying core values such as these and then making them part of your Agile Litmus Test (i.e. making them your new Agility outcomes) shows how simple it can be to improve, adapt and grow even this lightweight approach!

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
Announcements, Scrum Master

Announcing the Launch of Scrum Insight – an Automated Online Scrum Coach

Leave a comment

Scrum Insight is a tool for Scrum Masters and Scrum Coaches to help them improve their teams.  It leverages the accumulated experience of six expert coaches in an automated online tool.

Scrum Insight Logo - Online Scrum Coach

We have just launched version 1.0.  This version includes easy access  to a free report.  It also includes an optional paid Professional report that replaces the equivalent of 83 hours of on-site coaching.

For Scrum Masters this means access to Scrum coaches that may not otherwise be affordable.  For Scrum Coaches, this means leveraging your time to make progress on the hardest problems facing your Scrum teams.

Using Scrum Insight

Using Scrum Insight is a simple two-step process:

  1. Get all your team members to fill out the Scrum Insight survey (and remember to save everyone’s “survey codes”!!!).
    Taking the survey requires between 8 and 11 minutes.  It seems like a long survey, but is actually very quick to go through.
  2. Load your survey codes and generate your team’s report.
    The free report includes a single piece of advice optimized to your team, plus a score for how well you are doing Scrum and how well your organization is supporting your use of Scrum.
  3. (Optional) Upgrade your report to the Professional version for just $500.
    The Professional report gives you much more in-depth advice, more detailed score breakdowns, a permanent link to your report and much more.

So far, 102 teams have used the Professional Scrum Insight report, and many more the free report – let your team be the next to take advantage of Scrum Insight.

We have posted a more permanent description of Scrum Insight as a page here on Agile Advice.

Reminder: when you do the survey, keep your survey code(s) and print the report that is generated.  We don’t collect your email address to use the free report so there is no permanent way to access it other than using the survey code(s).

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

Mind-bender: A Scrum team increases their velocity by doing less work!

1 Comment

Sub-title: Breaking the Iron Triangle

Sub-title #2: Jeff Sutherland’s book could have been called: “Scrum: Twice the decision-making in half the time leading to half the work and twice the output.”
But every smart publisher would throw out that title.

A discussion is raging at LinkedIn about the Iron Triangle because Jeff Sutherland, co-author of Scrum, often says that “Scrum breaks the Iron Triangle”. This, you can imagine, causes ripples through the Project Management community. Mr. Sutherland also speaks of “Velocity” and sometimes as a way to explain the breaking of the Iron Triangle, he’s known to say that a Scrum team can increase their velocity by employing various patterns of behaviour which reduce hand-offs, increase quality, et cetera — and this “breaks” the Iron Triangle.

I have captured some thoughts on the subject below.

In Product Development, the end state cannot be known in advance of starting — that is, the scope cannot be known in advance of starting. And even after starting, the product scope changes rapidly as market conditions and users’ needs change and/or are better understood.

Therefore, the iron triangle is a weak model to apply. The Iron Triangle is a useful model only if the conditions which define scope, time, and cost have low variability. If building a house, for example, the end state can be known before starting its construction; apart from the paint colours and some finishing touches, every part of a house can be modelled and codified before starting its construction. Thus, the Iron Triangle can be useful to inform discussion and decision making: would we like to speed up construction of the house? Maybe…so let’s spend more to hire more contractors.  Will cost change if we add another bedroom and detached garage?  Probably, unless we buy cheaper materials.  See, the variables have predictable outcomes.

If developing product, such as creating software wherein the future states of the source code are unknowable, the iron triangle causes weird discussion and isn’t likely to improve decision-making. Perhaps other theories of constraints can be more useful.

Theories of constraints share a common supposition: “a chain is no stronger than its weakest link”. In complex, adaptive problems, the weakest link is neither scope, nor quality, nor time, not cost, nor knowledge, nor technique — it is common understanding or coherence.  Note, those factors are missing from the Iron Triangle. The Iron Triangle quickly becomes an irrelevant model in the realm of Product Development or complex/adaptive problem-solving. The only way to force the Iron Triangle model in this realm is to consider ‘time’ to be, not just a variable, but a changeable dimension. That is, as a Scrum team increases cohesion and alignment, they make decisions faster — this has the effect of making ‘time’ slow down, they can make more decisions per unit of time as though the team is travelling faster through time.  Weird, right?  So it’s just easier to throw away the Iron Triangle.

About Velocity

Yes, Jeff Sutherland discusses velocity in depth. But I’d like to remind everyone his definition of velocity…

Velocity is a measure of distance travelled over time. In other words, the *distance travelled through the Product Backlog* over *Sprint Length*. To say that velocity, in Scrum, is the speed of the Scrum team is quite inappropriate. More appropriately, an increase in velocity means the team is travelling further through the Product Backlog per Sprint.  It helps to stop thinking of the Product Backlog as a bunch of items and a bunch of story points. It’s more helpful to think of the Product Backlog simply as ‘the work that needs doing’ — a Scrum team can increase their rate of travelling through ‘the work that needs doing’ by…well…by learning.

An increase in a team’s velocity does not mean (necessarily) they are going faster. It OFTEN means they are going smarter. A Sprint is a learning cycle. The team learns as they work together. (Where’s “learning” in the iron triangle!??) When Mr. Sutherland  says Scrum “breaks” the triangle, I believe he is thinking of this very notion of learning. As transparency increases, the team can make better decisions, meaning they can eliminate waste (doing LESS work!!) and cohere more rapidly and achieve high-quality decision-making, thus going increasing their output.

“One of the ways a team increases their velocity is BY DOING LESS WORK.”

As a Scrum team travels through the backlog, a learning team will discover ways to reduce work per Product Backlog Item: they’ll figure out ways to automate a bunch of repetitive stuff; they’ll produce modular designs which create opportunities for reuse and adaptation; they’ll learn from their mistakes, reduce risk, and increase quality. (These are the results of learning as a team and one of the key reasons for Scrum’s rules that a Scrum team is small and has stable membership for long periods — communication saturation enables cohesion and therefore enhances learning…as a team.)

In other words, the team finds ways to travel further through the backlog each Sprint while not working harder/more.

Hence, the iron triangle as weak model for understanding the constraints in complex problems.

Tip: Angela Montgomery has written extensively about Theory of Constraints in complex settings — her writings are waaaaay more helpful to us in the realm of Product Development than the limited Iron Triangle.

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

IT Project Agility

5 Comments

Over the years I have done a number of talks for local chapters of the Project Management Institute.  They have covered a range of topics, but one common theme that comes up over and over is that Scrum is not the best Agile method for delivering an IT Project.  I even published a short video on the topic:

Several years ago, I also published a short article describing what Scrum is good for:

What is Scrum good for?

So… if Scrum isn’t so good for IT project work, then what can bring real agility to IT projects?

IT Project Attributes

Most of my work experience prior to running my business was in IT projects in banking, capital markets, insurance and a bit in government and healthcare.  I mention that merely to indicate that my discussion of this isn’t just theoretical: I’ve seen good projects and bad projects.  I’ve been on death-march projects, small projects and massive projects ($1b+).  I’ve dealt with regulatory issues, vendor issues, offshoring issues, telecommuting issues, architectural issues, political issues, and seen enough problems to understand the complexity of reality.

IT projects have some common characteristics:

  1. Like any project, there’s a deadline and a scope of work and a budget.  These things don’t work well with Scrum.  It’s possible to force them to fit together, but you lose a lot of what makes Scrum effective.
  2. IT (as opposed to, say, tech startups) tends to use more mature technology platforms.  Scrum is neutral about technology, but there are other Agile methods that address this type of technology more effectively.
  3. IT Projects are often not the only thing going on in the technology organization.  In particular, operations and user support add to IT project complexity, and require different “classes of service” than Scrum provides.
  4. The issues that I mentioned above such as regulation, vendors, offshoring etc. are also common attributes of IT projects.  Scrum makes harsh demands on an organization that challenge the approach to dealing with these issues.  The change required to accommodate Scrum may not be worth it.

The Bad News about IT Project Agility

The whole project orientation to IT work is questionable.  It’s just not a good fit.  In most mid- to large-size organizations, IT does two things: it provides technology services to the rest of the organization, and it provides technical product development capacity to lines of business.  For example, upgrading the office wi-fi routers and adding a new payment type to the online customer portal, respectively.  The work of the IT department, therefore, falls into several different categories:

  1. New artifacts that need to be created.  Usually this is the stuff like coding algorithms and other business logic, creating new databases, configuring purchased systems, etc.
  2. Repetitive activities that need to be sustained for a period or indefinitely, or which occur on-demand but at irregular times.  For example, running a nightly batch process or deploying an update to a production environment.
  3. Quality problems that need to be fixed.  Defects and production problems are the obvious categories here, but also quality problems that are causing user confusion or time wastage.
  4. Obstacles to work that need to be overcome.  Often obstacles come from outside the project team in the form of interruptions. Other forms of obstacles can be unexpected bureaucracy, shifting funding, problems with a vendor, etc.
  5. Calendar events that need to be accommodated.  Milestones in the project, particularly regulatory milestones are crucial in IT project work, there are many other types such as all-hands meetings, statutory holidays, hiring or contract end dates, etc.

Of these, only repetitive activities and calendar events fit well into a project perspective.  The others typically have a level of uncertainty… complexity… that makes it very difficult to approach with the project perspective of fixed deadlines and scope.

On the other hand, Scrum only really handles new artifacts and obstacles directly, and quality problems indirectly.  These are the kinds of activities that are the focus of product development.  Repetitive activities and calendar events are anathema to the core Scrum framework.  If I think about this from a scoring perspective, Scrum supports these kinds of work as follows (-5 means totally counter, 0 means no impact, +5 means total support):

Scrum Support for IT Project Work Types:

  1. New artifacts: +5
  2. Repetitive activities: -2
  3. Quality problems: 0
  4. Obstacles: +4
  5. Calendar events: -5

SCORE: +2 – barely positive impact on IT project work!!!

The bad news, therefore: neither a project orientation nor Scrum really cover all the needs of an IT project environment.

(For more information about Scrum, check out our “Rules of Scrum” page, our “Scrum Diagram” article, and our highly-regarded Certified ScrumMaster learning events.)

Alternatives to Scrum

There are many, but these are my three favourite alternatives: Extreme Programming, Kanban and OpenAgile.  All three of them cover the five types of work more effectively than Scrum.  All three of them are oriented to more generic types of work.  After describing each briefly, I’ll also mention which one is my top choice for IT project work.

Extreme Programming for IT Project Work

Historically, Extreme Programming (XP) emerged in an IT Project context: the famous C3 project at Chrysler.  This approach to IT project work has many things in common with other approaches to agility (which are described in the Agile Manifesto).  XP allows the five types of work as follows:

New artifacts are the core of XP and are usually expressed as User Stories.  This is common to Scrum and many other Agile methods.  These are typically the features and functionality of a system… the scope of the project work.  XP does not make any strong assertions about the size or stability of the backlog of new artifacts and as such can accommodate the project orientation in IT with relatively fixed scope.

Repetitive activities are not explicitly addressed in XP, but nor is there anything in XP which would cause problems if an XP team is required to do operational or support work which is the source of most repetitive activities in an IT environment.

Quality problems are addressed directly with both preventative and reactive measures.  Specifically, Test-Driven Development, Acceptance Test-Driven Development are preventative, and Refactoring and Continuous Integration are reactive.  XP has a deep focus on quality.

Obstacles are not directly addressed in XP, but indirectly through the XP value of courage.  Implicitly, then, obstacles would be overcome (or attempted) with courage.

Calendar events are not addressed directly for the most part with the exception of release planning for a release date.  However, the stuff related to other calendar activities is not directly handled.  XP is less antagonistic to such things than Scrum, but only by implication: Scrum would often put calendar events in the category of obstacles to be removed to help a team focus.

XP Support for IT Project Work Types:

  1. New artifacts: +5
  2. Repetitive activities: 0
  3. Quality problems: +5
  4. Obstacles: +2
  5. Calendar events: +1

SCORE: +13 – moderate to strong positive impact on IT project work!

Summary: much better than Scrum, but still with some weaknesses.

Kanban for IT Project Work

Kanban is different from most other approaches to agility in that it is a “continuous flow” method, rather than an iterative/incremental method.  This distinction basically means that we move packages of work through a process based on capacity instead of based on a fixed cadence.  Kanban asks that we visualize the current state of all work packages, limit the amount of work in progress at any stage in our delivery process, and use cadences only for iterative and incremental improvement of our process (not our work products).

Kanban is much gentler than Scrum or Extreme Programming in that it does not require leader-led reorganization of staff into cross-functional team units.  Instead, we identify a service delivery value stream and leaders manage that stream as it currently operates.

You can read a somewhat slanted history of Kanban here, and a good comparison of Kanban and other Agile methods here.

New artifacts in Kanban are supported, and certainly welcome, but Kanban does not seem to acknowledge the problem of formal complexity (creativity, problem-solving, human dynamics) in the creation of new artifacts.  There are good attempts to apply statistical methods to the management of new artifacts, but their fundamentally unknowable cost/end (undecidable problem) is not really effectively addressed.

Repetitive activities are handled extremely well in Kanban including different classes of service.  Repetitive activities are handled well partly as a result of the history of Kanban as a signalling system in manufacturing environments.

Quality problems are handled similarly to new artifacts: supported, welcome, and even possibly addressed in the cadences of continuous improvement that Kanban supports.  However, quality problems are another area where technical complexity makes proper analysis of these activities difficult.

Kanban relegates the handling of obstacles to the manager of service delivery.  There is no explicit support for strong organizational change efforts.  In fact, Kanban discourages “transformative” change which is sometimes required given the problem of Nash equilibriums.

Kanban works well with Calendar events by treating them as activities with a particular class of service required.

Kanban Support for IT Project Work Types:

  1. New artifacts: +3
  2. Repetitive activities: +5
  3. Quality problems: +3
  4. Obstacles: 0
  5. Calendar events: +5

SCORE: +16 – strong positive impact on IT project work!!

Summary: even better than XP, easier to adopt. (Actually, almost anything is easier to adopt than XP!!!)

OpenAgile for IT Project Work

OpenAgile is an obscure non-technology-oriented method based on the work I and a few others did about 10 years ago.  The OpenAgile Primer is the current reference on the core of the OpenAgile framework.  OpenAgile has been applied to general management, small business startups, sales management, mining project management, emergency services IT, and many other areas of work.  I’m partial to it because I helped to create it!

OpenAgile emerged from consulting work I did at CapitalOne in 2004 and 2005 and work I did with my own business in 2006 and 2007.  A great deal of the older articles on this blog are forerunners of OpenAgile as it was being developed.  See, for example, Seven Core Practices of Agile Work.

The types of work listed above, are indeed the core types of work described in OpenAgile.  As such, OpenAgile fully supports (nearly) all five types of activities found in IT projects.  However, OpenAgile is not just a work delivery method.  It is also a continuous improvement system (like Kanban and Scrum) and so it also assumes that a team or organization using OpenAgile must also support learning.  This support for learning means that OpenAgile does not over-specify or give precise definitions on how to handle all five types of work. Thus, my scores below are not all +5’s…

OpenAgile Support for IT Project Work Types:

  1. New artifacts: +4
  2. Repetitive activities: +4
  3. Quality problems: +4
  4. Obstacles: +4
  5. Calendar events: +4

SCORE: +20 – very strong positive impact on IT project work!!!

Summary: OpenAgile is the best approach I know of for general IT project environments.

Conclusion

Regrettably, I wouldn’t always recommend OpenAgile – there are just too few people who really understand it or know how to help an organization adopt it effectively.  If you are interested, I’d be happy to help, and we can certainly arrange private training and consulting, but mostly I would recommend Kanban to people interested in taking the next step in effectiveness in IT projects.  Please check out or Kanban learning events and consider registering for one or asking for us to come to your organization to deliver training, coaching or consulting privately.

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, Kanban, Uncategorized

Kanban: Real Scaled Agility for Your Enterprise

2 Comments

Your business is an ecosystem of interdependent services, a complex adaptive system.

A bunch of organizations I know started their journey of increasing their agility with Scrum. That didn’t solve all of their problems. Kanban enables organizations to evolve their service delivery systems towards mature business agility.

As addressed in How Kanban Saved Agile, pure Scrum is extremely rare. Scrumbut (the disparaging label that spawned from so many organizations reporting that they do Scrum, but…) on the other hand, is extremely common.

In order to not be Scrumbut, you need the following:
  • Cross-functional development team of 7 +/- 2 people—ALL skills needed to ship product is present on the team—there are no dependencies external to the team;
  • One source of demand with no capacity constraints—the Product Owner is the customer AND full-time member of the team;
  • Sprints are one month or less, begin with starting new demand from the Product Owner and end with the delivery of potentially shippable Product Increments, followed by a retrospective about how to do better next Sprint;
  • “Potentially Shippable” means that the decision about whether to actually ship is purely a business decision. All the technical work is done;
  • If all of the technical work required in order to ship isn’t done, then the Sprint is a failed Sprint;
  • The Scrum Master is a servant-leader and Scrum educator to the entire organization.

How many organizations do you know of with Scrum teams that meet all of the requirements above? I don’t know one.

So, what’s the solution? Give up on Scrum? Are we still getting benefits from Scrumbut? Alright, let’s stop it with the Scrumbut already. Let’s acknowledge what’s really going with real teams in the real world and call that Scrum. Let’s refer to the above  checklist as “Ideal Scrum”.

Agile scaling methods have become a popular risk hedging tactic for all the loose ends dangling around the real teams in the real world.

Here are some of the reasons for adding layers of scaling around Agile teams:

  • Teams are not fully cross-functional;
  • Teams have external and opaque depencies;
  • Many of these dependencies are shared services with multiple sources of demand and constrained capacity—often overburdened;
  • External dependencies can be other teams—demand from other teams shows up in their backlogs, prioritized by their own Product Owners;
  • Many dependencies don’t play by the same rules at all—some reside in a different part of the organization, with different structures and political forces;
  • The Product Owners are proxies for multiple stakeholders and customers and the Product Backlogs represent an array of multiple sources of demand, with different service level expectations, strategic origins, degrees of clarity, urgency and political forces pushing them into the deliver organization;
  • The Product Backlogs are made up primarily of solutions defined by stakeholders and translated by the pseudo-Product Owners as pseudo-user stories—how they get there is opaque, the “fuzzy front end”—and somewhere in here a fuzzy delivery commitment was already made;
  • The work of a Sprint includes all of the work that the non-cross-functional teams can get done—then whatever the teams get “done” is “delivered” (handed-off) to a subsequent set of teams or process steps (usually fairly well defined at an organizational level but outside of the teams’ influence);
  • Delivery decisions are made based on constraints imposed by legacy technology, systems and their gatekeepers (for historically good reasons);
  • The teams are “done” at the end of each Sprint, yet much work is still to be done before their “done” work is potentially shippable;
  • The Scrum Master’s are held collectively accountable for the collective deliverables of the teams and their ability to cross-team coordinate and integrate—accountability by committee translates into no one is actually responsible.
  • Middle managers are scrambling to pick up the pieces because they are actually accountable for delivered results.

Generally speaking, the aim of Agile scaling methods is to apply larger Agile wrappers around clusters of Agile teams in order to re-establish some kind of hierarchical structure needed to manage the interdependencies described above. Whether its a Release Train or a Nexus, or whatever else, the idea is that there is an “Agile Team of Teams” managing the interdependencies of multiple, smaller teams. As long as the total number of people doesn’t grow beyond the Dunbar number (~150), the Dunbar-sized group is dedicated and cross-functional, there is a team managing the interdependencies within the Dunbar, there are no dependencies outside of the Dunbar and there is some cadence (1-3 months) of integrated delivery—it’s still “Agile”. All of this scaling out as far as a Dunbar (and only that far) allows the enterprise to still “be Agile”—Scaled Agile.

This is all supposed to be somehow more realistic than Ideal Scrum (with perhaps am overlay of Scrum of Scrums and a Scrum of Scrum of Scrums). It’s not. How many organizations do you know of that can afford to have ~150 people 100% dedicated to a single product? Perhaps today there is enough cash lying around, but soon enough the  economic impact will be untenable, if not unsustainable.

How does Kanban address this problem? Your business is a complex adaptive system. You introduce a Kanban system into it such that it is likely that the complex adaptive system is stimulated to improve. The Systems Thinking Approach to Introducing Kanban—STATIK—is how you can make such a transition more successful (@az1):
  1. Understand the purpose of the system—explicitly identify the services you provide, to whom you provide them and why;
  2. Understand the things about the delivery of the service that people are not happy about today—both those whose needs are addressed by the service and those doing the work of delivering the service;
  3. Define the sources of demand—what your customers care about and why;
  4. Describe the capability of your system to satisfy these demands;
  5. Map the workflow of items of customer-recognizable value (@fer_cuenca), beginning with a known customer need and ending with the need being met through stages of primary knowledge discovery (Scrum teams somewhere in the middle, towards the end)—focus on activities, not looping value streams;
  6. Discover classes of service—there are patterns to how different kinds of work flow through your system (they are not arbitrarily decided by pseudo-Product Owners), what are they? Group them, they are classes of service and knowing them enables powerful risk management;
  7. With all of the above as an input, design the Kanban system for the service;
  8. Learn how to do steps 2-7 and start applying it directly to your own context in a Kanban System Design class;
  9. Socialize and rollout (learn how by participating in a Kanban Coaching Professional Masterclass);
  10. Implement feedback-loop Cadences for continuous evolution—learn the 7 Kanban Cadences and begin applying to your own context in a Kanban Management Professional class;
  11. Repeat with all of the interdependent services in your organization—every “dependency” is a service—Kanban all of them with STATIK and begin implementing the Cadences.

Don’t get hung up on teams, roles, your latest reorg, how people will
respond to another “change”, who’s in, who’s out, etc. These are all part of the service as it is now—your current capability. Initially, no changes are required at this level. The kanban system will operate at a higher level of scale. Through feedback-loop cadences, it will evolve to be fit for the purpose of your customers without a traumatic and expensive reorg.  Who is responsible for this? Identify this person. If you are the one thinking about this problem, there is a good chance that it’s you. Whoever it is, this is the manager of the service; take responsibility, do the work and make life better for everyone.

For more information about LeanKanban University Certified Kanban courses provided by Berteig, please go to www.worldmindware.com/kanban. Some spots are still available for our classes in Toronto, June 12-16.

For Agilists who have read this far and still don’t get it, start here:

14 Things Every Agilist Should Know About Kanban

The story below may be familiar to some:

Our IT group started with Scrum. Scores of people got trained. Most of our Project Managers became “Certified” Scrum Masters. Most of our Business Analysts became “Certified” Product Owners. We purged some people who we knew would never make the transition. We reorganized everyone else into cross-functional teams – mostly developers and testers. But now they are Scrum Developers. We tried to send them for “Certified” Scrum Developer training but hardly anyone of them signed up. So they are Just Scrum Developers. But we still call them developers and testers. Because that’s still how they mostly function—silos within “cross functional teams”, many tales of two cities rather than just one.

After the Scrum teams had been up and running for a while and we were able to establish some metrics to show the business how Agile we were (since they didn’t believe us based on business results), we had a really great dashboard showing us how many Scrum teams we had, how many Kanban teams, how many DevOps, how many people had been trained. We even knew the average story point velocity of each team.

The business didn’t get it. They were worried that Agile wasn’t going to solve their problem of making commitments to customers and looking bad because we still weren’t able to deliver “on time”.

As IT leadership, we were really in the hot seat. We started to talk about why the transformation wasn’t going as it should. We knew better than to bring the Agile coaches into the boardroom. They were part of the problem and needed to be kept at arms length from those of us who were making important decisions. Besides, their Zen talk about “why?” was really getting old fast. Some thought it was because we didn’t have the right technology. Others were convinced it was because we didn’t have the right people. After all, we didn’t go out and higher experienced (above-average) Scrum Masters and Product Owners, instead we just retrained our own people. Clearly that wasn’t working.

We started with improving the Scrum Masters. We went out and hired a few with impressive resumes. We developed some Scrum Master KPIs (HR jumped all over this one). Then one day we had a collective flash of brilliance—since the ScrumMasters are the servant leaders of teams, we will make them responsible for collecting and reporting team metrics and this will tell us how well the teams are doing and how they need to improve. This surely would be the key to improving the performance of IT and get us on a better footing with the business.

But we didn’t get the response we were hoping for. The ScrumMasters soon complained that the metrics of the teams were impacted by dependencies that they had no influence over. When we pushed harder and shamed them publicly for failing to produce meaningful metrics, they tried harder, but they weren’t able to do it. Some began disengage. “This is not the job I signed up for” became their new mantra. This was puzzling. We were empowering them and they were recoiling. Maybe we didn’t get the right Scrum Masters after all. Maybe we needed to go out and find people who could think and act effectively beyond the confines of their own teams. Or…

Affiliated Promotions:

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