Policies, Procedures, and Rules - Oh My!

About two years ago Dave Snowden, a highly respected modern agile thinker among other things,  wrote this blog post deriding SAFe as the "infantilism of management." I was reminded of this recently when thinking about all the other things companies do that put unneeded emphasis on compliance and rule following. Namely, the various rules and policies commonplace in traditional companies. When I say policy, I'm talking about the typical laundry list of rules put in writing regarding a specific business situation. This rule-making activity flies in the face of modern management thinking, yet they seem to be the only tools in the toolbelt for most companies, and thus they proliferate. In doing so, they relegate the role of managers to compliance czar, and threaten the foundation for a vulnerability-based-trust relationship with your employees.

In today's age of the professional knowledge worker, what use do we have for such policies and rules? And what does that mean for the role of a manager? 

Policies are the Wrong Vehicle. 

Imagine for a second we could write a perfect policy. 100% accurate rule-set mapping all known inputs to desired outputs. "If you apply for vacation under these circumstances, then it will be approved." "If you expense the following items, you will get reimbursed." Sound familiar? Corporations attempt this all the time. There are two problems with this, other than it obviously being impossible to do (I'll ignore that little fact).

One: We are using comprehension to attempt to create clarity, and this doesn't work. Snowden would say this is a "false linear model." Something advertisers have had figured out for a long time is that when it comes to influencing people's behavior, and that's exactly what we're after in management, Cohesive Trumps Comprehensive. A cohesive message leads to confidence in its underlying truth. A comprehensive message leads to analysis/questioning of the underlying truths. 

Example: If we want our employees to work hard and use time-off wisely, state exactly that and no more. It's a short cohesive message. By being cohesive, we'll create clarity. We might also create some really rich discussion about complex situations and be able to handle them as a manager in the context of the actual event, a very mature management situation. Alternatively, if we want employees to ponder/worry/water-cooler-chat about why the PTO policy states whatever it states, then list out all the various ways in which taking time off is appropriate: vacation, sick, holiday, death, baby, etc. By being comprehensive, we've almost certainly reduced clarity, and induced questions as to what our (the management) reasons are behind each element of the policy. What if I have a once-in-a-lifetime chance to take a trip but I've run out of PTO days? What if my dog dies, and I don't have kids, so this pet was everything to my family? The policy doesn't discuss days that my religion requires I don't work, I wonder what will happen now? I don't think the answer is universally "yes, take time off." As a manager we should have the opportunity to address these things in context of the situation, and even struggle with what the right answer is. This is our very hard job.

Two: We are trying to tackle a complex problem with a simple solution. By definition, a perfect policy would be the answer to a simple problem, and the company is not paying us to solve simple problems. Which brings me to this:

Policies are the Wrong Priority.

If we as managers are spending our time working on policies, we are not focused on the most valuable thing. In the context of complex work, there are certainly complex problems that require our attention. Making even 1% progress on these really hard issues is more valuable than creating a 100% perfect policy. Yet we see management spending an inordinate amount of time and effort creating and tweaking rule-sets. This is the zero-risk fallacy running amok and causing us to spend our time on non-issues and near-meaningless things. 

Example: The amount of abuse that would result in having no written vacation policy, is so miniscule compared to A) the amount of value it would bring to our employment brand and 2) using the time we otherwise would have spent on a formal vacation policy to make a dent in our geographical scaling issue or supply chain bottleneck or any other number of wicked complex problems. 

Conclusion. 

Management is hard. There are complex organizational problems with non-trivial and non-obvious solutions that we have to tackle daily. Rule-sets and policies attempt to make our jobs easier, but actually infantilize the role of management. They are simply the wrong vehicle for what we are trying to accomplish. Also, we should be absolutely terrified of working on the wrong things, and I can't imagine an organization that doesn't have bigger problems to solve. 

Today's knowledge worker is called upon to solve equally complex domain problems. We thrive on autonomy and creative space. Rule-sets and policies are wrong/incomplete at best and ulterior-motive-induction-bombs at worse.

Epilogue.

Interestingly, this is not all that "modern." My views here are not "radical" or "agile" or "only applicable in narrow situations like trendy startups." In 1944, the CIA published The Simple Sabotage Field Manual, part of which is directed at how to sabotage corporations as an inside-man. The language is a bit dated, and it's incredibly simple as the name suggests leaving room for interpretation. It's clear though that even back then we'd agree that policies can be sabotaging: "multiplying rules" and "worrying about the policy of a higher echelon" and "demand written orders."

We've known this for 75 years, time to update our organizational operating systems. 

What Exactly Are We Scaling?

Scaled Scrum. Agile at Scale. Enterprise Everything. Everyone is using the Scaled Agile Framework SAFe.  Scaling, Scaling, Scaling. If you’re working in product development, you’ve probably had a few conversations on this topic. It seems to be all the rage right now. In this blog post I hope to lend some clarity to what we mean by scaling. It turns out not everybody is talking about the same thing, and different organizations have different things they want to scale. So here’s a break down of possible scaling scenarios, along with my very simple, high-level, thoughts on where you might want to start.

One quick note on the word “product.” A Product is something a customer buys or internal stakeholder uses, as seen from their point of view. Too often the development side of the house sees products as a reflection of how their teams are organized or how the code has been written, or some other inside-out view. This is probably a result of Conway's Law, it frequently causes problems, and is a topic for a different blog post (or book?).

5 Scaled Agile Scenarios

1. One Product, One Team

You don’t need to think about scaling the process. Just relax, and focus on growing a solid agile team. Professional Scrum may be a good place to start: its mixture of XP, modern development practices, lean product ownership, and the Scrum framework is a good choice for most teams. You may however want to start reading on #5. Note that for every scaling scenario that follows, I’m presuming you actually have a healthy, sustainable, vibrant agile team at the core. Before you focus on how to scale anything, I highly suggest spending some time getting the most out of the people and teams you already have. Improvements at the team level almost always have a greater ROI than improvements in scaling. Or if you don't believe that, at least know this: if you're doing "just OK" at the team level, you'll be doing no better that "just OK" at scale, and probably much much much much worse.

2. One Product, Many Teams

This scenario’s chief obstacle is how do you get many dozens of people to create a single product, a big complicated product, all working towards the same goal, and creating the thing all at the same time?! Things that help here include:

  • A single backlog owned by a single product owner who is the person with the overall customer-centric vision for the product. You may scale some of the tactical PO duties (writing PBI details, acceptance criteria, daily clarification of work) downstream by having strong business/product/analyst skills on the development teams. You can scale some of the market-side PO work upstream by having a team of product managers/marketers help with pricing strategies, customer feedback, and market research.
  • A way for teams to select work from the product backlog, without stepping on each other’s toes. With just a few teams this is fairly straightforward and PBI’s can be pulled via having a simple conversation amongst team members. ProTip: Refinement sessions should focus on dependancies up and down the Product Backlog as well as across teams. With dozens of teams, you may think about asking the PO and teams to label the backlog with a few simple categories in order to help this go a bit faster. A scaling framework may help here, but I do caution against large and long meetings just for selecting work – the cost almost always outweighs the benefit, and it screams of the old-school-thought that we can perfectly estimate->assign->execute the work. Keep this simple, it’s not the biggest obstacle in this scaled scenario.
  • A way for teams to create a single product. Turns out if you want hundreds of people to simultaneously create one product, there are technical necessities. Single source control, continuous integration/build/test/deploy, use of SOLID principles, API’s, DevOps concepts, etc. The bigger you scale, the more of this you need.
  • A way for teams to communicate with each other. You probably need a mixture of formal interactions and informal communication cues. Some of the scaling frameworks can help with the formal checkpoints. My experience is that the informal communications are even more important. Focus on growing a culture of communication where anybody can go talk to anybody else, regardless what team you’re on or who you report to. Some chat tools like hipchat/slack/yammer and video tools like skype/hangouts/sqwiggle can help when there are hundreds of people across the globe too.
  • A way to see progress on the product across all the teams. Sprint Reviews become a challenge with dozens or hundreds of teams. Think about different formats like the “science fair” or the “video reviews” made popular by the teams at Microsoft. Tools like UserVoice or even some Visual Studio tools can be useful for gathering asynchronous feedback from stakeholders/customers. You also may have to do some arithmetic magic in excel for creating a multi-team release burndown for teams that have various velocities (even if you’re using a scaling framework I do not recommend the practice of “normalizing estimates” across teams, it breaks some core relative estimation principles, and it’s simply not needed).

My recommendation here is to start with Professional Scaled Scrum and the Nexus Framework.

 3. Many Products, One Team

This is an often-overlooked situation in the whole scaling discussion. Many teams are in the difficult position of developing and supporting many different products and product lines all at the same time. The scaling question here is “how do we figure out what the team should be working on?” and the following things should be considered:

  • Our constraint in this system is the throughput of a single team. We should optimize for that constraint by ensuring they are only working on the most valuable work we can find. Therefore, product ownership, backlog refinement, and hyper-prioritization based on value become even more important. You should be terrified of working on the wrong things.
  • Lean thinking tells us that context switching is a form of waste, so “work a little bit on all the products” is probably not an optimal strategy. You will have to get good at “saying no” and being able to explain that the team is focused on higher value items at the moment.
  • Shorter sprints or flow-based systems typically work very well here. I personally like combo of: Kanban + DoD + Refinement-On-Demand + XP-Modern-Development-Practices.
  • Extreme focus on quality. If you’re in the situation of also having to support all these various products, nothing buries a company quicker than poor quality. You have virtually no chance of survival if in addition to all the above, we have to constantly worry about production support issues. Keep quality high, tech debt low, and never compromise your definition of done.
  • Managing many different product backlogs and comparing the value of items between all of them can be a pain. Not to mention there are projects coming to an end and a funnel of possible new ones to begin. You need to consider some sort of agile portfolio management, whether that’s a tool, process or framework. The key to agile portfolio management is to visualize the portfolio, get the PO and other stakeholders talking about it on a regular basis, and have a lightweight way to get the necessary data you need to make decisions.

 4. Many Products, Many teams

First, for each product, see #2. Now the only problem that remains is how to manage all these various products we’re building, which we just covered in #3. You have both situations happening simultaneously. This is where most organizations reach for a solve-for-everything scaling framework. And that’s not such a bad idea here, assuming that the individuals and teams on the core of this huge scaled system are already operating at very high levels. As in #1 above, I suggest you focus most on the teams, and don’t spend all of your time, effort, on money, and solving for the higher level scaling issues. A process optimization that helps a dozen people at the top but hinders thousands of people on development teams is, well, not an optimization.

5. Beyond the Team

What do you do when other departments needing to plug into agile product development?  What are the leadership behaviors, management tools, and organizational structures that best support an agile enterprise?  Along with the software and product development practices, the agile umbrella includes many other concepts that are useful to other departments in a modern agile organization. Here’s just a few to look into.

Conclusion

Want to be part of this discussion?  Do you have more suggestions for "beyond the team" techniques?  Want help implementing these ideas? Please contact me!