“We aren’t being very Agile…”
I love this statement, it encapsulates everything that is wrong with Agile. Well, kind of. It encompasses everything wrong with the interpretation and implementation of Agile. I bet you’ve read a lot of articles about the perils and pitfalls of Agile, I bet you’ve read until you are blue in the face in the hopes that you’ll get a glimmer of hope, a sign of what might be a good thing to try next, ways of motivating your team, your business, your senior stakeholders, your managers and maybe even your board to understand and adopt Agile and be as pure as possible because that’s when Agile really works…
Yada yada yada, or to be a bit geeky, “Dilly dally, shilly shally” (Tifa, Final Fantasy VII : Advent Children — fantastic film btw, absolutely love it).
So, in the mortal words of Monty Python, “And Now for Something Completely Different”.
Every attempt at implementing Agile is founded for one of several reasons. One is to deliver software faster, another is to deliver business value faster, another is to help with hiring and another is to keep up with the Jones’s.
Here is the thing though, Agile is the result of a process. Now I don’t mean that it’s a long process and eventually you’ll be Agile. I mean, quite literally, that the very origins of Agile came about from a process that some clever people followed and the result was the Agile manifesto. It is the end product as they saw it, and, like many Software Developers like to do, they generalised the solution so that it was re-usable. But there is a problem with this, you see, like most code, generalised and abstracted just means more hassle and trouble down the road because it’s never possible to generalise and abstract technical function in order to meet none generalised and abstracted business requirements. I could go into this more, I won’t here because it’s off topic, but hopefully it’s set enough of the scene and context for me to continue.
I’m going to outline to you the process which was applied, whether they realise it or not, and hopefully convince you that if you follow this process too then you will figure out what to do within your business/team/partnership/relationship in order to solve the problems which exist and meet the goals you choose to set.
Acronyms are fun so I present for your consideration OIPOI. It sounds suitably wonderful and a little bit catchy so I’m happy to roll with it.
This is a cyclical thing, I’ll go through each of the steps in turn to provide depth of context but there are some other things, or themes, we need to establish first.
As an example, in a business where the team just isn’t delivering anything then we might establish the following themes for the context:
Is that it? No, each of these areas requires a lot more depth of discussion but I will summarise here for brevity.
Culture is going to be key to establishing stamina and maintaining the pace. It is the vibe of the team, the red tape they experience and directly relates to the chances of having that team cycle at inopportune times. (As an aside, your team will cycle, but teams with a healthy Culture will have longer cycle times and will recover rapidly).
Goal is a description of what you are actually trying to achieve. It is likely to be financial in nature but could be something more micro if you think it is appropriate.
Metrics is probably the most important piece, without it you have no idea whether you are achieving what you want. You will be flying blind and you will have no idea whether that’s good or bad.
You should look to re-assess, and I mean genuinely re-assess these 3 themes every couple of OIPOI cycles. Do they still make sense, are they relevant? If not then change them, that’s the point of this.
So, OIPOI, it really does just roll off the tongue, doesn’t it!
Observe and Measure, I start with this because it forms the backbone of everything that you are going to do for the rest of the cycle. OIPOI in its very essence has to be based upon facts and figures, this is why Metrics is the most important piece of the puzzle. Once you have established your key Metrics then you need to start observing and measuring. You are looking for opportunities where your Metrics could be measured, either negatively or positively, and you need to observe what happens to produce either the negative or positive impact that occurs. Now this is important, as you do this you are going to discover that your chosen Metrics aren’t quite right, do not resist the urge to change them, it is perfectly fine to change your Metrics at this point and repeat the observe and measure step. For example, you may discover that your chosen Metrics are all positively impacted, and yet you are not achieving your culture or goal, this means that you haven’t quite got your Metrics correct. Alternatively, you may discover there are few or rare opportunities to capture measurements for your metrics, this indicates that the chosen Metric is too big, it’s too far removed and, although it is a good measure for the goal or culture, you probably need a more micrometric to observe and measure. This is the opportunity to start digging deeper, you are getting your first glimpse of the underlying problem and you are about to focus your lens closer to the observables which will ultimately help you solve your problem. For example, you may choose to measure how many times a piece of work needs re-elaborating, or how many times team focus shifts. These could be good metrics to arrive at.
Once you have observed and measured then you will do an Impact Analysis. This step is about taking the observations and forming impact statements to help you focus in on the problem. For example, new high priority requirements were brought to the team 4 times in the last project iteration which meant the team had to re-prioritise and refocus and so nothing was delivered. Or, each task, on average, was elaborated 3 times causing lost time and effort and causing nothing to be delivered. These are fantastic pieces of impact analysis statements, they are the result of very careful measurement for well-defined metrics which directly relate to whether the goal and or culture is achieved.
Problem and Context, at this point, based upon sound data within the context of our metrics, goal and desired culture, we can attempt to establish the problem and context. We don’t need to be extremely accurate here, we just need to attempt to refine whatever understanding of the problem we currently have is so that we get a sense of it getting more accurate. For example, in the impact statement of the team re-prioritising, we could say that the problem is that the business doesn’t have a clear priority of what is required to deliver value, or we could say that the team doesn’t have a clear understanding of what the business priorities are. The context component of this may be that the goals and culture that we have set are incorrect or out of line. An indicator that you need to revisit your goal and culture is that everything feels like it’s lost relevance or meaning, this is the time to reflect on these and change them based upon what you have so far discovered and achieved.
Options Shortlist is where you come up with some of the different options available to you to move forward and progress the problem. Try not to get too caught up here, allocating 2 periods of time, a 2 hour period followed by a 30 minute period after a break of an hour or more (maybe even a day) should be enough. In the 2 hour period, you should attempt to come up with the different options available to you, go crazy dream big, flesh out a little detail, but not much. The 30 minute period is where you look at what options you came up with and assess whether they still make sense now that your brain has done some processing in the background. For example, to address the problem of the business not having a clear priority, we could have the following options:
There could be many more possible options. As you can see, some of these are within the team, some are external. In the 30 minute session, you will likely look at these and think that some aren’t relevant or achievable and that others really are on the money. Prune this list and try and come up with a complexity to value measure for each (purely relative) i.e. this is cheap but low value, this is expensive but moderate value, this is a little costly but has high-value potential. You are looking for more of a gut feel a thing here, consult a couple of other people if you feel like it. You don’t want to be overly detailed, you don’t want to agonise over it to the smallest measure, just a vague gut instinct, if it doesn’t work out, you’ll be trying something else before you know it.
Implement Cheapest High Hitter is the part of the process that takes the option from your shortlist which looks like the thing to do and then do it. It’s probably something relatively cheap to implement but which represents a lot of value. You may want to shortlist this even further to identify your top two or three candidates and then choose the one which looks to have the best chance of success. Once you’ve found it then you need to implement it. You may find that it’s impossible to implement straight away, you may need to negotiate to implement and you may even need to sell your idea to a few people to get them on board. Use your best judgement, if it’s too difficult and there is something else which looks like it could deliver similar levels of value but through an easier route then feel free to switch, however, don’t just opt for something much easier that delivers significantly lower value, that is just putting the cost off for longer. The only real thing you can change here is cost of effort, and that should really go down as you refine your options. In terms of identifying enough value, try and find something which as a minimum will look to have a noticeable impact on your Metrics. If it doesn’t then you will never know if it’s helped.
At this point, you start the cycle over again and keep doing so until there is another issue which is the higher priority.
The results of this process will be the way of working adopted by your company/team/whatever. It will help establish the culture you desire. Certain Agile methodologies may well be the result of this, but equally they may not.
This is the entire point right, up until now everything has been fed as a defacto finished solution, a silver bullet. But ask yourself, since when did the one size fits all thing ever work? What I have presented here isn’t a solution, it isn’t a product, it is merely a method of inquiry, questioning, observing and making an educated change in order to solve problems that you discover. It can be applied at the macro level and micro level equally. I’m not saying that having a daily standup is going to fix all your problems, in fact I’m not saying to do a standup at all, instead, I’m saying consider whether it would help based upon your key Metrics, Goals and Culture and then test it, experiment, observe and change.
If you need proof of whether this process works or not then I encourage you to consider it in a different light. This process has been used since the birth of the human species, and probably before that tbh. It is in essence the methodology of an inquisitive mind and the backbone of science. The difference is that it has been redressed for more everyday use.
OIPOI is presented as a tool that you are completely free to use. If you would like advice, suggestions or consultation then please contact me through email@example.com
Kevin a multi-disciplined and value-focused individual who is a skilled Software Developer and Trainer. His unique background gives me a fantastic competitive edge when it comes to working with businesses to identify and deliver the projects they want. Kevin primarily operates as a full stack and cross-discipline Java developer. He prides himself on writing incredibly easy to read the code and take a very lean attitude when it comes to creating abstraction layers.he has an uncanny knack for teasing out unknown requirements and really drilling down to the bottom of issues and work.
Kevin specialises in core Java development, REST API's, MicroServices, Enterprise Messaging, Automated Testing, Continuous Integration and Deployment, SCRUM, Lean, Agile, DevOps, SQL, UNIX, Spring Boot, AWS, JPA and NoSQL. He is constantly adding to this list of specialisations, with his most recent acquisition being a CSTA certification which has provided him with a solid foundation for Cyber Security.You can visit Kevin's consulting website here.
Kevin Timmins will partner with DevHubNE on the 7th November at 7pm hosting a webinar to educate on the realities and idealities of microservices, covering what to watch out for and what you can do to enable progress. You can join by registering here and follow DevHubNE on Twitter for updates on forthcoming events, podcasts, webinars, industry content and networking opportunities. See you there!
We are a leading niche digital & tech recruitment specialist for the North East of England. We Specialise in the acquisition of high-performing technology talent across a variety of IT sectors including Digital & Technology Software Development.
Our ultimate goal is to make a positive impact on every client and candidate we serve - from the initial call and introduction, right up to the final delivery, we want our clients and candidates to feel they have had a beneficial and productive experience.
If you’re looking to start your journey in sourcing talent or find your dream job, you’ll need a passionate, motivated team of experts to guide you. If interested, contact us or call 0191 620 0123 for a quick chat with our team.
Back to Blog