 Well, hello everybody. I think I'm going to get started. It's one o'clock. We might have other people that wander in but Figure we can try to keep this keep this on time My name is Matthew Saunders. I am the CTO of Trellin Trellin LLC. It's a Drupal shop based in the United States largely, although it's a distributed team across Ukraine the United States and Australia It's a recent role for me. I've been there only about three months Prior to that, I've worked for three different three different development shops Ranging from from shops that did custom PHP my SQL applications to to Drupal shops if you would like to tweet anything my my Twitter handle is at Creech if you'd like to ask questions That's that you know, I might be able to answer later on that'd be great or if you want to follow me That's terrific, too so I want to talk a little bit about who I am to begin with and And sort of how I came to came to project management And I think that's important because like a lot of people in the Drupal community It wasn't such a straightforward path. I was originally in technical theater. I was a lighting designer and I worked as a as a stage manager a number of things like that for for quite a few years And it's funny because I had the last time I did this presentation I had three people who came to me afterwards and said, you know, that's really weird. I worked in technical theater as well so there seems to be some kind of some kind of Pre predisposed disposition for people who do that kind of work to do this kind of work I've worked in nonprofit management. I worked For a company called Westaf the Western States Arts Federation in Denver for eight years doing technology work for them And also managing grant programs I marketed for a for a dance company. I worked in a bookstore wine store taught University So, you know, there's a whole gambit of things that that I engaged in before I found my found my way to technology So Westaf was the first first first sort of technology company that I that I worked for we did custom PHP My SQL applications there. It was a distributed team of Developers and that actually has ended up being a threat across all of the all of the work that I've done in the past At Westaf near the end of my tenure there I ended up I ended up going to Vancouver for a number of seminars that had to do with Drupal and I started drinking the Kool-Aid at that point I'll talk about that in just a moment After I completed sort of that tenure of work, I ended up working for a company called Ping Vision for a couple of years where I built With a great group of developers a ton of Drupal sites that somewhere in the neighborhood of 70 or 80 all together and that really Really ended up being a really great foundation for the work that I ended up doing at examiner later on When I finished at Ping Vision a group of us formed a Consulting company called Vintage Digital LLC and that company Currently isn't really taking new new clients, but it sort of hovers along and keeps keeps moving along as well and then there was This giant site that people might have heard of examiner.com that that I was asked to shepherd the the the process of moving the site from from cold fusion to Drupal 7 and move the database from Microsoft SQL to my SQL and MongoDB MongoDB is they ended up being the database of record But my SQL continued to do things like bootstrap Drupal most recently I was brought on to Trellin as I had mentioned and Sort of this this track goes all the way back to Drupal 4.6 So I've seen a number of changes to to the to the platform Over the over the years Although a lot of it has stayed exactly the same at least from a UI standpoint If you want to contact me on a variety of different ways, I'm Matthew S on d.o. You can find me an IRC Twitter so forth So I'm a cuckoo. That's the way I like to to describe myself. I worked in the nonprofit industry for for eight years ended up Finding my way to Drupal happenstance encountered as I'd mentioned while in Vancouver and The reason I'm bringing this up is because I want to encourage everybody to to think about when you see new people coming into the community How many here are new to the new to Drupal? Okay, awesome, and have have you felt like the community has been welcoming to you that that people have been have been friendly and and have tried to to to make you you know feel like you're part of part of the overall group That's awesome. So when you're in a year or in six months or whatnot when you when you aren't noobs anymore And you see new people coming in give them the same the same kind of experience That's exactly what happened to me and it it transformed my my my opinion of the of the of the platform Because back in four point six. It was really pretty rough. It was it was you know, it was There were there were things like CCK had just come into existence views didn't exist yet There were a number of things that that that made it a harder platform to work But the community was what really hooked me and kept me going Something that is important also when you're and we're gonna talk about communication in a little bit but When we're working with our clients, it's it's common for us to forget that we communicate in a very different way We're community communicating through technologies like Skype and IRC And to our clients. These are really foreign. They're really odd It's it's not a normal way of of communicating and in that kind of thing can lead to can lead to all kinds of stress that that you need to watch out for so You might find this familiar You might find yourself in an emotional state with a client Where the client is read a little bit and they're starting to throw out Drupal modules that you know really aren't that good But they're insisting that maybe this is the route that you should take when you're when you're planning out a project and it's a place where you where you find that the client is assuming that something is easy and It won't take much time, but you know that that's not true It's a place where you wonder where You're actually going to finish a job or even start the job start the building of that job And it's a place where you've realized suddenly that the project is constantly in flux Requirements are changing constantly Changes the norm predictability is evaporated and it feels like like the project sand under your feet Everybody had that experience. Yeah so You kind of face this monster, and I don't know whether any of you have read the HB Lovecraft, but There's a there's a creature called Cthulhu. If you look in its face you go insane Sometimes that's how that's sometimes so that's that's how a project management can feel But our job is to communicate it's to translate it's to mediate it's to unblock and Our job to a large extent is to take that chaos turn it into calm It's to make everybody else's job easier and it's to make things that are complex simple We break things down into small bite-sized chunks so they can be executed upon and if we're really successful There there'll be times when things look like they're running incredibly smoothly and people on the team might say Why do we need project managers and? At that point we have to make sure that we're not fooled by that that that calm Because we're the cat herders and we don't just herd developers and themers We also herd stakeholders product owners business owners and clients We have to keep communication running we have to keep our ducks in a row and above all else We have to keep our developers from being distracted from shiny things our Clients from being distracted from shiny things. We need to keep people on track So how many of you show show of hands? How many of you have been in the middle of a coding sprint and you've been asked to add one tiny little thing and the the the the reasoning behind it is it's going to make the the website so much better and You know you get the you get the the the the statement it can't take that long right? How many of you've heard sort of the five lethal words? How hard that how hard can it be? Show of hands. Yeah So to keep all of this under control requires strong communication And it's not just strong communication across your team. It's strong communication With with your clients and with everybody who might be peripheral to your team Does anybody here know why manhole covers are really heavy and round? Right, but why are they round? Why aren't they square or rectangular or not a lot? Right, it can't fall into the hole And they're heavy because it means that it can't it's it's hard for it to lift We do we we are the manhole covers we keep people from falling down holes down rabbit holes and getting hurt And our job is to prevent Ourselves our clients our colleagues from from from making making mistakes that that cost money and time So I want everybody to keep in mind that project management is 90% communication And it's setting up a framework Where your team can effectively communicate with one another and it's listening It's listening for underlying messages and it's listening listening for the unspoken message One of the things that will happen often is a client will Fundamentally not know what you're talking about and you'll assume. Oh, they haven't objected. They haven't asked questions They must they must know what it is and they must be agreeing with the with the direction that we're taking Only to find three four weeks later that that you've gone down a a Precipitous horrible path that has wasted everybody's time and and the client's money So you need to be an active listener. You need to be actively asking questions and making sure verifying that the client Actually understands what it is that you're offering So I'm going to talk about three soft software Project management methodologies the reason I'm going to talk about three of them is that I've used them in my career over the last 15 years with varying degrees of success and all of those Fed into an experience that I had with examiner, which is where most of my remarks are going to are going to end up being structured around That informed a process that we developed together there So the first is cowboy cowboy can be extremely unpredictable, but it's fast it requires a great deal of of trust to exist between developers and stakeholders and It can easily lead to miscommunication of expectations It's highly informal. It focuses on stakeholders It can be used to like I said in unpredictable projects and it's excellent for rapid prototyping So when I came to examiner in December of 2009, I was handed Requirements that were like this and I was told we need you to go through the requirements and Give us a sense of how long this project is going to take Clearly from the requirements not a single person that had been writing them had ever Used Drupal let alone let alone ever written requirements for for Drupal So I proceeded to break it down into bite-sized chunks and I can't charted the entire thing out and What I found was that we're looking at about an 18 month cycle Which you know when you're talking about a migration of a site that large and not just a migration But also redesign and so forth is actually pretty reasonable It was a migration that would become save 7 million nodes across 15 different content types 200,000 users that were active that needed to be that needed to be moved over a bunch of stuff like that So I went back to the executive committee and I said okay, so here's the plan I've got it all out here and it's on a giant piece of paper and we can talk through it And what I was told was oh, no, no, you don't understand. We've got seven to nine months to get this done And I just sort of went oh All right. Well, there's only one way. I know how to do this then With the time period that we've got we got to throw all these requirements away We've got to talk about your basic business business needs and then you've got a trust that me and the team that we're going to Give you what you need But not necessarily what you expected Fortunately the the executive team was open to that and we went into a period of time of Rapidly iterating sometimes the iterations were as short as half a day So we'd write code and then we turn around and sit down with the product manager and say does this look right? And we would do that over and over and over again And in fact certain portions of the design weren't completed until we literally were on the last day of development Prior to to launching the site in situations like that cowboy can be quite effective But the challenge is that it it puts it puts these stakeholders in a place where they feel really out of control And they are they at that point they have very little control in how the project moves forward So what that meant was at the end of that seven to nine months? They were like we need predictability and So we moved into more of a waterfall kind of methodology at that point and what that means You're sacrificing speed for predictability. It was much much slower. Everything was having to be defined up front and Again, we were in a situation where the project management team was teaching the product team how to write requirements for for Drupal because They were simply weren't used to that And that ended up not being so successful and the reason was that the the Executive team had gotten used to things happening really really fast How many folks here have worked with waterfall with the waterfall methodology? Yeah, most of you. That's cool and How many of you in another show of hands? How many of you have actually had a waterfall project? Where the scope didn't change? Ken, that's that's impressive I So I would I would I would maintain that waterfall in its purest state. It doesn't exist Except for Ken because he's hard-ass And and the reason that I say that is that you're always gonna have a situation where the client comes back Once there's once they start seeing what it is that you're building and they say whoa, that's not quite right Which means that you're really you're really engaged in in Already engaged in in a hybrid more agile kind of process Now some people may disagree with me and I know that there are lots of shops that have had had a lot of success Working in a waterfall methodology But I tend to think that it doesn't work that well for Drupal projects and that's because of community code You can find yourself in a position where somebody is released to set of modules that do very much what you need it for the client and You install them and they work great and suddenly you're managing to compress your timeline Likewise you can install a group of modules that you think that you're gonna use and then find something is conflicting And then you got to go through a whole series debugging to figure out why it's not working the way that you expected to work Which which can then extend your your your your timeline? The other thing about Waterfall is that sometimes it depends on the the situation that you're in but it can often make devs feel like they're not inclusive in the in the in the process and The more that dev that your developers feel like they're included in the process the more engaged they are and the more They will they will own The you know those portions the project and you're gonna end up having people who are far more willing to Take the extra steps go the extra mile do the extra hours if need be in order to get a project project completed You can get into a situation where developers feel like they're order takers rather than rather than Creative members of the team and that's that's a pitfall that you don't want to fall into You get people who are disengaged You don't get nearly as good good a product at the end when that happens So this is an experience that we had at examiner you felt like Maybe things were going fairly well in Waterfall But then because of changes in the middle of the project and the desire for the for for the client to have Have things being displayed quickly so they had things to look at you suddenly feel like you're on a on a jet plane That's out of control I Certainly felt a Good portion of the time that it was planned, but hurry up plan, but hurry up plan, but hurry up and I I don't think that that works all that well so then we get into agile and Agile requires that we weave that we move that were flexible and that there's Predictability in a single in a single time box as to what the deliverables are Agile doesn't mean the client can suddenly say at any time Oh, no, that's not right. I want to I want to do something else. What it means is that you're defining Short sprints and you're saying in this period of time. This is what we're going to accomplish You have defined time boxes You work in iterative development methods that means that as you build things as you as you prototype things You'll you'll you'll rapidly iterate on those prototypes Depending on what the feedback is that you get from the client And in some cases you may actually throw a chunk of code out entirely because it doesn't fit their fit their needs It's incremental and it tends to be collaborative and this is where developers really get engaged and and really end up Becoming invested in a project Within Multiple time boxes it puts you in a place where you can be rapid and flexible and responsive to change And I think the last point is almost the most important that when you're in an agile environment your teams are self-organizing The developers sit down they say oh, I want to do this and another developer says oh, I want to do this piece And you take a look at your time box and eventually you figure out who's who's going to do what? with the project management team ensuring that nobody is Taking on too much or too little so To recap that chunk cowboy fast can cause problems with expectation gaps between business and team can be volatile Waterfall slow changes inevitable which makes makes for rough situations sometimes Requirements often fight what Drupal does naturally if you don't have folks who know Drupal writing the requirements Developers become order takers not active participants So phase three of this is I'm going to talk about Agile hybrid approach that that we ended up developing at examiner This is going to be pretty high-level. I'm not going to get into nitty nitty gritty details But folks are welcome to talk to me about the details after the after the presentation if you'd like so I Like this slide It is how one group sees another group and What I found across four different four different companies is when you get into the situation Where where team members are fractured? They're not they're not communicating. Well They don't feel invested You get factions a group so you've got developers who see designers is as babies and a bunch of a bunch of paint and you've got Developers you've got developers who see designers is rather designers who see developers as being big babies and you know the whole the whole nine yards You don't want that to happen you want the team to be cohesive and without When you get into this situation, there's no traction. You don't have any traction any longer There's a lack of trust and there's frustration amongst folks across different departments and that can actually ooze out into into Your clients your clients vision of who you are as well It makes for not high-functioning teams So one of the things that we needed to do was we needed to develop a process that would work for everybody across the team and What this really means is that you have to have everybody involved in making the decisions of how you're going to operate? Everybody needs to have input and everybody needs to have buy-in because you've got one bad apple It kind of makes the the whole house of cards fall apart everybody has expertise and And they can bring that expertise to the to the table from the bet from the get-go And that's really important So in the book outliers by Malcolm glad Malcolm Gladwell He talks about how in the 90s a number of commercial flights quite a few more than average started crashing There was no there was no reason from a technical standpoint why this was happening There was no reason from an environmental standpoint. They weren't flying into hurricanes or anything like that So as it was being being Investigated as to what was going on it turned out that Communications were constrained by the rules of social hierarchy First officers and engineers weren't talking to the captain because they because they they had the expectation that they weren't supposed to talk to the captain They didn't feel at ease to speak directly to them and talk about concerns So planes were going down because people with expertise who could advise weren't advising they weren't speaking up They weren't being heard One of the strengths of agile is that it is flat Everybody's equal everybody. Everybody has a say When you're working in agile anybody who's on the team is allowed to write user stories based on based on the on the business requirements Everybody everybody is is supposed to be listened to So It's really critical that you start creating an environment where everybody feels comfortable offering suggestions and This puts us in a place where it's much easier to identify risks and then unblock problems It's really important to have communication Via scrums so every morning having a 15 minute stand-up where you just go through go through Each project really quickly that you're working on no more than 15 minutes is really important And then retrospectives and demos at the end of the sprints are often overlooked But I think are critical to the process You want to have a culture that eliminates blame where people can own mistakes and That they are asking for feedback and That they feel like they're being listened to and That when they have and and and when when other people are speaking that they're being listened to as well So I'm going to talk about four different roles That that we had there The first was the project management team In our case these guys acted as scrum masters They lead it and they let in in pointing out projects and pointing out projects Just means figuring out how long something is going to take how difficult it is They were responsible for protecting the dev team from distractions during coding sprints as we get into the timeline We'll talk a little bit about that as well And they inch their their job was to ensure the team didn't make mistakes It's really common for developers to have the most rosy picture of how long it's going to take for for for a given chunk of functionality to be completed and You need to you need to have in your head a sort of factor. This developer consistently Takes 20% longer than than than they think that they're going to take in a few cases You you'll have developers who actually work faster than they then than they expect but you need to start thinking about you know, how long is this actually going to take and and Protecting your team from making commitments that they can't follow through on And then finally the project management team managed schedule Yeah, so in in agile Rather than talking about hours or days You're talking about story points So you're identifying how tough something's going to be and a point a point is a weird thing It can it can talk about difficulty, but it also can talk about time at the same time And there are lots of really great books on on how to point how to point user stories For for agile, but yeah, that's that's what I'm talking about So then the the second group were the product team now the product team Owns the backlog backlog is a long list of features that ultimately you're going to build And they would write the personas epics and stories a persona is basically Who it is that's going to use the site and how they're going to use it and what their perceptions are going to be of the site epics are like sort of overreaching stories and then stories are you know one sentence as a site visitor I want to I Want to be able to register for a newsletter that would be a simple story We don't want the product people trying to write requirements Because they're not very good at it, but they are very good at identifying what the business needs are So then the other thing the product team needs to do is clarify business needs So if the story doesn't make any sense the project the project team needs to work with the Product team to make sure that they get to a place where it does make sense And then finally the product team should be demoing the software at the end of sprint Developers self-organize the selected stories in a given sprint They figure out who's going to do what when they're going to do it They decide what can and can't fit into a given time box So if you empower your development team to say you know what we can finish this amount of stuff But not this amount of stuff You you you're typically going to find yourself in a place where they meet those expectations consistently Then they define the implementation of those business needs So you don't have a situation where you've got folks outside the development team who are trying to tell the development team how to design the software You're looking at business needs and trusting the development team are going to implement on those business needs Effectively and then finally they execute so I'm going to talk now a bit about a 20-day sprint. That's a four-week sprint You can easily break this into a two-week sprint. I've done both They both have different advantages and different shortcomings, but for the for the sake of this this presentation I'm going to talk about a four-week sprint A four-week sprint isn't just the developers writing code. I like to talk about a 60-40-20 ratio 60 days out I want for the business to be thinking about what it is that they want to have built in the future I want them to be thinking of you know in general what direction the ship is going to be going in and and communicating with the product team as to how When they'd like to see in general these these features get to developed 40 days out you've got your product team who are writing stories creating the artifacts like wireframes and and comps to support those stories and And getting the project team and the development team to a greater and lesser extent being involved in asking questions and and so forth so you get a nice long backlog of user stories that are completed with artifacts and then the most the the current 20 days is where we're actually engaged in the in the sprint the coding of What it is that we're building So the product creative timeline looks a little bit like this Those first two days that are green are planning days those are devoted to the development team and Basically during those two days the product team has to be involved in helping helping Clarify any last questions that the development team has had in the previous sprint having to do with this set of functionality That's being built after those first two days the team goes into into Days three through twelve Where where where the product folks are engaged in writing the stories for the next for the next sprint and Taking care of developing or the artifacts comps Wireframes and and so forth And then when you look at days 13 through 18 those are meetings finalizing comps Delivery of the epics and the stories and then on day 19 they have to lock down the time box They have to say okay. This is what we're doing next time round You don't want once the lockdown occurs you don't want there to be shift You want the current the time box that you're currently in to be fixed So you've got predictability for everybody across the team and then on the last day there It's demo and retrospective and the product team would demo the current software that's just been built So then you've got the development team the first two days. They're they're asking questions. They're clarifying They're they're putting together their technical architectures They're making sure that they're talking amongst themselves to incur to ensure that they're they're engaged in the most efficient way of Developing that chunk of functionality whether it's custom code or contributed modules or a combination of the two After the the first two days and their days three through twelve are our head down to the ground They're coding and during that period of time the project management team is is is acting as defense they're making sure that the that the Developers aren't getting you know tapped on the shoulder and questions are being asked of them by the You know by other other folks on the team Because those kinds of distractions are really expensive You don't want your developers during that period of time to be engaged in context switching You want them to be thinking only about what they should be doing during that sprint these thirteen through eighteen is the time that that the functionality that they've built is Being debug tested etc And it's also the time where they have a chance to talk to the Product team and the project management team about the next sprint. What are the stories that are coming coming up? And and you know, this doesn't make sense to me and and so on And then on day 19 deployment and then day 20 demo and retrospective It's really important that to you know to to understand that these three sets of sprints are overlapping So you've got the business that are thinking about what they want in the future. You've got the Product team who are who are and the designers etc. Who are thinking about what's going to happen next and you've got the development team Who are doing what's happening now? So that it ends up looking a little bit like this Wherever things overlapping Yeah Typically typically the each of the teams from two developers one-themer project manager And in a QA person So fairly small teams Yeah, this this was for a four-week sprint. Yeah They're very occupied because they're looking at the at the stories for the next for the next sprint and they're and they're fixing bugs as the QA team identifies bugs But one of the things that that I found was that when you can get developers into a cycle where they're doing slightly different things over periods of time they stay fresh And they stay engaged if you have them doing nothing but coding all the time They they they start to lose their edge. So it's it's a good way of keeping keeping things sort of mixed up. Yeah Absolutely, absolutely peer review is is critical. Yeah Okay, so one of the things that we did was we we then took all of these deadlines that you see in here and the project management team would Assign these in Google Google Google Calendar to each of the people that had that had deliverables So they would automatically start getting pinged a day before, you know, this is what this is what you've got do tomorrow and and the idea behind that was to make sure that The artifacts the stories the epics The comps the wireframes all of these things are getting done when they need to get done Yeah well the self-organized team are looking at at the the current stories and Deciding the developers are deciding who's going to do what and when in terms of producing your producing your your your user stories to begin with and and Producing the wireframes and comps and so forth They the product team and the design team have to work together in in terms of that and identify who's going to do what and the project management team They're their responsibility at that point is to make sure that all of that's being scheduled correctly But you may have one designer who says oh, I want to do this piece of the of the next of the next sprint That's that's also, you know, you end up having having fairly self self-organized teams there as well Yeah So that brings us to demos and retrospectives If you if you start using an agile methodology, don't let don't let the the Higher ups in the company tell you that demos and retrospectives aren't valuable I Think that one of the things that you that you'll find with a demo is that it helps everybody know But everybody else was working on and in the future that pays dividends because somebody may have worked on a chunk of functionality that applies to another project to another client in the future And because the demos occurred it gets sort of into the into the culture and the ethos of the entire company That's to the kinds of things that have been worked on It also means that everybody knows what the status is of a given given project at a given time So there's sort of check-ins across the company It builds respect because people like to show what they've done. They like to be proud of what they've worked on and It lets folks know who to ask questions of and who to go to In terms of learning how to use a given chunk of the product if need be Directly after a demo, it's a really good idea to have a retrospective Traditionally, these are called post mortems. I hate that word Because people aren't dying So I like to call them retrospectives where you look back at your at your time box and you talk about what worked and what didn't work and It needs to be a safe environment where everybody feels like they can they can discuss what worked and what didn't work But at that point you can then iterate your process and improve your process So so each each sprint each time box becomes better and better and better and smoother and smoother and smoother During the the retrospective also, it's it's a The project management team is held accountable for any problems that had been Discussed in the previous sprint if they haven't been addressed in the current sprint So that gives you a sense of sort of the timing across the sprint If you take this down to a daily level It's important to have daily scrums and that's literally 15 minutes You get up talk about what you did in the last 24 hours. What are you going to do in the next 24 hours? And what are your blockers? Once you've identified what the blockers are you don't want the team talking about them in that meeting You want them to break off into into into groups of people that can solve those problems Outside of the outside of the scrum. You want it to be fast And then over so tools I'm going to talk about tools for a few minutes It's really important that you not Get yourself into a position where you believe that the tools are what? Define your process you want to have a strong process in place to begin with and then have the tools support that process All the companies that I've worked for have been highly distributed Even the ones that were bricks and mortar were highly highly distributed or they acted as if they were highly distributed For you know a variety of different reasons as a as a culture Drupal operates in IRC a great deal even bricks and mortar companies the team members will be communicating in IRC and you know it would be really great for you to Talk to your system administrator if if you haven't already to get more of us if spot module Installed so it's logging the IRC channel that you're that you're working within To a Drupal instance so you can go back and you can take a look at the Communications that have been going on one of the things that I do every day and have for Six years is I'll do a rapid scan of the previous day's logs to see what people were talking about to see whether there were any Any issues that need to be addressed that folks aren't bringing up. It's just a really good practice And then of course Skype for for for communication via voice in my current job we're starting to use Google Hangouts a whole lot and They're they're they're great One of the reasons that they're so powerful is that it's not just video chat. You also have an IRC style chat Sort of on the left hand side and you can screen share in ways that you can't do in groups in Skype So you might want to check out Hangouts if you haven't it's pretty pretty great communication tool Also Google Docs are really handy. So what you see here is a is a list of user stories The user stories that are green are ones that have been completed the user stories that are yellow are ones that are currently being worked on and The the areas that are pink are identifying where questions have emerged From from the team questions that need to be answered Across this Google Doc, you'll see that there's story ID priority Where where the artifacts live for that for this particular for this particular story the actual story itself Any notes that are there? Feedbacks of feedback links to comps timing of when it's going to occur Ticket numbers level of effort who the who the lead dev theme or QA product person is going to be This was a really effective way when we were using track track is you know in terms of ticketing Well, we we we migrated the team from track to Jira with Greenhopper Which is another which is another ticket management system Greenhopper makes it great for for doing agile projects And we actually got rid of the Google Docs entirely because we were able to do the same thing natively within within Jira with Greenhopper but still this is a good way of managing managing the the Stories within a given sprint single place you can see what these stories are you can put in your questions So other tools that that sort of sit in the in the in the toolbox I've talked about track a little bit some kind of repository you want to make sure that you're using a repository github is great We use skitch pretty heavily because we're a Drupal shot a rather a Mac shop skitches so you can do screenshots and They can be assigned to tickets and so forth. So you've got visual representations of what you're looking at our dev ops folks were using Jenkins for for doing deployments basically Jenkins is a is a Rapper around scripts so you can script all of your different dev ops types of things and then use Jenkins to to To run those scripts in a predictable way different Google Google documents We use Drupal for for logging our IRC channels yin for for doing video on Problems that you might be seeing same with screen flow and then Jira as well Started using Google Hangouts. Like I said join me as well, which is another good a good screen sharing piece of software, it's free And and again the IRC channels what happened for us is that we went from being fractured and being infective To being a highly cohesive group that was getting work done much faster much more efficiently with a higher degree of quality when we moved out of out of Working in a in a waterfall methodology Into a more agile Methodology and it put us in a place where we weren't overburdened by specific requirements that we knew what the general general needs were of the business and then those general needs were interpreted by the development team And and then executed it by the development team in that in that fashion I think that That it put to put that team in a place where we were delivering what what the business needed Not necessarily what they expected, but what they needed And it also allowed us to rapidly iterate on on pieces of functionality so That's the end of my presentation my remarks. We've got a few minutes for questions folks have questions Yeah But go ahead and use the microphone. I think the microphone is yeah Is it on okay? Yeah, the test cases weren't being put into Jenkins, but the but the Simple tests were being written So there's test test driven test driven Development that was going on so the tests were being written before the before the Code was actually be being written, but at the same time the QA team were we're developing test cases for for Testing the the the UI and the UX After the fact and also putting together Regression tests for the for the entire for the entire Site so each so each development cycle each sprint a full regression could be done of the site prior to pushing the next set of Code to production Some of it was manual some was using selenium So it was a variety of different different kinds of Efforts that were being taken on that so you know there was there were written test cases The the simple tests that have been written and then selenium selenium tests that have been developed as well Mm-hmm sure Yeah, yeah for sure in in in our case the the QA team Were not developers They were individuals who? Had experience in in writing test cases, but not Necessarily necessarily reviewing code and because there's heavy peer review going on through the whole process It was you know that that level of QA was being done by the development team themselves One more and then we'll go into oh paired programming is great if you got if you've if you've got the The time for it a because it takes a little bit longer be when you're working with junior developers It's fabulous. It's a great experience to have a senior developer working directly with a with a with a more junior developer I Think the I think the the challenge is really if you're if you're in a very very tight Time time crunch sometimes it's easier for for a for a developer to simply take on the task And then hand off their code to for peer review after the fact, but I I'm a fan of Paired programming. I think it's good. Sure. So if you're dealing if you're dealing with banking You don't want to be doing agile like you you don't you want to Because you don't want scope creep in that in that instance at all you want you want all of your requirements up front because You make one mistake You're you're you're you're up the creek So if you're talking about you know something like that, I I wouldn't recommend using agile I would go right back to a to a to a a waterfall a waterfall process and I would be doing a heck of a lot of of Prototyping and paper prototyping to begin with so they know exactly what it is that they're getting and you get sign off at every single step, but yeah, I wouldn't I wouldn't You know anything that's dealing with with money like that Yeah Sure, sure. Yeah, you can you can use two senior guys together as well In paired programming and that works really well If you're talking about having them having them sort of bounce ideas off of one another. Yeah, yes, sir Yeah, sure. So the question was I made a made a statement that that Certain members of business aren't great at writing requirements who should be writing in the requirements So I I would break this up into different Kinds of requirements when you're talking about the business needs the business requirements absolutely having some kind of of of Narrative that explains what it is that the that the business is looking for should be written by The product team in conjunction with the with the with leadership of the company What I'm talking about is is when you get to a point where where you're talking about how to actually Execute on those needs so you have your your business requirements to begin with and then the product then the product team takes those business requirements and writes their their their user stories based on what leadership has indicated that that they want leadership signs off on those on those user stories and epics and at that point It's handed off to the development team who look at the user stories and they're the ones that do the technical the technical requirements based on the user stories That's what I was talking about Mm-hmm. The business can say it needs to support a thousand concurrent users But the business can't say this is how we want you to do it. Does that make sense? Yeah, yes, sir. Sure. So the question is can this work on multiple projects? With smaller teams. Yeah, it's a little rougher. It's a little harder The the trick is to is to try as much as possible to encapsulate those those individual small teams on on single projects So you're not trying to have competing interests Engaged with one another across projects. That's actually one of the things that we're working on at Trelin right now to figure out how best to implement this kind of process and and understanding that we may have anywhere from from 10 to 12 projects that are current currently running at various levels of Completion it can be done Certainly have have been successful in in other shops in the past But it's a little tougher for sure. Yeah, absolutely. How do we what? Oh, how the question is how do we sell agile to clients? So there are a couple of ways that it can be done There are a number of high-profile shops that do just that they sell sprints. They don't sell Requirements, they don't you know, they'll look at requirements and they'll say we think it'll take about this amount of time but then they sell sprints so they say you've got two weeks and You've got two developers and a themeer and a project manager and You will help you identify what we're going to do in each of those sprints and then they sell those sprints and When the client says, you know, we're done and then then they're done When you're talking about fixed bid projects We the way the way that I approach it is I don't talk about agile I don't talk about sprints They don't get it Often They're looking for for specific results. We may act in a sprint fashion. We may behave as a team in a sprint fashion and And and and what we'll end up doing is saying to the client. We need you to take part in 15 minute daily daily conversations To to clarify Issues as needed. We need you to take part at the end of to each two week period in a in a in a review of the Of the of the work that we've done So you approach it in a different way You don't you don't end up talking about agile and scrum and sprints and and and so on because I think it's a foreign concept To a lot of a lot of clients who just want their website bill. Yes, sir sure the question is one of the slides talked about how cowboy can can Damage relationships with with stakeholders. So the whole notion of cowboy is that you are You're you're working in a small team That doesn't have any set requirements that have a vague idea of what it is that you're building and then you go and you rapidly iterate right and If you've got a tight team that are all on the same are all on the same page And they're doing prototyping that works really well But if you've got stakeholders who are outside of that tight little team who are perhaps Maybe a Client or if it's a company that you're working within that have their own website that you're working on you can miss expectations Completely because they're they're they're separated from the process And you know cowboy requires you to be highly engaged in the process all the time and Once you start missing missing those expectations it damages it damages trust Dammit, and that'll ultimately damage those relationships and once you lose trust Yeah, you know you're sunk The question is have I ever seen that happen? Absolutely 100% I've seen I've seen trust get destroyed and and Teams deep teams become dysfunctional because of of those mystic expectations. Yes Any other questions? Yeah, sure Yep, sure so the the the question is In instances where unpredictability of people's lives like getting the flu Disrupt a sprint how do you adjust for that? So in Google Docs, I agree with you It's a lot harder to to shuffle things around if you're using a tool like like Jira with Greenhopper you can pull you can pull tasks out of out of a given sprint and move them into the next sprint and And it'll automatically Readjust your your your velocity the whole notion of velocity is that there's a certain speed at which you can complete Complete tasks and it goes back to the points And if you've got fewer if you've got fewer user points available to the team during a given sprint Unexpectedly then your velocity is slowing down significantly Using Google Docs, I mean what what we would do is we'd gray out We would gray out on the on the dock Any stories that we had decided we weren't going to address at this time and then it would end up in another tab and they Would the the product team would literally copy and paste those those those grayed out Stories to the next to the next sprint Yeah, yeah There was a gentleman back there actually sure so the the question the question was One year after the demo and the end user starts playing with the with the product How do you deal with with change requests bugs, etc. Zack is that to accurate? so there are two ways that that We've addressed that the first is that change requests get put into the backlog and are and are prioritized by the by the leadership team In whatever sprint they decide they they want those those those changes to be put in place for bugs during the Qa period in the in the next in the next in the next sprint provided Provided it isn't a critical bug It's addressed during those those days that were yellow on that on that slide if it's critical Then then then we may be in a position where we're saying okay We have to we have to pull this resource off for this amount of time To complete to complete these tasks. That was disruptive when we first started doing it But we we ended up building a rapid response team So there were each each each sprint there would be one or two individuals who would be Devoted to bug fixes and so forth And that that actually ended up working really really well for us All right, I think that we've run out of time If people want to chat with me Feel feel free to feel free to grab me in the hallway or or whatnot. I'm I'm I'm friendly and if if If you wouldn't mind making sure that you put feedback that be be fabulous. I'd appreciate it and my slides are are up on the up on the The page that had the description of the session At this point I believe and my contact information is in there So feel free to feel free to reach out happy to chat with you Thanks everybody