 Shall we get started? Hi, my name is Matthew Saunders. I work for an agency in Denver, Colorado called Atten Design Group on the Vice President of Project Management there. And feel free to reach out to me on Twitter, Google Plus, or IRC, or whatnot. I'm happy to share and talk and spend time with anybody that is interested in talking about process. I'm also an at-large Drupal Association board member. So if there are issues that you want to reach out to me about in terms of the con or things that the association is engaged in, I'm one of the people that was elected, I guess it's about a year and nine months now. And I'm very, very happy to chat with you about any issues that you might have, any questions that you've got. I'll make sure that my slides are available at some point or another, probably on the DrupalCon website. And so if you want to grab those, you can as well. I've been working with open source professionally since about 1997. And I've been working with Drupal since 2006. Started working with Drupal in version 4.6. Did a very, very short stint in 4.6. Built a bunch of sites in 4.7. And I haven't really looked back since. The company that I work for at Design Group is focused on working with companies that do good in the world. Our core values include a strong desire to affect positive change in the world. To this end, we've been working with companies like Pointer, World Resources International, the World Bank, Stanford University, Results for Development Institute, Knowledge for Health, Human Rights Watch, those kinds of groups. Um, let's see. So what I'm gonna start with is talk a little bit about a book called Outliers by Malcolm Gladwell. Has anybody here read that book? Just one, okay, you're not allowed to answer any questions. It's a great book, really worth reading. It talks about how there are outliers of stats and how those stats sort of fold into systems. And one of the things that he talks about in the book is that a number of commercial flights started crashing in the 90s. And nobody could really figure out why that was happening. There wasn't anything to do with mechanical failures. There wasn't icing happening on the wings. Nobody could figure out what the heck was going on. So I want you to think about that. I want you to keep that in your mind while we go through the presentation because at the end, I'm gonna come back to it and we'll touch on why that's important in terms of project management and how that relates to Agile. So we need project management for successful outcomes. To illustrate that, I put out a call for stories on my blog, on Twitter, on Facebook, and asked people to send me their horror stories, basically. And I got about 40 responses altogether. And they ranged from complaints about support for modules to why the heck isn't there documentation that makes sense on Drupal.org to client stories. And what I grabbed was three gems, three stories from folks that sent me notes about their project management horror stories. So the first is, a couple of months ago, I got a call at 6.30 in the morning. My client was yelling and screaming at me because my site had gone down. I dragged myself out of bed, get to the computer, and his site comes right up. I told him to try to go to Google, and guess what? According to him, Google was down too. So I politely asked him to call his internet provider because that was what was down and once the internet came back up to use it to search for a new developer. So this is sadly pretty common, and it illustrates a lack of empathy between clients and vendors. And it's really important for us really at the very beginning of an engagement with a client to talk to them, set expectations, because in this case, I'm nearly sure that that vendor hadn't set the expectation that he wasn't a 24-7, 365 days a year vendor, right? It was just a single guy trying to do good work and ended up getting pissed off because his client called him early in the morning. We need to be active listeners. Number two, I had a project. It had multiple decision makers and they wouldn't move forward unless they agreed on any one point and they couldn't agree on anything. How many of you have been involved in projects where decisions were made by your client through a committee? It sucks, right? It's terrible. It's the worst possible way that you can engage in a project. So again, right at the beginning, I think what you need to do is set up a situation where the client is really clear. I need one point of contact or two at most, maybe a backup and that person needs to be able to make decisions on behalf of the organization that you're working for at that point. Indecision is crippling and it can cause projects to go way over budget, simply by eating up time in weekly meetings with the client where work isn't actually getting done. The third story. I had a client who didn't know what they wanted. They spent hours in meetings throwing ideas around and then despite warnings that they were consuming all of their contracted hours, they insist that they shouldn't have to pay for the time because the site hadn't been built. How many of you have had that happen? Yeah. So again, this comes back to process. It comes back to setting up schedules, expectations for both client and vendor and it speaks to a lack of planning, communication, process, focus, and differences in culture. And these differences in culture can make for very bad outcomes. Our clients are content experts in their field but they don't necessarily understand things like block, variable, theme, beam, context. All these words means things that are completely different to them. So we have to become translators. We need to have a mutually understood vocabulary. So they understand when you're talking about a beam, you're not talking about a can that you're getting from the grocery store. Project managers are those translators and Agile can help bridge the gap in terms of understanding by breaking projects up into smaller, bite-sized pieces that make sense that are understandable. So what you're looking for is a paradise of concordance. I find it funny actually that there's bird poop on paradise up there. And you desire understanding but you can find yourself trapped in an emotional state when you assume that a client, where rather a client assumes that something is easy or it won't take much time, but that's never true. You can find yourself in a place where you wonder whether you ever get the chance to build something. And you can find yourself in a place where your project is in constant flux, changes the norm and predictability is gone and at that point you panic. Don't panic, you don't need to panic. Our job is to communicate, it's to translate, it's to mediate, it's to unblock. Our job is to bring calm from chaos. And above all, our job is to make everybody else's jobs easier. We are there to simplify the complex and if we're being successful, people might say, why on earth do we have project managers? Don't be fooled by that. We're the cat herder, but not of just developers and themers, but of also product owners, business owners and clients. We keep the communication running, we keep all the ducks in a row and above all else, we have to help our teams avoid shiny things like these birds, they'll fly around and they find a piece of tinsel and they bring it up and then they see, oh, something else. We need to make sure that that doesn't happen to our developers. We want to keep them focused and able to do their job. We need strong communication across our working unit, across the company, with the client. Who here knows why manhole covers are generally round and heavy? Anybody? Manhole covers in the road? So yeah, it can move and fall into the hole right. And they're heavy because, exactly, you can't lift them up. So I like to think of project managers as being manhole covers. We keep people from falling down holes and getting hurt. It behooves us to use clear communication to prevent ourselves or clients or colleagues from falling down into dangerous places. And 90% of what we do is that communication. It's not just communicating out, it's setting up a space and a framework that allows us, our teams, to most effectively communicate with each other. And it's listening. It's listening for underlying messages. It's listening for unspoken messages because often when our clients say something, we may hear something, and what they mean is something completely different. So we listen to the unspoken message. And we're not gonna talk a whole lot about tools in this chat because the tools are just there to help us get to a point where the message, the communication is being facilitated well. If you wanna talk about tools, I'll be doing a buff after this where we can geek out on Jira and stuff like that. So over the last 20 years, I've used three different methodologies, and we're gonna talk about all three of them. And I'll talk a little bit about the lessons that I've learned from each of them and how they sort of all munged into a process that has generally worked well for a bunch of different shops that I've been involved with. First is Cowboy. Cowboy can be extremely unpredictable. Does everybody know what Cowboy is? Raise your hand if you do. Yeah, okay. So basically the idea of Cowboy is that you're iterating incredibly quickly. Your iterations can be like one day. And because of that, it's very fast in terms of development, but it requires that there's a ton of trust that needs to exist between developers and stakeholders. And it can lead to a miscommunication of expectations. It works really well if you're bootstrapping a new product. It also works really well if you've got screwy requirements that you can't get your arms around really, and in situations where you need to build quickly. It's highly informal, and if folks on stakeholders can be used in very unpredictable projects, rather, it's great for prototyping. Strangely enough, this is the methodology that we used at Examiner when I worked at Examiner to get Examiner out the door. Why would we do that with a giant site that ended up having seven million nodes being migrated across multiple media types, 200,000 users in one of the most heavily trafficked sites on the internet? Well, the reason was this. When I was hired, I went into the office and they handed me the requirements. And I kid you not, I had seven binders, like this big, seven binders. And I started going through it, and it was clear to me that nobody on the team prior to the Drupal team coming on had ever looked at Drupal. They were the most undrupally requirements that I'd ever come across. That's okay. I mean, we can build things. We can pretty much build anything that somebody wants. But what I said was I need to go away, and I need to plan this out. So I went away for a couple of weeks, three weeks, something like that, and I Gantt charted the whole thing out because they give me all these requirements. Waterfall was perfect for this, right? And when I got to the, and the Gantt chart was roughly the size of that screen up there was huge. And it was deep and wide, which meant that we needed lots of people over a relatively short period of time to get the job done. So I went into the boardroom and I said, I got great news. I know exactly how we can make this happen. And it's just gonna take us 18 months. And there was silence. Now, keep in mind, nobody had talked to me about timeframe or anything like that really at that point. And somebody spoke up and said, you got nine months. So at that point, the best thing to do was to pick up those requirements and throw them in the trash. And we started building. And every day we would sit down with stakeholders and we would go through what we'd built and we'd talk about it and we'd figure it out. And we got it done in nine months or at least we got the front end of it done in nine months. We were still using cold fusion at the end to do content publishing, but we did get the site out the door in that period of time. It was crazy, it was amazing. But the only way that we could do it was to throw the requirements away and start to iterate quickly. Waterfall sacrifices speed for predictability. It's much slower. And it's not great for companies that have some risk tolerance because typically companies that have tolerance for risk wanna get down to building things quickly. Early in my career, almost every project that I worked on was custom PHP MySQL applications and those were all done using Waterfall because we were planning everything right from the get go. We had to do everything from figure out what the authentication system was gonna be, how we were gonna build that, all the way down to how content was gonna be displayed. So for those kinds of projects like I built a grant making system that was used across the United States, built a adjudication system for artists, to submit artwork, to competitions, that kind of stuff. It was perfect for that kind of project. So who here has worked using Waterfall? Almost everybody, great. Okay, so have any of you ever worked on a project that had a fixed scope and the scope didn't change? Yeah, no hands, right? Right, that's cause Waterfall doesn't exist. It's a pipe dream, it's a myth. So you never can plan for things not changing. Waterfall works great if you're building a dam. It works great if you're designing a car. It's not great for software. Waterfall also often has requirements that are dictated. So remember how I was talking about examiner a few minutes ago? That big set of binders. How creative do you think that would have made our development team feel? Not creative at all, right? And we're all creative people. We wanna build things that are cool and we wanna do it in ways that are fulfilling. And when you just handed a bunch of requirements, you don't feel that way. You feel like you work at a faster food restaurant at that point. And worst of all, no matter how well you've planned something out, scope will shift in the middle of a set of features. In waterfall, there can be a tendency for a client to become impatient and that can lead to missteps. You can develop before you're ready to develop and that creates a munged up methodology that can feel like you're at the edge of a waterfall and about to go down it. So rather than fight change, I came to the conclusion that you need to embrace it. In Agile, it requires that we weave, that we move, that we're flexible. And there's this thought that with Agile that there's no predictability that you're not planning and that's completely not true. But what you are doing is you're setting up a set of expectations within a time box. We'll talk about a time box in just a minute. But the idea is that you set up your expectations in a very distinct period of time and you've got a beginning and an end to that period that's set. Everybody has the same set of expectations. So with Agile, you've got defined time boxes. You work in an iterative manner so you're adding to what you've built the last time box. It's incremental so you're building things that work. They're ready to ship hopefully at the end of each sprint. And it's collaborative. The requirements are collaborative, solutions are collaborative. And it's relatively rapid and flexible and responsive to change. So it's not as crazy as Cowboy but it sure is more flexible than Waterfall. And you organize your own teams. So let's talk about terms. First of all, I've talked about time box. A time box doesn't refer to a ship that can move through space and time although I'm guessing many of us would like to be able to develop software that way. Time boxing is a way to contain risk. So the idea is that you put constraints around a period and then you can better estimate what you're gonna build during that period of time because you're breaking your project up into smaller chunks. So time box defines a period that you can complete a set of tasks. And that includes doing your planning at the beginning, doing your development and also going through user acceptance testing with your client. We'll talk a little bit about acceptance testing in a bit. Sprint, a sprint comprises planning which stories from your backlog. Everybody know what stories are? Does anybody not? Okay, good. So you're planning which stories you're gonna work on from your backlog. And typically what I like to do is have two week periods for developers to be developing. I've found that in two weeks you can build working software that can do things that clients can look at and feel good about and go through a review process on. So you figure out what you can do in that two weeks of development. The other thing that you're doing during your sprint is you're having your developers code and at the end of it you're having your stakeholders test. You're fixing bugs during that period of time. Epic. So an epic is sort of like a really big story. It might be a blog or an article or something like that. It's a set of tasks that are going to arc over perhaps two or more sprints. And we use epics at Atten as a way to generally define a project. So when our sales people are out defining what a contract's gonna look like they use epics to define a set of features. But we also use them when we get into time tracking we'll book our time against epics not against individual tickets. So I've got a good sense as we're going through a project of how long it's taking us to do things specific kinds of things but it's not getting so granular that the development team is going oh my gosh I can't believe that I've gotta put time on every single individual ticket. User stories are a way to define experiences. So you might have something like as an anonymous user I want to log on to the site so I can post to a user forum. Things like that. And what I'll do is I'll start to go through the wireframes that our user UX people have put together and I'll start to put user stories together for each and every element that I think I might want a client to test against. And I write them in such a way that it's really easy for the client to understand what it is that we're gonna build. And it becomes a collaborative effort between the client and myself as we go through and write stories. And it's really common actually by the end of story writing for the client to be writing most of the stories at the very end. They've learned the syntax, they know how to go through it and we'll also make use of those stories. We'll do it with Behat so we can use those for testing at the end as well. So then we also use a thing called Scrum. Scrum is basically a 15 minute meeting every day. I ask, what did you do in the last 24 hours? What are you gonna do today? And what are your blockers? And if there are blockers that need to be dealt with, what we'll do is we'll ask people to find the appropriate individual that can help them unblock those blockers. We don't wanna discuss those during the actual Scrum meeting. Scrum meeting lasts more than 15 minutes, we're doing something wrong. We also engage in client check-ins. I do them at least once a week and this is kind of my Scrum with the client. They can last from anywhere from 15 minutes to an hour but we also allow all of our developers to have access to the client and vice versa. So clients can come in and they can say, hey, I really need to discuss X, Y, Z and we allow for that kind of interaction. So let's talk about roles now that we've talked a little bit about the terms that we engage in Agile. If teams aren't flat, they can make mistakes. So it's really important that everybody's equal, that everybody has a say, that everybody's able to communicate in a safe place. The first individual is a project manager. We use our project managers also as Scrummasters. So they're ones that run the meetings and so forth. They are the ones that lead our estimation process. That includes all of our developers and we use the Fibonacci sequence for our estimating. They act as a defense against distractions. So if, for example, my boss comes in and says, I really need so and so to work on such and such instead of the project that they're working on, I'll say, well, here are the implications. We won't get this done for this client. Is that really what you want us to be doing? And we help the team avoid mistakes and we manage the schedule. So we figure out when the sprints are gonna happen and work with developers to figure out what are gonna be in those sprints. We mix up our product in UX people a little bit. Typically in Scrum, in Agile, you've got a product owner and the product owner owns the backlog. Our product owners are also our user experience people. They act as a communication conduit between business and development groups and they help develop stories as well in advance sprints. They're responsible for the backlog, for personas, epics, and stories. They clarify business needs and they do demonstrations at the end of a sprint. So demonstrations we'll talk about in a little bit, but they're really important to the process. Our developers self-organize stories and they communicate expectations of what can be completed in a sprint and what can't be. So if I try to stuff too much stuff into a sprint, I want them to feel safe to be able to say, Matthew, we can't do all of that in this particular chunk of time. That's really important because, again, you don't want to have missed expectations. And then the developers also define how business needs should be architected and executed. So I'm not gonna tell my development team how to do their job. They're the best able to know the best technologies to make use of in order to get a task completed in the most efficient way. And then it's their job to execute. And because they've been so involved in the process, if they don't execute, then during our retrospective when we're talking at the end, we discuss what went wrong, how can we make this better? So we use, those are roles, and what I want to talk a little bit now is information architecture, user experience, and stories, and how we use those artifacts to set up projects for success. So we do a thing called a content audit at the beginning of every project. So we'll go through and we'll look at an existing site and we'll say, okay, what content's there? Hey, hey, client, what content should we keep? What content are you missing? What content can go away? All that's really important because at some point or another, you're almost certainly gonna be doing a migration. And it's best if you don't bother migrating content that just needs to go away. We'll also build these things called content maps. It's a text way to review what the architecture will look like that's easily consumable by non-technical people. So we'll define what each one of the page types is gonna look like, but we'll write down what's gonna be on that page. And we do it in hierarchy, so the most important stuff in that document is at the top of each of those descriptions. The idea is that these need to be really quick to build and we can throw them away when we're done with them. Then we'll go in and we'll do a site map. We don't do site maps like org charts. What we found is that when you do an org chart style site map, you end up having to define all those little boxes anyway so you end up with a document. So it seemed like a waste of time. So again, we do our site maps as text in Google Docs. We do our wireframes in a piece of software called Aksher, which I'll show a screenshot of in a little bit, but Aksher allows us to build working prototypes where you can click on links and you can go to pages and you can use menus. And it gives the client a real sense of flow through the site prior to ever having to write a line of code. Like I said earlier, we write our user stories collaboratively and then we build a Drupal architecture. So we'd find all the fields, taxonomies, content types, all the view modes, all those kinds of things up front. And then we use a module called sync. You wanna write this down. Sync. What sync allows you to do is have your information and architects use a predefined spreadsheet. And once they defined all of the fields with the client, all we need to do is press a button and all of our content types, vocabularies, they're all built. So within minutes of us getting sign off on the Drupal architecture, I can have a client in a working Drupal site testing, looking at the content types starting to get a sense of whether we've gotten things right or wrong. Sync is great. Design. So our design process is a little bit different than lots of different groups. We don't design each and every page in a site. We'll design just a few key pages. And what we do is we start with a design studio, what we call the design studio. And really what that means is we sit down with the client and we go through a series of sketching exercises. So a big part of that is to start getting our client partner used to collaborating with us. So we're drawing things together, we're working together. And usually our facts that come out of that exercise don't really get used for much, but it definitely starts that mentality that we're gonna be working together. And we expect you to interact. The process that we work in, if we don't have client buy-in and interaction, it just doesn't work. That moves on to our mood boards or element collages. An element collage is an artifact which has what is the header gonna look like? What is the footer gonna look like? What are our button styles? What will a block quote look like? What do our H1s, 2s, 3s, 4s look like? And it deconstructs it from individual pages. And the idea is that ultimately our themeers can use that as a template to look at, to see how things should look. And it also allows the client to do the same thing and reduces the amount of design that we need to do upfront. We'll then go in and we'll do two or three mockups, sometimes four. And from all of that, we're able to define the rest of the site. So once all of that's done, we've gone through information architecture, we've gone through design, then we get into our sprints. So we're gonna assume a 20 day sprint, a four week sprint for this. And I talked earlier about how we do two week development periods. Those overlap, so we'll talk a little bit about that as well. So the breakdown of that is one week of planning and organizing, two weeks of development, and one week of user acceptance. And usually at the beginning of a process with a client, I will sit down and I'll do user acceptance with the clients. I'll go through and I'll say, okay, let's take a look at the first story. Here's the path to success. I'll write down the victory state, I'll go through and I'll indicate exactly how to test with links and so forth. And it makes it super easy for the client at the end to say, yep, that does what we said that it was gonna do. And if you've broken down your stories into small enough chunks, what you'll find is that user acceptance comes very quickly and as people get used to accepting, they accept more and faster. So if you give a client a big page and say, what do you think? You're gonna get stuck on all kinds of tiny little details which really aren't important. They are important, but they're not important in terms of getting a product to ship. So it's really important to get yourself to a place where you can get acceptance on lots of things very quickly. We work in small teams, typically a team lead, a developer, who's also a developer, a back end developer and a front end developer. Sometimes we'll float in another individual, another developer who does things like migrations and so forth, but typically we work in three person teams. And each team works on two projects. So when I talked about planning and UAT, those are slightly down times for our development team and we want them to be actively producing stuff. So if you look up at that slide there, you'll see that for project one, week one is planning, week two is development, week three is development, week four is UAT. The second project that they're working on, they'll be engaged in development on project two in week one. I'll be doing UAT with the client during week two. Then we'll go into project planning week three and then we'll go into development, the first week of development in week four. So for our development team, it becomes sort of this rhythm where they're going back and forth between projects and we're able to keep their development velocity high. We want them to be billing pretty much all of their time and it allows the client enough time that they can breathe, they can help plan and they've got time to do acceptance testing. On the last day of any time box, we'll do a company in a wide demonstration. Demonstration's really important because it allows your entire company to know what's being built. It builds respect across your teams and hopefully at the end of it, everybody knows how to use the products that you've been building or at least who they can talk to. So if somebody picks up the telephone and we get a call from client A, they know which team's been working on that particular project and they in general know how it works. Everybody to feel up to speed on that. Directly after our demonstrations, it's really important to have a retrospective. A retrospective is a meeting where the team gets together, it's in a safe place, it's relatively private and we are brutally honest with each other about what worked, what didn't work and how we can make things better. So our entire agile practice is agile itself. We iterate every single sprint that we engage in and we learn from every single sprint and we make slight tweaks, little tweaks as we're moving along. Team members have their feedback and suggestions heard which is really important. People like to be heard, they like to know that their opinions matter and then project managers are accountable to fix any issues that have come up that we've discussed and that they're being addressed from time box to time box. So everybody keeps everybody honest in this process. Okay, I said that I wasn't gonna talk very much about tools but I'm gonna talk a little bit about them. First of all, does everybody use something like Slack or IRC or Skype or HipChat in your shops? Yeah. And how many of you are virtual companies and how many of you are, let's start with virtual companies, how many of you and how many of you are have bricks and mortar are in a building? Yeah. So I really like channels, log channels because it means that me as a project manager, I can go back and I can see what my team has been talking about, where the problems are. I can scan them. So for example, I'm in mountain time. I'm eight hours off of my team right now but I can go back and take a look at the end of each day. What is it that they've been working on and what were the questions? That's really, really useful. It's terrific. We're using Slack now, when I did this slide originally, we were just using IRC and HipChat mostly. And I like, personally, I like to separate out client communication when they wanna have chats into something like Skype, something completely separate from what the team uses. Again, this goes back to how can I minimize distractions? I also wanna have a tool that I can shut off. So if I need to just be concentrating on my team, I can completely separate those elements out. We use Google Docs a ton. We use them for documentation. We use them for collaboration with our clients. I'll take my ticket queue in Jira and I'll export it into a CSV and pull it into a Google Doc where everybody can work together. In this case, we're using, in this case, this Google Docs is being used to track stories. So you can see that there's a ticket number there, there's the story, there's the description, there's status, there's QA feedback in there, and so forth. And we use color coding to say, okay, this is done, this isn't done, this is, and for red, this is a blocker, this is a problem. We also use Jira for our internal ticketing. How many of you use a ticketing system? Does everybody use a ticketing? Good, all right. How many of you use Jira? Cool. So I've used lots of different ticketing systems. I've used Jira, I've used Chili Project, I've used Track, I've used a ton of them. I think Jira is the best of them, although I don't think anybody really likes their ticketing system that much, but Jira I think is the best of the ones that I've worked with. Yeah, sure, yeah, yeah. And similar to Trello, you can see that we've got swim lanes. We drag cards from swim lane, swim lane, swim lane. What you can see in this particular slide is that we've got our user stories in there, and then I task my developers to self-organize those stories and write their own subtasks. So at any given time, I can look at this Kanban style board, and I can see exactly what the state is of every ticket that's in a given sprint. And you can collapse up the subtasks you've won or you can expand them. There are all sorts of different filters that you can use to effectively just filter by yourself or by other people and so forth. But it's a highly effective way for me to be able to see what's going on. And they go through a general workflow of to do, in progress, internal review, code review, client review, and done. Once tasks are moved to client review, I point our client at base camp. We're actually starting to shift to service desk, which is another Atlassian product. But currently what we do is we have all of our stories in base camp, and then the stories get moved from a draft state into user acceptance when we're ready to go through the user acceptance process. And like I said earlier, I'll write up the path to success for each one of those stories. I list the story and I also put the JIRA ticket number just to make it easy for me to go back and forth. Again, this allows us to break things down into bite-sized chunks. And it makes it super easy for a client to know exactly what we're working on, when we're working on it. And it, again, helps with that collaborative process that we go through. We use Aksher, like I said, for our wire framing. Aksher's quick and interactive. My information architects can build out an Aksher prototype very, very quickly, often in a day or less. And again, because they're so quick, we don't feel bad about throwing them away if there's something wrong. We want all of these artifacts to be pretty much disposable. And then finally we use Harvest to book our time and the big reason for that is that there's a plug-in that you can use in JIRA that allows us to very easily track against Harvest and our accounting folks like Harvest better than some of the other tools that we've used in the past. So Harvest is a great way for people to be able to track their time. So it doesn't really matter what ticketing system you use, but I've done ticketing in Basecamp, Track. I've done it using JIRA, Chilly Project. And like I said, I like JIRA the best. We use, typically use Basecamp for client communication these days. And if you're not using something like GitHub or Bitbucket for version control, you really should be. And then we'll use things like ScreenFlow or Jing for screen captures that we can apply to tickets. And we use Google Hangouts, Join Me, that kind of stuff for client communication. Most recently I started using a tool called, what was it? I can't remember. It's a telephone conferencing system. Oh yeah, it's called Uber Conference. I don't think it's available here. It's probably just available in the United States and Canada. And then again, we use channels that we can log. So we're able to go back and take a look at what people have worked on. So we're gonna go back to the first slide. Just to remind you, a number of commercial flights were crashing in the 90s. And they couldn't figure out what was going on. There wasn't equipment malfunctions. There weren't tornadoes going on. Icing wasn't happening on wings. Nobody could really figure out what was going on. Does anybody have an idea why those flights were falling out of the sky? No? Nope, it wasn't computers. There was nothing going wrong with the planes. The black boxes were clear. Yeah? Mm-hmm, right. It was a process issue, you're absolutely right. So the problem was that communications were being constrained by rules of hierarchy. First officers and engineers didn't feel like they could speak directly to the captain about their concerns. And planes were going down because people who had expertise weren't speaking up. So the strength of an agile process is that you make everything flat. Everybody has their area of expertise. There isn't hierarchy. We keep each other honest. We keep each other doing the jobs that we're supposed to do. It's much easier to identify risks and unblock problems when feedback is built into the entire system via scrums, war rooms, retrospectives. And you wanna set up a culture where you eliminate blame, people can own their mistakes, people ask for feedback, and everybody listens to each other. And if you're able to do all of that, then what you're gonna end up with is a situation where you can deliver working code more quickly. We aren't overburdened by specific requirements, but we focus on business needs that bring value to the clients. And we trust that the scrum teams will deliver those products that meet the needs of our clients. And that will put you in a position where you can get things done faster, better, and more awesome. So thanks very much. I'll take questions if people have questions. And if you could evaluate the session, that'd be great. If you could use the microphone, that'd be great because they're recording this. This question has to do with your sprint timing. Yeah. So we do two-week sprints, but we're never sure whether you have sprints back to back or do you kind of have a week in between sprints so that you can do a proper evaluation after and then plan for the next sprint. So what do you guys do? So that's the reason that we do two projects at a time. We have a week of planning, two weeks of development and a week of user acceptance testing, but they overlap. So while user acceptance is going on and planning is going on on the other project, our developers are developing in the first project. That gives us enough runways, so to speak, to be able to keep them billable and keep them busy, but also gives clients enough time that they can breathe and that they can feel like they've got adequate time to be able to go through the process of planning with us and go through the process of acceptance testing. Does that make it difficult for developers to constantly switch on, switch off from project to project? No, because it's two weeks, right? It's not like it's a day on this project and a day on that project. Two weeks is plenty of enough time to really dig into functionality and deliver something that can be shipped. There are some projects that we work on where we have a higher velocity, like I'm working on a project right now for a largeish reproductive rights organization that we're actually treating them as if they're two different clients. So our development team is actually sprinting constantly on this one project, but we're still sticking to the 20-day sprint schedule and making sure that there's enough time for that particular client to be able to test and be able to plan with us. Thank you. Yep. Hi. I have a question about the product owner role in your projects. Yeah. The product owner, do you use that role? And is it someone from the client side and is he on site? So we mix up, that's one place where our process has sort of gone sideways compared to a lot of Agile shops. Typically our product owner internally is the person who's done the information architecture. And the reason that we do that is because that person has had the most conversation about what the product is gonna look like at the end with the client, but the client also is involved in product ownership. But I don't want the client owning the backlog. I want them to be involved in the backlog, but I want somebody on my team to own the backlog. So that's the reason I use the information architect for that. But the user acceptance test is done by the client. Yeah, well, so the user acceptance tests are based on the user stories that we've written at the beginning. So if we're able to reach a victory state on a user story and the client can test it, then we know that we've completed that particular set of tasks. And what I'll typically do is I'll put the steps to get to the victory state on the ticket that's been assigned to the client with that user story. So they've been involved in helping write them at the beginning. They know what the requirements have been that we've collaboratively developed and then they've get steps in order to complete that testing. Okay, thank you. Yeah. I'm curious about some tweaks to the schedule of involving hot fixing and rapid development if you've got a one month sprint schedule and they're not happy with what they got once it goes live, how's that handled? Sure, so once a product at Atten goes live, we shift teams actually. So I manage project teams and we also have what's called consulting and they are teams that are specifically involved in helping maintain a product after it's shipped. And so those teams are incredibly agile like to the nth degree and typically their engagements are anywhere from 12 to 50 hours a month with a given client and they're engaged in taking care of things like hot fixes and stuff like that. Hello. Hi. Have you also experienced Kanban instead of Scrum? Yeah, I use Kanban and I like it. I just like Scrum better. Yeah, I like the whole business of connecting with the team once a day. And we use a Kanban style board like a lot of agile shops do. But yeah, I've used Kanban in the past. Okay, thanks. Yeah. Any other questions? All right. I'm gonna be doing a, if people wanna talk about tools a little bit more deeply, I'll be doing a birds of a feather after this session. I'm not sure what room it's in but it's on the Boff schedule board. And anybody that wants to sit and talk more, I'd love it. Thank you.