In my last blog I left off with a discussion around this thing called “The Scrum”. So, what in fact is this thing?
For those of you who have ever watched a game of rugby, you will appreciate this statement – a scrum in rugby is a dark art. Very often the scrum is open to the referee’s interpretation. In agile, until you comprehend the whole scrum methodology, it too will be seen as a dark art. I have lost count of the amount of projects that have stand-ups and Jira’s but yet seem to not move a whole lot of post-it notes in a respectable time. In almost all cases, the excuse is that “this phase of my project is not Agile friendly”. Really? Really really? Let us unpack this beast called “The Scrum” again…
In a scrum, we have a sprint – that is a time-based window in which a series of tasks can be delivered. Sprint windows vary, in some cases they are one month, in some cases they are two weeks and in some cases they are one week. Each window works – the purpose of the sprint is to “eat the elephant in bite-sized chunks”. It combats the root cause of why waterfall hurts your project. If you are looking for recommendations, head on here – The case for the one week sprint
The purpose of a sprint is to deliver some usable code to your users in iterations. So for example, to add a page to a website, a report to a warehouse, or a series of calculations which helps with credit risk. What isn’t as obvious is that the purpose of a sprint may also be to deliver a usable environment to end-users or to configure an environment – the exact same principles apply and at the heart of it you are “eating the elephant in bite-sized chunks”. You could go “big bang” waterfall on your configuration, but ask any administrator how many times they have committed to providing an environment by x date only to be late by several days. If you cannot deliver on the day you said, it is better to fail early than to fail hopelessly – it means that I can plan and work around your timelines with my timelines.
Within the sprint, you break things into user stories. So for example, to calculate credit risk, you would assume that you have credit data; you have consumer balances; and you have some kind of risk scoring techniques. You could say that each one is a story (credit data is one story, consumer balances is another, risk scoring is another). In fact, it may be so complicated that you have several stories (so if consumer balances comes from multiple systems you would break the stories into one per system). Once you realize that the sprint is useless unless you haven’t delivered all of the stories, you are already changing your mindset.
What makes it so powerful is that if you see you are going to fail on one early, you now have some flexibility to make plans to ensure your sprint isn’t an abject failure. In waterfall, you would only know this when everything is delivered. What isn’t obvious is that you can break environment configuration and deployment into several stories as well. So configuring connect direct on source x to talk to target y is one story of the configuring connect direct sprint. In this way, when you discover that source x cannot talk to target y because of ridiculous policy z; you are able to communicate early and communicate effectively.
Finally, within a story there are tasks. A task is the lowest level piece of work you can do within a sprint. It isn’t healthy allocating too many tasks to a story, as it means someone somewhere needs to administer. It also means that your sprint may become over managed. It is however healthy to allocate the highlighted tasks. So for example, lets say we need to stage data, apply some rules, materialize those rules, and then report on our end object – those would be tasks. We wouldn’t put things such as “create staging table”, “create materialization table”, “apply rules” etc. It tends to get you stuck in the trees where you cannot see the forest any more. What isn’t obvious is that you can break configuration stories into tasks as well. So very often there are several repeatable and predictable tasks to configuring connect direct or Control M or some piece of configuration.
The point is that with the right creative mind, you are able to set up a sprint, create stories and allocate tasks. Be that analysis, build, or implementation. If you are hiding behind “this phase of my project is not Agile friendly” then maybe you need to revisit the agile manifesto and the tenets of agile. You probably have your sprint, user stories or tasks at the wrong grain.
In my next blog, I will look at the difference between “Doing Agile” and “Being Agile”. I would love to hear from you, please feel free to comment.