For the most part they don't ... unless you buy into the 80's notion that the GM's job is to manage the group, manipulate its people, and bring them together to do great things.
To my mind, that's people-management skills ... which are helpful for a GM, but are in no way part of the GM's role as world-maintainer and challenge-provider.
Like, if a team-captain of the PCs could do the job equally well (or better), then it's probably not a GM job.
Depends on your role in the scrum team. For example, I am a scrum master, and the GM skills of thinking ahead to solutions to possible obstacles is useful, as is the expectation that the team will come up with some possibility that no one ever thought of and would never have been imagined before they actually started messing with the problem is quite useful. But in general, the idea of testable increments is... okay, I can think of some ways to apply it to gaming, but in general those are probably best avoided.
> At the outset of a sprint, it is critical to identify what needs to happen, what that will require, and get everyone's buy in. There may be competing stakeholders and differing opinions, or it may be clear to everyone and simply need implementation, but either way, even if everyone is enthusiastic to work, a clear channel needs to be carved to make it easy for them to do that work. A GM goes through a similar process at the beginning of a campaign (and to a lesser extent at the beginning of every session) - if the GM just decides by fiat, the game is going to be a crapshoot, but if she gets buy in and engagement, then the easiest path forward is also the best. > Any GM can make statements, but the best GM's focus on asking question. Scrum (any kind of PM work, really) has little authority besides what it's granted, and one of the most effective tools you have is a willingness to ask the right questions. Learning how to ask meaningful questions is something that GMing can prepare you for. > The flip side of that is that a good GM listens. A critical part of Scrum is the retrospective, where you get input on what went well, what went poorly and what can be learned. RPGs have tools for this too (things like Roses & Thorns) and they translate well. > Most critically, GMing requires keeping track of lots of information in a useful, actionable way according to arcane and sometimes arbitrary rules. That is Agile as hell. > Lastly, a good GM is willing to look stupid for a great game. The same is true of a PM/SM for their project.
Rabbit Stoddard I didn't know you are a scrum master! Or, if I'd heard that before, I hadn't internalized it. I'll try to ping you in to these posts as I move forward, ok?
Oh, Also: Trying to convince a non-agile group to try agile feels a LOT like trying to convince an old school D&D group to try...well, almost anything else.
There's a very high chance that Thursday I'll pitch Scrum to a high-level exec. The job as my boss understands it is more data analysis than software development, and this has been changing. The high-level exec would rather it were more like software development, and likes me. The intermediaries between my boss and the exec are in the same boat; fans of me, and fans of turning what we do into more of a software development.
I think I can reasonably say something like: our current methodologies are running into problem as we try to deliver the end-all be-all product, instead of providing value in the interim. This results in firedrills like we've experienced over the last couple of weeks, which result in short term but not longer term gains. To provide consistent value, we need to change things up; I suggest we switch around structure a bit, with boss's boss as product owner, me as scrum master, boss and some others as devs on this project.
If pressed, I can say that I have: totally read a book, lead groups through adventures (phrasing!), and failed real fast.
I feel like that sounds reasonable, but I don't know anymore.
William Nichols: There's also the fact that the other folks are much better rooted in Scrum than I am. I agree with Rob's assessment of how GM thinking in advance about how problems break down can help to inform thinking about how technical problems can break down in agile, but I'm not grounded enough in scrum methodologies yet to have seen it.
I have heard tales of places that have smoothly transitioned to Agile/Scrum, but I have never actually seen such a place. Odds are good that even if successful, you'll end up adopting a sort of weird hybrid that reflects the goal you're shooting for alongside the realities of your situation.
(That's a good thing. Agile has its purists, but I'm not one of them - adopt what you can, learn from it, iterate and improve and that's more agile than any particular methodology)
With that in mind, one bit of unsolicited advice: when you make tradeoffs, the one thing you need to keep clearly in focus is "How will we know how well or poorly we're doing, and how will we change?". If you have that step, even if you got no other concessions, then you now have a means to improve things. if you don't have that step, then you'll just be introducing new processes and procedures, and any gains they create will get ground down as they get crufty.
For circumventing my boss and going straight to his boss and her boss's boss, who'll be in the room trying to find a reason to give me more responsibility and money.
If that's a fear, you might be better served finding a way to turn it into a win for your boss. If necessary, drop all references to "Scrum", "Agile" and other buzzwords and just talk about status reports, feedbacks, clear deliverables and such. If you can get your boss on board, that's probably indicative of the strength of your pitch.
If you haven't approached him and given him a chance to say no, then I would definitely worry how he would perceive and attempt to jump him without giving him a chance/getting his input.
Thanks everyone. I was in the room with my boss, and was feeling nervous. I've been worried he will take it personally if I say we can do things better.
So far, so good. Bigger mtg in a couple days, with folks who have the power to yes.
That is: I think my boss, who is both smart and qualified, is running into a mental road block that he doesn't know how to get past.
If things go one way, end of the week (or so) I end up with the ability to build an agile team.
As I'm thinking about it, the work that my boss's team does requires both technical and business acumen -- ie, you've got to know your way around a select statement, and you've got to know how to read a contract.
The team I am envisioning, with myself as scrum master / team lead (or something) takes those things and erases one or the other -- ie, we make it so it only requires only technical expertise, or knowledge of the business. Or, of course, say we can't do it and send it back to my boss's team.
I'll be in the room with people who can make that happen.
That seems like a tough set of business requirements! But scrum/agile can be good for bringing an interdisciplinary team together. Daily standups can be a place where your technical experts and business/subject matter experts learn more about each others' worlds. If you do have those sorts of people, you could offer to introduce some agile ceremonies like standups and retros as a starting point to experiment from. But if your business problems require both areas of knowledge, you probably need coverage in both areas to be an effective team -- otherwise you risk delivering things that the other team doesn't need.
I agree with Rob Donoghue that the retro, or a point to evaluate and change, is the most important single thing -- if you can do that well you can come up with a system that works for you. I'm also not a purist and like to see different agile processes as different tools you can use to achieve different goals -- and I advocate for being fairly ruthless about cutting out stuff that takes up time but doesn't deliver what you need. (Don't spend time solving problems you don't actually have.)
I'd be more worried about going above your boss. Trying to get your own team might be taken the wrong way.
In terms of GMing skill: I'd say that the things that matter the most are things like how to facilitate meetings, build consensus and divvy up spotlight time to make sure that everyone stays engaged. If you're good at those things in gaming, I'm sure it will translate :)
Sara Williamson This is amazing, thank you. My boss's team is a "reporting and analysis" team -- essentially, the product is reports for he business units. These require constant maintenance, there are fire drills, and the processes are such that errors occur.
So, for example, a colleague built an outlook VBA-based thing to enter in contract performance information into a sql table such that he can use it to calculate where we'll be at the end of the contract year based on previous years curves, using a third-order regression model.
That is: he both built the process, is doing the data entry, and is wrote the calculations. Which sounds like a whole lot! I've done some similar work.
What we've not done well is get things off our plates. I've done some of that, and think it's maybe the way to go. We've got teams with business knowledge or technical knowledge, and it'd make sense to change those products such that they only take one or the other.
Shane Liebling What should I do with that whisper in the back of my voice, telling me that I'm bad at doing work, no one likes me, and that they are all about to prove I'm a fraud?
Kind of! In my world we have product managers who are kind of similar to business analysts -- they're responsible for gathering requirements from stakeholders, coming up with a solution, and transmitting that to the rest of the team (for us it's a combination of devs, QA, data scientists and UX designers). We do this in the unit of stories. Sometimes they're data and reporting stories but most often they're user stories for building features for the end users of our product.
You don't need to use stories, but it's a good idea to have something like them that can track what work needs to get done, what state each unit of work is in, and what the requirements are. If it's reliable estimable that's nice, too :)
Once you have that and your team is comfortable it's easier to deal with fire drills. For us, since we use story points it's easy to say, "okay, we can usually clear this many story points in a sprint, so we should descope to that amount if we only have one sprint to do this in."
If I were a new project manager on your team I'd probably start at just writing down the steps of your current process and for each one ask: "when this part needs to get done, do the right people know what to do? Do stakeholders know how it's going? Are people stressed out?" -- that lets you map your pain points and figure out what tools will relieve them the fastest. If you have a lot of fire drills, that sounds to me like it could be unclear requirements, un-managed stakeholder expectations, or both.
I think I do most def want to move to something more like scrum, rather than what we're doing now. The two most recent fire drills had a 24 hour turn around time demanded by the client, and my boss is unable to say no.
I partially want to get away from that, but mostly I want to make it such that when these requests come in they can be dealt with nigh automatically, hopefully simply by having the data elements exposed to the business users.
Interestingly enough, a new PM did come onboard a few months ago -- assigned as my boss's boss -- and asked very similar questions to the ones you addressed. She's aware of the pain points, and that we're essentially never able to put hand a project off to someone else.
I dunno. I feel like that's where I'd like to be, maybe without even a single new head.
We don't know each other that well, and I very much appreciate you coming here to help me, just because our mutual friend thought it'd be up your alley.
For the most part they don't ... unless you buy into the 80's notion that the GM's job is to manage the group, manipulate its people, and bring them together to do great things.
ReplyDeleteTo my mind, that's people-management skills ... which are helpful for a GM, but are in no way part of the GM's role as world-maintainer and challenge-provider.
Like, if a team-captain of the PCs could do the job equally well (or better), then it's probably not a GM job.
Depends on your role in the scrum team. For example, I am a scrum master, and the GM skills of thinking ahead to solutions to possible obstacles is useful, as is the expectation that the team will come up with some possibility that no one ever thought of and would never have been imagined before they actually started messing with the problem is quite useful. But in general, the idea of testable increments is... okay, I can think of some ways to apply it to gaming, but in general those are probably best avoided.
ReplyDeleteCouple easy ones:
ReplyDelete> At the outset of a sprint, it is critical to identify what needs to happen, what that will require, and get everyone's buy in. There may be competing stakeholders and differing opinions, or it may be clear to everyone and simply need implementation, but either way, even if everyone is enthusiastic to work, a clear channel needs to be carved to make it easy for them to do that work. A GM goes through a similar process at the beginning of a campaign (and to a lesser extent at the beginning of every session) - if the GM just decides by fiat, the game is going to be a crapshoot, but if she gets buy in and engagement, then the easiest path forward is also the best.
> Any GM can make statements, but the best GM's focus on asking question. Scrum (any kind of PM work, really) has little authority besides what it's granted, and one of the most effective tools you have is a willingness to ask the right questions. Learning how to ask meaningful questions is something that GMing can prepare you for.
> The flip side of that is that a good GM listens. A critical part of Scrum is the retrospective, where you get input on what went well, what went poorly and what can be learned. RPGs have tools for this too (things like Roses & Thorns) and they translate well.
> Most critically, GMing requires keeping track of lots of information in a useful, actionable way according to arcane and sometimes arbitrary rules. That is Agile as hell.
> Lastly, a good GM is willing to look stupid for a great game. The same is true of a PM/SM for their project.
being able to make shit up on the fly will always be a useful business skill. :)
ReplyDeleteRabbit Stoddard I didn't know you are a scrum master! Or, if I'd heard that before, I hadn't internalized it. I'll try to ping you in to these posts as I move forward, ok?
ReplyDeleteI wrote a thing about Agile and RPGs a while back. It may be relevant, may not.
ReplyDeleteplus.google.com - *Using Agile Development Methodology for Roleplaying Games* TL;DR — Fail fas...
William Nichols sure! And I don't talk about work much on G+, so you probably hadn't heard that. :)
ReplyDeleteAlso, if you've survived edition wars, you are totally prepared for discussions like "What's really agile?" and "Are estimates good?"
ReplyDeleteOh, Also: Trying to convince a non-agile group to try agile feels a LOT like trying to convince an old school D&D group to try...well, almost anything else.
ReplyDeleteI think it's really interesting that what Tony has said is so far removed from what Rob, Rabbit, and Mark have said.
ReplyDeleteI am still happily rooted in the 80s. :)
ReplyDeleteThere's a very high chance that Thursday I'll pitch Scrum to a high-level exec. The job as my boss understands it is more data analysis than software development, and this has been changing. The high-level exec would rather it were more like software development, and likes me. The intermediaries between my boss and the exec are in the same boat; fans of me, and fans of turning what we do into more of a software development.
ReplyDeleteI think I can reasonably say something like: our current methodologies are running into problem as we try to deliver the end-all be-all product, instead of providing value in the interim. This results in firedrills like we've experienced over the last couple of weeks, which result in short term but not longer term gains. To provide consistent value, we need to change things up; I suggest we switch around structure a bit, with boss's boss as product owner, me as scrum master, boss and some others as devs on this project.
If pressed, I can say that I have: totally read a book, lead groups through adventures (phrasing!), and failed real fast.
I feel like that sounds reasonable, but I don't know anymore.
William Nichols: There's also the fact that the other folks are much better rooted in Scrum than I am. I agree with Rob's assessment of how GM thinking in advance about how problems break down can help to inform thinking about how technical problems can break down in agile, but I'm not grounded enough in scrum methodologies yet to have seen it.
ReplyDeleteI have heard tales of places that have smoothly transitioned to Agile/Scrum, but I have never actually seen such a place. Odds are good that even if successful, you'll end up adopting a sort of weird hybrid that reflects the goal you're shooting for alongside the realities of your situation.
ReplyDelete(That's a good thing. Agile has its purists, but I'm not one of them - adopt what you can, learn from it, iterate and improve and that's more agile than any particular methodology)
With that in mind, one bit of unsolicited advice: when you make tradeoffs, the one thing you need to keep clearly in focus is "How will we know how well or poorly we're doing, and how will we change?". If you have that step, even if you got no other concessions, then you now have a means to improve things. if you don't have that step, then you'll just be introducing new processes and procedures, and any gains they create will get ground down as they get crufty.
Weird hybrid is definitely my experience. As for the OP question, others have covered what I might have said.
ReplyDeleteAm I going to get fired?
ReplyDeleteFor suggesting it?
ReplyDeleteFor circumventing my boss and going straight to his boss and her boss's boss, who'll be in the room trying to find a reason to give me more responsibility and money.
ReplyDeleteI know. It's a bit messed up.
If that's a fear, you might be better served finding a way to turn it into a win for your boss. If necessary, drop all references to "Scrum", "Agile" and other buzzwords and just talk about status reports, feedbacks, clear deliverables and such. If you can get your boss on board, that's probably indicative of the strength of your pitch.
ReplyDeleteI've for sure told him that I think we should move to something like scrum.... I am uncertain if he'll be onboard.
ReplyDeleteIf you haven't approached him and given him a chance to say no, then I would definitely worry how he would perceive and attempt to jump him without giving him a chance/getting his input.
ReplyDeleteBeen trying.
ReplyDeleteAnd I mean, it's not really a fear. My brain is just crazy about that.
Thanks everyone. I was in the room with my boss, and was feeling nervous. I've been worried he will take it personally if I say we can do things better.
ReplyDeleteSo far, so good. Bigger mtg in a couple days, with folks who have the power to yes.
Yeah man, you'd be taking a hell of a chance criticizing the ship's coffee on your first day aboard!
ReplyDelete[ Edit: For those who worry I'm being unsupportive ... it's an in-joke. ]
Sometimes, I think he's pip.
ReplyDeleteThat is: I think my boss, who is both smart and qualified, is running into a mental road block that he doesn't know how to get past.
ReplyDeleteIf things go one way, end of the week (or so) I end up with the ability to build an agile team.
As I'm thinking about it, the work that my boss's team does requires both technical and business acumen -- ie, you've got to know your way around a select statement, and you've got to know how to read a contract.
The team I am envisioning, with myself as scrum master / team lead (or something) takes those things and erases one or the other -- ie, we make it so it only requires only technical expertise, or knowledge of the business. Or, of course, say we can't do it and send it back to my boss's team.
I'll be in the room with people who can make that happen.
Does it sound like a terrible idea?
Paging Sara Williamson
ReplyDeleteThat seems like a tough set of business requirements! But scrum/agile can be good for bringing an interdisciplinary team together. Daily standups can be a place where your technical experts and business/subject matter experts learn more about each others' worlds. If you do have those sorts of people, you could offer to introduce some agile ceremonies like standups and retros as a starting point to experiment from. But if your business problems require both areas of knowledge, you probably need coverage in both areas to be an effective team -- otherwise you risk delivering things that the other team doesn't need.
ReplyDeleteI agree with Rob Donoghue that the retro, or a point to evaluate and change, is the most important single thing -- if you can do that well you can come up with a system that works for you. I'm also not a purist and like to see different agile processes as different tools you can use to achieve different goals -- and I advocate for being fairly ruthless about cutting out stuff that takes up time but doesn't deliver what you need. (Don't spend time solving problems you don't actually have.)
I'd be more worried about going above your boss. Trying to get your own team might be taken the wrong way.
In terms of GMing skill: I'd say that the things that matter the most are things like how to facilitate meetings, build consensus and divvy up spotlight time to make sure that everyone stays engaged. If you're good at those things in gaming, I'm sure it will translate :)
Sara Williamson This is amazing, thank you. My boss's team is a "reporting and analysis" team -- essentially, the product is reports for he business units. These require constant maintenance, there are fire drills, and the processes are such that errors occur.
ReplyDeleteSo, for example, a colleague built an outlook VBA-based thing to enter in contract performance information into a sql table such that he can use it to calculate where we'll be at the end of the contract year based on previous years curves, using a third-order regression model.
That is: he both built the process, is doing the data entry, and is wrote the calculations. Which sounds like a whole lot! I've done some similar work.
What we've not done well is get things off our plates. I've done some of that, and think it's maybe the way to go. We've got teams with business knowledge or technical knowledge, and it'd make sense to change those products such that they only take one or the other.
Does that still make sense?
Shane Liebling What should I do with that whisper in the back of my voice, telling me that I'm bad at doing work, no one likes me, and that they are all about to prove I'm a fraud?
ReplyDeleteKind of! In my world we have product managers who are kind of similar to business analysts -- they're responsible for gathering requirements from stakeholders, coming up with a solution, and transmitting that to the rest of the team (for us it's a combination of devs, QA, data scientists and UX designers). We do this in the unit of stories. Sometimes they're data and reporting stories but most often they're user stories for building features for the end users of our product.
ReplyDeleteYou don't need to use stories, but it's a good idea to have something like them that can track what work needs to get done, what state each unit of work is in, and what the requirements are. If it's reliable estimable that's nice, too :)
Once you have that and your team is comfortable it's easier to deal with fire drills. For us, since we use story points it's easy to say, "okay, we can usually clear this many story points in a sprint, so we should descope to that amount if we only have one sprint to do this in."
If I were a new project manager on your team I'd probably start at just writing down the steps of your current process and for each one ask: "when this part needs to get done, do the right people know what to do? Do stakeholders know how it's going? Are people stressed out?" -- that lets you map your pain points and figure out what tools will relieve them the fastest. If you have a lot of fire drills, that sounds to me like it could be unclear requirements, un-managed stakeholder expectations, or both.
Sara Williamson Yes!
ReplyDeleteI think I do most def want to move to something more like scrum, rather than what we're doing now. The two most recent fire drills had a 24 hour turn around time demanded by the client, and my boss is unable to say no.
I partially want to get away from that, but mostly I want to make it such that when these requests come in they can be dealt with nigh automatically, hopefully simply by having the data elements exposed to the business users.
Interestingly enough, a new PM did come onboard a few months ago -- assigned as my boss's boss -- and asked very similar questions to the ones you addressed. She's aware of the pain points, and that we're essentially never able to put hand a project off to someone else.
I dunno. I feel like that's where I'd like to be, maybe without even a single new head.
William Nichols good luck :) let us know how it goes!
ReplyDeleteAlso, Sara Williamson? Thank you.
ReplyDeleteWe don't know each other that well, and I very much appreciate you coming here to help me, just because our mutual friend thought it'd be up your alley.
William Nichols you're very welcome!
ReplyDeleteUpdate: Scrum master cert course approved within minutes, and we'll use that as a lead up to making me a team lead.
ReplyDeleteDepending on how a couple things shake out, I could wind up with ability to hire and build out the data-driven agile team that I want.
YAY! That is awesome!
ReplyDelete