 on dribble.org, you can find me at texel.com. I maintain CRM Core, I maintain a couple of other modules. I really believe that people who run technology companies should know something about technology, which is what makes me cool. And then I'm also the father of two kids and I have a dog. Do you wanna introduce yourself? Yes. Hi everyone, I'm Blake Maples. I'm an account executive here at Trellon. I switched over from the music industry and have been working in sales and I'm the proud godfather of a wonderful kitten and a lazy millennial as I read. Thanks Blake. I'm Jake Tuman, I'm a project manager here at Trellon. I'm from San Diego originally. You can find me at JW Tuman on Twitter, IRC and Drupal.org and I'm excited to say this is my third DrupalCon. Very cool. Together the three of us today are gonna talk a little bit about agile development techniques. We're gonna talk about this from the perspective of being a company that is trying to implement agile processes. I would love to just see a show of hands here. Who works for a web development firm? Maybe not an agency, but some group looking to implement agile. Can I see a show of hands? Okay, I think that's about 40% of the room by a quick count. I think you're gonna find that we have some very practical techniques and some very practical approaches to talk about here today. The very first thing we're gonna talk about really is implementing agile. What goes into that? Why people think about it? But we're gonna look at it in terms of some of the challenges that exist. Secondly, we're gonna talk about where to start. I think every long road starts with a first step and we're gonna make some suggestions about where to consider putting that first foot. Third, we're gonna talk about how agile fits into our sales process. We have vertically integrated into everything that we do. And so we'll show off some of the techniques that we use in order to get agile going even before a project starts. Next, we'll talk a little bit about from the design perspective. That's really where I'll jump in. And just try and illustrate how agile happens, okay? Because for a lot of folks, they have trouble visualizing like where to start having conversations about user stories and things. And so we'll lay some of that out and hopefully, you know, lend some clarity. And then finally, we're gonna talk about it from the development phase, okay? When does agile come into what we're doing? How do we do sprints? And how do we stick with our scrums? But first to roll it all back, let's talk a little bit about implementing agile, okay? Implementing agile within an organization. Trellan is our company. It's, you know, 10 years old. We've been involved in the community since, you know, God knows when. And over the last 10 years, we've had a lot of time to try and perfect our project management processes. It's really been over the last three years that we've been making a strong push to move towards agile. We have an existing development process that's been in place forever. It is effective, you know, in answering some of the common challenges that we have. But at the same time, getting to the point where stakeholders, outsider organization, developers, designers are all on the same page. It has really been like the holy grail for us. Having an efficient and convenient way to move between different phases of projects where people are really bought in and excited about what they're doing. You know, I think is what every development process should be structured like. So we had to look at agile. We had to really think to ourselves, you know, what are the things that we're looking to accomplish here? We find that it helps to start with some definitions. But there's a lot of words to learn. Some of the, I guess, common terms that come up very often are listed here. What we found is that as you went from a project manager to a director, to a, you know, technical lead, to a lead developer, to a designer, all of these terms had very different meanings. Even after we had sent people to trainings, they would come in and talk about what a sprint is, what a backlog is, you know, what burn rate really means. And it wouldn't be a universal definition that everybody adhered to. So an organizational challenge that we really faced was, you know, trying to get everybody on the same page about what this is. Another option that a lot of folks have is to go out and get some training, which takes time to implement. Most shops that are looking to implement agile aren't necessarily looking to just jump in with both feet. They're not necessarily looking to send people off to extensive training courses. What they're looking for is very practical ways of getting started that have a demonstrable impact that can be measured in the near term in six months to a year. Not necessarily one that takes a large investment in order to switch over to. So we had sent a few people to get certifications with Scrum Alliance. It worked out okay. Those people quickly found jobs at other companies because now they were certified product owners. And, you know, there's other sides that go along to it. So how do you find a balance? For Trellin, what we really tried to do is focus on integrating agile development techniques, not just in the development process, but within our sales process, within our design process, and then also in our coding. And that was hard, okay? I wouldn't say it's like NP level hard, but when you have a lot of different people with a lot of different ideas about what things mean, there tends to be a lot of confusion. Instead of working on a project, there's a lot of discussion about some abstract concept about how to work on a project all of a sudden. And it takes time for the dust to settle and that's normal. That's what should happen. At the end of this road, it led to a lot of improvements and outcomes, okay? We were able to finally start making promises that if it's gonna take us six months to get a project done, we would really deliver within six months. Things wouldn't get stretched out. If we're saying that it's gonna cost $100,000 to do something, we're not suddenly charging you $120,000, okay? And then finally, that the quality of the project, what we actually build reflects what you intended at the start. There's not some feature missing that's suddenly getting pushed to a phantom phase two that doesn't exist yet. These were the kinds of outcomes that we were seeing across the board as we started getting deeper and deeper and using some of the techniques we're gonna talk about here in a few minutes. But there's one big outcome that really does matter and with all of the other ones, we can still get away with it if we slip in one of those areas. But happiness is kind of the key outcome that I like to see. People should really love what's being built. If you're doing Agile right, what happens? As you see people's hopes, their aspirations, their ideas for their applications are being expressed in a much more meaningful way that they can understand when you get to the end of a project. These are some letters that I got recently and I'm not doing this as like an advertisement, but I think our clients actually say it the best and much better than I ever could. Having a perfect delivery on this is very real for us and I'm delighted Trellin again came through with the goods. You guys are in danger of making it look easy but I know it's not. We get to the level of predictability where we can say, look, we're gonna do this at a certain level and it's going to cost so much and it's gonna be done at a certain time. And that's the kind of reaction you get from folks when they actually see it happening. You got an exceptional amount done in a very tiny time window, I've said it before, but your project managers are great communicators. One of the other sort of tangible effects that we've seen is since we've really switched over to Agile, everybody thinks we are the greatest communicators on earth. I don't put us too far above or too far below anybody. I think we're not mediocre, but it does create an impression relative to other people folks have worked with that you're really on the ball at all times. So a useful perspective on where to start. For me it's always the way I like to think about Agile and the way I tell my team to think about Agile is really that we are telling a story about a system and we're carrying out the plans for how to build it. So when we can get away from the idea that there is like a technique to this and we can really just boil it down to the simplest form. This is what you can't do without and still say you have an Agile process is that you're telling a story and you're putting the plans in place for how you're gonna build it. What we really started with are first practical steps that we implemented into all of the stages of our company processes. It's really the idea of user stories. They give us a basis to understand what needs to be done. They get us a basis to understand how much work goes in to making it happen. And they also give us a basis for testing the outcomes. When we're done with development how do we judge what it is that we've actually done? And that's what user stories give us. So for anybody who's unfamiliar I'm sure crowd this large most folks probably have a good sense of it. But with each story there is a construction to it and we stick with a very formal construction. Every story has a perspective. We'll say as an automated user or sorry as an authenticated user as an administrator, as someone else but we're always saying where the story comes from who this is attached to, who we're worried about when we put this down. Each story also has a requirement. That story has to say that there's something this person can do when they're in the system. I should be able to change my password. Each story also has a justification. That justification is what communicates the business value of it. And you could have a story that explains how to do something without that but what it makes sure of is that your business stakeholders and your developers always understand things and see things eye to eye. It lends greater context to everything that comes subsequent. Once we got through user stories, once we got to the point where people could grasp user stories where a designer and a developer could write it and our clients could tolerate us when we were trying to put them together because there were a lot of awkward steps in that direction. We moved on to points. We use points to measure everything. Okay, to measure work average, to measure business priority. Those are the common ones we use in the planning stage but then also to measure the response from focus groups. We might be done with a design. We might be testing a design to understand how effective it is. We will actually use points built around user stories to do that and then also to assess outcomes at the end of a project. We might want to understand how well our work matches up with the business value that was expected at the initiation of a project and so we'll use points there. Points are weird things. You want to apply them in a way that is contextually relevant to a project but you don't want people's kind of preconceptions to creep in. We use something called a Fibonacci scale. You see it depicted here and it's just a relative scale, okay? You know, how much work effort is required? How valuable is this compared to other requirements in your system? Depending on the question being asked, it can be a really useful tool. What we really like about it is that the answers that people give are relative within that project. Maybe a password reset feature has a business value of one in one site because there's a lot of users who need to reset their, well rather there aren't many people who need to reset their passwords. And maybe it's an 89 and another one. Maybe it's a giant community and they don't want administrators to ever have to go back and change their password. The Fibonacci scale actually allows us to kind of stay in on that. One thing about points and this is something we kind of treat as a truth is anytime we're going to collect points, we don't do it from just one person. We're not interested in one person's perspective. We try to shoot for a minimum of three. We try to shoot for no more than seven. And there's a little bit of research on the upper side of that scale that says you tend to get less relevant results when you have larger groups. But on the lower side of the scale, what it is is we just don't want one person's perspective to predominate a conversation. And that's why we're always pulling together teams in order to help evaluate whatever it is that we're measuring. After we got through user stories, after we started creating points for everything, looking for those nexus between development effort and business value, we got very serious about sprints and structuring the work output of our team to make sure that anytime a developer is working on code, it's part of a plan where we've sized it and we can make sure that things are going to get done in a structured way. Every time we have a sprint, what we do is we prioritize those sprints themselves around the things with the greatest business value. This keeps us from risking, letting critical path items fall off of our development schedule. We can always make sure we're hitting the high notes first. What sprints also allow us to do is to keep development from getting out of control. Anytime we create a task that is part of a sprint, what we do is we make sure it won't take more than a week. If it has the potential to, we break it into more than one task. And the reason is, is just we want to have predictable, measurable results at all times. That's been kind of a game changer for us. The way sprints and user stories intersect and this is what a lot of people, I think, sort of miss when they think about how all this goes together, is that each user story goes into a sprint. If you collect 100 user stories, maybe you break it up 10 by 10 and suddenly it's 10 sprints, but more likely what's going to happen is you're going to organize them thematically into something called a saga. And a saga is, well, this is the way we describe it to clients sometimes, is it's the story of a user's journey through your site. It simply talks about one kind of set of actions you want people to take to do, or one set of things you want them to take away when they've come and experienced what you have to offer. Part of what we do with sprints is we're constantly verifying and assessing what we've done. So we can involve stakeholders in the sprints every single day when we're reviewing our work and doing check-ins, but most often what happens is we have a shared desktop and at the end of the week we're logging in, demonstrating the way you would click through things, providing a little bit of training on how it would work, and it's incredibly useful for us to do that because we're just collecting unbiased kind of impressions. Does this work well enough for me? Is this the thing that I would like to be using? Incredibly useful tool for all this is join.me. We'll just get a shared desktop going, we'll get as many people into it as we feel like they need to be there, and we'll start showing off what's going on. At that point we have this opportunity, right, where we can stop being those experts on the phone with you, and we can start being those people who are just other users just like you, and we can talk frankly about what's going on. It tends to lead to better outcomes when we can get stuff down to that level. One of the other things about sprints, and I just wanna short, quickly make that point, is that they're always time limited. We never go over two weeks on any sprints. Like I said, it has the potential for things to get out of control, but really there's other reasons for that too. If you've got like 50 stories lined up, okay, and you fail on three or four of them, that's better than failing on one out of 10, isn't it, like from a points perspective? Any time you can quantify developmental measures and say to ourselves, you know, we've got past fail on this number of things, it's just a more structured way of communicating, and that's one of the big reasons that we use time limits on all of our sprints. So some of the side effects, and this is just kinda to summarize what three of the very practical techniques are that we think people ought to be considering in order to get started, really a transparency. The idea that your client knows as much as you do about your application at all times, and also about the plans for what's going to happen next. You want business stakeholders and developers really to have that same level of understanding. One of the things I've always hated is the idea that because I have a technical perspective on something, my clients don't have a clue what it is that I'm talking about, and they're kinda trying to tune me out. Agile development techniques help us to get past that real quick. Predictability, we really like knowing how much things are going to cost and when they're gonna get done. So to most folks, when we can get to that point where we're making claims and we're delivering on them, that gives this whole other kind of perspective into the things that is that we do. And it really plays into those feelings of satisfaction that I was talking about. And then finally, insight. One of the big challenges that I've had with Trellon over the years is the idea that like, hey, why did this thing break? I asked five different people, all of them worked on it. None of them know why it's broken. It's really hard in the midst of the development process to get to some of those answers sometimes. I'm not saying that I have the answer to everything, but probably four out of five times when I go to ask a question about what's going on, I can track it back to a user's story, I can track it back to a sprint, we can find a way to deal even with really complex regression errors, simply by looking back at our process and looking at the way these stories unfolded. It's a whole different perspective to development. I'm gonna back off and my good friend Blake here is gonna talk about the sales process. Thanks, Mike. I'm gonna talk a bit about the sales process and using agile techniques even at that early stage of development. So, using sizing to scope a project, you want to know that you're not losing money on a deal. And since we've been implementing this process, I'd say nine out of 10 of the projects that I've brought on have operated a profit. It creates transparency about the work that will be done. You understand the time and effort needed and so you're really empowering your developers, you're empowering your clients, you're empowering yourself as a salesperson and you're keeping everyone happy as much as humanly possible. Everyone is involved and that's what's really cool about this process. You don't have to be a genius to use it. I switched industries into technology and it was very intimidating at first because a client asks for something and you wanna make them happy but then your developers are very upset with you or me for promising these things at a certain price level. And so this gets everyone involved and there's really two sides to it. There's the sales side, the account executive, me and then there's the developers and whereas what Mike and what Jake will talk about, it has a few more people involved with the process. With me, it starts with collecting requirements from a very high level. So meeting with clients, discovering what they need and collecting questions from the developers. So I bring the list to the developers and they'll ask me more in-depth questions like how are we actually going to get this done? And from there, I'll itemize the things that need to be done and put them in a list and a spreadsheet and we'll all hop on. So we're dealing with some third-party integration with a nonprofit recently and I really didn't know much about this type of integration and so we went around, we'd collect comparative design compositions to understand the user interface requirements. And in that process, the developers evaluate each requirement, they point out gaps and things that I might not have thought about and they provide relative levels of effort required to complete the work. So really, it's just a process of empowerment. Any employee at Trelon has a support system or a safety net almost. So you're not gonna over-promise something and with that, you know what needs to be done and you know that you're not operating at a loss. Yeah, I'm gonna hand it over to Mike to discuss the design process. So to paint a little bit of a picture here, when, let's say a project has been closed on, we have these sort of proto stories that come over that were used to create, you know, sizing for us to estimate the number of hours it will take to do certain things. And at that stage, you know, we're kind of reading through them and we're thinking about what they mean and asking some initial questions during kickoff meetings. But then things kind of get real serious. With my designers, you know, some of the guys who work for us who do a lot of the planning, we get a lot of questions about like, you know, when would I create a user story? When is it appropriate to get started? I see a lot of hesitancy that happens. And the reason is that designers tend to be visual people, more so than word people. You know, they might use words for emphasis, but at the same time, they don't really focus on putting things down. So I've taken kind of a militant answer all the time. If you wanna know when to create user stories that should be the first thing you do, it should be done in parallel with everything else that you're trying to handle. I really think user stories complement wireframes naturally. And I put these two graphics up there to kind of try and illustrate some points. If you look off on the right, you know, that's a wireframe, right? We add annotations to wireframes. Those annotations naturally can become user stories. Not just because, you know, they're there, okay? But annotations tend to, let's just say, explain some of the intricacies of a design. And they tend to be the sorts of things that developers really need to know about. Like what happens when I click that button? How does the interactivity occur? So what we always say is that they go hand in hand. Annotations from a wireframe should always be reflecting user stories. That doesn't mean you shouldn't have other user stories, right? But it's kind of a nice visual for, you know, getting the picture in your mind for how they make their way from one side to the other. So how do I organize user stories, okay? For a lot of us, we have wireframing processes where maybe there's a home page, there's a bunch of landing pages. You know, we've already spelled them out for how they're gonna do. The one big change that we've kind of had to have is to tell people to organize them into sagas. Describe what it's like to go through four or five pages that are part of the registration process. Make sure that we've iterated that story before we move on. That's the only part that's really required to change the thinking for our developers is the idea that you wanna make your way to some endpoint before you move on and try to normalize everything else. It's, you know, kind of had a, let's say a big impact from another perspective, and that's of the stakeholder. The idea that they can look at multiple pages in this arc that are coming together and they can make sure that those things are consistent rather than just focusing on a set of disconnected landing pages. So how do I share user stories, okay? One of my goals always is to make sure that our clients are participating in the construction of stories. You know, my degrees are in English and philosophy. I think I'm a pretty well-spoken person, but when I'm sharing user stories with a client, I'm constantly being corrected. Nothing I can say is good enough. There's days where it feels like that. And the reason is that this is the story of something that they care very much about. There's a very specific way that they want things stated. When you can start putting stories in front of them that just aligns you with what they're expecting, which is a good thing. And maybe in the first time you sit down to do it, you know, that's kind of rough, right? But the third or the fourth time, you're using the same language as them. You expectations have been adjusted on both sides. And so that's a way of getting on the same page, which is usually a little bit more effective than other ways of doing things. So I put just in terms of decreasing importance, a list of the things that we usually do. So a shared desktop, literally sitting down writing stories together is the most effective process we have. It's one we use all the time. Shared spreadsheets is really the number two. The idea that you could take a spreadsheet that I've been working on, pick up on my stories, start writing them yourselves. We can track the changes and see what the other one has done. You know, that's a big deal. Third is wikis. I don't like wikis as much just because they're not, they don't have a forced structure. You can kind of do anything. Our stories tend to become bizarre for folks who don't have experience with that format over time. But yeah, they can be effective tools. And then sometimes doing it in front of a group can be effective. I simply do that the least because we visit our clients' offices a lot less frequently than we do the other things. But sometimes I'll have a group of 10 to 15 stakeholders and people are offering perspectives on certain parts of the system. That's a good way to make sure you get those right. And then finally, email and downloadable documents. Sometimes people ask me to email them my user stories. I try to cheat. I try to tell them, no, I can't download those. There's no way. You have to use the shared documents. But that's just how it is. So a common objection I get from designers, like what they grouse about when I say, look, we're doing user stories. And they'll say it takes a lot more time. And I'll say, yeah, at first it does. But we always make up for it in terms of development. You know, by the time we get to where we're building things out, we've got this huge backlog with all of these stories. And developers can go to town on it. Developers having to do less research is a lot cheaper than having designers put some stuff to put together their notes in a structured format. Those animations have messed up. Another common outcome that we have is another thing people are worrying about is how do we hand them off to developers? And the answer really is you don't. You know, you should be involving project managers at that stage during design. Getting them to size stories, getting them to do some of the planning way ahead of time before it's time to start working on stuff. When you're able to do that, your backlog is completely sized. You can literally jump to development, okay? Right, I mean, once you start getting near the end of design. We tend to shoot for 90% design, meaning we've got 90% of our design deliverables in place prior to starting to hand things off to developers, really. But, you know, again, with great communication and project management, that's usually a pretty easy process. So, would you like to go? So now we get to the fun part. I'm gonna see how far my voice projects, but Mike did a good job of kind of giving us an overall sort of bird's eye view of the agile process and how Trilan has adopted it. Blake did a good job of explaining that it does start with the sales process all the way until the end of the process, but we're really here at this point because of this, development. So let's prepare to set our phasers to stun. Sizing the user stories is really the most important part. As project manager, I get this very long list of user stories, or backlog, if you will. And my goal right away, as project managers, is to identify any faulty user stories. These are basically user stories that I don't think are defined well enough, maybe a little bit too big, or just need more definition. So at that point, I take it back to the clients and or developers and try to help them understand how can we cut this down? How can we make this more digestible? And the purpose of doing that is just so that everyone's on the same page and we're not trying to introduce a user story to the process that's really just too big to handle in the sprint. That's really grooming the backlog is what we call it. On the other side is I actually, as a project manager only, I do not show my developers is there's a business value assigned to each user story. And this goes back to that Fibonacci scale that we were talking about earlier. And this is done by the clients. They go from zero all the way up to Epic. That helps me as a project manager know what's really the important features that we want to accomplish in this project, but also to help me prioritize which ones we should focus on first. So at that point, we get to something called user poker at Trellen. And this is actually, the purpose of user poker is really just to have some fun. I like to have two to three developers together with me. And ideally the reason is just to have a really broad spectrum of kind of how developers might think of a user story and how they might evaluate it. And I actually keep it really simple. I use a Google doc and then column A, I leave blank. Column B, C and D, I put the developer's name. And then what happens is that I take each user story, I plop it into column A and I say it out loud. Developers here, they kind of digest it a little bit and then I go three, two, one, go. And each one of those developers in their column put in their Fibonacci scale sort of how they rate it as far as effort. At that point it becomes really fun because you get to see how different developers sort of rate on effort a user story and kind of help understand how we can come to a sort of consensus to decide what is the actual effort required for this user story. So this is a process we use quite a bit at Trello and we find that's very fun and effective of really finding out what is the pure value of how to use a user story and what does it require as effort? And again, these are points on effort, not on time. After we've done the user story's poker and we've got basically our backlog now of our business value and our now user story effort value, we begin to sprint. And I think we all kind of know what sprint is. Mike touched on it a little bit. It's just a period of time in which we actually start development. All sprints start off with a kickoff and that's where we include the clients, myself and the developers to kind of get out any sort of last minute clarification that might be required on our user stories. We also, at that point, identify based upon business value and where the user story efforts can intersect decide a total amount of effort points that we want to assign for the sprint. Sometimes it's 100, sometimes it's 200, but what this eventually becomes is our burn down rate. So after assigning our points to a sprint, we basically begin the sprint. And again, we try not to do sprints more than two weeks. I like a week, but each day during the sprint, I do a scrum and I think everyone here kind of understands how a scrum works. It takes 15 minutes, no more, no less, and then I ask, what did you do yesterday? What are you doing today? And are there any obstacles? If at any point in time during the scrum, I feel like a developer's getting a little bit too sort of technical, I stop them right there, we move on, we say that's a tech huddle. So after a scrum, right afterwards or later in the day, I'll have a tech huddle where we can get a little bit more involved, share screens, and kind of figure out what is it the developer's trying to accomplish and seeing how we can fix it. My actually favorite part of Agile is during a sprint, I really don't get any client involvement. It's pretty clear what we're doing, the expectations are set, so they can't really inject any of their requirements or concerns during that sprint and that's pretty much a benefit for a project manager. After a sprint is complete, I then looked at the burn down rate, again, back to the user stories, how many of those points were completed in that time period. During that time also, I do a client demo for review and I point and click and decide, do you accept this or do you not? And if they accept it, great, remove it from the backlog. If they don't, we add it back to the backlog for the purpose of potentially adding it to a new sprint. And then again, we just go through that process over and over, it's pretty straightforward, nothing too fancy about it. So with that being said, thank you for all your time and any questions? Okay, we got through things a little bit faster and maybe than what we thought, but yeah, we'd love to talk. I think so. Yeah, I'll put one up that we can kind of look at and if anybody has any specific questions about it, this is a screenshot of the one that I did. This is for a website that we're working on currently. Can you repeat that question? Yeah, just so everybody knows, what he was asking is, can I show a sample, sorry, a chart for tracking user stories? It might actually help us if anybody does have questions. We have a microphone there in the back of the room. Maybe just feel free to get up and line up and that way we'll make sure everybody hears. But yeah, that's what it looks like and usually there's 100 or so. You'll see on this one, we've actually rated business value and technical effort using some of those scales. This is what it actually looks like when we start putting those things together. What we're always looking for is high business value, low technical effort. That's how you rate a great story. That's one of the ones you wanna include in your first branch because then you're setting yourself up for success. When you find ones that have low value, well even high value and high effort, you wanna wait, if you can. But that's what one of these sheets looks like and I don't know if I can scale it out but hopefully it helps. Next question? Could you talk about the process you've gone through and how the scoring, the efforts, values have improved or did you get it right from the first time and determining the sprints like how much you can include in a sprint? Yeah. What I'd say is the process we went through to get this implemented was an organizational shift of a very high order. I had good friends who had been working with me for a very long time and for many of them I had to help them move on in our roles in other companies because they weren't getting it and they were never gonna get it. You have to have good leadership to have good agile processes. That's what I think. You have to have people who are not going to rush to build stuff. You just don't really get anywhere there. Everything has to be a little bit measured and that's a second reaction to some folks. So I would say our shift towards agile started close to three years ago. I'd say we started seeing results roughly a year ago and it was very painful at times but again I think it's very satisfying when you start to see the outcomes and just leave it at that. What are the questions? Okay, so the question is with billing and documentation what's different around a normal client? The answer is nothing. Most of our work is done on a time and materials basis. We bill a certain number of dollars an hour for what we do so it's the same. It's just that our billing tends to be very accurate at this point. It's very rare that we go over or come in less than 10% off of where we were originally. So we're gonna switch to just the questions at the mic. So this goes back to the sales part of it when you're going through all of that exercise of estimating. Are you actually doing that as a paid discovery phase? Are you actually getting some sort of request of proposal and you're going through all that effort because I know how much effort that takes. So where are you doing that? Because then you're having to come up with kind of a fixed bid originally. So tell us a little more about that because that to me is really the mystery behind all of this. Yeah, it's not part of the paid discovery phase but it's when we're trying to scope it all out. It's the very initial phases and the initial discussions with the client and it's not as involved as the development sizing exercises. It's a matter of sitting down, grabbing a couple developers and making sure that we're not over promising anything. Just remember, we've got some pretty bright guys on our team. So it's never that much effort for us to have to go through something like this. If we know that there's a part of it that we're not gonna get right without that, we will include our own paid development cycle or discovery cycle as part of a proposal. Like if you're trying to create an API to some system that you don't know or something like that. So another common thing that we'll do is we'll say, look, you have up to 100 hours of time that we'll be spent on this or we're gonna do up to eight wireframes. We'll build logical separators in just to give ourselves some protections. I mean building boundaries and having constraints is a great thing. And when people understand them, they get very creative about how to work within them. And it just leads places that people wouldn't if they thought it's a buffet. So that's kind of why we do it that way. Hi, thank you for sharing. We've been implementing agile for a while and we've noticed that design and specs creation like UX design and stuff like that really blocks our way when we're trying to apply that with agile. So we've kind of moved it away from the agile process and we're making it before we start the sprints for code. So my question is, do you guys do anything to get design work and design spec for usability with agile or is it just the development part? Absolutely, the two things happen hand in hand. I don't think you can build a great site unless you have a great design process. I can totally understand some organizations struggle with the idea of doing agile during design or that UX can happen before you're actually building clickable prototypes and things, right? It's really hard to assess an experience at that stage. So the way we approach it is that we're gonna create user stories in parallel with wireframes. What that does is it kind of sets the stage so that our mockups later on are going to be a little bit more informed. We'll be spending a little less time on those. When we get to the point where we're actually building the interfaces, if we were to find that like, hey, like we completely got it wrong, it's ugly. Yeah, that's a potential outcome, but that's never happened. And what we see is the opposite. Clients just kind of know what's going on. We tend to be thinking down the road of like being a partner where we really understand what the outcomes are that they seek at the end. And so just given the fact that there's a lot of folks who are thinking down the same track because we're building these user stories, that tends to solve a few usability issues long before we even get to development. So yeah, that's how we do it, but we don't consider that a blocker. That's not hard for us. Yeah, I was just curious. Wouldn't you have a user story or more than one user story, they get in progress and then inevitably takes a lot longer than you expect, doesn't get completed within the sprint? What sort of mechanism do you use? Do you just roll it to the next sprint or what do you do? Yeah, generally, you know, it's a time period, right? So if it's not done, that's really just an indication of maybe either the effort points weren't assigned correctly or maybe we need to add more effort points in a sprint. But generally, if it doesn't get completed, that's it, pencils down. You gotta put it back in the backlog and then decide if you wanna add it to the next sprint. Hi there, as a consultant sort of walking into a client that wants to do agile sprints, can you talk a little to the idea of sort of evolving into the process versus, hey, we're ready, we wanna start, we just bought Jira Sprint Zeroes tomorrow, go. Oh, that's a threatening sounding situation in a way. So, the way I would answer it is just to say, look, you know, everybody gets some place, right? We don't all start off perfect. And that goes with our processes as well as with our relationships with other people. And, you know, some of the longest, some of the clients Trillin's been working with for like six or seven years now, you know, it started horribly. Like, something god-awful happened in the first, that cost them money, embarrassed us, like threats of lawsuits and stuff. But over time, you know, we kinda learned to work together and keep things going. I'll just say that experience is a teacher. And when you walk in on the first day and, you know, folks are ready to go, you just try your hardest. And if it doesn't work, you try again. Okay, and I don't think it's any more complex than that, right? Like, one of the things I tell folks on our team all the time is just remember to swing the bat. Like, you can't just push this aside for a few months and then hope you're gonna catch up on it. I will notice and make you feel guilty. But before it even, you know, gets anywhere, it's just try. That's 50% of implementing the practice. This question is regarding team dynamics. You have a team and variably, there's developers that can do a lot more points than others. And let's say that developer may be on vacation, your burn down chart doesn't quite affect the reality of it. What kind of tips have you guys experienced perhaps that you can share that to deal with such situations? Biggest variances that we see are actually generational. I don't mean to sound weird about it, but like Gen X developers do things a different way than millennial developers. What you tend to find is that the kinds of solutions people will want to implement are greatly influenced by what they've seen in the past. And it's really true. There's generations to technology and the solutions people may have implemented a long time ago, like write a query, might be very different these days. Used Vrupal's database abstraction layer and put something else in. So where we see the biggest variances is in stuff like that, when you have a different style of programmer coming in. We don't really do vacations at Trellin, so that's never, our guys are pretty tough. You know, there's the 80-20 rule, you have 20% of developers, 80% of them work, when they're not there to kind of get that image. My other question is, do you, as a rule, or maybe high point stories, you should break up into smaller story points for a given sprint, or it's just you can assign a 12 or 21 to somebody that's recommended practice. We have a designation for something that must be broken down, it's epic. And I learned this from my good friend Zach, who works for some giant university. And anytime we get to the point where something's epic, it must be broken and we don't care, it's just automatically. It's like accusing somebody of being Hitler in a IRC forum, you know, just conversation over, let's move. So that's our designation. And basically, epic would mean over two weeks. A relationship between points and time, eventually. Kind of, we're just saying, once you get into a gray area, that's it. Any ambiguity whatsoever, you have to break it down. It has to be in digestible chunks and sort of put into a situation where if a developer can't deal with it in two weeks, then we have to rethink how that user story works or that user story becomes a saga, if you really think about it. And at that point, you're breaking down user stories below that saga. This sort of building on the design side of things for Agile, we're experimenting with options where we do everything using some sort of Agile framework, even content inventory and audit, content strategy, modeling. We haven't looked at assigning points necessarily for effort or value. Is that something that you've done, like throughout this whole process, for the design for the UX side of things? Yeah, so kind of going back to this wireframe, user stories and wireframes go hand in hand. If you look real carefully at that spreadsheet, you'll see the technical complexities there. That's development effort and usually we'll assign business value as well. It's just that we do it sporadically when we're at the design stage. In other words, we're not going to have a project manager formally sizing every story within X number of hours or something. What we're gonna have is us reaching certain points and saying, look, let's sit down and size this first because we might be getting to the point where things are way out of hand. That's really just an awareness of what needs to be there. Now, we have other parts of our process that this doesn't cover, like content type audit and user roll audit, but a lot of that kind of emerges from what we've done with stories. By the time we have wireframes and by the time we have user stories in place, that's 80% of that's mapped out already anyway. So we don't necessarily need to think about those as budget centers. Oh yeah, that makes sense. Okay, cool. I saw in your spreadsheet that you have for the business value like one and then 50 and then 100, you don't really go in between those three settings that look like. Is that a common thing? Low, medium, high, pretty much? Well, yeah, let's just remember it's all relative and you can use any scale, low, medium, high or fine. We tend to stick with the Fibonacci scale. The only times we try to break from it are when a client starts spouting off numbers. I want a 73. We can't account for that, but it means something to them. And as long as it means something to the person who's saying it, hopefully they can remember the difference between a 73 and a 69. But that's what it is. It doesn't have to mean anything outside of that context. Do you find yourself using these numbers at the end of the day as an evaluation tool of your own employees? No, no, that'd be cruel. I don't know, they could talk about what evaluation cycles are, but that has nothing to do with Hagell. Oh, okay, one other question. Oh, never mind. Okay, so with the spreadsheet, I was just getting a little lost between the spreadsheet and the wireframes. Is it that these are grouped? Like, actually, if you go back to the spreadsheet, I was looking at that, and I wasn't seeing how I would turn that into a wireframe. Is it that create a booking story that's a page and this is all the contents that's gonna go on the create a booking page? Well, where it says like booking strain story, we can say that it's Saga. The Saga, again, is that detailed journal of a user's experience as they go through your site. And we call them the Saga to imply that there's some traveling going on, right? So with every Saga, you could kind of think of it that way, like a Saga could be about a single page and describe the interaction that's gonna happen on it and other things. But the relationship is tenuous at best, right? There's sometimes when you have like a chicken and the egg problem, should I draw it first? Should I write up the stories for it first? All I know is that after a day or two, you ought to have some user stories and you ought to have some wireframes. So one does not have to perceive the other. It's just they can't really exist without each other. The one requirement that we really have for designers is just there better be some annotations. I don't wanna see back on my drawings that nobody can explain. If somebody gets into a meeting and they're like, oh, well, I don't even know I did that. I never wanna hear that. That implies you don't have a plan. And that's what we do is we think and we plan. That's what design is. I'm intrigued by the idea that using agile for the design aspect of it before you start development. But I was just wondering how would you handle technical requirements before you start developing such as custom integrations with external systems? How would you cover, how would you capture that kind of information as part of your agile process? So I can answer that a few ways. From the sales perspective. We recently had a client come and say integrator site with this third party platform. They have an API, just do it. Tell us how much work is involved. So I made Blake answer that. And I kinda knew the answer because I was able to read the API but I wanted to see how he would run with that ball. And so he set up a meeting. We itemized the high level requirements. Like the user logs in, they're logged into this other thing. User can easily go over from one system to the other. We can display the scores of the user. User always has an account, blah, blah, blah. And we sat down with the developers, size it. Developers, of course, immediately pointed out the gaps. And then they sat down, they looked at the API. Unfortunately, it was a well-defined API. So it wasn't the hardest thing on earth. And that's how we came up with a size. And a size communicates cost and time to do it. That's what was gonna be needed. Now, the second thing I would answer is, there's another part to our process. It's called core configuration. Where we look at a Drupal site, we've got this list of like 150 or so best practices that we follow. And we would use that really to determine do we need a custom module? Can it be handled a different way? What are the other cool things that could happen? And by sort of focusing at that level, okay, we're also able to sort of like make this harmonious decision, right? About how would that fit in with everything else that we have going on? So with core configuration, it's part decision-making tool and part documenting. And that makes it pretty easy for us to understand if there's other Drupal modules that could be used, or maybe we use the services module to handle some of the authentication and stuff. And that kind of makes that simpler. But then it's moving into sprints and moving into just kind of getting things done and assessing with the client. What's important to kind of recognize there is that it always starts before the engagement. We don't need this to be in a developer's hands and say, just figure it out. Whenever we do that, just I've got these little hairs and they raise in the back of my head and it's horrible. We're able to get away from all of that because we can handle it at multiple levels and allow it to make its way down the stream. But how do you capture requirements? Like, you know, if you send a query to the external system and the time's out then you need to take this step or you need to respond. It gets documented in the wiki. It gets explained in user stories for how it's going to behave. And written out in sprints and built out. So we would capture that information in our wiki and if you're interested, stop by the Trellin booth and I'll show you how we document. All right, thank you. I don't recall if you mentioned earlier in your presentation, but are any of you scrum certified, say for instance, with the scrum master alliance and do you see a value in that training? Yeah, I see a lot of value in it. Trellin's been around for 10 years and people really like to coach our employees. And so every time I get somebody's certification they're gone. What I try to do is sort of be the trainer and lead people in a certain direction and then push them towards getting it. People seeking certification tend to pick up what is it, a lot of professional credits just by virtue of their role. There's a certain number of hours you need for to be a certified scrum master. And so usually over the course of a year you get X% of those just by being a project manager. But I don't make it a requirement in what we do. It's not just that, you know, this kind of like fear of coaching. It's just that I think agile evolves and I don't know if people recognize that. They think scrum is there and it just works a certain way. But to be real honest with you there are technologies that emerge all the time that automate parts of this. They make certain questions easier to answer and experience plays a huge role in it too. Knowing who the people you're talking to is has a huge, let's say impact on the perception around what's required in terms of effort. Have we done this before? And from that perspective I think certification has a role, other organizations overvalue it. And we kind of see it as one of sort of a spectrum of things people could bring. Thank you. I was just curious if you all would task out your user stories or are they just a user story? That's a no, but we think about it. Okay. And why do you not? Because how do you know where the developer is in that particular user story? And like you said, if they don't finish it would you not want to split the story so they got credit for some of the work and then the rest of the credit could be applied to the next print? Well a user story becomes a task, okay? Like at that level we will take it, we will paste it into our task management system and it will be there. It's just that the idea of tasking out implies like there's a certain developer that's gonna get it, right? And the truth is we've got three or four developers assigned to any project, they're working through a series of sprints. When people come to deal with Trillian they're paying for a series of sprints. That's kind of like how we calculate what we're gonna do. And it's just we're not like we never have it in our minds like hey so and so is perfect for this. Let's have him do it. What it is is we write the things, we figure out who on the team can do this and then sometimes we just invest in our guys. Like you're gonna need some time to figure out how to build this thing and so we'll push them in that direction. But it's a little less task oriented than what it might seem. I remembered. Okay, if you've got someone that wants sprints longer than two weeks, have you ever had a client that's had that? Like they said they wanted to say we want to do a three-week or a four-week because we've just got a lot of stuff. Do you force them to break it apart? No, I just tell them it's a horrible idea. I'm sorry? I just tell them it's a horrible idea to try and go further than that and then I'd suggest that we do and they usually do. Thank you. Any other questions? The sprint does include a review or the day before we say pencils down as I like to say and then that next day is when I do the review with the client. That following what we generally like to plan on Mondays is sort of the back grooming for the log to see what we'd like to now include in that next sprint and then that Tuesday is generally when we do a kickoff meeting and we kind of run that same sort of cycle again and again. So the review. Do you encounter later? Well it's part of the review, right? I think you're asking how do I know if it's accepted or not or when to remove it from the backlog. That's part of the review process which happens at the end of every sprint. I sit in front of the client, we share a screen, we look at the user story, then I go through what they've done and then they tell me, yes, I like that or oh, can we just do this? Then I go okay, it's gonna go back into the backlog and then we decide if we wanna add it in to complete it that next week or we wanna move on maybe to a different saga. It's not necessarily like 100% complete, right? But it's almost there but we have to have a process. If we don't have a process, we can't point to it when things go wrong. It's part of the reason. I think we're over in terms of time. So we're gonna break off but if anyone wants to stop by the Trillin booth, we have these nice key chains and stickers and all kinds of other stuff and that could be your treat for waiting until the end. Thanks so much.