Scrum Master – A Manager

Manager – Traditionally

Traditionally an individual is declared a ‘manager’ when having hierarchical control over other individuals. A traditional manager exerts power. A traditional manager commands people through the assignment of to-be-done work; expressed as tasks or work packages, given on a daily base or via to-be-followed plans. Subsequently a traditional manager follows up on the execution of the assigned work. The traditional manager does not wait for the results of the work but wants to see how the work is being carried out, who is doing it, when the tasks are being performed and how much time it is taking. The time it takes is in general compared to the time that was instructed the task should take.

This and other performance information is recorded and stored, mostly in reports and other forms of documents. The traditional manager (in)frequently uses the stored information to evaluate a subordinate in order to steer that person’s career; via carrots like education, promotion, incentives, bonuses, salary. The traditional manager acts as the one who knows it all, and is supposed to act in the best interest of the company and its shareholders, even if that interest is obscured from the people assigned with the actual productive work.

Not limited to, but certainly in a context of agile, there is not only no need for a ‘manager’ behaving according to this authoritarian pattern and traditional expectation, it is even highly counterproductive and extremely discouraging. Dan Pink - DriveIt undermines enthusiasm, disregards intrinsic motivation by focusing solely on extrinsic motivators, kills job satisfaction, is an open door for politics and bribery and is therefore catastrophic for an organization depending on people. It is without doubt disrespectful and inhumane.

Is the notion of ‘manager’ therefore forever corrupted? Evil by default? A lost case?

Management – Actually

Scrum, like all things agile, has a very different viewpoint on working with people and on the aspect of management, but it does not the disregard that the activity of managing is required.

Let’s explore this different perspective upon the statement that “Scrum Master is a ‘management’ position”.

Indeed:

  1. A Scrum Master is a manager. Contrary to the traditional idea of a ‘manager’, a Scrum Master has no formal power over the people in the Development Team, not deciding over their careers, incentives, etc. A Scrum Master does not manage the people or their tasks. But a Scrum Master does manage (via) the Scrum process. Within an organization a Scrum Master is accountable for the maximization of Scrum, for ensuring that people, teams, departments and the organization realize the highest benefits possible from using Scrum. A Scrum Master is accountable for the way Scrum is understood and enacted. This requires management skills, traits and insights.
  2. A manager is a Scrum Master is a manager. A Scrum Master is explicitly responsible for removing Impediments. Impediments are elements that limit the efficiency and progress of a Development Team in areas that are beyond the reach of self-organization of a Development Team. Impediments are most often found in the wider organization, in company processes, procedures, and structures. Removal of Impediments works better if the Scrum Master is a manager turned Scrum Master, thereby adopting facilitation as the primary management tool and seeing the workfloor as the primary habitat.

A Scrum Master indeed is a manager, albeit not in the traditional sense. It is clear that a Scrum Master does not manage budget, people, work and tasks. Product Owners manage investments. Teams manage themselves. However, self-organization as promoted through Scrum does require goals and boundaries. A Scrum Master manages the boundaries that Scrum provides to augment self-organization; time-boxing to limit risk, focused efforts, cross-functional collaboration, releasable results, validated learning.

The Scrum process does no more than framing the creativity of people in their joint creation of valuable software. The process of Scrum lays out a foundation for rhythm and discovery. A Scrum Master manages the Scrum process through the provision of specific services like removing Impediments, facilitating teams, educating the organization, coaching people and keeping the road open to perform, to work, to innovate, to be creative. The services that the Scrum Master provides, needs to provide or is allowed to provide become a mirror to the state of Scrum in an organization.

Scrum Master can be seen as a management position because the Scrum Master role holds what is expected from a manager in an agile context, not because it reflects what traditionally is expected from a manager. A managing Scrum Master is a wise leader that engages people through organizational purpose and vision.

Manager – A Scrum Master

A manager who acts like a Scrum Master optimizes the value of management to the organization. The optimization lies not in commanding and controlling tasks and detailed work items. The value a manager brings lies in identifying wasteful activities, eliminating waste, removing impediments, embracing complexity by assuring Scrum is understood and enacted, from its principles and roots in empiricism, building on the core Scrum Stance, propelling on opportunistic experimentation, setting goals, and maintaining purpose.

The Scrum Master-manager is strongly affiliated to the Lean idea of “Go See“. A manager turning Scrum Master is a person that does not hide in a far-away office. Not hiding is much more than merely creating an open door policy. An open door is a fake measure, as it still lays the burden with the people wanting to see and talk to the manager. The workfloor buzz does not enter through that door. The flow needs to be reversed. The Scrum Master-manager walks around, is part of the workplace with the teams, the place where the real value is created. In Lean this place is referred to as Gemba.

It can even be taken some steps further with the idea of Empirical Management.

Management – Definitely

Even in an agile context, the act of managing remains a valuable activity. The act of managing is performed by managers.

Teams manage themselves. They organize their work autonomously. They are managers too. Product Owners manage the product’s vision and the investments in the product. Others manage boundaries, company objectives and identity, technical environments, the Scrum framework. ‘Management’ is the collection of all such activities. Management done properly thrives on servant-leadership. ‘Management’ is not a collection of people executing hierarchical powers. It is an emergent, networked structure of co-managers, people with complementary skills, focus and accountability, mutually exchanged services. All seek direction. Collaboratively. Continually. Skills and meaningful conversation prevail over title, hierarchy and position.

“What you say has priority over how you look.”

Is a manager who turned Scrum Master still a manager then?

Product Backlog and the Tea Leaves Effect

The Tea Leaves effectDo you like drinking a cup (glass) of tea? Ever had a tea bag that was torn? Spreading tea leaves in your tasty drink?

Then you know that such leaves circulate wildly and chaotically throughout your tea when you stir it, add water, or drink it. Science is somewhat more precise about the behavior of such leaves, calling it the tea leaves paradox, but let’s just stick with our more direct observations.

Floating tea leaves are best removed from the tea. It prevents obscuring of the tea, and makes a better and tastier drink. Most consumers prefer tea without such leaves. If not for the look of the tea, then certainly because it’s no fun to drink tea leaves.

The tea leaves effect is a good metaphor to understand the need to refrain from collecting and listing requirements in a Product Backlog endlessly. The tea leaves of your Product Backlog are those requirements that go up in ordering every time the Product Backlog gets stirred. They float around, obscuring your Product Backlog and decreasing its transparency, and they always sink to the bottom as the environment settles again.

Keep your Product Backlog clear, clean and tasty. Remove those features that cloud your Product Backlog. Remove those features that always sink to the bottom of what you plan for your product, and never get implemented. If those features are really valuable, they will pop up again at some point in time.

It connects to ‘trimming the tail‘ as described by Alistair Cockburn. The goal is to not build low value ideas. It sounds simple, the gains are considerable, but it takes much discipline. But you don’t want to feed your customers tea leave requirements, right?

Scrum Is A Stance (too)

-An inquiry into the expression of behaviors through Scrum-

Scrum is not a cookbook ‘process’ with detailed and exhaustive prescriptions for every imaginable situation. Scrum is a framework of principles, roles and rules that thrive on the people doing Scrum. The true potential of Scrum lies in the discovery and emergence of practices, tools and techniques and in optimizing them for each organization’s specific context. Scrum is very much about behavior, much more than it is about process.

(from the preface of „Scrum – A Pocket Guide“, Gunther Verheyen, 2013)

It is worthwhile elaborating on the importance of people and behavior in Scrum. Because, indeed:

Scrum is very much about behavior, much more than it is about process.

Introduction: the simplicity of Scrum

Presumably there are many reasons why Scrum turned into the leading framework for Agile software development during the past decade. One of the reasons may be the simplicity of Scrum. Or, perhaps it is the opposite, the wide adoption of Scrum is more like a miracle given that same simplicity.

Yet, the simplicity of Scrum is ESSENTIAL. The simplicity of Scrum reminds us of the fact that the real complexity to be tackled in software development lies outside of the rules and roles of Scrum. The real complexity resides in the specific context within which Scrum is applied. In software development, ‘context’ starts and ends with people; what people do, don’t do, like, dislike, prefer, hate; how people jell, feel and behave. The rules and roles of Scrum help people tackle complexity. But no ‘process’ can replace or compensate the people aspect of software development.

The simplicity of Scrum creates openness. It is an open invitation for discovery and emergence. Yet, the simplicity of Scrum gives rise to many frowns, emotions, reactions, debates. It is experienced as enticing, provocative, offensive, powerful, inadequate, a mystery, impossible. Is the beauty of Scrum, expressed through this simplicity, therefore in the eye of the beholder only? Or is there more to Scrum than meets the eye?

In the end, more than the rules and roles of Scrum, people have the key to Scrum. Behavior is the key to unleashing the potential of Scrum. Scrum is a stance, too.

The eye of the beholder

The rules and roles of Scrum are described in the Scrum Guide. The Scrum Guide was created and is maintained by Jeff Sutherland and Ken Schwaber, co-creators of Scrum. It is the definite body of knowledge to Scrum.

The rules and roles included in the Scrum Guide can be applied and followed as described, with no further inquiry into the why of these rules and roles. They can be regarded as ‘to be followed’ instructions, merely because the Scrum Guide prescribes them.

Blindly following the described roles and rules is for many in the industry of software development at least a great start to transform to Scrum. It helps. People, teams and organizations start, learn, and improve in creating and delivering software iterative-incrementally, with small steps of validated learning. However, sticking to, not transcending, such blind view and usage of Scrum is likely to turn Scrum into no more than yet another IT delivery process. As such it still leaves many holes, gaps, disconnects and waste. The rules and roles of Scrum, as described in the Scrum Guide, in themselves might not be enough to grasp the depth of Scrum and reap the full benefits of employing Scrum. The simplicity of Scrum may be somewhat deceptive.

It helps to dig deeper by:

  1. Reflecting on the definition of Scrum included in that same Scrum Guide document,
    “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
    In the Scrum Guide this definition precedes the description of the rules and roles. This definition shows how Scrum is intended, i.e. an aid for the people employing Scrum, a way for people to structure and organize their own work. It sheds a different light on the subsequent roles and rules of the Scrum Guide. Yet, both are in the same document. Ultimately, the roles and rules described in the Scrum Guide can only be fully understood from the definition of Scrum and the clear intent expressed in that definition.
  2. Reading the description of the roles and rules again, e.g. some time after having started with Scrum. It often leads to the discovery that the Scrum Guide describes behavior more than it has technical prescriptions. A typical focus of many processes is on ceremonial technicalities like meetings, deliverables, timings, phases; i.e. on what is expected from people. Scrum is a framework that gives people the room to organize their own work, yet provides boundaries as every healthy ecosystem needs.
  3. Stepping back to a perspective that goes beyond the Scrum Guide document, the perspective offered in the Manifesto for Agile Software Development. The rules and roles described in the Scrum Guide, the behavior described, don’t just stand on their own. They are grounded in the values and principles expressed in the Agile Manifesto. Ultimately, the Scrum framework can only be fully comprehended when seen as an expression of these values and principles. Ultimately, the rules and roles of Scrum, the behavior described in the Scrum Guide, can only be fully understood in combination with the fundamental views expressed in the Agile Manifesto.

The intent and definition of Scrum, matched against the agile values and principles should ground and then drive the behavior expressed through Scrum.

The Stance of Scrum

Scrum has many facets. Scrum is a framework, not a methodology. The framework of Scrum is not just a set of technical prescriptions, but a recipe to deal with complex challenges. The rules and roles of Scrum support and complement, not replace, the intelligence and creativity of people. The framework of Scrum is an implementation of the values and principles of the Agile Manifesto. Scrum implements empiricism in software development.

The framework of Scrum thrives on implied principles, thinking and… behavior, on people taking a stance to product development through Scrum, a Scrum stance.

The definition of Scrum shows the way to the core of the stance typical to Scrum. If Scrum is an operating system for the values and principles expressed in the Agile Manifesto, the definition from the Scrum Guide shows the way to the kernel of the operating system.

The kernel is expressed as:

PEOPLE EMPLOY EMPIRICISM TO OPTIMIZE THE VALUE OF THEIR WORK.

Where:

  • People are respected for their intelligence, creativity and ability to organize their own work, to self-organize. People collaborate, thereby adhering to the values and principles of the Agile Manifesto and embodying the Scrum values of respect, focus, courage, openness, and commitment.
  • Empiricism serves to deal with the complexity typical to software development. In empiricism only reality and past results are accepted as certain. At a regular cadence outcomes and behaviors are transparently inspected for new and changed insights against set goals. These insights are used to adapt to observed reality.
  • The value of outcomes, work delivered to an ecosystem of creators, stakeholders and consumers, is constantly evaluated, optimized and maximized as a shared goal. Value comes in different shapes and appearances; satisfaction, money, improvement, credibility, risk. Optimizing value is very different from adhering to traditional development drivers like budget, tasks, scope, time, schedule.

In the end, Scrum has many appearances. In the end, Scrum -like all things agile- starts and ends with people. Scrum is a stance, too.

The Scrum Stance

Measuring Success, Measuring Value

The aim to deliver valuable software is a great, core principle of the agile movement. The difficulty however is that ‘value’ in itself is hardly quantifiable. Yet, I do believe it is imperative to think in terms of value in software development and therefore overcome some fluffiness attached to ‘value’. If we don’t find actionable ways to deal with ‘value’ it might remain meaningless; another buzz word, another way of getting people to think it’s time to move on to the next hype. It is not only difficult to quantify value, it is not even necessary, maybe even undesirable. It is better to measure whether we are delivering value (effectively).

What we thought defined success

For many years we were tricked into believing that software development can be considered a success if we meet 3 criteria: deliver (1) all promised requirements (2) within the planned time (3) for the allocated budget. It is reflected in the famous iron triangle of software development.Iron Triangle of Software Projects

That in turn tricked us into believing that, in order to be successful, we had to exhaustively analyze, detail and describe all requirements upfront, and get formal approval and sign off over them before the actual programming can be done. The underlying motivation is to secure the first element of what we were told defines success, the ‘requirements’.

This beforehand gathered information then becomes the input to careful and exhaustive calculations for the delivery part, often with the addition of some ‘contingency’. The underlying motivation is to set and fix the other two elements that we were told make out success, time and budget.

The result is poured into a plan, often complemented by risk mitigation strategies and other exception procedures. When this plan and all its components and clauses are approved and signed off, implementation can -finally- start. And then, obviously, it is just a matter of following the plan to be successful. Deviations from the plan, seemingly happening sometimes, are unlikely to cause any real problems, because it’s what ‘change request’ instances are for (meetings, documents, approvals, and sign offs).

Unfortunately, this was (and at many places still is) believed to be the only way we can ensure the ‘success’ of software development.

Yet, things aren’t that easy. The installments of the mentioned extra safety nets are already an indication that, despite our firmness, this approach isn’t really giving us the certainty it claims to have. And despite the safety nets, the detailed preparations and the seemingly perfect plans, many projects are plainly cancelled (29% according to the Chaos Report by the Standish Group of 2011) or in the end still fail in meeting the widely accepted success criteria of scope+time+budget (57%).

Some however are actually successful in delivering according to the three predictions (14%). But then, success doesn’t take into account that often quality was lowered to unacceptable levels in order to live up to the success criteria; reason why it’s good to add that as a fourth variable to the iron triangle (see figure). Success doesn’t take into account that the elapsed time might be according to plan, but may business-wise be extremely slow. Note that it is not unusual for projects to deliver software no sooner than 12-24 months after the start! Success doesn’t take into account that by the time the software actually becomes available for use, nobody really sees much ‘value’ in the features anymore; at all rendering them useless or in the functional way the features are implemented. More innovative ideas for them have emerged, or improved technological ways to implement them are discovered. It connects to the finding that 64% of features, produced in this way, are rarely or never used.

The three factors they told us defined ‘success’, fail in doing exactly that. And even if they are met, they still only reflect how successful the ‘delivery’ of the software to the market is, not how the software is being received or appreciated on the market place, let alone that the approach helps us addressing changes or new requests from the market place. The three factors fail in showing how valuable the software is; it only says that a version of software got out the door at certain predicted conditions.

What we say determines success

Agile overcomes the fallacy of traditional, upfront predictions and descriptions with collaboration, communication, incremental progress and continuous improvement. All risks taken are limited in time through time-boxed iterations. Time-boxing allows adaptation and adjustment within the process.

Agile Value Delivery (general)

The agile movement stresses the importance of active business involvement as part of cross-functional development work. The agile movement stresses the need for frequent releases to the market place to learn what actually is appreciated. There is no better risk mitigation than regular feedback from actual users.

Scrum, as leading framework for agile software development, is designed upon the foundation that software development is too complex for a predictive approach. Scrum implements empiricism in software development, thriving on frequent inspections to decide on the best possible adaptations. Inspections however are pointless if the inspected information is not fully known, opaque instead of transparent, and if the inspection is not done against known and agreed standards and definitions.

The target of the adaptations is not only the software being produced, it is also about the tools, the engineering practices, the relationships, the process and the three elements they told us define success, i.e. budget, scope and time. Scrum does not care about the abused notion of ‘project’. The concept of ‘project’ generally only serves the idea that success is possible if software is delivered on time, within budget and has all the predicted features. Scrum focuses on the software product (having a role and an artefact for its owner and its backlog) and incremental sustenance of the product.

The foundational belief to this is that the success of software development is defined by the capability to satisfy and impress the consumers of the features, at a reasonable price, at a cost that has an effective return, with creation happening in a way that is sustainable for all people in the ecosystem of the product.

Yes, we can… measure

The success of an organization, in terms of survival, prosperity and leadership, increasingly depends on their ‘agility’, i.e. their overall capability to deliver value in a context of constant change, evolution, innovation, improvement and re-invention.

The difficulty in establishing the value of software or software requirements is that it depends on context, time, technology, market, business domain. It also cannot be reduced to one parameter only. Predicting value doesn’t make much sense either, since it can only be validated by the market place.

But if value defines success, how can we then measure whether we are successful?

Scrum.org has developed the Agility Path framework to help organisations increase their agility and move toward a value-driven existence.

Agility Path Circle

Agility Path focuses not on the illusive goal of calculating and predicting value or similar magic. With Agility Path the outcome of an organization’s work is measured with metrics to help them think about the way that outcome is achieved. Organizations get a clear indication on whether they are delivering value or not. If from the metrics it seems they are not, they have many areas and domains to inspect further, and do adaptations by installing, removing or improving practices, tools and processes. It is how the Scrum framework is used to manage the change process, the transformation of an organisation required to increase their agility.

The metrics provide the transparency needed to identify the areas where adaptation has the most impact. Think in terms of business metrics like employee satisfaction and customer satisfaction, revenues, investment in agile, etc. Think in terms of delivery capability metrics like cycle time, release frequency, defects, etc.

All metrics are consolidated into an overall Agility Index for the organization. This Agility Index is an indication of how effective the organization is in delivering value. One Agility Index is bound to time, place and context. The exact figure is of no importance. The evolution is of importance. The underlying set of metrics is of importance. The insights gained from the metrics, as a source of improvement, are of importance.

No magic, just hard work

There is no magical formula to calculate value, and even when trying to calculate value to steer development priorities, it is a prediction, an assumption that remains to be validated (or contradicted) when you actually go to market. You can never be sure.

The best we can do is to capture the results of our actions with metrics, and do those measurements regularly. We detect trends and patterns (and prefer that over a naked, singular figure). We relate that back to how we work, change how we work, and measure the change in outcome of that assumed improvement. We do that endlessly and relentlessly. We continuously improve by learning and adapting. We get the most out of what we do.

This flexibility primarily helps organizations respond better and faster to change, it implements openness to change over ignoring or blocking it. Once the thinking gets ingrained and new ways of working are installed, organisations discover that there may be different options to respond, thereby embracing change as a source of information. And, finally, organisations start innovating, be ahead and cause change (for the others to follow). Thus an agile approach harnesses change for the customer’s competitive advantage, and the organization’s agility.

The Potential of Agility

Ways to play Scrum

Scrum.org-Logo-CirclesIn our Professional Scrum classes we also talk about the topics of User Stories, Planning Poker and (Daily) Stand-up meetings. Some attendants have never heard of it. Some have never practiced it. Some are convinced, or have been instructed, that Scrum says these are mandatory to do.

I have grown my own little pattern to work with a class whenever we run into one of these topics during my classes.

  1. I start by asking what Scrum actually says on the practice. In general, people don’t know or are not sure, and conclude that Scrum says nothing about it.
  2. I ask where the practice then does come from, if it’s not Scrum. Few people know that it is eXtreme Programming.
  3. I end up by saying that, despite the XP origins, we do support them in many cases as they represent good ways to play Scrum, they are good practices to chose from. And that this is the reason why we cover them in the course; to inspire people with different options to play Scrum.

But, they are not mandatory from the Scrum framework described in the Scrum Guide:

  • Extreme Programming Explained: Embrace C16614_fUser Stories, written on story cards, are the practice in Extreme Programming to hold and describe requirements from a user perspective. Bill Wake, author of ‘eXtreme Programming Explored’, suggested the ‘INVEST’ acronym as a simple way to remember and assess whether or not a User Story is well formed.
    A Scrum Product Backlog though serves to provide transparency to all work that a Scrum Team needs to do, which might be more than only functional requirements. The obligation, from Scrum, to use the User Story-format would endanger forgetting other important work to be undertaken, or it might force teams spending more time and energy on using the ‘right’ format, thus creating waste. However, for functional items on the Product Backlog, User Stories may be very good.
  • Planning Poker was invented by James Grenning during an eXtreme Programming project where he suffered from having to spend much, much time on producing estimates.
    In Scrum, estimates are to be created by the Development Team and, although not mandatory, Planning Poker is a good technique to do that. It leads to more honest estimates from a complete team. But don’t forget that the intention is to invoke an honest conversation over the estimates. Because that results in a good understanding of the work attached to implementing the discussed item.
  • Daily Stand-up are described in Extreme Programming, which recommended participants stand up to encourage keeping the meeting short.
    Scrum describes this meeting as the Daily Scrum, but doesn’t oblige to do it standing up. However, it is a good idea to do, especially to keep the time-box of 15 minutes.

That is often a relief to students, knowing that it is not mandatory. And I am glad I can help people. I am glad they see more opportunities to discover their own best way to play Scrum respecting the intentions and design of Scrum. They see better how Scrum can help teams and organizations emerge their own process. These ways to play Scrum in teams’ specific contexts turn the selected good practice into best practices.

Scrum, after all, can be called a ‘process’, but it’s a servant process, not a commanding process.

Take It To The Team

Lyssa Adkins - Coaching Agile TeamsI have read Coaching Agile Teams by Lyssa Adkins in a gradual way. I regularly stopped reading for a while because I wanted time and mental room to absorb, practice and reflect about what I was reading before continuing down the fascinating path of insights offered by this book. Although I require from every professional book to give me something I can immediately apply, in this case the richness was so huge that the need to stop-start seemed a lot bigger. I also regularly stopped reading to take my newest gained words and insights to the team; test and try them, plant some seeds, watch out for sparks that might turn into a fire.

In Short

Lyssa Adkins has written a very comprehensive book that covers a great, all-round collection of topics concerning agile, professional coaching and… agile coaching. She uses her past of traditional project manager to describe how she discovered the beauty, the power and the value of agile via Scrum and self-organization. But Lyssa is also a co-active coach, doing coaching from a peer perspective with an emphasis on active collaboration between coach and coachée. The book blends the aspects of agile (via Scrum) and (co-active) coaching in a fantastic and enlightening way. But I highly appreciate Lyssa’s strong emphasis that our journey as Scrum coaches is not only about coaching in general, nor about life, personal or love coaching but that it’s about agile coaching. It’s about helping, mentoring, facilitating people, teams and organizations to become great in agile, to achieve high performance through agility. And that is a lot more than producing still mediocre products, just faster.

Audience

On its cover the book says to address a rather broad audience (‘A companion for Scrum Masters, Agile coaches, and project managers in transition‘). But I see Scrum Masters as an important target audience:

  • Because the book has its origins in Scrum, the most applied agile framework, and Scrum foresees the roles of Scrum Master, Product Owner and Development Team.
  • Because this companion holds extremely useful material on behavioral aspects in facilitating Scrum and from my practical experience and as a Professional Scrum trainer for Scrum.org I see much room for improvement there for many Scrum Masters.
  • Because Scrum Masters are expected to be coaches too, doing much more than just managing the process of Scrum.
  • Because too many people think ‘coach’ is a title to achieve, and not a level of mastery to grow into.

Lyssa clearly depicts what it might take to ‘be’ a Scrum Master (or agile coach as you wish), not just ‘do’ it. Remember that, as servant-leaders, Scrum Masters help the other roles within the Scrum Team to play their part (like a conductor would do, one of Lyssa’s metaphors). They help Development Teams achieve great team dynamics. They help Product Owners interact with stakeholders and discover better product ideas. They inform the organization about the Scrum process. They promote agility, agile behavior and the agile principles. They make sure that the wider organization gets the absolute maximum out of Scrum, as part of the continuous search for the art of the possible. And Scrum Masters know how to adapt their communication and working style according to place, time and audience.

Content

Coaching Agile Teams starts by helping the reader to introspect on behavior, habits and attitude in “Part I: it starts with you”.

Part II (“Helping the team get more for themselves”) obviously is the main part as it shifts the focus to the role of a facilitating coach towards the team. It does so by highlighting the various appearances a team facilitator might want to learn to master, the natural fluency with which appearances can be switched, the honesty and openness it takes to learn and admit failures while learning. Some important coach appearances include the teacher, the mentor and the conflict navigator. Throughout Lyssa offers advice, techniques and insights all based on practical experience.

In Part III (“Getting more for yourself”) Lyssa reverts back to the reader with a chapter that describes failure and success modes, skills and abilities that might help and war stories of some world class coaches. It makes most sense for experienced and seasoned practitioners. The danger of reading this chapter too soon is that people will turn some of the topics into incentives, objectives and goals to strive for, rather than real life findings one wants to match his/her personal experiences against.

At a personal level

Lyssa’s book has helped me in many ways. It gave explicit words, a vocabulary, to some of my existing -often unspoken- observations, practices and behavior. It enriched my existing ways of working with additional insights, evidence and perspectives. It offered many new ideas, insights, practices, papers and backgrounds. It helped me further transcend the technical views on agile and Scrum with the book’s strong focus on human behavior, psychology, people and professional coaching. And I can share this transcendent perspective better with others now.

Many great books on agile have I read, but Coaching Agile Teams by Lyssa Adkins is one of the few agile books that truly changed my life. And it’s been a while since I had that feeling over an agile book again.

Impediments (and where to find them)

Probably the most known purpose (task) of a Scrum Master is to remove impediments. If that is reassuring: it’s even described in the Scrum Guide. A Scrum Master is indeed ‘officially’ expected to remove impediments to development and to the Development Team’s progress.

Unfortunately, this is sometimes interpreted as the Scrum Master having to be an ‘impediment hunter‘. That suggests that a Scrum Master should proactively search for impediments in order to track them down and kill them. There is a danger in this wording, besides the very negative feel to it. I particularly wonder how this aligns with the self-organization of teams and transparency? Self-organization is essential in Scrum and it’s to be promoted, served, coached, taught and mentored by that same Scrum Master. Transparency is required to know about reality, inspect it, learn from it and make proper adaptations.

An impediment is an “obstruction; hindrance; obstacle”. And Scrum is a framework that helps teams in finding better ways to create working software in 30 days, or less, and handle the complexity attached to that. An impediment in Scrum is therefore anything that blocks the (development) team in its creation of a valuable piece of software in a Sprint, or restricts the team in achieving its intrinsic progress.

Where to find an impediment?

We can expect a team to raise an impediment, any annoying problem that is truly blocking them. Actively looking for (‘hunting’) and removing impediments is solving problems that are not a problem yet. It assumes that a Scrum Master, as 1 single person, knows more -or pretends to know more- than the united brains of a complete team of up to 10 people; a team that daily makes hard choices by disciplined collaboration.

Solving a problem before it’s a problem points at a lack of belief in the self-organizing capability of a team. Solving a problem before it’s a problem prevents learning and improving because it obfuscates transparency to the team. Solving a problem before it’s a problem is mostly a waste of time and energy because the team will probably handle it by itself anyhow, without the Scrum Master, preventing it from turning into something that truly blocks them. They probably even solve more problems than the Scrum Master knows or can imagine.

It’s simple, an impediment is not an impediment if it hasn’t been raised by the team. Impediments cannot be anticipated. And if there undeniably is an impediment (not an anticipated one and not an issue that the team is already handling) and it is not being raised, the question of the safety of the environment arises. What is preventing the team from raising the impediment?

Not raising an impediment does block the team. What’s then the real problem for the Scrum Master to solve?

What does an impediment look like?

Issues only become impediments if they cannot be tackled within the self-organizing ecosystem. The concept of ‘impediments’ is not a replacement of the traditional escalation procedures. Traditionally people are told to escalate whatever bothers them to a person external to their work to solve it for them. Easy and convenient. But is it also helping?

Scrum delivers great results because it thrives on self-organization, accountability and skills; it appeals to those elements. Scrum restores the respect for people and the understanding of software development as complex and creative work. By definition, in Scrum an issue only becomes an impediment if it can’t be unblocked through the authorizations of the (development) team.

Let’s illustrate this with the example of a team conflict, a conflict between team members.

A team might have problems in resolving a conflict and call the conflict an impediment, expecting the Scrum Master to remove it for them. They expect the Scrum Master to solve the conflict. However, working as a team inevitably includes getting to know each other, finding ways of building software together, exploring different ways to collaborate, outgrowing the desire for personal heroism, and improving through constructive disagreement. Conflicts are a part of working with people, part of becoming a self-organizing team, part of aiming at high performance.

Once again we should raise the question what the real problem for the Scrum Master is to solve? Is it the Scrum Master’s role to solve the conflict? Or would that be an undesired intervention in the self-organizing ecosystem, undermining future honesty, learning and self-improvement? How can the Scrum Master facilitate self-organization? Is it by offering teams an excuse, an external decision to hide behind? Consider how to help a team work out their problems themselves and offer any tools, trainings and insights on how to do this.

Not dealing with an issue does block the team. What’s then the real problem for the Scrum Master to solve?

Fixed Price bids. An open invitation to bribe, cajole, lie and cheat.

I have been fortunate. Because some things take time and I have had the time to experience Scrum deeply before the demand rose sky high at my local markets. Time and experience formed the foundation upon which I build in some larger scale Scrum transformations that I am involved in.

I have learned much. I have much to learn. Yet, some people ask for my opinion.

A frequently recurring question is on the combination of agile and fixed price bids (and contracts). Here are my thoughts:

I have an opinion

Fixed price bids are an open invitation to bribe, cajole, lie and cheat.

  • Fixed price contracts introduce a blaming culture. They don’t aim at collaboration and sharing but at shifting all risk to one of the contracting parties. It invites people and organizations to be dishonest and fight in order not to take the blame (and the penalties). It might end up with the supplier financially getting hung, or the requester getting bad quality or not getting work by devious (and clause-wise) omission.
  • Fixed prices deny the very nature of our business. Software development is complex and creative work. There are a lot of elements that influence process and progress, and the number of unpredictable elements surpasses the number of predictable ones.
  • Fixed prices thrive on the belief that time, budget and scope can be fixed and planned upfront. Although everybody (at least off the record) acknowledges the truth in the metaphor of the iron triangle of software development, few seem to say it aloud. Hereby, fixing time, budget ànd scope creates only one certainty, i.e. low quality.

I have experience

Fixed prices define ‘success’ as the predicted combination of in-time+on-budget+promised-scope. Research by the Standish group has shown that agile is more successful than a traditional approach, even against these old criteria. This is not a reason to promote the combination! Yield rate is better but still low by setting the wrong expectations in the context of software development, i.e. that the unplannable can be predicted in a plan.

In the early years of my life in agile, I have delivered several fixed price projects successfully with Scrum. I even developed a framework for it. Still, from a contracting point of view it introduced the notion of ‘fixed price-negotiable scope’. Every single time that this notion was neglected or ignored I ended up in a one-way scope negotiation situation. The bleeding, the pain and the war situations never positively contributed to quality, time to market, user satisfaction, ROI, TCO. Blaming and penalties just appeal to a primitive sense of revenge.

In our Professional Scrum courses we work with the people in the class to figure out options to use Scrum. We try to facilitate bottom-up knowledge generation. We consider parameters and complexities that influence IT and software development, to find that in general we can’t be sure we have them all, and that at least some of the known ones are still quite unpredictable.

Agile via Scrum restores the understanding of the true nature of software development, and offers new ways of working and control to deal with uncertainty. It helps us to shift from the industrial to the creative paradigm and to accept that software development and fixed price contracts are not fit for each other.

I have a dream

Against all experience in, proven low yield rate, failures, burnt-out people and caused distress, the belief remains that a fixed price contract offers certainty. Although there is a tangible and incredible way to deal with the natural uncertainty of software development, Scrum. Scrum allows us to collaborate and behave as partners. We can jointly evolve, learn and check regularly on what does/does not work. But it still requires the first, huge step to let go of the false belief in planned certainty.

I have a dream; the dream that IT professionals stop offering on fixed price bids. Because it is unethical, risky and untrustworthy to make that kind of hard-coded promises in a complex and fast-changing environment. It is… unprofessional. And there is a great alternative option.

Agility can’t be planned

I have been fortunate. I have been involved in some larger scale Scrum transformations. I have learned much. I have much to learn.

Here are some basics that are fundamental to set the right expectations for a enterprise Scrum transformation. I will relentlessly repeat and remind these. Because introducing agile without accepting these essential truths closes the door to the path to agility instead of turning it into a gateway of opportunities.

Agility can’t be planned. Agility can’t be dictated. Agility is never ready.

A time-planned way to introduce agile at an organizational scale sets unfavorable expectations. Change processes are highly complex and therefore not predictable. And agility is much more than following a new process. It is about behavior, it is about cultural change. In a transformation towards an agile way of working, there is no way of predicting what change needs will be encountered at what point in time, how these are to be dealt with and what the exact outcome will be. There is no way of predicting the pace at which the change will spread and finally take root.

A decision to move to agile is a decision to leave the old ways behind. It is not only about accepting but about celebrating that agility is living the art of the possible. It requires the courage, honesty and conviction of acting in the moment, acting upon the reality that is exposed by iterative-incremental progress information. Agility is about doing the highest possible at every possible moment, given the means we have and the constraints that we face.

Time-plans create the illusion of deadlines and an end-state. Agility has no end-state, but introduces a state of continuous improvement, a state in which each status quo is challenged, all the time.

Agility can’t be planned. Agility can’t be dictated. Agility is never ready.

This must be in the hearts and minds of every person guiding or driving a Scrum transformation. Because agility needs to settle in the hearts and minds of every person impacted by a Scrum transformation. And in general those people have been instructed the wrong behavior for 15 or 20 years. In general a plan will slow down the transformation process, as it just extends the old thinking. Living the art of the possible engages people and accelerates a transformation as it thrives upon the future. A bright future if you have the vision, the determination and the dedication. And if you have, I hope I can help you. And I will bring metrics, practices and tools that will light your path.

Personal Scrum Day Europe Impressions

On 11 July 2012 we organized the first edition of the Scrum Day Europe (for which I previously published the abstracts of Ken Schwaber and myself). 130+ enthusiast people gathered, interacted and connected at the beautiful location of “Pakhuis De Zwijger” near the Amsterdam docks (Netherlands). I was delighted to see so many friends of Scrum; Professional Scrum students, colleagues, clients and personal friends. And I am extremely grateful for the appreciation and the energy received.

Ken Schwaber opened the day with an inspiring talk on the global accomplishments of Scrum, and how well this positive change for the software industry is currently being embraced in Belgium and the Netherlands. He announced he is working on further evolutions of the Scrum framework towards management and organizational improvement.

The CIO of Tele2, Svenja de Vos, talked us through the practicalities of their ‘big bang’, ‘no guts, no glory’-style transition to Scrum.

Subsequently the audience split up to (1) join an OpenSpace, (2) play some agile games and (3) enjoy more perspectives to Scrum (change basics, coaching people and Scrum in a hosting environment).

After lunch the full group joined again in the central room to listen to the highly energetic story of Amir Arooni, member of the ING IT management team. He gave the crowd an honest insight into their findings, impediments and future hopes after a 1+ year, large-scale transformation to Scrum. I was honored to be mentioned by Amir as one of the crucial guides of their transformation.

As Capgemini global leader for Scrum I was asked by Ken to do my talk on the ‘Emergence of the Customer-Oriented Enterprise’, an organizational pattern to build on the Scrum framework to achieve enterprise agility. Beyond the appreciation I received I was particularly glad for getting away with a form of humor. My presentation is free for download. All pictures and presentations of the event are available at the Scrum Day Europe website.

Here’s a very personal selection of (mostly mobile) pictures by friends:

A big thanks to Scrum.org, all co-organizers and I hope to see you next year!