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):
- The nature of the work is not a fit for Scrum.
- The organizational culture is not a fit for Scrum.
- 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 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.
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.
Ye leave the commandment of God, and hold fast the tradition of men. Mark 7:8 (ASV)
I never in my wildest dreams would have thought I would ever write a post “defending” Scrum especially considering that I’m not a Scrum advocate (ask the folks I work with, I think they’ll confirm that ). Then again, Scrum definitely doesn’t need me to come to its defense and yet I’m compelled to share a few thoughts down – at least for posterity’s sake.
Every week I come across a post indicating why Scrum did not work for a team and how they switched (or evolved as some describe it) to something else. (I come across similar posts on diets and soccer formations as well). First of all, I’m happy that the teams found something that worked for them. I hope that if they wanted to work in Agile-based manner, their new approach allows for that. After all, “we are uncovering better ways…” aren’t we?
However, I find it irresponsible for these people (and other Agile thought leaders) to blame Scrum for certain things that occur especially when these things are really not Scrum things. It’s important to remember that Scrum is a framework that needs to be filled out if software is actually going to be developed and delivered. Scrum, via the Scrum Guide, doesn’t provide much (explicit) guidance on how to actually develop and deliver software. It provides a framework for managing the software development process.
Before you begin to debate this with me, let’s simply agree that the Scrum Guide is the official definition for Scrum. In my opinion, any other text on Scrum is the author(s) description of how the framework was implemented and what additional techniques or practices were found beneficial as the framework was leveraged. Unfortunately, some of these techniques (promoted by Agile and Scrum thought leaders) have over time become characterized and adopted as Scrum rules when they are really techniques used with Scrum. They are traditions. Let me provide a few examples.
Scrum currently says nothing about how estimation should be done and yet it would seem that Story Points estimation is considered THE Scrum estimation approach.
Scrum requires that a “potentially releasable product increment” be created by the end of the defined time-box. I don’t see anything in this requirement that prevents a team from releasing sooner if both they and their customer can handle it. I also find this supposed limitation to be a bit hilarious. I mean, it wasn’t it but a few years ago that many organizations were struggling with delivering software more than one time a year!
Is this in the Scrum Guide?
These days it’s become quite chic to state that instead of focusing on the individuals doing the work, we should focus on the work itself. In other words, focus on the baton, not the runner. The criticism of the Daily Scrum then is that every day, it’s the same (paraphrased) three questions that are asked:
- What did I do yesterday?
- What do I intend to do today?
- What impediments do I possibly have?
Unfortunately, these three questions (while represented in the Scrum Guide) are removed from the larger context for which they are a part of. Here are the first two lines of this section in the Scrum Guide:
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.
In fact, if you are interested, take the time to read that section (and the entire Guide) on your own. Tell me where it requires you to “stand up”!
These are a few examples of things I often read people say “Scrum made them do…” So is this a post to convince you to use Scrum? Nope. First of all, I don’t believe it’s always a fit for the type of work a development team might be doing. Secondly, context matters and depending on your context (of which I have no idea of), something else might be better. However, I will challenge you to read for yourself what the rules of Scrum are so you can separate those rules from the traditions of men and make informed decisions. Study to show thyself approved.
When I have these conversations in social settings, its suggested that the Scrum Guide has changed over the years. When did change become a bad thing? What happened to inspect and adapt? Show me a method or framework that doesn’t evolve and I’ll show you a dead method or a dead framework. The real problem is that many (maybe even most) Scrum Masters that I interact with don’t evolve beyond what they may have learned in their 2-day CSM course 7 years ago. Ask them the last time they actually looked at the Scrum Guide or how many Scrum books they have read. The answer is often quite disturbing and disappointing. (By the way this point extends beyond Scrum and into Agile (as an approach to software delivery). The cargo-cult behavior of people who promote “inspect and adapt” can be quite disappointing). Don’t even get me started on managers who try to impose Scrum (or any other Agile approach for that matter) in their organizations without having a clue.
Scrum is a framework that your team can leverage (if it’s a fit) to develop and deliver products in an Agile manner. It’s not perfect because nothing really is. There is no silver bullet and that includes your new approach as well.
I’ve recently spent a lot of time thinking about the notion of respect and its importance in social settings.
How would our interactions be different if respect was present when we engaged? For example, if we intended to respect all the participants in a meeting, would we still dominate the meeting with our own opinions or would we share the floor with others? What if a team member wasn’t performing at a high-level? Would we take the time to try and understand what was getting in their way?
Because I’m actively involved in Twitter dialogue, I’m often saddened by conversations that become “insult parties” when people cannot agree. As I recently tweeted:
Respecting each other doesn’t mean we have to agree on everything and anything. In fact, that would probably be unhealthy. For example, there are a few people in my Twitter circles who have suggested that we redefine Agile or move beyond it to something more “modern”. I disagree with some of these thoughts (and that’s substance for a subsequent post) and yet I still respect them and respect the fact that they have that view even though I don’t agree with their opinion.
Respect (in my humble opinion) is even more critical when an individual is involved in cultural change (change management) initiatives. As an Ibo boy growing up in a Yoruba community, I learned at an early age that taking the time to understand the differences in the cultures was an important form of showing respect. If I wanted to be able to influence, I needed to respect (even if I didn’t agree). Later on in life, I was introduced to the famous Stephen Covey maxim:
Seek first to understand, then to be understood.
(What should we do when we’ve totally lost respect for an individual or group of individuals? I’m curious to get your thoughts.)
Being respectful of others can be especially challenging in certain circumstances. Let’s keep trying.
It’s amazing how the most innocuous statement can get the mind racing. One of my teammates went to a Lean Coffee meetup here in town and when I asked how it was she simply gave me the phrase “dual track Scrum”. It had been a while since I’d heard someone mention dual-track Scrum or dual-track Agile. Hearing it again got me thinking about its implication to Agile software development. (Thank’s Rose).
In case you are not familiar with the concept, read Marty Cagan’s article on the subject. For the record, I’m a big fan of a lot of Marty’s stuff. In a nutshell, dual-track Agile is characterized by a Discovery track and a Delivery track that run concurrently. The Discovery track is focused on generating good backlog items (probably meeting teams definition of ready) while the Delivery track is focused on developing and releasing software. The output of the Discovery track is input for the Delivery track.
Dual-track Agile is implemented by many Agile teams in many different ways. Some teams just have a single role on the team creating validated backlog items; others employ an approach similar to the “3 Amigos” where multiple prepare the next set of backlog items to be worked and some scaled Agile approaches have a completely separate team responsible for creating validated backlog items. My least favorite approach is the approach that has been popularized by some scaled Agile frameworks.
So why do teams practice some form of dual-track Agile? It’s to prevent the delivery track from spinning on backlog items that are to be worked on next. I liken it to a scout or advance team going ahead and preparing a campsite for the rest of the team so that when the rest of the team arrives; it can focus on setting up the camp (instead of clearing brush, fetching water or getting firewood).
Agile Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile software development is characterized by regular feedback from customers (stakeholders) as feedback guides the team on what to work on next based on what has everyone has learned from what has been delivered. This is why principle number 1 is so important. Often people see it to be important only from the perspective of getting something into the customer’s hands. This is true but incomplete in my humble opinion. An additional reason why we want to deliver valuable software early and continuously is so that we can learn what really needs to be done next.
If our backlog is largely ordered independent of customer feedback then our team is not exploiting all that Agile software development has to offer. Our goal has become to get through our backlog as quickly as is possible – some may consider this to be a project. Value has largely been predetermined upfront. Some may argue that Agile doesn’t make sense for us if we’re working in this manner while there may be some truth to this, I wouldn’t advocate abandoning everything Agile if a team finds itself in this situation. We may just need to make the best out of the situation while realizing that there is a huge aspect of Agile software development that is not present in the way we work.
The output(s) of the [Sprint] Review (or similar practices) are supposed to serve as meaningful input into the [Sprint] Planning process subsequently guiding the team on what it should work on next. For example, the Scrum Guide states the following:
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
If your teams [Sprint] Review do not serve this purpose then [Sprint] Planning is largely pre-determined based on other factors that most likely do not include customer feedback on what has been delivered.
If as a team we are pretty sure on what we will work on next before completing what we are currently working on, dual-track approaches might prudent. They will probably reduce (what is correctly classified as) waste in the process and improve our cycle times. However, there is the danger of operating in a “waterfall-like” manner with handoffs especially if another team is responsible for creating validated backlog items.
So here is my question for us. If you are thinking of using dual-track Agile, why do you think it will work? Is frequent customer feedback guiding what the team works on next or do you have a backlog of items with the order of delivery largely predetermined and the team is just making its way through the list as fast as it can (showing progress as it goes)? Is this what it should be? Is this the best it can be? What do you think it should be? How do you intend to change things? Can you?
Remember that “a little learning is a dangerous thing”. Progress is dependent on the unreasonable woman or man.
Recently I was featured on the Scrum Master Toolbox Podcast.
Check it out: http://www.scrum-master-toolbox.com/?s=ebenezer
Over the last 48 hours, I’ve been engaged in some #NoEstimates conversations. A tweet this yesterday evening re- introduced a very interesting dimension to the conversation (at least in my opinion).
What risks are we possibly concerned about here? I can think of two related to the actual process of software development and one related to the people actually doing it, so in all 3 major risks (even though I wouldn’t be surprised if there are others):
- Risk of team not developing the right thing
- Risk of team not delivering on time
- Risk of team not doing their best
Getting It Right/Being On Time (Value 3, Principles 1 and 4 at least)
It is my experience that software development is largely non-deterministic and empirical. YMMV. (If this is not your experience, I’d love to hear about it and the software you develop). There is a significant amount of learning that occurs as the work is being done. Just pull any developer off any team and ask if they “figure things out as they do the work?”. I’ve been developing software long enough to remember a number of approaches to software development that tried to front-load learning via the use of documents and models of other forms. We still found ourselves learning a lot as we actually typed lines of code. We can debate ad nauseam as to whether our discovery process was broken and I imagine there are those who simply say that we should just get better at identifying and writing requirements. There may be some truth to that, but I’m positive it’s not the only way.
Agile as an approach to software development desires to exploit the uncertainty and learning that is inherent in software development. This post is not an Agile primer and yet a meaningful study of Agile methods/frameworks shows that the first two risks are actively being addressed all the time as the team works together to deliver working software. Remember the team includes the paying customer. They are part and parcel of managing the first two risks as we go along. They are part of actually providing a solution. If the customer is not heavily involved in the development of the solution, and yet wants a guarantee around the first two risks, then you may need another approach that lends itself to such an engagement – I’m not sure Agile is it?
So this puts us in the land of contracts. By contracts I am referring to any agreement (verbal or written) on what is going to be delivered and when it is going to be delivered – think funding models as well. When a team commits to delivering X scope in a period of Y, a contract has just been put in place. The nature of the contracts ultimately impacts the behavior of your teams, which impacts how software is truly developed. But we know contracts don’t guarantee results (think about all the prenup’s that have gone by the way side), they guarantee (maybe) a course of action when things go wrong. They can be an indicator of low trust.
This is an opportunity to go read up on what Agile contracts look like (there is no shortage of resources on this topic). But the essence of many of them is that the buyer makes small bets while remaining part of the team. Do they often bear a larger percentage of the risk? Possibly. They often reap a larger share of the reward as well. What they don’t do is handoff a problem and say “see me when you’re done”.
If you thought that software development happens in a bubble, you were mistaken. There are multiple organizational conditions that influence it directly and indirectly. It’s not just something that those technology guys and gals are doing. Agile software development is disruptive to the “normal” way of working. It requires the investor to be part of the team in some form or fashion.
Having a Committed Team (Principle #5)
Ok, so maybe I can leverage Agile contracts for work that is outsourced but what do we do when the team is part of our organization and is salaried? We could be paying them and not getting results. Well, this leads us to risk 3, the risk of the team not doing their best or to put it more bluntly, not being committed. While we can definitely focus on getting the team to comply with internal contracts and similar instruments (such as threats), things are not often what they seem to be. Metrics and efficiency numbers that show a team is “working hard”, “improving” or “getting faster” are not a true indicator of a teams commitment. Maybe they are an indicator of compliance, maybe. (If compliance is good enough for your organization – Agile is probably not a right fit). Leaders who are looking for what they deem to be “tangible” stuff should really be focused on how much value is being created and generated.
Here is a formula for committed teams: Hire great people, create cross-functional teams, give them meaningful work, share with them how their output as a team will make a difference, tell them about important dates and budget and then let them loose. Support them by providing enabling conditions that allow them to excel. Follow’s Drucker’s advice; see them more as volunteers than anything else. This requires you to discard your Theory X approach to management. It requires you to actually trust them – if they are committed they’ll share in the risk as well.
Manifestos and Things
Take a look at the Agile Manifesto (I’m sure you can find it). If you look at it carefully you’ll see that this post has gone over some of the Agile values and principles. This, to me, is what software development guided by the Agile Manifesto is all about. It’s not just about standups, backlogs and story points. In fact, I consider those important but lesser. It’s about a particular culture of developing software. Any method that consistently demotivates or disempowers is not Agile. This is at the center of the #NoEstimates dialogue in my estimation (excuse the pun) – the culture of software development and hence the engagement models that arise as a result of the culture. (Sidebar: I find myself continually saddened by Agile leaders in organizations and consultants who don’t get this and still claim to be leading Agile transformations. They are doing more harm than good). Agile is not mandatory, it’s choice.
In Agile software development, the risk is shared and mitigated by everyone involved (including the investors) by working together in an Agile manner with a committed team. This may or may not work for you – it does not however mean that it is not an option (or the only option).
(I really should be at the piano but I find that there are few things on my mind this morning).
I find myself engaged in my fair share of conversations around accountability in various settings – particularly the Western world’s spin on it. That is, who can we hold accountable when something goes wrong? As I’ve blogged in the past, I personally think that individual accountability for team outcomes is a bit misguided. Debating “who gets called in the middle of the night” is truly missing the point. If you structure your organization in a manner such that individuals are solely accountable for team outcomes then don’t be suprised by the behavior that follows.
(As a leader, you are first and foremost a system designers and influencer. Don’t forget that.).
However, I do wonder what would happen if leaders spent half the time they spend debating who is accountable, actually promoting individual and team ownership in their organizations. Do individuals and teams feel ownership over their work, processes, techniques and outcomes? Or do they feel like their stuck simply following instructions? A means to an end? It’s not enough to simply talk about it, we need to intentionally create the conditions that actually support ownership at all levels.
Does your organization have a culture of ownership? What would a random survey show if you asked that question within your organization? How much time is spent discussing what needs to be done so that individuals and teams actually take more ownership? Nothing is a panacea and yet low ownership levels leaves a lot on the table.
Let’s focus more on a culture of ownership, maybe it’ll address our accountability problem.
(Now off to the piano…)