 My name is Lee Griffin. I'm a senior engineering manager working for the CPE team and that's the team that helps to look after the fedora and sent to West communities I'm also a lean master student in Water Institute of Technology Where I'm looking at lean enterprise excellence And I'm here today to talk to you about a topic that I've been exploring for the last couple of months To look at scrum from a lean lens and it's called how lean is your scrum Now why scrum? Well scrum is dominant quite simply and in the most recent state of agile report It's occupying about 80 something percent of the market share when you factor in the hybrid versions of scrum the pure versions of scrum But more importantly across all the people surveyed the top five agile techniques have the majority the scrum ceremony So people really enjoy retrospectives. They try to do some kind of iteration planning and reviews and try to work in short iterations And what I really like about scrum and it pairs well with other approaches It's really something that you can get other frameworks and approaches to complement So the most popular going on the scrum master trends report This is the last one available to me and had Kanban Which is actually a lean in approach as one of the highest and most popular Integrators with scrum and Kanban is very popular because of the visuals and it gives you this pull-based system and But how strict do you follow Kanban? I know teams I've worked with very rarely followed with to the letter of the law work in progress limits But it's a complimenting tool And what's really interesting if we just quickly switch back to the last slide 1% of the agile techniques are in the lean startup sphere And if you look at the percentages here at the top four items lean as it mentioned Which is really interesting and that's kind of what I gravitated towards Some motivators here for why we want to look at this Remote scrum is difficult and I say that as a practitioner of remote scrum for several years Now that the whole world is at home and we don't have this hybrid model. There's a lot of distractions You have emails instant messaging family life So you know at any given moment even in this presentation you might hear two screaming kids in the background and that's totally fine The duration of the ceremonies are problematic and Sprint planning for example, if you were to go by the scrum guide is up to eight hours for a one-month sprint ergonomically sitting in a chair for longer than an hour is not good for your health Fatigue meeting apathy. These are things that are happening and there's a lot of research being carried out now But the real impacts will be seen in a couple of years time Something I've always preached and it's very difficult in remote scrum is the whole mechanically agile be mentally agile And what I mean by that is teams that are mechanically agile they can do the ceremonies They can groom their backlog they can work in short iterations They stay on the framework tracks and they get to their destination But is it sinking in up here is the rationale happening for why you're doing these things? And if you don't have the rationale, that's when the fatigue of the apathy starts setting in and if you Pay are all it is not just from a process perspective How many companies are set up for working from home with it policies? And this pandemic will help to fight it policies for the globe going forward and Then you have inadequate home office spaces people working from kitchen tables Not a great situation to begin But this is the reality that we find ourselves forced in so that's my motivator for why I wanted to look at this And scrum is evolving We've had several iterations of scrum going in recent years after a large gap in time Adaptations to scrum to me they're normal and healthy. That's why we have a retrospective And this is why hybrid scrum year on year is increasing in popularity But not all teams have a perfect scrum environment and we try and make scrum fit into an imperfect environment Matrix organizations what I mean by that is development and QE of different manager streams and different parts of the organization and different budgets Which can present a lot of challenges And not all skills are capable of being in that one team So as much as we like to talk about a cross-functional team Sometimes all of the skills aren't available to us for various reasons and what we often have particularly in big companies and is a Waterfall flowing into an agile processes flowing out to a waterfall. So market needs and all of that top heavy analysis for Deciding to invest a heavy amount of resourcing into a problem. That's waterfall in nature Shipping your code to a customer, you know the nirvana of shipping at the end of the sprint Very difficult for a lot of teams that are in a multinational to have compliance and other regulatory issues to deal with And that means when the sprint teams are finished it goes into a waterfall to get out the door to customers That's the reality and that's why scrums adaptations are becoming more and more important Now a very quick note about lean and the origins are in the Toyota production systems And this is going back to the 1930s. So they have Probably an 80 year head start on the modern version of agile software development and won't make it out in 1991 and Wrote a seminal book on the machine that changed the world and these explored some principles Which is really what lean has to still down to as a philosophy and I really need to reinforce that lean as a Philosophy in a mindset within a company set of tools and culture So it's not like a full-blown framework that's got like scrum And the principles are looking at productivity waste reduction is a big one and this continuous improvement mindset And that's really what lean is all about And the most successful companies really do embrace it as a philosophy and not just the tools to achieve the likes of waste reduction And the productivity aspects It's really interesting that the success rate despite having 90 plus years of experience in lean environments Is actually 10% that isn't really really low when you look at the adaptation of lean It's ubiquitous in manufacturing industries, but only 10% have a successful adaptation. That's long-lasting And that's that whole meant leavey mechanically conversation. I mentioned So here are the famous eight ways of lean and I'm not going to dawdle on this slide because we're going to look at them individually as we go through it The first waste is defects So this is additional work that is performed on a product or service And if we're to view this with a software lens because we're at a software conference that software bugs that's extra work that we have to do that we didn't originally plan for and Where this can actually come from a lot of the time is unclear Procedures or specifications, so we're unsure exactly what we've been asked to do and we don't really have a format or a process to handle this and The relevant causes as viewed from a lean perspective is poor training And it can be caused by excessive stock. So leaving things hanging around for too long. Is that technical debt? I think it is it's probably technical debt Now if we look at this show a scrum lens and Scrum genuine you struggles to handle in flight bug bugs if you worked on a SAS platform And where you have just in time bugs coming in we can't plan for those bugs We can plan a capacity and if you're viewing your your team as I'll do 80% on plan work and 20% on unplanned work that fallacy comes back to bite you so quickly and What teams have had to do is abstract the bugs into a dedicated team a customer or community success team That breaks scrum as a model and that mentally Impairs the team because they're spending so much time going through ceremonies to plan two or three weeks of work and then problems are encountered in production There is a challenge with requirements right if you go too deep on requirements You're not agile. You're probably a version of waterfall If you go too light the risk of defects increases So that balance is really really difficult and I don't think any team in the world has solved this yet But it's something to be conscious of I then you have the skills and balance the scrum guide denotes three roles and exactly three roles scrummaster product owner and the team And you look at the amount of people that are trained for scrum and Certified scrummaster is one of the most popular training and certifications in the world for anyone want to work in scrum Product owner is a distant second and scrum developer So training developers for how to operate in a scrum environment to use all their tools or approaches their best practices Minimal absolutely minimal. So for example, if you're a team that follows Test driven development scrum is probably a very good mix for you If you're a team that follows behavior driven development Not such a good complement because of how BDD actually operates. So that Imbalance creates a potential defect in issue with scrum from a waste perspective The second lean waste is inventory that sitting idle or waiting as we like to call it So literally waiting for something to happen with your code and In manufacturing terms and even in software terms this can be viewed as batch completion versus a single item transfer So trying to move items True the value stream and moving them at a single level rather than waiting for that to load up And what's also added in here is the time required to perform rework because all of these ways to interconnect with each other The rework time is literally waiting before your customer can get it And that is a real symptom of inadequate flow through the system that we're not able to move things quickly enough into our customers hands Now you look at this from the scrum lens again the potentially shippable increment That's a batch right because we don't release those bugs and those features as we go Well, most teams don't there's certainly teams that operate at a very high level of CICV But in general is your customer able to receive Bugs or our new features in flight or do we have to batch it and hold on to it? The definition had done to me actually hampers the flow within the team It increases the quality and this is where the trade-off and the conversations have to happen within the team Because you have this early and often feedback loop it causes rework naturally where you're putting a very raw Pull request out there for people to review give feedback and do that rework cycle Arguably great learnings, but it creates bottlenecks depending on team makeup Especially if you're depending on a core set of skills to progress that I Mentioned the skills in balance and matrix organizations earlier and that skills matrix can lead to people waiting Especially if you have an imbalance with quality engineers and engineering and depending on Your team's view of quality. It should be everyone's responsibility But some teams will always opt for the the expert and quality to review something and with about a five to one ratio That's an imbalance in skills and that can lead to a lot of waiting on that person's availability the third waste is transportation This is described as non-value add movement the materials are people Lean talks a lot about value add necessary Non-value add and non-value add and the three things are basically framed around the customer is our customer paying for this That's a value add. We're adding value to what the customer wants Sometimes there's necessary steps we have to take that don't add any value But we're okay with it because if we don't take it the customer ultimately won't get the product But non-value add are things that are pointless. So why are we doing this? And Processes that should be grouped closely together to minimize delay is a way of handling this from a lean perspective But going back to our causes large batch sizes Which you see is a repeating feature going through the waste is a problem and complex systems If you name me the software system, that's a simple system And I'll give you a hundred dollars because they just don't exist to get a complex And system view of software that is distilled down into something that's simple to allow a very clean value stream It's very very difficult unless you're designing specifically for that and if you are you're going to make a lot of money Now if we look to a scrumb lens What we're talking about here from a transport perspective is the imperfect skills mean work is handed off And this is where the code to feature the product a ticket is handed off and waiting for another part of the company to complete This could be compliance for example So security productization release engineering policies might require this to go down the value stream Outside of your scrum team's visibility to get the final stamp before it gets to the customer This means that you need to view your software engineering processes as an entire software supply chain They look at it from the inception point to the requirements to the point that reaches the customer's hands and Your scrum team might not have that buy-in But you need to try and push for that buy-in to get all of those other parts of the organization buying into the process and not Having scrum working in an isolated silo Now automation is generally an afterthought and Manually moving code through environments looking at manual intervention because it's gated by key skills or requirements or so on and There is a base set of technologies and Technological and safety nets that need to be in place before a team can really harness and Empower themselves through the use of scrum so the likes of regression test beds proper environments proper access to hardware virtualization and a process that allows all that flow But generally we tack that on mid-flight in the scrum team or after the fact the product is launched and available Because we need to get the market quickly and I get that's a trade-off and that's probably a very critical view of the world And put that value that you get from having automation is huge to minimize this particular waste The Fort Waste is motion and this is another non-value add where you have the movement directions of people that don't add value to the product or service and from a Manufacturing perspective. This is the poor design and layout of the organization the poor process design The large batch sizes that you have to go and move things in a slower pace Now, I hear you thinking that we're not in manufacturing. We don't really meet or move, right? We're not moving between meeting room certainly at this time of year, but you look at motion from a scrum lens and meeting attendance to me is a problem and whole team meetings which scrum Recommends, I won't say mandates is probably the wrong word. It is designed for knowledge sharing, which is fantastic But 90% of people on scrum calls in my experience are passive listeners when you get to that knowledge sharing ceremonies for Ticket breakdown or backlog grooming and it's typically the person with the most knowledge to technical lead or the SME in the area are driving the conversation The rest of the people are passive and passive is very bad and remote scrum at the moment because people are getting distracted by emails by cap mems Anything else going on in the world? So That's something we need to consider right do we need the whole team to be there? Context switching so the multi hat roles from I'm writing code to review and code to testing code to deploying codes to debugging code and It's mentally difficult for humans to do more than two tasks At the same time without losing about 33% in productivity lots of research stats out there on that and Why don't we enforce our whip limits to protect ourselves from that this goes back to the usage of Kanban going through the system And what you're trying to actually get to is a pull from the right mentality where we're actually going towards Tickets and code that is as close to being released to the customers We can can I help deploy it? Can I help review it? Can I help test it? Can I help pair programming and can I help write a new feature? That's the kind of mentality we should be doing to try and minimize this waste and then reduce the motion and increase the flow through the overall system The fifth waste is overproduction and that's the worst kind of waste from a lean perspective because it is a root cause of other wastes It obscures the need for improvement because we think we're doing the right thing by producing more and How could that happen? Well, we produce faster than required or faster than our consumer wants and What can cause this from a pure lean perspective is this forecasting? We're thinking we'll deliver X and we deliver X plus one and unbalanced teams can cause this where you have Way too much being produced at an early part of the value stream and it causes issues further down, but ultimately One part of the overall stream working harder and faster than other parts could actually create an overproduction scenario because they're Forcing the pace on the team and I can put a lot of pressure at a people level as well Or they feel under pressure to perform at the level of the fastest person in the team Now from a scrum lens I mentioned the team ratio has been off the typical 5 to 1 ratio for engineering in QA straight away We're in a dangerous area where we're going to produce too much code That will run the risk of the quality regressions and quality is everyone's problem, but do teams view it like that? Estimates right so scrum guy it actually doesn't mention estimates per se or story points They allude to it and teams will use it for velocity, but rarely do teams complete exactly what they committed to and More often than not they pull in new work into the sprint because typically when they're under performing They reduce what they want to commit to and they end up reducing it too low Which means they overproduce as natural sprints and progress and that can have a Mental impact on the team as well that they're not feeling they're delivering the value and they're missing their goals Which questions they're buoyant the scrum the process and so on Now extra functionality that's potentially not captured by acceptance criteria also causes this because it creates this bigger maintenance footprint Which are dev ops folks have to actually maintain The great example I use for the extra functionality you're after being tested as a calculator It's just addition and multiplication the customer wants nothing else But smart engineers are smarter they'll say well subtraction and division is just an inverse operation I can quickly give that functionality and that's not in the acceptance criteria That's not in the brief and what we've done is created more pressure on the whole value stream because QE Now have something else to review dev ops have something else to deploy and our customers gotten something for free I don't think the business folks like giving customers something for free So the over eagerness of an engineer and not adhering to the acceptance criteria You can actually cause overproduction issues and with the best of intent, you know, it's not done maliciously by any means The sixth waste is inventory so stock being held and not used in a just-in-time manner If you're storing stock is costing you money because you have to allocate room for it You have to make sure it's Refreshed you have to make sure it's rotated to make sure that the oldest stock as he was first so the things are going off for example in the food environment and This cannot just be at the end. It can be before or after a process So it can be in the middle of the value stream and that causes this flow problems when bottlenecks are in place looking at that from scrum and The first place where I look for inventory is the backlog and there's this little slow Which looks at true push which is defined by your work in progress by your cycle time The great example they use is if you're in Starbucks wanting to buy a coffee. There's six people in the queue There's two people serving. It takes a minute per person to get served You know, you're going to get served in about three minutes time. If you look at your backlog Can you tell me the littlest law for your backlog? When will you exhaust your backlog? Most teams have a backlog that will probably stretch to two years. That doesn't sound very agile That's a lot of waste from a human development perspective going in to look at specifications to break down work That probably won't be considered for 18 to 24 months and anyone that works in the software industry will know that is a very long time So try and put a work in progress limit on your backlog to try and Focus on the real value in front of you and not waste time on effort that probably won't be valid and will need to be revisited down the line Scrum and partially done work is always a debate that you see at conferences, right? So incomplete items in the sprint should be returned to the backlog Are they reevaluated? What have we learned? What can we pull from it? Will we guarantee we'll do it in the next sprint, especially if you're running team at experience There's no guarantee that you will take that item and finish it and that's waste because you're now storing incomplete work I'm storing that ticket still on your backlog The work in progress that it can cause poor flow Because user stories can be held for review and batches in between process stages So when you are in progress on an item you want to progress it to the next stage where it's ready for review and People don't know on the context switch straight away to grab that and run it through the system They might wait till 2, 3, 4, 5 tickets are available to have a review afternoon or review a couple of hours And that hampers flow through the system to protect themselves from context switching The seventh waste is extra processing and what Linian talks about is doing the minimum amount to match What's useful and needed so not going beyond it not putting additional decorations on it and one of the big problems That has emerged here is standardization And the lack thereof in many industries So if you have a standard or best practices approach and minimizes the extra processing And the specification which is again a reoccurring team from a waste perspective Is what often causes extra processing because you think you've completed what was asked you get clarity on it And you have to do extra work then to finish and get it over the line Looking at that from Scrum Scrum actually requires help from XP and others to minimize extra processing Because of this concept of any member the team and being able to take work and complete it That means that you could work on something in a silo And then your colleague could pick up an equivalent ticket another few sprints later And work on it in a silo unaware that there was knowledge gained and unaware that there were specific Use cases that they should have known about that requires extra relearning. That's an extra processing step So payer or mob mob programming depending how much you buy into that Is what can be used to break down knowledge silos to try and Identify opportunities where we can avoid having to learn the same problem by looking at a unique bug or a unique scenario That you have domain knowledge about And what often happens there is the person that has the domain knowledge will keep picking that bug up until they're out on holidays Or they left the company and then you're relearning again And the specification balance right that problem again. Um, how do we solve it? That's the million dollar question about getting the specification nailed with the right acceptance criteria. Um, that we don't do extra processing Longer term maintenance is one of the definitions of extra processing and software Scrum doesn't speak to this right scrum will try to tell you put everything on your backlog, right? But artifacts need to be generated for long term maintenance. CVEs are a problem End of life for life cycle and dependencies that you have are a problem So making sure that you're have an upgrade pack for your software to stay at the latest and greatest and make sure you have the right level of support That's often break into the definition that done versus becoming a standard user story And that extra processing often forms that 20 ratio that people try to gravitate towards to fix these problems Instead of making them a primary citizen, um and make it part of the long term maintenance of your overall software suite The eight waste is actually not part of the Toyota production system. It's the underutilization of talent and what that looks at Um, is not getting the most out of your workforce red had a this fantastic OPT model Which is organization passion and talent where if you get people with the right passions The right skills and talents and put them in the right role that intersection point is what their career best is And what leon attributes this towards is the separation of management and employees these rigid processes that are in place And a lack of challenges for people who are working And from a scrum perspective scrum doesn't recognize the manager role and that becomes a separation of concerns because the manager is disconnected from the team And that lack of a day-to-day pulse for guidance and career changes can harm people over a longer period of time It can lead to one-on-ones with your manager becoming a conversation to update the manager on the inner workings of the scrum team Versus that person's career opportunities And you'll often see that the manager has missed an opportunity Because they're not there observing or having the ability to observe what's going on to make recommendations at a career level If you follow scrum by the book the retrospectives stay within the framework They don't want to break scrum But agile is so rich that teams should look beyond scrum as a framework to look at what complements well and solves their problems around it That means people don't innovate that means they don't want to look beyond it because scrum is saying hey stay in your lane This is what you're going to do And another question that I think everyone should ask in their in their teams when they go back after this is is how Involved are the team in the vision and direction is work handed down or can ideas bubble up? Are your team considered a stakeholder? I know my teams are and that's something that I believe is rare based on conversations with other people in this area So your team should be able to bubble up ideas and help set the direction that it's going on because that's how you get smart people engaged And that's what you pay smart people to do And just a quick whistle tour of um lean tools and approaches that you can apply Embrace Kanban a lot of people embrace it for the visuals But please look at it from a work in progress limits pull from the right to minimize that context and increase the flow What about your ceremonies? How many people are idle? Can you streamline them? Can you get the technical experts to? disconnect Run it on their own Share the knowledge asynchronously or find a different way that does not pull intent people into a call For an hour to sit down and have someone talk through a problem or an issue Reveal your backlog. Um, can you exhaust it in six sprints? What is little is law telling you? How much runway do you have? Forced those value conversations to make people really question whether an item should get on the backlog or not And I really would like people to consider empowering their team innovate influence the backlog Get all of your maintenance bugs technical debt as primary citizens. They should be up there with user stories. So you can help Wall off issues before they become an issue for the team because that's mentally draining on people I did a pandemic with everyone working from home. We don't need that level of stress when we can prevent it by minimal tweaks That is me. Um, my email is elgryphon at redhat.com. I'm on twitter at the griffin as well I'm just exploring this lean area. I'd love to hear your thoughts. I'm happy to take questions here On the discord after it or over email or on twitter as well And I hope you enjoyed it and got some value from it today. Thank you very much Thank you very much Lee And we have one more questions in the q&a section. So do you want to answer it now? We still have time Okay, so I miss hallway coffee conversations on structure accidental What's your experience in dedicating time for coffee chats? So I can speak from our team experience We have in our calendar placeholders for Social kind of conversations. We have them at an office level even though we're all remote and our team have had virtual coffees We even do things like a pub quiz every couple of months as well to get people together in a social element We have a team meeting every week Where I think the most value in the meeting is before the meeting and after the meeting where people can Get their talk have conversations But creating a means to improve the communication within your team is usually important because that social aspect in computing Will make or break a team It creates that camaraderie where people are willing to to go the extra mile to help each other out And there are so many tools that you can do this with but even having a social chat room Is is so much fun We often have pun battles in our chat rooms with awful puns by people But it gets everyone laughing and it gets everyone talking And we do regular office hours where people can come with a topic And or just come to have a chat and those informal chats then lead to those Really cool bright ideas that that people want to get which is what to me comes out of the hallway Conversations, you know Where you go in just to talk about the weather and how everyone is And you come out of it an idea for a problem that you've been working on because the conversation just naturally happened So force it somewhat Until it becomes normal Thank you And we have we have one more questions there Kenny from Pavel Zielinski Kenny point me on the golden advised reduced Reduced waste on meetings We can't hear you If I have it a hidden mute when I'm not talking And have an agenda And I try not to turn up the meetings with no agenda have a very Clear agenda about what the goals are because a big part of waste is people coming along and Wanting to talk about what they want to talk about but it's not documented the team haven't bought into it People haven't prepared So you might spend the first 10 minutes trying to understand what the problem is So in general if it's an important meeting Send your agenda in advance send any pre reading in advance so people have an opportunity to Upskill on what the topic might be And and when you get there try and time box it as tight as you can So if you see we're running over And don't extend the meeting end the meeting take things asynchronously see what the action points are And every meeting to me should have a defined outcome So we go into a meeting. What is the outcome because you don't want to walk away from it Everyone comes out with a different idea of what the conclusion was And then another meeting is called a week later to rehash the same conversation so really being strict on it and what we've also Used in in red hat certainly is the google calendar feature Which ends 30 minute meetings after 25 an hour long meetings after 50 minutes They give people five to 10 minutes between meetings so they don't feel Rushed or stressed. They can get a coffee. They can use a toilet. They can just get up and stretch, which is usually important And and that's something that we should definitely consider