Search results for: Sprint Retrospective

How to Use Kanban Metrics in Your Sprint Retrospectives

Many teams found the retrospectives is not valuable and want to skip it. Many teams see the retrospectives is just about having fun and playing games. Quite often, I see teams who see retrospectives as a ritual activities. In this video I share how to use Kanban metrics in Sprint Retrospectives to make it more […]

Free Workshop 04: Introduction to Sprint Reviews [Review & Retrospective]

This workshop was delivered on 16th September 2021 and focused on introducing the core concepts of the Sprint Review and its empirical nature. I used a combination of Liberating Structures, Microsoft Teams, and Mural to deliver an interactive session. This session went really well however we had some technical issues on the live stream! Participant […]

I do continuous deliver, why should I Sprint?

Martin Hinshelwood·FollowPublished innaked Agility from Martin Hinshelwood·3 min read·May 17, 2017–Many folks believe that a Sprint is an arbitrary length of time in which you create and release software. They look at their continuous delivery pipeline and say to themselves; “Why would I limit myself to shipping only once every two weeks?”To that I say: “Where in the Scrum Guide does it say that you can’t release every day?”You will not find it, I know as I have looked. I work with many teams that release software on a continuous delivery model of everything from a few hours, to a few days, and often on-demand. Can you say that they are not doing Scrum? Of course not.So why would you want a Sprint at all?A Sprint enshrines your empirical process by providing a maximum delivery cadenceIt increases communication and alignmentIt Adds some predictability to the unpredictable nature of software by evening the batch sizes.A Sprint is a container for planning!As far as the Scrum Guide is concerned you must deliver working software at least every 30 days, but there is nothing to stop you doing it more frequently than that. Indeed continuous delivery and Scrum go together quite well in my experience.A Sprint enshrines inspect and adapt by containing your other feedback loops:Sprint Planning — Inspect the Backlog and Adapt the plan for the next SprintDaily Scrum — Inspect progress and adapt the plan for the next 24hours.Sprint Review — Inspect the Increment and adapt the BacklogSprint Retrospective — Inspect the Sprint and adapt the process.Without a Sprint when would you bring all this together? The Sprint makes the effort required to pull your work together and create a Done increment of software mandatory. It is absolutely crucial to understand that if you don’t at least have working software that meets your definition of done by the end of the Sprint then you are not doing Scrum.If you are an awesome disciplined team then by all means do something that looks a little more like Kanban, but if you don’t have the discipline to follow the rules of Scrum, how would you expect Kanban to work.Communication & AlignmentAn additional benefit of Sprinting is that it gives a cadence that your management, and other dependant teams, can follow easily. If you are coordinating work, then having a common frame of reference, Sprint 231, will aid in communication.Creates PredictabilitySoftware is inherently unpredictable. The standard deviation between the amount of work required for seemingly similar tasks is so big that it is very difficult to gain predictability. A Sprint creates an artificial batch of a fixed size (or at least less varied) with a time boxed Sprint so that you can create that cadence of predictability.ConclusionA Sprint is a container for planning rather than releasing and while Scrum requires that you have a working increment of software at least every Sprint, there is nothing to stop you doing it more often. Indeed the recommendation from Scrum.org is that you not only ship your software at least every 30 days, you should endeavour to do so more often.Scrum.org recently changed its mantra from “Improve the profession of software development” to “Improve the profession of software delivery” to start to enshrine the idea that delivery, to your customers, is no longer optional to get significant actionable feedback that you can reflect on.In short, while the Scrum Guide does not explicitly state it, it is no longer optional to ship your software to production at least every 30 days if you want to stay competitive and build the software that your users deserve.Who is naked Agility Limited — Martin HinshelwoodMartin Hinshelwood is the Founder/CEO of naked Agility Limited and has been their Principal Consultant and Trainer on DevOps & Agility for four years. Martin is a Professional Scrum Trainer, Microsoft MVP: Visual Studio and Development Technologies, and has been Consulting, Coaching, and Training in DevOps & Agility with Visual Studio, Azure, Team Services, and Scrum since 2010 and has been delivering software since 2000. Martin is available for private consulting and training worldwide and has many public classes across the globe.Originally published at nkdagility.com on May 17, 2017.Martin Hinshelwoodinnaked Agility from Martin HinshelwoodGetting started with a modern source control system and DevOpsThere are a number of things that you have to think about when selecting a modern source control system. Some of that is purely about code…8 min read·Nov 10, 2017–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodHow do you handle conflict in a Scrum Team?As part of the Scrum.org webinar “Ask a Professional Scrum Trainer — Martin Hinshelwood — Answering Your Most Pressing Scrum Questions” I…3 min read·Oct 7, 2019–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodWhat my father taught me about Evidence-based Management (34 years before it was invented!)A few weeks ago I headed out to the Scrum.org offices in Boston to participate in training to hone my skills as an Evidence-based…7 min read·Mar 20, 2014–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodThe Dumpster fire of SAFe!SAFe has done irreparable damage to many companies like Volvo & Fitbit. Do not take their case studies at face value!2 min read·Jun 25, 2022–Kevin CooperLean vs Agile — The Alchemy of DevelopmentUnderstanding Lean and Agile: A Comparative Overview9 min read·Sep 21, 2023–1Ahmed BadranHow to Use Jira Product Discovery to Manage Ideas, Build Roadmaps, and Prioritize What to Build…An Example of Using Jira Product Discovery Custom views to build RICE Framework Board.5 min read·Sep 20, 2023–Wilson GovindjiinAgile InsiderTesters have no place in a Scrum team…Know how to succeed with testers in a Scrum team·6 min read·Jan 26, 2024–1Luke PivacinAgile | AdaptHow to Write and Manage Dependencies in Agile ProjectsA how-to guide on creating and managing dependencies.·7 min read·Dec 26, 2023–1Ameer OmidvarinBootcampApple’s all new design languageMy name is Ameer, currently the designer of Sigma. I’ve been in love with design since i was a kid. It was just my thing. To make things…4 min read·Feb 14, 2024–28Jessyvictany5 Best Alternatives to AgileLearn more about 5 different alternatives to Agile development.5 min read·Oct 6, 2023–1

Can the Definition of Done change per Sprint?

I was asked this question today and I think there is a clear answer, however it may change depending on the context of the question. “During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with […]

I do continuous deliver, why should I Sprint?

Many folks believe that a Sprint is an arbitrary length of time in which you create and release software. They look at their continuous delivery pipeline and say to themselves; “Why would I limit myself to shipping only once every two weeks?” UPDATE: Scrum.org just posted my Scrum Tapas – Scrum and Continuous Delivery which […]

Adventures in Scrum: Lesson 1 – The failed Sprint

I recently had a conversation with a product owner that wanted to have the Scrum team broken up into smaller units so that less time was wasted on the Scrum Ceremonies! Their complaint was around the need in Scrum to have the entire “Team” (7+-2) involved in the sizing of the work during the “Sprint […]

Professional Scrum teams build software that works

Martin Hinshelwood·FollowPublished innaked Agility from Martin Hinshelwood·6 min read·Dec 8, 2017–I am always surprised at the number of teams that release undone work to production. I understand that one may need a few sprints, or many if you inherited something nasty, to pay back that debt, but if it’s more then you are not a Professional Scrum Team. The sheer amount of software that I have that is buggy, slow, or just not finished makes me think that there are few Professional Scrum Teams out there!TL;DR;Every organisation has the right to hold their Development Teams accountable for the quality, but never quantity, of the software that they build. Every Development Team should pursue engineering excellence through DevOps practices, automation, and rigorous attention to detail for every release. Working software builds trust with your users and promotes your brand, faulty software encourages distrust and hurts your reputation. Defective software and technical debt are the causes of the current death grip that organisations have to traditional Taylorism based management techniques.Ultimately if your organisation will not let you build software any way you please its because of the shit that you have been trying to get away with delivering in the past. You have work to do to build trust again.Treat your team to a Professional Scrum Developer class to get them up to speed.Scrum teams build quality software that worksWorking software is software that is Free from fault or defect. The Development Team is primarily accountable for quality and delivering working software. While they are also responsible for value delivery, the accountability for that lies with the Product Owner. That means that if there is a choice between delivering value that lacks quality or providing less value that is of higher quality, a Development Team should always choose quality.Since “rules are for the guidance of wise people, and the obedience of fools” I am going to caveat that statement for those that like to latch onto absolutes. Since any software that you build is an organisational asset, and all assets are attributed to the value of your company then that software must exist on a balance sheet somewhere. If you as the Development Team decide to cut quality to make a delivery do you immediately speak to the CFO so that they can accurately reflect that loss of value on the companies balance sheet? Because if you don’t, then knowing or not there is a danger that your organisation is committing fraud by inaccurately reflecting the value of your software! Ultimately the decision to cut quality should only be taken with the full consent and understanding of your executive management team.The decision to cut quality is not one that the Development Team, the Product Owner, or IT management are able to take, it is reserved for executive management.Quality software is not about expectations!Working software is software that is Free from fault or defect, but it does not necessarily meet the Product Owners or stakeholders expectations.It is just not possible for everyone’s expectations to be understood let alone met, and thus it is unrealistic to expect the Development Team to deliver on them. At the end of every Sprint we have a Sprint Review where we invite stakeholders, and the Scrum Team, to pause and reflect on the Product Backlog based on that which was delivered. There you can explore the difference between expectation and delivery and then update the Product Backlog to reflect that difference. The Scrum Team should continuously be investigating the difference between what they delivered and stakeholders expectations so that they can close that gap as much as possible, so while they are responsible for meeting expectations, they can’t be held accountable.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. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment. -Scrum Guide http://www.scrumguides.org/scrum-guide.html#team-devThe Scrum Guide very deliberately does not tell you how to build working software. It only states that its delivery is the accountability and accountability, and responsibility of the Development Team. If you don’t have working software, then you are not yet doing Scrum, although you might be working towards it.So, to define working software we have to look at what working software is not:Known errors or exceptions — if you find a bug then fix it. If it’s too big, then raise it with the PO, and get it on the backlog. To much time is spent managing rather than fixing bugs. Just fix them.Manual Tests — if you have manual tests then you are already working towards software that does not work, or that you struggle to deliver. It is unsustainable to have any manual testing, so get automating.Manual pipelines — in 2017 no-one should be building production code on their local computer, never mind shipping it to production from there. Even if all your build does is package up some files, and push them to an FTP location. Automate your build process… If you have a person that has to do something more than approving between code and production, then you should look to automate that process away. Humans make mistakes, and humans miss stuff. At least with an automated process if not continuous delivery, you get consistency, and you can increase the complexity over time for consistency. Make sure that you automate both your build and release pipelines.No Source Control — Yes, I still meat organisation with no Source Control, or no control over it. I wrote Getting started with modern source control and DevOps for just that reason. If you don’t even have source control, whatever you are developing, then you need to get help and quick. The business risks that are exposed by not having it are just too big.Lack of feature flags — It is a fundamental fallacy of the rejected backlog item, and your engineering team is going to have to figure out how to release at the end of every sprint (or every commit) regardless of the quality of the PBI’s being worked on. Hide features that are not completed behind feature flags so that they are not visible to end users, but your code can still be shipped.The other name for the things that make it difficult to get to working software; Technical Debt. All of the things listed above are forms of Technical Debt, but the biggest form is just poor quality code. Code that is not tested or would not meet even a cursory code review by another software engineer.What happens if the Development Team is not accountable for Quality?If the Development Team is not held accountable for quality why do you believe that you have it? Quality is one of those hidden measures in software that can be there or not, and you would not know unless you were using that product in anger. If you put pressure to deliver on a Development Team, they will consistently and increasingly cut quality to meet whatever ridiculous deadline you give them.Use Scrum to Inspect and Adapt empiricallyEvery organisation needs to focus on delivering quality working software that is of use to their customers. The first part is owned by the Development Team, the second by the Product Owner. This Professional Scrum Team then works together over many iterations, experimenting and continuously improving, to deliver the best possible outcome in the circumstances. So instead of being an amateur team, be a team of Professionals that deliver working software because that is what your organisation and your customers deserve. If you are having a hard time delivering then discuss your options anytime, but especially at your Sprint Retrospective, and figure out what actionable improvement you can make that will help you pay back some of your technical debt and move forward. Once such step could be making sure that your Development Team at least understand this with a Professional Scrum Developer course.Use empiricism to Inspect and Adapt with Scrum.Who is naked Agility Limited — Martin HinshelwoodMartin Hinshelwood is the Founder/CEO of naked Agility Limited and has been their Principal Consultant and Trainer on DevOps & Agility for four years. Martin is a Professional Scrum Trainer, Microsoft MVP: Visual Studio and Development Technologies, and has been Consulting, Coaching, and Training in DevOps & Agility with Visual Studio, Azure, Team Services, and Scrum since 2010 and has been delivering software since 2000. Martin is available for private consulting and training worldwide and has many public classes across the globe.Originally published at nkdagility.com on December 8, 2017.Martin Hinshelwoodinnaked Agility from Martin HinshelwoodGetting started with a modern source control system and DevOpsThere are a number of things that you have to think about when selecting a modern source control system. Some of that is purely about code…8 min read·Nov 10, 2017–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodThe Dumpster fire of SAFe!SAFe has done irreparable damage to many companies like Volvo & Fitbit. Do not take their case studies at face value!2 min read·Jun 25, 2022–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodHow do you handle conflict in a Scrum Team?As part of the Scrum.org webinar “Ask a Professional Scrum Trainer — Martin Hinshelwood — Answering Your Most Pressing Scrum Questions” I…3 min read·Oct 7, 2019–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodRelease planning and predictable deliveryMany organisations wrestle with the seeming incompatibility between agile and release management and they struggle with release planning…10 min read·Dec 29, 2017–Mike Borozdininmanaging-software-teamsThe Death Of ScrumI remember in 2001 when I first heard about Agile software development and Scrum. It was a free lecture by one of the early Agile software…4 min read·Feb 12, 2024–3Jessyvictany5 Best Alternatives to AgileLearn more about 5 different alternatives to Agile development.5 min read·Oct 6, 2023–1Zombie Scrum ResistanceinThe LiberatorsExperiment: Create A Low-Tech Metrics Dashboard To Track OutcomesAn experiment that encourages teams to select their own metrics4 min read·Oct 16, 2023–Susan TangIs Agile Dead?Cliff Burg’s post on LinkedIn, R.I.P Agile, went viral online. In his post, he stated that finance company Freddie Mac has let go of 75 of…4 min read·Jan 28, 2024–5Code with MesfinMy quick Note on Scrum FundamentalsScrum Fundamentals11 min read·Mar 10, 2024–Willem-Jan AgelingBeyond Agile — 7 lessons from the Agile eraTo navigate away from rigid frameworks·4 min read·Mar 10, 2024–2

A better way than staggered iterations for delivery

Martin Hinshelwood·FollowPublished innaked Agility from Martin Hinshelwood·6 min read·Dec 11, 2017–There is a better way than staggered iterations for delivery that will keep you on the path to agility. Staggered iterations lead to more technical debt and lower quality software.TL;DR;The expected result of staggered iterations would be an increase in rework and in technical debt. If you are moving from a 4-year iterative process to a 4-month one you will see the value, but your process will be opaque and will only reduce your ability to deliver working software.Yes, your cycle time will be reduced, but you can do so much better. Move all requirements for shipping your software into your Sprint. If you need testing then it needs to be inside of the Sprint. A general rule is that:If you need to validate something outside of the Sprint; User Acceptance, Security audit, regulatory aproval; Then you need to make sure that all of the work required to pass that outside validation is doing inside of the Sprint, with no further work required from the development team. –Martin HinshelwoodFor example, this means that if you have 6 weeks of animal trials, followed by 6 weeks of human trials to validate that your pacemaker firmware is good, you cant have those things happen inside of every 2 weeks Sprint. Instead, focus on what you can do to make those things pass. If they don’t pass then do a full route-cause-analysis and bring that new information to your Sprint Retrospective and make sure you put measures in place to make sure it does not happen again.I have seen many companies that are trying to move towards greater agility get trapped in the past by creating artificial silos based on skills. They believe that by creating a timbox for planning, development and testing that we can get closer to agility and move away from our traditional models. Unfortunately, the actual result is to enshrine that traditional staged model and step sideways on the path to agility, not forwards. In many cases, it can be a significant step backwards that will take many painful years to rectify.Figure: Example of staggered iterations for deliveryI have heard this called many things. Water-Scrum-fall or maybe Scrummerfall but whatever you call it the reality is that this is just small waterfalls and in the case above not really that small at all. This is often how organisations respond when they are told to “do agile” and they end up figuring out how to not really change, and do the same thing that they have always done.This is not the action of a Professional Scrum Team, but that of, at best amateurs and at worst cowboys.The problem with staggered iterations for deliveryIn the diagram above we have an 18 week cycle from inception to delivery. That’s more than 4 months between ideation and delivery with a lag of 2 months to even get feedback with a 2 month lag for all subsequent feedback. Worse this is the most expensive kind of feedback as the Coding and Testing teams have already moved on from the thing that is getting feedback and the result of that feedback will be more expensive to implement. Indeed worse yet if QA finds something that needs fixed we have maximised not only the cost to fix but the mean time to repair as the developers have moved on. And what do they do with that feedback? How is it prioritised? Do they quit what they are doing immediately and fix the previous iteration or do they wait until after they deliver this one? What if they are blocking QA? Does QA sit around till the end of the iteration after the one they reported the problem in?The solutions to staggered iterations for deliveryWe need to foster teams over individuals and make those teams responsible for the delivery of working software. To get that we need cross-functional teams that can turn ideas into that working software. And we need to do it often.Cross-functional teams — We need to have everyone on the Development Team that is required to turn the Backlog Item into working software. If you were a property developer you would have access to joiners, plumbers, plasterers and electricians. You would create a team of individuals that was sufficient to complete the daily work on site with experts on hand as needed. This is the same process for a Development Team. You should have all of the skills that you require on each team to turn the forecast backlog items into working software each and every iteration. Have experts on hand for those tricky items but minimise the dependency that you have on them.Asynchronous development — Ideally you want all of the disciplines that you need to complete each backlog item to work together to deliver the software. This is more than handing off between disciplines but moving towards everyone always working at any point in time. This is a hard one to achieve but is the responsibility of the team to figure out how; To achieve asynchronous development you will need a modern source control system.Test first — Test first is about not doing any work unless there is a measurable test that elicits that work. Creating tests from acceptance criteria will make sure that your team is working on and understands the next most relevant thing to be worked on and that you have built what the customer wants. Additionally, creating unit tests before code will make sure that your coders are working on the most relevant problem, and that each line of code that they complete does exactly what they intended. The long term benefit of this is that we now have an executable specification that will result in an error if a future change breaks existing functionality. You are doing it wrong if you are not using test first.Working software each iteration — If you don’t create working software at the end of each iteration you have no way of knowing what really needs to be done to create a working increment. If you do four iterations of two weeks before you think about creating a working increment, how much work (re-work really) is left that you need to complete to really be done? To really have shippable quality? If you don’t have working software at the end of each iteration you are making sure that your business can’t ship out of band, no matter how much it wants to; Professional Scrum Teams build software that works.Quality Assurance requires no testing — If you consider that all testing is done as part of the sprint, then the only thing that needs to be done as part of the QA gate is to review the test results and coverage and determine the sufficiency of those results and coverage. If you are taking more than four hours to QA two weeks of Development then I would suggest that the Development Teams work is not sufficient.These things will all individually help and if you are doing all of them together your value delivery and quality should start to increase over time. Make sure that you focus on automating everything from the moment a Software Engineer checks in code, to it being continuously delivered to production. In the age of agility giving you a competitive advantage in whatever marketplace you are in, any manual work is a risk.Who is naked Agility Limited — Martin HinshelwoodMartin Hinshelwood believes that every company deserves high-quality software delivered on a regular cadence that meets its customer’s needs. His goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals. Martin is the Founder/CEO of naked Agility Limited and is both a Professional Scrum Trainer and a Microsoft MVP: Visual Studio and Development Technologies. He has been delivering software since 2000 and has been Consulting, Coaching, and Training in DevOps & Agility with Visual Studio, Azure, Team Services, and Scrum since 2010. You can reach Martin on hello@nkdagility.com.Originally published at nkdagility.com on December 11, 2017.Martin Hinshelwoodinnaked Agility from Martin HinshelwoodGetting started with a modern source control system and DevOpsThere are a number of things that you have to think about when selecting a modern source control system. Some of that is purely about code…8 min read·Nov 10, 2017–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodHow do you handle conflict in a Scrum Team?As part of the Scrum.org webinar “Ask a Professional Scrum Trainer — Martin Hinshelwood — Answering Your Most Pressing Scrum Questions” I…3 min read·Oct 7, 2019–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodWhat my father taught me about Evidence-based Management (34 years before it was invented!)A few weeks ago I headed out to the Scrum.org offices in Boston to participate in training to hone my skills as an Evidence-based…7 min read·Mar 20, 2014–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodThe Dumpster fire of SAFe!SAFe has done irreparable damage to many companies like Volvo & Fitbit. Do not take their case studies at face value!2 min read·Jun 25, 2022–Vaishnav ManojinDataX JournalJSON is incredibly slow: Here’s What’s Faster!Unlocking the Need for Speed: Optimizing JSON Performance for Lightning-Fast Apps and Finding Alternatives to it!16 min read·Sep 28, 2023–167Alexandru LazarinILLUMINATIONTen Habits that will get you ahead of 99% of PeopleImprove your life and get ahead of your peers in 10 simple steps9 min read·Nov 18, 2023–391Artturi JalliI Built an App in 6 Hours that Makes $1,500/MoCopy my strategy!·3 min read·Jan 23, 2024–166Gowtham OletiApps I Use And Why You Should Too.Let’s skip past the usual suspects like YouTube, WhatsApp and Instagram. I want to share with you some less familiar apps that have become…10 min read·Nov 14, 2023–353Julie ZhuoinThe Year of the Looking GlassAverage Manager vs. Great ManagerExplained in 10 sketches2 min read·Aug 11, 2015–306Tamás PolgárinDeveloper rantsAgile has failed. Officially.Either I’m a gifted oracle, and all of my friends are, or Agile really was just a stupid idea to begin with. After many years of agony…2 min read·Dec 2, 2023–487

Release planning and predictable delivery

Martin Hinshelwood·FollowPublished innaked Agility from Martin Hinshelwood·10 min read·Dec 29, 2017–Many organisations wrestle with the seeming incompatibility between agile and release management and they struggle with release planning and predictable delivery.TL;DR;Without working software, you cant build trust and you don’t know when you will get the next piece of working software.Any software that you create is an organisational asset and decisions to cut quality need to be reflected in your company accounts and as such those decisions need to made by your executive leadership and should not be made by the Development Team. Once you accept this, and quality becomes non-negotiable, your Development Team can focus on creating shippable increments of working software. Once you have shippable increments of working software you can then start to look with interest at the progress being made on features and goals.Without a regular cadence of delivery of working software any belief that you will get working software is misguided at best. Professional Development Teams create working software.The incompatibility between predictable delivery and agility is fictitious (tweet this) and while usually created by an organisation and structure that is unwilling to let go of the old ways and embrace the tenants of agile it can also be the result of a Teams fervour to divest themselves of all things that smack of prior planning. There is a lack of understanding that agile and the path to agility is far more than just a change in the way that you build software, it is a fundamental shift in the way that you run your business. Much like the lean movement in manufacturing, companies that embraced it wholeheartedly were the ones that ultimately see the competitive edge that it provides. If one is unwilling to let go of the old ways then one can’t attain the value of the new. This change will take hard work and courage as the fundamental transparency required to inspect and adapt effectively is at odds with the measures of the past. The lack of predictability of software development is the key to understanding the new model.Why is software so unpredictableAll software development is product development. In lean manufacturing, we can optimise the production of pre-developed products through the nature of its predictable production. Each unit of work takes the same amount of materials and time to produce so any changes that we make to the process, time, or materials can easily be qualified and the benefit demonstrated. Manufacturing lives in the predictive world.With software everything that we create takes its own amount of time: You can really only know how long something took after it has been completed. Even in manufacturing if you asked an engineer how long it would take to develop a new type of unit of work they would not be able to tell you with any certainty. Once they have developed it however they can tell you exactly how long it will take to make each one, and then systematically optimise the process that you use to make it. In software development we are always doing new product design, therefore, we have no certainty…and this often results in chaos. Software lives in the empirical world.All is not lost however as we can, by looking at our history of delivery for similar things, make a pretty good forecast…The best thing we can then do is to expend effort to make that forecast as accurate as possible while accepting that more time spent planning does not necessarily affect the accuracy of that forecast.Figure: Diminishing returns from Agile Estimating — Estimation ApproachesUltimately Software Development is a creative endeavour and has the same lack of predictability that painting a picture, writing a book or making a movie has. Yet movies get made all of the time. How can that possibly be! Well they have a Director (Product Owner) that has a bunch of money and a plan for delivery, a Producer (Scrum Master) to make sure that everyone has the skills, knowledge and assets available at the right time and place and one or more Units (Development Teams) that have all of the skills necessary to turn the Directors ideas into a working movie. They create Storyboards of what they expect to create so that they can run it past the stakeholders and get feedback. They take those storyboards to the Units who collaboratively work together with the stunt, prop, lighting, camera, sound and wardrobe crews to get estimates and costs and ultimately coordinating to create the movie. Sometimes they don’t know how to do stuff, and just have to have a go and see what they get.Making a movie is just like building software, you need a budget, you need a plan, and you are trying to reach a ship date. And just like building software you have to make money at the end of the day so that you can do it all over again.Accept the lack of predictabilityWhile I hope by now you understand that the lack of predictability is part of the nature of building software, there are many things that we can do to lessen the impact of that chaos. Indeed if you were to estimate all of the discreet things that you need to do to achieve a goal (let us call them backlog items) in Small, Medium and Large what would your standard deviation of actual hours be? I would wager that it is fairly large. So large in fact that at least half of all mediums would be more accurately classified as Large. But that reclassification can only be done with hindsight. This is indeed one of the tenants of the No-Estimates movement, as really there are only three classifications of size: trivial, fits in a Sprint, or too big to fit in a Sprint.This difficulty in estimation is normal for organisations that move towards agility as the transparency that it brings uncovers these sorts of problems. In order to increase the accuracies of our forecasts, there are a number of simple activities that we can perform. These activities, while easy to understand, are very hard to do as they require a culture shift within your organisation as well as the courage of the participants to make them work.Focus on continuous qualityMost software lacks quality for the simple reason that you can not easily see the quality in software like you could with a table or a painting. I am not talking about the quality of the User Interface, but the quality under the covers; the quality of the code.If you put developers under pressure to deliver they will continuously and increasingly cut quality to meet deadlines.-Unknown (Tweet this)A lack of quality of the code results in an increase in Technical Debt (or more accurately an unhedged fund) which in turn results in two nasties. The first is the teams increasingly have to spend more time struggling with the complexity of your software rather than on new features. If you are still pushing your teams to deliver the same feature level every year you are only encouraging them to cut more quality and thus incurring more technical debt which becomes a vicious cycle. The second is an increasing number of bugs found in production. Bugs found in production also directly impact on the number of features that the team can deliver and any bug, no matter how small, costs ten times and much to fix in production than it does in development.The only way to handle technical debt is to stop creating it, and then pay a little back each iteration. If however, you are so drowning in technical debt that you cant create working software at the end of the iteration then:Create a short measurable checklist that mirrors minimum releasable product (Defenition of Done)Stop adding new features and make your product meet that checklist and release your productWhile you have an increment of working software (Sprint)— — Work to create something of value (Increment)— — — — Work towards a new goal while meeting the DOD (Sprint Goal)— — — — Leave things better than you found them (Engineering Excellence)— — Review that thing of value with your stakeholders (Sprint Review, Backlog Adaption)— — — — Get feedback on at least one new thing for stakeholders— — — — Update the Backlog to reflect this new information— — Reflect on how you worked with your entire team (Sprint Retrospective, Kaizen)— — — — Is quality increasing?— — — — Is the DOD increasing?— — — — What can we change to make things better?Go to #1You can call the activity that results from dropping out of the while loop of working software to be a Scrumble; You need to stop piling more features on top of the features that don’t work and fix things so that you can make new things. Ultimately professional teams build software that works.There are a number of strategies that can help you both stop creating and start paying back technical-debt:Sufficient requirements — If your backlog has things in it that are too big or too vague then your team will not really be able to understand them and this, in turn, creates a multiplier for uncertainty. Follow the INVEST (Independent, Negotiable, Valued, Estimable, Small, Testable ) model for every single thing that you ask the team to deliver. If you invest in you backlog in this way you will find it much easier to deliver the contents and thus predict that delivery. This will require you to spend a significant amount of time in refinement. Backlog refinement is key to facilitating a flow of actionable Backlog Items to your team.The Development Team chooses what they can deliver — this implies that the Development Team can reject any item on the backlog that they do not understand. If we accept that every Development Team is trying to do their best to deliver for their Product Owner then the only reason to reject anything would be if an item is too big or does not have enough detail to understand. These Backlog Items can be put on the queue for refinement and refined over the next Sprint. Remember that there is no such thing as a rejected backlog item, only actionable feedback and continuous improvement.Definition of Done (DoD) — Along with having sufficient requirements the single biggest blocker to predictability is a lack of common understanding of DONE. Done for a Development Team should equal what it means to complete an item with no further work required to ship it. If you cant ship working software then you need to stop sprinting, Scrumble, and focus on getting your software into a shape that can be delivered in a Sprint.Test First — Focus on Test First practices like TDD or ATDD to help you make sure that not only did your engineers build what they expect, but that you ultimately built what the customer expects.Fixed length iterations — If you have variable length iterations you can’t be sure what you can do in a particular timeframe. How much decomposition do you need to do to the backlog? How much can the team deliver in a single iteration? You can’t be sure unless you have fixed length iteration, and you reject the idea of staggered iterations.No separate teams — This means no separate test teams, configuration management teams and definitely no separate maintenance teams. Its hard for folks to grasp, especially with the recent focus on DevOps but if you have separate teams then why would your Development Team, those best placed to fix any problems, care about the problems of other teams. The most successful organisations at creating software have development teams that own the entire application lifecycle (Amazon AWS | Visual Studio.)Manage dependencies — Managing dependencies is a hard task and my advice would always be to minimise the number of dependencies that you have. A Development Team should have all of the skills required to deliver what you want at the quality level that you want. So if you need to have productionised databases or scripting for production delivery then you might need a DBA or an Operations administrator or two. This can be hard for many teams or organisations but you will have far less success creating silos like Configuration Management or DevOps. Rather add those individuals that you need to the team. However, if you have a dependency on a separate team, maybe you have an application upon which all of your other applications depend, then you may need another way. This is not a silo of types of individual skills, but of a domain and that team just has something in their backlog upon which you are dependent. It is up to the team’s respective Product Owners to fight negotiate over when these things get done.Use a modern source control system — A modern source control system is more than just code management, it should include all of the goodies talked about in DevOps practices and beyond.If you can, do them all, and many more…Who is naked Agility Limited — Martin HinshelwoodMartin Hinshelwood believes that every company deserves high-quality software delivered on a regular cadence that meets its customer’s needs. His goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals. Martin is the Founder/CEO of naked Agility Limited and is both a Professional Scrum Trainer and a Microsoft MVP: Visual Studio and Development Technologies. He has been delivering software since 2000 and has been Consulting, Coaching, and Training in DevOps & Agility with Visual Studio, Azure, Team Services, and Scrum since 2010. You can reach Martin on hello@nkdagility.com.Originally published at nkdagility.com on December 29, 2017.Martin Hinshelwoodinnaked Agility from Martin HinshelwoodCan the Definition of Done change per Sprint?I was asked this question today and I think there is a clear answer, however it may change depending on the context of the question.4 min read·Oct 14, 2019–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodThe Dumpster fire of SAFe!SAFe has done irreparable damage to many companies like Volvo & Fitbit. Do not take their case studies at face value!2 min read·Jun 25, 2022–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodI do continuous deliver, why should I Sprint?Many folks believe that a Sprint is an arbitrary length of time in which you create and release software. They look at their continuous…3 min read·May 17, 2017–Martin HinshelwoodinSerious Scrum80% of communication is non-verbal | naked Agility with Martin HinshelwoodIn light of the new normal and the last 20 years of technological progress, we need to re-define co-location as we no longer need to be in…6 min read·Jun 28, 2020–Valerio ZaniniinAgile InsiderSystem Story and Job Story formats: Not everything is a User StoryThe System Story and the Job Story are two alternative formats to describe Product Backlog Items (tasks in a backlog) when the User Story…4 min read·Sep 15, 2023–Neeraj KushwahaDemystifying Agile and ScrumIn the dynamic landscape of project management, traditional methodologies often fall short in adapting to the ever-evolving requirements of…7 min read·Feb 4, 2024–Alexandra Turian8 easy steps to create a Jira story template for issue descriptionLet’s enhance our approach to refining user stories and address Jira issues with precision. 🚀·5 min read·Nov 28, 2023–eiki9 Patterns of User Story SplittingOne of the biggest challenges in Agile Product Backlog management is how to split a User Story. While one of the important practices in…5 min read·Jan 30, 2024–6OTTO TechinOTTO TechHow to setup a Kanban board in Jira using sub columnsThe team that I am part of is very used to Jira Scrum boards but recently decided to give Kanban a try. Since our tickets are all setup in…5 min read·Oct 4, 2023–2Barry OvereeminThe LiberatorsA Quickstart To Improve Team MoraleThree simple retrospective formats based on the Liberating Structures “Conversation Cafe”, “Troika Consulting”, and “Discovery & Action…9 min read·Nov 14, 2022–