 All right, I think we're gonna get started My name is Matthew Saunders and We work for examiner calm and today we're gonna talk about project management using hybrid agile development So if you're not here for that Any yeah, yeah All right, so if you have any questions that you'd like to tweet with the hashtag We're going to use pound decon dem PM If you wanted to include either one of us either one of our tweeter Twitter accounts, that'd be great too. That'd be fine So if if any of you want to join us in terms of Tweeting directly at us you can we'll also use this this hashtag that we've got up on the screen So I'll just leave that for a second If you want to write it down Okay, so my name is Matthew Saunders. I'm the director of technology at examiner calm And I'm the director of project management. It's pretty self-explanatory Examiner is a giant Drupal site. So for those of you that aren't familiar with it When we launched it in Drupal we we launched with roughly nine million nodes and There are anywhere between two thousand and three thousand new articles that are published each day and then there are associated Associated media files along with those articles that can bring it up to ten twelve thousand new nodes that are created each day That includes photos videos slideshows all all sorts of things like that We use a hybrid approach of my SQL and MongoDB Which is unusual in the in the Drupal world? And the reason I'm bringing this up will make more sense when I get to our migration and The approach that we took when we migrated from cold fusion to to Drupal We Have multiple web heads load balancer redundant failover slaves databases the whole nine yards It's a it's a pretty big affair My role at Examiners largely as a cat herder as is Stacy's and we act as a bridge between product and development for the most part So who are we? I Worked originally in technical theater. I was a lighting designer and a lighting technician I also worked as a as a as a freelance artist for a number of years that's what I did my undergraduate work in and That's segwayed into working in nonprofit management technology and so forth and ultimately into grant-making Worked in the book business. I've worked in the web worked in a wine store. I've taught university that kind of stuff and I grew up in Silicon Valley Mountain View my dad was an engineer my mother was a just had frightening superpower type PGM project management skills, so I Learned a lot from her. I moved to LA after university and started in film and television writer and producer for top 10 ranked television shows But I moved to San Francisco and got into web producing and writing Instructional design in the training space and at fortune fortune 500 companies where I also picked up a lot of organizational management and operation skills and experience And then I moved to Colorado Tried it all out in it startups this time So along the way, I've been trained in group facilitation and have a PMP So I've been working in Drupal since 4.6. I started In in the web roughly 15 years ago Originally with a company called the Western States Arts Federation, which is actually local to Denver And I was building custom PHP minus QL applications for that for that company along the way, I found Drupal through through a series of happy accidents and And that segued into my working with a company called Ping vision for two and a half years where I was involved in building And migrating oh somewhere in the neighborhood of 40 or 50 or 60 sites. I'm not quite sure how many it was a lot but that included a number of pretty significant migrations that That became sort of a basis for the for the work that I'm doing now I also work for a company called vintage digital LLC, which I started with a number of other web developers we've got a number of small to medium-sized clients and the most recent was My work with examiner comm now with examiner. I was hired to come all come on and and Help with the migration from cold fusion to Drupal 7 it was a giant job and It was it occurred over oh all told it took probably about 12 months But we'll get into how that phased we phased through that a little bit in a little bit future in the presentation However, the interesting thing about it was that Drupal 7 was barely out ahead at the time And that meant that we were building from basically the the the bare bones of what to what Drupal 7 is now and in fact our team Was responsible for somewhere in the neighborhood of 18% of Drupal core in 7 Matthew and I have been working Together since paying visions. Oh the last three four years and again together at examiner I've been project managing throughout my career at places like Disney Sony and Pdi ninth house It's been a great ride at Drupal. All right So if you have any interest in getting in touch with us right quickly because I'm not going to stay on this slide for very long But the long and short is that it's perfectly fine to get in touch with either one of us. We're friendly We don't bite at least not very much so I sort of think of myself as a Drupal cuckoo and the reason that I feel that way is that Despite the fact that I've been in the web industry now for 15 16 years that's not where my my roots are my roots as I'd mentioned before was in technical theater and What what occurred and during that that period of time is happenstance encounters meeting folks in Vancouver becoming more and more interested in Drupal and Finally finding my way to a place where I was looking at this community and going okay You guys talk in this thing called IRC What is this and and I found myself not quite fitting in but The sweet thing was that I found that the skills that I had from Working in the theater as a stage manager as a lighting designer all those Organizational things that I needed to learn in order to do that job. Well release segwayed amazingly well into into into software development So in 2007 I was a little bit like a little cuckoo's egg that had been dropped into a into the nest of a bunch of Drupal birds and When I popped out People sort of looked at me and went okay. Well, we'll see what you have to offer now I'll tell you this one of the things that occurred was that I found that this community was unbelievably warm and friendly and and and was more than happy to take me under their proverbial wing and Help me learn what it meant to be part of the community and since that since then I've got to say that the community has been something that has nourished me both personally and professionally since then So I would encourage you all that as you see new people come into the community, please embrace them welcome them Take joy in their differences because those differences are things that are going to make us all much much much stronger All right, so why do we do what we do? so you might find this familiar if you're into science fiction at all and To me, this is the emotional state that you find yourself when a client is throwing fits Because they know that there's this contrived module. That's just right Or they know that that something is easy or at least they assume it is they assume that it won't make that it Won't take much time But we all know that that's never true It's the place where you really wonder whether you're ever going to get to build something whether the talking will stop It's the place that you find yourself when the sand is moving under your feet because the scope is changing constantly And you really don't know how to how to get yourself back into a into a strong Fundamental place where you can build the site that you've been asked to build It's when you realize that the project state is in constant flux Flux and changes the norm and all your predictability Has a has evaporated and to me that's sort of this HP Lovecraft place of the call of Drathulu So really our job is to communicate. It's to translate. It's to mediate our job is to unblock and Our job is to take calm and turn it that rather take chaos and turn it into calm Yeah, it's really to make everyone else's job easier and to simplify the complex if we're being successful There are times when things will appear to be running smoothly, you know on their own and it's like what why do we need project managers? But don't be fooled. We're actually like peddling madly behind the scenes So we're the cat herders But what we've discovered over the over the last number of years is that you know There's this assumption that we heard the developer cats and the theme or cats, but it's much more than that We also are the the the herders of the product owners the business owners clients, etc So our job is to continue keeping the communication running keeping those ducks in a row and above all else we have to keep people from seeing that shiny thing that makes them go pull and Those things are the things that are going to distract you during your during your sprint So I'd like to ask folks how many of you in the middle of a coding sprint have had a client or a boss come up Do you say just this one little thing, please? It can't take that long really come on Show a hands. How many of you? All right, so There's this notion that adding this one little thing might make the site so much better and The lack of discipline of say of not being able to say you know what let's wait until we're finished This particular sprint is something that's gonna is gonna Cause all sorts of grief for you So all of this requires strong communication across your your company the working unit with your client So I've got another question. How many of you know why manhole covers are round and really heavy You right there oh and Andy last He says that's because because that's who won the bid. No, that's incorrect You right there in the back Middle glasses short hair right exactly and that's our job as well we need to be round and Heavy and keep people from falling down the hole Yeah, 90% of project management is about communication so not just communicating out but setting up the space and framework that allows the team to most effectively communicate with each other and it's also about really listening listening for any underlying or unspoken message or trend that's That's brewing So what we're gonna do now is we're gonna talk a little bit about the three different Methodologies that examiners gone through over the last two and a half years that let us started leading as to where we are now And the main reason that we're gonna talk about him is because they they they've influenced how we've how we've adopted an agile methodology We've learned from each one of them and and how they can inform Our own method because at the end of the day what what I believe is that there is not no there is no thing that is pure agile There's no thing that's pure waterfall They're all blended sort of gray areas so the first phase of our development methodologies was cowboy now the reason for that is that when I was brought on board in 2009 I was handed a a Stack of requirements yate yate tall and I was told this is what we want you to build So I said, okay I need you to leave me alone for a month because I need to get through all of these documents And I'm gonna get chart this thing out from the beginning to the end so I so we know what resources we need We know when we need them. We know how long it's gonna take At the end of it. I said hey, I've got great news This is an 18 month project and we know exactly what we need and when we need it And I was told 18 months No, no, no, no, no, you have seven months at which point I sort of Blanched and I said well, there's only one way I know how to do this because these requirements aren't droopily These requirements are highly cold fusion a and they and we're gonna be fighting against the the software We're gonna be fighting against what the platform does naturally if we if we follow these requirements So what we really need to do is take a look at the goals Of the requirements and then you need to allow the the development team to go into rapid iterations where we where we bang through things as quickly as possible and You know the the back end might not look how you expected it because in the old system It was all custom custom cold fusion So we were using as much as much of what Drupal would give us out of the box as humanly possible So this is a highly informal kind of process it focuses on the stakeholders It can be very unpredictable, but it can be excellent for for rapid prototyping But it also means that that There is a whole lot of Unpredictability for the stakeholders and that's tough for them to take at times. So We got through our Our initial phase and we launched the front end of the system and I think it was a eight months So we were off by about a month, but for a project as big as migrating From the examiner calm from from cold fusion to Drupal 7 when Drupal 7 wasn't even in alpha That was a pretty good. That was a pretty good effort so the pendulum swung The business wasn't so so happy with the idea of Of the unpredictability and we went right back into sort of a waterfall kind of kind of place And that gave a whole lot of predictability But the challenge with that was that we weren't being as nimble as the business wanted So we were we were in a constant a constant tension between getting things done quick or Being able to plan things out from from from the beginning to the end And and run things through in a in a waterfall kind of fashion and given the fact that examiner tends to be a somewhat somewhat tolerant of risk kind of company It it made it kind of kind of rough on everybody. So we were constantly getting requests for new things all the time The nice thing about waterfall though is that it is highly formalized. It focuses on requirements It's a little inflexible which is unfortunate But all your planning is front loaded Now I'm gonna ask you who here has worked in a waterfall methodology All right Another show of hands how many of you have had zero scope scope creep in a in a waterfall project Nobody. Oh, come on All right So I would maintain that waterfall in its purest state simply doesn't exist There will always be change requests and the change requests might happen even before your requirements are completed So given the fact that Drupal is always in a state of state of flux. You always have new community code that's being released Things are changing Constantly it seems to me that waterfall isn't necessarily the right methodology to use in a Drupal project because you may well find Yourself in a place where a new module is released. That's good quality code That does 80% of what you what you need to have done and that could cut your scope Or you might find yourself having problems that you didn't that you didn't anticipate or Even worse you might find yourself in a position where a client is asking for for for significant scope change Right. And so the munch methodology really felt a bit like that Can everybody see what those pictures are Yeah So we found ourselves in a place where we decided look we have to we have to be more agile and Being agile requires that we weave that we move that were flexible but it also requires that there's a Uncertain amount of predictability within a certain within a single time box as to what your deliverables are So you're planning you really are planning in a way up front what it is that you're gonna do and you do have quite a bit of Predictability during that period of time but it's a little bit different than when you're dealing with when you're dealing with a a Waterfall kind of project so we went into defined time boxes. We went into iterative development methods It's incremental We started working in a collaborative way the the development team was was active is active in Helping to find how we're gonna solve a problem So we're given a but business problem and we solve we take our own Our own methodologies and we apply those methodologies to solving that that problem We also have been Moved into self-organizing teams and we're trying to be as rapid and flexible and responsive to change as possible Now as we get into more of the details on this particular Methodology that we've moved into because it is hybrid. There is a certain level of inflexibility Within the time box and we'll talk a little bit about that as well so Our approach that we've come up with To recap what we've discussed so far Our phase one was cowboy fast cause problems with expectation gaps between the business and the team It was volatile not much predictability Then we moved into phase two an attempt at waterfall slow change was inevitable often in the middle of the project and Requirements often fought with what Drupal does naturally lots of dictating occurred to the Development team which made it tough on us because we we felt like we had a often had a good solution to a problem and Being dictated to how we would solve that problem often made the problem that much more difficult to to complete our developers really became order takers and knocked active Participants and their creativity was was suppressed quite a bit and it didn't make for a happy situation So then our third phase which we're now going to talk about is the hybrid agile approach that we that we have taken And this is going to be the focus of the rest of the talk Now I'll say that we're not going to talk about about the very very very very detailed pieces of this methodology But we'll we'll touch on pretty much everything that we've come to at this point Our current unit is comprised of product creative QA and development and you'll see we have a number in each area Release management and infrastructure as well. The team is both local and distributed. We have our main You on campus in Colorado, and we have people in Massachusetts, Canada, Great Britain, Hungary We've had the great fortune to work with an exceptionally talented group of people But before you know we go into identifying what each of the roles and responsibilities were I just want to talk a bit about what the team's mentality was Before we made this big paradigm shift and what it took to pull together and establish and have people accept a new methodology This is You may have seen this slide before but really I think it captures kind of how fractured We were you can imagine after the months of stress of these two conflicting approaches There was not a lot of traction. There was a lack of trust of frustration among the departments This was not a high-functioning team though as I said very talented One of our product managers likes to say this slide is particularly significant because their products not even represented there, so Some of us were steeped in agile from previous work Others of us just had no exposure whatsoever or very you know committed to waterfalls. So this was very hard to kind of You know Get a kind of uniform thinking around this buy-in What we needed was breathing room and breathing room is Really what's needed to change a fast-paced kind of high-pressure Organization that's producing a lot and that's just what our executive team allowed us They were very eager to implement But gave us the permission to jump off the hamster wheel for a minute and just strategize some improvements This is an image from a film called Fitz corraldo And it's about a guy who hires a crew to move a boat across miles of mountainous jungle terrain and and to me this is an app metaphor Why our task was difficult, you know to execute a full-scale site redesign in a very short amount of time that also It also significantly affected our architecture But also the making of the film was about as challenging as the fictional characters experience from what I understand and Filmmaking always is and I think it's an interesting study. How does a disparate group of eccentric? professionals Accomplish challenging intricate work with very little sleep and in as little as six weeks without tearing each other's heads off and I'd say first and foremost They're unified behind a singular goal, you know make a film move the boat and we had a single goal To stand behind together, which was to redesign the site all other projects would and could be deferred And we were given clarity and purpose and the green light to do it in the best way possible And you know normally you don't get that but I think it was really necessary to make a big kind of process shift And when I say us I mean the whole team was involved in setting up the new process Everyone was required to give input and to bring their expertise to the table from the get-go really it was Any team-based paradigm shift really only works when it has contribution and buy-in and ownership for the new process And as project managers our job was to set the framework and then allow the team to help organically build Upon that framework to support its own needs every team There's no two teams that are alike and projects no two projects that are exactly alike And so really we had to find what was exactly right for us As a project manager moving from waterfall to an agile-based process a key paradigm shift is going from a directive style of leadership to that of really primarily facilitation and Direction is still necessary But you really have to become ambidextrous and know when to make that shift and when to apply Each style I happen to serve as a group facilitator at juvenile hall in Los Angeles in an earlier life And actually I think that's one of the experiences that's helped me the most in in working in the corporate world Ironically above all else One really key point that I learned in that process was that when you have a key to conflict management and group problem solving is to You know the tendency is to try to ignore or clamp down on conflicts just to press them and hope they go away But that actually what you need to do is the opposite you have to steer into the problem any kind of inkling of dissatisfaction Or complaint or cynicism you got to address it head-on Not dictatorially, but inquisitively. What what's the concern? Why do others share it? How do we resolve it? And the catch to all of this was that of course while we were collaborating on process changes and having our kind of group discussions We were already on the clock for delivering an enormous project Many of the process improvements had to be done while rushing down this river of an a really aggressive timeline In the book Outliers, I don't know if you've heard of it with it's Malcolm Gladwell And he points out that you know back in the 90s a number of commercial flights were crashing at a sort of alarming rate and it wasn't because of equipment malfunctions or severe environmental conditions, but it's actually due to communications and What they found was that because of the rules of social hierarchy, you know pointing to culture some cultural I actually think you know, maybe the military Pilot culture also affected that First officers and engineers were not at ease to speak directly to their captain about their concerns and so, you know, they were saying things like Gee the radar is a very kind of convenient tool. Isn't it captain? I mean just way too subtle and instead of saying look we're about to crash. Come on, you know, lift the nose up so Plains were actually going down for this reason that that people with expertise Didn't feel they could advise they weren't speaking up and they couldn't be heard I actually think that's a pretty good metaphor for What we do when we when we execute on very complex complex projects and we're going at pretty intense speeds A strength of the agile methodology is that while we all have our areas of expertise It's not a hierarchical hierarchical system and frequent feedback is really built in there's scrums you know, we had a war room that we used for that project and retrospectives and but beyond that we took extra steps to Work to clear communications and really improve them in our new paradigm We worked really hard to eliminate a blame culture to take ownership of mistakes, you know And you can do this by example, but just but just by you know facilitating Asking for feedback frequently and of course listening So this is kind of what we arrived at We Have our project management team Who act as scrum masters they leave it lead on pointing pointing stories and basically moved into a story methodology rather than a strict requirement methodology So we would figure out how long we felt in number of story points How long a certain task would take a big part of our job is to protect the the development team from distracting distractions during the coding phase And it's to ensure that the team doesn't doesn't make mistakes for example saying things like oh that should be easy Or I think that that'll be quick We want to avoid that that kind of language because if that does definitely stick into stakeholders brains and you're stuck with that with that Perception and Finally it was our rock our job to manage the schedule Product owns the backlog so all of the all the features that we've been told are important to the company They work on the personas the epics in the stories that that are Are being used for a given time box the answer questions clarified business needs and at the end of the time box They're responsible responsible for demoing the the software at the end of the sprint Then the developers are self organizing and and work on the selected stories So in collaboration with the with the management team we'd figure out who would do what But then it was up. It was up to the developers to figure out Within their own little group who what when why and not why but how? and and it was also for our Responsibility to decide what can or can't be completed during a during a time box and where where there's context switching where there's change We're empowered to say look these are the things that that are going to fall out of the current time box because we just don't have the time for it any longer and Probably most importantly as the development team is the team that defines the implementation of the business needs and then Executes on those on the on that implementation So we've broken the examiner time box up into a sort of a thing that I call 2040 60 The notion is that right now? We're Rather right now the product and the creative team are working on writing stories for the next for the next time box So during that 20-day period they're highly active in in figuring out What it is that the personas want out of a given feature? Days through three through 12 our story creation wireframes days 13 through 18 are meetings comp Spinal delivery of epics and stories and then on day 19 of the time box. We lock the time box down at least we try to And the idea of that is that we've got some predictability for the next 20 days During the same period of time the exact same period of time the developers And the QA department are executing on what was in the last 20 days the stories in the last 20 days So we basically go into two days of technical planning 10 days of intense coding code sprinting Six days of testing and reworking and then we go into deployment and then at the end of it all there's a Drupal day Which allows the development team to? Take what they've worked on Genericize it commit it back or work on any other project that they might want to work on The idea though is that that it needs to be part of part of the actual Drupal project And then finally at the end we have a retrospective and that retrospective is critical We sit down in a safe environment and we talk about what worked and what didn't work during the time box And then we iterate on the process itself And that's critical to making sure that that you don't fall into a rut And we're very very open and honest as a team about what does work and doesn't work during that period of time And we've also recently added to our Process a rapid deployment process, which we'll talk about in just a little bit But the the key to this is that the three things overlap we have we have the Executive team figuring out what it is that they'd like to see in the next in the next to 60 days We have the the product team who are writing the these personas stories Etc for the next time box and we have the actual development for the current time box going on right now and they overlap So it ends up looking a little bit like this right On the last of the time box. We also have we have what a company wide demonstration I know some people stick to just their development or production team But for us the company wide demo really works and the reasons are that The entirety company gets to know what's been developed and you know, it sounds simple But it's like another communication thing, you know, what's what's just been done It builds respect and it also helps everyone know how to use the products and Who to ask about them if they don't know how to or they have further questions? again directly afterwards we do the retrospective meeting and Not only does it allow really open feedback and communication about what worked and what didn't but it holds the project managers accountable for Fixing problems from time box to time box because otherwise the same points come up and it's a bit embarrassing when You know, nothing's been done about the thing that's been brought up several times a Little bit about the rapid deploy team now we had Feedback that you know once a month for releases was tough for a company Web development company that needs to have some quicker turnaround and you want to be able to see more frequent releases so What we did was in the last time box implemented a rapid deploy track a Specific task force to develop test and release smaller projects quicker turnaround projects And this team would work on a quick sprint paradigm Attacking a prioritized list that could change depending on the last minute needs of the company and the product lead would actually manage that list How did it go? Well, we hit some bumps The resources from the rest of the time box were pulled off of other projects to work on the rapid deploy team kind of defeating the purpose of You know developing to delineated tracks, but you know, that's what the retrospective is for we're in the middle of This time box and we will you know make improvements for the next cycle and and and this is the great thing about About these cycles is that you can make iterative improvements and have that breathing room to look at those problems So you do use the notion of scrum we do daily scrums and we break our Currently we basically have three feature teams and the scrums are broken into into three general questions What did you do in the last 24 hours? What are you doing today? And what are your blockers? We also have bug triage scrums once a week or so to take a look at what bugs have come up during the during the previous time boxes and Try to make sure that they're scheduled into into our rapid deploy team work as well So we've got a toolbox and In that toolbox we make use of IRC and Skype for for our communication IRC is logged using more of us ifs bot just like it is in a lot of our other IRC channels So we can go back to any one of our any one of our logged logged Conversations and go back and look at what was said This is particularly important in our case because we have a distributed team that pretty much is working 18 hours of the day because of the the different places that these folks are working in at one point it was as disparate as The United States all the way to to to Japan So it really became critical that that people be able to go back and see what was being talked about We also use Skype for for voice calls and for screen sharing when we when we need to do screen sharing We are a heavy user of Google Docs. What you see here is a picture of what a what our User story document looks like basically it's broken into story ID priority where it lives the story itself Notes on it feedback a comp whether a comp is available You know is needed or not the timing Ticket number level of effort leave dev leave the theme or QA resource product resource, etc The reason that you see colors here is because we identify Whether whether whether a Story is being worked on By putting it yellow if it's completed by putting it green and if it's pink or salmon as we call it There are questions that need to be answered about that particular story This is proven to be a very helpful living document to us and and each time box we create a new one which Comprises all of the user stories for each of the tracks that we're working on We also use a bunch of other tools for example we use track currently for for our ticketing We are trying to move right now to Jira with Greenhopper Which we feel is going to help us in our in our in our overall reporting We use version control using get deployments are done through Scripts that are controlled by Jenkins We do screen shares and screen screen captures using tools like jing and skitch and screen flow We use Google for managing user stories as I'd mentioned and Drupal for logging our IRC channels So by adopting a more agile process what we found ourselves being able to do is Deliver working code more quickly. We aren't overburdened by specific Requirements any longer but focus on business needs and and focus on the notion that the business trusts us to Build things the way that they ought to be In a in a in a way that the software platform most readily will will allow us to work scrums teams deliver Product that fits the needs of the business and for us It's taken over two years at this point to get to this point and we continue to shape the process each and every time Box by focusing on those lessons that we've learned But ever it seems like each time box things get to get more solid Based on the feedback that we get from our team One quick thing about the colors. We do have some team members were color-blind So we made a little bit of a mistake with the red yellow or the yellow green So just put put some thought into that. Well, that's the reason that they're so bright So folks like me that have trouble seeing colors actually can see them The other thing I should say is that the reason it's for us It's hybrid is that we don't do all our story Building on the first two planning days on the planning days, you know, there is that 20 days out So the product team can work with Business to really flesh out all of that in advance What have we built using our methodology among many other projects many other small ones? We've at that site redesign was successful. We actually Ended up releasing always six weeks ahead of time the largest Drupal mobile site in existence currently as Spearheaded by Richard Burford over here We did we release that in January a complex behaviorally based rewards program for our 70,000 examiners is is Soon to be released next week And I would just say that our team which has always been very talented is now just a really high performing team is a lot of camaraderie and just a a lot of understanding the miscommunications that we had in the past just don't happen in the same way So I would say that we're faster better and more awesome All right, so what we'd like to do is open up the floor to questions All right, looking at your guys's process I noticed you're starting with the user stories moving into development and then finishing off with testing Had you guys tried a test-driven approach where you write the test prior to it to avoid rework to fix changes So there are two sort of different ways that tests are dealt with in our team the first is Tests they're written by the developers themselves test their their own code And there are roughly roughly 2,300 of those tests now that run On our on our on our testing environment each evening automatically so we know if things have broken Existing functionality From a standpoint of the tests the the the browser-based tests Those are generally written after the user stories are Developed however, I think that one of the one of the imperatives that we found that we need to move into is having those Those particular browser-based tests written at the same time as the stories So it's something that we're working on right now As a suggestion our company uses selenium to do that and we're very familiar with that very helpful Cool. Thanks. I would also say that we we do as soon as the code is written and pushed to staging it And the QA team can get to it. They'll get to it It's not just isolated by that time box if that's part of your question Hi, I'm Shannon from Blue Spark Labs, and I had a question about how you are Explaining your process to clients especially in a world of fixed bid where so many clients just don't Understand the idea of we're gonna pull things into time boxing and sprinting and we'll get through what we can using this kind of agile Hybrid methodology and I'm wondering how you Explain that to them in a way that they can understand and accept and not feel insecure about like they're gonna get screwed over My clients are the executive are the executive team of examiner comm we don't have We don't have exterior clients. So the examiner site is a is a giant Giant Journalist kind of site citizen journalist kind of site that that is The revenue model is actually advertising. So it's a little bit different than than being an agency land I Will say though that that took a certain amount of socializing to you know to get to the point where you know time box, huh, you know, it's interesting because You know, we were we actually found it to be one of the big selling points was that Once we got a handle on our burn rate. It was pretty easy to say, you know very Likely probably good 95% you're gonna get X amount of done by this date. It was much more predictable for them so the executives actually really appreciate that That structure now that the vernacular has become more comfortable But I will say that in previous lives where I've worked in in in an agency That's a huge challenge for sure. It's it's tough and You know, there's a variety of different levels of Appetite for that ranging from people who really get it to those that want to fix bid I get it It's tough Hi, I'm Vitaly with very corp Have a question about have you ever faced situation when you had to do replace team member during sprint or time box? And if so, do you have any standard workflow to approach this situation? For replacing a developer for example, yeah Yeah, we've had a number of situations where a team member has had to leave for one reason or another in the middle of a Time box It's tough and I actually think that the biggest part of it for us is Identifying that risk to our executive team when the risk occurs because really what that means is during that period of time our burn rate has reduced and It means that things that we've thought that we're going to be able to get done. We we haven't been able to complete So basically it extends the scope for next sprint or you need to move Yeah, and we actually build in some, you know for risk management a certain number of points toward you know Unpredictability and that's included Hi, I noticed on your team Lay out there. You have four themers and nine developers. I'm just wondering how you distinguish between themers and developers They seem very similar to me Yeah, they are they are similar That said that in terms of our particular team our themers a good chunk of them are Highly trained also in design but that said Our our site isn't like a lot of Drupal sites. It's it's very complex in the back end and And we're running crazy queries against MongoDB, which isn't a standard database for for for Drupal So our back-end developers almost almost almost never touched the theme our front-end developers are focused heavily on the theme and our light Into the into the back-end kind of kind of work But it's the difference between back-end work and theme layer work Hi, I'm Justin from the street It's really interesting because you guys have a really similar model to what we do at the street We separate development teams are you know truly agile. I'm interested in what you guys call your rapid deploy team because we Do something similar and I'm wondering if if you guys are collecting stories for that group the same way you're doing it for all Your projects through Google Docs or versus like a Kanban style, you know something a little more quicker Yeah, we don't really use Kanban, but we do collect our stories in a very very similar way for for Our regular projects sometimes those stories will be written in the middle of a time box though And it's interesting you should mention that one of our product managers would is is working toward Building out a Kanban board just because I think it's really conducive to the rapid deploy Yeah, since you mentioned it I couldn't recommend more the green hopper plug-in for JIRA. It's probably the best thing out there Yeah, we're looking forward to that Two questions the first one probably really simple why triple seven why take that risk was it unstable? What was so important? I'm just curious Because we're nuts No, we a good chunk of our of our development team core developers and There was a desire to have as long a leg if you will for the for the product once it was Once it was delivered and then add on top of that the performant issues that that we knew that we were going to have to overcome Because of the size of the site the amount of traffic that came to the site It became clear that we needed to use Or or desired not necessarily needed but desired to use a database that was going to be more performant than my SQL And and it was it was obvious at the time that even in its Infancy triple seven was going to handle that a whole lot better than Drupal 6 All right, and second thing is how involved are the developers or how much do they know what's coming in the next time box? Pretty involved when they finish there when they finish their their development during the sprint they're actually sitting down with with product and project managers and reviewing Reviewing the stories for the next for the next time box. I will say that's a challenge because when the developers are in their coding phase We don't we want them to be uninterrupted. So what we will do is pull You know Matthew as the technology director. He will Cover that portion But we'll try to pull the development leads on a project as quickly as early as possible to get them involved Hi, John Reynolds, Martha Stewart living. I've got a question about how you turn user stories into technical tasks Point of friction we often have is the user story will be get way too many technical tasks And we start to wonder is it more than one user story and I noticed on your on your spreadsheet You actually had a ticket number column Suggesting that you had one ticket I presume a track ticket per user story for us I don't know. We usually blend up with possibly a dozen technical tasks mapped to a user story I was wondering how you manage that so the ticket number that you saw is a ticket number for a parent ticket and and that parent ticket then becomes the umbrella for a bunch of technical tasks and you're absolutely right we have the very same challenges of of trying to of trying to Match user stories to technical tasks that said What we found is that for for our product team to be able to express what it is that they want a Persona to be able to do or experience Using the user stories is has made that much much clearer and and more efficient for us Yeah, definitely a challenge, you know, they're different needs the user stories has a different Use for each different group in particular QA needs a sort of more broken down user story almost, you know My new show whereas the developers, you know They have a better experience and they can be freer to develop and be creative when they have a more general user story So we're experimenting with that from time box to pint time box It depends on the project as well with the rewards project that was so intricate and there was just really Specific infrastructure that had to be late in place. We had some you know, 200 user stories for for that and you know people weren't Developers weren't happy. We'll move back to swing back on the other end of the pendulum Thank you All right, I think we've got time for maybe two more questions than everybody's gonna want to run to the plenary, right? Currently in my agency, we you know, we have our war room We have our scrum board and we have a fairly large distributed team Is there any tools that you would recommend for the distributed team to use as a scrum board? Wow So we're moving to one of the reasons that we're moving to Jira with Greenhopper is because it has an integrated scrum board into it Greenhopper does and allows you to define your workflows specifically to your to your groups needs and You can drag your your Scrum tickets from one one portion of the board to the next portion of the board to to move through the through the Through that process. I've also used a product called tingle Which is which is another agile scrum tool that specifically it's not a ticketing tool so much as a as a scrum board tool And it works pretty well as well But you're with Greenhopper. I think is they is for us at least is going to be the answer to that Yeah Tom Ho project manager at madex media. My question is I think a number of the audience here works for agencies or as a freelancer What are the most important skill sets you'll As a project manager working for that environment versus for like Examiner calm where your client is the executive team. What do you think the difference in terms of skill sets are for project management and What are the you know the same things? I actually think that there isn't that much of a difference in terms of the skill sets One of the things that that you need to be aware of between working in an agency and and working for for a company like say Examiner or something like that is that When you're doing your your budgeting The budgeting is going to be a little bit different for example If a project when you're when you're taking a look at but you're the budgeting of your time, you're not assessing You're not assessing an hourly rate to the budgeting of the time You know that you've got x number of hours per time box That you can use for theming and for development and for infrastructure stuff and so forth And because you're not billing directly against that it changes that paradigm a little bit But they did the core skill set. I think it's pretty much identical All right. Thanks so much everybody for coming to our presentation