I recently had a scheduled call with a client that was aimed to level-set expectations around some upcoming Agile Consultation work that I’d booked. The work was specifically to help them visualize and build their workflow. I had my Sales Engineer come with me, as we both had the suspicion that the client had also bought a tool on the promise it would help them become more Agile.
Becoming “Agile” is not about a tool, just like visualizing and building workflow isn’t about setting up a Kanban Board. Being “Agile” is about the people and their interactions.
I’ve seen this a number of times, where a client seeks a tool to become “more Agile”. Usually a Director or higher executive, spends money on training some or all of their staff, more often opting out of the training themselves. After a short period of time, they realize that the promise of better results isn’t looking promising. So they then seek additional funding, and invest in a tool with the promise that “this” will help their teams become “more Agile”.
It became quite clear that this was the case with this client, as their original request “to help our people become more agile”, suddenly changed to “help us use this tool”. As most people in this field understand, the first Value of the Agile Manifesto is to value “Individuals and Interactions Over Processes and Tools”.
I have that Value deeply embedded in my mind, as I’d had the fortune to work directly with two of the original twelve signatories of the Manifesto, and we often talked about the genesis of the Values. The creators of the Manifesto were people who had lived the mindset that this client presently maintains. Through similar experiences as my client, the Signatories began to foresee the pitfalls of the old mindset, and simply sought a better approach to become more agile.
So this particular client has the hallmark of having the old mindset. With great care, the Sales Engineer and I were able to demonstrate that the tool can support the interactions of their teams as they incrementally develop their products. And we would be happy to use the consulting dollars to look at their teams, leverage the training they already had, help visualize their workflow and ultimately help them understand that Agility comes from developing the Agile mindset.
By the end of the call, two of the three team members fully understood that they were perhaps going down the wrong road by placing the value of the tool over their people and the interactions of their teams. In this specific case, the third person had arrived to the meeting late, was the most senior person in the room, and in my belief, had missed information that might have also changed their perspective. It is impossible to know, but I strongly suspect that none of the three were in a political position to change course. Whether they had directly invested in the tool or not, is immaterial.
The agreement is now on hold, and that is probably the best thing for our client-vendor relationship in the long-term. We could have provided training on the tool and taken their money, but that would be unethical. As an Agile consultant-salesperson, and all of us here at Berteig, we deeply understand the nuances of the Manifesto, and as such, we need to sell and deliver what is right for the client.
For now, the personal and financial investment they made with respects to the tool will need to be seen through. Which I respect, for all the business, political and personal reasons. There is a high likelihood that their original request will resurface in a number of months. Obtaining “agility” is a journey and often takes such time.
Most leaders I work with have a common frustration they express to me: an inability to achieve significant gains in how quick and predictable they are in delivering work to their customers.
In my work as a consultant, coach, and trainer, there is one strategy that I help them discover that results in dramatic change to their thinking and how they view work and workers within their organization. So what is the strategy?
Flow Efficiency
Work items (ie: user stories, features, epics), or whatever artifacts represent customer recognizable value within your context, can spend their lifespan alternating between two states: active and waiting. Work is active when we are currently engaged in adding value to a work item – it has our attention and we are actively working on it. Work is in a waiting state when it has been started, but is then interrupted (for a variety of reasons) to address something else. The active time in relation to the total lifetime of a work item is a construct known as Flow Efficiency. An understanding of this relation can have serious implications on how you view your work and the decisions you make.
It’s expressed as a percentage using the following formula: (Active Time / Total Time) * 100
Here is an example. A user story has taken 26 hours to complete (from start to finish). Out of that 26 hours, only 2 hours where actually spent working on the item and 24 hours of the total was in a wait state. That is a flow efficiency of 7.7%.
( 2 / 26 ) * 100 = 7.7
You may be surprised – as are many of my clients and students – to discover that in knowledge work (ie: Software Development) a typical flow efficiency is measured at 4-8%! In fact, 40%+ would be VERY good.
Think about that!
This means that work items spend their existence primarily in a waiting state. Even though we have started to work on something, 92-96% of the time we are not adding value to the work item! There are numerous reasons as to why work items are placed in a waiting state: task-switching, queues, blockers, internal/external dependencies, etc… (Remember: If you are working on more than one item, every time you put aside one item to work on another, that item effectively goes into a wait state.)
So what are the implications of a low flow efficiency system and how might it change how we work and the decisions we make?
Implication #1: How busy people are is largely irrelevant.
20th century management techniques have engrained in us an obsession with the high-utilization of people. Everyone must be busy working on as many work items as they can.
This stems from a desire within us to measure what we can see, and unless we are in a manufacturing environment, what we can see are usually people! In knowledge work we can’t see the work going on – it is for the most part invisible. It happens inside people’s heads. Yet managers consume themselves with ensuring that people are busy in the hopes that this will churn out more work in less time. And even if it doesn’t, at least they can claim they were getting the most out of their people!
In a low flow efficiency environment high-utilization of people is not the path to greater speed and predictability. The fact of the matter is that if work spends the majority of it’s time in a waiting state, then it really does not matter how busy people are – to the contrary. More work for individuals in a low efficiency environment only contributes to a degrading flow efficiency – particularly because of task-switching.
Customers are not paying for key strokes. They don’t care how busy your workers are. They care about speedy delivery, reliability, and quality. Idle work, not idle people should be the centre of your attention. Your customer’s needs will be more positively impacted by focusing on the flow of work (and removing delay within that flow), not the utilization of people.
Implication #2: The performance of people is largely irrelevant.
In an effort to increase the speed and amount of work that teams deliver, the response from most managers is to hire more people and/or make people work faster and harder. The majority of my coaching engagements usually begin with a manager meeting with me and pleading for help to “please go make my teams faster”! Thus begins the process of me helping them understand that if they are in a low flow efficiency environment (they usually are) focusing on improving the performance of individuals (or hiring more of them) is not really going to have much of an impact in addressing their pain points. Why?
Imagine this frustrated manager has an environment where flow efficiency is 6%. So 94% of the time work is in a wait state, and only 6% of the time is value actually being added to work. If we choose to focus on optimizing the performance of the 6% of active work, any improvements are going to be very marginal on the overall increase in delivery time of work over its entire lifespan – we are only addressing 6% of the total!
Let’s suppose that out of that 6%, that 2% of that time is development work. Even if you make your development team 10 times faster, or double the size of your development team, you are going to have very little impact on the whole.
The opportunities for improvement that are really going to shift the needle in delivery times and predictability are in tackling the 94% of delay that exists in the flow of work. In such an environment we need to help managers move away from managing and measuring people, and instead managing and measuring the flow of work.
Implication #3: Your estimates are doomed.
Most organizations are horrible at estimating. There are numerous reasons for this, but a key contributor to why our estimates are so unreliable is that when we estimate we are producing “effort” estimates. We are estimating the amount of effort we think it will take to complete a work item, and when we do this we are estimating the 4-8% of active value-adding-work-time we anticipate to incur. But we are NOT estimating the amount of wait time that our work item is going to spend in its lifespan. That’s 92-96% of the lifespan of a work item that we are not taking into consideration. No wonder we are so far off in our estimates. We can try and game the system by adding buffers to our estimates, but alas this tactic is often futile and detrimental to developing predictability.
Implication #4: Focusing on team performance is not the path to business agility.
It has been my experience, that in most organizations of more than 50 people, the notion of self-organizing cross-functional teams is a fantasy. Time and time again, when I look at how work flows through an organization, it rarely exists within the boundary of one team and independent of any other teams. What I more commonly witness are cross-functional silo’d teams that have dependencies between each other.
Even more detrimental to the delivery times and predictability of our work is the delay that exists between teams. If work is flowing through more than one team (it usually is) and that work is not arriving to the right-team-at-the-right-time then delay is going to be introduced – and with delay we have negative impact to our flow efficiency.
It won’t matter how optimized individual teams are if the flow of work amongst them is not managed to create smooth flow. Business agility is not achieved by how many high-performing teams you have, but rather, how well you manage the interactions amongst teams.
“The performance of a system is not the sum of its parts. It’s the PRODUCT of its INTERACTIONS.” – Dr. Russell Ackoff.
Let’s Do Something About It
Now that we are aware of some of the implications of a low flow efficiency, what practical and actionable guidance should we consider in order to improve our service delivery and deliver value to our customers when they need it? How can we do this in a way that favours managing and measuring work OVER managing and measuring people?
Visualize work: Knowledge work and professional services are domains in which the work we do is largely invisible. We need to find a way to make this work visible so that we have something tactile that we can have conversations about. We need to see how-our-work-works!
Limit the amount of work in progress: If we are to catalyze improvements in how we work and develop a sustainable pace, we need to start limiting the amount of work we commit to at once. Predictability in our delivery is not possible unless we limit the amount of work in progress.
Manage the Flow of Work: As we have discussed in this article, we need to focus our efforts on identifying those things that hinder the flow of work. We need to shift our attention from the utilization of people towards the management of work and how it flows.
Make Policies Explicit: Whenever we discover flow impediments we should strive to resolve them. Part of the resolution should include updating the policies of how work flows through our system and making them visible. Evolving our policies and making them explicit is a cornerstone to continuous improvement.
Implement Feedback Loops: Business agility and continuous improvement are rooted in a desire to quickly learn and respond to feedback. We need to establish mechanisms where we can collect and evaluate feedback so that we can maintain or correct our course. These mechanisms should foster an ability to gather meaningful feedback that we can act on.
Collaborate and Experiment: An agreement to pursue evolutionary improvement by encouraging acts of leadership and collaboration at all levels of an organization are necessary if we aspire to a culture where change can flourish through experimentation founded on the scientific method. Our approach needs to move towards a non-deterministic probabilistic way of thinking, and away from a speculative and wishful mindset.
Helping organizations develop an understanding of the implications of poor flow efficiency and then using these practices to help overcome that challenge is a strategy that has proven very effective for myself and my clients. My premium management training classes provide in-depth practical guidance on how to apply these techniques.
Conclusion
I’m not suggesting that an obsession with accurately tracking flow efficiency will be time well spent, in-fact, even if you wanted to, it can be quite difficult to do without electronic tools. However, even an approximate understanding of your flow efficiency, or being on the lookout for interruptions of flow (blocked items, items aging in queues, dependencies, etc..), and focusing on developing smooth-fast-flow, can have tremendous benefits to your ambition of delivering more quickly and more reliably to your customers.
Focus on eliminating wait times of your work items! Strive for flow that is smooth and fast! Spend more time managing and measuring work, less on managing and measuring people.
If you are interested in learning more about each of these practices and how to apply them in your place of work, consider signing up for one of my premium management training workshops. I offer three LeanKanban University accredited management classes:
It appears to me there are more jobs available for Scrum Masters than ever before! Why is it so hard for some people to find employment with Agile teams?
The problem is entirely predictable. And for those eager to work in Scrum teams, the answer is also predictable. I’ll explain.
Having taught Scrum to more than 2000 people, I have ongoing dialogue with many former students who are struggling to find opportunities to serve Agile teams and gain experience as a Scrum Master. I have struggled to understand this dilemma because my experience was very different – I learned of Scrum in 2007 and simply asked my workmates:
“Would you like to try Scrum…I could be our Scrum Master?”
Unanimous reply: “Yes!”
That is not the common experience. Many organizations are willing to send their staff to Scrum training for the sake of ‘Professional Development’ but only some of those organizations intend to develop Agile teams. That pattern has created the current condition in which many recently-trained Scrum Masters are eager to apply their new knowledge but do not have organizational support to do so.
I opened my inbox today to a question from a former student of my Scrum class. Let’s call her Jane:
“Hi David, I wanted to get your advice on a dilemma I have. I’m back on the job market and several companies are looking for Scrum Masters which is great to see. I was in your CSM course last year and would love to work with a Scrum team…but I didn’t have the opportunity with my former employer. How can I gain experience if all the available jobs require 2+ years experience? What advice do you have for me?”
Jane is not alone. The job market (today at LinkedIn) offers 591 positions in Canada for keyword ‘Scrum Master’ – and all that I’ve scanned require 1 or more years’ experience in the role.
In contrast to the dilemma described above, I have a totally different problem: I am contacted a few times per month by recruiters and hiring managers who ask me if I’m looking for a new contract.
Where’s the welcome mat for newcomers? Do jobs exist for enthusiasts with no prior experience?
I believe so.
The dynamics we’re observing in the job market for Scrum Masters are well described by Everett Rogers in his paper called “Diffusion of Innovations” (1995). You may recognize his theory by the following bell curve:
I assert that Scrum has achieved “Early Majority” market penetration. And you might be asking what evidence I have to support that claim – of course, other than the fact that opportunity knocks frequently at my door but never at Jane’s. I’ll describe the patterns I’ve observed in the market.
The authors of Scrum (Ken & Jeff, and others) were the Innovators. When I first took on the role of Scrum Master (2007), knowledge of Scrum was limited to a few enthusiasts and early adopters. Worldwide, a few thousand had learned of Scrum; in Canada, perhaps a hundred or so. None of my friends or workmates had prior knowledge of Scrum; there were no job advertisements for Scrum Masters; there were no public training classes; many of the well-known books on the subject had not yet been written; and there was exactly one Certified Scrum Trainer in Canada: my colleague, Mishkin Berteig.
By 2012, awareness of Scrum was spreading. It was a buzzword among start-ups and software development firms and a few brave souls were socializing the practice in large enterprises. Despite the increasing awareness, the number of people who had served as Scrum Master in a proper Scrum team was, I’d estimate, less than 100 in Canada. Yet, anyone with “Scrum” on their resume was considered rare and hiring managers among the early minority adopters were eager to snap them up. A swell of “Agile Coach” contractors was starting to emerge and anyone willing to hang that shingle was considered an expert. I’d argue their enthusiasm often out-weighed expertise but it was a new frontier after all and sheer enthusiasm counted for a lot.
By 2014, I noticed 2 patterns emerge. First, young tech companies in Canada (the ‘early early adopters’) were no longer hiring Scrum Masters. They considered Scrum expertise (or willingness) an obvious requirement of all new hires – like table-stakes. Second, large enterprises were starting to post job advertisements for Scrum Masters. These two patterns infer that the ‘late early adopters’ were onboard.
By 2016, evidence of ‘early majority’ adoption was mounting. I received frequent requests to speak at hospitals, marketing agencies, industry events, ‘Leadership’ seminars. Our federal Government departments started recruiting, not only Scrum Masters, but Product Owners too. Small armies of young MBA grads were being sent by their big consulting firms to my Scrum classes to “get certified”.
So, in 2018… Jane is certainly asking “what does it mean for me?” Well, it means there’s more opportunity than ever before. That is certainly true and awareness and demand for Scrum continues to grow. It also means I see a vast landscape of opportunities, but Jane sees closed doors – unfortunately for her.
There’s good news in this story for Jane… I promise!
Let’s think about the mindset common among the ‘early majority’ adopters. They are risk-averse, but not so much that they ignore market opportunities. They live by a simple rule: “the 2nd mouse gets the cheese.” They watch the early adopters carefully hoping to spot advantageous patterns. (Scrum is one of those.) And when they see a trend, they don’t pounce on it immediately – remember, they’re pragmatic. They will want to hire Scrum Masters, but they’ll be careful about it: perhaps they’ll hire contractors rather than commit to full-time/permanent roles; perhaps they’ll require 5+ years’ experience hoping to acquire one of the early adopters who helped prove the efficacy of the new method; perhaps they’ll train internally hoping to gradually adjust and minimize disruption. They’ll be reluctant to “take a chance” on a new hire without proven experience.
Those pragmatic habits of the early majority adopters make it difficult for them to hire Jane.
5 to 10 years from now, Jane’s job search may get a lot easier. Why? Let’s think about the mindset common among the ‘late majority’ adopters. They are risk-averse – to the point they ignore new trends and look instead for so-called “best practices”. These organizations are doubling-down on Waterfall right now and sending their staff to PMP exam-prep courses. They still think Scrum is a buzzword. But they’ve taken note when Brian Porter, the CEO of Scotiabank said publicly, “we’re in the technology business. Our product happens to be banking.” They’ve felt some shock when Alex Benay, CIO of Government of Canada talks about agile procurement and relentless incrementalism. They will start hiring Scrum Masters when they’re shown evidence that Scrum is teachable, repeatable, reliable, and so-called “normal”. They will believe (and trust deeply) that the community has developed well-established and standard methods which can be taught and learned systematically. They’ll find the senior practitioners too expensive; and they’ll look to less experienced practitioners, like Jane, as a bargain. They’ll be less concerned about in-the-trenches experience and more interested in industry norms.
Those risk-averse habits of ‘late majority’ adopters will make it easy for Jane to find employment – unfortunately though, the salary range is likely to be average at best.
(Let’s not discuss the Laggards today – they’re just funny. They’re the reason your office still has a fax machine and your car still has a cigarette lighter.)
Jane! I promised good news. Here it is…
Even at this stage of ‘early majority’ adoption, you’ll find some people who are on the edge of innovation. Look for those enthusiasts and visionaries! You’ll not find them easily in the big employers (banks, telecoms, etc.) You’ll find such people in start-ups, small tech firms, product companies. Those organizations are not looking for the stodgy corporate mindset – they’re eager to find other enthusiasts and they’re willing to take a chance. They’re more interested to forge new paths than to follow others – so they’re excited by Jane’s willingness to forge her own new path and they’ll want to help her!
So, what if Jane herself is not ready for that level of risk? Well, on one hand I feel every Scrum Master must develop high risk-tolerance. But I understand not everyone starts there. Jane might seek the sense of job security and stability common in large enterprises. In that condition, my advice to Jane would be: consider taking a job as not a Scrum Master but as a team member. If you’re a Project Manager or Developer, or Business Analyst in the past, hunt for those opportunities then look for ways to transition into a new role. That is, after all, the type of pragmatism the enterprises (early majority) appreciate.
Happy job hunting!
*** Thanks to Massimo for the conversation we had on the train yesterday.
Thanks to Brian.
Thanks for Valerie who reviewed and helped improve the article.
This article is adapted from a session proposal to Toronto Agile Conference 2018.
Leadership occurs as conscious choice carried out as actions.
Everyone has the ability to carry out acts leadership. Therefore, everyone is a potential leader.
For leadership to be appropriate and effective, acts of leadership need to be tuned to the receptivity of those whose behaviour the aspiring leader seeks to influence. Tuning leadership requires the ability to perceive and discern meaningful signals from people and, more importantly, the system and environment in which they work.
As leaders, the choices we make and the actions we carry out are organic with our environment. That is, leaders are influenced by their environments (often in ways that are not easily perceived), and on the other hand influence their environments in ways that can have a powerful impact on business performance, organizational structures and the well-being of people. Leaders who are conscious of this bidirectional dynamic can greatly improve their ability to sense and respond to the needs of their customers, their organizations and the people with whom they interact in their work. The following list is one way of describing the set of capabilities that such leaders can develop over time.
Create Identity: Real leaders understand that identity rules. They work with the reality that “Who?” comes first (“Who are we?”), then “Why?” (“Why do we do what we do?”).
Focus on Customers: Real leaders help everyone in their organization focus on understanding and fulfilling the needs of customers. This is, ultimately, how “Why?” is answered.
Cultivate a Service Orientation: Real leaders design and evolve transparent systems for serving the needs of customers. A leader’s effectiveness in this dimension can be gauged both by the degree of customer satisfaction with deliverables and to the extent which those working in the system are able to self-organize around the work.
Limit Work-In-Progress: Real leaders know the limits of the capacity of systems and never allow them to become overburdened. They understand that overburdened systems also mean overburdened people and dissatisfied customers.
Manage Flow: Real leaders leverage transparency and sustainability to manage the flow of customer-recognizable value through the stages of knowledge discovery of their services. The services facilitated by such leaders is populated with work items whose value is easily recognizable by its customers and the delivery capability of the service is timely and predictable (trustworthy).
Let People Self-Organize: As per #3 above, when people doing the work of providing value to customers can be observed as self-organizing, this is a strong indication that there is a real leader doing actions 1-5 (above).
Measure the Fitness of Services (Never People): Real leaders never measure the performance of people, whether individuals, teams or any other organization structure. Rather, real leaders, practicing actions 1-6 (above) understand that the only true metrics are those that provide signals about customers’ purposes and the fitness of services for such purposes. Performance evaluation of people is a management disease that real leaders avoid like the plague.
Foster a Culture of Learning: Once a real leader has established all of the above, people involved in the work no longer need be concerned with “safe boundaries”. They understand the nature of the enterprise and the risks it takes in order to pursue certain rewards. With this understanding and the transparency and clear limits of the system in which they work, they are able to take initiative, run experiments and carry out their own acts of leadership for the benefit of customers, the organization and the people working in it. Fear of failure finds no place in environments cultivated by real leaders. Rather, systematic cycles of learning take shape in which all can participate and contribute. Feedback loop cadences enable organic organizational structures to evolve naturally towards continuous improvement of fitness for purpose.
Encourage Others to Act as Leaders: Perhaps the highest degree of leadership is when other people working with the “real leader” begin to emerge as real leaders themselves. At this level, it can be said that the culture of learning has naturally evolved into a culture of leadership.
Stay Humble: Real leaders never think that they have it all figured out or that they have reached some higher state of consciousness that somehow makes them superior to others in any way. They are open and receptive to the contributions of others and always seek ways to improve themselves. Such humility also protects them from the inevitable manipulations of charlatans who will, form time to time, present them with mechanical formulas, magic potions, palm readings and crystal ball predictions. Real leaders keep both feet on the ground and are not susceptible to the stroking of their egos.
If you live in Toronto, and you would like to join a group of people who are thinking together about these ideas, please feel welcome to join the KanbanTO Meetup.
Register here for a LeanKanban University accredited leadership class with Travis.
Nowadays, one of the buzzwords in companies is growth. Companies want to be better today than yesterday, and tomorrow even better than today. But the challenge itself is not the need for growth rate. The challenge is related to how to achieve continuous and sustainable growth over the years in a scenario which constantly changes.
Several studies have been done analyzing the sources of growth, especially related to companies and countries. Centuries ago Adam Smith, David Ricardo, Thomas Malthus studied the elements which can influence growth in countries. These studies provided very rich knowledge when applied to companies of different sizes and industries.
It’s interesting to see how people explain growth. If you ask a company leader “What do you need to grow?” the answer might be “New investments.” If you ask “What kind of investments?” most will answer “New equipment.” If you want to be more specific and ask a colleague what should be done to increase sales, production or profit, he may respond “Buy new technology.” “Equipment or technology” may be correct, but it represents only one component of the answer.
Growth can also be explained based on the variables of Physical Capital (K), Labour (L) and Technology (T). So the idea behind this approach is a formula as represented below in which Y represents the results for each company in terms of revenue, output or even profit.
Y = f(K, L, T)
That means that a company output is influenced by different variables and not only technologies. The interesting point about this reflection is that one answer will not solve everyone’s problem. For over 15 years, working in different industries, my team and I were able to increase companies’ results 90% of the time, with ZERO investment in new technologies. So, what’s the miracle?
The answer is People. The eyes and expertise of a Consultant or a Coach can help your company, in a short-time frame, identify opportunities to increase productivity, quality, and much more. If we take a closer look at the Labour part above, we can identify new sources of growth. For example, labour can be seen not only as how many people you have under your organization but it MUST include knowledge acquired over time. Ask yourself: how is your team expanding their knowledge and understanding of methods and techniques over time? There are different ways of learning and once you create a learning organization you’ll start to benefit from it.
And if you’ve achieved the desired results, what’s next? Sustain the results. Whether the environment changes or not, it is important to have the right people (with the right knowledge) to respond properly to those variations. Training and “learning by doing,” as Agile proposes, can be very useful strategies to achieve long-term results.
In summary, growth is possible when you have the knowledge to achieve it. Consult experts and engage people toward your purpose and you’ll see the results.
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.
An evolving and flexible system of pragmatic, actionable, evidence-based guidance;
Adaptable to the unique needs of each context to which it is applied;
Inclusive of evidence-based guidance from a broad range of professional disciplines, including economics, psychology, sociology, process management and change management.
The Kanban Method is not…
A project management method;
A software development lifecycle process;
Completely defined in a “manifesto” or “guide”;
An immutable process framework with binding rules, extant only in its entirety—in other words, you don’t need to be doing all of Kanban for it to be Kanban, nor is it advisable to try.
You would likely benefit from exploring the applicability of Kanban to your business because…
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 to improve. – Alexei Zheglov
This wikipedia entry provides a fairly accurate description 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.
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
Obstacles: +4
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
Obstacles: +2
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
Obstacles: 0
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
Obstacles: +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.
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.
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.
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 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.
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.
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…
The Kanban Method is a management method for…
