Scrum Masters as Subject Matter Experts

A question I come across often is whether or not a Scrum Master (or for that matter an Agile Coach) should have extensive knowledge in the business and/or technical domain in which the team they are working with is engaged in. I find that many people believe the Scrum Master should be an SME or else they will not be able to provide any (or as much) value to the team they are working with. I find just the opposite is true. When a Scrum Master is a knowledgeable expert they tend to engage in command and control activities even though they are often exceedingly nice about it. They tend towards telling the team what to do and how to do it vs. being exclusively focused on how well everyone is working together (including the organization around the team and with the customers, stakeholders, etc.). There is no doubt that a Scrum Master who is a domain expert is going to be able to give some constructive input however they are also at a high risk of giving destructive input, input that erodes the team’s ownership of their work or undermines the Product Owner’s authority.

The role of Scrum Master is utterly unique in corporations. There is no other role quite like it and I find that those who excel at the role (and hence work with teams that excel in their roles) focus on how each individual is doing and how the team is doing together. They are focused on the personal and interpersonal dynamics which lead to great work, each individual giving their all to the team and the team giving their all to the product. Being agnostic about the nature of the work itself, they allow themselves to focus on the people and the organization, on removing and resolving and escalating impediments at the team level and at the organizational level. They get to focus on the culture and the values and principles that drive it. Instead of the ‘what’ or the ‘why’ or even the ‘how’ of the work, they are simply focused on ‘how well’ it is all going, and this focus is invaluable even though at times it seems invisible. Without someone focused in this way, the team just has one more contributor who may or may not be truly adding value, they may even be taking it away.

So my recommendation is always to look for the right people to be Scrum Masters, those with the characteristics that will truly drive the team forwards towards perfection (even though they will never reach it), and someone who can help drive change in the larger organization. For this is where the true value of the Scrum Master lies, not in domain expertise.

Dealing With Ambiguity

One thing humans seem to have a challenge with is being comfortable with the unknown. Waterfall project management gives one the illusion of certainty, that you can know what you are going to get and when you are going to get it at the beginning of a project. Scrum comes from the opposite direction. It asks you to admit that you don’t know at the start, but that you will learn as time goes on.

Waterfall’s illusion of certainty starts to dissipate almost as soon as it is established and generally is blown away over time. Near the end of a waterfall project there is a metric ton of anxiety and ambiguity about what exactly will be delivered and when it will actually happen.

Scrum starts out completely uncertain about what will be delivered when and sprint over sprint gets more and more certain about what can, will and should actually get done and when it is going to happen. By the end of a Scrum project, everyone is so certain it is almost anti-climactic what will happen with the final releases.

I much prefer the way Scrum learns over time what reality will be versus Waterfall’s assumption it knows everything up front. Scrum deals in reality while Waterfall deals in fantasies, which much more often than we would like to admit, never come true.

Scrum Without The Agile Manifesto

Even though Scrum was created before the Agile Manifesto, today, I do not believe Scrum truly works to its fullest potential on its own without also adopting the values and principles of the manifesto. All four of the values need to be in place to do Scrum really well, even if you are not conscious or conscientious about that fact, the fact remains, the best Scrum teams have the four values in place.

The same can be said for the principles. None of this is surprising of course since the creators of Scrum were also all signatories/creators of the manifesto itself. It actually seems to me that Ken Schwaber, Jeff Sutherland and Mike Beedle did the job of fleshing out the Scrum values and principles when they helped create the manifesto. The Scrum values are good, but for really successful teams they include the manifesto values. The Scrum principles are good, but again for really successful teams they include the manifesto principles.

If you do Scrum without the manifesto values and principles, you still get a kind of Scrum that works. It will probably work better than what you were doing before, but you will be missing some key ingredients that can make Scrum teams really soar into the stratosphere. My main point is that I would love to see some future version of the Scrum Guide actually reference the Agile Manifesto as a source for material critical to Scrum’s success. It is nice to imagine, even though I have no power to do so of course.

When I teach Scrum, I teach teams the manifesto first, always. When I mentor Scrum Masters and Agile Coaches, I advocate the manifesto as much, if not more, than the Scrum guide, at least as the source of truth for what is or is not Agile. These are two great things that are greatest together; they become more than the sum of their parts and truly define some of the best teams I have ever worked with. I hope others recognize the combination as well.

Whose Foot Is On The Gas?

I have heard Scrum criticized for encouraging/supporting an unsustainable pace of development. Partly I blame nomenclature. Scrum calls each iteration of development a “Sprint,” and this just brings to mind a race to the finish line. It is built into the definition of the word “an act or short spell of running at full speed,” and even one of Scrum’s creators Jeff Sutherland consistently quotes statistics like a team achieving a 400% increase in productivity using Scrum.  All of this combined with over-zealous managers, Product Owners and a general urgency to get things done can lead to teams believing that Scrum is just an endless race, a head’s down sprint that never ends until everyone is exhausted or quits.

In practice this is not only not true, but it is not Agile (as defined by the Agile Manifesto) – “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

A constant pace indefinitely, this means a reasonable pace, this means a work/life balance pace. This means a pace where people can think about things and do the right thing the right way.  This is the opposite of the “death-march” waterfall method, the opposite of burning people out and burning people up. But in Scrum, who is ultimately responsible for setting this pace? It is never stated explicitly, but it is without question implicit in the following statement from the Scrum Guide, “The Development Team works to forecast the functionality that will be developed during the Sprint.” As well as, “The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.”

There is no question in Scrum that it is entirely up to the development team how fast they work. Their collective foot is on the gas pedal, they set the pace. Now of course you can argue that there can be pressure put on them by outside forces (including an unenlightened Product Owner or Scrum Master, managers, executives and other stakeholders), but in the end, if a company wants to do the right thing, they need to respect the pace set by the team, and the team needs to set a pace they can sustain.

To do anything less is less than Agile.

The Hardest Part of Scrum

Scrum as a framework is simple to understand and can be challenging to implement well, but it is easy to implement the structures. What is difficult with many teams is instilling and living by the values and the principles of the Agile Manifesto and the Scrum values. What is hardest, what is truly challenging is helping a company culture to change from one of command and control to one of empowering teams to work it out for themselves and to align with customers and the business on their own. What is hardest in Scrum is not scrum itself but the culture around Scrum teams. Teams get it quickly and are aided or impeded in their journey by management and corporate culture and whether or not they are truly on board with the values and principles which can fly in the face of how things have “always been done around here” and challenge micro-managers and command and control minded people at every level of an organization.

It is the very idea of a corporation that needs to change: how one is run most successfully, why one is run at all, what values and principles does the company possess as a whole? That is the biggest challenge of Scrum. Companies embrace values and principles either implicitly or explicitly. They may not be (in fact they often are not) the ones they have outlined as aspirational in their employee handbooks or signage. I find cultures to fall into one or another main category, trust or fear. Trust is at the heart of any Agile company. Fear is at the heart of any command and control culture. How do you migrate from one to the other? You hire for trust, you promote trust, you trust yourself, by which I mean you demonstrate trust yourself and you are trusting. I do believe that people can change, but I do not believe that companies can often change them. In those cases you may truly need to hire and fire your way into a culture of trust, a culture that supports Agility. I think you can try to educate, try to coach and encourage, but at the end of the day if you cannot change your culture, you will have to change your people. You will have to find the right people to build the explicit culture you desire. Scrum cannot help you with that, it can only start to reveal the problem. That is the hardest thing about Scrum.

What Does Commitment Mean In Scrum?

I have learned many things in my journey with Scrum, and I continue to learn on a daily basis even after 15 years of practice with it. Scrum is simple but deep and the lessons I learn make me a better Agile Coach and Scrum Master. One of the things I have learned over the years was what commitment means in Scrum. I used to think it meant the team committing to get the full scope of work done during a sprint, that it was about a promise to get everything done. This was just wrong of me and a hold-over from my command and control days as a project manager. It was a remnant of the illusion of certainty that waterfall fosters. It was at its heart a fear reaction to the uncertainty of the sprint backlog. I had the idea then that commitment meant taking the work in sprint chunks and promising to get each one done instead of the whole, and that this was progress. The reality was that I figured out that the sprint backlog is just as emergent as the product backlog and just as uncertain. There is no way a team can commit to the sprint backlog and no reason that they should.

The team commits to many things but the sprint backlog is not one of them. The team commits to the sprint goal, they commit to their definition of done and applying it to all of their work. The team commits to the rules of Scrum and the values of Scrum and the principles and values of the Agile Manifesto. The team commits to doing the best job they can. They commit to learning. They commit to teamwork. These are powerful commitments, and they are commitments to each other and themselves. Scrum does not function well without commitment to these things, and you can tell the health of a team by their level of commitment to these things. Commitment to the scope of the sprint backlog is a fool’s errand, and I am happy that I learned this and sad about the teams I worked with before I learned this. I am not now nor will I ever be perfect, but this does not stop my reaching for perfection, does not stop my commitment to continuous improvement of myself. I take my commitments to these lean and agile values seriously, and so I keep learning and growing and hope I never stop.

The Perfect Scrum Master

Let me start by saying I am not the perfect Scrum Master, nor have I ever met one. I do however have the ideal in my head and I think that ideal is worthy of pursuit. For myself, this ideal is what I aim to be, how I measure myself as an enterprise Agile Coach and Scrum Master when I am filling that role.

The perfect Scrum Master:

·        Knows the Scrum Guide, backwards and forwards because they know that this is what Scrum is and maybe even more importantly for many companies, what Scrum is not.

·        Lives the Agile Manifesto values and principles. Can quote them to a team when they are following them and when they are not. Internalizes the values and principles and demonstrates them constantly in their thinking and behavior.

·        Is a true servant leader according to Greenleaf’s seminal essay “The Servant As Leader”. Embodying the principles they espouse.

·        Is technical enough to understand trade-offs and to have the respect of the team that their work is understood at a fundamental level at least.

·        Has enough business sense that they can communicate effectively with all stakeholders in the team’s success.

And that is about it. Not that much to ask is it (sarcasm)? If you know anyone who fits this bill please send them my way because I need them in my network, I hire a lot of Scrum Masters and have yet to find the perfect one, but anyone on the path described is close enough to merit hiring.

Stop Starting and Start Finishing

It is widely understood that when you multitask, you do many things poorly versus focusing on a single thing and doing it well. I believe it is just how we are built as human beings and especially how teams are built. Scrum teams should be able to focus on a single product at a time. If teams are allowed to do this, you get all the benefits of collaboration (teamwork) without the inherent loss of productivity in context switching between more than a single product in a sprint, or the loss of team work when team members are split up and thinking about and working on multiple products.

This is not Scrum.

I see too many teams faced with this situation today, Product Owners and organizations unable to truly prioritize between products, too afraid to say “no” or at least “not yet” to stakeholders or even customers. To be fair, it is often not the Product Owner I see at fault, it is the executive stakeholders who are unable or unwilling to prioritize between products and are instead committed to trying to keep everyone happy by being able to say that progress is being made when in actuality progress is being slowed across all products in favor of being able to say they are being worked on. 

It takes some courage for executives to protect teams from this type of situation. It means someone will have to wait their turn, but it also means when it is their turn they will see rapid and competent progress, and they will get the team’s exclusive attention and the best of all minds working together on it.

When teams work on multiple products at the same time their productivity is eviscerated, and even if Scrum can be adapted to this situation, it does not mean it should be. Make people wait their turn or spin up more teams if you cannot wait. Don’t dilute the power that a focused team brings to product development, don’t hobble their productivity and creativity. Be brave and focus. You won’t regret it.

WIP Limits in Scrum

Don’t call it Scrumban but using WIP limits both on your workflow board and overall points (assuming you are using story points) in progress can help a team manage their work more effectively, especially if they have been struggling to achieve a smooth burndown of work on a regular basis. I have worked with a number of teams who have struggled with “burn-across” rather than being able to show a smoother sprint burndown of work during a sprint. I believe this is a serious issue because it indicates “waterfall thinking” (thinking you have to have work in progress in order to manage expectations of stakeholders or whomever is interested in the work of the team). This is also an issue because without a good burndown (or some other way to sum the remaining work in the sprint), the team is flying blind on whether or not they are on track to hit their sprint goal. WIP limits have many benefits and a smooth burndown is just one of them.  What I like best about WIP limits in Scrum is how it increases team communication about the work and helps the team to more actively manage themselves. 

With a tool like Jira you can easily configure WIP limits by column on a board in active sprint view. On a wall, a big red number for your limits at any step in the workflow is one of my favored ways to show it. In any case, make it big and visible and easy to see how close to the WIP limit you are. I also recommend some education for the team before establishing WIP limits, like the benefits of using them, the benefits of slack time, the benefits of self-management etc. Used properly and preparing the team ahead of time, WIP limits can be a powerful tool to increase team productivity.

Workflow Boards

I think something is lost when we use a digital vs. a physical workflow board in Scrum. One of the things we lose is an instant view into how the sprint is progressing. There is nothing like a well-organized and up to date board for showing you how things are going, how close or how far away the team is to achieving the sprint goal. It is the ultimate and the original information radiator. Most digital tools, and especially the most popular one these day (Jira), just do not have a good view of the whole board that is as easy to take in (in its entirety) or drill down to detail as a physical board. Jira gets lost in swimlanes and other “features” that make viewing the whole board at one go impossible unless you have a gigantic monitor. But this is just one of the things that is lost.

Another, and perhaps more important, loss is the centralized sense of community that a physical board brings. As team members move their stories across a board, they talk to each other. They can all see the whole board and take it in while they are focusing on moving their own work.  They meet at the board, they talk at the board, they plan at the board. There just is no comparison to it digitally.

When you have a physical board, you do not need to worry about a sprint burndown. You can see it in front of you every time you look at it with no additional effort. 

I could go on, but I am sure I am starting to sound like someone railing against photography over oil paintings and am in danger of making myself sound out of touch. But that is exactly my last point, touch. The visceral feel of moving work across the board is satisfying, much more so when planting something in the “Done” column vs. a few mouse clicks.

The only real reason why physical boards are out of favor in the industry is the prevalence of geographically dispersed teams, which is a subject of a later post, but I bet you can guess how I feel about those too.

Roles In Kanban Continued

Roles in Kanban Continued

My last post about roles in Kanban mentioned two roles, Flow Master and Product Owner. I spent some time talking about Flow Master but now would like to talk about the need for a Product Owner.

Kanban (in my view) needs a Product Owner role. It needs someone who is overall responsible for the “What” the team is being asked to do: for defining it, for prioritizing it, for working with customers and managing stakeholders. Very similar to how Scrum has this need, I believe any team doing the Kanban method has this need. In “The Essential Kanban Condensed,” David J. Anderson and Andy Carmichael as much as admit this themselves. I think this is authoritative!  David admits he had someone playing this role on all of his Kanban teams and will not come out and say it directly, but I will. This role is required. Without one person (not a committee) making priority decisions, making definition of “What” the team is doing clear, the team will not be successful. I would model the Product Owner in Kanban directly after the Product Owner in Scrum. 

Along with the role of Product Owner comes some events. The backlog or queue needs to be replenished, and I believe this should be a team based activity led by the Product Owner. I also believe there should be a regular demonstration of what the team is doing for stakeholders and this is going to have a lot of similarity to a Sprint Review in Scrum. If you are just doing Kanban and not Scrum then I would call it a Team Demonstration or something similar. However, I would strictly follow the same pattern as a Sprint Review in all aspects just adopted for Kanban (no time-boxes).

It may sound like I am advocating for a combination of Scrum and Kanban, but I am not. While I do advocate for “Scrumban” if you are going to do Scrum, you may as well adopt the ethos (values, principles, practices) of Kanban anyway. You have nothing to lose and everything to gain. I do believe, however, that there are plenty of scenarios where Kanban is appropriate and Scrum is not, and there I believe that Kanban needs to borrow from Scrum all the practices it lacks to become a fully-fledged framework instead of just a change method that you add to an existing process. I believe Kanban needs to grow up and learn to stand on its own, and to do that, it needs to adopt some roles and events (learning from Scrum) so it can become what its great potential is when it is done well.

Roles In Kanban

My last post about Scrum vs. Kanban got me thinking about how fast Kanban is growing up (in the short decade + that it has begun being more widely adopted in software development and knowledge work generally). One of the tenets of the Kanban method is to respect existing roles, job titles, etc., and Kanban says it introduces no new roles as you use it. This, however, is starting to change. Even David J. Anderson, one of the pioneers in the Kanban method, is being forced to admit that Kanban needs two specific roles. He suggests a lot of names for them, but I will pick my favorites: Flow Master and Product Owner. I like these two because they borrow heavily from Scrum, which is fair because I think that Scrum has informed a lot of the development of Kanban as a change method, and I see the similarities and the differences, but primarily I see how they inform each other.

Flow Master is a role I believe is truly needed and someday Kanban will have to admit it formally. Someone has to be and feel responsible for flow through the system, someone has to “own” it even though the whole team is responsible. I like Flow Master because it implies all of the other responsibilities of a Scrum Master only applied to Kanban, but since you can do Kanban without Scrum there does need to be a separate role. It does beg the question what if you were doing both, (Scrum and Kanban) together; would you need a Flow Master and a Scrum Master?  My answer would be no, it would be the same person but it would broaden their responsibility and better define their role. This does bring up another question about Kanban. Today, Kanban says there are no particular meetings or events/ceremonies associated with Kanban, but again, I think this is naive and will not bear out over time. I think Kanban as it grows up will adopt a few formal meetings, one of which will certainly be a retrospective similar to Scrum’s. I won’t go into all the formal meetings or the other role yet, I will save that for a later post. Suffice it to say for now that Flow Master is a needed role and each team may need to define what that role is responsible for today, I hope that Kanban becomes something that “formally” adopts the role of Flow Master who has as part of their responsibility facilitating a regular retrospective for Kanban teams.

Scrum vs. Kanban

I see a lot of chatter about Scrum vs. Kanban on the internet in general and think the debate is misguided. You can do Kanban with Scrum (whether or not you decide to call it Scrumban), and Kanban itself is not a process or a framework that compares to Scrum. Kanban is a change process that you implement on top of whatever established process you already have in place. If that is Scrum, it is still Scrum. If it is any other kind of workflow or framework, it is still that. My favorite description of Kanban so far is that it is a lens, a lens that you see what you are currently doing through, whatever that is.

Just using a Kanban board to track your workflow is not Kanban.  Terminology is important and I like the term “Kanban Method,” which necessarily includes the values, principals and practices of Kanban not just using a board to track your work. Kanban comes from Lean and Lean is all about eliminating waste. So any time you are truly using the “Kanban Method” you are also relentlessly focused on reducing waste in your work. Kanban has at it’s core a need to create “Kaizen Culture” in the company that uses it. Kaizen Culture and Agile (as described by the manifesto) share some interesting components, values and practices as well. Which brings me to the true vs. debate. Are you Lean and Agile or just one or the other? I personally believe Lean and Agile are best together and are not in opposition at all. They are nicely complimentary and at some future point I may post about that in particular. It is enough for now to say that Kanban vs. Scrum should not be a debate. It really is two questions: Are we going to do Scrum? AND Are we going to do Kanban? And in my view both are best. Although, sometimes Scrum just won’t fit, Kanban always will because Kanban is a change process not a framework.

Take It To The Team!

In order to truly reap the benefits of Scrum and Agile, there is a simple practice that I have learned from others which is invaluable. It is simply to not try to solve all the problems for the Scrum team, take the problems to them for solutions! Too often I run into Product Owners and Scrum Masters who are shaken because they cannot figure out how to resolve something for the team. They have racked their brains, pounding away at a problem and cannot find a solution for the team. Instead, I often suggest to them, take the problem to the team, see what they can do with it. You might be amazed (because they can solve the problem), you might be frustrated (because you do not like their solution even if it works for them), but you will not be disappointed at the short and long term effects of empowering the team to solve their own problems and even to answer their own questions.

It is now my first reflex but it wasn’t always so. It takes practice not to babysit a team, not to try to take care of everything for them, so they can just get the work done without worrying their brains about problems like MVP or how to deal with UAT or who knows what…

Take it to the team, bring them the problem and see if their collective, emergent wisdom doesn’t come up with an answer to the issue (even if you don’t like it) that works!

The Two Greatest Challenges With Scrum

All things being equal, everyone is on board with Scrum from the CTO to the janitor, and your company is functional (as opposed to dysfunctional) as all get out. There are two major challenges I see every team face to a greater or lesser degree, sooner or later. The first is simply MVP. I won’t go into the whole Skateboard through sports car metaphor, (which is awesome but not my point) I mean just simply building one slice through the application or data process or whatever it is you are going to build. One slice through it to provide some value to the end user, to the customer, so they can get something right now which you will then iterate on and incrementally build out for them until it is everything they ever dreamed of. This is a very hard transition for many teams to make in my experience. They want to design everything up front and deliver it all in a big bang and often cannot really imagine what delivering the skateboard would look like or why the customer would want it. Once they finally get it (and this happens only by doing it for the first time), it becomes a great revelation, a new way of thinking and doing that they never want to return from ever again. Once they are on the other side of this monumental change they cannot imagine ever doing it the old “big bang” way again.

The other major challenge is user centered thinking, taking the actual view of the customer of whatever they are building. This is in every sense one of the harder shifts to make in everything from how to write user stories, to simply how to look at everything they are doing from the standpoint of who they are doing it for. This is a seismic shift! It is not an easy thing to do. I often refer to it as the “broken brain” moment where new synaptic connections form and people look like dogs who have just heard a baffling sound with their heads cocked to the side. I once worked with a very large team (6 teams working together actually) on a process redesign. There was a moment where they actually turned as a group from thinking about things from their company’s point of view to the point of view of a user of the process and it was like a silent “whumph!” where everyone collectively and suddenly realized the implication of what their actions as a company meant for a user of their process. It was a revelation.

I love these two moment of realization. I live for them when working with new teams, and once they get these two things, suddenly, you have a real scrum team, one that is in tune with the Agile principles. A team that is in tune with their users, and once there you can never go back.   

Two Kinds of Scrum Master

There is the kind most people look for today. You can see help wanted ads for them everywhere; they are the Scrum Master/Project Manager. This is a symptom of how far Agile has come and how far it has yet to go.

These are not real Scrum Masters, they are Project Managers in disguise. So many people cannot imagine not having a PM, not having someone perform the PM function that they conflate the idea of the Scrum Master with a Project Manager. Speaking as someone who has been both, these two roles are not at all analogous. Scrum does not use Project Managers because it doesn’t need them. Yet so many companies I see today that think they are “going Agile” are hiring this combination of SM/PM. All I can say is that if you are combining those two roles, you are not doing Scrum. You may think you are, you may have all the window dressings of Scrum, but you are not doing Scrum, and the likelihood that you are Agile at all is very low to non-existent. The two roles are like matter and anti-matter; they cannot exist in the same space, much less the same person, or the universe will implode.

Conversely, if you see a help wanted ad for a real Scrum Master, you are going to see some reference to the Scrum Guide, to the Agile Manifesto principles, to removing impediments, to team morale, to servant leadership. You will not see references to project plans or Gantt charts. I see many, many help wanted ads for Project Managers and precious few for Scrum Masters. They stick out like diamonds in the rough. They are written with passion and feeling. They appeal on an emotional level where the cold dead PM job description should be dead and gone in my view, at least when it comes to software development. Until this happens, Agile may have “arrived” and hit a kind of critical mass, however, there will still be work for me and others who are on fire with the values and the principles of Agile to come in and attempt to clean up the mess left by those who cannot (or will not) tell the difference.

Agile Adoptions vs. Transformations

Currently, I work as a Scrum Coach for both teams and organizations, and there will be work along these lines for many years to come for the simple reason that adopting Agile, and specifically Scrum, is easy to do and easy to do poorly and in name only, which is what most companies unfortunately do.

Agile and Scrum together are truly transformational approaches to getting work done. Merely adopting the practices into a slowly moving business/bottom line focused company is not enough to transform the company or their culture as Agile and Scrum actually demand. Without transformation, the adoption of Scrum will become mere paint on top of a waterfall world of project management, and it will fail. When the company tries to figure out why, maybe they will be lucky and find out all that they are missing and will begin the process of truly transforming, maybe they won’t. It is a fact that you will not see all the purported benefits of Scrum and Agile without truly transforming your organization to become truly people-centric, not just customer-centric for they are just some of the people affected.

To become an Agile organization should be the goal, and most companies fall short of that goal time and time again. Burnt enough by multiple attempts to “go Agile,” they will invariably give up and go back to the old ways, the waterfall ways until they die out due to competition kicking their butts or get new leadership that actually understand the value proposition of Scrum and Agile, and what it means for the world of management, corporate culture and their actual bottom line over the long term.

I remember when Scrum was just a fad; that was when I found it. Despite the predictions of the day that it would die out quickly in favor of some newer shiner fad, I recognized right away that it was going to dominate the world of software development, and now I believe it will begin to dominate the way the world gets work done period over the coming decades.

What all this means to me is that I have job security doing what I do until retirement or I just up and decide to stop working. Good luck if you don’t believe me.

Project Managers and Scrum

I find it ironic that the title of the book that launched Scrum into the mainstream was titled “Agile Project Management Using Scrum” because in my experience, Project Managers and Scrum mix like oil and water.

I was a PM for about a dozen years until I read that book and realized that everything I had been doing until that point needed to change (except for a few things that were actually Agile and Scrum-like). I was very good at my job. I escalated my skills to the point where I was in charge of a major many millions of dollars portfolio of work as a Program Manager. However, once I read that book, my world was forever changed, and I have never looked back.

Why are PMs so antithetical to Scrum? For the simple reason that a PM is born to command and control a team to get the job done. A Project Manager is the very definition of a command and control role, one with limited power and unlimited responsibility. The PM is the center of the project universe, and all things must flow through their control. They command because they have to (in a typical waterfall scenario this is demanded of them), and while I hold my former associates in high regard as people, when it comes to Scrum, they are the very last thing you would want to impose upon a team in any capacity.

I have only ever seen one scenario where a PM type role was of value and that was to track project financials and do some basic admin work, but that is a sliver of a PM’s responsibilities and could be more easily tasked to a Scrum Master or Product Owner or just assigned to a Project Administrator or Coordinator role if you really feel you must.

I have seen many large organizations attempt to integrate Project Managers onto teams or get them to fly around teams on larger scaled initiatives to coordinate dependencies or communicate status, and I can tell you that they always, without exception, made things worse instead of better. The same can be said for former PMs that take on the role of Scrum Master. They are generally terrible at it. They stick to their PM ways and just become passive aggressive in their command and control behavior. I feel for them. I really do. I was once just like them and saw the Scrum light. To me, it was a beacon of reason and opportunity. It was a revelation, but to others it signals the death of their jobs, as it should if an organization is truly going to embrace Scrum - there is no role for PMs on or around a Scrum team. Luckily for them, Waterfall will never go away entirely. It still has its applications, and, of course, the rest of the world is slow to learn the lessons of Scrum outside of software development, so there will be ample opportunities for PMs to ply their trade for many years to come. I do not however advocate getting into to the field now as a PM. You are watching the decline of the old way of getting work done and the ascension of a number of new ways (Scrum and Kanban for two but there are many more). None of the new ways needs a command and control center any longer and that is a fact to me as much as gravity.

Dedicated Scrum Master

If you go by the book on Scrum, a Scrum Master can be anyone on a team. They can do their day job (Dev, QA, etc.) and moonlight as the Scrum Master as needed. Maybe this is true for some very high performing teams, maybe not. I have never seen the team that benefits from this approach, I have seen many try it. What usually happens is that the team sees the Scrum Master as a simple secretary, scheduling ceremonies and maybe facilitating them. There ends the value of a Scrum Master. Anyone can do that right?

From my experience this is absolutely incorrect. The Scrum Master should be a dedicated role played by someone with no other responsibility on the team. The Scrum Master idea has evolved in the industry since the book was published and is now vastly more important to a team’s success than running a few ceremonies. In my view and experience, the Scrum Master is in charge of how well everything is running, how well the Product Owner is managing the backlog, customers, stakeholders and interacting with the team. The Scrum Master is responsible for how well the team is doing, each individual member as well as the team as a whole. The Scrum Master is responsible for how well the organization is doing around the team; are they getting the trust and support they need to get a great job done?

For me, the Product Owner is What, Where, When, Who and Why. The team is How and the Scrum Master is How Well. The Scrum Master is coach to the team, the Product Owner and the organization around them. Coaching them on Scrum, coaching them on how to work at the highest levels of adherence to the Agile mindset (values and principals). The Scrum Master role takes on the flavor of the management role in Lean Manufacturing. Coming from the viewpoint of the Toyota Way, there is no other analogous role than the Scrum Master for the role that management plays in that system which birthed many of the ideas of Scrum and still serves as an incredible source of improvement process for it. This is not a role to be taken lightly. There does come a day when a Scrum Master has less to do, even if they are great at their jobs, maybe especially if they are great at their jobs, because if they are great, then their team is great and should need them less than they did in the early days. The organization around the team should be great and so need less from a Scrum Master as well. Even when that day comes, I would not give the role of Scrum Master to someone who has a day job. I would give the job of Scrum Master to a junior Scrum Master and send that awesome one off to work with a team that needs them more or simply give them more teams to work with. Some day I will talk about the career path of a Scrum Master, but not today. Suffice it to say, there is a path for them, and it does not include going back to their day job.

My (partial) Scrum Manifesto

I value people as people. People are human beings with wants and needs, fears and desires, strengths and weaknesses and skills and abilities. People are not resources. Resources are things that can be used and used up. Resources are things to control, people are not. Resources can be divided up across teams, people should not be. Resources can be interchangeable like the cogs in a machine, people never are. People are the most important element of my practice at work. If you get people right, you win, get them wrong and you lose. It is as simple as that. Referring to people as resources is dehumanizing and insulting. I do not do it. I value each person. Every team member is as important to the team as a whole. It takes every team member to do great work, to delight the customer, to exceed expectations, to build something elegant and strong. Getting every member of the team to bring their whole selves to work is my primary job. Team dynamics usually take care of themselves if you get that right. Connecting with people, engaging with them to enable their self-determination, self-management, self-organization and accountability is more important than giving them suggestions, advice or expectations. I value people as people

I value helping the team. Helping the team to resolve, untangle and remove impediments to getting work done well is important to me. When they are unable to deal with impediments, I take them to those who can; being willing to put myself out there to hold others accountable is crucial to success sometimes. It is dangerous sometimes. Sometimes you are able to see impediments resolved, and sometimes you have with work with or around them because there will be people who are unwilling or unable to help when it is needed. There are dysfunctional people and institutions out there, and one person can only go so far on their own. Judging where to draw the line is challenging sometimes, and sometimes I do not get it right. The struggle for what is right and good for teams is what matters. I value helping the team.

I value presence. Teams are always more effective, efficient, practical and creative when they are in the same room together, when they can fully communicate face to face with each other. I have come to believe that most of communication is non-verbal, and distributed, dispersed or isolated team members do not a team make. There is so much lost when teams are not able or allowed to work together. The heartbeat of a team, the workflow board, is no longer a gathering place for people to interact and imagine and discuss as needs warrant. This is not to say that taking a break from the group and going off on your own to produce something has no value, it most assuredly does have value, but the key is being able to return to the group and get the full feedback needed to make those efforts great. When teams are dispersed and nothing can be done about it, I work hard to ensure the loss of presence is mitigated through tools and processes that encourage as full an interaction as possible. I value presence.

These are just a few of the things that I value about using Scrum. Perhaps I will write more on my Scrum values at a later date.