Should a Scrum Master Be “Technical”?

This is a pretty popular question in Scrum circles that recently came up on LinkedIn (again).

In order to answer this question, I believe we first need to define terms “Scrum Master” and “technical”.

Merriam-Webster provides this as a definition for the term technical, “having special and usually practical knowledge especially of a mechanical or scientific subject” while the Business Dictionary provides the following for its definition, “pertaining to computers or technology”.  For the purposes of this post and in the context of Scrum as a process framework for the development of software products, technical, will simply mean “understanding the technologies and being able to engage in the software development activities involved in the process of creating software products”. Technical, is not a synonym for “software developer” or “computer science major”.

For the definition of Scrum Master, we don’t have to look any further than the Scrum Guide which provides us with the following as it relates to the Development Team:

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

I highlighted “helping the Development Team to create high-value products” because it stands out separately from “coaching the team”, “removing impediments” and “facilitating events like retrospectives, refinement, and standups”. What does it mean for the Scrum Master to “help the development team create high-value products”? Pretty vague, isn’t it? It would seem to me that the interpretation is largely left to the Scrum Master (and the Development Team) on what help they can provide. In my opinion, helping includes the Scrum Master to directly engaged in the value creation process.  In other words, the Scrum Master can directly act on the software product as its being developed. (For what it’s worth previous versions of the Scrum Guide said something much stronger when it came to helping the development team: https://webgate.ltd.uk/scrum-guide-2013). In helping the team, the Scrum Master still needs to respect the empowerment given to the Development Team.

I don’t know how a Scrum Master can effectively engage in core software development activities without understanding what’s going on from a technical perspective. In the Scrum community, there is a ton of focus on coaching, facilitating and removing impediments. I have no intention to diminish the importance and necessity of these activities but these activities do not act directly on the product that is being created.

I don’t see a lot of conversation around how the Scrum Master can help with the core activities of software development if need be.  In fact, I read many posts that seemingly discourage Scrum Masters from becoming directly involved in value creation. It’s taboo to ask (for example) if a Scrum Master can test, write stories or even code if need be. I’ve interviewed many a Scrum Master who didn’t really care about how things really got done or worked because they believed that this needn’t be a concern of theirs or as they often put it, “I’m not technical and I was told during my training that I didn’t need to be”.

Maybe we’re compensating for bad practices we observed such as the making of the Lead Developer a part time Scrum Master. However, I don’t believe that we effectively address dysfunction by reinforcing other dysfunctional practices.

So, should a Scrum Master be technical? I believe the answer is yes but that is only if the Scrum Master wants to be able to help act directly on the software product being developed. Otherwise, the answer is obviously no. I encourage all the Scrum Master’s I work with to be as technical as they can comfortably be.  As a Scrum Master, the choice is ultimately yours.

Advertisements

Are We Done Yet?

Recently, there has a been a bit of talk about being done in the context of Agile software development.  If I’m not mistaken, as far as Agile frameworks go, it would seem that the Definition of Done as described by Scrum influences many an Agile team. We also know that there are variations on this as well such Done-Done and Done-Done-Done.

But when are we really DONE?

In some regard this depends on how we define done.  Is a movie done when production is over?  Is a presentation done when the slide deck has been prepared?  Is a meal done once it has been cooked?  Is a software increment done when coding and testing are complete?

Teams engaged in real (there is a lot of fake and dark Agile out there) Agile software development are guided by a set of 4 values and 12 principles.  The very first principle in the Agile Manifesto goes as follows:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

When we use this principle to guide how we define done, I cannot understand how we can consider ourselves done until we’ve delivered an increment of value to our customers. Not just deployed (and hidden behind feature toggles or something like that) but delivered such that our customers can interact with the increment in some form or fashion.

So the next time your team debates whether you are done, ask yourselves if your customers are using the increment.

(Thanks to Mia Augustine for inspiring this post).

P.S. IMHO Scrum’s Definition of Done (in the best case scenario) is really (more appropriately named) Definition of Ready To Be Delivered.

Time-boxes, goals and realizing outcomes

Goal is defined as:

the end toward which effort is directed” or “the object of a person’s ambition or effort; an aim or desired result.

I don’t understand the debate over the Sprint Goal.

I also don’t understand how a teams can function and focus without goals (be they implicit or explicit although I would suggest that there is a danger in not making goals explicit).

If a team carves out a fixed set of time (a time-box) to do some work, they already have, albeit implicitly, established a goal i.e. completing a certain amount of work in a certain amount of time.  I don’t consider this type of a goal to be a best goal we could come up with because it’s output focused and you know I favor outcomes over outputs.  I will concede however, that this type of goal is probably better than no goal at all.

From the Scrum Guide, the Sprint Goal is:

an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Seems pretty straightforward to me with a lot of latitude for the Scrum team to create their goal.  What do you think?

If your time-boxed work period has no goals, no aims, no objectives, no desired end what exactly is your team doing?  Where are you headed?

(I’m pretty sure some folks reading this are thinking to themselves that time-boxing is an archaic practice and should be dropped altogether.  Stay tuned for my next post).

And while this post has focused up till this point on teams working with time-boxes, I will go even further to suggest that any team that is developing and delivering software in support of a broader organizational vision – yes I’m looking at all the teams that say they are using Kanban out there –  that doesn’t have time-bound (see Agile Manifesto Principle #3)  goals is operating irresponsibly.

Goal are very useful.  Use them wisely.  Use them well.

What’s Wrong With Scrum – Part III

Earlier this year, I started writing on the limitations of Scrum as a result of articles I had come across.  In my first article, I was critical of the individuals (largely Scrum Masters) responsible for guiding Scrum adoption in organizations. In my second article, I took a look at the system (and those who create them – leaders and managers) and wondered aloud as to whether the organizational constructs actually supported Scrum being effectively leveraged in our organizations.

It is possible, readers came away from my first two postings with the impression I believe nothing is wrong with Scrum –  it’s perfect – and dubbed me a Scrum zealot of some sort.  Well in case you did, maybe this last post will leave you with a different impression.  Maybe.

Scrum is defined as: a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.  This definition would seem to imply that as long as a team is in the business of delivering products, Scrum should be a fit.  Is it really as simple as that?

I rarely hear productive dialogue around the scenarios when and where Scrum (the process framework itself) isn’t a good fit for a team developing products, so I’ll attempt to start some dialogue here.  In my opinion, for Scrum to be a fit, the holistic nature of the work the team is doing needs to be in alignment.  When could the nature of the work not be a fit?  I’m going to attempt to identify these situations via the lens of the VUCA framework.  VUCA stands for volatility, uncertainty, complexity and ambiguity.

Volatility

Volatility refers to how much change is occurring.  In the context of Scrum, I see this as how does the rate of change impact how we plan.  Let’s consider Team A that gets to their Sprint Review and identify they did not deliver what they had planned because they had to deal with new work that emerged during the Sprint (not because they planned poorly which many teams do!).  Or maybe every Sprint there is a discussion around canceling the Sprint because the Sprint Goals keep changing due to emerging market factors.  Maybe emergency customer requests or defects have to be addressed in order to keep major accounts. The nature of their work is so volatile, they cannot plan any further out than maybe a day or two.  In this case, Scrum may not be an appropriate fit.

Uncertainty

Uncertainty is focused on the degree of predictability we have.  Scrum works well for handling unpredictability around what will satisfy the customer because the framework requires customer engagement throughout the process. On the other hand, Scrum expects certainty around what the team will be working on in any given Sprint and the goals they have.  If we cannot arrive at a level of certainty around what exactly we will be working on in a Sprint (maybe due to volatility), Scrum may not be a fit.

Conversely, if there is little uncertainty about what needs to be delivered such that (for example) customer engagement has little impact on delivering a work product that meets the desired goals or if the team just needs to plow through a laundry list of items and ordering (or prioritization) is not particularly important or if potentially releasable increments are not needed during the duration of development, then Scrum may not be valuable as a framework for delivering products.

Complexity

Agile frameworks and methods are designed to deal with the complexity involved in the development and delivery of products.  But what if your work is not complex?  What if it’s simple or complicated?   While complicated work is difficult/hard, we know the steps we need to take and the “end is largely known from the beginning”.  Simple work is like complicated work except we don’t have the ‘difficulty’ property present.  In either case (with simple or complicated work), the amount of discovery that occurs while we are doing the work is minimal and hence the benefits of Scrum itself is probably minimal.  If we don’t need to inspect and adapt, then the events Scrum provides for this are probably overhead.

Ambiguity

Ambiguity has been described as the presence of “unknown unknowns”.  It seems to me “unknown unknowns” are always present except in the simplest of endeavors.  The question we need to answer is this: how much of our work is characterized by ‘unknown unknowns’?  It’s my personal opinion that Agile (and hence its frameworks like Scrum) work best in situations where the work has a balance of ‘known knowns’, ‘known unknowns’ and ‘unknown unknowns’.  When ‘unknown unknowns’ is the predominant characteristic of the work, there may be better frameworks for managing such work.

So yes, it’s quite possible, that the nature of a team’s work may be such that the Scrum framework is not the best framework for managing the work. We can only come to this conclusion when we take the time to objectively profile our work.  Objectivity is key here and worthy of another post.

It’s at this juncture I need to remind us that Scrum (and Agile by extension) are not THE goal.  Your organization has business goals that are extremely important.  Your team has hopefully been asked to own making a contribution towards these goals.  Agile (and its frameworks and methods) may enable you achieve those goals in a manner that is fulfilling and rewarding and yet it is important that we continuously assess, with a critical eye, the frameworks and methods we have chosen and make sure they remain a fit.

I find many teams and organizations give up on Scrum because it makes them uncomfortable as it shines a light on both team and organizational dysfunctions, NOT because the nature of their work is not a fit.  To make matters worse, they then distort Scrum by redefining it to meet how they would like to work.  When we give up on Scrum or any other frameworks for the wrong reasons, we have placed a self-imposed cap on what we could have accomplished.  Our new approach doesn’t really solve our problems; it just introduces a brand new set.  Isn’t that a crying shame?

I hope these three articles on Scrum provide you with thinking tools that help you choose ways to work that are both fulfilling and extremely effective.

What’s Wrong With Scrum – Part Deux

Five months (and a bunch of Agile thoughts) later, its time to continue to address the challenges organizations have with Scrum.

In my last post on this subject, I focused on the Scrum Master role, the current certification model and the failure of people who are in supposed Agile change agent positions to really dig deep and own their craft.  I got a bit of feedback from some people indicating I was a bit too harsh.  I’m sorry if I offended anyone.  The remainder of this post may also be offensive to some. Please proceed with caution.

This post focuses on the situation where the existing organizational culture not being a fit for Scrum (and Agile).  The values of each subculture are not shared or complementary and the behaviors are at odds with each other.

Many organizations that want to “go” Agile (by way of Scrum for example) don’t realize that they are potentially embarking on a cultural change that the organization may not be prepared for.   A lack of awareness and unpreparedness eventually causes conflict and failure. I’ll present (as examples) three Agile cultural values that are often at odds with the prevailing cultural values in many organizations.

Planners Plan, Doers Do

I’ve shared my thoughts on the role of the manager in knowledge work and human-based systems.  You can check out all my posts on this here.  Many (if not most) managers have been informally trained to be managers from the school of Taylorism with the belief that managers “plan” and the non-managers “do”.  A manager is only successful if she or he is good at telling people exactly what they should do, how they should do it and ensuring it gets done.

Scrum teams are self-managed. It’s been my experience and observation that many organizations find themselves at odds with the concept of self-managed teams because it challenges the conventional role of a manager in their organization.

The organization has little need for Scrum Master’s who focus on helping establish self-organizing teams.  Managers want someone who will answer to them and “drive the team to success”. But in order to have the moniker of an “Agile organization”, they label these individuals as Scrum Masters.  It doesn’t take long for Scrum to implode in such environments.

Get Off My Lawn

Many organizations struggle with establishing cross-functional teams that work across functional silos.  The development of products is often more than just a ‘tech org’ endeavor and yet I often hear people (in and outside of technology) suggest that Scrum (and Agile) is just for technology.  As a result of this, silos are encouraged and reinforced.  People spend hours debating roles and responsibilities and then developing RACI matrixes to govern their interactions.  Working as a cross-functional team throughout the process of developing products simply doesn’t occur.  Instead, work is handed off from department to department and complex processes are developed to manage these handoffs.  If your organization is not committed to cross-functional teams and believes deeply in silos, Scrum has a little chance of helping the organization change.

It’s Just Complicated (Not Complex)

Many individuals in organizations will agree (on paper) that product development is inherently complex and yet their behaviors would indicate that they view software development as being a “complicated”.  What’s the difference between complicated and complex?  The answer to that is probably worthy of it’s own post however I will try to illustrate with simple examples.

A jigsaw puzzle of 1000 pieces is complicated.  Even though it’s difficult and may take hours to finish, there is still only one outcome that indicates that we have solved the puzzle. With study we can determine the best way to solve the puzzle and possibly automate its solution.  On the other hand, a soccer match is complex.  There are many interactions that are occurring and multiple outcomes are possible.

Product development is complex.  Scrum as a framework realizes this and has “rules” and events that are intended to guide work that is occurring in a complex system.  Organizations that spend a lot of time creating plans and then attempt to follow them as closely as possible are treating product development as if it’s complicated.  Organizations that focus primarily on efficiency (over effectiveness) are essentially considering the creation of products to be a predictable and repeatable process.  Scrum will struggle in environments where this is the case.

Culture Matters…

These are just three examples of where the Scrum subculture could be in conflict with an organizations pre-existing subculture. I actually expect such conflicts to exist.  The question is this: Is your organization ready to embark on a cultural change journey or is it wedded to its current culture?  If there is no intention for meaningful change, then it’s very likely that there is nothing with Scrum. On the other hand, there may be something wrong with your organization.  I’ll let you decide that.

What’s Wrong With Scrum?

What’s wrong with Scrum? In my opinion, nothing really. That’s right, nothing.

But Scrum isn’t perfect. Okay, show me what is, please.

But Scrum is missing some key properties. Okay, show me what has ALL the key properties you believe are required for successful software delivery.

But Scrum doesn’t work in MANY situations. You just might be right and I just might agree with you. But does that mean that something is wrong with Scrum? I think not – and I’m not a Scrum defender (even though it seems like I’m becoming one these days).

There are at least a three reasons that I can quickly think of as to why Scrum will NOT work in a given context (I assume you’ll be able to add to the list):

  1. The nature of the work is not a fit for Scrum.
  2. The organizational culture is not a fit for Scrum.
  3. The individual(s) responsible for guiding Scrum adoption are lacking in skill and ability.

In a very unusual turn for me, I want to explore bullet point 3 first, that is, I want to focus on the individual(s). I rarely do this but in this case I believe it to be important, so with that being said, let’s talk about the Scrum Master role.

The Scrum Master Role

The Scrum Guide says this about the Scrum Master:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

But actually doesn’t stop there, it goes on to say the following:

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

  • Finding techniques for effective Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  • Understanding product planning in an empirical environment;
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

I took the liberty to copy directly from the Scrum Guide because I consider this to be important stuff.  (Another good resource is the 42 tasks).

A careful review of this role description hopefully makes it obvious to the reader the vital nature of the Scrum Master role in Scrum.  If you currently serve in the role of a Scrum Master, what does your self-assessment look like taking into consideration the Dunning-Kruger effect? Be honest with yourself. Did you understand what empirical product development was (before you googled it right now)?

I posit that one of the big challenges to Scrum in the industry is the inability of many Scrum Masters working in different organizations to be effective. I might be wrong about this but after working with a lot of Scrum Masters, interviewing many more and participating in online discussions, I believe there is some truth to this.

So why is this the case? There are few reasons in my opinion and yet today I just want to look at three that focus largely (surprisingly) on the individual. (There are organizational factors that contribute to the low degree of skill and ability as well, but those will be addressed in a subsequent post.)

 

The Scrum Master Certification

For a handsome fee and a two-day training session, you can become, wait for it, a Certified Scrum Master. The Scrum Alliance says that: As a CSM, you will be able to fill the role of Scrum Master or Scrum team member.

I am yet to understand how a 2-day training session equips anyone to effectively perform the services required of a Scrum Master (except they were already a practitioner).  I would love for someone to bring clarity around this statement. People tell me that they are going to take the class so they can act in the role. Recruiters present candidates that are CSM’s. Managers look to hire CSM candidates. The services are entrusted into the hands of people who are not qualified to perform the role (but they are certified).

The way the CSM certification seems to have been positioned leads people to believe that just taking the class qualifies them for the role and that there is really nothing much to it. This may not be the intent of the Scrum Alliance, but it is definitely (at least) an unintended consequence. Your CSM trainer might even be good enough to stress what is needed to be really effective and yet I’m not sure that makes a difference to many people. I suppose I could be wrong. My interactions would suggest that I’m not.

As Rob Myers and I discussed the other day:

 

Shallow Commitment to Craft

What’s sad about this point is that I encounter many Scrum Master’s that are more committed to enforcing myths in Scrum (as I pointed out in my last post) than they are to improving their craft and growing in their knowledge. They are victims of a “little learning”. As I asked in my last post, when is the last time you as a Scrum Master reviewed the Scrum Guide? Do you know that the Scrum Master doesn’t actually have to attend the Daily Scrum? How about the Agile Manifesto? What’s the last “people coaching” book you read? How about the last dialogues you participated in on a Scrum forum? How much time are you investing in growing your ability?

Scrum Masters that do not continually evolve their capability actually retard the adoption of Agile in the organization. Facilitating events is only the tip of the iceberg. There is more to the role than meets the eye.  Go back and read the role description again.

If you’re really serious about being a Scrum Master then the Certified Scrum Professional certification may be something you would want to look into.

 

Poor Examples

Albert Einstein is attributed with saying the following:

Setting an example is not the main means of influencing others, it is the only means.

I find that many people feel they can be effective Scrum Masters because of the examples of other Scrum Masters they see around them on a daily basis. Examples that are extremely poor. Examples that suggest that one can perform the role after a two-day training session. Examples that suggest that the role is only about facilitating meetings and removing impediments. Examples that suggest that the role is just another flavor of a project manager (or release manager or…well you get the point).

I’ve focused on the Scrum Master role here because Scrum is talked about quite a bit. I do need to point out however that these observations are not exclusive to the domain of Scrum. I find them quite applicable to Agile (as a value system) and any of its methods and frameworks that are being used today. Hence, this post is not just focused on Scrum and the Scrum Master role.  Its scope includes all Agile Team Leader-type roles.

At the beginning of this post, I presented 3 reasons why Scrum may not work in a particular context. Interestingly enough, an ineffective Scrum Master will not be able to identify reasons 1 and 2 presented above. It disastrous having people who don’t have the requisite skill guide Agile adoption. I’ve encountered many certified Scrum Masters who want to make every thing they do fit into the Scrum framework. For them, they have a hammer and everything is a nail. The inability to take a step back and look at things through the eyes of the system is severely lacking. Sometimes, Scrum is not initially a fit and it’s in the best interest of the teams and organizations to evolve so that Scrum does become a fit. At other times, something else (instead of Scrum) needs to leveraged. The ability to discern and then influence appropriately is critical and yet I find those skills to be significantly lacking in many Agile Team Leaders.

So for Scrum Masters or for those intending to be Scrum Masters (or similar Agile Team Leader roles), take a few minutes to understand the significance of the contribution you are supposed to be making within your organization. Identify where you have gaps and make a conscious effort to address them. Find someone in your organization or the Agile community who can be your coach or guide. Join Twitter and follow some Agile thought leaders. Join one of the Agile groups online. Engage in conversation, debate and learning.

Don’t be the reason people say something is wrong Scrum or Agile.

Sequential Agile Software Development

Is there such a thing as “sequential Agile software development”?  Possibly.  Maybe.  Look at your process.  How many phases does a piece of work have to go through before its complete?  How many (in)formal stages does your process have?  How about sign-offs?  How about handoffs?  Interestingly enough, the hallmark of the strawman referred to as Waterfall is the fact that work passes through different phases in a sequential manner just like a bottle of Coke goes through the bottling process.  Until work is completed in one phase, work in the next phase cannot be started.  Is this how your process works?  Is it possible that you have mini-waterfalls occuring in your iterations? #justasking.

But Eb, product development phases have to be sequential you say.  At least that’s how we were taught. Yeah, I remember those classes as well.  But let’s think about it.  Is it possible (for example) that certain test activities can occur while code is being developed?  Can testing commence after some code is checked in even if the story is not 100% complete?  Can different disciplines perform activties on the same work item in parallel?  Can we challenge ourselves to identify how we can all contribute concurrently to the completion of a work item?  Do we even have these conversations?  Please don’t tell me you won’t know when the work item is ready for you to work on it.  What happened to face-to-face conversation and all its 21st century incarnations?

Classic Agile task boards are famous for having only three phases: To Do, In Progress and Done (or something similar).  The goal is that everyone should be working together concurrently and collaboratively on the items “In Progress”. Phases should overlap such that there is no value in explicitly calling them out because the work item cycles through each phase quickly and concurrently.  Could your team get by with three phases?  If the answer is no, why? How many phases do you need?  Do your phases foster a true spirit of teamwork and collaboration?  Is this an area worthy of inspecting and adapting?

The essence of this post is not to suggest that every team should have only three (or any number for that matter) phases but rather to spur us to take a hard look at how we’re working as Agile team and consider whether our process fosters as much collaboration as is possible or leaves some collaboration on the table.  Are we dependent on handoffs and sign-offs?  Can we only pick up an item after its completely through a previous phase?  Are we really more waterfall-esque than maybe we’d want to admit?  To start and finish together, the team needs to work on the same things together. Take a look at the image below, which type reflects your current process?  Hopefully at least Type B? Maybe Type C?

sequentia_vs_overlapping.gif

Image Credit: The New New Product Development Game – HBR

Do Your Homework

This is just a reminder to myself and the readers of my blog that it is critical to understand the originating domain and context under which new advice/principles/practices being applied to software development came from.  Taking ideas that sound great on the surface and running with them can be catastrophic if those ideas are not well understood as they can easily be misapplied e.g. no testing as a reaction to “ceasing mass inspection” or the blind use of manufacturing principles in software development.  For those of us leveraging Scrum, have you read the original seminal paper on Scrum as a Product Development Game?

I’m not discouraging looking outside the field of software development for radical ideas as I don’t believe the field will evolve if we don’t do so.  Rather, I’m suggesting that we become more accountable in the application of these borrowed ideas.  Let’s understand that our domain is unique in its own way and grow it in a responsible manner.