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.
