Its a puzzle game based around the idea of having different shapes made up of four blocks falling from the top to the bottom of the game area and settling at the bottom. The idea is to complete a row by filling in the gaps, at which point the row will disappear. The game space is a fixed number of rows so you need to be careful rows are removed regularly else the entire game area is filled up and the game is over. To the side of the game area usually it'll show you the next piece - this is invaluable in planning where to drop your current block. As you remove more rows the speed of the falling blocks will increase and it becomes a challenge of how fast you can think and plan the blocks.
Its unbelievably easy to pick up. It seems to do well you plan ahead so you can utilise the 4 blocks in a row which means you can resolve 4 rows at once which means big points! And the number one thing that will bring your game to an abrupt end is if you don't deal with the gaps in the rows in a timely manner as the rows will quickly stack up and fill up the board.
Now take this game which you've probably wasted so much time playing in your youth and in your mind put it side by side with software development. They are very similar. No really they are! Okay you might have to squint a bit at this point. Look at the grid. The blocks falling as pieces of work being worked on by a given team. The rows on the board represent the ideal technical solution that if time and other pressures weren't an issue - I did say ideal. We all know in reality this is never the case and as passionate technologists we strive to reach technology utopia and every day we're hindered by imposed deadlines, often magnified by a legacy system with little/no test framework and maybe insufficient resourcing. So we have no choice but to compromise our solution. This is represented by the gaps in the lines. Over time we deliver more changes and more functionality to the business and this will be peppered with 'we wanted to do this but..' holes. These crop up in future pieces of work and usually means that the amount of effort needed to complete a relatively small piece of work has been inflated by a dependency on something that we skipped over in a previous project. And of course we never got around to addressing it after the piece of work was delivered because we immediately got reallocated to a new project. It got swept up under the carpet.
I like this Tetris analogy. In fact I like it so much I feel as part our Agile approach it should incorporate the 'What did we skip and why?' as a process step. This has amazing impact on providing additional information for decision making and ultimately effective prioritisation. We would effectively have technical debt backlog stories immediately available whilst its still fresh in our minds and if categorised effectively with any new project the business would have immediate indicators of sizing - "We've skipped two big system changes that were necessary to meet the deadline and after the project they were sized at 40 story points each for a project that completed 200 story points". "Oh dear! We probably shouldn't have skipped those.. why did we skip them?" The documented reasons for why scope was reduced means we can provide clear ways to improve. Whether that means sufficient resources to start with, sufficient time for the project (which should be helped by the Technical Debt stories, or a sufficient effort in understanding the problem and its scope.
When a situation builds up where we have a number of sizeable stories in a particular area then this could potentially be spawned off as a piece of work in its own right. Think of it as your vertical 4 block that removes 4 rows. You know, the really satisfying ones!
Lets summarise what we've learnt about how to play Tetris effectively.
- Plan the gaps on your game board by utilising the look ahead - being able to see the next move means you can potentially have a plan or more precisely a Technical Roadmap. This hopefully allows you to have horizontal and vertical visibility of the impact when taking on pieces of work
- No one piece will complete an entire row - software is never ever 100% complete or ever ideal. Accept this by acknowledging the compromises that have been as soon as they were made. Compromises have to be made somewhere to meet the project constraints. This is normal business as usual with software development (and other sort of development?).
- Being able to see the entire board means you can plan future moves - being able to visually see the gaps in the product due to compromises means the business and the project team is aware of its weaknesses. You can provide visibility of this by documenting them as part of the Project Retrospective. What, why and a size against the original project sizing should provide enough information. These stories (or epics) need to be categorised according to your product such that when people have a project initiation they can easily find these. These stories will also provide invaluable information as to where to improve with regards to why we don't have a much better product.
I'm not sure the basis of this post stands within a good grasp of Agile. Technical debt can and will be avoided if your PO understands *at the time it is raised* how important it is. You are also assuming there is always compromise in quality or scope, and that's not necessarily true. It may be true in your own environment, but that doesn't make it obvious.
ReplyDeleteYou don't need to document these as part of your project retrospective. Your epics as you see them include all the "perfect solution" criteria you envisage, and rather than "losing" them and creating these so-called gaps, when the epic is broken down, you just need to create a separate user story to address the so-called technical debt items. As with anything else, they can and will be prioritised. Or discarded.
The problem with documenting this possible future problem is that it is, by its nature, waste. And waste isn't very dear to Agile.
You aren't accounting for the likelihood that a large percentage of the documented debt will be irrelevant in time. Other projects will come and wash away those past-perceived problems.
The redeeming part of your analogy is the "look ahead" window. This is akin to iteration planning: you can only deal with what you know right now. You can't deal immediately with what you *think* might happen at a later stage, because you simply don't know enough. So don't waste energy on it, just put it into your backlog, and when it becomes important (ie. prioritised), look at it then.
With regards to the PO understanding the importance of a particular piece of Technical Debt, when a situation arises when the Business Constraint for example is a fixed deadline (I should have probably mentioned this as being a common constraint), combined with resources that cannot be increased (this is another) then it only results in scope or quality being impacted. Here understanding still means that features for a product are delivered prematurely against other potential plans to try phase gradual change through the iterations to minimise risk. I hope this clarifies what I meant.
ReplyDeleteIsn't the purpose of a retrospective to review the iteration/project for its highlights in a positive and negative such that we can potentially learn from these in future? Since the nature of Agile is that the task's details are discovered nearer the time they are intended to be actioned there is always an aspect that if one was able to see the overall journey there could have been a much smoother and less rocky route to the destination. Also the termination of a project can also be brought to an abrupt end when resources have been committed to other projects despite there being remaining stories that maybe perceived as 'low value'. And as you say 'discarded'
This documenting future problems is far from being a waste. The project team working on certain areas of the system won't necessarily be the original team and with collating this information means we're accepting that it is very likely that these will become legacy issues but this is for the future team to prioritise and evaluate the impact on the new work. Debt like the true nature of debt does not desolve without intended action. And if left unaddressed will accumulate. Having map of the potential pot holes prior to embarking on a project sounds like something projects would benefit from.
A lot of these points about fixed deadline and resources are moot if your PO and the business understand the cost of the scope reduction. And ultimately you can't build trust in the business' regard if you aren't delivering value to them, while highlighting the potential risks. It's a bit easier to say "I told you so" if you are still able to deliver value "on time", and in time this makes it easier to engage with your PO and for the business to better align with these "technical debt" issues.
ReplyDeleteYour language also implies that scope reduction always = technical debt, and that's false too.
In terms of waste and documenting - I just think its unnecessary to spend a lot of time on this - you highlight the risk if and when the story is broken down, which will happen during backlog grooming sessions and roadmap reviews, and move on. I'm not saying don't do it, I'm just saying there are simpler and smarter ways of doing it.
Debt *can* dissolve, we aren't always acutely aware of everything. A product can be replaced, a system can be rewritten, a feature can be removed. The future is uncertain. And don't assume debt is always discarded, if that's a constant issue in your workplace, that's not necessarily a consequence of Agile. ;)
I think you misunderstand me if you think I was suggesting lowering the importance of delivering value to the business. As I'm sure you're aware this should be the forefront of any Agile project.
ReplyDeleteI mention 'scope or quality' as technical debt. I agree scope for the immediate purpose of the feature in the product may not be technical debt.
I'm curious why you feel this documenting is so time consuming. It is merely a title, description, comparitive sizing to other project items along with a few choice tags with the right Agile tool this very little effort in the grand scheme of things.
With regards to debt dissolving (thanks.. it was late and I couldn't remember for the life of me how its spelt), you've just reiterated what I've said. 'debt does not desolve without intended action' By rewriting/replacing a system, removing a feature that is an action. You are right though, the discarding of debt isn't a consequence of Agile as a methodology, but the suggestion in the original post was to provide visibility of it so we can better judge and size with knowledge which is difficult with ever changing teams - again this isn't Agile's fault.
Cool - I think we're talking about the same thing. I just had aversions to the term "documenting" because it implied reams of arguments and detailed observations. Perhaps "recording" would better suit the situation...
ReplyDeleteAny scope change can result in split stories, rather than dropped stories, and as long as the items remain in the backlog, an important step at the closure of the project would be to address all remaining stories in the backlog. Either the project team remains to pick up the still-relevant items, or they are distributed to new/existing supporting teams, depending on the context of the remaining stories.
I think we agree, but perhaps the balance of effect for me lies in the business objectives rather than technical impact.
I think developers are quite likely to raise issues if they see larger areas of technical debt relating to business requirements or stories on which they happen to be working, but also that it's worthwhile encouraging developers to create tasks/stories for smaller pieces of work as they see them arise. Under time constraints and pressure to ship, it's these smaller rough edges which are likely to be ignored. I guess these are the single unit gaps in Jason's tetris analogy.
ReplyDeleteOf themselves they are unlikely to be significant enough to get prioritised, but by documenting/recording them it may be easier to spot when there's a few in the same area which can be addressed at the same time. It may also help the team (and not just the developers) spot them early enough that they don't become a hindrance to other work, and can all be addressed at once with a relatively small amount of effort.
One satisfying 4x1 block put in the right place.