Martin Hinshelwood

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions.

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to.

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to. In case you missed it, here is the recording of yesterday's Ask a Professional Scrum Trainer webinar with Martin Hinshelwood! Watch here: http://ow.ly/ijiM50vwEkD [Question] Are technical skills required to be a Scrum Master? As per the Scrum Guide, there are no requirement for a Scrum Master to have technical skills. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. -The Scrum Master, Scrum Guide When I discuss the Scrum Master in class and with customers I talk about them as being someone that can be a Teacher, Mentor, Coach, & Facilitator for your Scrum Team. So let's ask a question: If you were the Scrum Master for a Scrum Team building some financial software for a bank, how would you expect to guide and mentor the Product Owner without some understanding of what their challenges are? Oh, you can coach them, one does not need expert knowledge of the problem to coach a subject. The Product Owner is the one that knows the answer, the Scrum Master just needs to facilitate their own discovery. That is only part of the Scrum Master role, I also need to teach & mentor the Product Owner to become better at realising value; for that, I need to have an understanding of the context within which they operate. I think that while you can be a non-technical Scrum Master, you can be a better Scrum Master with more knowledge of the context for each of the roles; you need more than technical skills! In order to be an awesome Scrum Master you are going to need 3 main masteries that you can leverage to help each of the roles, as well as the wider organisation: Technical Mastery – While I would not expect a Scrum Master to have to be able to do everything that the Engineering team members can, they need to understand what the mastery of that profession looks like as well as the context within which the engineering team are practising. For example, they should be able to tell if TDD is appropriate for this team, what does it look like, and if so, are they doing it well. There are a wide range of engineering practices that I would expect a Scrum Master to guide the team towards which include, but is not limited to: Pair programming, (A)TDD, Refactoring, UI testing, Functional testing, Continuous Integration (unit, deployment, build, integration, regression, … tests), Performance testing. How would they change their approach if the technical team was at Boeing, or if it was a call centre line-of-business app? Scrum Master Service to the Development Team The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality; Helping the Development Team to create high-value products; Removing impediments to the Development Team’s progress; Facilitating Scrum events as requested or needed; and, Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood. -The Scrum Master, Scrum Guide Without technical mastery, I think it would be very difficult to help the development team build high-value products. Business Mastery – The Scrum Team, and especially the Product Owner need to understand the business, and how they can optimise the product they are delivering to best support it. Does everyone understand the product qualities that are required within their context? Do you have Quality code base (clean, readable, naming conventions), Valuable functionality only, Architectural conventions respected, According to design/style guide, According to usability standards, Documented, Service levels guaranteed (uptime, performance, response time)? How would you help the Scrum Team get better at meeting the business goals without a keen understanding of what those are? Scrum Master Service to the Product Owner The Scrum Master serves the Product Owner in several ways, including: Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible; Finding techniques for effective Product Backlog management; Helping the Scrum Team understand the need for clear and concise Product Backlog items; Understanding product planning in an empirical environment; Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value; Understanding and practicing agility; and, Facilitating Scrum events as requested or needed. -The Scrum Master, Scrum Guide Without business mastery how could the Scrum Master ensure that the backlog maximizes value; without the context of the business how can they ensure that everyone understands the goals, scope, and domain? Organisational Transformational Mastery – Have you ever tried to change an organization without really understanding the structure, people, and history that led to the current culture and organisation? This is why so many organisational transformations fail. If the Scrum Master really understands the organisation, the people, and the key players that need to come together to effect real change then they can make a difference. Without that knowledge, they have little hope of success. Scrum Master Service to the Organization The Scrum Master serves the organization in several ways, including: Leading and coaching the organization in its Scrum adoption; Planning Scrum implementations within the organization; Helping employees and stakeholders understand and enact Scrum and empirical product development; Causing change that increases the productivity of the Scrum Team; and, Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. -The Scrum Master, Scrum Guide Without organisational transformational mastery, and the context of the organisation there is very little likelihood of real lasting change. These masteries for me mean that a Scrum Master needs to be fully familiar with the Technical, Business, and Organisational context within which they are operating and how and when to encourage the Scrum Team to particular practices based on the Scrum Teams and the Organisational maturity. Does it sound to you as if the Scrum Master can be awesome if they don’t have technical, business, and organisational change skills? While there are no right answers there are some answers that are better than others. For your given situation select the most right answer and iteration to the best version of it.

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to.

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to.

Recently I worked with a new customer in Denver to help them move towards a greater degree of Scrum in their software development. The idea that Scrum is for everyone in your organisation is kind of new, but it reflects the modern understanding of the way people work, and the rejection of Taylorism and command and control.

There is nothing in the Scrum Guide that says that you can't have workflow across the Sprint boundary. I'm going to suggest that not only can you, but you should as long as you don't endanger the Sprint Goal. The definition of Done is an instrumental part of maintaining transparency of the past work and is not optional. The Sprint Goal provides focus and direction. In order to maintain flow we need to be able to reduce the batch size of the work, thus we must allow for work to flow across the Sprint boundary. If you have a Professional Scrum Team that is adept at creating Done increments of working software then introducing flow can improve the value delivered by increasing the throughput of the team. Always remember that the Sprint is a container for Planning and not always for Delivery. Just like you can do Continuous Delivery in Scrum, so you can also introduce flow and Kanban. Less skilled teams can also benefit as long as you make sure that you meet the Sprint Goal and Done Increments are created to provide transparency of the past and build trust for the future. Starting Work that the Development Team knows that it can't finish Although you will not find anything in the Scrum Guide that prevents you from flowing work across Sprints you should consider it an advanced technique. Most teams that I work with are not even at the point where they have Working Software at the end of the Sprint and they are often only just achieving their Sprint Goal. I also believed the myth that we could not flow work across the Sprint boundary. It took a long conversation with Steve and Daniel to kindle a different idea, and long discussions over a beer to make it concrete. My argument went; "If you have to be Done by the end of the Sprint then how can you have any unfinished work?" My argument was wrong! I was confusing the need to have a Done Increment with all of the PBI's being finished. If you as a Development Team are practising Continuous Delivery (CD) then they always have working software. I would expect that a team doing CD would have every single element of their Definition of Done (DOD) automated and every Checkin/Pull Request meets the DOD. If that's true, then when you get to your Sprint Review you just show the work that you have finished. If you want Flow then CD is no longer optional for a Software Team let along a Professional Scrum Team. Shipping software with Unfinished work can still be Scrum There are a number of Engineering consideration that a Development Team will need to take into account if they want to focus on Flow. With CD comes the need to validate early and often, with automation, so that you don’t have to stop and check everything manually. There are a number of practices that can help: Feature Flags - Often referred to as Feature Toggles this is a way to insert a switch into the code so that something is visible or not to the customer based on a switch. Advanced toggles might support "controlled Exposure" to customers, as well as A/B testing, and other features. Regardless it is generally accepted that you can't leave all of your toggles in the code indefinitely. Once you have completed the PBI / Feature or tested your hypothesis you need to remove the flag through Refactoring. Refactoring - The act of restructuring or rewriting code for clarity of purpose and future maintenance. One would never write a book or article and then just published it. You would normally do your first pass… re-read it and update for clarity. Maybe get someone else to take a look, and incorporate feedback. Same for code… Test Driven Development (TDD) - Part of the general Test First movement TDD allows an engineer to prove that the code that they wrote fulfils some pre-defined purpose. It’s the only way that a coder can prove that code does at least what they intended. This practice also supports refactoring since I can continue to prove that the code after I change it, does what was originally intended. Many more… All of these are optional complimentary practices that help you achieve CD but it is not an exhaustive list. There are many other practices that will help, try them and see what works for your team. While the Scrum Guide does not say that you need to do CD let alone the practices I have listed above, it does require that you create an Increment of Working Software at least once per Sprint. Anything less and you have no transparency of what was done. With no transparency, you lose your empirical process control, and without empiricism, you are not doing Scrum. Unfinished Backlog Items are not the same as Undone work. How does this impact Scrum elements Within the bounds of the Scrum Framework, you are allowed to flow work from one Sprint to another. The Result is still Scrum if we have working software, and we meet the Sprint Goal. Sprint Review - the purpose of the Sprint Review is to inspect what was just created, review and analysis it, and update the Product Backlog to be an accurate reflection of future work based on this new Increment. At the Sprint Review, we show the work that was completed and discuss what was not completed. It's not a failure if the team did not finish something, software development is complex and that will happen, often. As long as we have an Increment of Done work we have fulfilled our obligation to Empirical process control. Sprint Planning - The purpose of the Sprint Planning event is to inspect the Product Backlog and create a Sprint Goal, Forecast, and Sprint Backlog for this Sprint. Nothing prevents Stories flowing over into the next Sprint unless it prevents the team cresting a Done Increment, or endangers the Sprint Goal. Sprint Goal - The Sprint Goal provides purpose and direction for the team. And that does not mean that we can't have work outside that Sprint Goal inside of the Sprint. We may have production issues, leftover work, or just something super important to the Product Owner that turns up. As long as the team believes that they can achieve the Sprint Goal they can take on any additional work that makes sense. I have found that reading the Scrum Guide carefully, turns up all sorts of miss conceptions that we all have as we interpret and use Scrum. If you are not sure, re-read the Scrum Guide, maintain the Scrum Values, focus on empirical process control and maintain transparency. At the end of every Sprint, you should have working Software that meets your definition of Done and you should have meet your Sprint Goal.

Most Scrum Teams that I encounter don’t do refinement of their Product Backlog and try to work on things that they don’t understand correctly. However, if you get to the Sprint Planning Event and your backlog is not ready, then you are doing it wrong. If what you build is not of good quality then you should read about Defenition of Done. If you get to the Sprint Planning event and your Product Backlog Items for the next Sprint are not already of a size that can fit into the Sprint and fully understood by the Development Team, then you are doing it wrong. You are heading for the rocks from the start, and you have no map of the shallows to prevent it. Although the Scrum Guide does not define Refinement as an Event, you should be doing it. You can come up with your Refinement event(s), or refine ad-hoc. Whatever you chose there is a simple measure of success. If your Development Team looks at something within the next 2 Sprints on the backlog and they don’t understand it, then you have work to do. If you find that you can't quite get things to fit and have to stagger iterations, or you are just not able to deliver at all, then a lack of refinement is usually at fault. What does ready mean for a Product Backlog? If the Development Team does not understand the things that they are being asked to do how could they possibly agree that the items can fit in a Sprint? You will often find teams that don’t do refinement confused as to why they cant get everything done in a Sprint. While we accept that in an empirical process like Scrum that we, know less up front than we discover as we go, merely taking a guess and hoping for the best is decidedly unprofessional. "The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint." -ScrumGuides.org While we don’t need a definition of ready, we do need a working agreement between the Product Owner and the Development Team. If you are following Scrum, then the Development Team are the ones selecting for the Sprint, and they are the only ones that can decide what they can do. The Development Team should be empowered to refuse to take items from the backlog that either they do not understand, or are too big to be completed in a single sprint. In general, I would expect that a team take at least ten items into their Sprint, so they need to be sized appropriately. Ready Backlog just means that the Development Team can select it with confidence. How do you refine your backlog? Refinement is not an explicit event in the Scrum Guide because it is something that can be different depending on the Product, Domain, or Technology. If you were to ask how much refinement you should do then the answer is "as much as you need and no more". Too much Refinement is waste, as it too little. "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion." -Scrum Guide In the Scrum Guide there is the guide that it usually takes not more than 10% of a Development Teams time, and for a two-week sprint, this is reflective of a whole day per Development Team member. 10% may seem like a lot, but not only is it necessary it is a maximum guide and not a minimum. I have found that many teams that were not doing refinement in the past may need considerably more time to get their backlog into some semblance of order. Once it is in order, you are only maintaining a rolling two Sprint projection of what you might achieve. I usually run at least the first refinement as a guided workshop. Run one before a Sprint Planning and most teams will see the value by the end of the next Sprint. For the Workshop, I get the Scrum Team (Product Owner, Development Team, & Scrum Master) into a room with any necessary subject matter experts and we merely open the existing backlog. Start at the top and ask the Product Owner if this is the next most important thing? If not, find something that is. Then have the Product Owner read and explain it. Any time the PO deviates from the text that is in the Backlog Item, or adds more information, stop and have someone add that info to the Backlog Item. Ask the Development Team to estimate the item (will or will not fit is fine too as in #noestimates), "Does this look like it can fit with nine other friends into a single Sprint?". If the answer is no, then you get to work breaking it down, reordering in the Product Backlog, and start refining again. You continue this process until the Development Team agrees that there is enough backlog refined for the next 2 Sprints. This enables your Product Owner to be able to plan future releases and your Development Team to create an execution plan for the current one. How do you monitor your refinement effectiveness? During the Sprint Planning event, your Development Team should be able to quickly select a least 10 Product Backlog Items that go towards the chosen Sprint Goal and agree that they fit. If you can do this, and most of the time you get most (not all) of the Items delivered, then you are probably doing enough refinement. If you can't, then you need to focus a little more on Refinement and making your Product Backlog Ready. If at your Sprint Review the Product Owner is always wanting to reject that Backlog Items are complete then there is unlikely to be enough refinement for the Development Team to understand what they are expected to do.

In my last post about Professional software teams creating working software David Corban made a good point. How do you determine what "Free from fault or defect" means? Since that is different for each Product and may change over time you need to focus on Quality and reflecting that quality in a Definition of Done (DoD). Your Development Team is ultimately responsible for creating done increments of working software. Done Increments. Done. Your Development Team needs to decide what Done means. They need to sit down and create a list of things that must be true for every Increment of software that they deliver. Working Software is not specific to a PBI; it's applied regardless of PBI to the entire delivery. Not just for each PBI. "The increment must be in useable condition regardless of whether the Product Owner decides to release it." -http://scrumguides.org If you can't ship working software at least every 30 days then by its very definition, you are not yet doing Scrum. Since Professional Scrum Teams build software that works, stop, create a working increment of software that meets your definition of done (DoD), and then start Sprinting, and review what you mean by "working" continuously, and at least on a regular cadence. What is a Definition of Done (DoD) You need to start somewhere, and most often we don’t have a greenfield product. Either we are handed an existing product, or we are the team that built it and are switching to Scrum. Wherever your product originated, the code, and thus the product, will not currently be working software. How can it be when you don't have a definition of what working means? So what do you do? Before you cut a single line of code, you need to decide what done means for your product and your company. It will be defined very differently if you are building firmware for pacemakers or if you are creating an e-commerce portal. Here are some characteristics of a Definition of Done: A short, measurable checklist - try and have things on your DoD that can be measured, that you can test the outcome, preferably in an automated fashion. Mirrors shippable - While you might not have shipped your product, although we recommended it, you should have that choice. Your Product Owner should be able to say, at the Sprint Review: "That’s Awesome… lets ship it.". No further work - There should be no further work required from the Development Team to ship your product. Any additional work means that you were not Done, and it takes away from the Product Owners capacity for the next iteration. Ideally, you have a fully automated process for delivering software, and never use staggered iterations for delivery. Your short, measurable checklist that mirrors shippable and results in no further work required to ship your product needs to be defined. I find the best way to do this is to get the Scrum Team (the Product Owner plus the Development Team) into a facilitated DoD Workshop. Without a Defenition of Done we don't understand what working software means, and without working software we cant have predictable delivery. Your Product Owner can't reject a Backlog Item, only whether the Increment is working or not. My first Definition of Done (DoD) Your Definition of Done does not just magically appear, and your software does not magically comply. Making your Software comply with your definition of done is hard work, and while your definition of done should organically grow, you need to create the seed that you can build on. I recommend that you run a workshop with the entire Scrum Team, and likely some other domain experts. If there are Stage Gates that your software has to pass after the Development Team is Done, then you need representatives from those Gates to participate in the workshop. Regardless of your product you likely need representatives with the following expertise; Code, Test, Security, UX, UI, Architecture, etc. You may have this expertise on your team, or you may need to bring in an expert from your organisation, or even external to your organisation. Some examples of things to put on your definition of done: Increment Passes SonarCube checks with no Critical errors - You will be increasing over time, so maybe you need to say "Code Passes SonarCube checks with no more than 50 Critical errors" then work on it over time. Increment's Code Coverage stays the same or gets higher - Looking at a specific measure, like 90%, of code coverage is a read hearing and tells you nothing of code quality. However, it might be advantageous to monitor and measure for adverse change in code coverage, and we always advocate for TDD practices. Increment meets agreed engineering standards - You should decide rules for naming of methods, tests, variables and everything in-between. Start small and add over time. Link to your agreed standards on a Wiki and continuously improve and expand your rules. Automate if possible. Acceptance Criteria for Increment pass - Making sure you at least meet the prescribed criteria is a laudable goal and automating them with ATDD practices is even better. Acceptance Tests for Increment are Automated - Make sure that you automate all of your tests. If you think something will break, then you should have a test for it. Security Checks Pass on Increment - Use an automated tool as part of your build and check for known security vulnerabilities. You will not find all of your security issues, but at least don’t do things we know to be reflective of poor Security. Increment meets agreed UX standards - Again, have a Wiki page and make sure that you check it twice. If you are not using an automated DoD entry, then you need to agree as a Team that you have met the criteria. Increment meets agreed Architectural Guidelines - Wiki's are fantastic for this, but automate what you can. Whatever Definition of Done you come up with it is unlikely that your entire Product currently meets the criteria. You are not yet doing Scrum. Before you start Sprinting, you need to focus on making sure that your current Increment meets your new Definition of Done. Focus on Quality, which is what the Development Team is accountable for, and make sure that your Increment meets that new quality bar before you start. The next Increment can only reach the quality bar of all those that came before do. Create a Working Increment of Software that meets your definition of done and then start sprinting. Keeping your software in a working state will require a modern source control system that provides you with the facility to implement good DevOps practices. Growing your Definition of Done (DoD) It's super important that quality is always increasing, and that means that you will need to at least reflect on your Definition of Done on a regular cadence. In Scrum, this cadence is defined by your Sprint length, and you have a Kaizen moment at the Sprint Retrospective. That does not mean that you don’t reflect on your DOD all the time, you do. You reflect continuously on whether your increment currently meets your DoD, and what you need to do to get it there. You should always be reflecting on whether your DoD fits your needs. If your Development Team finds that something is missing from the DoD halfway through the Sprint, then they should go ahead and add it, making sure that they are not endangering the Sprint Goal. You may discover that you have a performance problem with your product as David Corban pointed out in my previous post. How do we make sure that we fix that issue? As I see it there are two pieces to this once you are in flight. You can Scrumble (stop Sprinting because of poor quality), and fix it, or you can integrate this new knowledge into your product cycle. If it is a significant issue that results in you not having working software, then you need to stop and fix. In Scrum, this is called a Scrumble, as a reflection that the Development Team stumbled because something is missing. You should stop adding new features and create Working Software before you continue Sprinting and adding new features. Once you have repaired the issue, you can increase your Definition of Done to make sure that all future Increments meet the new requirements. If it is less significant, you might want to keep working and add what you need to your Product Backlog. You can then deliver improvements over the next few Sprints that mitigate and then resolve the identified issue. Once you have resolved it, you can then pin the outcome by adding something to your DoD. Always look for ways that you can increase your quality. What does your definition of done look like today?

Many organisations wrestle with the seeming incompatibility between agile and release management and they struggle with release planning and predictable delivery. 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. Release planning and predictable delivery 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 tenets 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 unpredictable All 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 Approaches Ultimately 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 predictability While 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 tenents 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 quality Most 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 as 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 (Definition of Done) Stop adding new features and make your product meet that checklist and release your product While 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 #1 You 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 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's Martin Hinshelwood Martin 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 info@nkdagility.com.