Monday, September 22, 2014

What is Agile Game Development?

Agile is a set of values for building products, like games, more effectively by balancing planning with reality, delivering features and quality iteratively, while focusing on the emergent fun of the game by adding features and mechanics in a player-value prioritized way.  It allows a more responsive and predictable approach to development by balancing planning, art, design, technology and testing within small iterations rather than consigning much of the work in these areas to phases of development (i.e. big planning documents at the start and a flurry of testing and bug fixing at the end.  

Scrum is an agile framework with a further focus on the people making a game.  Scrum sets up a framework of small cross-discipline teams that take control of the work done in small iterations (2-3 weeks) to achieve a functional goal.  There are a number of reasons for doing this:
  • Small teams (5-9 people) communicate more effectively than larger groups.
  • Cross-discipline teams can respond to the needs of an emerging game (quality and functionality) more quickly.
  • Creative developers are more effective and motivated when they have a clear vision of a goal, can take ownership of their work and implement changes day-to-day without being micromanaged.
  • Scrum iterations level out workload to be consistent and sustainable throughout development.  They do that by balancing design, development, debugging and tuning so that the game doesn’t build an overwhelming debt of undone work that needs to be paid back, with interest, later in a project through death marches and compromises in quality.
Agile Game Development is a set of collected experiences of what works and what doesn’t work with iterative approaches and practices (e.g. Agile, Lean, Scrum, TDD, Kanban, etc) as applied to over a decade of game development with all genres and platforms.  Although it may not follow all practices of any single framework, it does adhere to the agile mindset and values.

Monday, July 14, 2014

The Futility of Art Estimation

Artists frequently are often frustrated when asked to estimate how much time a new piece of content will take to build. The problem in asking for time estimates for art is that quality is the large variable in the equation that cannot be fully factored in until something is actually built first.

Unlike code, which has more of a binary definition of done, art has a larger subjective quality variable that frustrates any attempt to assign time to it’s completion. What we should be doing is negotiating the quality and observing the time it takes to achieve that quality. 

I’ve coached teams to focus on quality and explore the time it takes to achieve it in a piece of art through time-boxing.

So instead of saying: “Tell me how long it will take to finish this asset”. We are saying:  “Let’s spend a week of time to finish something and see what the result is.”

The variable goes from time to quality.  We'll get one of three "goldilocks" results:

  • The quality is too low.  The time-box is too small. 
  • The quality is too high.  The time-box is too big. (we've all seen 10,000 polygon fire hydrants! ;) 
  • The quality is just right.  The time-box is probably a little too big, but it's close. 

A time-box is a negotiation between the product owner and the artists creating the asset. It’s not picked out of a hat. Often, the conversation about the duration of the time-box is very revealing and informative to all those involved.

As artists and teams learn more about the quality/performance bar being established (and translate from pre-production to production of more similar content), the time-boxes become more of a reference to forecast completion dates. Teams will continue explore ways of shrinking those time-boxes through improved practices and tools.

Wednesday, June 11, 2014

Improving your Sprint Backlog through Refinement

I see a lot of teams spending far too much time in sprint planning.  A full day of planning for a two week sprint, for example, consumes 10% of the team's available time and rarely produces enough accuracy to justify the cost.  Often, the impulse for spending so much time in planning is that the team, or management, wants a reliable forecast of what the team will accomplish by the end of the sprint.  The problem with this is that the features, the work needed to accomplish them and the challenges the team will face, aren't so precisely known.  Therefore the initial plan can't be precise either.

A better approach, when facing such uncertainty, is to create a rough initial plan, with some detailed first steps, and revisit the plan as more is known and the next steps are needed.

An Example
The team working on a Parkour mechanic is implementing some IK motion and wants to blend it with animations.  They're not sure what will look good or what type of animation or blending will be needed, or even if they'll have time to iterate on animations once the IK is in place.  Rather than try to plan all the work out on the first day of the sprint, they'll spend an hour and identify the initial tasks to try IK in place.  Near the end of the week, they'll spend another hour discussing their progress and identifying the next steps to take, including what animations they'll want to try blending in.

Note: there will likely be other stories for the animators to work on or they will be shared with another team.

By spending a quarter of the time, the team will have more time to spend on the feature and actually identify the work more accurately: it will respond better to the emerging mechanic and iterate more effective, rather than relying on the initial plan being correct, which was based on a good amount of assumptions.

So why don't more teams do this?
  • Trust: Management often wants to see a detailed plan coupled with a firm commitment to achieve that plan.  They don't yet trust the team to "wing it" with uncertain features.
  • Certainty is preferred over maximizing player value: Many organizations are task focused: a developer's success is measured by how well they meet their scheduled assignments.  Using an emergent sprint backlog requires a "value added over task estimate" approach acknowledging that work emerges to achieve a value focused goal.  This requires the ability for the team to safely say "we don't know".
An emergent sprint backlog requires improving trust and leadership.  Leaders need to move from being remote task managers to local mentors helping developers become better at:
  • Responding to emergence
  • Being accountable to value and quality
  • Communicating with courage, rather than hiding behind a task list out of fear.
This takes time, but it is well worth it.

Thursday, May 15, 2014

Win-win: Great teams make better games and enjoy making them!

Have you ever been a part of an amazing team: a team where work flows and time flies; you have to drag yourself away at the end of the day and come rushing back the next morning  filled with ideas?  If you’ve worked long enough making games, you may have experienced being on such a team (called a “great team”) and know that such experiences are not only the ones we want, but lead to better games.

Great teams:
Don’t get me wrong.  We’re not talking about singing Kumbaya in a circle.  Great teams can be messy, chaotic, noisy and drive each other crazy from time-to-time.  They focus on the game and communicate candidly with one another, even when hard things need to be said.  Great teams often happen by chance, when the right mix chemistry, experience, and skills come together, but when left to chance, it doesn’t happen very often.

During the past ten years of training and coaching, I’ve observed how some studios “get it” and foster great teams, while others haven’t learned to.  This article is about the differences between the two.

How to Improve the Creation and Support of Great Teams

There are better ways to foster great teams than chance.  Models such as Situational Leadership, Tuckman as well as others are useful for leadership, but like any model, they are imperfect.  People are not systems that can be so easily predicted and manipulated, but there are basic tools leaders and coaches can use to foster great teams:
  • Keep teams small.  Plenty of research has shown that teams that are too large simply don’t communicate well.  They stop being teams and become groups, which have less cohesion.
  • Coach interactions based on the maturity level of the team.  Some teams need a good deal of coaching, while others need a light touch.  
  • Make changes where necessary.  Sometimes, despite coaching, the chemistry isn’t working for a team.  Before it irrevocably damages the team, mix the membership up a little.  It’s amazing how much a so-called “bad team member” can become someone valuable for another team.
  • Give the team more autonomy.  As a team grows in maturity, they’ll begin to coach themselves and even influence their membership.  Let it happen.
None of this is tied to any methodology or framework, but a framework can help by establishing a common vocabulary and set of interfaces as a starting script to know when and where coaching occurs.

Agile, and Scrum specifically, are frameworks for supporting such teams.

Some of you might not agree with this.  What you’ve seen or were told was that Scrum is a hard-core set of rules to follow.  It’s too bad this view exists.  It follows from bad implementations and it’s doing real damage to the aim of supporting great teams.

For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intellectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans.
- Ken Schwaber, Agile Project Management with Scrum

How Scrum Values Bridge Methodology and Great Teams

“Grand principles that generate no action are mere vapor. Conversely, specific practices in the absence of guiding principles are often inappropriately used.”
- Jim Highsmith, Agile Project Management: Creating Innovative Products (2nd ed.)
  • How does standing around in a circle answering three questions a day increase productivity?
  • What practices do we need to follow to make great games?
  • What metrics or tools do we use to ensure we’re making a hit game?
  • How does a good process avoid making mistakes?
These are nonsensical questions.  There are no silver bullet practices and when teams follow good practices without heart they gain little value.  Great teams examine each practice in light of how it allows them to work better.  That said, there needs to be some underlying set of values that drive decisions about practices.

Values are a foundation that are important to people .  For example, the value of respect is important to us all.  I want others to respect my work and I can assume that others want the same for theirs.  How does that value guide our day-to-day behavior?  One way is in how we respond when someone makes a mistake.   When someone makes a mistake, we might have one of two reactions.  The first is that the person who made the mistake was lazy, dumb or incompetent.  The second is that the person who made the mistake didn’t have all the information necessary to do the right thing.  By valuing respect, we’ll intrinsically choose the second reaction.  Valuing respect when mistakes are made avoids the fear of making mistakes that can kill experimentation and learning in studios.  The signs are unmistakable:
  • Highly detailed Gantt charts and documents are created, not to predict the future, but to protect middle management from blame as reality emerges.
  • Bloated processes emerge, built from practices and rules created in response to every past mistake, in hopes that those mistakes will be avoided in the future.
Scrum’s Values
Scrum has five values, which underly the reasons for all the practices and direct how teams are coached:
Respect - Teams share successes and failures and work together to increase respectability, rather than creating an atmosphere of blame and fear.  Respect builds trust.
Courage - Teams challenge themselves and their studios to find ways to work better and to create a better working environment.
Focus - Teams focus on building a few things at a time .
Commitment - Teams commit to building games with quality and become accountable to one another and their results.
Openness - Teams operate with transparency, sharing good news as well as bad to make better decisions faster.

These values not only explain the reasons while a daily scrum is standing-only and time-boxed, but are a foundation for every change made to customize the practices.  For example, some teams will do a quick play-though of the game at the start of a daily scrum because it improves focus, openness and commitment.  Other teams move to an electronic tool to update daily progress and might diminish those values.  A coach (or ScrumMaster) helps guide the team through these decisions by keeping these values in the forefront.

Why is it so Hard to Do This ?
When I was three years old, my father tried to teach me how to swim using the same method his father had used: He threw me into a local lake off the end of a long pier and expected me to learn.  Sadly, that day I wasn’t going to learn to swim before drowning and he had to rescue me.  I’m told that I avoided the water for the next few years.

I didn’t use this approach with my own sons.  Instead my wife and I brought them to a swimming instructor, who started them off in shallow water, learning to put their face in and blow out bubbles.  Later lessons grew skills, while managing fear.  I wanted my sons to have a healthy respect for the dangers of water, but I didn’t want them paralyzed with fear and not experience the joys of surfing, diving or just cooling off on a hot summer's day.

Unfortunately, I didn’t apply this approach with my first Scrum team.  I applied dad’s approach of tossing them off the pier.  This involved handing them copies of a book and telling them to “follow the rules”.  Fortunately, the team didn’t “drown”, but they were terrified of all this “agile stuff”.  They clung to the rules, deathly afraid of what book I might read next.  They learned the equivalent of  “treading water” and that was all.

I’m a slow learner, but I eventually correct my bigger mistakes.  For the next team adopting Scrum, I behaved less like my father and more like the swimming instructor.  I had them attend some training to get the big picture, learn the vocabulary and to acquire a vision of what we hoped to achieve using Scrum.   We (management) worked on basic, “safe” practices, such as having leads sit with junior developers to help them estimate a sprint.  The team didn’t commit to a certain number of features for their first sprint, but accomplished what they could.  We measured those features that met a reasonable definition of done and used that metric as a basis for planning future sprints.  In carefully facilitated retrospectives, we listened to their feedback about what worked and what didn’t and agreed on some easy-to-achieve actions.  Slowly, we backed off our involvement and let them assume more responsibilities.

The results for this team were far different than those of the first.  The second team felt empowered with a sense of ownership and were less fearful of change.  This team frequently changed their environment and practices.  They even made demands on management, such as having someone from QA join their team.  The only intervention we found necessary was when, in deciding to tear down cubicles, they exposed live electrical wires and were about to fix the problem directly!
There are too many leaders that don’t understand how to approach this fundamental change.  It has to be done with safety and respect.  I count myself as one of these who has hopefully mended his ways.  I don’t blame others who are stuck in a command-and-control mode because, like my father and myself, they come from a long line of “doing things the way they learned how to do them”.  Breaking this cycle is hard, but rewarding.

You may think this is a bunch of feel-good hand-waving and we should just focus on making games without worrying how, but consider this:   At the end of your career, when you recall your life in game development.  Which do you think will weigh more in your thoughts:  The games you made or the people you made them with?

“Here’s what we all know, deep down, even though we might wish it weren’t true: Change is going to happen, whether we like it or not. Some people see random, unforeseen events as something to fear. I am not one of those people. To my mind, randomness is not just inevitable; it is part of the beauty of life. Acknowledging it and appreciating it helps us respond constructively when we are surprised. Fear makes people reach for certainty and stability, neither of which guarantee the safety they imply. I take a different approach. Rather than fear randomness, I believe we can make choices to see it for what it is and to let it work for us. The unpredictable is the ground on which creativity occurs.”
Ed Catmull  Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True

Games are dependent on the individuals, leaders, teams and cultures that create them.  Game development will always be uncertain and lack the level of predictability we might crave, but when we push for more predictability than our existing knowledge allows we start to do harmful things to our culture, ourselves and the teams we lead.  Rather than trying to create certainty with random teams, we need to be setting great teams loose on uncertainty.

It's a win-win: Great teams make better games and enjoy making them!

Thursday, May 01, 2014

The Four Phases of Video Game Development

  1. “Our game will do everything and sell ten millions units” design phase 
  2. The disposable-code greenlight phase
  3. Bug introduction architectural phase 
  4. Creating content "because the schedule says" phase 
  5. Fixing content created too early phase
  6. Fixing code that should have been thrown out after greenlight phase phase
  7. The marketing reset phase
  8. Death march to gold master phase
(inspired by @imccowatt)

Wednesday, April 30, 2014

Drowning in Scrum

This might have been the actual pier
When I was three years old, my father tried to teach me how to swim using the same method his father had used: He threw me into a local lake off the end of a long pier and expected me to learn.  Sadly, that day I wasn’t going to learn to swim before drowning and he had to rescue me.  I’m told that I avoided the water for the next few years.

I didn’t use this approach with my own sons.  Instead my wife and I brought them to a swimming instructor, who started them off in shallow water, learning to put their face in and blow out bubbles.  Later lessons grew skills, while managing fear.  I wanted my sons to have a healthy respect for the dangers of water, but I didn’t want them paralyzed with fear and not experience the joys of surfing, diving or just cooling off on a hot summer's day.

Unfortunately, I didn’t apply this approach with my first Scrum team.  I applied dad’s approach of tossing them off the pier.  This involved handing them copies of a book and telling them to “follow the rules”.  Fortunately, the team didn’t “drown”, but they were terrified of all this “agile stuff”.  They clung to the rules, deathly afraid of what book I might read next.  They learned the equivalent of  “treading water” and that was all.

I’m a slow learner, but I eventually correct my bigger mistakes.  For the next team adopting Scrum, I behaved less like my father and more like the swimming instructor.  I had them attend some training to get the big picture, learn the vocabulary and to acquire a vision of what we hoped to achieve using Scrum.   We (management) worked on basic, “safe” practices, such as having leads sit with junior developers to help them estimate a sprint.  The team didn’t commit to a certain number of features for their first sprint, but accomplished what they could.  We measured those features that met a reasonable definition of done and used that metric as a basis for planning future sprints.  In carefully facilitated retrospectives, we listened to their feedback about what worked and what didn’t and agreed on some easy-to-achieve actions.  Slowly, we backed off our involvement and let them assume more responsibilities.

The results for this team were far different than those of the first.  The second team felt empowered with a sense of ownership and were less fearful of change.  This team frequently changed their environment and practices.  They even made demands on management, such as having someone from QA join their team.  The only intervention we found necessary was when, in deciding to tear down cubicles, they exposed live electrical wires and were about to fix the problem directly!

There are too many leaders that don’t understand how to approach fundamental change.  It has to be done with safety and respect.  I count myself as one of those who has hopefully mended his ways.  I don’t blame others who are stuck in a command-and-control mode because, like my father and myself, they come from a long line of “doing things the way they learned how to do them”.  Breaking this cycle is hard, but rewarding.

Friday, April 11, 2014

Feature Cards

My previous article described Feature Boards, a variation of task boards that some agile game teams find more useful.  The main difference between a by-the-book task board and a Feature Board is that task boards contain task cards, which are markers for individual tasks the team foresees will be needed to complete a set of features,  while a Feature Board contains Feature Cards, which are markers for the features themselves.  This article describes a typical Feature Card.

An example Feature Card

The above card shows some typical elements:

  • Card Color: Using a simple color priority scheme (e.g. red, yellow, green) can help teams decide the order of features to work on based on their priority in the backlog or any dependencies that exist between them.
  • Title:  In this case “Jump”.
  • Description: Very often written in a User Story format.  This briefly describes the feature from the point of view of the user, such as the player .
  • Acceptance criteria: While planning an iteration, teams will capture some unique aspects of the feature that will need to be tested.  For example, it might be important to the product owner that the blending of animations be smooth and without popping.  Someone, usually a tester, will write this criteria the back of the card to remind the team to test the feature to ensure there is no popping while jumping.
  • Start and End Dates: It’s useful to capture the day when the team starts working on a feature and when it’s done.  As mentioned in the article about Feature Boards, it’s not best to work on too many features in parallel during an iteration.  Using the dates will allow a team to measure how much work in progress is occurring during the iteration.  I’ll describe how this is used in an upcoming article on Feature Board Burndown Charts.
  • Estimates: As a part of iteration planning, each discipline will discuss the plan for implementing their portion of the feature and may want to capture some time estimates.  Some teams use hours, some days, while some teams will skip estimates altogether.  Capturing discipline estimates rather than individual estimates increases collaboration among members of the same discipline.  These estimates are used to track whether an individual discipline is at capacity or not while features are planned.  For example, if a team is finding that the sum of all animation work across all features adds up to more time than their one full-time animator can handle, they’ll find another animator to help them or they’ll change which features they commit to.
  • Tasks: Tasks captured during planning or during the iteration can be annotated on the card with smaller post-its or, by using larger cards, be written on the cards themselves.  If you use post-its, make sure you use the brand name ones with the good glue!
  • Card Size: Feature cards are usually written on a 3x5 or 4x6 index card.  


The sky is the limit on how to format these cards.  For example, some teams record the story points or t-shirt sizes on the cards and don’t use time estimates.  Some teams will break down larger features into sub-features and track the completion of those.  The key is to collect meaningful metrics that are part of an ecosystem to help the team better plan, execute and deliver features at ideal quality.


We’ll look at an optional burndown or throughput tracking chart.

Monday, April 07, 2014

Feature Boards

A challenge in agile game development is managing cross-discipline teamwork where a wide range of skills is required.  As a result, following some practices and artifacts by-the-book doesn’t work as well as it does for software-only teams.  One of these artifacts is the task board.  These boards are used for teamwork transparency during an iteration and are a tool for the team to manage their day-to-day progress.  However, for a highly diverse game team, task boards are often modified.  This article is about one such modification, called a “Feature Board”.

Task Boards

A strength of the physical task board is that the team owns it.  A physical task board is always visible and requires no licenses and little training to use.  The only limitations are that it requires wall space and team collocation.  The photo above demonstrates some example modifications made by the team using it, such as adding columns for verification or colored cards for tracking different types of work (e.g. emergent work, bugs or impediments).

A problem that boards like this encounter is the lack of visibility of cross-discipline dependencies.  For example, let’s say a team is working on a number of player mechanics in an iteration, such as jumping, crawling and ducking.  There are three programmers and one animator among the team.  Halfway through the iteration, the programmers have the code working, but can’t fully test it because the animator is backed up with too much work.  Perhaps the animator is trying to work on all three mechanics at once or the task of animating one mechanic is harder than they thought, or there is a problem exporting the animations.  Creating awareness of these problems is one of the functions of the daily stand-up meeting and a mature team will address them, but sometimes a problem like this doesn’t surface until it’s too late in the iteration to do anything about it.  This is one instance where a Feature Board can help.

What is a Feature Board?

A simple Feature Board looks like this:

Instead of tracking tasks, a Feature Board visualizes feature development state.  The iteration (or Sprint) goal is on the left side and contains cards identifying features the team committed to implementing over the next 2-3 weeks.  The cards move around the board (not just left to right) during the iteration, depending on the work that is being done.  Each column on the board indicates the type of work being done on the feature at the moment.  The rows show which features are in progress and which features are waiting for work to be done.  As features are completed, they exit to the right of the board into the “done” column.  In this particular example, the features are prioritized in value.  Red features are the most important.  Green features are the least important and yellow are in-between.

How is a Feature Board used?

A Feature Board serves the team.  It shows them the state of each feature on a daily basis and leads to conversations that are necessary for a cross-discipline game team.

Take a look at the board above.  The board is telling us that the jump feature is having some coding done, while melee is getting some animation.  There are a few bug fixes that need to be done and one of them is being worked on by both a designer and programmer.
The board also raises questions.  For example:

  • Are the testers overwhelmed?  It looks like they have test work piling up.
  • What is the modeler doing?  Have they run out of work?
  • Why are lower priority features ready for test?  Why are they ahead of higher priority features?

The board won’t answer those questions, but quickly highlight them for the team to answer.

What are the benefits of a Feature Board over the by-the-book Scrum task board?

Feature Boards focus on feature progress, not task progress.
Too many times, teams get focused on completing tasks in any particular order and don’t worry about features being “done” until the end of the iteration.  Postponing “done” means features don’t get enough polish and tuning time.  As a result, teams release lower quality features.  Feature Boards focus the team on completing prioritized features over merely completing tasks in any particular order.

Feature Boards help balance cross-discipline teams.
Unlike software-only teams, a cross-discipline team of game developers can’t share as much of their work (e.g you really wouldn’t want me creating a texture or a sound for your game).  So it’s important to quickly identify problems with the flow of work.  Task boards don’t do this well;  They don’t visualize stalls and backups.  As a result, individuals end up solving problems by working on more things in parallel, leading to late integration, testing and tuning.  Feature boards show, dramatically and frequently, where the stalls are occurring, or soon to occur, which focuses a team's response.

Feature Boards help limit Work-in-Progress (WiP).  
In order to complete features sooner in an iteration, a team needs to work on fewer features in parallel and address issues or workflow problems that are stalling work or wasting time.  By separating the “In Progress” features from the “Waiting/Blocked” features, a team will see where work is piling up quickly enough to be able to do something about it.  Teams can even institute “WiP Limits” on the columns or rows to stop any new features being added when work is piling up too much.  This leads to different behaviors.  For example, when the team sees that testing work is piling up above, others in the team can help out.  There is no law of nature that says “only testers can test”.  By embodying WiP limits, Feature Boards can be a tool for encouraging such “out of the box” thinking.

“This looks like Kanban!  Why not just use Kanban?”
Some of these ideas come from Kanban (like WiP limits), but it’s not Kanban by-the-book.  While Kanban by-the-book is great for some work—work that is less exploratory, or follows a predictable flow of hand-offs from one discipline to the next—the Feature Board is better for teams that are working on unpredictable new features and “first-time” content.  Feature Boards fit best within a time-boxed iteration which has a lot of “swarming”.  “Swarming” means that there is an unpredictable flow of work between disciplines to create a feature and the feature will bounce around or iterate unpredictably before the fun is discovered.

Own It

The bottom line is that I don’t care what label you use (Kanban, Scrum, etc).  You need to find what works regardless of where it comes from and keep finding ways of making it work better.  That’s the agile mindset.

See Also

Friday, April 04, 2014

Situational Leadership and the ScrumMaster

After I recently posted an article called "An Introduction to Situational Leadership", I was contacted by Randy Baker.   Randy lived nearby and had worked with Dr. Paul Hershey, the developer the initial Situational Leadership (SI) model, for 20 years.

In the original article, I shared an illustration of the levels of team maturity:

I described to Randy, how the ScrumMaster role is meant to help teams reach higher levels of maturity by, at first, directing less and then delegating more.  Randy then drew the following diagram (it was, literally, on a Starbucks napkin so I've redrawn and added it to the diagram above):

The diagram shows the relationship between a leader in the SI model and the team, based on their maturity.  This diagram resonates because it matches the formations you'd observe in a Daily Scrum based on the maturity of the Scrum Team.

Scrum attempts to bootstrap a Scrum Team into the "high supportive behavior" side (top half).  Very often a studio's culture will be more directive going in, and you'll initially find teams reporting to the ScrumMaster, who is running the meeting (the "Coaching" quadrant in the upper right) at the center of a group of developers.  Over time, a good ScrumMaster will improve their facilitation skills and support (upper left quadrant) the team as an equal member, standing as a part of the team's circle.

As a Scrum Team develops their maturity and becomes more self-organizing, the ScrumMaster will delegate more of their day-to-day duties, but always observe and support the team (lower left quadrant).

Any team that finds themselves in the lower right quadrant is not "doing Scrum" yet.

Thursday, April 03, 2014

The Stages of Agile Success

Achieving the full benefit of agile requires a long-term commitment to change.  Applying the basic practices, such as answering three questions for 15 minutes a day, is simple, but adopting the mindset of self-organization, continuous improvement and building a culture of engagement, trust and respect is challenging.

The Three Stages of Agile Adoption

Over the past decade, I’ve witnessed common patterns of successful agile adoption and have grouped them across three stages[1] shown below, which I call the apprentice, journeyman and mastery stages.

When speaking about agile, we're talking about the agile values and principles.  How these are embodied in your day-to-day practices depends on your culture and the framework for your process.  Scrum is one such popular framework, Kanban another.  These frameworks are great scripts for starting agile, but over time teams change the practices and even blend them.  In this article, I'll mainly use Scrum terms, but your terms may vary.


Teams that are newly formed and/or are new to agile aren't expected to apply agile practices very well at first.  They need constant coaching as they struggle to figure out who does what and when[2].

Apprentice teams learn how to deliver features at a regular cadence and apply new roles such as Product Owner and ScrumMaster.

I prefer to see apprentice teams follow the practices, such as those of Scrum, “by the book”, because changes at the start of Scrum adoption are usually done to conceal problems Scrum exposes.

Effective Daily Stand-ups
One example of abandoning a practice too early is when teams skip the daily stand-up meeting because they feel an electronic tool is better for reporting task status.  Reporting task status is a part of the stand-up, but it is not the primary purpose and so something is lost.  The daily stand-up is meant to align a cross-discipline team to their daily priorities, revisit their commitment to their sprint goal and recommit their accountability to delivering quality features.  Thinking that it's all about task reporting is a vestige of a task-assignment culture and it takes a while to change this mindset.

Cross-Disciplined Teams
Forming cross-discipline teams that can commit to goals is critical to early adoption.  Departmental or siloed organizations will resist the formation of cross-discipline teams.  Not only do department managers fear losing control, but developers themselves will resist being teamed with those outside their own discipline.  Yet, if cross-discipline teams don't form, then the weight of dependencies and the inability to deliver a demo-able game every iteration, will prevent most of the benefits found with agile.

Well formed cross-discipline teams can take more ownership of their goals, which leads to more effective problem-solving and higher productivity.

Established Roles
Roles, such as Product Owner and ScrumMaster, are meant to balance the need to build the right features in the right order and in the right way.  The roles are separated, because they often come into conflict with one another and need to be balanced for there is a fine boundary between building features faster through improvements to productivity and building features faster by dropping quality.

Realigning existing roles with the new ones take a while to establish and even longer for the teams to understand how they are meant to function.


When agile teams create a definition of done and start altering their practices to achieve it every iteration, it's a signal that they are entering the Journeyman stage.   The following areas of development maturity are common with Journeyman teams.

Leaner Designs
Through close collaboration, Journeyman teams reduce handoffs of written design documents and concept art.  For example, instead of a dozen storyboards for a level, a concept artist will draw half as many and spend more time working directly with the level artists and designers.  In this way, all disciplines can more effectively collaborate and iterate on more emergent and higher quality levels than a one-way handoff of concept art would allow.

Faster Integrations
As cross-discipline teams iterate more, the inefficiencies of practices such as branch-and-merge and hand-testing everything are replaced by practices such as continuous integration, test servers, unit testing, etc.  These practices allow more iterations on up-to-date assets and code throughout the day.  The ability to iterate more frequently contributes to higher quality.

Better Testing
As mentioned above, faster integration requires improved testing practices, such as test servers.  Additionally, Journeyman teams will increasingly integrate members of QA onto their team.  This will lead to further refinements of the definition of done.

Release Planning
As journeyman teams improve their definition of done, agile estimation techniques can be employed to produce a more reliable forecast about the schedule, cost and scope.


Mastery is a stage occupied by so-called hyper-productive teams.  These teams hold themselves accountable to their results, practices and organization.  For teams to enter this stage, they must have an established level of trust within the organization and be allowed to achieve higher levels of self-organization.

100% Customization
Sometimes, when I visit a team that has been effectively inspecting and adapting agile and Scrum practices for a while, it’s hard to say “they're doing Scrum” anymore.  They completely own their work, and take much pride in it.

The goal of Scrum is to leverage the power of small, self-organizing teams to maximize the value they create.  By giving teams and individuals more freedom to make decisions about their work and providing structure, coaching and mentoring, their work becomes far more focused and meaningful.

Studio culture and structure are often barriers to this “low constraint” form of self-organization.  Fortunately, as more studios emerge that demonstrate the value of this approach, the acceptance and proof of it will continue to grow.

Continuous Improvement
Following a set of prescribed practices isn’t the goal.  The goal is continuous improvement.  Markets and technologies change.  Individuals change.  Processes have to change as well.  There are no "best practices" because the word "best" implies that there are no better.

It's Not Easy, but it's Rewarding

The agile state of mind challenges our beliefs and assumption and insists that we continue to challenge them.  It flat-out defies the persistent superstition that we can treat creative people with the same tools that make machinery more productive, that we can add more people or add more hours they work or write bigger planning documents, which will result in more output.  People are far more complex.

It makes us coach, listen, challenge, inspire, care, respect, and collaborate in ways we were never trained to do.  It's a lifetime challenge with no finish line in sight.

[1] These are not unlike the three stages of martial art mastery called “ShuHaRi”
[2] This is not inherent to Scrum teams, all new teams go through a settling phase.  Google “Tuckman’s stages of group development” for more on this.

Tuesday, April 01, 2014

Agile & Levels of Planning

Recall the last time you took a long driving trip.  You probably came up with a plan for the trip.  You used Google Maps to explore various routes and distances.  If the trip took a couple of days, you reserved a decent motel along the way.  Before the trip began you filled the gas tank and printed a map.  You even might have planned to leave your home earlier or later to avoid rush hour traffic along the way.

When the day to travel arrived, you reset the odometer, set up the GPS and off you went.  However, the job of planning wasn’t complete.  There might be detours along the way.  Frequent glances at the odometer or GPS might inform you that you are ahead or behind schedule.  Also, the map and GPS aren’t enough.  You monitor your speedometer from time-to-time and constantly look out the windshield and at the mirrors in case another driver does something unexpected.

We use all these different measures and methods to maintain a plan and respond to change for something as predictable as driving.  We need similar tools for the far more complex and uncertain endeavor of making a game!

Figure 1 - Planning Onions for Driving and Games

The figure above shows “the planning onion”, which represents the different layers of planning frequency.    The inner layers of the onion are the more frequent inspection tools/cycles, while the outer layers encompass tools applied less frequently.

Layers of Planning
Let’s examine the layers of planning from the inside out using the driving example for comparison with how a Scrum-developed game would plan:

  • Daily - The team will meet every day in a daily Scrum to discuss the progress and issues which are affecting their Sprint goal.  This includes conversations about bugs, impediments, dependencies, or merely points about the quality of the game.  This is like looking out the windshield of the car during your trip.
  • Sprint - The team, product owner and domain experts forecast what is possible to accomplish in the next one to three weeks.  The duration of the sprint largely depends on how much certainty the team has with the work and how long the stakeholders can go without seeing something.  A team will forecast and track the work in any way they want for the sprint.  Some teams use hours, others days, while some teams will come up with their own units[1].  This compares to using the speedometer in your car to measure you velocity.
  • Release - The team, stakeholders, marketing and leads identify stretch goals for the game that they hope will be demonstrated in a “shippable build” at the end of the release.  Product owners might alter these goals during the release as quality, cost and true velocity emerges.  Forecasting and tracking during a release is usually done using metrics that size the features on the backlog (e.g. story points).  This level of planning and tracking is comparable to using an odometer during your drive.  The odometer gives you a more long-term view of velocity when miles are measured against larger units of time, such as hours and days.
  • Project - For a cross-country drive, you’ll likely have a map and a rough idea of your progress and stops along the way.  You may have a gas budget and looked online to see where major construction delays  might occur on your path.  If asked where you expect to be tomorrow night, you’d have an answer like “Denver”.  If asked where you would be at 2:15 PM tomorrow, you might not be much more precise.  Long-term project planning should be like this.  It focuses on the major cost, schedule, and feature goals and identifies significant areas of risk.  Similarly, long term planning will break out epics and define some constraints based on experience.  An example for “online multiplayer gameplay” might be:
    • Cost: 10 people for six months to implement and 20 people for six months to produce content.
    • Schedule: Starting in June, finishing in 12 months.
    • Risk: Online technology risks and core gameplay risks.

Just as we don’t forecast our speed down every mile of road while planning a cross-country drive, a long project shouldn’t forecast what teams will be working on every day for a year or more[2].  Instead, as the planning horizon extends out, the metrics for planning become larger grained and less precise.  There are a few reasons for this:
Reason 1: The further out our plan goes, the more uncertainty there is with the details.
This is best illustrated with the cone of uncertainty shown in Figure 2:

Figure 2 - The Cone of Uncertainty

This figure illustrates that the further we are from shipping the game, the more uncertain its cost, scope and schedule.  Everyone who has shipped a game should recognize that the great concept art and ideas and plans expressed in the initial design documents usually don’t resemble the shipped game very closely.  This is not a bad thing.  This is the nature of creating complex games that have a subjective and emotional dimension.  We simply can’t “plan away” this complexity and uncertainty.  This doesn’t mean we can’t plan.  It means we need to plan at a level appropriate to the level of certainty that exists.

Reason 2: Simply breaking down a long term plan into finer details won’t give us more certainty, it’ll give us less uncertainty and waste our time doing it.
 This is the hardest to convince people of.  The assumption is that a 300 page design document creates twice as much certainly as a 150 page design document.  When I worked in the defense industry, this assumption led me to create a 40-pound specification document for an Air Force contract.  The Air Force wanted so much demonstrated certainty from their contractors, that they received documents so big they couldn’t read them[3].

However, numerous studies have shown[4] that not only is uncertainty not reduced equally with more planning effort but, beyond a certain point, the attempt to plan away uncertainty with more effort (documents and spreadsheets) produces forecasts with less accuracy (see Figure 3).  The reason that a bigger plan creates less accuracy is due to human nature.  It’s in our nature to see a big document and turn off our critical thinking, just as the Air Force did when they saw our 40-pound document.  Had they read that document with a critical eye, they would have quickly found out that it was a rushed cut-and-paste job by a junior engineer.  Instead, they simply weighed it and awarded us the contract.

Figure 3 - The Accuracy of Planning Based on Effort

The tools that we choose, based on where we are in the planning onion, help us stay in the ideal range of precision, which gives us the best amount of accuracy without wasting effort.

[1] I’ve seen some teams estimate in “NUTS”, which stand for “nebulous units of time”.
[2] Although I’ve seen some producers try to do this!
[3] Ever wonder why new fighter aircraft are years late and billions over budget?
[4] One of many quote is

Sunday, March 09, 2014

No estimates and set-based design

I’ve been following the #noestimates discussion on twitter over the past few months.  I understand the reasoning on both sides of this divisive topic of whether teams should estimate or not.  My opinion on the topic is that the time spent on creating estimates and planning diminishes as a team gains maturity.  Mature teams create a more intuitive and reliable way of figuring out how to work, their velocity is superb and reliable and there is trust created in the organization that replaces the need to insist on such up-front commitments.  There are a number of benefits to this.  One benefit is that the time spent creating estimates is now time spend doing the work.  The second, and most significant benefit, is that the options and possibilities remain open longer when mature and trusted teams do not commit to a single solution early on.  This is the type of difference described in my book between point-based design and set-based design and a concept I wrote about in 2006.  Point-based design is where a single point is selected from a cloud of possibilities.  When we create a detailed estimate, we are selecting a narrow range of solutions from a larger set; we are deciding how to do something up front.  Everything outside that range (or point) is discarded.  The further out these estimates go, the larger the range of discarded possibilities become (referred to as the cone of uncertainty).

Set-based design is the idea that we keep considering the set of all possible solutions until we learn more through execution.  A classic example of this is the design of the Toyota Prius.  The vision for the Prius was for a “green car”, but the decision of whether to use a efficient gas, all electric or a hybrid power-train was deferred until all possibilities were explored to the point of knowing about the efficiency and production cost of each.  As a result of this approach, this revolutionary car was designed in half the time of more conventional designs.

Avoiding detailed estimates supports set-based design by avoiding the early, uninformed, commitment to a single solution that is required to assign a number (hours, days, points).  As mentioned, a no-estimates approach only works with a mature team.  The team has to execute in a way to produces the knowledge to refine the set of possibilities first.

For a game mechanic epic, this means that the team finds a way to demonstrate the core gameplay of the mechanic first and refines it every iteration.  Teams that build a bunch of parts of the mechanic that  later integrates into a fun experience are really doing point-based design; they are choosing the solution first.

From experience, I’ve learned something which sounds intuitively wrong at first:
Set-based design is one of the biggest cost savers you will find.

As demonstrated, it halved the design of the Prius for Toyota.  I’ve seen the same on game teams.  Set-based design forces teams to focus on the simplest things first and to maximize the work not done.  An example I’ve seen is with complex AI systems.  Many games start off by creating a list of everything the AI has to do in the game (point-based design).  Then an AI engine is created to do them.  Although integration is frequent, the AI isn’t really demonstrating emergent value to the player yet.  It’s a “work-in-progress that will payoff before alpha”.  Somewhere on this road to value, there is a major rewrite of the AI, a reduction in the AI requirements or an admission that “our game’s AI is not going to be very good”.

A set-based approach to this problem starts with asking “what does our AI need to do first?”.   The answer shouldn’t be “create path-finding NPCs”.  The player doesn’t care about the NPCs path-finding if they don’t add anything to their experience.  Perhaps having only NPCs that are close by and interact in a meaningful way is enough.  Maybe we’ll discover that we don’t really need them to path-find as much or in the way we'd planned.   Maybe there’s some “little trick” we can do to make the player think the NPCs are doing something complex when they are out of sight.

The additional benefit of a set-based approach is that the team is much more connected with the game.  They are asking themselves “how do we make the game better” daily.  This is better than the question being asked once every two weeks during sprint planning and far better than asking once every three months during release planning!  Teams that are more connected to the game have increased opportunities to add value and subtract work that doesn’t need to be done.

Again, I want to emphasize that abandoning estimation is not the goal, but a side effect of teams maturing.  The goal is to coach teams to maturity and continuous improvement.  When I train new teams, I don’t train them to abandon estimation.    That would be like training a snowboarding novice to do a 1080: it’s a fast path to crashing.  When a team has reached a level of maturity, they’ll find this on their own (with a bit of coaching along the way).

Saturday, March 08, 2014

Productivity is a function of engagement, skill and accountability

Productivity is a function of engagement, skill and accountability.  Engagement, skill and accountability are cultivated through trust and respect.  Trust and respect are the foundations of a culture.  Studios with a foundation of respect and trust demonstrate it by investing in the growth of their people, not by treating them as capital resources that can be added or laid off to hit goals. They treat mistakes as opportunities to learn.  

Tuesday, February 11, 2014

How Do You Turn a Vicious Cycle of Distrust Into a Virtuous Cycle of Trust?

Very often, I see this cycle occurring in studios:

I call this the "Vicious Cycle of Distrust".  Having been on both sides of this cycle, I'm quite familiar with the damage it does to a culture.

I've also seen the reverse of this cycle, I call a "Virtuous Cycle of Trust":

I've changed the term "management" to "leadership" because a significant purpose of leadership is to drive this cycle, to create safety and purpose.  I've also called out "teams and individuals" rather than "developers" because the two act differently and teams are ideally more capable than just the sum of individuals.

I've also left some question marks at the interfaces as a question to you.  What are the interactions and values that need to occur to drive a virtuous cycle of trust?  To me these include:

The Scrum Values

  • Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
  • Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
  • Openness. As we work together, we practice expressing how we're doing, and what's in our way. We learn that it is good to express concerns, so that they can be addressed.
  • Commitment. Because we have great control over our own destiny, we become more committed to success.
  • Respect. As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.
What else have you seen that drives a virtuous cycle?

Tuesday, February 04, 2014

Tunnel Vision Product Ownership

"640K ought to be enough for anybody." - Bill Gates (supposedly said) in 1981

No vision is perfect, but sometimes the hardest person to convince of that is the visionary.  Given that a shipped game rarely resembles the original detailed design document, an equally detailed and prophetic vision buried inside someone’s head can be just as capricious. A common result is that the emergent gameplay quality is not taken into account and teams become disengaged.

I call this dysfunction “tunnel-vision” product ownership.  It’s common in studios transitioning from a design-document approach to an agile one.  Although the visionaries admit that detailed design documents fail to create a shared vision, they haven’t yet adopted an agile mindset which requires:
  • Frequent face-to-face engagement with developers.
  • The ability of teams to produce iterations of an emergent game that validates the vision (or not).
  • The ability of the product owner to evaluate their vision against the emergent game.
This leads to a major of pattern of dysfunction called:

Parts on the Garage Floor
The product backlog become a component list of features and functions that are necessary to fulfill the vision…someday.  This reminds me of someone building a prototype car, part-by-finished part.  They build a carburetor, then the tires, etc.   Eventually, when all the parts are built, an assembly phase is entered.  Even if all the parts fit together, it rarely results in a very functional car (check out how cars should be prototyped -

The same thing happens on games.  The following practices are seen with the parts on the garage floor dysfunction
  • There are too many component (or functional) teams.  Examples:
    • AI team
    • Animation team
    • Design team
    • Graphics team
This is not to say that component teams are all bad.  Often they are necessary, but when a majority of a project is composed of component teams, it usually results in delayed integration and knowledge (i.e. debt).
  • Crunch sprints (usually called something else) with lots of overtime, little velocity or just tackle user stories created to address debt (refactors, bug fixes, polishing, etc). If most user stories don’t read like features users would pay for (e.g. I wouldn’t buy a game based on how many bugs the team fixed), it’s generally a strong indication that a good definition of done is not in place, teams are doing a lot of component work or debt is piling up,
  • Team disengagement - Teams that don’t have a tangible vision or one that is months away from being realized have a hard time engaging in their work.  This is especially true on larger projects.  Nothing will drag velocity down more.
Addressing Tunnel Vision
As with any cultural issue, tunnel vision is hard to fix.  Transforming a detailed-design-document focused culture to one of frequent communication and inspection doesn’t happen overnight.  There needs to be some bridgework between the two.  Before the documents are shrunk, the product owner needs to gain skill in communicating vision and in learning to respond to the emergent game.  To start with, I’ll find ways to improve communication in sprint planning, reviews and retrospectives.  Establishing a better definition of done, and phrasing the sprint goal in terms of true value (e.g. “what are we going to be able to play at the end of the sprint”) sets the context for what is expected (in the playable game).  Focusing the sprint review on the state of the gameplay sends that message as well.  For the team, it’s easier: having a product owner responding to gameplay communicates priorities.
For the product owner, it’s more challenging.  I encourage ScrumMasters to be diligent in asking the appropriate questions of the Product Owner in planning and review:
  • Sprint planning questions:
    • “What do you want to be able to do in the game by the end of the sprint?”
    • “What should the player be able to experience by the end of the sprint?”
  • Sprint review questions:
    • “Does the game demonstrate the gameplay you asked for in sprint planning?”
    • “Are these mechanics are as fun as we envisioned in sprint/release planning?”
    • “Do we need to make changes to the release plan/product backlog to course correct based on what we’re seeing?”
    • “What are the biggest concerns in making this game as fun as we envisioned for the release?”
  • Sprint retrospective questions:
    • “How can we decide earlier in a sprint if gameplay quality is achieving a vision?”
    • “What can we do to achieve the litmus test of a gameplay mechanic earlier in a sprint?”
    • “What parts of this game’s vision do the developers not believe in or have concerns about?”
These are questions for the entire team.  Discussing them as a group is very beneficial in supporting a shared vision.  Keep in mind the product owner will still own the final decision about the product backlog priorities.

It’s better to have a vision than none at all, but a vision must be tempered with reality.

Monday, February 03, 2014

The Attention Deficit Product Owner

We need to focus on everything” - an anonymous dysfunctional product owner.

 It’s great when a product owner has a strong vision. It’s not so great when that vision changes daily. Some famous game designers have been known for this. They have a dream one night, or their cat does something interesting that sparks an insight, etc. Next thing you know, they are running through the studio excited about their new insight and impatient to see it being implemented. Unfortunately, this can have a bad effect on the team, game and business. There is such a thing as “too much change”. Change should include empiricism. The product owner needs to measure their vision against the actual game and not fall in love with their ideas alone.

Don’t get me wrong, I love enthusiasm, especially when it can be shared, but it needs to be combined with a focus on demonstrating fun in the game. Focusing on too many things that will somehow come together months later is a debt we don’t want to owe.

Friday, January 03, 2014

Solitaire, Zen and Engineering

The game I play the most is Solitaire on my iPad.  I play it when I’m waiting for a flight.  I play it when I’m waiting for fall asleep.  I play it on a flight, when I’m too tired to read anymore.  I’ve played thousands of games and have nearly perfected my ruleset for winning (the percentage of Solitaire hands that can be won from randomly sorted decks is ~ 85%).
After years of playing, Solitaire has also started to reinforce, in a visceral way,  something about engineering, and possibly life in general.  It’s reminded me the benefit of focusing less on the outcome and more on the steps in between.  It reminded me of a book about Zen and motorcycles I read 30 years ago and it’s closing a long, old circle.
In Solitaire, the goal is to completely sort the cards into the four “foundations”.  Decisions made on card placement and the initial sort determines how easy, hard or impossible the goal is too reach.  In addition, my iPad Solitaire game has an option to only deal hands that are known winners, which eliminates the ~ 15-20% of the deals that are impossible to solve.
I’ve gone through several phases in my attitude and approach towards the game:
- Stage 1: Playing to win and failing frequently.  I played randomly and was quickly frustrated with getting stuck and would give up quickly, but I was delighted when I won.
- Stage 2: Mastery and the pursuit of winning.  I cared about winning and would play moves into the thousands to win.  I developed a deep set of rules about moving cards, which resulting in a ~75% winning ratio.  After a while, I found this pursuit of winning, percentages and winning streaks led to much frustration and I gave the game up for awhile.
- State 3: Playing only winning hands.  After I came back, I only played the “known winners” option.  After this, I never lost a game.  I racked up hundreds of wins in a single streak.  Sometimes a deal was particularly hard and it would take days to win.  After months of this, I became bored and frustrated again and gave the game up.
- Stage 4: A few months ago I returned and started playing the random games again.  At this point I no longer care about outcomes, but enjoy the flow of the game.  I know I can win every solvable game.  I explore every known “path” to winning a hand and if it becomes apparent that it’s an impossible hand or if I feel the effort to win is not worth it, I’ll “surrender” and deal a new hand.   I’ve found that I enjoy the game far more and unlike the previous experiences, find it quite relaxing and engaging.

This last stage has led me to rediscover something valuable outside of Solitaire, related to engineering.  When I build a device or write some code, I get very engaged in making it work.  When this device or app refuses to do what I want, I get frustrated.  This leads me into a cycle of pounding away at all the possible solutions, which leads to more frustration at why a fix doesn’t work.  I’ve always felt that my tenacity at solving problems and dealing with any level of frustration was a strength (I’ve broken a few keyboards).
But my recent experience with Solitaire has led to me try a different approach.   Why not embrace the failures not as failures, but opportunities to learn about what the world is telling me?  Recently, I tackled a problematic Arduino/Xbee data transmitter device that has been intermittently failing for over a year.  Instead of trying to rush to a solution, I spent more time characterizing the problem in a playful way.  I decided to learn more about radio transmission, antennae impedance and trying out all sorts of ways to characterize the problem.  I definitely had fun learning more deeply about how the Xbee and the Arduino libraries for it work.   At the end of this playful endeavor, the solution sort of “popped up” (it actually interrupted the fun).  This time it wasn’t the relief of something working, it was more the feeling of “well, of course that’s the way it should work”.  The reward had transferred from the solution to the path of learning, which produced the solution.

This reminded me of books I read decades ago (like “Zen and the Art of Motorcycle Maintenance”), which described “mindfulness”: of being in the moment.  Although I understood the concept of mindfulness from reading about it, I hadn’t tied it to engineering or living.  

I’m not a Zen devotee (although I did take my little 550 cc motorcycle cross-country after reading the book) and I don’t adhere to any religion.   I won’t be shaving my head or donning robe anytime soon, but I will be focus on exploring this state more.