Some of the most basic principles in productivity are ignored on the basis of it being too stiff. For example, the advise you should put everything you want to do on the calendar is usually met with some form of trepidation, after all, who wants to live their life in a straight jacket!
Yet, there is a certain freeing dimension to it, you now can be sure what you want to do actually has some scheduled time to it. This effect however only kicks in if you also realize you own your calendar, you can switch things around if you wish, subject of course to other work constraints.
Agile practices offer you a similar kind of freedom. In fact it does you one better, you can even change the structure of some of its most prominent variant, scrum, to whatever best fits your organization!
But then, when does agile stop becoming agile?
In this entry, I will be exploring some of the core characteristics of agile which I believe if you are not doing, you need to call your practice something other than agile.
Is there a timebox?
Scrum depends on timeboxes.
I believe a timebox is so important, it’s not even just a scrum or even agile principle, it is a life principle!
A timebox does to your life what a budget does to your finances. Without a budget, your money will likely disappear to the first expenses which happen to occur. A budget helps you be mindful of other important expenses which may not be as immediate but are as important.
In a previous entry, I discuss why and how to timebox.
If you ever find your team working endlessly with nothing to show for it, you are probably violating these principles.
Are features working?
Life happens, sometimes you are just not able to deliver on everything you said you would.
I used to work with a developer whose goto statement was:
This is just about doneIt seemed all features were 90% done and nothing was ever 100% done. Thankfully, he has since moved past this stage and now provides fully functioning features useful to our end users.
If you find yourself in a similar state and still continue as if nothing has happened, then you are living in some form of denial.
As humans, we are good at recognizing when something is done or not done. The various shades of incompleteness bring nothing but confusion to the team.
It is tempting to mark a task/feature as complete if it does look nearly complete, but as our product manager likes to remind me:
If you tick of this feature, you are being dishonest with yourself, it needs to first reviewed, integrated and documentedIs the backlog prioritized by business value?
After being with Twiga for a couple of months, I was getting quite confident in my knowledge of the product.
In fact, I was quite sure I knew more about the product than say the agents its meant to serve who only use it as opposed to us who build it.
Such hubris never takes you to a good place.
I was relieved of this disillusion from a field trip where I observed one of the agents use a trick to quickly add a new delivery, a functionality not officially provided.
At this moment, I came to realize the end users of a product have access to a certain view of the product not available to myself or anyone else in the development team. Just because you wrote it does not mean you have hands-on experience using it.
This incident taught me not only an important lesson in humility but also, your backlog should not reflect your priority, it should be an expression of what your end users care the most about.
Are there estimates?
A common pushback when asking for an estimate from the developer team is we have no idea how long this will take.
I don’t think this is ever true.
Let’s take an example of my trip to work this morning. Will it take exactly one hour from my gate to the office?
Probably not.
Does saying it will not take one hour of any use? Does that mean it will take 2? Maybe 12 hours? Of course, I know from experience this is also not true.
In fact, I can say with confidence, over the last 30 days, it has taken me between 30 mins to 1.5 hours to get to the office. With this information, I can guesstimate with 90% probability if I leave the house at 7 am, I will arrive at between 7:30 and 8:30 am.
The numbers above may not be pinpoint accurate but they sure as hell do communicate a lot more than I will not reach at 8 am.
Furthermore, if I now actively start tracking my estimate vs actual values and reflecting on possible causes of variance. I generally get better at my estimation.
The questions above are not meant to be comprehensive, but I have come to find by constantly asking them. We are able to evaluate if we are still on the right path in our process.
How do you know you are still agile? Talk to me in the comment section below or on my twitter @jchex
