Blog – Martin Hinshelwood – naked Agility Ltdhttps://nkdagility.com
Expert in DevOps & Agility with Visual Studio, Team Services, Azure, & ScrumThu, 31 Jan 2019 11:13:12 +0000en-GBhourly1https://wordpress.org/?v=5.0.3https://nkdagility.com/wp-content/uploads/2014/03/cropped-nakedalm-logo-260-32x32.pngBlog – Martin Hinshelwood – naked Agility Ltdhttps://nkdagility.com
3232DOD has made it illegal to do waterfallhttps://nkdagility.com/dod-has-made-it-illegal-to-do-waterfall/
https://nkdagility.com/dod-has-made-it-illegal-to-do-waterfall/#commentsTue, 01 May 2018 00:02:03 +0000http://nakedalmweb.wpengine.com/?p=10204Did you know that the DOD has made it illegal to do waterfall? For the first time in many years the Department of Defence (DOD) in the United States had made a major update to its procurement rules. They can no longer be held accountable for holding up our industry, and being culpable for its inability to move towards agility. The last vestiges of the old ways are gone.

]]>Did you know that the DOD has made it illegal to do waterfall? Well, kind of… For the first time in many years, the Department of Defence (DOD) in the United States had made a major update to its procurement rules. They can no longer be held accountable for holding up our industry, and being culpable for its inability to move towards agility. The last vestiges of the old ways are gone.

TL;DR;

The benefits of working in an iterative agile process are now painfully obvious to both the FBI as a result of Sentinel and partly as a result to the US DOD.

Higher success rate – you are three times more likely to be successful with agile

Cost Effective – As you always have working software you can stop at any time without waste

Low Risk – You only ever have one short iteration of risk at a time.

In the UK we have government-wide lean-agile initiatives that are producing awesome results already and in the USA lean-agile has effectively become the law.

Deliver Early and Often – This principle is aimed at changing the culture from one that is focused typically on a single delivery to a new model that comprises multiple deliveries to establish an environment that supports deployed capabilities every 12 to 18 months.

Incremental and Iterative Development and Testing – This principle embraces the concept that incremental and iterative development and testing, including the use of prototyping, yield better outcomes than trying to deploy large complex IT network systems in one “Big Bang.”

Rationalized Requirements – User involvement is critical to the ultimate success of any IT implementation, and user needs must be met. However, this principle also recognizes the need for users and requirements developers to embrace an enterprise focus across a portfolio of capabilities with established standards and open modular platforms vice customized solutions to ensure interoperability and seamless integration.

Flexible/Tailored Processes – The Department’s IT needs range from modernizing nuclear command and control systems to updating word processing systems on office computers. This principle acknowledges unique types of IT acquisition and embraces flexible and tailored-and risk-appropriate-IT paths based on the characteristics of the proposed IT acquisition.

So with the radical change in approach from two western governments, these positive messages should filter down through anyone who does business with them. The tides are changing…

The changing state of agility in defence

You may be thinking “But who gives a crap what the DOD does?”. In the USA the Department of Defence employs over 1.2 million people, and that’s not counting contractors. This means that, unfortunately, everything in IT revolves around how the DOD develop software and work with vendors. If you are a vendor that works even third-hand with the DOD you used to be bound by law (the DOD procurement rules) to create software and work in a stage-gated and distinctly waterfall manner. Oh, many teams tried to do agile anyway. However they could only do this within each stage and this is the situation and source of Scrumfall, Agilefall, WaterScrumFall and all of the other “pretending to be agile” processes out there.

The DOD has influenced Universities by requiring that they create engineers that work within their model and by providing and creating jobs that function this way. How can one learn to be agile in a world governed by waterfall. Indeed our own Ministry of Defence (MOD) has had the same influence, maybe from their own rules but also as a result of working with the Americans and within their rules; like how airports in Europe require you to take your shoes off or go through those big scanners even though you are not flying to the USA.

(2) be designed to include—

(A) early and continual involvement of the user;

(B) multiple, rapidly executed increments or releases of capability;

(C) early, successive prototyping to support an evolutionary approach; and

With the new rules, there is now freedom to deliver more frequently and iteratively throughout the western world and this effect can be seen in recent UK projects as well as in the US. There is no better government site than http://gov.uk! It is quickly becoming the envy of other governments in its simplicity and ones ability to quickly and easily find the information you need.

One of the defining projects of the last 10 years that has resulted in this change in the USA was the resounding and public failure of the Sentinel project buy the FBI.

The impact of the Sentinal project failure, and success

I created this presentation based on work that I have done with Scrum.org and I use it at organisations that have a little more inflexibility and stubbornness than most. Usually, at these customers I hear phrases like “You cant do that here.” and “We are not a software company.” Thus looking at the FBI is a good one as it is not software and government. If the government can do agile then by golly everyone can.

I always like to start a presentation by looking at some data. For good reasons have we moved to agility from waterfall and above you can see that as of 2011 we are three times as likely to succeed doing agile as we were under a waterfall.

Succeed – Project was on time and on budget

Challenged – Project was delivered but not on time or on budget

Failed – Project was not delivered

Although we still have a lot of challenged projects we can vastly reduce the failure of them. In addition one would hope that an agile project that fails, fails only a few short iterations into the project so the costs are a lot less. Waterfall projects tend to fail near the end as it is not clear what will be delivered, or not delivered until at least testing commences.

Can you imagine a green screen terminal application delivered in 1995? Just to put it in perspective, Windows 95 was available. Hell, my Atari has a graphical UI. Well the FBI launched their obsolete criminal records system in1995 and used technology that was museum quality at launch. This is all to common with projects that take many years to complete and even more so on government projects.

So what happened next?

At first all was well and the FBI Director commissioned a 3 year project with a budget of $390 million but very quickly things start to drift and he had to go, cap in hand, to congress and ask for more money. As this is typical government fair he obviously got it but in 2005 there was still nothing delivered. Not a single piece of working functionality existed after 4 years and an extra $170 mullion. How would your boss react if you had nothing to show for 4 weeks… let alone 4 years?

Would you still have a job?

In this case obviously the best idea would be to throw away the last 4 years work and start again with a new vendor. Yes… that’s it…now we can really deliver.

Obviously having already spent over $400 million on vaporware the new vendor just needs more time and more money. It obviously also makes sense to pick not only a large defence contractor, co they have a good record of delivering high quality on time and budget, but also not a software company. The rational for this I do not know but that is just what the FBI did. However after 4 years not even a third of the work was complete and almost 90% of the budget had been spent. Indeed rough estimates to complete the project was another 6 years (10 years total) and another $351million (grand total of $772 million.)

So with over 400 people working on the project the total waste so far is over $700 million and the project is 9 years in. Remember that the out-of-date green screen terminal application has now been in place for 15 years and Windows 7 is just around the corner. We already have the iPhone and iPad so what the hell are these muppets playing at! Its time for a different tack…

The new tack was an agile one and for these guys it was more of a jibe. They created a Scrum Studio in the basement of the hover building and found the 40 best folks that they could to run with the new format. This being the second reset with so many years and dollars under it there needed to be results and quick. Not only did they deliver incrementally but they were code complete with only one year of work and $30 million spent. That’s right… I am not missing a zero.

Unfortunately the project had taken so long that the hardware that had been bought by the previous attempts was vastly out-dated and needed to be replaced as obsolete.

In early 2012 the FBI shipped to production on the new refreshed hardware and saw significant improvements for a much lower cost.

]]>https://nkdagility.com/dod-has-made-it-illegal-to-do-waterfall/feed/22Introducing Kanban for Professional Scrum Teamshttps://nkdagility.com/introducing-kanban-professional-scrum-teams/
https://nkdagility.com/introducing-kanban-professional-scrum-teams/#respondMon, 26 Feb 2018 15:00:08 +0000https://nkdagility.com/?p=38334A few weeks ago I was in Boston to visit the Scrum.org offices and learn to teach the Professional Scrum with Kanban (PSK) training class co-taught by Steve Porter and Daniel Vacanti. This is a new Professional Scrum training course created by Ken Schwaber, Scrum.org, the Professional Scrum Trainer Community and Daniel Vacanti who helped […]

TL;DR;

Now you can not only learn Scrum from those that created and maintain it, but you can add the Kanban Method from those that developed it as well. This new class show how to take the core practices of Kanban and implement them within the context of Professional Scrum without changing Scrum. I have already posted on how you can flow work across the Sprint boundary and that was a direct learning from me attending this class.

This is a 2 day class that also has an assessment that will earn you a PSK certification. I’ll be teaching this class in combination with Chris McDermott, founder of Lean Agile Scotland, to bring some much needed Kanban team experience to the class. While I have significant experience with Scrum teams, I have only worked with a few Kanban teams.

Kanban Guide for Scrum Teams

The Kanban community and the Scrum community have been working towards the same end for some time. Since the mission of Scrum.org is to improve the profession of software delivery then anything that we can do to make that a reality is within scope.

Scrum is more than 20 years old and has been trawling some baggage with it. Since the creation of the Scrum Guide Ken & Jeff have been working to remove much of that baggage from the definitive and agreed definition of Scrum and they have done a fantastic job. You will not find a mention of User Stories, Story Points, or Velocity in the Guide. They are not required to create an empirical control system.

I am not saying that they are bad, just that they are merely complimentary practices that you can choose to use or not. And let’s be super clear, if you have an amateur team then you should be starting with User Stories, Story Points, or Velocity, they are good practices. For more advanced teams that are already delivering working software on a regular cadence you might want to change those practices out for ones that focus more on flow, and you might also choose to use User Stories.

You can read the Kanban Guide for Scrum Teams which is an extension to the Scrum Framework. The Scrum Framework is closed for modification and open for extension which is reflected in this new guide. The new Kanban extension adds the following practices:

Visualisation of the workflow

Limiting WIP

Active management of items in progress

Inspecting and adapting workflow

In order to adapt your workflow to maximise the flow of value to your customers we also need to add the following metrics:

WIP

Cycle Time

Work Item Age

Throughput

This is an implementation of Kanban within the context of Scrum and as such has a definition that might differ from other Kanban implementations. Have a read of the guide and see if it appeals to you. For me the ideas of limiting WIP are ones that I have always encouraged teams to do and velocity always seamed like a broken metric.

Professional Scrum with Kanban Training

Working with Daniel Vacanti has opened my eyes to throughput and how it can replace velocity and help answer many of the questions that I have been asking for some time. His training and this class made so much sense that I don’t know why we have not yet adopted these practices in mainstream Scrum. I think that is time for a change.

]]>https://nkdagility.com/introducing-kanban-professional-scrum-teams/feed/0Work can flow across the Sprint boundaryhttps://nkdagility.com/work-can-flow-across-sprint-boundary/
https://nkdagility.com/work-can-flow-across-sprint-boundary/#commentsTue, 30 Jan 2018 20:12:00 +0000https://nkdagility.com/?p=38300There 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. UPDATE: To find out how to allow work to flow across the Sprint boundary you can […]

]]>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.

TL;DR;

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.

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.

]]>https://nkdagility.com/work-can-flow-across-sprint-boundary/feed/5Professional Scrum is for everyone in your organisationhttps://nkdagility.com/professional-scrum-everyone-organisation/
https://nkdagility.com/professional-scrum-everyone-organisation/#commentsTue, 16 Jan 2018 13:25:00 +0000https://nkdagility.com/?p=38287Recently 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 […]

]]>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. You cant use someone else approaches to get to agility, but you can learn from it.

Professional Scrum is for everyone in your organisation

Armed with previous experience with Scrum.org, the PSF class, and me; the CIO, CJ Singh, asked me to come along and train as many people as we could in the time that we had available. Turns out that looked like 147 people from the engineering department, and my did we had a lot of fun. While they have been constantly moving towards a greater degree of value delivery there were a lot of misconceptions built up about Scrum over the last 8 years… those misconceptions were creating a glass ceiling and inhibiting the flow of value to the business.

This is the second time that I have worked with CJ, and again he excelled at helping his team understand that it is the makers that are the ones that get things done. They are the ingenuity that delivers the value that is needed by the business and they are the ones that need to be nurtured. Without the makers coming up with ideas there would be no company, and there would be no ideas; no backlog.

I previously worked with CJ at Backcountry in Utah where I trained everyone in the company. I still get emails from folks from Backcountry, even 5 years later, and many folks considered the experience of going through the PSF class as “a game changer” for them.

The purpose of the PSF class is to not only to level set everyone on Scrum but to give them a very real understanding of what is required to get significant value from it. If, like at Backcountry (Utah), Healthgrades (Colorado), Fraedom (England), Teleplan (Norway), and HESA, I can get everyone in the organisation to participate something then interesting happens. There is enough of a catalyst, a tipping point, that starts the snowball of change rolling.

Conversations and discussion is the point

The conversations that take place over the 2-day class are ones that don’t normally take place and all of the Professional Scrum classes are designed to get people talking about their issues and what experiments might be useful to find the right way.

At Backcountry I had everyone from the CTO to the guy that drove the forklift in the warehouse. That’s right, everyone… including the CEO’s assistant… Because everyone in your organisation has good ideas, many are direct stakeholders. Getting them to feel that they are empowered to make suggestions and to have ideas is part of Agility. Getting the CEO to hear all of the questions, and discussion, around why things are not running as smoothly as they could be, and what would need to change to make that happen is invaluable. Getting the Stakeholders to understand what it takes to build software opens their eyes to the involvement they need to have in the process. Getting the developers to hear the business realities that create the pressures again changes the conversation. How can you possibly hope to change your organisation unless everyone is on board and going in the same direction?

As with all courses where one trains everyone there are usually many dissenters. Folks that don’t want to be there because they think that they know everything or they just don’t think it will be valuable. David was in the “were doing Scrum already so why bother” category, but it only took 4 hours of the class for him to realise how much his understanding had deviated from core Scrum. The fundamental understanding of how Scrum implements empiricism is something that not only do we need to know, but it’s nice to have a reset every so often so that we remember the reasons why.

Creating a bounded environment for change

So many teams I work with across the world forget, or never knew in the first place, why we have things in Scrum. They forget that we need the transparency of the past provided by the Increment of Working Software. They forget that without the Product Backlog we get no transparency on what we are doing next, and without the Sprint Backlog, we have no visibility into what we are doing now. They forget that without that transparency there can be no meaningful inspection of what is going on at each of the Events and no meaningful change to the way that things happen.

Many attendees of the Professional Scrum Foundations at all of the companies I have done it for, regardless of their existing knowledge level, come away with a new appreciation for Scrum, its Artefacts, its Events, and its Rolls. Even experienced Scrum Masters like Katherine has something to learn and find value in the reset. Its easy to become complacent with the organisational dysfunctions that are the “way that things are done here”. I worked closely with Katherine to make sure each of the 6 class that we ran went smoothly and facilitated the right discussions.

Just as Scrum creates a bounded environment so that we can all be going in the same direction in our work, so the Professional Scrum classes create a guided environment for discussion and revelation.

Iteratively tailored training not content

Each instance of the PSF class I learned new things about the organisation, its employees, and how it operated that helped me guide the classes to a better understanding of Scrum. I use the same material as every other accredited Scrum.org trainer worldwide, and I tailored the path. I learned which things we can skip over, and which we need to dive headlong into. Some of the experiences were traumatic, and the discussions heated, and by the end, there was not a single detractor from agility or Scrum in those that went through the classes.

Healthgrades now has 147 people are the pioneers, evangelists, and change agents that now feel empowered to make meaningful change.

One of the outcomes of the Professional Scrum Foundations, along with the new knowledge and excitement, is an organisational change backlog. One that has been created by those that are doing the work and understand the constraints and challenges of the work. The hope is that management then uses the Agility Guide for Evidence-based Management to facilitate changes in the organisation to get rid of those pesky impediments to value delivery that are out with the control of the teams.

Healthgrades now has a Backlog of things that need to change in order to facilitate meaningful change.

With these two things, agile torchbearers who feel empowered and a list of changes, I am hoping that Healthgrades can change their organisation and increase their ability to take advantage of market opportunities as they arise, and out-manoeuvre their competitors with ease. Refine backlog facilitate meaningful change.

]]>https://nkdagility.com/professional-scrum-everyone-organisation/feed/1Create your own path to Organisational Agilityhttps://nkdagility.com/organisational-change-create-path/
https://nkdagility.com/organisational-change-create-path/#commentsThu, 11 Jan 2018 13:28:00 +0000http://nakedalmweb.wpengine.com/?p=11214Other scaled agile frameworks employ a cookie cutter approach to organisational agility. While I accept that they may have worked somewhere once, the likelihood that the same approach will work in your organisation is small. They were created to get a unique company from their existing state to their personal vision of where they wanted […]

]]>Other scaled agile frameworks employ a cookie cutter approach to organisational agility. While I accept that they may have worked somewhere once, the likelihood that the same approach will work in your organisation is small. They were created to get a unique company from their existing state to their personal vision of where they wanted to be. To increase the likelihood of success you need a framework that guides you to changing your organisation in an incremental and custom fashion towards your own vision. Cookie cutter approaches will not work for you.

TL;DR

If we accept that our path to agility is unique and will always differ from others we can leverage the Agility Guide to Evidence-based Change to help guide us to a greater degree of organisational and business agility. We can use the same ideas that have created so much product value with Scrum and leverage them to create organisational value as well.

Create your Organisational Change Backlog and Organisational Change Team and create your own path to agility. Then train everyone in your organisation and have them identify, as only those that do the work can, the impediments to value delivery that you have in your organisation.

Create your own path to Organisational Agility

Every organisation, and indeed every department, is a little bit different and you need to tailor your approach to suit the culture that you have. A clear vision and an incremental drive is the starting point to enact improvements.

I have been working with a few companies in the last year to move them towards a greater realisation of their ALM and DevOps visions. In my world, DevOps is made up of your Processes, Practices, and Tools that you use to deliver on your products vision and achieve some amount of business agility. The greater degree of agility that your organisation can attain the larger the competitive advantage that you will have over your competitors. In today’s marketplace, there is no room for inefficient and wasteful organisations that are slow to change. As long as you are building software that your business uses to make money this is indubitably true. It really does not matter if you are selling that software, or that software runs the warehouse that allows you to deliver goods to customers. You rely on the function and features of that software to do business.

The first step to creating a direction for improvement is to create an organisational improvement vision. Think about where you would like to be and write it down. And don’t just think of the short or medium term, this will be a living vision of your end goal. Try to think of the ‘whats’ and ‘whys’ that you want to achieve rather than the ‘hows’. You want to set direction and not constrain the ingenuity of those working towards the vision. This vision then needs to be communicated to everyone in your organisation. Everyone needs to understand that you stand behind that vision and plan to enact it.

“The greatest resistance to moving towards the culture and process that you want is the culture and process that you have”

You also need to communicate, and often accept, that it takes time to change. Especially in Enterprise where the greatest resistance to moving towards the culture and process that you want is the culture and process that you have. Indeed if you are being truly iterative in achieving your vision the route to get there will likely change many times as your organisational culture adapts to the changes. The time it takes to reach your vision is directly related to the amount of support that you get in pursuing it. Bottom-up support is not all that is required to enact the type of organisational change that reaching towards business agility needs. You need full executive buy-in for the initiative and not just the usual lip service. They need to act in the change process, after all, it’s their company and if they are not interested in being more efficient and beating competitors then why should you?

If you get that top-down involvement you can often accelerate the move to a greater degree of business agility by short-circuiting some of the usual resistance. Public buy-in at every level removes a lot of the vision backchat that often accompanies chaotic change.

Now that we have our vision we need to be able to enact it. Time and again Scrum has proven, worldwide and consistently, to deliver on the ‘twice the features in half the time’, promise and it can be used not only for delivering a product, but also for delivering change within your organisation.

In order to enact our vision, we need a continuous improvement cycle where we:

measure the organisational value that we are getting using common metrics that we may need to tailor to our organisation

Improve based on the direct evidence combined with the organisational capability

This process allows us to create an organisational improvement backlog while leaving room to change dynamically as we create more organisational value. We can easily switch focus to other areas that will provide more value for less investment. You should focus only on your first few steps towards your vision to maintain your ability to change for as long as possible.

The Organisational Change Team – the guiding coalition

At this point you should read the Agility Guide for Evidence-based Change if you have not already as an understanding of the concepts in this document is necessary to understanding this approach. You need to understand that your engineering practices will need to keep pace with your cultural and process changes. You can’t leave any of these three pillars to lag or your pace of change will slow and may stall.

Key to moving forward at a sustainable and consistent pace is a guiding coalition that comprises senior representatives of engineering, commercialisation, and portfolio groups. This guiding coalition is the Change Team that will work through the organisational change backlog. You organisational change backlog should reflect the difference between where you are now and the vision that you want to achieve and the guiding coalition would be responsible for working through that backlog and showing improvements within the organisation to the change owner. These roles and accountabilities, just like for a Scrum Team, are key to being successful.

Guiding Coalition – The group of people that are going to take your organisation forward and enact the change.

Change Owner: The individual who is accountable and responsible for the Organisational Change Backlog. Might be the CEO or senior Product Owner.

Change Team: The Team responsible for delivering against the Organisational Change Backlog. This team should have everyone they need to activate the items that they take on.

Process Manager: The person responsible for making sure that everyone is effective within the bounds of the framework.

If your organisation is large then we may want to break our guiding coalition along the lines of the below Practice Domains and have a separate and relevant guiding collision that is accountable for that domain and for working together with the other domains to achieve the vision.

When you have a large enterprise or even just a large part of that enterprise, it is essential to make sure that you make progress in each of the practice domain identified above. Sometimes that will mean that you need to have a separate and focused guiding coalition for each of the diagnostic practice domains. This will enable progress, in parallel, across each of the disciplines.

Process – Process is typically owned by your Scrum Masters which may be part of your traditional PMO and should contain all of the key drivers for implementing the Scrum framework with your teams.

Productivity – Your engineering teams would be the most relevant and effective members of this domain.

Value – Value is a key factor of your Product Owners and as such their organisation should be the leading members of this guiding coalition.

Quality – Your commercialisation teams may be a key participant here, and with engineering practices high on the list of activities involvement from engineering would also make sense.

Enterprise – This domain should be owned by your leadership and sales teams. This is where you focus on the high-level organisational culture shifts that need to happen.

The ideas above for membership and accountability of the domains is by no means strict and should just be taken as a suggestion. In this process, we are accepting that every organisation is different and we will need to adapt the way we implement this organisational change framework to suit.

Each of the organisational change teams would be accountable and responsible for the delivery of measurable improvements to your organisation on a monthly cadence. While it may seem insurmountable it’s about scale and focus. Break those large changes down into things that are achievable and show valuable improvements. The change backlog will help us focus on, and monitor, the pace of improvements.

As we move towards our vision, after each step, we may need to improve, refactor, or completely redo our organisational change backlog as necessary to maximise achievable organisational value. Another practice that helps with this is communities of practice. Having an organised group of engineers share their knowledge across you teams will help each team assimilate the changes and improve their engineering practices in step with the changes. If you give dedicated time to these communities you should see a marked improvement in everyone’s knowledge and skills.

Avoid sabotage and train all your stakeholders

You should not underestimate the ability of the uneducated members of your organisation, at whatever level, to undermine and often derail the change process. All of your employees are your stakeholders to any organisational change, and its hard to do anything without the support of your stakeholders. On top of this one of your greatest challenges will be making sure that your message, and the agile message, does not get diluted with every telling. While at the executive level there may be a keen understanding of agile and lean and how to implement them the reality is that the further away the message must pass the less likely the message is to remain intact. Think of something as simple as the telephone game; how easily can the message get distorted. Then think of how complex your message of change is.

If you have a core message, like Scrum, that you can have told the same worldwide you can cut through the human need to change the message to one they want to hear. So instead of focusing on posters and booklets, it is far more valuable to spend time in workshops all learning the same thing. Especially if you can get a wide variety of people into those classes.

The most effective agile transformations I have encountered have all got consistent and broad-based training in common. Wither you train with an internally created course or through professional training there is value in everyone having the same understanding of the agile principals and the Scrum framework. When I have dont this for organisations it has visably empowered and exited the folks that work there and kick started the move towards agility. That is why the Professional Scrum Foundations class was created, for brawd training at all levels throiught the organiation. I have had everyone from the guy that drives the forklift in the warehouse, to the CEO of the company in the same room, working on teams to deliver working softwarea. The understanding on empiricism and the complexity of software developemnt that this provides is invaluable for getting folks moving in the right direction.

Get your stakeholders to create Orgnisational Change Backlog Items

The other outcome of the Professional Scrum Foundations class is as a feeder into the organisational change backlog. Who better than the people that are actually doing the work, at all levels, and who have just leanred about Scrum, to create Backlog Items? With the learnings of Scrum fresh in their mind they are eminantly perfect for identifying the Impediments in your current orgnisation to moving towards the new model. The last few hours of the class is dedicated to a workshop that gets all of your stakeholders thinking about what needs to change to move to the new way.

How do you create Backlog Items for your Organisational Change Backolg when every employee is a stakeholder?

]]>https://nkdagility.com/organisational-change-create-path/feed/3If your backlog is not refined then you are doing it wronghttps://nkdagility.com/backlog-not-refined-wrong/
https://nkdagility.com/backlog-not-refined-wrong/#commentsTue, 09 Jan 2018 14:04:00 +0000https://nkdagility.com/?p=38243Most 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 […]

]]>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.

TL;DR

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.

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.

]]>https://nkdagility.com/backlog-not-refined-wrong/feed/3Getting started with a Definition of Done (DoD).https://nkdagility.com/getting-started-definition-done-dod/
https://nkdagility.com/getting-started-definition-done-dod/#commentsThu, 04 Jan 2018 13:03:00 +0000https://nkdagility.com/?p=38238In my last post about Professional software teams creating working software David Corbin made a good point. How do you determining 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 […]

]]>In my last post about Professional software teams creating working software David Corbin made a good point. How do you determining 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).

TL;DR;

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 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.

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 Corbin 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.

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.

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 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 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.

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 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 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 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 product

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 fight negotiate over when these things get done.

]]>https://nkdagility.com/release-planning-and-predictable-delivery/feed/7The fallacy of the rejected backlog itemhttps://nkdagility.com/the-fallacy-of-the-rejected-backlog-item/
https://nkdagility.com/the-fallacy-of-the-rejected-backlog-item/#commentsWed, 13 Dec 2017 11:55:32 +0000http://nakedalmweb.wpengine.com/?p=9833To my understanding there is a frustrating misunderstanding of reality when one thinks that the Product Owner can reject a single story at the Sprint Review. This is the fallacy of the rejected backlog item.

]]>There is a frustrating misunderstanding of reality when one thinks that the Product Owner can reject a single story at the Sprint Review. This is the fallacy of the rejected backlog item and the misguided belief that this backlog item can just be left out of this delivery. That backlog item that was chosen by the Development Team at the Sprint Planning event to help them achieve the Sprint Goal. The Sprint Goal that created focus and has the entire Development Team working in the same area of the codebase.

The fallacy is that without this single Backlog Item, one of many, the code will still function as intended.

TL;DR;

Since the Development Team is held accountable for quality, but not quantity, and they sure cant be held accountable for meeting expectation.

DONE – If in the pursuit of the Sprint Goal the output of the Sprint is a DONE Increment of working software then the Development Team did everything they were required to do. Any gap between what was delivered and expectation is merely a learning opportunity. At the Sprint Review, the Scrum Team investigates this gap and updates the Product Backlog to reflect what is now needed next.

NOT DONE – If the Development Team is not “Done” at the end of the Sprint then there are some consequences:

An increase in Technical Debt that is going to make future work slower

Removing the option for the Product Owner to release the product if they so choose.

With undone work, you have to fix it next Sprint and thus interfere with the next SPrint Goal and the Product Owners delivery expectations.

But if its DONE. There is no rejection of the Backlog Item there is only feedback. There is just a learning opportunity that can be used to reduce the expectations gap for future Sprints. Reflect on that during the Sprint Review, engage with Stakeholders to better understand both their intent and their expectations.

Empirical process control is not about doing everything correctly, it’s about transparency, inspecting, and adapting.

The fallacy of the rejected backlog item

Oh, the Product Owner can deny the assertion of the Development Team that they have completed it and had them re-estimate it and stick it back on the backlog. They can decide to postpone deployment until the next Sprint. They can even choose to reject the entire Sprint and lose all of the work done in that Sprint. My point is that it is neither physically nor technically possible to remove a single PBI from a Sprint without incurring significant rework.

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
–Scrum Guide – Sprint Review

The Scrum Guide 2017 mentions nothing of rejecting anything at the Sprint Review.

This is the reality of product development that gets in the way of the idea of the rejected backlog item. The software that we are producing is complex. If we are creating a Sprint Goal and selecting backlog items that help us achieve that Sprint Goal then they are probably inter-related. These inter-related items will likely build on and reference each other’s functionality. If we then decide to rip one of the nodes out of this complex web of classes and methods, then we are increasing risk, and we are also unlikely to have working software at the end of the Sprint. Oh, I am sure that there are exceptions, but it will take time to remove no matter how good the team’s engineering practices.

Just to be clear, this is not about Done. I expect every team to produce work that meets whatever definition of done that they have agreed with the Product Owner. If the Development Team calls Done when they are not then that is a wholly separate problem… because Professional Scrum Teams build software that works.

Rejecting a Backlog Item is missing the point

Not only that but you may be missing the whole point of the Sprint Review. It is not about acceptance or rejection of the increment by the Product Owner, but instead, it is about discovery and understanding between the Product Owner, the Development Team, and Stakeholders. It is one of the keys inspect and adapts points for the Product Backlog. The Product Owner, being human, perhaps had a picture of what they wanted in their head that does not match what the Development team has produced. In this case, the Development Team need to work with the Product Owner to update the backlog with the changes that now need to make it that which the Product Owner envisaged. So it meets “done”, it meets the acceptance criteria, and it is still not what the Product Owner wanted. Is this the Development Teams fault? Of course not… it is a learning point, and inspect and adaption of understanding between the Product Owner and the Development Team. The Product Owner learned how the Development Team interprets their words and the Development Team learned something about the Product Owners intent. This is intensely valuable learning for the Scrum Team as a whole.

There are only three actions open to the Product Owner at the Sprint Review:

Update the Product Backlog to reflect what we now need to do to achieve the vision

Choose to ship the current increment or not

Choose to end the project or continue

Making it easier with feature flags or toggles

All of that being said it is the job of the Development Team to make things as flexible for the Product Owner as possible. They should implement what capabilities that they need into each increment to make it possible for them to turn a new feature off and still ship. This will not only make the Product Owner happy; it will get the newly built features in front of the Stakeholders as quickly as possible for feedback.

There are a few things that can make this as easy as possible:

Communication – Good communication between the Product Owner and the Development Team can help alleviate these sorts of issues. However, continued interfering in the Development Team by the Product Owner will make it harder to deliver what was estimated. The Development Team should deliver their understanding of what the Product Owner presented to them at the Sprint Planning meeting while collaborating where timely and appropriate.

INVEST– Making sure that your PBI’s are all following the INVEST [Independent | Negotiable | Valuable | Estimable | Sized appropriately | Testable] model. If you follow this guide, then you can minimise any misunderstanding between the Product Owner and the Development Team.

Feature Flippers/toggles/flags – The single most valuable thing in your developer’s arsenal is the ability to turn the things that you are adding on and off at will. This should be applied both to a feature and the multiple layers of that feature that are added to each pass delivering PBI’s. You may think of each PBI’s as requiring a switch to be able to turn it on or off. It is usually not perfect as there are some things that are iterations of the same feature. More advanced implementations may allow you to enable or disable features by account or user.

If you can do all of these things as they will all add value by making it easier to give the Product Owner flexibility.

]]>https://nkdagility.com/the-fallacy-of-the-rejected-backlog-item/feed/6A better way than staggered iterations for deliveryhttps://nkdagility.com/a-better-way-than-staggered-iterations-for-delivery/
https://nkdagility.com/a-better-way-than-staggered-iterations-for-delivery/#commentsMon, 11 Dec 2017 09:00:52 +0000http://nakedalmweb.wpengine.com/?p=9735There is a better way than staggered iterations for delivery that will keep you on the path to agility.

]]>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 Hinshelwood

For 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.

A better way than staggered iterations for delivery

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 delivery

I 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.

The problem with staggered iterations for delivery

In 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 delivery

We 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.