 Welcome to DrupalCon Dublin and agile your agile changing process one step at a time. Did everyone have a good lunch? Yeah, all right great. So my name is Steve Perche. I'm an agency and community engineer at Pantheon You can find me on Twitter githubdrupal.org as Steve Vector You can also find me on Twitter as Drupal high coos. So What I am not I am not a project manager. I'm not a certified scrum master So I want to make it clear that that what I'm presenting are are the opinions of Someone who has worked as a developer as a team lead on a number of projects And I've I've felt the difference between projects where the process works. It works for the team It works for the client it works for the work being done And I've I've felt projects where where that's not the case where the processes and practices being used Either don't fit the team or don't fit the client or don't fit the budget So my my interest in this is is largely coming first and foremost from my experience as a developer on a number of teams as a freelancer working on small teams working on Scrum teams as as large as 15 which I found out in in doing my research was too big And and against the advice of a lot of the scrum community So I'm also interested in these conversations around agile methodologies because they really remind me of all the conversations I've had in the improv comedy community I started doing improv comedy when I was 15 years old in high school and Improvisors love to talk about the different forms of improv comedy that they use some Improvisors use really strict forms of improv comedy where there are clear rules as to how many people should be in a given scene How many people should be in the next scene when you bring out all the performers for a group scene And there are very clear rules and procedures for when you do which things There are also forms where it's much looser where you have guidelines and suggestions And you try and feel it out as you go and as I heard more and more about the agile community Starting about five years ago all the conversations and ideas I heard reminded me of things I heard in improv comedy and and a bunch of other communities I'm also here because I work for Pantheon and Pantheon's long-term success is tied to our ability to enable Developers and development teams to work the way they want to work We think we have a strong technological advantage. We think our technology is pretty great We now have well over a hundred thousand websites running on our platform We're serving over a billion page views every month Thousands of developers are using our platform and we think the key to our success so far has been Standardizing the right things. We don't standardize everything, but we standardize things like engine x configuration We standardize things like get branch names and and we think we've made a lot of good decisions Pantheon comes from an agency background our founders were running agencies So they were working with different hosting environments like shared hosting like single VMs They made a name for themselves in the Drupal community by getting really good at setting up custom hosting clusters that could handle really large traffic situations eventually they started Pantheon because they felt That they were in a situation like this where there are too many different things Going on to any different release procedures too many different workflows being used by different teams and these workflows were varying Not necessarily for intentional reasons, but just because different decisions got made on different projects So Pantheon works a little bit more like this whether or not it's a large site or a small site Developers can think about the technological architecture in basically the same way So we feel pretty good about this however long term we know we really need to enable agencies to work They work the way they want to work. So the too long didn't read version of my my presentation I think is summed up in this quote from Dan north Dan north is the guy who coined the term behavior driven development I'll talk a little bit more about behavior driven development a little bit later In a blog post from from July even after I submitted this this session, but I found out this really summed it up The original motto of scrum is inspect and adapt and that's an idea. I'll be talking about a lot We want to inspect and adapt both the work that we're doing like the actual product. We're producing We want to inspect it make sure it does what it's supposed to do and if not we adapt the product We're also supposed to do that with ourselves inspect and adapt ourselves our team Revise our team as we go. So Dan north is suggesting that we do that for the methodology is that we use We should look at each of our processes if we're having morning stand-up meetings We should ask ourselves. What do we really want from that daily scrum meeting and are we getting it? If not, perhaps we change so it's a lot of agile methodologies really emphasize first Identifying where you are right now. So I want to identify the assumptions about This group of people the assumptions I'm making about the people who come to the project management track sessions at at Drupal con So I'm assuming that you're a part of a team that makes websites Maybe that that can feel like a team of one at sometimes. I'm assuming that your team makes new websites I'm also assuming that some of your work is maintaining old or pre-existing websites And then I'm also assuming that you do other things if you're an agency I'm assuming your your agency perhaps has a blog and part of your responsibilities are writing blog posts Perhaps your agency maintains some open-source modules if if you're in-house at a large company Perhaps you're a part of a marketing team that in addition to the website Maybe you're responsible for videos print materials things other than the website I'm assuming that you have some separation between your stakeholders and the team working on the websites and I'm assuming that the making of new websites Especially Drupal 8 websites feels like one of the most complex things if not the most complex time-consuming thing That you're doing and I'm also assuming that it's the thing you want to Agilofi It seems like the most complex thing were the most moving pieces So that's the thing we should be focusing on because it's it's the highest value Piece of work that that you're doing so I'm assuming you've then felt some pain points Especially around the making of new websites I'm assuming that at some point you've tried to produce a detailed plan early on in a project that identifies all the work That you're going to do for for this new website And I'm assuming that that has been painful at times that at times you get confusion between your developers trying to work with That detailed plan and the person who made the plan up front. Maybe someone Decides very early on in a project. We're going to use field collection The person who gets that detailed plan maybe three months later sees that may not know why why field collection Is that a suggestion? Do we really need field collection instead of paragraphs? Module or or inline entity form I'm also assuming that in addition to confusion among your team You may not be getting feedback from your stakeholders early enough. Maybe if a stakeholder sees a detailed plan They may not know exactly what to do with it. They may think this looks like a solid plan I'm working with professionals. I'm just going to wait until I see the finished product and and then I'll give feedback and And that often doesn't work out very well because often that's that's simply too late So your client may ask too late for a change and in that moment as as a caring professional I've certainly been in this position. I want to do what my client is asking me Three months four months six months after the project has started and I don't always know if I can give that to them So feeling those pain points. I I think maybe you think we're currently working with too much rigidity We need more agility. Okay, you've probably never said it quite like that But I've certainly felt that in in some way shape or form. So a number of other people in the software community have felt that pain and About 15 years ago now a number of prominent thinkers in the software development community representatives from the scrum community which predates the agile manifesto representatives from Extreme programming came together and they wrote the manifesto for agile software Development and and some of them are a little bit sore about it now just getting called the agile manifesto They really emphasize it is agile software Development that the key here is the software development part. So the manifesto gives us these these Suggestions these guidelines that individuals and interactions are more important than processes and tools We still have processes and tools of course, but when faced with the choice between the two We should be prioritizing our individuals and our interactions over processes and tools We should be prioritizing working software over comprehensive documentation Documentation is great, but if the software doesn't work in the first place the documentation isn't going to do us any good We should be focusing on customer collaboration rather than Focusing on on contracts and we should measure our success by our ability to respond to changes rather than Successfully executing a plan that was set months ago. So how do you do that? So that those are those are some big ideas. How do we actually do that? So one suggestion from a person who is there. How do you work with more agility? You can find out where you are you take a small step towards your goal You adjust based on on your your understanding you adjust based on what you learned and then you repeat So this comes from a blog post from Dave Thomas the blog post was titled agile is dead long live agility He's responding to what he saw as too much prescriptiveness in in the agile community So he suggests this looser framework. This is still a a fairly loose framework This doesn't tell you what do you do on Monday? This is a this is more specific than the agile manifesto But it doesn't tell you exactly what you do Monday at at 8 a.m. Of the morning when you're getting started. This is this is a One example of this dichotomy between a manifesto and a manifestation Humans have been talking about this separation for literally millennia going back to at least the allegory of the cave We've had this idea that there's a separation between Abstract ideas and there are more visible manifestations. We see this all over human experience I certainly saw it in improv comedy You see it in in sports in basketball a basketball team may think the way we win Well first we have to get the ball in the hoop the way we do that is by getting it to our best shooters The way we do that is by passing the ball. We need open passing lanes. How do we get open passing lanes? We use the triangle offense. All right, that is a very specific manifestation That's a prescriptive set of guidelines the triangle offense that can get you to this bigger idea of a basketball team or a Soccer team or really just about any sport trying to control the open space that will allow them to score So we have this this tension here between we're trying to fulfill this big idea And we're also getting really specific Recommendations for how to do that and sometimes those specific recommendations can end up being counterproductive They can get in the way so again from that Dan North blog post Scrum has become the dominant form of of agile a lot of people just use them Interchangeably I should say agile method So if you've been using agile techniques in the last 15 years You've probably heard of of scrum and and Dan North and a lot of these thinkers think that they should not be used Interchangeably so if I if I'm going to talk about scrum I'm I'm setting it up here as a a prescriptive Foil to to compare against let's talk about what scrum suggests so so the heart of a scrum here is the sprint and Forgive me for reading some notes, but I want to get this exactly right because scrum is is very Particular about getting the rules exactly right so the first concept that we have here is the product backlog So the product backlog is an ordered list of everything that might be needed in the product And it's the single source of requirements for anything to be any changes to be made to the product The product owner is responsible for the product backlog including its contents Availability and ordering so this brings us to the concept of the product owner if you're a web agency your product owner I think ideally is someone at your client company someone who best understands the needs of the project someone who best Understands the work that is needed and that product owner is then responsible for maximizing the value of the product and The value of the work done by the development team so that brings us to the development team the development team consists of professionals who do the work of Delivering a potentially releasable increment of done product at the end of each sprint That's kind of a mouthful a potentially releasable increment of done product at the end of each sprint The product owner and the development team meet at the beginning of each sprint in the In the sprint planning meeting so the sprint planning meeting is there to answer at least two questions What can be delivered in the increment resulting from the upcoming sprint and how will the work Needed to deliver the increment be achieved That set of questions is guided by the scrum master the scrum master is the person responsible for ensuring That scrum is understood by the team and enacted scrum masters do this by ensuring that the scrum team adheres to the scrum theories principles Practices and rules again scrum is big on theory practices and and rule So the scrum master is guiding all of these meetings guiding each of these ceremonies making sure that the rules of scrum are followed This then brings us to the daily scrum after we have agreed in our sprint Sprint planning meeting on a sprint backlog all the work. We're going to do in our our sprint We then have our daily sprint meetings every morning. We have a 15 minute meeting capped at 15 minutes by the scrum master We answer at least these three questions. What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? And do I see any impediments that prevent me or the development team from meeting the sprint goal? So the development team uses the daily scrum to inspect the progress Towards the sprint goal again scrum is really big on inspecting and adapting you inspect the work that you're doing and and you Inspect the team itself. So at the end of the sprint we come to the sprint review meeting The sprint review is held at the end of the sprint to inspect the increment and adapt the product backlog if needed So we're really moving in a circle here So the result of the sprint review is a revised product backlog that defines the probable backlog items for the next sprint So by the end of one sprint We should know roughly what we're going to work on in the next sprint before we do so we have the sprint retrospective Meeting the sprint retrospective is an opportunity for the scrum team to inspect itself and create a plan for improvements to be enacted during the next sprint and and this really is the idea that I grab on to here that I'm setting scrum up as a as a really prescriptive rigid foil for For what I'm suggesting here and yet in scrum itself is this suggestion that the team is always Inspecting and adapting itself the team is always evolving And that's really the heart of the suggestion that I'm giving here The cover of the scrum guide so the thing that I've been quoting from you can find this on scrum.org Scrum org I think it is so the title of this document is the scrum guide the definitive guide to scrum the rules of the game And I like to think in metaphors sometimes and scrum presents itself as the game being played So this here is the the set of rules for the game of scrum. I don't like that metaphor all that much I don't like to think that the thing I'm doing is scrum I like to think that the thing I'm doing is building a website or delivering value to my client and scrum is more The strategy that I'm using yet scrum tells us that scrum's rules artifacts Events are immutable so you can implement parts of scrum But when you do so the result is not scrum scrum is big on defining what is and is not scrum You're either inside or you're outside So scrum is making some assumptions and these assumptions affect the way people do it and especially web agencies Scrum comes from a world where where it's a reality that projects can be canceled at any moment And when you have that baseline assumption, it's extremely important that you do the most valuable thing first That's why scrum makes such a big deal out of prioritizing that backlog Because if your project could be canceled at any moment or if you could be thrown on to if your whole team could be taken off of that Project put on to something else. You don't get to come back to this project for a year It's really important that you do the most valuable thing first because if you don't then then you're wasting your time I don't think that that works very well for for web agencies Where often the project being done is the replacement of a of a client's whole site that project probably isn't going to get Cancelled they their website is five years old. They need a new website Cancellation isn't a huge risk So there's less of a need to carefully rank every single story against every other story Scrum also assumes team continuity It assumes that there's going to build up kind of an oral history within the team The team will have a collective knowledge base That's one of the reasons you can Prioritize documentation because everyone working on the project has been there since the beginning of the project is going to stay on until the end of The project that's not a reality that many web agencies can work inside of for a lot of web agencies team members are going to get shuffled around and As much as a web agency may try and work around that or avoid that It's it's just reality that team members get shift around vacation schedules can can throw things For a loop scrum is also assuming a high level of expertise Expertise not only among the development team which which can be a pain point Especially as you adopt a new technology the first Drupal 8 site your team builds You probably won't be at at that expert level that you just left with Drupal 7 it's also assuming an expertise and the scrum master and the product owner role and It may not be a reality that your client is an expert product owner You may want them to be an expert product owner capable of understanding all the dynamics of the project But that may not be a reality. It's also assuming a certain starting point It's assuming a starting point that that is ripe for for scrum a great point that I think summed up this idea is that scrum starts with the right context and More flexible agile methodologies like Kanban improve the existing context so In a project at least as as I found it scrum more has the attitude that if it's not working Then it's the fault of the situation scrum is correct and something about the situation must be changed Whereas a philosophy like Kanban is more likely to assume that the given situation doesn't need to be judged You accept where you are and you take a step in the right direction. So there are still some advantages to Strict scrum you're going to have volumes of literature that you can read That will answer questions for you. You don't have to answer every single question for yourself There's a community of people that you can hire Scrum practitioners really do suggest that you hire someone who's a certified scrum master who can be present at all of these Meetings and guide your team so that when a question comes up, how should we handle this situation? This sprint seems to be going off the rails. What do what do you do? Well, you ask your certified scrum master what you do and and then come to an answer More quickly you also have the advantage of internal consistency if you're working at an agency that has multiple teams and Everyone is doing strict scrum. Not only are you internal amongst yourselves. You're also Consistent amongst yourselves internally You're also consistent with with the outside world and and even your client possibly may be familiar with strict scrum Practices and may even see that as as a value and and a selling point that you can use for the outside world I still think this is is somewhat odd that agencies try to do one giant leap to a Specific practice or a philosophy that's all about baby steps. So In in preparing for this presentation I looked at suggestions for how does a team adopt scrum and I found two main lines of suggestion either you do a big bang Transition as it's called in a lot of the blog posts where your entire company switches overnight and this has some advantages You can reduce resistance if if the messages were we're doing it. We're doing it all at once We're leaving the old world behind. You don't have different teams doing things in different ways and And creating friction amongst the teams internally and it'll be over more quickly is is another point All these points come from a blog post from Mountain Goat software a great source of information really for all things scrum And and agile included the the other Way of doing things that I found other than a big bang transition was switching individual teams yet switching each team All at once so you may go team by team But for any one team it is a hard switch from the old way whatever the old way is to strict scrum so again, this can be painful for a Lot of agencies your client may not know enough to be the product owner You may not have a certified scrum master on staff And it may not be realistic for for your agency or your company to hire a new person who's a certified scrum master Just to play this role The person playing this role can do other things. You don't need someone who is only this scrum master Yeah, this still can be a blocker your internal teams may may be shifting You also may not have someone dedicated to a continuous integration Process this is the pain point that I hear a lot in my role at Pantheon People come to us because they're making a technological shift or what at first feels like a technological shift from whenever their their hosting solution is And their development workflow solution is before Pantheon to Pantheon So we start with conversations like what branch what branching strategy do you use? How do you do deployments and very quickly we uncover deeper problems and again to that point that scrum is assuming Expertise scrum and agile methodologies as a whole work best when you when your tools are solid especially your continuous integration tools all these Agile methodologies and philosophies emphasize the importance of knowing exactly where you are now so you can take a step in the right direction Continuous integration is the way you validate on a technical level that you are where you think you are I've certainly been on projects that didn't have continuous integration where I closed a ticket Saying it was done and we didn't really know that it was done Until the project got further along because we didn't have Environments that continuously tested our code I could close a ticket and not really know that it was done another pain point is the the philosophy of MVP minimum viable product the idea here is that the work that you're doing is the creation of a product and that you want to Create an early iteration of the product that can be released to the world can be Usable by by the general world and after you get to that point Then you can prioritize the next most valuable thing and the next most valuable thing after that This can be very difficult when the thing you're building is not a new Minimum viable product but a replacement for a mature website if you're building a replacement for a website that has stood for five years You're going to have a hard time with minimum viable product thinking because your client is used to a website That's five years old. That's very mature. It has a mature feature set. You'll have a hard time telling your client Oh, we don't need these features anymore. We can launch this new Drupal 8 site that has 50% of the features of of the old site MVP then may just be the the end of the project and if your MVP is when your budget runs out Then it seems totally counterintuitive to me. It's just the end of the the project also a lot of the scrum guidance I think best applies to that post MVP stage, especially backlog Prioritization prioritization if if you have 50 stories that are required to even launch the site Then I think it's less critical to order those by highest value because they all have to be done before the site can be launched And and there's also a natural tension between this product mindset And if you're in a web agency your your core offering is a service Not necessarily the the product of the website being built So you may be trying to use all the aspects of scrum But do you have control over the strategy the scope the structure the skeleton the surface? These these five levels of a digital project come from this book I read a few years ago called the elements of user experience and when I when I read this book that Said nearly all digital Projects have these five layers a light bulb basically went off in my head because I realized for a lot of the projects That I was working on Drupal site builds. We didn't have control over all five of these layers We didn't have control over strategy or scope at least the team implementing the site We got to make structural decisions about content types and modules and and skeletal decisions About you know even even more fine-grained implementation details And we can make decisions about the surface layer like like CSS, but a lot of the scrum tools like user stories are really meant to I Address these first two layers of strategy and scope and if your team doesn't have control over strategy and scope if your client Doesn't want your input if they just want you to build the website then using tools meant to address those top two layers Won't be all that helpful for you because if all they want is the site to be built and you're trying to Address strategy and scope questions. You may just be spinning your wheels. So I I Talked to a lot of agencies in my job and I hear a lot of well We don't do scrum we do Wagel a mix of of waterfall and agile or it's scrum, but it's it's not quite scrum It's it's a little bit different. It's or it's scrum con bond It's scrum bond it's scrum ish or we do a customer-centric process that bends the best of waterfall scrum extreme programming and and BDD and I Think this sums it up really well. We need to let go of the process guilt. That's plaguing us There is no gold star for achieving a 100% agile process I think this gets back to that idea of what is what is the game you're playing if the game is scrum then? Okay, you are trying to get scrum points and and do everything correctly because you're trying to get the perfect scrum score But most of the clients I worked with didn't care if we got the perfect scrum score They they cared if the website did what they wanted it to do They cared if if there are expectations about the website or met So are you are you doing agile or are you auditing your clients content? Are you creating a brand strategy making a website? What is the thing that you're doing? Are you delivering value or are you doing all of the the things of of scrum? So agile is not what you do Agility is how you do it Dave Thomas again that the guy who wrote that blog post about agile is dead long live agility He really emphasizes that Agility is is what you should be focusing on agility As a as a descriptor not agile as a noun so What what now how how do you how do you do what I'm talking about? So again from that Dan North blog post the idea here is that for each of these scrum practices We should be asking ourselves what value do we really want from this? What benefit is this practice really supposed to give us as a team? And if it's not giving us that value should we be doing it at all so? user stories as an author of the agile manifesto I want that stupid story format to go away so that people can get to the essence of user stories So who here works off of user stories? I worked off of user stories for for quite a long time and Writing good user stories is really really hard as as I found I fell into I think each of these pitfalls I jumped to detailed solutions. I wrote stories like as a something. I want a list of five related news articles I don't think anyone using a website has ever said that Mismatched personas you might write a story like as a shopper I want a fast checkout experience so that I don't abandon the cart Shoppers don't care about shopping cart abandonment your stakeholders might care about that metric shopping cart abandonment is Someone on the inside someone on the inside cares about that your shopper may want to a fast checkout for some reason other than Protecting your metrics you also have the Goldilocks problem of user stories that are either too big or too small to be actionable in a single sprint dependencies in the idealized form User stories should not depend on one another they should each be Independently prioritizable so that anyone could be pulled in based on its value not based on the order in which things need to get done and I think a really big risk is getting into the mentality that user story writing is the thing that you're doing I Think what that that tweet from Ron was emphasizing was that user stories are a tool to do something else The thing that you're doing is talking with your stakeholders trying to discover what they really need and user stories are just a way To do that however I certainly got into the mentality that what I'm doing is writing user stories rather than what I'm doing is Talking to my stakeholders finding out what they really need Finding out what the the website needs to do and then I'll capture that in the best format and maybe user stories are the best format We're doing that, but user stories are not the thing itself So write user stories where you are the user write user stories where you are the the person trying to get the benefit make a backlog for improvements to your physical office as a developer I want a Fuseball table because I don't know I I don't actually want a foosball table Write user stories for things other than than websites practice the the art of writing good user stories and And then form them into a backlog if you're moving offices or if you've got an office that just needs improvement A backlog is a great way to show what's not being work done If you have that user story that says as a team member I want a foosball table so that I can relax at lunch That user story might be at the bottom of the backlog and it's a great way to just identify Not a priority this year We are not getting a foosball table this year anyone can look at your all company office backlog and see foosball table is at the bottom of the list or maybe it's at the top of the list and It can then be clear the next time We land a project foosball table is the next thing we're pulling in it's a way to prioritize Future work and it's a way to have conversation and definition prior to action If other people on your team don't want a foosball table They can jump into that ticket or that issue and explain why they don't want it and that argument can be had out In the bottom of the backlog before pulling it into the top so Another suggestion a point a product owner for your company's own website and the reason I suggest this is because Being a product owner is hard Especially if you're expecting your clients to product own their own projects They're going to have a difficult time with that because they probably have a bunch of other responsibilities They probably have to maintain something about that Drupal 7 site while you're building the Drupal 8 site This could feel like extra work that you're asking them to do and that's going to be painful And there'll be all kinds of ways it can go wrong. So I suggest that your company feel that pain first Appoint the the owner of the web agency or your marketing director as the product owner of your own website have them rank user stories find out how difficult it is to do and then Through that you can learn suggestions to give to your own clients about how they can do the difficult job of being a product owner And then what value do you really expect from that product owner? I think a great value is just a clear ranking of priority You can have one person who is responsible for ordering the the priority of things for for your own company website You've got a clear Responsibility for who is defining done. What does done really mean for our new social marketing campaign for our own company's blog Same thing with continuous integration. I talked to a ton of Agencies who are excited about continuous integration who want to do all kinds of things in response to pull requests They want to run a million tests. They want to install Composer and they don't necessarily know where to start I think it's a risky proposition to figure out all things continuous integration related on billable client time If you're working on your own site in between client projects I think it's a great a great place to experiment with continuous integration Find out which pieces of continuous integration are highest value for for you and your developers Same thing for the concept of a minimum viable product. What really is the minimum viable product for for your new physical office? What's the minimum viable product maybe for the the open-source modules that your company? Maintains if if you're writing new modules for Drupal 8 as a company There's a lot of tension between are we just porting the Drupal 7 basic functionality? Are we trying to do all the bells and whistles that Drupal 8 makes possible? Answering the question of what is the minimum viable product for our our open source module We'll then get you in a better practice of defining minimum viable products for for your client projects Your company's blogging practice. Are you making a training series even even your holiday card? And and I want I should have added here the minimum viable product for scrum itself at your agency If as a company you're adopting scrum decide What what does success look like for adopting scrum at your agency? How will you know when you're done a lot of? Scrum and other methodologies really emphasize defining done are you ever done adopting scrum probably not because scrum is encouraging you to Continuously adapt and inspect yet. I think there there's probably a point where you can say we're at least satisfied We've reached a minimum viable product of agile methodologies themselves At our company when you do that when you define a minimum viable product you're lowering risk It can be risky to just aim for the the what seems like the final end point of a product If you get to a minimum minimum viable product you can then pivot or evolve your project more easily It also forces clarity. What's the the real purpose of our our new office or our open source module? And that can inspire and guide the work that you're doing those those three questions What did you do today? What did you do yesterday? What is is blocking you? I think it's worth asking what value do you really expect to get from those questions? I've been on on projects where that scrum that daily scrum meeting starts to feel a little robotic Where we just wait for everyone to go through and not not everyone is necessarily even listening to one another So what's the purpose of that meeting if you're an all remote team is the purpose of that meeting? Really answering those questions or is the purpose of that meeting just getting face-to-face interaction with people who otherwise? Don't share an office. I think that's okay If the the real value you're trying to get out of that daily stand-up is just a human connection with your teammates That's totally fine. Ideally you have tools like Jira or github that are already answered those first two questions I think an abuse of this meeting is when Team members assume I can just tell people at the meeting what I did yesterday I don't have to update my tickets your tickets should should answer that first question What is blocking you? That's that's probably worth we're talking about no matter what although Identify that in a ticket to the bi-weekly demo or or that sprint review meeting What do you really expect to get out of that meeting? Of course you want to review the work that you've done but maybe there are some some byproducts are you Reinforcing for your developers that the work is real when I shifted from Having kind of vague monthly milestones to hard every two-week demonstrations that that got me more serious about my work and Helped me make sure that I was calling things done that were actually done I Also found this concept of demo driven development as I was leading teams and talking with more junior developers We're having a hard time grasping. How am I going to do this ticket? I've got I've got a ticket that tells me I have to do this photo gallery How will I know what I'm done what I would ask is well How are you going to demonstrate it to the client and we would talk through how we would demonstrate? Demonstrate it and that would guide the development work itself So we would clarify when when we're really done and this can also just be an excuse for other conversations If you've got a whole team of stakeholders who will show up every two weeks But won't answer email and won't answer your tickets this bi-weekly meeting could just be an excuse to talk to your Stakeholders and get answers to questions that they're otherwise ignoring And I think no one is stopping you from doing a bi-weekly demo on a waterfall project I think any project management philosophy you're using you can do a demo at any time and just show your stakeholders This is how far we are And and probably no one is stopping you from breaking down even a waterfall project into two-week increments The first project that I worked on that I called agile was really just a just a waterfall project in two-week increments We we had a daily scrum. We had user stories, but it was it was a set scope Broken into two-week chunks. We had demos and it worked pretty well So they're byproducts as well of Retrospectives that that meeting that your team is having maybe you just need to blow off steam about your client maybe the client is is really difficult to work with and and it's helpful just to have 10 minutes of Discussing what's happened. Maybe your team likes to bike shed details And if they don't have a scheduled argument with one another then in every pull request in every issue They'll they'll debate minutia and the the bi-weekly retrospective can be a good time to catch up on those things It can also be a good time to catch up on implementation details, especially if you're just starting to Adopt Drupal 8. There's a good chance different people are figuring out different things at different times It can be hard to squeeze that knowledge sharing into your daily scrum fit it into the the bi-weekly retrospective meeting We also have this concept of a different driven development. We've got demo driven development Which is not a real term. It's it's just something I came up with Test driven development and behavior driven development. The idea here is that somehow we are trying to guide our development by by some Visible goal test driven development can be as as simple as just writing unit tests or writing some kind of automated tests as you're coding Behavior driven development is is a relatively new community compared to some of these these other communities that really emphasizes those Conversations that you have with your clients really emphasizes the importance of finding out what your clients really need capturing those needs in conversations and then as a byproduct Writing automated tests that really capture those those conversations And I really like the behavior driven development community because they have a philosophy of community that I think is really helpful They see themselves as a centered community rather than a bounded community This is a separation and ideas of community that really comes from the theological world So they point to scrum as a bounded community that really emphasizes those rules and practices really emphasizes that you're either Inside or outside scrum that there's a hard boundary They see that as different from the way they identify the behavior driven development community which Orients itself around a center and they think the key question is are you moving towards the center? Are you moving towards the manifesto for agile software development? Or are you moving away from it? And that's really what you should be focusing on moving towards the center rather than trying to be inside or outside a Hard boundary because when you focus on the boundary then there can be this byproduct on focusing on Excluding people excluding the people who are outside the boundary the behavior driven development thinks It's much more important to pull people towards the center wherever they are So I think you're moving towards the center when your team knows the benefit of each process being done If your team doesn't know why they're answering those three questions Then they're not going to really be adding value those questions are a way at getting At a deeper concept and if your team isn't familiar with what the values that each process is bringing then they're not going to get that value If you can safely experiment with new processes the agile community is evolving all the time coming up with new ways of doing things Flipping the user story so that the value is first whoa Experiment with that find out is that going to help you if you put the value before the the persona Can you drop practices that that just aren't working for you anymore? Can you talk and disagree about your practices without it completely stalling your team? There's a risk here I think especially with scrum when there is that hard boundary and a desire to be on the right side of the boundary that It can lead to argument and it can lead to teams stalling out arguing about the rules of the game scrum And not focusing on on what their clients really need and I hope you feel a little bit less Scrum guilt as a result of of this talk So thanks everyone and I think we've got about 15 minutes for her questions anyone who has a question Please come up to the microphone so that it gets added to the recording here Any questions at all? No questions. I don't believe it All right, we've got one here. I work in a small company and we have three developers Two developers and one designer And the problem is that most of we also work with scrum, but most of the time our clients Give feedback or really late. Yeah, or really fast and then we have to adapt right directly How can we use that in the scrum methodology because if we have to work with two weeks? I have to tell my client every time don't have time for you now come back in two weeks Right. So you're talking about the problem of the client gives feedback Maybe mid sprint and you have to tell them. Sorry. We already locked our sprint. Yeah I Can't listen to your feedback until two weeks from now or I can't do anything about your feedback until two weeks from now Yeah, that really reminds me of I've certainly felt that same pain point where I was in a situation where it was Nearly the end of the project like the site was launching literally next week And one of my co-workers wanted to say that same thing to our client Sorry, we can't fix that bug because the sprint doesn't end until you know that next Friday and our client is saying Yeah, but we're launching on Tuesday and this is a bug and it's the most important thing and my reaction was well We we need to fix that bug and and that for me really highlighted that the difference in thinking between My thinking that scrum is the strategy that I'm using to play this game this game of serving my client and when when my strategy doesn't suit me when my Strategy tells me to do things that contradict what my clients need then I'll drop the strategy Whereas my co-worker was thinking more that the game that we were playing was scrum and we need to play by the rules so we can't we can't fix that bug until the next Monday and I I Don't think that makes any sense. So I think It There's there's certainly value to setting clear boundaries for your clients because if you don't then they won't pay any attention at all to the two-week Concept of a sprint and they'll expect that you can can do anything at the drop of a hat And that that's where it gets to a gray area and you just have to decide is it worth it for us to deviate from our process here for this request and That's that's a taxing question to be asking over and over again, which is I think why why scrum suggests Follow the hard rules because then the answers are clear and you don't have to To spend so much time thinking about the answer to each question as it comes up the answer is already there The thing we sometimes do is we have time blocks We said for that client two hours and two hours for that sure, but then or you have too much Too much time in your sprint is for three-week work if all the clients would react, right? And that that's always also very difficult to to priority eyes. Yeah Yeah, and that's why I think Kanban is a good entryway into these kinds of methodologies And I think Kanban is is a better way for for some teams entirely where Particularly if what you're talking about is a support model where Where Your clients may ask for something and expect it to be done as soon as possible Then I think Kanban which gives you that board of these are the tasks that should be done These are the tasks that are in progress and these are the tasks that are done and you may have you know Different broken out stages in between but it's basically stuff We haven't started stuff being worked on and stuff done I think that's just a better starting point for a lot of projects And it may even be a better ending point for a lot of projects that the value you need for your team is clarifying how much stuff are we trying to do right now because I think a problem Really across the board for for just about any company or any group of people is that they're trying to do too many things at once And a Kanban board is a really good way to identify. Oh, we really do think we're doing 12 things at once Maybe you're maybe you're not actually making progress on 12 things at once But there are 12 things identified as in progress that gives us a clear indication that we we can't Pull in this new request unless it's absolutely critical Thank you. Sure Yeah, maybe just a quick comment on this kind of situation where you have a client And you cannot rely that the client will answer every two weeks, right? Which is when I'm working on for a client just for myself, which sometimes happens then It doesn't make sense to say to make this metronome of two weeks And then the client becomes the metronome of everything then the client sends an email either One month and then one month later and then one week later and then two months later, right? And then so there's some communication and this dictates the Rhythm how you do things right and I think that gets back to like what it what is your organizing metaphor or what idea? Do you have in your head about your relationship with your client and what what picture does your client have it in their head? I think these processes work best when everyone has the the mental model We're all on the same team together. There's no opponent. We're all trying to do something as a cooperative entity That's not the picture all clients have in their head. Some clients have in their head. I Pay you I tell you to do stuff and you do it and and if that's them if that's what your clients think then I think Most of these methodologies aren't going to be helpful because most of these methodologies assume everyone Sees themselves as equal members of a team and we're all working towards a common goal and if your client the person paying your bills sees you as as Someone who who's just there to serve their whims and and do what is asked then then it's not gonna work Yeah, I mean there I still want to have some interactivity, but and someone for inside tried I said, okay Let's make some issue issue queue, but then I found that it doesn't really have a future with it Right, so and then we just have like emails and I say, okay I finished this and this and this can you review this and then I can't go to reply and so one important thing to organize is that you You need to prepare that you're not working full time for this because there will be times when you have to wait for the client And so you have to fill this with other work Yes, then you also you need to tell the client that sometimes you will do other work and they have to wait for you Yeah Yeah, I certainly found found these methodologies most successful when everyone on the team was full time And there was a large enough budget that we could could decide all right. We have four people We have six people and we're going for this amount of time and we're all full time. We're all focused on it. There's There's a cost of inefficiency to be paid when when your client isn't giving you enough work for full time and and that's I think is something just worth communicating to your clients that if if they don't have the bandwidth to do the project at full speed and full time then You're just going to have to split their work with someone else's work And your work is going to be more inefficient as a result so I think sometimes there there is a cost savings to be had by by convincing your client that this project is important enough for their full-time attention for a month or two months or whatever amount of time it is because Someone has to pay that attention and if you can talk about it attention attention as a right as a thing that has to be paid Either they can pay the attention or or they can pay you in dollars or euros For a project manager or a product owner to be appointed internally within your agency to pay that attention Yeah, yeah, maybe the last point I was making is that internally even if you have the client Irregular rhythm then you can make still use some of these techniques. Oh sure. Yeah, and and you You're not completely off the trail, but you just shouldn't be too close-minded about it, right, right? I think there are plenty of clients that that can't Can't move it at that speed and I think that's where Kanban boards are really helpful They're just a great way to identify for your clients. These are the things in progress We're just going to to work as many as we can when we can review them at your leisure, I guess And then and then we'll keep going All right, well, we're just about at time I'd love to talk with with anyone else who's who's interested, but thank you for coming