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?
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.
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:
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:
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.
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.
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.
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:
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.
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.
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.
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.
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:
New artifacts: +5
Repetitive activities: -2
Quality problems: 0
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.
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:
New artifacts: +5
Repetitive activities: 0
Quality problems: +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.
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:
New artifacts: +3
Repetitive activities: +5
Quality problems: +3
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:
New artifacts: +4
Repetitive activities: +4
Quality problems: +4
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.
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.
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:
Automated testing is cheaper and exponentially more effective than manual testing;
ALL defects are discoverable and fixable before hitting production environments;
Quality is not something one outsources
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.”
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.”
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.
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.
The second line from the fifth Principlehas 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 elementswhich 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.
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.
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.
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):
Understand the purpose of the system—explicitly identify the services you provide, to whom you provide them and why;
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;
Define the sources of demand—what your customers care about and why;
Describe the capability of your system to satisfy these demands;
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;
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;
With all of the above as an input, design the Kanban system for the service;
Learn how to do steps 2-7 and start applying it directly to your own context in a Kanban System Design class;
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.
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…
In a recent scan of the e-literature on the reciprocal impact of Agile on HR, I connected some very interesting insights which I’d like to share. A set of insights that looks like ripples across the surface of a pond. Ripples that started when the Agile stone was thrown into the pond in 2001. In its simplest form, Agile is about a different way of working with each other in teams. Teams that are cross-functional, collaborative, co-located and customer-driven in their decision making. The insights provide compelling reasons why HR needs to take an active role in Agile implementations.
“In the most successful Agile transformations, HR is a driver of the change and a key hub that steers other departments’ success.”
HR certainly needs to be ‘a’ driver in the change, but not ‘the’ (sole) driver. Rather they need to partner in the change. Successful Agile transformations will benefit from HR’s expertise in
Learning & Development
Workforce Planning & Talent Management
The driver of the change, historically IT, will need HR’s help to manage the impact to people and traditional HR processes/tools. As the change scales and starts to impact other departments in the business, HR can play a large role in ensuring the business overall stays aligned in delivering end-to-end value to customers.
“2016 will be the year of Agile HR… most HR teams have no clue what Agile HR means.”
(HR Trend Institute)
Agile was a hot topic for HR in 2016 as evidenced by the number of times ‘Agile HR’ has made the shortlist of topics being brainstormed for HR conferences and networks. It was the #1 trend on the 2016 HR Trend Institute list. Its popularity is not cooling off in 2017. And yet most HR teams still don’t have a clue what ‘Agile’ means, never mind what ‘Agile HR’ means.
“As the world becomes more volatile, organizations need to find ways to become highly agile. HR will need to support a world where people may no longer have predefined ‘jobs’ that lock them into doing one activity.”
Agile has entered the mainstream. A necessity given the VUCA world we live in. Agile is no longer the sole domain of IT. The common refrain from all C-suite leaders these days is increased agility and nimbleness across the entire business – not just IT. The impact of capital ‘A’ Agile or small ‘a’ agile will affect HR. People will no longer have predefined jobs – People’s career paths will change. In this VUCA world, standardized career paths are no longer effective. Batch-of-one career paths will become the norm.
“HR’s job is not just to implement controls and standards, and drive execution—but rather to facilitate and improve organizational agility.”
The HR profession itself has been going through its own transformation. The HR profession has evolved from an administrative and transactional service to a strategic business stakeholder with a seat at the executive table. The role of HR now includes a focus on organization-wide agility and global optimization of departmental efforts.
“Human capital issues are the #1 challenge for CEOs globally.”
(The Conference Board CEO Challenge 2016)
The Conference Board’s 2016 survey of global CEOs ranked human capital issues as the number one challenge. It has been number one for the last four years in a row. Within that challenge, there are two hot-button issues:
Attracting and retaining top talent
Developing next-generation leaders
The adoption of agile ways of working will change
How we recruit and engage
How we nurture and grow not only our leaders but our talent in general
In the words of Robert Ployhart, “…employees don’t just implement the strategy – they are the strategy”. CEOs around the world would tend to agree.
The net of these insights is the more HR professionals understand Agile and its implications, the more effective Agile or agile initiatives and people/strategy will be.
I’d like to see HR ride the wave.
 VUCA is an acronym introduced by the US military to describe a state of increased Volatility, Uncertainty, Complexity and Ambiguity
 Ulrich, Dave, William A. Schiemann, Libby Sartain, Amy Schabacker Dufain, and Jorge Jauregui Morales. “The Reluctant HR Champion?” The Rise of HR: Wisdom from 73 Thought Leaders. Alexandria, VA: HR Certification Institute, 2015. N. pag. Print.
“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”
It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.
“Companies are running 21st century businesses with 20th century workplace practices & programs”
– Willis Towers Watson
It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:
“Can we team interview the candidate for attitude and fit?”
“I was an IT Development Manager. What’s my role now?”
“My manager doesn’t see half of what I do for my team. How can she possibly evaluate me?”
“With no opportunity for promotions in sight, how can I advance my career?”
“Why do we recognize individuals when we’re supposed to be focused on team success?”
“Charlie’s not working out. Can we as the team fire him?”
As the volume increases, how will HR and HR professionals respond?
“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”
– HR Trend Institute
The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.
There are three significant change movements gaining momentum:
Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
Reinventing HR – where HR is moving beyond its historical focus on basic people administration, compliance and transactions to a valued place at the executive table; ensuring context and alignment across the business to generate Customer delight.
Reinventing organizations – as the level of human and organizational consciousness evolves from valuing meritocracy, accountability and innovation to valuing self-management, wholeness and evolutionary purpose. (See “Reinventing Organizations” by Frederic Laloux: http://www.reinventingorganizations.com/)
All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.
An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.
“How do we get HR started towards their destiny?”
If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.
If you’re an HR professional, here are some suggestions:
Learn about Agile
Visit with your Agile teams during sprint reviews or daily scrums
Talk to your friends and colleagues about their Agile experiences and challenges
Review in-progress HR process & tool changes through an Agile lens
Partner with IT and other Agile implementation stakeholders to guide the success of Agile
To help HR take the first step, here are some suggested Agile learning resources:
I dutifully watch Scrum Alliance’s webinars whenever they offer something I want to learn about, so I recently attended Michael Sahota’s “Top Ten Secrets of Agile Transformation.”
Sahota is a bit of an Agile guru, and well-respected in the community. He founded the Toronto Agile Community, and can be seen at Scrum Alliance gatherings everywhere. He also facilitates a Certified Agile Leadership course. You can learn more about Sahota by going to his website www.agilitrix.com.
The webinar he conducted was fascinating, because by the time he went from #1 to #10, I realized his “secrets” were very simple, and that one could start with #10 and work backwards to #1 and learn the same things.
By simple I mean his points were clearly articulated and comprehensive.
Before enunciating his secrets Sahota started with the idea that “Culture is the #1 Challenge with Agile.” He asked, “What are we (agilists) doing to create resistance to a change of culture in an organization?” Mindset, he averred, is more important than the practice of Agile – by which he referenced creating safe and trusting relationships, engaging with others, promoting continuous learning, innovation and so on. On a continuum line with “practices” on one end and “mindset/culture” on the other, he urged practitioners to find a balance between the two.
And now for the count-up:
Secret #1 – Clarify the purpose of bringing in an Agile coach by asking “why?” Usually the answers have to do with improving the quality of a product and encouraging more collaboration.
Secret #2 – Focus on organizational goals (and drop the word “Agile”). If the goals are clear, as those articulated above, one can drop the Agile initiative and try another. Agile is not the goal, but focussing on doing and being Agile can set up the wrong expectations. You may say, “Of course we will likely use Agile to help us achieve the organization’s goals,” but remember that Agile cannot be the goal!
Secret #3 – Focus on growth (and drop “transformation”). The idea of transformation is that it is a painful process. It also implies an end point: one is transformed. The idea of growth is more natural, and transformation is really about creating healthy change and growth. It is ongoing.
Secret #4 – Increase awareness of the global context. Global trends mean that an organization must be growing to survive. A lot of organizations do not know how to read their engagement surveys, or don’t even have them. People’s talents are wasted when engagement is low, which leads to massive financial waste. Millennials demand change – will not seek to work in an organization that’s regressive or stagnant. An agile enterprise is resilient and anti-fragile. How well is an organization set up to thrive in the future?
Secret #5 – Increase awareness of organizational context – what’s happening in an organization? However, resist telling leaders that their organization is broken. Start with humility and compassion, and then show leaders that there is a lack of engagement by their members by reading the survey. It’s not about blame – have the leaders acknowledge this and say what they want to do about it. What difficult conversations are needed here? The coach must stand in the truth of what’s happening, listen and understand. Be real.
Secret #6 – Clarify the focus of the initiative. Is more time spent on tactical initiatives (as in, how do we work?), in strategic initiatives (what do we want to achieve?), or in cultural concerns (who do we want to be?)? Discuss what percentage of time is needed to spend on culture in order to have a bright future.
Secret #7 – Build a shared understanding of what culture is. Culture has to do with both consciousness (or energetic property) and structures. Consciousness includes identity, values, beliefs, and the unwritten rules and norms in an organization. It includes values such as safety, trust, people being valued… Structure (practices) and consciousness (culture) co-exist together and are inter-dependent. Refer to the Agile Manifesto: people over process. – focus on structures without consciousness cannot succeed.
Secret #8 – Clarify the leaders’ role in growing. The consciousness of the leadership is most important. New organizational behavior requires new leadership behavior. Growth requires leaders go first! How do we invite them to go first?
Secret #9 – Honour the leaders’ freedom to choose. Do they wish to work on something tactical? Cultural? A coach must let go of what he or she wants. We cannot coerce people into believing what we believe.
Secret #10 – Growth can happen anywhere.You, as an individual, are the limit for growth.
Sahota suggests creating a culture-bubble in which consciousness and safety can be grown. In this last point he quotes Gandhi: “Be the change that you want to see in the world.”
I am aware that in the 45 minutes of the webinar, Sahota went through each point relatively quickly. Each one in itself provides room for reflection. For me, the fact that the tenth “secret” puts the onus on each individual to grow is telling; if we change, we can help those around us in their transformation. But that requires extra-consciousness, I think, and humility. Overall, Sahota points to values and culture within and without as the key.
I facilitated this workshop today for a senior leadership team. I mostly employ famous quotations familiar to many to provide a brief overview of Servant Leadership as well as a learning framework for systematically building capacity in others while improving the systems in which they work. The folks in the workshop seemed to really connect with Scott’s CLEAR model (not so famous but ingenious in its deceptive simplicity). I offer it as a guide for designing CLEAR acts of leadership.
Nearly everyone is hanging out the “Agile Coach” shingle. Agile has reached the point where many large organizations are adopting Agile practices. As a result, consultants and consulting companies are trying to jump on the bandwagon to take advantage of this fad. Unfortunately, we at BERTEIG are often being called in to clean up after other Agile coaches have made a mess of things.
Here are the most common mistakes that organizations make when hiring Agile coaches.
1. Not Measuring the Results of Your Agile Coach
Agile coaches should be able to measure their results as they work with your teams and your organization. Important measures include performance, cost, quality, time to market, customer satisfaction and others. If you aren’t measuring results, you can’t possibly know if the money you are investing into your Agile coach is worth it. Of course, some qualitative measures such as staff satisfaction with the coach are useful too, but quantitative measures are also essential.
2. Not Benchmarking before an Agile Coach Starts
You need to be able to know if an agile coach is making a difference. Knowing where you are starting is necessary. Having benchmark measurements of important KPI’s will help you to make sure that your agile coach is successful. Benchmarking is something that your agile coach should be able to help you with, but make sure that you are involved directly!
3. The Agile Coach is Lacking Advanced Certifications
Agile coaches need to have proven their knowledge and experience by obtaining advanced certifications. A “Certified Scrum Master” designation is just not sufficient. At a bare minimum a Certified Scrum Professional (CSP) or Kanban Management Professional (KMP) certification are critical. However more advanced certification’s such as Certified Enterprise Coach (CEC), Kanban Coaching Professional (KCP), or even non-Agile coaching certifications such as Leadership Circle Profile are important to see in a candidate.
4. Lack of Diversity of Agile Experience
An Agile coach must be able to prove having worked with at least Scrum and Kanban methods on more than one team in more than one organization. However, there are many other Agile methods and techniques, and it is critical to explore the depth of your candidate’s knowledge and experience with those techniques. Do they know how to do the Agile engineering practices? Have they used many different retrospective techniques? What about Innovation Games? Estimation and planning tools? If your coach has less than five years of experience with Agile techniques, chances are they don’t have the depth to deal with the complexity of your situation.
5. No Huge Agile Coaching Failures
An Agile coach needs to be able to explain how they have failed to achieve results in at least one case, ideally getting fired as a result. Failure and learning from failure are critical parts of the Agile framework. If an Agile coach can not share with you a significant failure then you cannot trust that they are able to learn from their mistakes.
6. No Systematic Agile Coaching Approach
Helping teams, groups and organizations become more Agile requires systems thinking and systematic approaches. Organizations are complex (and sometimes chaotic!) – if an Agile Coach does not know how to deal with this complexity, and cannot describe to you their systematic approach, then they probably aren’t going to be consistent in their results. And if the approach they describe doesn’t seem to make sense to you, you are probably right to give that coach a pass.
7. Missing Clear Agile Coaching Goals
This mistake is a little less common, but it is important enough that it still needs to be mentioned: your organization absolutely must have clear goals for the Agile coaching. Those goals should be related to both Agility and business results. Agile techniques are a means to an end. Lacking clear goals often results in an organization spending far more than it needs to on Agile coaching.
8. Hiring an Agile Coach to do Training
(Or the other way around.) Coaching and training are two completely separate disciplines! It is rare to find an individual who is able to do both well. The systems and techniques of coaching are different than those of training. Becoming excellent at one, takes many years of focused work. Becoming excellent at both, takes deep commitment and opportunity. If you hire an Agile Coach who has good experience, don’t just assume that they can do training just because they have delivered a few talks or made up a slide deck. Put the same discipline into hiring an Agile trainer that you would put into hiring an Agile coach.
9. Not Letting Leaders and the Agile Coach Work Together
This is probably one of the biggest mistakes of all! An Agile coach must work with your organization’s leaders to have any hope of helping you with lasting change. No matter how large your organization, the culture is set by leadership, Agile has a huge cultural impact, and your Agile coach needs to be able to link the two together (leaders and Agile culture). Even if the Agile coach is “just” working at the team level, a lack of contact with leaders will make the coaching work inefficient, frustrating, and unsustainable.
Your organization deserves the best chance it can have. Consider contacting us at BERTEIG to help you make sure your Agile coach (or Agile coach candidate) is up to the challenge. We have a systematic program to develop Agile coaches.
“Sometimes we get so caught up in what should be that we miss the beauty of what is.” – Doc Norton
At the 8th Annual Agile Conference, held in Toronto, Ontario last week, the keynote speaker Doc Norton presented some insightful ideas on Host Leadership, about the roles people take when initiating, launching and facilitating new ideas. The basic premise of having a Host Leader mindset is to be fluid with the needs of the environment. While there is a time and place for authoritative decision-making, otherwise called gate-keeping in Host Leadership lingo, there is also a need for a humble approach to supporting an idea from conception to fruition without clinging to hard-and-fast expectations about what must happen.
In his example of applying these principles, he shared how his family decided to host a Euchre game to create an opportunity to meet new neighbours. When something different than expected emerged, he experienced the value detaching from “what he wanted it to be” and accepting “what was becoming.”
In brief, here are the 6 key aspects of Host Leadership.
Initiator – The person that provides the initial spark. A new idea.
Inviter – Extends the invitation to people who may be interested in the idea. Who to invite and who not to invite.
Space Creator – Those who create the physical and emotional space for those in attendance to feel safe, to learn, and to engage in the opportunity.
Gate Keeper – Defines and protects the space which is created. Lets people in and out as necessary or appropriate. People who enforce the rules, doing interviews and hiring. Note: there is a right balance for this where there is not too much gate-keeping but just enough to create the right boundaries.
Connector – Brings people together. They are conduits for information. They are typically the ones who know how things get done.
Co-participator – Team leads participating in a retrospective as equals.
Sometimes the Host Leader sets and reinforces rules, but sometimes they serve others. This depends on the moment and context.
Doc Norton laughed at his own story when he revealed that even though he and his wife put lengthy effort into creating “Euchre Night” he discovered that in the basement a large group of guests started playing poker. Rather than becoming disgruntled about the change, he adapted and became a co-participator. As a result of letting what was becoming just be, the neighbours found themselves carrying out Poker nights monthly for a decade.
Host Leadership is about creating space for great things to emerge and surrendering the inclination to control the outcome.
These six items are aspects of roles of everyone on a team and shouldn’t be thought of as one person per role per team. Instead, when people on a team ebb and flow around these roles the thought-processes and discoveries can be shared with the team, and the growth on the team supports the initiatives for team members.
What were his concluding words of wisdom to the audience?
He said, “Consider your leadership role at work. Regardless of your title, think about what you are initiating. How do you extend invitations? What space are you creating and maintaining? When are you gate-keeping? How are you connecting with others? How are you joining what is emerging even if it is different than what you expected?”
The take away from this inspiring opening address was the optimistic message that what is becoming may be better than anything anyone could have hoped for.