The Way We Win Matters

TL;DR

• Reaching goals without regard for how you do it costs companies and societies far more than money.
• Activities are more than fun, they're for learning, bonding, achievement, and more.
• Fulfilling employee needs is a profitable business model.
• Leading with values is the best way to care for and grow a business.

I recently watched the movie Ender's Game, and one line stood out to me. Ender is in a military institution, and one of his superiors is pushing total destruction of the enemy, including at the cost of their own army. Ender fervently replies, "No, the way we win, matters."

I can't get this out of my head. It's a cornerstone in my life, and especially in how business should be done. A good business leader should bring not only results, education, direction and mentorship, but do it in a way that's interactive, collaborative, adds variety, and even fun.

Variety and Fun

With variety and fun, I don't mean Nerf dart fights in the hallways, I mean activities that take the monotony out of meetings, help a team understand a concept, or increase participation and motivation. In the pressure-cooker of business, it's important to not just deliver, but deliver in a way that promotes stability, unity, and even enjoyment. Would you rather deliver, or deliver with a workforce and customer that feels valued?

I like to bring that value to the workplace. Jane McGonigal has been on the leading edge of serious games for quite some time. Her book Reality Is Broken is all about how games have been educating and bonding us for centuries. She describes how we can leverage activities to educate, and even do work for us. Do you retain a lesson better from a PDF you read on your screen, or from an activity that you shared with your colleagues? People benefit more from interpersonal activity, and those are the things that make a difference in the work environment.

Games, variety and activities will encourage motivation, and break the monotony of work. Many struggle to get the everyday work done on time, few are those who consider the enjoyment of the environment as part of the process. However, the benefits are tangible. Employees who enjoy their workplace will grow in value to the company, and will commit to the place that values them.

The Best Talent Responds to Leadership, Not Command

I feel like this is old news, yet command-and-control is everywhere. I think it's because we're not brought up to be collaborative thinkers and problem solvers. The opposite of command-and-control is servant leadership. It means that your ego is not what comes first. You're there to help others achieve the common goal. Servant leadership is harder because it takes patience, compassion, and thought. Hierarchy filters out all of that, and leaves you with simply "do what is told."

Hierarchy also filters out transparency and agency from those you lead. Without these, the people who do the work can't be relied upon to create the best solutions. It hides information, removing the opportunity to create more value and growth for the business. The business itself is stunted. Flexibility is lost. I have often seen one unquestioned bad apple near the top spoil a whole vertical of business. Yes, there is a need for tie-breakers and people to make a final decision. Good servant leaders make space for safety, autonomy, and respect, which in turn builds commitment, creativity, flexibility, and satisfaction. Scrum done well also promotes this environment.

Lead With Your Values

To be a good leader, you have to be a good human yourself. If you're a leader who hasn't set aside time to consider values, then now is a great time. I promise it will benefit you in unexpected ways.

Human Values

Autonomy, respect, to be listened to, to feel safe. These are all basic human emotional needs. There are many more, and these are the bare minimum to valuing people. If a company or interaction doesn't offer this to employees or customers, how can we expect them to respond well? What are your own human values that you need, and should give to others in return?

Scrum Values

Traditional project management extols the virtues of doing the right thing, while acknowledging there are grey areas. That's about it. Scrum goes further by identifying and placing at the center of its framework the values to keep the project, and people on-track.

Each Scrum value below has both human & business meanings, can you find examples of both?

• Focus, Respect, Openness, Courage, Commitment

Business Values

What does your business value? What drives its goals beyond profitability? When making your business values, they shouldn't be repeats of the human and Scrum values listed above, they should be in addition to those. You can also think more globally, since that's how your business likely operates. Once you have business values, then ask what is your business doing to actively put them into practice? The answer to this question is the difference between what I call public relations values (a false pretense established to make a business look good), and authentic values.

Let's Get Over Differences

People process information differently, respond to stimulus differently, and everything can be done in ways that are different from what we might expect.

1. Primary bias comes from the false assumption that everyone is supposed to be mostly the same. Uniform.
2. Secondary bias comes from the idea that those within a group will always act the same.

By removing these bias, we open up to a higher diversity of people and ideas that can bring value to the business. Instead of working to tear down someone with a difference of opinion (or anything else), let's find out more about why there's a difference, and what can be done to create improvement for all sides.

A society forms by preserving a set of values, and its norms become culture. Whether or not the society can adapt to a changing environment will determine its success (a bit like Scrum). So let's recognize the differences, understand them, and work with them. People have differences, but there's always a lot more common ground that can bring us together. Until we consider all sides, no resolution will be final, because it's not just winning that matters.

The way we win, matters.

The "Problem" of Changing Requirements

TL;DR

• Change is often the thing we’re most afraid of in traditional PMO.
• Scrum done well turns change into opportunity, it's part of the process.
• To handle change, Scrum can't be half-baked into a waterfall process.
• Planning is good, rigid planning is painful.
• Only say yes to the changes that add value.

We’ve all experienced it. The thing we’re most afraid of in projects is change. Change to requirements, customer expectations, quality standards, budgets, to the market, and even changes to our product relevance while we’re building it. Typically, change means a higher burden on the dev team and management. It means extra work to rebalance expectations and baselines, change boards, and dev team overtime (on top of the OT they’re already working). It’s no wonder that change is what we typically try to prevent on a traditional project.

What if I told you that Scrum handles change quite well. Have you been working in Scrum for a while, and yet change is still killing your teams? Is it still an overall demotivating aspect to your projects? If change is something your teams fear, then you’re probably using a half-baked version of Scrum. I recently wrote about the systemic factors that disrupt the essence of Scrum. Basically it’s a combination of the contracts, timelines, and requirements structure. These are the main issues that prevent a true implementation of Scrum. When setup properly, Scrum handles change as a bend in the river, rather than becoming a steep drop-off in productivity.

How Does Scrum Handle Change?

Once your organization is setup to use Scrum, change will be handled as a flow. Here are ways Scrum supports change as a flow.

When Done is Truly Done

One of the key concepts in Scrum is that your Sprint features are in a complete state by the end of a Sprint. Product Backlog refinement is key to this concept. The Product Owner and Dev Team must refine and prioritize your backlog in a way that prevents features from being spread across multiple Sprints. This supports the ability to create a done, releasable product. This has several positive knock-on effects to handle change.

When you release a truly done increment...

• Change isn’t as big an issue when you release stable, done increments, there are no loose ends to tie up.
• Sprints can be made short enough to allow feedback and movement in another direction.
• Product Backlog refinement ensures features are broken up in a way to reduce dependencies.

Every Sprint is an Opportunity for Change

Whoah, wait, opportunity for change? But change is such a baaaaad thing! With done increments being delivered, there are no loose ends to tie up, so a change in direction isn’t as painful to the teams. It reduces resistance, and allows unexpected changes to be handled more like just another feature in the Product Backlog.

Flexible Planning is Good, Rigidity is Bad

Flexible Routes

There’s a difference between planning for an outcome, and following a pre-planned path to a specific output. Let’s say I need to drive to my friend Ned’s house. Before I start, Google maps says the best route is to take the main highway route. While driving, traffic gets backed up, and Google tells me there’s a better route to take. Do you stay on the path you’re on, just because it’s what you chose when you started your journey? Heck no, you take those side streets, and arrive with less stress, and on-time. This is what Scrum is like compared to traditional project management. Scrum is veering off in the other direction when you need to, and still achieving the same goal (or getting there even faster).

Flexible Destination

Another flexible aspect of Scrum is allowing changes to an outcome, rather than hitting a specific output. Let’s say I call Ned when I see traffic is backed up. He says, “We can meet at the restaurant instead of meeting at my place, since we were going out to eat anyway.” Scrum would respond with an emphatic “Yes! Let me shift this old route to the new one, and I’ll see you soon.”

Traditional project management might say, “That’s not what we agreed upon before I left. I’ll consider it, but since it’s not the original agreement, let me document what you’re suggesting, estimate this traffic backup, call my parents for advisement, plot a new course on Google maps, compare it to my current path, write down the differences between the two, text it to you, and then have you and my parents text me back in agreement on this new plan. If there’s a difference in cost between these paths, I’ll bill you.”

I don’t know about you, but one definitely sounds like a better approach than the other.

Final Notes on Planning

Scrum’s method allows for planning on a just-in-time basis, which means you have more information to make your best decision, when you need it. Hold until the latest responsible time to make a decision, so you have the best data to decide with. Second, Scrum also doesn’t advise saying yes to every proposed change, but to say yes to the right changes that add value. This area is where a good Product Owner shines most.

Conclusion

Following a rigid, overly preplanned waterfall path may get you to success, but at what cost? If your customer is the cause of change, they will be very unhappy if their needs aren’t met. If the market needs have shifted, you won’t deliver the necessary product. If change means your team adds more work within a rigid timeline, they end up burnt out. These are all reasons true Scrum projects can outshine waterfall delivery. Setup your projects in Scrum, and make fear of change a thing of the past!

Why Your Scrum is Getting Pushed Over the Waterfall

TL;DR

• Fixing 2 major waterfall habits will greatly improve your Scrum success.
• Flexible contracts provide better outcomes for your business, employees, and customer.
• Iterative end-user delivery, or flexible requirements will pave the way to success.

When problems arise, I don’t want to just fix the aftermath of the problem, I strive to fix the root of it. With this in mind, I’ve seen 2 major systemic problems in Scrum adoption that force Scrum to fail. This often happens when Scrum is used as a thin veil over a waterfall setup. You’ve probably seen this happen, or are managing it now. Businesses choose to use only the events and artifacts of Scrum, while it’s truly guided by the waterfall. This is fine for a transition period, but offers little improvement over the long-term. The value earned is often the same employee burnout, lack of ability to handle change, and reduced ability to handle risk. Since you may now ask, "why adopt Scrum at all?" I’ll give a brief overview of benefits.

Proper Scrum setup provides...

• a graceful way to handle your customer/user’s changed needs over the project
• faster time to market, and real market validation
• stress reduction at all levels of the project
• higher skilled talent, and retention of talent
• adoption of discovered innovations/needs that would otherwise have been missed
• increased customer relationships and buy-in.

If you don’t need these things, then you don’t need Scrum. Beware that waterfall simply cannot provide these benefits in the graceful way that Scrum does. That said, here are 2 major systemic waterfall habits that must be fixed for your successful Scrum adoption.

The Root Cause May Be Your Contracts

When I see a project with an improper Scrum implementation, I immediately go back to the contract. Scrum handles change gracefully, but at the root, it must be supported by the contract. The bane of Scrum’s existence is the fixed price contract. If your contract has a firm budget, and a firm full-features date, you’ll fail to gain the benefits of Scrum.

A non-fixed price contract will be the firmament upon which the Scrum framework needs to do its work properly. Although the idea can be a challenge for traditional businesses and customers to embrace, once they do, they find a completely different world of development based upon true accountability, trust, and quality of service.

What’s keeping your organization/customers from embracing Scrum and the non-fixed price contract? Most likely, what's needed is an exposure to, and an education of the way work can be done iteratively. Done well, Scrum will bring strong coupling between the business, customer, and end users, operating nearly as a single organ with a purpose. It just takes the right knowledge and guidance.

Contract Risk

Using contracts that aren’t fixed price can place risk on the seller. It may allow the customer to back out before the entire product is complete. However, many contracts already have a clause which allows a customer to pull out early if quality standards aren’t met. An iterative contract is not much different, and there are ways to structure a contract to reduce this risk, while also keeping the customer happy.

Once you have teams that have worked on a project and know their velocity, there are opportunities to use fixed price contracts, but there are also caveats for the Scrum Master and Product Owner to consider, before doing this.

The Full-Feature Release Date

Secondly, successful Scrum adoption must have either a flexible feature list, or a flexible release date/release chain. Without one of these, Scrum won’t have the portability to become the most valuable, and mangeable product it can be.

Your MVP is your MVP

When planning for a flexible feature set or iterative market delivery, know your minimum viable product (MVP). Minimum is the keyword here.

• Contains a small feature set.
• Minimal (but stable) operable capability.
• Can be deployed with stability on all initial platforms.
• Preferably deployed by the Dev Team.

Plan for Iterative End User Release

When your end user’s release expectation matches your production process, this is ideal. Iterative delivery is also an industry standard now, with only a few industries still holding onto the release-all-at-once cycle. If you're in a large release industry, examine why large release cycles are still being held onto. Customer absorption and adoption of updates are concerns to take into consideration, but there are so many more benefits to an iterative release cycle.

Build for the minimum viable product, and plan to add updates after launch. Launching early with fewer features is better for quality, too. You must release a stable, “bug free” product, but you can’t hire enough testers to find the type of issues that your end users will find. Releasing a smaller, fully tested product early makes unforeseen user reported bugs easier to triage (and re-release) than with a larger feature set that's full of dependencies to work around.

Flexible Final Feature Sets

Change happens in every project. If you have a firm date where all features must be released at once, work out a way to use a flexible feature set. Again, knowing your MVP (minimum viable product) is critical here. Prioritize your features in a way that leaves room for the least necessary features to fall off when unexpected changes, or better ideas occur.

---

---

To be clear, there are many more reasons why Scrum adoption may not be working yet for a business, but a good Scrum Master will help identify, mitigate, and correct those issues. What I listed here are the 2 main waterfall habits that most businesses overlook, and how to navigate those waters for project success.