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

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Finding Compassion – Lessons Learned From My Street

It may be a cliche to be talking about “Compassion” in the workplace, as it is a “concept” that has been addressed multiple times over many years.

Frankly, it is difficult to actually put into practice. And for me, it was something I explored, adopted, and then ignored, over the past number of decades as real-world priorities shifted.

But I want to share a very personal story that unfolded just today. Bear with me on this, as I will relate this personal situation to the workplace interactions we’ve all likely experienced.

My neighbour is a struggling single mother to whom I genuinely want to succeed, as she is a dedicated mother and a hard worker. However, she recently took a very base-level approach to an emotional situation that affects many people within my neighbourhood.

In short, her dog has behavioural issues which have lead to attacks and mock-attacks upon myself, my family, local contractors, and fellow neighbours. Latitude has been given to her in each instance as she has made earnest efforts to curb this behaviour, but for the most part, she has had marginal success. Most recently the dog actually attacked a local boy, who spent 3 days in hospital as a result.

Clearly, the issue with the “dog in the room” needed to be escalated and dealt with. The injured boy’s father rightly requested that a muzzle order be put in place: an order that has subsequently been appealed by the owner.

Think about this for a moment.

The position of the dog owner just changed, from “I am making earnest efforts” to “my dog is not the problem. You are the problem”.

Why?

Well, there’s been a trigger event and it’s because of a strong emotional connection to her dog. To justify this, she has created a “story” about all the people that are involved in this situation: the young boy in the hospital “provoked” the dog. The “dog doesn’t have the problem, everyone else does, and it’s all lies”. My personal situation in which I had to physically defend my family from the aggressiveness of this loose dog “never happened”. And of course the contractor who locked himself in a room until she came home……. well, you get the point.

It is very easy for me, as a professional who is accustomed to teams, and boardrooms, proper process, HR, and mature interactions that move business forward, to look at her position as an immature and flailing attempt to justify a deeper need. An  emotional need to protect the love she has for this dog and what the dog represents as part of her family.

Relating this to business, I’ve met people who have acted much like her in the workplace. The same story of innocence the dog owner positions, is often found in the boardroom! The questions are why, and secondly, do such people tend to remain in their position or do they get moved along?

They survive. While they may be unskilled and unready to address the actual deep personal issue driving their behaviour, they often position themselves in a very innocent light, and they tend to point out those “liars” around them.

The light went off for me when I found myself emotionally wrapped up in being called a liar by a person who was clearly to blame. How do you defend yourself with your “team skills” and “boardroom skills” against a person with “street skills”?

That is where I found Compassion.

As in situations with my co-workers, colleagues, clients and friends, I realized that this single mother is just trying to provide her son with a home, an education, a pet to call his own, and in between, cut the noise in her life, and find her own sense of happiness while shouldering 100% of the burden.

Moving this concept to the workplace, could it be that a percentage of your colleagues who sometimes leave you scratching your head, have some well-developed “street skills”?

After today I do believe it begins with you – not them – just as this personal revelation with the neighbour began with me.

In the end, the injured son’s father expertly resolved this emotional powder-keg: and I learned it’s not about defending against the accusations, it’s doing exactly what this father did.

He listened to all parties with genuine interest and curiosity. He asked neutral-based questions, keeping his emotions in check. He did not take the accusations personally. He sought answers and he sought consensus. He asked for timelines and process. He often asked for help, and sometimes he had to escalate (i.e. getting a muzzle order) where he needed. But he exercised Compassion at every step.

I learned that defending myself against accusations is not the name of the game: it’s about taking the father’s approach. His Compassion renewed Compassion in me.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What Kanban Is (And Isn’t)

The Kanban Method is a management method for…

  • Directly improving service delivery
  • Catalyzing improvements
  • Evolving a business to be fit for purpose

The Kanban Method is not…

  • A project management method
  • A software development lifecycle process.

Your organization is an ecosystem of interdependent services—a complex, adaptive system. You introduce a Kanban system into it such that the complex system is stimulated improvement. – Alexei Zheglov

This wikipedia entry provides a fairly accurate description of the Kanban Method:

https://en.wikipedia.org/wiki/Kanban_(development)

The Kanban Method has 3 Agendas:

  1. Survivability  (of the business, for business executives)
  2. Service-orientation (for all levels of management)
  3. Sustainability (for professional services knowledge workers)

The Kanban Method has 9 values:

  1. Customer focus
  2. Transparency
  3. Understanding
  4. Agreement
  5. Leadership
  6. Respect
  7. Collaboration
  8. Balance
  9. Flow

The Kanban Method has 6 principles; 3 change management principles and 3 service delivery principles.

Change Management Principles:

  1. Start with what you do now.
  2. Agree to pursue improvement through evolutionary change.
  3. Encourage acts of leadership at all levels.

Service Delivery Principles:

  1. Understand & focus on customer needs and expectations.
  2. Manage the work, let people self-organize around it.
  3. Policies govern service delivery.

The Kanban Method has 6 practices:

  1. Visualize
  2. Limit WIP
  3. Manage flow
  4. Make policies explicit
  5. Feedback loops
  6. Improve & evolve

LeanKanban Inc. is the authority on the Kanban Method. LeanKanban University is the accredited training organization of LeanKanban Inc.

David J. Anderson is the founder of the Kanban Method.

Travis Birch is an Accredited Kanban Trainer with LeanKanban University. You can sign up for his upcoming public Kanban courses in December 2017 at Berteig World Mindware.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Sleep and Productivity – Sustainable Pace

Good article on sleep and productivity – you need at least 6 hours per night to not fall into a vicious cycle of lower productivity leading to longer work hours, less sleep, and then lower productivity.

The Agile Manifesto asks us to work in such a way that we can maintain our pace indefinitely.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What if no one was forced to do Scrum?

I just commented on a LinkedIn thread about “Sprint Zero”. It occurred to me that Sprint Zero is often used as one of many coping mechanisms for people who are forced to do Scrum. It also occurred to me that in my 9 years or so working with a reliable sample size of Scrum teams, not one of those teams was populated entirely by people who were not coerced into doing Scrum.

Gut check: The percentage of people I know who are currently on Scrum teams and who would be doing Scrum if it wasn’t mandated by management could be lower than 50%. This begs the questions: What if Scrum was offered to teams as an optional way to manage their own work? Would there be less Scrum in the world?

With one exception, all of the Scrum teams I have worked with were mandated (forced) by management to implement Scrum. The exceptional team was exceptional in other ways. They were by far the happiest and most revolutionary (in terms of recognition for business success in their organization). Although one or two hesitant team members were roped in by their peers, the social climate of the team allowed the wary to adapt safely and gradually to their new reality.

For the overwhelming majority (in my experience), there is an irony, even a paradox at play. A lot has been said & written about how command and control management is antithetical to Scrum. Yet, many—if not most—Scrum adoptions are commanded by management with vanity metrics (i.e. velocity) installed to uphold the illusion of control.

What are some of the other coping mechanisms for people who are forced to do Scrum? What is driving this behaviour? How many of these behaviours have been labelled as “anti-patterns” and why?

Safety is an essential success factor for any organization. Is it safe for people to choose to not do Scrum, or express dissent about Scrum adoption in their organization? What does this tell us about Scrum itself? Does Scrum need to be reimagined or reframed in order to make Scrum adoption safer for more people? Is it safe to do so?


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Build Positive Relationships With Trust in Your (Work) Life

Trust is an exceptional quality that we humans can develop with each other. It goes a long way to building positive relationships. We hope and strive for trust in our families, and with our most intimate connections. Yet do we expect trust in our work lives?

Can you imagine the  relief you might feel entering your work space, knowing that you can do your work with confidence and focus? That encouragement rather than criticism underlies the culture of your workplace? That a manager or co-worker is not scheming behind your back to knock you or your efforts down in any way? That you’re not being gossiped about?

Trust is especially key in today’s work spaces. Teamwork is becoming an essential aspect of work across every kind of business and organization.

Here’s what one team development company writes about this subject:

The people in your organization need to work as a team to respond to internal and external challenges, achieve common objectives, solve problems collaboratively, and communicate openly and effectively. In successful teams, people work better together because they trust each other. Productivity improves and business prospers. http://beyondthebox.ca/workshops/team-trust-building/

It Starts With Me and You

As with so many qualities in life, the idea of trust, or being trustworthy, starts with me and you.

It is essential that we take a hard look at ourselves, and determine whether or not we display the attributes of trustworthiness.

To do this, I might ask myself some of these questions:

  • Do I tell the truth?
  • Do I avoid backbiting (talking about others behind their back)?
  • Do I do what I say I’m going to do?
  • Do I apply myself to my work and do my best?
  • Do I consciously build positive relationships with all levels of people in my workplace?
  • Do I encourage or help others when I can?

There are many more questions to ask oneself, but these offer a place to start.

One website proposes a template to assess employees in terms of their trustworthiness:

Trust develops from consistent actions that show colleagues you are reliable, cooperative and committed to team success. A sense of confidence in the workplace better allows employees to work together for a common goal. Trust does not always happen naturally, especially if previous actions make the employees question if you are reliable. Take stock of the current level of trust in the workplace, identifying potential roadblocks. An action plan to build positive relationships helps improve the overall work environment for all employees.

http://smallbusiness.chron.com/develop-maintain-trust-work-relationships-12065.html

This snippet comes from “Lou Holtz’s Three Rules of Life,” by Harvey MacKay:

“The first question: Can I trust you?”

“Without trust, there is no relationship,” Lou said. “Without trust, you don’t have a chance. People have to trust you. They have to trust your product. The only way you can ever get trust is if both sides do the right thing.”

http://www.uexpress.com/harvey-mackay/2012/5/7/lou-holtzs-3-rules-of-life

Asking questions helps me to be more aware and to learn. What might you change to help create greater trust with your colleagues or team?

As well, what actions can you take to help your team to experience greater trust altogether?

You can read more about Trust at http://www.agileadvice.com/2017/05/29/uncategorized/soft-skills-revolution-may-want-team-development/

Valerie Senyk is a Team Development Facilitator, Blogger, & Customer Service Rep at BERTEIG. You can learn about her Team Dev workshop at http://www.worldmindware.com/AgileTeamDevelopment


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leveraging Six Sigma Projects with Agile Techniques

Six Sigma is a methodology which has been used for more than 30 years to deliver great strategic and financial results. It has brought significant results for industries and companies from different industries.

I am a Master Black Belt in Six Sigma, and for the past 15 years I have trained over 5,000 people and conducted projects for many companies in South America, North America, and Europe.

Globalization has shortened the distance between customers and business, requiring more speed and adaptability from companies to sell their products and services.

Through a combination of training and consulting in Six Sigma, my team has been supporting organizations to embrace projects towards variability reduction as well as waste elimination to increase customer satisfaction. Millions of dollars have been saved, and we have satisfied our stakeholders.

The reward for our success was that project opportunities came flowing in, yet we were challenged to complete projects even faster and better than before. How could my team do that? We needed to figure out a way together. More and more frequently we were collaborating with our customers and stakeholders to understand exactly what was important. We were inviting the team, analyzing many possibilities, rethinking our approach and then implementing the new framework.

The business environment forced new techniques to achieve different results. I realized that if I challenged our team at the planning meeting stage, we would find new ways to reach the goal (most of the time utilizing a better approach than before). Even if, during the process, we encountered a roadblock, we were able to involve the team to find a creative solution. We found we could do almost anything because we had created an environment of trust.

All along, our stakeholders were aware of what was happening, and they were encouraging the team to keep using the ‘new strategy.’ We stopped wasting our time with delays, dropped the useless documentation, while always ensuring that people were seen as more important than the process. Because of this, we were already delivering results faster than expected and had started the process of becoming Agile.

David Vicentin, Director of Business Development, BERTEIG

Lean Six Sigma Master Black Belt, Coach, Trainer and Agile practitioner, has more than 15 years in management consultancy experience delivering operational excellence and Agile implementation across various businesses. His experience and capabilities have taken him to Spain, United States, Mexico, Brazil, UK and Canada. David’s enthusiasm and practical coaching experience have allowed him to mentor senior managers to achieve sustainable results. An Industrial Engineer with a Masters degree in Economics and Finance, David is able to create an environment of learning in various fields of work.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

IT Project Agility

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Equifax Data Breach: Lessons We Must Learn

I woke up this morning to the news that my personal data has been leaked by Equifax to…who knows!?  I was reminded of the following tweet:

So, what “awful circumstances” led to Equifax’s recent breach?

Let’s reflect:  News has surfaced (TechCrunch, Reuters) that hackers have scraped untold amounts of sensitive data from Equifax systems.  143+ million people are affected as hackers have amassed a huge database of names, addresses, credit records, license numbers, banking histories.  (That probably includes you too!)

I want to be clear though, the news broke yesterday but the problem started long ago.  The security vulnerability has existed for (probably) years and I have no doubt some Equifax staff have known about it.

Equifax!  We’re not talking about some high-school project with junior coders and tech newbs.  We’re talking about one of the world’s most trusted organizations.  We’re talking about a company whose very existence (their whole business!) is to protect our collateral.  This is supposed to be one of the best-funded, most secure, most technologically-advanced companies on the planet.

But I’m not surprised.   Here’s why…

I teach Scrum and my classrooms are filled regularly with people who work in companies exactly like Equifax.  I hear their stories every day:

“Our managers don’t provide the tools we need to do the job.”

“Our managers don’t understand the time required to deliver high-quality software.  We’re always pressured to cut corners to meet arbitrary and impossible deadlines.”

“Our systems are broken, everyone knows it, but managers continue to outsource and off-shore our QA.”

“We don’t have authority to decide the implementation, we’re often told what to implement by architects and supervisors, even if we know it to be rotten.”

“Our managers never ask us about quality…they ask us only ‘when will this be done’?”

And that’s the crux of the problem: people are hired by companies like Equifax to provide technical expertise, then their advice is ignored and their implementation decisions aren’t trusted.

Some important questions to consider…

1. Does Equifax lack the money to hire excellent technical staff?

No, their offices are filled with some of the best programmers in the world.  I meet them (or people like them) regularly in my classes and I have no doubt that the technical staff at Equifax have warned the managers for years of security holes and technical defects.  I have no doubt those managers have ignored the alarms and have pushed the staff to deliver deficient code.

2. Does Equifax lack the time to build high-quality systems?

No, last I checked they’ve been at it a long time and their existing contracts will carry their operation years into the future.  And as mentioned earlier, securing our data is the reason the company exists.  It’s  the one thing they’re supposed to get right – I’d think their time should be entirely devoted to building high-quality systems.

3. Does Equifax lack the financial resources to invest in proper tools and training for security/quality testing?

No, such techniques and tools are widely available and inexpensive (even hackers can afford them!)  Managers at Equifax have denied budgets for training, tools, and upgrades because “it’s too costly” – hmm…I wonder the cost of this data breach?

4. And my favourite question of the day: Are the hackers “smarter”?

Absolutely not.  But they’re more dedicated and have equipped themselves with good techniques and tools for penetration testing.  In my personal experience as a hacker (er, I use that term loosely) security holes are all around us if we look for them.  Equifax simply wasn’t looking!

What to do about it…

First, it’s clear to me the problem isn’t technical or financial.  It’s cultural.  I see it all the time.  Teams of good product developers are surrounded by bureaucracy instead of support.   Teams of good coders aren’t trusted to see the source code of the systems used by the company – yes, that’s as crazy as it sounds!  Teams of good coders are kept silent about the security vulnerabilities they see.  Solutions are ignored by management and the arguments are: “improving the security isn’t a priority right  now” or “we know there are some possible security concerns and we are in discussion with vendors or outside agencies to address it” or “we have a budget for security improvements scheduled for next quarter; let’s focus for now on new features instead”.  Managers are more concerned with deadlines than with quality.  Managers scrutinize the number of hours a developer works on a task, and outsource or off-shore the quality assurance and testing!  Managers conduct endless planning activities then compress the implementation into tight budgets and timelines – evidently, a lot of energy is spent getting the plan “right” but getting the software right is not a priority.  I could go on.

If you’re interested to know how things work at Equifax, just think of the Dilbert cartoons.  I mean it.  I am very serious.  Dilbert isn’t funny because it’s fiction; it’s funny because it’s NON-fiction.  Sadly. Typically, for enterprises like Equifax, their technical staff and customers take a back seat to management “theatre”.  This needs to be fixed and it starts by asking the technical staff a single, simple question:  “Who among you have raised concerns about technical debt with your managers/supervisors and were ignored?”  That question will unearth bugs which have been deprioritized by managers, budgets that have been denied for technical training and automated testing, projects which have been reported as “done” before they were actually ready for deployment – in other words, that question will reveal the many (fixable) ways managers get in the way of quality.

Second, executive staff at Equifax need a crash course in automated testing.  Yes, THE EXECUTIVE STAFF!  It’s is essential they understand and see with their own eyes that:

  1. Automated testing is cheaper and exponentially more effective than manual testing;
  2. ALL defects are discoverable and fixable before hitting production environments;
  3. Quality is not something one outsources
  4. and the techniques to achieve ZERO DEFECTS are well-known, teachable, repeatable, and proven.   I’m of course referring to techniques like Test-Driven Development, Continuous Integration, Refactoring, and Swarming.  For example, these technical topics form the bulk of our Certified Scrum Developer classes. (Shameless plug.)

And third, technical staff need to stop behaving like sheep.  So far in this article, I’ve been very critical of managers, sure, and anyone who knows me personally knows I have no time for inept management.  But too often I meet smart, well-meaning developers who deliver shoddy code – perhaps at under pressure and against their better judgement, but in the end whose code is it?  Developers! I understand you might feel trapped in a pattern of quantity-over-quality and you are frequently coerced by your management to cut corners.  I get it… I understand it… it’s easy to feel that deadlines are some sort of immutable truth and that managers wield all the power.  But the fact is, developers, YOU hold all the responsibility and therefore you need to be the professional.  You need to say “no” and demand the latitude you require to deliver high quality.  You’re the one closest to the code and therefore directly responsible for the safety and well-being of your users.

So, Equifax and enterprises everywhere, I’m speaking now as your user or stakeholder or customer…

Equifax has failed. Miserably. The company deserves all the class-action suits coming there way. From leaders to developers. Everyone.

Most members of society are unwilling participants in all this.  Most of us aren’t your direct customers.  Example: I’m not a direct customer of Equifax – nobody has chosen Equifax as their personal agent.  Instead, our banks and our governments have selected Equifax on our behalf.  This presents a problem: if I were a direct customer of Equifax I’d call them today and close my accounts; but I can’t do that.  Instead, the best I can do as an individual is contact my banks, lenders, and insurance agents to demand change.  (Yes, I likely will do that.  I’m that sort.)

However, the larger issue is that we are at the mercy of YOU who produce software.  I’m talking about the software in our vehicles, in our heart-monitors, in our subway systems, in our air-traffic-control centres, in our banks – this is serious stuff!  We must be able to trust those systems…with our lives, with our security.  We must be able to trust you even though we don’t and won’t ever know you.

A hacker friend of mine once said, “if self-driving cars are being produced without complete automated test coverage, then that’s a future I don’t want.”

In this day and age, low quality is intolerable.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Do You Want Love in Your (Work) Life?

Do you want love in your work life? Is it a possibility? Would love in your work life give you a happier step as you leave home each morning?

To be clear, romantic relationships with colleagues at your work place is not the topic. The love I’m proposing is love for your work, and loving affection from and for everyone you deal with in your workplace. So if your answer to the question is “yes,” then read on.

Personal History

I previously taught Theatre Arts and Drama at universities for over 20 years. I loved my subject. I loved watching students transform from insecure, self-conscious, wary creatures to confident, trusting and expressive actors. How did this happen?

In my approach to teaching, I made every effort to nurture students with care and affection, to create a safe and trusting space for them, to provide them with the best learning tools I could find to strengthen their capacities. I treated each one as an individual, trying to understand his or her particular needs. I truly cared that every student would advance.

My door was always open to them outside of classes. They could come to me with personal problems that ostensibly had nothing to do with their course work. I listened with empathy. I made sure that I was trustworthy in all my actions.

For example, I never asked anything of my students that I myself wasn’t willing to perform. I nudged them, sometimes gently, sometimes a bit aggressively (depending on their nature), to move outside their comfort zone. This often resulted in exhilarating experiences for the student.

In other words, I loved my students!

What Creates Safety?

When people are polled about which cultural attribute is most important to them in their workplaces, the highest percentage list “safety.” By safety, they usually mean things like “feeling safe to express my self;” “safe to have a difference of opinion;” “safe to sometimes fail without negative repercussions.”

If we look for the root of what helps us feel safe, I think we can trace it back to receiving human affection and loving care. This is what causes us to stay with a marriage partner over time. It creates lasting bonds with our children, family members, and long-time friends.

How often have you asked yourself the question: “Do I stay in this job that I intrinsically like, but have the urge to flee because its culture is unsafe and unloving?”

Imagine when you were a kid in school and had a favourite teacher. Who was s/he? Why was s/he your favourite? Was s/he especially kind or affectionate? Encouraging? Generous with her time? Think of the way s/he managed her class of several children.

Now think about a person in your workplace with whom you do not feel safe, and imagine that this person is actually like the teacher who was your favourite. How does that change how you feel about that colleague? How differently might you react to him/her?

Giving Love

It may sound flakey, but it has been proven that one of the ways to receive love is to give it. It can start with your thoughts toward a difficult manager or colleague. Reflect on this statement:

When a thought of war comes, oppose it by a stronger thought of peace. A thought of hatred must be destroyed by a more powerful thought of love. Thoughts of war bring destruction to all harmony, well-being, restfulness and content. Thoughts of love are constructive of brotherhood, peace, friendship and happiness.

http://www.bahai.org/library/authoritative-texts/abdul-baha/paris-talks

A wonderful article by Sigal Barsade and Olivia A.O’Neill in the Harvard Business Review discusses this subject of love in the workplace. Here’s a snippet from their article (which is worth reading in its entirety):

We conducted a follow-up study, surveying 3,201 employees in seven different industries from financial services to real estate and the results were the same. People who worked in a culture where they felt free to express affection, tenderness, caring, and compassion for one another were more satisfied with their jobs, committed to the organization, and accountable for their performance.

https://hbr.org/2014/01/employees-who-feel-love-perform-better

Love in the Business World?

I first encountered love as a conscious factor in the business world when I joined BERTEIG. Its founder, Mishkin, spoke often about the importance of expressing love in his training, consulting and coaching events. I found this fascinating, because my impression of big business was that of cool efficiency.

On the BERTEIG website, you can find this Vision Statement:

We co-create sustainable, high-performance organizations where continuous improvement is deeply embedded in the culture. We believe truthfulness is the foundation of improvement, and love is the strongest driver of change.

http://www.berteig.com/about-us/

For the past four years, I have seen the benefits of that vision of love being a strong driver of change in the BERTEIG team. Thus, despite being a very diverse group of people, we have a great deal of affection for each other. This affection enables us to grow, to continuously develop our capacities, and to offer our best. Clients who attend our training courses sometimes gush (yes, gush) about their trainer. Affection not only helps our own internal collaboration but our external as well. When we commit to a project/ job/ event, we follow through because we care.

And, too, one of the beautiful things about love is that it will radiate out to whomever we work with, and to whatever social spaces we participate in.

Now – You!

Do you want love in your work life? Do you believe love can be the strongest driver of change? If so, how can you action this in your own workplace?

Valerie Senyk is a Team Development Facilitator, Blogger, & Customer Service Rep at BERTEIG. You can learn about her Team Dev workshop at http://www.worldmindware.com/AgileTeamDevelopment


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Unpacking the Fifth Principle of the Agile Manifesto

The Agile Manifesto was signed and made public in 2001. It begins with short, pithy statements regarding what should be the priorities of software developers, followed by Twelve Principles. In this article I want to call attention to the fifth principle in the Agile Manifesto, which is:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

Although it appears to be a very simple statement, I suggest that it is jam-packed with profitable guidance, and is essential to, and at the heart of, real Agility. Human qualities must be considered.

Motivation

The first part of the principle urges us to build projects around motivated individuals.  What does this imply?

The idea of “building a project” makes it a process, not necessarily a fait accompli. It can change and be altered as one works toward it. There may be a structural roadmap, but many details and aspects can change in the “building.”

The second part of the statement describes motivated individuals. The verb “motivate” is an action word, meaning to actuate, propel, move or incite. Thus, in this line, is the “project” the thing which will “move or incite” those being asked to carry it out?

Or do we understand this to imply that the individuals are already “motivated” in themselves, which is an emotional condition of individuals? Is this motivation already there prior to starting a project?

The topic of motivation is rich. How does motivation occur? Is it the culture and environment of the company, lived and exemplified by it’s leaders, which motivates? Or is motivation an intrinsic quality of the individual? It may be both. (Daniel Pink, author of “Drive,” uses science to demonstrate that the best motivators are autonomy, mastery and purposeful-ness – ideas which are inherent in the Agile Manifesto.)

In any case, the line itself suggests that the project may be a) interesting to pertinent (perhaps already motivated) individuals, b) do-able by those same individuals, and c) contains enough challenges to test the mastery and creativity of the individuals. In other words, it’s going to be a project that the individuals in your company care about for more than one reason.

Environment

The second line from the fifth Principle has two distinct parts to it. The first part, “Give them the environment and support they need” puts a great deal of responsibility on whoever is assigning the project. Let’s look at the idea of environment first.

In a simple way, we can understand environment as the physical place which influences a person or a group. It can be any space or room; it can refer to the lighting, the colours, the furniture, the vegetation, the walls, whether water or coffee is available – physical elements which will certainly affect the actions of people and teams. For example, creating face-to-face collaboration environments is also part of the Agile Manifesto.

But we must remember that environment also entails the non-physical ie, the intellectual, emotional, or even the spiritual. Is the environment friendly or not? Cheerful or not? Encouraging or not? Affirming or not? We can think of many non-physical attributes that make up an environment.

Support

These attributes allude to the second part of what’s to be given by an owner or manager: “…and support they need.” This idea of support pertains not just to helping someone out with tools and responding to needs, but that the environment is supportive in every way – physically, intellectually, emotionally and spiritually. This may be a more holistic way of considering this Agile principle.

The last part of the statement is of great importance as well: and trust them to get the job done.

If you as product owner, or manager have created motivation, environment and support, then the last crucial requirement of trust becomes easier to fulfill. There is nothing more off-putting than being micromanaged, supervised or controlled with excessive attention to small details. Trust means you have confidence in the capacity of your team and its individual members. It also implies that they will communicate with transparency and honesty with you, and you with them, about the project.

Context

The principles of Agile do not exist in a vacuum, because, of course, other principles such as the following, are relevant to this discussion:

The best architectures, requirements, and designs emerge from self-organizing teams.”

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

This fifth principle has application far beyond IT projects. I wanted to reflect on it because it speaks to human qualities, which must be recognized as a key factor in happy work places, and in any high-performance team.

Valerie Senyk is a Customer Service agent and Agile Team Developer with BERTEIG.

For more information please go to http://www.worldmindware.com/AgileTeamDevelopmentWorkshopStage1

Also read about BERTEIG’s RealAgility Program: http://www.berteig.com/real-agility-enterprise-agility/


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Importance of Emotional Intelligence in the Agile and Corporate World

Emotional intelligence (EQ) is a topic that has not been fully addressed on this site, nor in the agile or corporate world, yet it has great ramifications for anyone choosing or hoping to practice Agile and/ or Scrum.

I obliquely touch on it in my article: The Soft Skills Revolution: Why You May Want Team Development and I think I can safely equate most “soft skills” with “emotional intelligence.”

My purpose is not to connect the dots for anyone, but simply to introduce the idea. If you go to the site below and read the materials and watch the videos, you may understand for yourself the importance of emotional intelligence in all that you are endeavouring to do. Thanks to John Hawthorne for pointing this out to me – enjoy.

https://www.cornerstone.edu/blogs/lifelong-learning-matters/post/are-you-emotionally-intelligent-heres-how-to-tell


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Kanban: Real Scaled Agility for Your Enterprise

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…


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail