 I feel like it's probably close enough to 345 for me to go ahead and get started. I generally have to place my phone like far away from me when I'm presenting because if it buzzes in my pocket, I get really distracted. I'm like, oh, what's going on on the internet? I'm like, no, no, no, focus. You're giving a presentation. So this presentation is titled, A Developer's Primer to Managing Developers. You are currently at DrupalCon Austin. The year is 2014, and this is Room E. If none of those things match your expectations, please feel free to get up and leave and go find a different session or a different year or a different conference. I will not be offended. My name is Joe Schindler. I'm known on the internet as EOJTheBrave, Twitter, IRC, Drupal.org, pretty much anything that was invented after 1995 that you can create a user account for. I have registered EOJTheBrave. So that's where you can find me if you've got questions and you'd like to tweet them at me or just to come and find me and ask questions after the session as well. I currently work for a company called Lullabot. Lullabot is a development company. We do development, design, consulting, a whole bunch of other stuff, primarily focused on Drupal, but we also dabble in other technologies as well. Really the whatever works to solve the problems that our clients have. At Lullabot, my primary role is as part of the Drupalize.me team. As me is a web service for training videos and my role on that team is sort of multifaceted. I'm both the senior developer on the team so I'm responsible for maintaining the infrastructure that keeps our website up and running and I'm also one of the trainers so I help to create the videos that are on the site that people come and watch on our site. So any given week that responsibility varies from sometimes I'm a developer for five hours and a trainer for 35 and sometimes I'm a developer for 35 and a trainer for five. So that's a little bit about me. I'm also supposed to tell you that Lullabot is hiring so if you want a job, stop by the booth. Lullabot is having a party on Wednesday night at a place called the Handle Bar. No, the Handle Bar, not Handle Bar but Handle Space Bar. It's really confusing. It's apparently five minutes away from here. I'm sure if you stop by the booth somebody will give you way more information than I could. And in general, if you have questions afterwards, I will probably right after the session head down to our booth and hang out there so people can stop by and ask me questions and chat. So that's kind of like where I work but a little bit more about me and kind of what's going to happen in this presentation. I'm going to spend the next four slides I'm going to use to set up the context for this presentation. We're going to talk about who I am and who you are and why we're talking about this stuff. And then there's going to be a whole bunch of slides in which I talk about various process things and experiences that I've had over the last couple of years of being a developer. On slide 33, we're going to take a break for cookies and then we'll continue for a few more slides until the end where we'll have hopefully if I go quick enough time for a Q&A. There's like 38 slides so that's roughly a slide per minute and then we get like 10 minutes to have Q&A at the end. We'll see how it goes. I'm a developer. I've been doing Drupal development for probably about 10 years at this point and I'm going to momentarily pause because this is not showing my presenter notes. There we go. Confirmed. 10 years is what I wrote. So I've been doing web development for probably about 12 years. I've been focused on Drupal for the last 10. During that time I've worked at a number of different agencies. I've also worked as a freelancer. I started out at a small company in Minneapolis, Minnesota. There was actually a print and publication design firm and didn't do development at all and over time we started doing web development. I transitioned into being the lead of the web development team there. That team grew. I eventually needed to move on to other things. I did freelance for a while, ultimately ended up at Lullabot. I've worked on teams from just myself being like the project manager and the lead developer and the junior developer and the Q&A team to teams where there's multiple project managers, 30 plus developers, things like Drupal.org where there's thousands of developers. I would consider that a team that I've worked on as well. During that time I've never been a project manager before. I don't particularly have a lot of interest in being a project manager. I really like the day-to-day like sitting down and writing code. I definitely have those afternoons where I want to bang out some code and be done with my day and have somebody else kind of telling me what to do. But I've also often found myself in leadership roles on the teams that I work on. Usually as a result of having been the first person on the team and then just by default you're there for a couple of years and now you're the person that knows the most and now you're the leader even if you don't want to be the leader. But as a result of that I feel like I've gained a lot of experience of what it means to be a leader on a team. I've also worked with a bunch of project managers over the last couple of years. You know, those experiences have been both good and bad. This presentation is about trying to translate those experiences into information for project managers and to give them a better sense of when you're talking to a developer what are they hearing you say. When I first kind of conceived of this presentation I thought this is going to be a presentation where I'm going to stand up at the front of the room and the room's going to be full of project managers and I'm going to tell them if you want me to do things this is how you get me to do them. But the more I thought about it I realized that like the messages that I had to give were relevant for project managers but also for anyone that's part of a team. Because if you're part of a team it's important for you as a team player to understand how everyone else on your team wants to be project managed so that you can help them accomplish their goals so that you know how to ask them when you need help or when you need them to do something. And so I started to realize that this talk was sort of it's for project managers but it's also for anyone that's part of a team. So this is what I'm going to talk about roughly in this order hopefully. I'm going to spend a little bit of time talking about things that motivate developers. What are those things that make you get out of bed and go over to your computer and actually turn it on and start working. I'm going to talk about I'm going to spend quite a bit of time talking about the process that we use for doing development on the DrupalizeMe team mostly because it's the thing that I'm the most familiar with because I've spent a lot of time on this in the last couple of years. But also because I feel like the process that we have currently ends up being kind of an aggregate of all of the knowledge that I've gained and everyone else on the team has gained over our 10 years or whatever it is as being developers. So I've got some stories that I'll share and then hopefully lessons based on those things that we've tried and what's worked and what hasn't worked. And then I've got some other random tidbits that will fill in there. That's right about the same time as the cookie break and then of course there'll be a recap at the end and which I'll tell you everything that I just told you. So last thing set in context because I will probably interchange these words and not even realize I'm doing it. When I say the word ticket or to do or task or probably any other set of words what I'm really referring to is some kind of actionable item that someone else on the team or myself or a project manager could assign to me to do assuming that it has some maybe defined amount of time that we'll take to do it and it definitely is something that it's the thing I can cross off my list at the end of the day when I'm done. All right so that's all of our context. So I think it makes sense to start out by talking a little bit about motivation because motivation is the thing that gets us up in the morning and gets us to go to our computer and turn it on and select a ticket to work on. It's the reason that we kind of do our jobs and do a good job of doing it and so as a developer it's important to me that the project managers I work with and anyone else on my team that I work with understands what the things are that motivate me so that in a sense they can use that as a lever to manipulate me into doing a good job or doing the tickets that they want me to do and I don't feel like doing but really like if you understand what motivates me that's your leverage to get me to do something. And for me this is kind of like it's not the things on the motivational poster that say aspire and then there's a picture of a mountain and you assume oh I'm supposed to aspire to climb to the top of that mountain. This is more like the things that motivate me to like not fall asleep at my desk. So for the most part they're pretty straightforward and I think that they'll apply to most people but these are my motivations. So remember that and hopefully this will be an exercise in getting people to sort of think about and identify the things that motivate them as well. So for me hands down the thing that motivates me to do work and to do good work is having fun doing those things. If I'm given a task that I think is going to be fun to do I guarantee you I will complete it I'll do a good job of completing it I'll probably exceed your expectations and I'll be smiling when I'm done with it. You know I could think about this and go when was the last time you heard one of your co-workers say oh man I'm so excited and proud of that really boring thing I just worked on like it it doesn't really happen. But what's cool is for me and probably for everybody the things that we consider to be fun are going to be different so in a team where you've got multiple people understanding what each person thinks is fun is important I might find what do I find fun I do not find recurring billing systems fun however I do find them challenging which we'll talk about in a minute I find it really fun to be able to solve tasks that I can see have a direct impact on DrupalizeMe's customers so when somebody can go oh man I'm really glad that I can add this to my queue now that's a fun thing for me to work on so number one motivation for me is I want to work on things that are fun because I'll do a better job at it if I think it's fun but I can also pretty easily change the word fun with a couple of other words and I think that this holds true for a lot of developers not necessarily everyone but I've been in the years that I've been doing development I've also been in a lot of interviews to like hire new developers or to be hired as a developer and they always ask you that question like you know what do you want out of this job and I feel like ninety percent of the time when I'm talking to other developers they say things like I want to work somewhere that challenges me to do a better job or challenges me to learn new things I want to learn new things like as a developer I think this is a common especially web developers when a field that's moving so quickly we get excited by being able to learn about all the new things that are going on and when we get the opportunity to do so that can be really motivating so for a project manager or for someone else that's on my team and is kind of asking me to do things if you can understand the things that I find to be challenging or fun that's a lever that you can use to help get me to do those but you can also understand that I like working on a challenge and I may encounter tasks that I'll initially push back on and I'll say I don't think I can do that that's kind of outside of my realm of what I'm familiar or comfortable with and I really appreciate when other people that I work with push me to try to accomplish those things even if I might think I'm not capable of it and a lot of times those end up being some of the most rewarding things for me to work on in the end because I've not only had fun I've exceeded my own expectations and that's a really motivating feeling the other thing that really motivates me and this is kind of recursive like the desire to do good work motivates me to do good work I really want to build awesome things and I think this is also true of a lot of developers we get excited when we get to kick ass and when we get to do our best work I live in Minneapolis currently and I live about two miles away from my mom and it's awesome because a couple of times a month I can go over to my mom's house and she'll make dinner I can hang out and have dinner free dinner it gets really cold in Minneapolis in the winter and so it's even better when I can go over to my mom's house and have dinner in the winter and she makes soup and my mom makes the best potato leek soup you've ever had it's awesome hands down the best when I left Minneapolis during college I left for a couple of years I moved away I started to get homesick so I called my mom and I asked her for her potato leek soup recipe and she sent me the recipe I went to the store I bought all the ingredients I tried to make the potato leek soup and I made it I you know I followed the recipe I crossed all my T's and dotted all my eyes and I did everything I was supposed to and the soup was okay but it wasn't awesome so I go back and I have soup and I'm I go over to my mom's she makes the soup again and I'm asking her I don't get it how come when I follow your recipe my soup never turns out as good as the soup that you made and her respect it's like do you have like a secret ingredient you put into this do you have some kind of metal in your pans that isn't in my pans what's going on here and that response that my mom gives is well I put love into the soup that I'm making and for me I want to be able to do that with the code that I'm writing I want to feel like I'm loving the thing that I'm working on because if I can do that I'm going to kick ass at it and so as someone else on my team and especially as a project manager it really helps if I'm if you're in a position to prevent me from having to cut corners and not and make it so that I have the time in the space to put that extra ingredient into all of the work that I'm doing I totally recognize that this isn't always possible like we have deadlines we have obligations that we have to meet but whenever it is possible it helps if I have the space to do things the right way the first time and not have to go here's my quick fix I hope to come back and fix this later on it's gonna be great when I do it the right way next time because I'll never do it again so I like to work on things that I want to work on and I want to do a good job working on them of course like I said earlier not all developers are created equal each of us finds different things to be fun or challenging each of us are motivated to do awesome things for different reasons but all of us do have motivations and it's important to understand what our motivations are and what the motivations of other people are on our team are as well so I encourage you guys to take a minute either now or at the end of the day or next week this is this is your one and only homework assignment from this presentation spend some time thinking about what motivates you but also spend some time thinking about what motivates everybody else on your team to try to write those things down for me this was an interesting exercise to try to write down what are like the three things that really motivate me to do awesome work and then it got really hard when I had to go through everyone else on my team and try to write down the three things that motivated them to do good work I couldn't do it without asking them so that's where the second part of this homework is once you've made that list or once you've started to identify for yourself what makes you want to do awesome work as a developer you need to tell everybody that you work with because they probably don't know I mean it's one thing for me to say I like to do things that are fun and it's a totally another thing for me to identify what is fun or what I find to be fun the more that my co-workers know about that though the more likely it is that they'll be able to put me in a position where I'm working on those types of things I feel like what what how's the saying go it's admitting that you have an addiction is the first step to solving that addiction admitting that you have motivations is the first step to being able to be motivated or as Sir Michael Philip Jagger likes to say you can't always get what you want but if you try sometimes you just might find you get what you need to me this is that like yep I know that even if you know all of the things that motivate me to do good work I'm still gonna have to fix typos once in a while even if it's not fun like I'm an adult I know what it takes to have a product what it takes to launch a website and I'll get those things done but if I can identify for the people that I'm working with what's fun for me and they're put into a scenario of all other things equal they've got two tasks and they need to pick which of those two to assign me why not assign me the one that I'm going to find fun and assign somebody else on the team the one that they're going to find challenging and as a learning opportunity and you can't do that if you don't know what motivates the people on your team what a break so motivation that's a kind of a little bit about the things that motivate me and encouragement to think about the things that motivate you I want to spend some time now talking about the development process that we use at Drupalize me currently and used to use and how our ability to spend some time thinking about the things that motivate ourselves and everybody else on our team has allowed us to adapt our process in such a way that we can hopefully better accommodate people's motivation I'm gonna talk about these processes at a pretty high level and then I'll spend some time talking about particular change or specific changes that we've made to our process and not so much like the change itself but more of the lessons that we learned by making those changes so background let's say step back a year ago one year ago Drupalize me this is kind of how we did work on it on the Drupalize me website our development cycle looked like this we have roughly a two to six person development team depending on the week with and people's availability during the week each developer on the team also usually has a different number of hours depending on the week like I said for me sometimes I have five hours for training training and 35 for development sometimes I have 35 for development in five hours for training it was back and forth in that scenario we ended up with a ticket tracking system we use a ticket tracking system called unfuddle unfuddle allowed us to group tickets together into various unfuddle calls them milestones I'm just called in big buckets of tickets what we did was we had a big bucket of tickets the backlog so just one giant backlog of the 800 plus things that we needed to accomplish on our site we had two week sprints during a two week sprint we would create a new bucket the project manager would pick what I'm pretty sure was just a bunch of random tickets out of the backlog and put them into this new bucket and then assign them to people based on well Joe's got five hours so I'll give them the one that I that I the project manager think we'll take five hours and you know Kyle's got 35 hours so here's a few tickets that will match 35 hours we'd go to work to we at the end of the two weeks I'm expected to have completed everything that was assigned to me in the sprint bucket we have a review usually in the review we realize we only accomplished half of the things that we have planned on and half of the things that we did accomplish weren't done as well as we could have done them then we launched that version of the site and it worked like and this is a pretty common way of attacking that problem like I'm a project manager I've got a bunch of developers I need to give them tasks to work on and it's certainly I'm not trying to say that this is a bad way of doing things by any means I'm just kind of identifying a year ago this is what we were doing I'm going to tell you more about what how we do this now and then talk about some of those changes that we've made and why we made them so last week at Drupalize me when we wanted to work on development tasks this is how it worked same team we've got roughly two to six people working on development varying number of hours instead of organizing all of our tickets into one giant bucket of everything and then a smaller bucket of the things we're working on right now we've organized all of our tickets into big picture goals based on conversations that we as a team have had about the project that we're working on where we would like to see it be in the future how we think we might get there in which tickets in sort of go in those specific buckets each of those buckets at this point has somewhere between like two and twenty tickets in it depending on what the goal is instead of this scenario where the project manager assigned each of us x number of tickets and we were expected to accomplish them by the end of the week we actually let all of our developers just choose any ticket from any bucket that they want to work on at any given time they still have x number of hours and they're expected to fill that number of hours during the week but they can choose the task that they want to work on we do one week sprints now instead of two so it basically works out to during the week I can choose anything I want to work on once I've completed I mark it as resolved it goes through a QA process if it's been through QA by the end of the week it will be live on our site next week and this in this scenario amongst other things I feel like this is allowed project managers to focus more on helping me as a developer remove the things that are blocking me from getting worked on helping me to work on tickets that I find challenging or motivating and spending less time going do you think this ticket's going to take five hours or 15 hours and is this should I put it in the bucket this week or next week amongst a bunch of other things that's kind of our current process of course this is our process and I think it's important to recognize that every team's process is going to be a little bit different because the people that make up a team are always different and the motivations of the people on that team are always different it's really easy for us to fall into this like look somebody wrote down their ideal process on a blog post and I've read it three times that must be what our team needs to do to when in reality you probably want to do most of that with a couple of minor variations that make the process right for your team the other thing is that process should be fluid you should allow your process to change over time and we continue to allow ours to change over time a year ago the process that I described that we had been using a year ago that was also the process that we'd using been using the year before that and the year before that and the year before that and we kind of once when we started working together as a team identified well this is how things should work and we wrote it down and we continue to do it that way forever because that's what was written down eventually we realize like it's probably okay for us to make some changes to that process and they started out really small and they continue to be small changes but they're incremental and over time they add up and we start to get this process that works for all of us and what we found out is that like we started to understand what motivated people on our team to do good work and what motivated you know each other to do good work and we realized that the process that we put in place and that we use to do our work should also facilitate us doing good work it should facilitate the things that motivate us so that we get to work on the tickets that we want to our process should motivate us to do good work and it shouldn't hinder us and make us feel inefficient or bogged down or frustrated that it's Wednesday and it's a third day of a two-week sprint but the project manager hasn't yet put anything into my bucket so I've just wasted two days not doing anything because they're still trying to load this sprint up or whatever the case may mean so process should be fluid and you should adapt it to meet the needs of your team our changes started out really small the first one that I can remember changing was actually a two-word change to the label of a bucket of tickets in unfuddle and all of a sudden it was this like opening the floodgates and we were like holy cow we can change things and changing things mean we work better together as a team so the example here is we we had all of our tickets in this giant backlog and we would pull tickets from that backlog and work on them doing the sprint the backlog at the time was named MVP or minimum viable product and the idea was once we had cleared all of the tickets out of this backlog we would have a version of our site that we could launch there were like 400 some tickets in this MVP backlog and it would play out in that I would always be trying to add more tickets to the MVP backlog because I was like I don't want to launch a site that doesn't have search working I don't want to launch a site that has a regression from the thing that we've already got like I don't want to cut these corners and the project manager going we don't need this one we don't need this one we can do this one later it'll be just fine and it was really frustrating for me because I wanted to do good work but I felt like I couldn't because all I was working towards was getting the minimum done so we changed the label of that bucket from minimum viable product to launch blockers that was it we just labeled the bucket differently and we said this is the list of tickets that we need to solve before we can launch the version of our site and had this huge like impact on the morale of our team we went from being like oh man this sucks like I'm so excited about launching this thing that I'm not excited about to oh man we've only got 20 tickets left in the launch blocker backlog we're getting really close let's get this done and we can launch this version of our site and it still played out the same I still tried to add tickets to the launch blocker backlog the p.m. still as far as I could tell randomly through tickets away but it worked out in the end and we're all more motivated to do good work that simple change also led us to realize that it was okay for us to change our process to and that maybe we should reevaluate the way that we're doing other things and see if there were like other gains that we could get from looking at our process so we had a team retreat we didn't really get together to talk about our development process but we ended up spending like an entire day or more talking about our development process while we are there and during the team retreat I proposed what would it look like if we allowed everyone on the team to just choose what they wanted to work on when they wanted to work on it and I was like this is like my dream world right I get to show up on Monday I get to pick whatever ticket sounds fun I get to work on it if it's not fun I'll just stop working on it and work on something else this is going to be awesome and this will allow me to meet all of my motivations because I know what motivates me I also felt like this scenario would allow for me to have a higher satisfaction in the work that I was doing because it's not all made with love aspect I would get to be proud of the things that I was working on because I picked things that were important to me and I also felt that this was going to help facilitate better communication amongst our team and this was maybe a little bit naive but in the end it did pan out but initially I was like yeah it'll be great we'll just have to talk more because we'll need to know what other people are working on and we'll have better communication as a result turns out it's actually really hard to talk about chaos which is kind of where some of this other stuff comes in the pushback on this of course was as the project manager or as the product owner especially there are things that are important to me or that I know need to get done in order for this project to be successful and I need some ability to tell you you need to do this thing this week because if you don't you're blocking Justin from doing the thing that he needs to do but we talked about this a bunch and we came up with some ways to resolve that problem it ended up with what we call road maps really what the roadmap is is it's a document that defines our team's goals for the next quarter so we set quarter one quarter two quarter three goals and these goals are really big picture there are things like we would like to improve the experience for people browsing our library page or we would like the ability to sell gift certificates on our website but we spend some time as a team kind of going through that exercise of saying these are all the things that are important to us our roadmap allows for anyone to write down any goal and you there's basically like a sandbox at the bottom and you can say man this is something that's really important to me and I want to talk about it with the team in the future we've also got our current set of goals which is these are the things that we're going to work on for the this quarter this was cool because it allowed us to talk together more about the the ideal product the ideal end result for this project and what each of our individual goals was this also ended up having the sort of by product of providing a lot of structure for me randomly choosing tickets from this bucket of I can work on anything to now I kind of identified like as a team these are our goals and if we want to meet those goals as an adult and as a good team player I should probably pick tickets that are related to those specific goals I don't have to like if it's Tuesday and I really don't want to work on our billing system I can pick a different ticket and it's fine but for the most part I'm happy to pick those tickets that will help the team accomplish its goals and I'm still getting to identify the tickets that are fun for me so I'm picking from maybe a smaller bucket but I'm still picking tickets that are a good fit for me it also provided kind of like a motivational rallying point for our team it was the ability to like get everybody excited about a particular thing and it was amazing the amount of efficiency we would have when we recognize like our goal as a team right now is to redesign the page that has the video player on it and everyone would be like yeah that's awesome I can see how this is going to be better for our customers let's all get really excited about that the roadmaps are created by our whole team so they're not just the product manager or the project manager saying these are the goals for the team you have to do these things whether you'd like to or not we actually spend time each quarter kind of talking about the goals that are already on the list deciding for right now these are the ones that we'd like to move to the top and have be our focus this worked out really well too because back before Christmas one of the goals on our list was we'd like to be able to sell gift certificates and as a team we went you know if we're going to be able to sell gifts or tickets it sir that if we're going to be able to sell gift certificates we might as well have this would be better if we could have this feature accomplished and usable before Christmas so we very quickly bump that goal up to the top of the list but everyone was on board with that because we all recognize the importance of being able to sell gift certificates before Christmas and not just having this be something that we launched somewhere in the you know April of 2014 and we were like look you can get an Easter gift certificate so it these roadmaps and defining what our goals as a team were allowed us to sort of channel that self assignment of tickets and in a weird way has really allowed the project manager to again leverage me into doing the tickets that they need to get done but they're doing it not by saying you have to do this thing they're doing it by saying this is important to our project this is important to our product and as a team we've identified this as a goal that we can all rally around and accomplish and I go oh man I can totally help with that I'll choose that ticket and that ticket and then the project manager goes that's what I saw as a result of this some other things that we've gained from having this allowing people to choose now choose whatever the ticket they want to work on from the pool of you know we basically narrowed it from like 800 by setting goals we know from like 800 to like 10 but I'm still choosing what I want to work on right and I'm totally that rebel as soon as my mom is like you can't go on a bike ride I'm like oh you want to bet I'm going on a bike ride as soon as the project managers like you need to work on this ticket I don't want to work on that ticket but if I'm like I'd like to work on this one and the project manager goes that's fine it needs to get done like that's a whole different mentality for me we've ended up with tickets that have way better descriptions and the reason they have better descriptions is because the person writing the ticket needs to write it in such a way that you define not only what the problem is but why solving this problem is important to us as a team so that someone else on the team that's capable of solving the ticket or like resolving that task will go oh yeah I can see how this is important and choose it so we write our tickets now with a whole section dedicated to the problem and the motivation for solving this problem it's pretty cool it also gives us the excuse me it also gives us a much better understanding as a team of what our overall priorities are we've spent some time talking about them we've written down these goals we now know that like as a team our goal right now is to launch the gift certificate feature in time for people to purchase gift certificates by Christmas we also learned that you know each of us on the team are responsible adults too and even though I'm in this world where I can choose whatever ticket I want to I recognize that sometimes things just need to get done like sometimes we just need to fix the typo sometimes there's a PHP error and I just need to fix it so that our site works and it's been a really rewarding experience to have my managers recognize that level of responsibility in me as a developer to say you can choose whatever you want to and we recognize that if something is really important that that you'll make sure it gets done because I think we all know that you know we can identify what's important to getting this project completed or to keeping our website up and running and if you can you should probably have a discussion with your team about what's important and how to keep your website up and running all of this kind of resulted in us like learning more about how we as a team work together and what our vision was and as a result we end up building in much building a much better product and being more successful together I like this quote it says great teams it turns out begin with a shared vision a unified clearly articulated belief about the software they are creating and I think it's true like you think about even a project like Drupal it's really successful because the people that are working on it are excited about it they have well to some extent a unified vision of what Drupal will be if if content management system is a vision but and being able to articulate what you're building what this allows for is me to get excited and to make sure that we're building a more polished thing together this whole idea of allowing people to choose the things that they want to work on I found out after we kind of switch to this I was like oh man this is awesome we're like totally innovative not really turns out people have been doing this for years and it just took us a while to catch on one example that I came across of this was the multiple alternatives program or map which is a program that Oracle use used to have I don't know if they do anymore but I think it really kind of helps to illustrate how these things could work Oracle big software company they're always trying to hire like the best developers in the world so one of the things that they would do is they would go around all of the top computer science universities and they would talk to all of the top graduates from each of those classes and they would offer them jobs and the job description you got was come work at Oracle not come work at Oracle and be a web developer come work at Oracle and be a DBA it was just we'd like you to have a job at Oracle and as part of that job you get to spend your first two weeks walking around meeting the people that work here figuring out what all the projects are the people are working on figuring out what sounds fun to you and then you can decide which of those projects you want to work on and what you want your job to be and this worked out presumably really great for them because they were able to attract top talent by saying you get to do whatever you want because we like to do whatever we want but they got to have all of that top talent in house now working on well at least something at Oracle and not something at one of their competitors and I also found out there's actually a lot of books about this stuff too and turns out project management is actually a thing and like when the project manager told me yeah this is important and my role is to assign you tickets okay so there are other resources as well this is the part where I kind of go more into these additional things that we've learned from changing these processes we changed from two-week sprints to one-week sprints initially we just did this because I really had this idea as a developer that I needed to have continuous integration because this is the thing that everyone was talking about and I wanted to set up Jenkins and like when I committed code I wanted it automatically deployed to our site because I was going to be awesome we don't actually have that but we do have one-week sprints instead of two-week sprints and what I learned from this was that I didn't really care that much about continuous integration it sounds nice but I love the fact that I can more quickly get the work that I'm doing in front of people who care about the work that I'm doing the two-week sprint had this byproduct of like you spend you solve a ticket on Monday the first Monday of a two-week sprint no one else other than the people doing QA are going to see the results of that for a minimum of two weeks more likely two and a half or three after it's gone through all of the QA and regression testing and it's frustrating because you know I deal with customer support on our site a lot and I would often get these questions that are like oh how come this button doesn't work and I would go look and I'm like yeah you're right it doesn't work and I'm thinking that would be a really easy fix but instead of just fixing it I'd have to write a ticket and I have to put the ticket in the minimum viable product backlog and then the project manager be like we don't need this ticket and then I'd be like it's so easy it would take me like 10 minutes and it would take somebody else like 10 minutes to do the QA on it and now it's six months later I'm getting back to the customer and going I'd like to inform you that we have made it so you can click on this link and they're like oh I'd like to inform you that I canceled my subscription three months ago now I can on Friday say oh man this sucks I can fix that really quick I can go and write the ticket and then I can choose the ticket and then I can solve the problem and I can commit the code and on Monday it'll get into QA and somebody QA it'll only take like 10 minutes because they're going oh yeah the big works when you click on it and then on Wednesday it's live on our site and I can write back to our customer and I can say hey thanks for pointing that out we went ahead and fixed it and they're like oh that's awesome this is totally solving the problem that I was having now thank you and we've made our customers even happier we also learned that sometimes changes to your process aren't always pretty some we've made some changes that we kind of went we thought this was a good idea but it's not going to work as well as we thought the whole like choose your own tickets was this initially it was like here's your giant bucket of tickets and us developers were like huh I'll do this one and that one and there was no cohesive like getting anything done so we allowed our process to be fluid and adapt and we started adding things like the roadmap to address that so be aware that when you change your process it might not always work out the way that you thought it would but if you're willing to allow for change you can always revert that thing that didn't work out and try something different so what we learned from excuse me what we learned from changing our processes and talking about motivation we I learned that as a developer I want to do my best work and that as a project manager or someone I'm working with I want you to facilitate me in any way that you can to allow me to do those to do my best work I'm more productive more motivated more excited I have more fun and I'm more challenged when I get to pick the tickets that I'm working on because I know what I find fun and challenging and motivating and engaging and all those other things that motivate me we learn that as a team the more that the developers on the team understand what the mission is of our whole team the more we have a unified vision the better we can do it helping achieve that unified vision we learn that process should be fluid and that it's okay for us to make changes to our process and that we don't have to get stuck in this you know the book on scrum says you have to do it this way we'll only ever do it that way so we can make slight variations to that and it's fine we also learn that I like cookies because I've had at least two slides they contain cookies a few other things change your process and then document those changes to your process especially like you know project managers I'm a developer I understand API's I know how to read API documentation I know like if I need to ask a question of Drupal this is the function that I call to ask that question and this is the format that I expect the result to come back in it's nice if I can have that same sort of process or that same level of understanding of the process that we're using as a develop as a development team project managers think of your documentation as sort of like the API that you want developers to use to interact with you again process should be fluid which means you need to keep your documentation up to date this is true of like development documentation to write how many times if you like tried to query Twitter's API and they haven't updated the documentation yet you're like nope that didn't work nope that didn't work I'm just going to throw things at this black box and see what comes back if your process is the same way it's kind of ineffective if I have to go to my project manager and just kind of throw things at them and say like can I get the answer I want how what if I do this what if I do that not very helpful having good documentation helps improve the communication between me and the people that I'm working with because I know who to ask questions to you and I know how to ask those questions and I know when to ask those questions and I know when to expect a response to those questions and I know what format the response is going to be in and so in a lot of ways us taking the time to step back and go we should probably write this down and codify it really allowed for us to have better communication as a team it also makes it easier for someone that's new to the team to communicate with everyone else on the team because they can say this is how as a team you guys already work together and I can understand that because I can read the documentation I don't have to just start throwing things at a black box and see what comes back sort of off on a tangent here now we're kind of going from the things that I were process related to things that I've learned by working in this new process with various teammates and project managers as a developer it's context switching is really complicated the the whole like somebody pings you and IRC and they're like hey I've got a quick question for you and I'm like okay I'd like to know if this thing is important I don't know if it's important let me go find out if it's important and then you're you know 10 minutes later your responses now it's not really important I'm gonna go back to what I was doing before and I get back to what I do is doing before and I'm like halfway through a line of code I don't remember what I was doing so now I've got to spend 15 minutes figuring out what I was doing by rereading the ticket and all of that stuff context switching is hard I taught a workshop once with one of my co-workers Jeff Ian and we were we're teaching people about the features module really we're teaching people about teaching people about the concept of deployment and Drupal and we're using the features modules an example and we knew that inevitably people were going to ask us how do you deploy content and we were gonna have to say oh it's Drupal you don't but we didn't want to say that in this workshop and we couldn't come up with a way to get people to to really make this easy for people and so Jeff's solution was insert a slide with a picture of cookies and I was like what is this gonna do and he says oh it'll be great because we'll ask everybody to you know context switch we'll bring up cookies we'll tell some random story and then we'll come back to the next slide and we'll have just totally skipped the part about content deployment and I'm like that's being brilliant so this we're in this workshop and the slide comes up right when the switches to that slide and it's like this picture of a cookie and a hand pointing in this direction and says cookies the like hotel catering staff walks into the room with a big plate of cookies for like our afternoon break and it just like worked out perfect not planned but it works out perfect so we're gonna we have a 15 minute cookie break and we come back and the next slide that Jeff has is something like totally unrelated to content deployment and we just pick up from there and we have at the end we said I'm sorry we tricked you guys this is really hard but seriously context switching is hard who here remembers whether or not the slide before the one with cookies on it had a period at the end of the title right context switching is hard and the only way that I can know is to go back to that slide and reread it and figure it out this has resulted in us starting to come up with what I would like to dub the emergency classification system one of the things that we deal with a lot is someone else is doing support they ping me an IRC and they say one of our customers just contacted us and they said that this isn't working is this important do we need to fix this right now and I go I don't I don't know if we need to fix it right now or not but let me go find out and I'll tell you if we need to fix this right now and now I'm in it and I'm halfway into the code and I go well this isn't really important but I'm already here so I might as well fix it so I fix that thing and now it's the next day and I'm finally back to what I was working in before and the only thing I have to remind me of what I was working on before is the fact that I have like a dirty working tree and get I'm like I must have been doing something so we started to talk more about what are the scenarios in which a project manager should ask me to contact switch to solve a problem for us right now this definition basically boils down to things that we would consider a hot fix for our site so like something isn't working we need to fix it right away and for us the definition of hot fixes basically would you ask me to leave the bar on Friday afternoon during happy hour to fix this problem if you would this is an emergency and we should deal with it if it can wait till Monday don't send me an email till Monday it'll be fine there's lots of ways to think about this problem but I would encourage you as a team as a project manager to think about when you're going to interrupt what your developers are doing and why you're going to interrupt them and as a developer to talk to your project managers about the things that are interrupting you that maybe don't need to because I think a really good project manager for me as a developer sort of acts as an abstraction layer between me and the work that I need to be getting done and all of the things that are happening around me as a developer I've been hired to write code and solve these problems and I shouldn't be having to solve all kinds of other not necessarily non-code related problems but kind of like tangential problems and for me a good project manager is someone that can identify those things before they're put on my plate so that I don't have to context switch and deal with them that they're just handled for me so I can continue to do the work that I'm doing my example here is a couple of years ago I was working on a top-secret project at Lullabot and we three of us were flown out to Lullabot's offices in Providence Rhode Island to have a week-long sprint there's actually a three-day sprint to work on this project they fly us out to Providence Lullabot's got this brand new office in Providence so we're going to go check it out this is going to be the first sprint that we have there we show up at the office on Monday morning ready to sprint and we walk into the office and it's empty there's no chairs there's no tables there is nothing in this office so instead of sprinting and writing code and getting things the things done that we were brought there to do we end up going to IKEA instead and we buy a bunch of tables while we buy a table and a bunch of chairs and we bring them back and then we spend the afternoon assembling them and now it's like three in the afternoon and I'm not going to start anything new because it's three so I'm going to go to the bar and have a beer instead so we go to the bar and we have a beer and then we go to the hotel and we go to sleep and then we get up in the morning we go back to the office it's Tuesday morning we're in the office we've got this big list of things that we have identified that we're going to accomplish during this sprint I pull out my computer I turn it on there's no internet it's like how am I going to do anything on a Drupal project without internet so instead of getting down to work we go to the mall we go to the clear store we buy some internet we're at the mall already my co-worker's like you know I kind of wanted a new phone so we go to the AT&T store you buy a new phone well we might as well get lunch so we get lunch then we go back we're at the office we open up our list all right we can get connected to the internet so we can see what our list is and by the end of the day we've basically gotten that list written down on the whiteboard and that's about it we go to the bar we have a drink we go to the hotel we go to sleep we get up the next morning we come back to work and now it's Wednesday of a three-day sprint and we finally get to start working on the things that we came here to work on but if somebody had thought of those things ahead of time and realized like I really don't need them to contact switch I really don't need them to spend their time building chairs create buying the internet that kind of stuff if those things had all been in place we could have accomplished everything on our list in those three days instead we accomplished about a third of our list in those three days we never came back to that project again we never accomplished the rest of the stuff on the list the product never launched there's still a splash page for it that exists that we occasionally get people emailing us and saying hey what is this thing is going to launch or like oh when somebody decides to finish the other two-thirds of this list but who knows what could have happened if someone had abstracted that away if they had if the chairs were there and the internet was working and we could have successfully completed everything on that list so as promised a recap of the things that we talked about motivation know what motivates you and know what motivates the people on your team both as a project manager and as a developer working with other developers knowing what motivates the people we're working with is really important because then we can use that motivation as a really giant lever to manipulate them into doing the things we want them to do recognize that it's okay for your process to change and that sometimes a process that isn't the right fit for a team can really curb the motivation and the morale of that team and that sometimes simple changes like the change from minimum viable product to launch blockers might seem like oh who cares can be really really important and really change the morale of a team and allow your process to change over time don't feel like you know as the project manager I have to come in here and define this process that we're going to use on a tablet that I then hand to every developer that comes into the project and you've now got your big stone but nothing about it defines everything you're supposed to do but nothing can change allow your process to change over time and adapt it to the people that currently make up that team and when somebody leaves the team or when somebody joins the team make sure you reevaluate the process to so that it's fitting everyone on the team that's my messages about motivation and process and such if you would like to fill out a survey you can go to this url or you can just go to the page on the conventions or on the conferences site for this session and there's a survey there I will also be hanging out up here for a little bit to answer questions otherwise I'll be down at the lullabah booth and you can stop by and ask me questions there thanks for coming I think we also have a few minutes left so if people do have questions I'm happy to answer them now as well yeah I'm sorry I can't hear you Mike or you can just come up here and I can repeat it into the mic here you go ahead you first can you hear me now I can all right good needed some exercise to come back so did you find any kind of productivity kpi metrics that kind of work for everybody devs and pms and executive management and what not like how do we know we'll be in productive as a team like produce an excellent award how do we measure productivity and know that the changes to our process have improved or decreased productivity of the team for us it's mostly just been kind of like gut feeling we don't have any real metrics in terms of like graphs that show number of tickets completed over time or that we've we've kind of based it off of do we feel like we're accomplishing more for the drip lies me team anyways we're a pretty small team and that's worked for us I think that you could though pretty easily like a system like unfuddle or github allows you to see burn down charts for tickets that are accomplished but that's not always a good measure either because you know some tickets take five hours and some tickets take 30 hours it for us it really was more of a being able to talk about our process from a a bit more of a personal level and less of a the numbers show x level so far it's an interesting question though and I I haven't yet looked into any sort of system for measuring that yeah I totally get that so it's the like your client wants to know if you change the process how do we know that it's going to make things better or yeah or even what is the current rate of anything I unfortunately I don't have a good answer to that I as as a developer I could probably write the software to do it as a project manager I don't even know what the yeah hi um a really good idea in terms of the shift from you know doing kind of with randomly throwing something into sprint to doing what the developers you know kind of feel the most fulfillment from right now we we do it where for our sprints we have an external client and so we we do what's dubbed like the most important items I put kind of in air quotes high priority yeah so how would you suggest kind of approaching you know that change sure so for for external clients because it sounds like you have an internal client right basically yeah so what's the difference so in that scenario where like you've got someone else that's kind of identifying the priority of tickets you still do have a a bucket of tickets you've still got maybe 10 tickets that need to get accomplished and you can at least start to figure out is there a way that as a team we can make sure that those 10 tickets are getting assigned to the people that are the most interested in fixing them you've got three people on your team and 10 tickets like let those people choose of those 10 tickets which ones are going to accomplish you can limit it to say we have to get these ones done we actually did a lot of that initially and it was a bit more of a process of as a developer but the start of a sprint spending some time in conversation with the project manager who would tell me these are the things that I think we need to get done during the sprint and I would say of those things these are the ones that I would kick ass at these are the ones that would be fun for me these are the ones that I'll do if I have to but I don't really want to sometimes you have to do the things you don't want to too and that's fine but if you can let people do the things they do want to you're going to be better off okay so if I heard you correctly basically instead of trying to get like which ones am I going to be the most productive at it's more like which ones am I going to be the most motivated to do and that kind of changes changes I think for me at least that helps like I'm going to be more productive at the things that I want to do like if I don't want to be changing this typo I'm going to check Facebook instead right right all right thanks a lot you bet hi Joe thanks very much for sharing your experience you're welcome so you so the the Drupalize Me team is all distributed is that correct correct yeah so how have you dealt with encouraging feedback on the process in that are people very upfront about saying this process is not working for me or do you have have you built in structures for doing you know feedback between you know one-on-ones or 360 feedback or other forms of that thank you yeah so how do we as a distributed team especially how do we continue the conversation about process we don't currently have a formal way of doing that we do when we set our goals for each quarter we have a call or usually a couple of calls where we kind of talk about what the goals are and then amongst it within that like is the system still working for us we also have team retreat retreats team retreats and at our retreats we always talk about process now and just kind of a is this working for everybody is this not working the truth of it though is I think what we've discovered is people don't often recognize that it's the process that's blocking them and that you need to get people to start talking about where their points of frustration are or what's kind of painful for them right now and then be able to identify that as a process problem the minimum viable product thing for us was one of those like I had a lot of conversations with people basically being like I'm really frustrated that I'm having to build something that is just the minimum and you know ultimately having the project manager recognize you know if we just change this that would make a big difference yeah and also Emma just yelled this out whiskey which really boils down to find opportunities to be in a social environment with your co-workers and talk about your process and talk about or not even process talk about like your motivation and what's working and what isn't working we don't yet have a formal way of reviewing that I wouldn't be surprised if that's something we start to add down the road but this is all still pretty new for us as well how do you how would you characterize the line to draw between what a PAM should abstract away versus what the developer should be able to either pick up or figure out or or would want to kind of do their own research or you know how much of that where do you draw that line between what what they should provide and what they should kind of let the seem though on their own right like when should the project manager put together the chairs and when might I want to put together the chairs myself yep hmm that's a good question I would say that again that's a little bit about kind of as a project manager understanding the things that motivate the people on your team and knowing like that Joe finds recurring billing to be challenging but he enjoys doing it because it challenges him and he enjoys challenging projects and probably just remembering to talk to people about it too you know inevitably you're going to end up in a scenario where you can't abstract things away if you don't know what needs to be abstracted so I would say trying to as the project manager trying to make sure that you have an open line of communication for people to identify to you these are the things that are blocking me or are frustrating because I have to do them and I don't feel like I'm productive when I'm doing them would be a good place to start thanks yeah hi Joe great great talk today learned a lot thank you thank you just so quick question as a project manager how do you balance sort of the the business budgets versus allowing your developers to kind of pick and choose what they want to do I mean as a PM we all want to do great work we want you know we want quality work we want our team to be happy but many times if you're working you know under a fixed price or a budget constraint it's not you know it's for an external client you may not have the luxury of allowing people to pick what they want and do much more than the minimum as a team or as sort of the the developer side of things how do you kind of either explain that or work in that constraint and maybe you could talk a little bit about that I think maybe that goes back to the question that was asked earlier about like if the client has said these 10 things are high priority how do you make sure that those 10 things get done and also recognizing that like this is the process that works for us in our unique situation and it's going to be different for everybody but ultimately anything that you can do to facilitate allowing people to work on the things that are exciting for them is going to help all of us are adults too though so we're going to recognize you know this month I just have to work on the stupid stuff because it needs to get done remembering that you know if I know that you as a project manager are interested in assigning the things that I want to work on to me just knowing that you're going to do that when they come up is really motivating to you because there might not always be things that are interesting or that you know you can assign to me right now but any chance you get to assign something to someone and say I really know that Joe would kick ass at this and have fun with it you know take that opportunity and it improves all of those things it's kind of so maybe like a trimmed down version of it but whatever you can allowing yourself to recognize the things that motivate the people you're working with and feeding that thank you all right I am totally out of time now but thank you guys for coming if you have more questions I'll be down at the Lullabot booth for a bit after this