Introduction 3: The Trio, Game Maker's Toolkit, and Marty Cagan
Last chapter we talked about software products. We gave a tentative definition: a collection of capabilities and features that solves a need such that someone would pay for it. We then talked about how this definition is on the right track but there’s a considerable amount of gray area. Let’s look at a second definition— and this one comes straight out of the Scrum Guide:
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
Scrum Guide, 2020
I wanted to go over a business definition first because I think value is the least understood concept in all of software— but everyone understands money. But we can see how the Scrum’s Guide definition plays well with what we talked about.
For a software product, the value to the company is, at the end of the day, revenue.1
For a platform, the value to the company is, at the end of the day, efficiency gains in your profit centers.
And so on
But this definition, being broad, also covers those nice edge cases: the online banking system doesn’t provide revenue but it does provide value: some intangible virtue that keeps customers in your bank and gives them confidence every time they open the app and see that their paycheck is in their account.
Think back too to our discussion of McDonald’s: a hamburger patty doesn’t have a “clear boundary”; no one would pay for it by itself, but the whole burger does. Scrum is also medium-agnostic, and can be used for software products; physical products; anything.
So, uh, what is Scrum?
But First: Scrum
We’re going to talk a lot more about Scrum when we talk about the agile industry, but let’s get some things out of the way first.
Agile terminology is inherently silly. “Scrum”, “Kanban”, “Sprint”, “Kaizen”— are these serious words for serious people?2 I’ll do my best to talk you all through it, but know that when you roll your eyes… I am also rolling my eyes a bit.
I am, at the end of the day, a completely unapologetic Scrum Stan. I don’t have any favorite children but I do have a favorite framework: it’s Scrum.3
If you’re interested, you can read the whole Scrum Guide for free online. It’s only 3.6k words long; just a bit longer than one of these posts. In a world of process and jargon heavy nonsense4— I’m looking at you SAFe— Scrum is, and always has been, a breath of fresh air.
So let’s take a minute to talk about what Scrum is.
Scrum says that a product is a vehicle for delivering value and therefore Scrum is a framework to optimize your chances of doing so. Scrum is used in complex environments where the end state is somewhat defined but the path getting to there is not. You forge the path through empiricism: do, observe, learn, repeat.
This cycle is called a Sprint and it looks like this:
A Product Owner orders the work for a complex problem into a Product Backlog
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
Repeat
Scrum Guide, 2020
You could use this cycle equally well in science as in software.
Scrum is not only my favorite framework, it’s also, perhaps, the most commonly used framework for developing software today— sort of. While there are a lot of companies that say that they practice Scrum, I find that Scrum is frequently bastardized in that practice. Certain agile methodologies are starting to fall out of fashion, Scrum included, for reasons that we’ll talk about in a later chapter, but I want to channel my inner G. K. Chesterton here and state that Scrum “has not been tried and found wanting; it has been found difficult and left untried.”
Yes, I’m one of those people.
But let’s elide over industry trends for a second and talk about the team. In Scrum, there are three “roles” on the team.5 They are Product Owner, Developer, and Scrum Master. We’re going to talk about each of them in turn, using an orchestra as an example.
Developer: These are the fine people that actually do the work. They are the ones who are responsible for turning ideas into value, one step at a time. They could be software developers, UX designers, QA engineers, animators, sculptors, anything. In an orchestra, these are the cellists, drummers, violinists, etc. who actually make the music.
Scrum Master: You could think of this role as the “team coach.” This person is responsible for the effectiveness of the team. Under the premise that Scrum is, itself, effective, they are also responsible for implementing Scrum as a framework. This is the least understood and most corrupted role on the team— but we’ll talk about that later. In an orchestra, this is the conductor, who makes sure everyone is on time to the music, is playing at the appropriate tempo, and is making music beautifully together.
Product Owner: This person helps the all important question for the team: what is valuable? This person is responsible for maximizing the value of the product by articulating the team’s goals and the backlog to achieve them. In an orchestra, this is the composer, who writes the music that the orchestra will play.
What’s the Point of This
Someone who isn’t in software development may well ask: isn’t this all too complicated? What’s the point of any of this? Why doesn’t this work like every other industry where your boss tells you what to do and then you go and do it?
Someone who is in software development may have similar objections: isn’t this all too complicated? Aren’t Scrum Masters just the dopes who run JIRA and get in everybody’s way? Just have the business tell us what the customers need and then we’ll build it! What the heck is this guy for?
There may be other objections.6 There’s a lot of interesting history that we could get into, but the fundamental idea is that identifying value is really hard.
If you ask fifty people in your organization what would make your software more valuable, you would get fifty different answers. Your customer success team would point to all of the tedious manual work-arounds that your users need to do because the software doesn’t work quite right. Your customer delivery team would point to your painful onboarding process. Your developers would point to your horrific tech stack which was out of date back in 2009. Your sales team would point to how you haven’t added in any modern AI tools and are thus getting hammered on the conference circuit. And on and on it goes.
You don’t have a chance of doing much of this in a year, let alone all of it— so what do you do? Who makes the call? And why?
Many of these frameworks: the Project Management Office (PMO), Scrum, OKRs, and, yes, even SAFe— are all intended to make it easy for the organization to organize around a definition of value and all move forward on work to accomplish that value.7
We’re going to talk a lot more about value in the next few chapters, don’t you worry.
Those Who Can, Do; Those Who Can’t, Teach
With apologies to all of those in the noble profession of teaching,8 let’s return to my own career and finish defining the road-runner.
I went from software developer to Scrum Master to Agile Coach, and this is when I started to feel uneasy about the way my career was going. And part of the reason was that I was watching YouTubers like Mark, who runs Game Maker’s Toolkit.
Game Maker’s Toolkit, hereafter referred to as GMTK, is a videogame analyst / channel on YouTube. GMTK does deep dives into the way videogames are designed. He will dig into specific coding choices in platformers, showing how the physics engine in platformer Celeste produces a markedly different player experience than a different platformer like Super Mario Bros. He’ll look at different gameplay routes for open-world Metroidvanias like Hollow Knight, and explain how the designers created multiple paths through the game to reward different kinds of exploration (and make speed running possible).
But a few years into the channel, Mark started to make a different kind of video.
Instead of making videos analyzing other developer’s games… he started making videos chronicling his personal journey to make his own game. Here’s a typical example as he’s building out puzzles for his platformer:
Read Mark’s explanation at the beginning of his journey:
For the past seven years I’ve been making videos about game design concepts and ideas and principles without ever actually applying them…
Which is perfectly fine! I think it’s absolutely okay to, say, talk about screenwriting without making movies. Everyone has a valuable insight.
But I do think there might be something wonderfully interesting about taking these ideas that have been, so far, academic… and trying to physically, literally, apply them to game development, and seeing what happens.
The series is really fascinating and it’s fun watching him grow as an analyst and as a game developer. This also isn’t unique to GMTK! Another YouTuber I enjoy is GothamChess, who has a “Road to Grandmaster” series where he goes in detail on the lessons he’s learning, the tournaments he’s playing in, and the games he wins / loses while he works to be promoted from an International Master to a Grand Master in chess. While GothamChess still has a ways to go in his journey, GMTK’s game is coming out next week.9
This, I felt, directly related to my own career as an Agile Coach. In that role, I was often in the business of advising Product Owners or Product Managers. I would help re-write their goals, trying to articulate the business value that they were after. I would be consulted on roadmaps and backlogs, where they asked me to act as a sounding board for their prioritization decisions. At one point, my company put me in charge of a series of internal trainings for “The Product Mindset”— trusting me to teach others how to think about the business of building software products.
As I was building this content in the morning and watching these kinds of videos over the lunch hour, I noticed an uncomfortable parallel: I was advising, coaching, and mentoring on something that I had not done myself.
If we think back to the trio of roles in Scrum, I had experience in two out of three. I had gotten my CS degree and developed software for a few years as a developer: check. I had acted as a Scrum Master / Agile Coach in multiple different companies, large and small, for all kinds of teams: check. I had never been in Product and had never shouldered the weight of maximizing for value myself. Like GMTK, I had commented on it without actually doing it. And, like GMTK… I really wanted to see what that felt like. I really wanted to see if all of my advice, theory, coaching, the workshops that I had made, etc., actually translated into the kinds of success that I advertised that it would.10
And so, I started trying to find ways to move my career into Product.
I am lucky to work at a company with a wide variety of time for self-improvement. We get days of development every year (with a modest budget!) that we can use on almost anything that we want— whether it’s related to our role or not. Taking inspiration from Google’s “20% Time”, my company has historically carved out time for company wide innovation every quarter— which could be on almost any topic, related to your product or not.11 Over the course of a year or two I started to spend my development and innovation time on topics that would increase my chances at getting product positions. (We’ll talk about this topic a lot more when we talk about micro-promotions).
This paid off: when our company decided to get into the Product Operations game, I was lucky enough to have built enough groundwork to get the job. And then, as you heard about in my first post, that promotion put me into just the right spot to slide into Product Management later in the year.
There was one other inspiration that caused me to want to move into Product Management. As part of my research for workshops on Product, I read Inspired by one of the prime thought leaders in the software product space at the moment: Marty Cagan. Inspired is a book that advocates for focusing the efforts of software development around a product— what we talked about in the last post— rather than a project; a self-contained set of work to be done. We’ll talk more about products v. projects when we talk about outcomes.
When I was a software developer, a simple Scrum Training made me realize what a whole new world of modern development could look like— and made me want to become a Scrum Master. In the same way, when I was an Agile Coach, this book laid out such a compelling picture for software products that I wanted to be the person who set that vision.
Well… not the book itself, exactly. In particular, it was a book review of Inspired that really cemented this idea in my brain. The entire review is worth reading (David at axtensoft is one of the smartest software engineers in the business and a fantastic communicator), but here’s the relevant paragraph:
There’s one objection which I [David, the reviewer] don’t have an answer for and which Cagan doesn’t even attempt to address. At least as Cagan describes it, the entire structure seems to hinge [on] having a superman in the role of Product Manager. It asks her to be a veteran of the industry, but also fluent in the lingo of technology to earn the respect of the engineers. It requires her to be a far-sighted leader. She needs to have an idealistic vision of what the company could become, combined with a realpolitik sense of its limits. She is a diplomat who can get multiple silos in the company working together, and all from a position without managerial authority. She does this from behind the scenes, takes the blame when things go wrong, is humble and demure when things go right, then rides off into the sunset without bothering to collect a paycheck…
I don’t have an answer to this. I feel like it will be hard for me to be 100% on board with the idea of product teams until I find one.
Book Review: Inspired, David Stiennon
My road-runner (at this point in my career, at any rate) was David’s characterization of the Product Manager re. Cagan. And, like GMTK, I wanted to stop commenting on this role in an academic way and perform the role in a physical way.
We have finished the introduction and are now ready to move onto the rest of the month: what am I learning now that theory of product management is meeting reality?
The rest of the month will be a mixture of that theory and practice, meditating on the accountabilities of the Scrum trio:
Value
Increments
Effectiveness
We’ll get started next by talking about Value.
National Novel Writing Month 2024: 7,961/50,000If you say this sentence in certain places you will get a hoard of ProdUX folks descending on you in anger. How mundane! How dull! How prosaic! Surely something as gauche as money is a lagging indicator of the real value of the product: ease of finding the song you want; the speed at which you can deposit your online check; how much money you can save on airline tickets by using our software.
Yes, yes, you’re all very wise. Shut up for a second.
When I got my first job as a Scrum Master, I was thrilled— but I didn’t know how to describe it in my family’s Christmas Card. I ended up with “working as a Scrum Master (i.e. process manager) for two of [company’s] IT development teams.”
… “process manager”?? What was 2015 me thinking? What a gross mischaracterization of the role.
Evidence Based Management has sure risen in the rankings in the last two years though.
We will also talk more about this when we talk about agile, but for any budding agilists or frustrated software developers in the audience, pull up that guide and do some searching. You may be surprised on what you find— or, rather, don’t find. For example, story points, one of the most controversial bits of agile jargon, are not in Scrum.
For those of you who don’t know what a story point is: be grateful.
Roles— not job titles. This is another point that has been abused in the industry and another point we’ll talk about later in the month.
For example, if you’re a SAFe practitioner, you may be asking: isn’t this all too simple? I’m pretty sure your company needs to spend $5 million on consultants to fix your Ways of Working up this year. You can’t write software this way without the latest and greatest framework, what are you thinking?
Some frameworks just do it better than others. 🤔
Which includes most of my family and friends… sorry Mom and Dad.
Search for “Mind Over Magnet” on Steam— and enjoy the free demo!
There’s a very important point here that I am NOT making: do you need this kind of experience to be an agile coach?
I will talk about that topic a lot more when we talk about the state of the agile industry, but please note that, at the moment, I am making the claim that I, personally, started to feel uncomfortable coaching something that I had not directly done. I am not (yet) making the claim that other coaches should feel that or that such experience is necessary to be a coach.
This innovation has produced a few product features, to be sure, but just as often is used for fun Slackbots, for cutting-edge technology research, for pipeline improvements, for bugs that would never be prioritized but are a pain in the butt whenever a customer hits them.
My favorite innovation was when a more technically inclined manager got so frustrated with our rotten online PTO portal, which had no settings for notifying you when your staff put in a vacation request, that he built his own batch process and listener to hit the portal and send an e-mail if there were any notifications.
Every manager in the company e-mailed him after the innovation to try to get his tech loaded on their computer too.