I wrote a thing for the Joint Futures conference blog by employer Nitor is sponsoring. Check it out!
See Part 1 here!
In the picture above is my entire dissertation's line of argument, written out on whiteboard paper across our living room wall. Tangible!
Research on a cadence
In Agile, cadence means that there is a constant rhythm to how you do things, usually in the form of some set number of days you will plan your work for, do it and then reflect at the end. This is especially useful in large undertakings where you don’t know how much there is to do, how long it will take, or even if you want to do it all. Working on a cadence also involves creating routines and ceremonies on a regular schedule, so it is just a perfect fit for working on a dissertation.
I’ve been working on a one-week cadence for four weeks now and it seems to work for me. My week starts by setting weekly objectives (see previous post). I try to do this on Fridays because I usually have a discussion with one of my supervisors on Friday afternoons and I can often make “promises” on what I want to focus on next week. I write my objectives as a checklist so that every list item is a statement on the lines of “X is done”. Once the objectives are written, I’m ready to plan my week.
On Sunday, I take a picture of my weekly calendar (see previous post) for last week for record keeping, and wipe it clean. The format of my weekly plan is essentially two block of work including everything else, trying to be as specific as I can while having as few items for each block as I can:
Preparing this helps in two things: I get serious about what I have time for on the following week regarding my objectives, and I have something to start working on every morning. I use the Kanban board to track what thought-out work item I’m working on at that moment so I can flexibly follow leads and inspiration to tackle tasks in the domain I’ve set in the calendar. This helps me keep myself in maximum productivity and minimum context switching.
To motivate myself to keep writing, I use tracking and accountability. Tracking means that I mark a tally for each 25-minute interval I have spent working during a day, which gives me some sort of metric how well I could to stick to my schedule (good day is around 7, all time high is 10). Accountability means that I must send that week’s results (usually the dissertation document with tracked changes) by noon on Thursday to the supervisor who will give me feedback on Friday. I have been very lucky to have two supervisors who have agreed to take turns commenting my work on alternating weeks. It really keeps me working for the extra mile so I can get the most feedback, and writing for clarity because I know someone will read it. Now if only you could write automated tests for your dissertation…
Enabling a sustainable pace
A sustainable pace means that the team must be able to keep a steady output by keeping their work hours reasonable, avoid damaging their morale and make sustainable decisions in their work so that they aren’t overwhelmed by e.g. bug fixes or major refactoring.
For me, sustainable pace means keeping my health and sanity intact through this three-month window:
- Exercise – keeping my posture and support muscles healthy. Before the writing leave started, I got a gym membership with personalized instructions that I go to three times a week for general aerobic health. I also have 30 min Pilates on Wednesdays for guided exercise on core muscles and 30 minutes of daily yoga for balance and coordination. Sounds like a lot but it has worked wonders on my stamina and I’ve had zero back problems even though I write all day.
- Mediation – focus and stress management. I’ve been doing 10 minutes of app-guided meditation with a 10-day free trial for. Mostly it helps me orient myself and get writing every day, but I’ve been happy to find that some of the practices have stuck with me.
- Rest – ensuring I have enough time to recover from writing. No working after 5 pm. or on weekends, and going to bed by 11 pm. This was less of a challenge for the first three weeks since I’ve been exhausted from writing my 2 pm when I’ve been writing since the morning, but having more energy and drive for writing means that I have to set boundaries for myself. Burn-out isn’t Agile.
- Calendar management – learning to say no. I’ve had to turn down so many interesting meetings, breakfasts, lunches and more to protect my writing time. Obviously this means that I won’t have meetings during the day, but also that I won’t be out late or drinking if I intend to write the next morning. On the other hand, discipline with working times has enabled me to dedicate Friday nights and weekends for staying in touch with my wife, friends and family.
That’s my Lean and Agile research routines in a nutshell! Do you have questions about my research practice? Did I leave something out? I’d love to do Part 3 as a Q&A so leave your questions in the comments here, on Twitter or on Facebook!
Three weeks ago I took a leave from my day job as a Lean-Agile consultant to finish my doctoral dissertation in three months. The last time I did research full-time I was working at Aalto University SimLab from May 2013 to December 2015. Based on this, you might think I had this whole “how to do research” under wraps, but I was always unsatisfied about how use my time effectively and actually write the dissertation. But now after a year as a Lean-Agile coach I felt more prepared to tackle the challenge than ever before.
This is a retroperspective on how I’ve managed to make myself a better researcher and enhance my probability of getting the dissertation done by July. In this part 1, I will give you an overview into some techniques and tools that I’ve created in the last three months leading up to and the beginning of my writing leave. In part 2, I will explain more about how I actually use the system formed by these tools.
Thinking about work items
When thinking about a big project, even one where a lot of thinking and creativity are needed, it helps me to accept that everything is just work that needs to be done. This comes across in both Lean and Agile and it applies to assembly lines where the machines are literally just waiting for you to assemble them, but also software engineering where we track our progress based on the system functionalities we have delivered. You can have work items of different types and sizes, but each item of work is always either not started, in some state of work-in-progress (WIP), or done. Sometimes pieces of work need to be iterated, but the new iteration is thought of as a new item of work.
Breaking down large chunks of work
The biggest lesson I learned from working in an agile team was that the size of the work items you handle matters. Agile teams work with work items called Stories that can be completed within two weeks, i.e. a Sprint, and Lean teams just want to keep item sizes small and consistent. By the time it is finished, my doctoral dissertation will have taken me 3½ years, over 10% of my life. If that is not a work item that needs breaking down, I don’t know what is.
When I look at my work as an individual, my biggest item of work should be roughly half a day. This means that if I work on an item for half a day (e.g. the whole morning), I am reasonably confident that I will get it done. If a job has multiple phases, I might try to break it down as small pieces as I can just so I have more focus and flexibility during the day. Work item size might be the most important thing on this list, which will make even more sense when we start talking about iterations and limiting work-in-progress.
Different areas of work
I started by creating categories of work based on the end result – the dissertation text itself and its chapters. Each chapter. Writing a dissertation or any kind of thesis is hard because you can’t just sit down and write it, you need to write multiple chapters in parallel because your view on the literature changes how you analyze your data and the conclusions will place requirements on how you frame your research in the introduction and so on. Each chapter will also need a different kind of mind set, whether it’s talking to a large audience in the introduction, reading and commenting on literature or working with data in analysis.
Now if I plan to do a revision that will impact multiple chapters, I can write down work items to each chapter and then focus on one chapter at a time instead of jumping wildly from one chapter to another. Having a system in place for tracking which chapter each work item will impact also helped me talk with my supervisors. When talking about the dissertation and giving feedback, we are always talking about the state of this or that chapter, so this system helps me to both describe how I have developed each chapter and create work items based on the feedback of that chapter.
Focus on the desired state
When starting an agile way of working, a lot of people have problems internalizing that the best way to write down work items is not “do thing X” but rather “X is done”, or even better, “Y can X”. For example, my work item for analysis reads “Episodes have been searched and listed from the transcription”. The difference from “Search and list episodes from the transcription” is subtle at first, but reading the former automatically triggers a response of “What still remains to do?” which helps me get that work item into Done and on to the next instead of evading a vague work item because I’m not really sure what to do next.
Visualizations for everything
Most of my work revolves around three objects I have on the wall next to my monitor. My Kanban wall, my weekly calendar and my weekly objectives:
The big mess of tape and magnetic notes is my Kanban wall. The columns tell which phase each work item is in. I often have just a mess of things I might do on the left – called a Backlog – which is then refined into things waiting to be done under “To Do”. I only allow one item of work to be “In Progress” at a time so I know what I’m currently doing – this is called a WIP limit and it helps me finish work items before I move on to the next. The rows are the different chapters: Introduction, Theory, Method, Analysis, Results & Discussion, and then one for planning and other general work like “remember to tweet a lot”.
The brown framed whiteboard is my weekly calendar that I update at the start of every week. I plan my daily work time in two chunks - morning and afternoon – and mark down what I expect to finish during that time. I also mark down everything else that impacts my available work time e.g. meetings, gym, rest days or the time I must leave to catch a bus to meet my friends. During the week, I tally the number of 25-minute timeboxes that I get done, with breaks between them for stretching and snacking. This gives me a sense of how well I’m able to keep to my writing routines and creates a bit of accountability so I have a better chance of reaching my goals.
The two big magnetic notes above the weekly calendar are weekly objectives. I initially did my objectives for two weeks i.e. Sprints, but quickly realized that I had to have objectives that fit my cadence (more on that later). They’re not (always) replications of the work items, but instead they’re usually things I’ve agreed with my supervisor to do in the following weeks. After settling down with the objectives, I can then identify which chapters need work items and how to write them in an actionable way.
Finally, I use wall space for all kinds of notes and data analysis. Because I don’t have a whiteboard at home, I use Magic Chart, a roll of whiteboard paper that sticks to your walls. They are handy for theory formulation and data analysis, and they can easily be moved around or trashed after they’ve been incorporated into the text.
That’s all for today, follow me on Twitter to get a heads-up on Part 2: Making it all come together.
At the core of servitization is the idea that the customer doesn’t want a drill, they want a hole. While seductively obvious, a danger lies within.
Say you apply this idea to create a new turn-key kitchen installation service. No longer will the customer have to wonder which materials are water-resistant and how long you should let the sealant dry, we’ll pick the materials that fit your kitchen and come install it in your home!
What was previously just a product business model (producing/importing kitchen appliances and materials) has been turned into a service business model (providing new kitchens to homes that need them) and if offered at a competitive price, the service will surely deliver great value for everyone! Market capitalism!
Let’s take closer look. Services are always part of someone else’s journey of fulfilling a need. Let’s say that this visualization represents the customer journey before and after the “servitization” of kitchen acquisition, with the responsibilities of the customer in blue and the service provider in orange:
What happened was that we increased the orange parts and decreased the blue parts. Better service, right? Well, more service would be correct.
And now that we have more of this service, we need a service designer. They will design how the customer interacts with the service, how we deliver the service, what happens in each phase and how the material and people are choreographed over the course of a service experience. Rock solid!
However, if you think of service design as the analogy of product design, you give the service designer the job to design every part of the service. And because service is delivered anew every time, you want the service to be delivered as designed, and that’s where things risk going dumb.
With a detailed design, you need detailed implementation: routines are documented into processes, roles and responsibilities are drafted to make sure the service delivery organization works in a predictable way, and little by little the service becomes a metaphorical machine that can only do one thing. We end up with more boring jobs and a slow decline in employee skillfulness.
But it’s not just the service provider organization that suffers, customer experience might worsen as well. As the service provider becomes more rigid, the whole journey loses adaptability because we made it more orange. The service doesn’t adapt to different customer needs or changes in customer preferences in the way that the product did, because the customer could have done the parts they were responsible for in any way they want.
Unlike what you might expect, I’m not advocating for a total Do It Yourself revolution. Instead, the tipping point in this narrative was the moment service design was thought of as the design of services, as if a service is something you design well and be done with it.
In their article “Designing for Service: Creating an Experience Advantage”, Shelley Evenson and Hugh Dubberly point out that a service is design because people, products, places and systems interact every time to create i.e. design that particular service experience. The authors then propose that what is done beforehand is designing for services, a sort of meta-design there the conditions and limitations are put in place. The result is an assembly of people and places by whom the service is designed as it happens.
For me, designing for services opens a completely new perspective into taking people and organizations into the service design process. Perhaps more importantly, it helps me separate the role of the user experience (UX) designer from service designer in digital services, since a UX designer is looking at a service from the perspective of a customer’s needs and outcomes while a service designer reaches into how the service providing organization is designed.
Do you think we should talk more about designing for services? Or is the role of the service designer just a hype thing and we should stick with user-centered design? Probably stuff on services and co-design coming in future!
I've just finished the book/pamphlet Flinch and I wanted to share with you some of the reflection just defining the flinch has set in motion in me.
In 2012, I told my significant other that I wanted to break up. I had prepared for it for a while, but as I drew breath to say it, time suddenly slowed down. I felt like I was in a dream, or as if a horrible accident had happened but I still hadn't realized how bad it was. The two alternatives, so say it or not to say it, hung in the air and I was free to choose either of them. This was when I realized there was something special about the moments when your realize you're about to do something irreversible.
A year ago I wrote my goals for 2016 but chickened out on posting them online. I felt shame and inadequacy because looking for work in the Fall had revealed that I had little to demonstrate any of the skills and abilities I was convinced I had. In my piece I promised that 2016 would be about paying dues and laying roots, about not saying I'm done before the bell rings, about learning how to write through the pain and the self-loathing. I had realized the shape of my problems, but could not put my finger on them. I started saying that the way to get through something hard was to "go towards the pain", but I didn't do it myself.
In the Spring of 2016, Dr. AgileFant a.k.a. Jarno Vähäniitty told be off-hand that "if something is hard, you should do it more often". This instantly rang true, and I started saying it to everyone I faced a challenge with. Every time I got the same response: agreement that this was indeed the case, accompanied by a nervous laugh. I had realized that I need to go against instinct time and time again if I want to learn.
In early October I came back from a four-day vampire larp "Convention of Thorns" still neck-deep in my character, and on the following Monday I realized something had changed in me. I could talk to anyone and bring up anything without fear or hesitation. No chore felt repulsive, writing was as easy as putting words together and decisions happened without procrastination or doubt. I knew the effect is called bleed in the larp community and means that something from the fictional game bloods into a person's life, or vise versa, but the effect was something I had never felt in my life. I was free. I head learned that there was an option of living without fear and hesitation, even if this time the effect dissipated in two weeks.
Yesterday I learned that the word for what I had been tackling was flinch.
Flinch is the biological but largely instilled hesitation when doing anything that's not in your comfort zone. For some people it might be talking to strangers, for others it might be staying in and listening to the sound of your own head. The point is, we all flinch at a lot of things and if we don't fight it we end up living our lives in a corridor that leads from bed to breakfast to work to home to bed, and we never get any of the things we really want.
This has been my life with the flinch.
It's about to change.
Because as long as there is flinching, there won't be co-creation, there won't be Agile and there won't be a complete dissertation at the end of 2017. And that's unacceptable.
(Also you should read the book, it's short and comes with exercises!)
The objective of conversation analysis is to marvel at our ability as humans to make sense of each other, and occasionally transfer meaning across the vast void that separates us. In my research, then, the point is to marvel at how we can engage in such overwhelmingly complex activities such as playing games and coming up with new ideas. To be truly frank, I have skipped at least two dissertations' worth of groundwork and analysis to properly understand the phenomenon I am studying, and am therefore walking carefully in the cross-section of so many intertwining discourses.
But that, I'm afraid, is the role of applied science: to attempt solving the problems that arise in the world in their natural, messy form, trying and failing to learn all the lessons that basic researchers have made available. Here are the three synthetic perspectives that I'm trying to outline, utilize and develop in my dissertation.
1. Dialogical knowedge co-creation
The motivation for studying service design games in the field of industrial engineering and management lies understanding and exploiting the ability of service design games (SDGs) to facilitate knowledge creation in organizations. In my work I have chosen to utilize an interaction analytical approach to studying SDGs and as such will utilize a theoretical framework of dialogical knowledge co-creation, following Tsoukas (2009). This focus on the interpersonal creation of knowledge is reflected in the use of the term knowledge co-creation to delineate the phenomenon of dialogical knowledge co-creation from other perspectives such as knowledge management.
My contribution to this perspective will be a continuation of dialogical knowledge co-creation using conversation analysis in a setting of intentional knowledge co-creation. The conversation analytical approach will provide further understanding and examples of the structures employed in conversation of knowledge co-creation.
2. Scaffolding knowledge co-creation
The ability of SDGs to support knowledge creation is conceptualized in my work using the scaffolding metaphor which originates from learning science and sociology. This perspective, after Wanda Orlikowski, posits that all knowing is made possible in interaction with material infrastructure which both enables and restricts us. In this work scaffolding is extended into the realm of practice knowledge, the primary definition of knowledge in this work, to propose that action is scaffolded not only by material artefacts but also conceptual artefacts such as game rules and institutions.
My work will provide a process-oriented view into the role material and conceptual scaffolds play in a game setting. The analysis explores the different use of scaffolds in different phases of the game and as a part of different interaction structures.
3. Service design games as interaction
A study of the SDGs to scaffold knowledge co-creation will, finally, require a way of analyzing SDGs as interaction. This work is informed by game studies where games and play are studied as socially constructed activities, but the primary perspective for studying games in this work is institutional interaction.
According to Drew and Heritage (1992, 22), institutional interaction has three typical features:
- at least one participant is oriented to a particular institutional task or identity
- the interaction is restricted
- the interaction involves interpretation frames that are typical for that context
The contribution of my work for the study of service design games in particular and of games in genera is to provide an example of studying gameplay as institutional interaction constructed by the players and afforded by the game material, rules and the larger institution of games.
PLAY WITH ME HERE!
Design games as scaffolds for knowledge co-creation
Science is the pursuit of knowledge and as I have described over one master’s thesis, three conference papers and one journal article, knowledge is created in dialogue. With that insight and the ever-growing anxiousness to make headway with my dissertation while simultaneously working full time in the industry, I am making a step I haven’t seen anyone else do and would not have thought about just a year ago.
Today I’m releasing the up-to-date work-in-progress version of my dissertation on my website at http://otsohannula.com/blog/dissertation-public-beta. I do this to open myself to criticism and feedback from the largest imaginable audience: The Internet. If you end up reading this document, I invite you to give your piece in any form you see fit, such as the following:
Commenting on the document: I have opened the document for anyone to comment with a username or anonymously. This allows you to ask questions or make suggestions directly to the text. This also helps me get a “heat map” of the text about which sections provoke most responses.
Commenting on the blog: If you would rather give feedback in long form or provide a piece in response, my blog provides a great platform to kick off a discussion by making your comment available to others.
Email/IM: If you would rather give private notes you can of course send me an email to otso.hannula (at) aalto.fi. You can also just give me the highlights on any social media you see fit. ;)
To put it bluntly in the spirit of Ed Catmull in Creativity Inc., all dissertations start by sucking. In the document you will find a lot of (almost) empty headings and bullet points standing in for interesting and well-thought ideas, as well as passages lifted verbatim from my previous publications (with apologies to co-authors). If you feel like a section is just going nowhere, skip to the next one.
So my work sucks, and it is by opening my work to the world before it is too refined that I try to take full advantage of your feedback so that one day my work might not suck. It is in this moment that I feel more scared and less afraid than ever before.
I love you.
In Espoo, September 30th 2016,
Scratch that, writing any interactive fiction is hard. But writing tabletop roleplaying scenarios is excruciatingly hard.
I have little actual writing experience (mostly from co-authoring the script to a 100-person crew & cast sci-fi student musical) but at least in stage plays most of the writing is about figuring out the characters and making them do interesting things that make sense for those characters.
Now, what is a roleplaying scenario? In roleplaying games, especially when they're played in conventions, a game master writes and hosts a 2-4 hour session in which players participate with limited prior knowledge about what they're about to do. Think of the players as going to the theater except that you're going to be on the cast and make up your own lines.
Think about that. What would it take for you to do something like that?
I think you the player need to feel like you're going to be taken care of, and provided with material that you can make sense of. Roleplaying games make the whole improvisation theater thing a bit more approachable by not having an audience (besides the other players) and not having to move around on stage (unless its a specific type of scenario in which you're supposed to use bodily interaction). But in the end, the game has to be prepared specifically to allow players to make sense of it on the fly.
Modern video games do this all the time: think about the opening of Portal - or even Super Mario Bros. You have no instructions on what the game is about, what you're supposed to do and how to do it. But in a video game the player(s) can only do things that the game was specifically created to allow. In roleplaying games it's different in multiple ways.
First, tabletop roleplaying is an analog game like board games: no computer will suggest or validate actions. The only things you have to guide players are their expectations based on previous games, the responses of the game master, and whatever explicit game mechanics they can read at the beginning of the session - no long rule books!
Second, where board games most often rely on setting up a system up front with all the rules, pieces and goals are explained to everyone, roleplaying is supposed to be mostly imaginary and free. So free, in fact, that if a player comes up with something they want to do and a game master will deny it without giving enough explanation why, the whole group of players can and will call bullshit on the whole game. Roleplaying is terrifyingly free - both for the player and the writer.
And that's what I find terrifying about writing roleplaying scenarios. The trust that people I haven't even met yet are placing on me to take care of them.
I can't let them down.
PS. If you're interested in what I'm talking about, feel free to check out The Laundry World, the Apocalypse World hack that I'll be running the game with, and the full scenario I wrote and ran in Ropecon 2014!
I'm currently at ServDes 2016, the Service Design and Innovation Conference, and there is just so much going through my mind. To alleviate this and make sure I can follow up on at least some of these ideas, I'll present a disconnected series of paragraphs summarizing my day. If one of them caught your interest, please send a comment or an email and I'll be happy to elaborate!
The conference is organized around a nifty set of graphical elements signifying the centres, tectonics, fringes, paths, transformations, and private and public spaces. Especially interesting was the idea that the core topics of the field seem to be "Service Innovation", "Design thinking" and "Service-Dominant Logic". The division feels intuitive: creating new services and ways to provide service, inspiring creative and divergent approaches that focus on creating solutions, and applying a service-oriented way of seeing things in the larger context.
However, this didn't capture the great opening keynote by Chistian Boson about service design in the public sector. The keynote started with the question "Why doesn't the better solution always disrupt the older ways of working?" Christian shared that the public sector seemed to be good at running service design experiments and even projects, but that governments are facing huge difficulties in enacting change in the large scale way of working. The challenges he elaborated on captured the huge challenges of changing organizations and ways of working service design is only recently starting to tackle. Maybe this will spin off and area such as strategic design further away form service design, or maybe the field will transform itself.
Christian Boson also described a dichotomy of management vs. design. Whereas management is about finding the optimal decision, design is about creating the best possible solution. This actually made me connect design thinking with systems thinking as the empathic/analytical sides of the same coin.
A friend of mine put it succinctly: "D&D is a cargo cult of older D&D". Basically he claimed that new editions of Dungeons & Dragons try to replicate the story of how "original" D&D was a game of mystery and whimsical adventure, whereas the game was actually designed as a tactical skirmish-level wargame. He also noted that even the current editions make more sense when viewed through this lens - when the character is just a set of numbers that enable you to solve puzzles and reach goals within the game, the "gameness" of D&D with its encounters and reward systems comes alive as a complex and fascinating challenge.
But I've been thinking, if a person comes into roleplaying games via D&D, will its fundamental principles become ingrained habits in any future games that the person plays or designs? Many aspects of D&D have ended up in definitions of that roleplaying games are, such as the preeminence of a gamemaster's vision of the world ("Is there a door here?" "No"), the limitation of a players' agency to the character's agency ("having authority end at the ends a character's fingertips"), and having logical, social and tactical challenges as the core of the game experience.
The watershed moment of roleplaying beyond D&D in our gaming circle was the introduction of Apocalypse World after its author, D. Vincent Baker, visited Ropecon in 2013. The post-apocalyptic game of Playbooks and Moves instead of Classes and Attacks took us by storm. Suddenly we were handing out storytelling authority let and right, groaning about the uselessness of detailed battle maps, and writing our own derivative games called "hacks" in AW circles.
But out group didn't really "click" with these games, not in the way convention games I played in did. We laughed and usually had a good time, but we couldn't replicate those moments when everyone around the table is leaning in with anticipation and hanging on every word of a dialogue between two players. And that kept bugging me.
As this was going on, I was researching facilitating knowledge co-creation with games (you know, the serious stuff). Studying these "serious" games finally helped me pinpoint what it is about roleplaying games I find so irresistible but often beyond my grasp. It's the act of co-creation.
To be precise, it's the act of spontaneous, intrinsically motivated social co-creation with a dynamic team in a psychologically safe space. And what my research into co-creation has taught me is that all those other words around "co-creation" are redundant: co-creation is either the result of or the cause of spontaneity, intrinsic motivation, sociability, team dynamism and psychological safety.
What's more, games research superbly summarized in length by Jaakko Stenros indicates that both (free-form) play and (structured) games are adept at creating this kind of mental and social space. The first time I saw people playing the knowledge co-creation game ATLAS, all I could think of was "this looks exactly like roleplaying". People throwing dice, moving tokens, having discussions about imaginary things they were personally invested in, all in the intense atmosphere of co-creation.
Years later and despite getting proficient with a number of co-creation methods and tools, I still struggle with the same themes. It is hard getting into a co-creative space for fun, let alone at work where you maintain an image of responsibility and usefulness. But in understanding my struggles with our D&D background roleplaying group, it sheds a light on why I have found it so hard. Unlike at work, I don't have routines of co-creation with these people and I'm in a setting where I have modes of acting that date back to our D&D days.
So I arrived at a conundrum: What could I change about our regular gaming that would create the expectation of and the ability to create a space conducive to co-creation?
I didn't find an answer to that question, but on the side I have begun a project to introduce new people into the hobby by running beginner-friendly roleplaying games. The games I'm running are based on tropes from popular media (our first game was set in Victorian England) to provide content authority, and utilize lightweight description-oriented systems (such as FATE Accelerated) to give system authority to the players . After that it's my responsibility to run the game as a facilitator which in my mind involves setting expectations and providing an inciting goal or a shove that will orient the players and get them over the awkward start of a game.
Early results with these games look encouraging. I still feel that the "click" eludes explanation but creating a culture from scratch had led me to some tricks that make it more probable. Whatever the answer, co-creation has proven to be a challenge worthy of tackling in an academic discussion - with the potential to save my living room table.
The last month of my life has been a nosedive into the Scaled Agile Framework, i.e. SAFe, as a new member of the Nitor Delta team. I admit, I was initially suspicious of a systems-thinking heavy framework that gets sold to executives and managers alongside slogans like "only managers can change the system" and "leadership is imparting excellence into the organization".
But the best way to approach SAFe is through the SAFe principles: a list of nine principles which act as a kind of step-by-step logical induction of the Lean-Agile philosophy that underpins SAFe. Through them, I was convinced that correctly applied SAFe is not a tool of control but liberation, and I'm happy to share with you how I came to that conclusion. Below are the nine SAFe principles rewritten to emphasize their ability to distribute authority and agency in your organization.
1. Use a shared measurement of success
In order to be sustainable and beneficial, everything a business does should be guided by the creation of value in the most effective way. This simple idea should be present in everything an organization strives for: which user pains do we address, when do we launch, how do we organize customer support? An economic view that runs through a system empowers actors to make their case across functions and roles at all levels of an organization and to take initiative in consider the economic impact of their decisions.
2. Encourage people to look beyond their immediate surroundings
"You need to look beyond the immediate when considering consequences." Such a simple idea that is the root of all thinking in organizations: it's not about your interaction, it's about the team. It's not about your department, it's about the company. it's not about the company, it's about the ecosystem. Systems thinking does not tell you which level you should consider at any decision, just that you're probably looking at it too closely.
3. Allow your people to react to changing conditions
The SAFe principle of "assuming variability" means that you don't want to stop everything and start over when your inputs vary or if the requirements change over time. In knowledge work, you often don't want to create the exact same thing as before, so you shouldn't aspire to the same predictability of process as a chemical plant. To fully take advantage over this, people should be encouraged not to nail things down before they have to under perceived pressure to "get things done".
4. Insist on completing small things to foster learning
The most commonly recognized aspect of Agile is completing large undertakings through small tasks. There are a number of advantages to this approach but to foster learning and a sense of agency, completing small things allows your people to get early feedback on their whole process from end to finish - not just the early planning phases. When iterations go through all phases of delivery, you are not only able to iterate to improve the product, but also allow people to iterate on their process and practices.
5. Set milestones on value delivered
Don't set milestones based on your preconception about how the phases a solution will be developed in. Instead, insist that every iteration be made as a viable solution and measure progress in terms of value delivered - whatever definition of value fits your solution. The team will find the best way to make headway and stakeholders can be involved over the course of development.
6. Visualize everything
Visualizing helps your team focus, handle stress and understand how they work. Increasing flow by setting WIP limits, reducing batch sizes and managing queue lengths is important and useful, but up-to-date visualizations help your team understand what they are doing. Most importantly, the key driver of stress is often not working too hard, it's working with too little visibility.
7. Structure work to build routine and collaboration
SAFe is literally "Agile, but scaled". This is most apparent in teams working in parallel to one another but also in how work is anticipated over "scaled-up" (i.e. long) stretches of time. Having all teams working on cadence creates routines that buffer uncertainty: "'When do we overview work across team?' 'Next IP sprint, in 4 weeks.'" Having all teams and even teams of teams work on the same cadence creates opportunities for cross-team collaboration and problem-solving.
8. Unlock the intrinsic motivation of knowledge workers
This I didn't have rephrase at all, which makes me even more confident that SAFe has empowerment and respect for people built deep into its core. Instead of monetary incentives to exert control over your team, understand that the teams are already motivated. You only need to overcome the obstacles to their sense of autonomy, mastery and purpose. In best case, you can communicate a clear intention that your teams can pursue under minimal constraints. Good things come to those who allow.
9. Make less decisions
Once you have established and communicated a shared method of evaluating decisions (principle 1) in a system with maximum visibility (principle 2) and awareness (principle 6) where your people can adjust for changing conditions (principle 3), you are the last person who should be making any decisions for these people. And you won't.
I recently came across a third person blog piece (in Finnish) about the failure of a university to meet the writer's expectations as an employer. Even though most of the post was devoted to arguing against bringing practices of corporate management into Finnish universities, my mind immediately stuck to a rhetorical device at the beginning of the post (freely translated, formatting per original):
When going to work for a university Julia thought that a place in which people do creative work, building new knowledge, is surely different from companies which still apply principles of the industrial age. Julia also though that out of all places universities have a lot of research on how to best support creative thinking, problem-solving, team work [and] workplace well being. Surely the structure and practices of the university itself reflect this knowledge that the organization holds?
As a fellow second-year doctoral researcher and the employee of a university I fullheartedly agree with the sentiment of the post, but I believe that by expanding on where problems arise we can elevate the discussion surrounding them. From the point of view of organization research - a social science - the fact that universities continue to lag behind best practice in terms of supporting knowledge work makes perfect sense.
1. Explicit knowledge is not practice knowledge
A plethora of knowledge management literature, including the often-cited SECI model by Nonaka and Takeuchi, differentiate between explicit knowledge (knowledge what) and practice knowledge (knowledge how). This is especially pronounced in the field of practice studies in which knowing is inseparable from acting. However, the ability to act is always constrained by practice: practice of being a doctor, practice of management, and the practice of being a researcher. According to practice theory, information about how to best manage creative organizations exists as the object of inquiry within the practice of being an organization researcher and separate from the practices of developing organizations. Merely having access to explicit scientific knowledge about managing creative organizations does not imply anything about the ability to change the surrounding world.
2. Converting explicit knowledge into practice is hard work
The utility of scientific knowledge means that it can be applied in real life but doing so literally means developing a new skill. Even getting to the point where a theory explains one's surroundings takes effort, but then coming up with a change proposal and negotiating with coworkers on how to implement it requires the creation of organizational development capabilities.
3. Universities are old, rigid and have a lot of moving parts
All organizations have a history and universities have long histories as public institutions which makes them prone to formal hierarchies and bureaucracy. What's more, universities rarely act as single entities, but are instead divided into dozens of semi-autonomous units such as faculties or schools, which in term house semi-independent departments which are home to research groups headed by academic staff - who, according to academic tradition, hold significant autonomy on how to run their groups. While as a rule each level reports to the level above it and grants funding to the level below it, academic employees have free reign to judge whether they want to follow some particular best practice.
4. Researchers don't really care
The first rule of every researcher, at least in my field, is that every researcher tries to maximize the time they are able to spend on their research. Joint papers, shared projects and all teaching are all commitments that eat up the time the researcher is able to freely follow their particular passion, the mastery of which is the defining feature of their career. Add to this that 1) they have no sense how precisely to change their surroundings, 2) figuring it out would require a lot of effort, and 3) changing practices requires voluntary participation from everyone else, you have a prisoner's dilemma where no one makes the choice to keep investing their energy into creating a supportive organizational culture. Curiosity requires autonomy and the freedom to delve deep into subjects and explore a lot of dead ends.
The prevalence of IT in all areas of life often blinds us to the fact that social systems don't scale well if at all. Organizations change through slow evolution and a complete overhaul by frustrated managers will evoke even more hostility from people whose autonomy is both prized and always under threat. I think management practices from the private sector may hold the key for renewing universities, but they have more to do with servant leadership and autonomous teams than centralizing power to a chain of command. True change always starts at a community level, and research groups would do well to make clear for themselves if they expect to act as a creative team or a loose assembly of autonomous researchers. A mismatch of expectation will always end up with doctoral students who wonder why they ended up in academia.