In my last post, I touched on the fact that Agile introduces a certain process overhead to the equation. This overhead is an investment. Given time to mature, it reaps great rewards. But what happens when it doesn’t get to reach a state maturity? What happens when the project’s lifespan was never destined to reach that tipping point?
Let’s first assume we’re dealing with a client who is open to stepping outside their comfort zone and adopting a new engagement framework with you. Let’s assume they’re willing to make themselves available for regular planning sessions and demo/review periods. Let us also assume that they’re willing to be held accountable for their role in the project’s completion. Let’s assume our client meets all these requirements, what do you do when the cost of educating the client on the methodologies, the processes, and the language of Agile is greater than the reward of putting those tools to work?
To make matters worse, I have found that the majority of the organizations I’ve dealt with in my career were not willing, or in some cases even capable, of meeting the afore mentioned requirements, nor did their projects posses what I deem to be the characteristics of a project, which would benefit from Agile.
I am by no means an expert on Agile, in fact my working experience with Agile is minimal — largely due to these substaintial stumbling blocks. Agile gurus, here’s your cue to jump in and tell me why I’m wrong. Please demonstrate how Agile addresses the issues I’ve raised. I’d love to be way off base on this, it’d sure make my life a lot easier.
In the meantime, enough about why Agile doesn’t work in these scenarios. Let’s get to the fun part: What does work?
Setting out to design a better way of managing small to mid-sized projects, I believe there are several criteria which must be met, on top of several of Agile’s parameters:
- It must be easily, and quickly adoptable. When I say quickly, I mean pick up and go with no prior knowledge.
- It must utilize familiar language. Part of easy adoptability means we must avoid new terms wherever possible. Terms, processes and tools must totally self-explanatory because no one wants to go back to school for the pleasure of working with you.
- It must cater to different levels of client involvement. No company is the same and trying to force a client to do something that is dramatically different than what they do routinely does not work in the course of short term engagements. We can’t always have dream clients who can provide continuous, and timely feedback so we need a system that minimized the expense of less than timely interactions.
- It must come with a tool. I truly admire the spirit of Agile’s “individuals and interactions over tools” notion, but let’s face it, even the most skilled carpenter isn’t very useful without his tools. The tool must be flexible and capable of adapting to meet the needs of variable of usage, but the tool must exist.
In my next post, I will begin to isolate the bottlenecks I see in the Agile process, discuss how they adversely affect small projects and start to explore alternatives. Until then, aside from the four criteria I mentioned here today, which characteristics must a process posses to work for your business?
4 Comments to “Finding a Better Way”
Good thoughts, Adam. These questions are best addressed in a conversation, hard to go into any great depth via a posting. Here are starting points for more discussion I’d enjoy having over a virtual drink or two. I’ll just focus on the 4 points you made:
Every project has a process of some kind. When you work with someone for the first time, there is going to be a need to get them familiar with how you do things and why that benefits them. Doesn’t matter if that process is Agile-based or not. Naturally, a process that is simple to understand and use is preferable.
Agile, or more specifically Scrum can be explained without use of a lot of jargon. A product backlog is a list of features prioritized by the client i.e. product owner. Features i.e. stories are written in sizes useful for prioritizing and working on by the team. We get together at the start of the project to better understand what you need and estimate the effort i.e. release plan and / or sprint plan. We have a meeting i.e. demo to show you what we’ve done so you can sign off and adjust the plan if needed. And so on… notice I haven’t had to use Scrum lingo.
A busy client needs to understand the downfalls of not engaging a client with timely feedback. It is the ideal, and anything less is costly to the client. How many times do clients end up not being happy with what they get? Problems include missing important features, doing wrong features right, poor quality.
We can’t escape Little’s Law of work in progress which states that the more tasks in motion, the less that gets done. In a short-term engagement, there is little room for delays. How can a team deliver high value without sufficient client involvement? Again, focusing on the value of being engaged and the risks of not usually works, in my experience.
Not sure what you mean by tool. There are lots of tools required to get work done. Are you referring to a tool to manage the work? The tool of choice by far is something simple – a task board on the wall. Easy to maintain, highly visible, encourages communication. It’s easy for digital tools to constrain high bandwidth conversation or force a certain way of working – they aren’t super flexible. I’ve worked with teams that want to adjust process in ways that the tool didn’t allow. A physical task board doesn’t have that problem, it can be changed quickly and easily, the way iterative development should be.
Agile / Scrum doesn’t have all the answers, in fact what Scrum’s strength is in making issues visible so that they can be dealt with sooner. It’s up to the team to figure out how to address them.
I suggest establishing some baseline metrics as you attempt to tweak your process. Some suggestions: measure how long projects take from concept to completion vs. # hours spent on the project. Look at number of defects per project. Look at your profit margin per project. Log amount of time spent in meetings and correspondence. Calculate time fixing things. Maybe group your numbers into category sizes for projects: small, medium, large. With baseline numbers, you can more objectively evaluate process changes. Qualitative measures are important too: team happiness, client satisfaction.
Sorry for the long comment, practically a blog post itself. Lots to talk about, happy to dive in deeper with you if interested.
Gerry: Thanks for your comment, it’s great to have feedback from someone with your depth of experience with Agile/Scrum.
It’s interesting how perspective influences perception. The parallax, working in a small web agency, can completely shift some characteristics of Agile from being positive, to being most assuredly negative.
For example, process “flexibility” on a large project is undeniably essential. There will inevitably be tweaks that can be made to make the process better over the course of the project. The downside is that often those tweaks are project/client specific, and really can’t be ported over to the next project. This is acceptable on large projects because the overhead of designing this improved process pays off over the months to come.
However, on a short term project, “flexibility” actually means “delay”. If the framework for engagement isn’t clearly established from the onset, a big chunk of the relatively small project budget can be eaten up merely establishing process.
For small projects, the process must be defined on day one of the engagement. It can be improved from project to project, but must essentially be rigid during the course of individual projects. This is the only way the project can a) remain profitable for the service provider, and b) reserve as much budget as possible for doing actual work.
Lastly, I fully understand and appreciate the importance of timely client feedback. Most clients do as well. Unfortunately, as I mentioned, it’s not always possible due to the inherent diversions of running a small business. Once that fact has been accepted, it’s not hard to see that it’s easier to design a process, which minimizes the negative effects of delayed feedback than it is to require a client to change how they operate their business over the course of your engagement.
Would love to keep the conversation going and please invite anyone you feel might be able to contribute, the most voices the better.
As someone who’s not 100% comfortable with Agile, #1 and 2 are really important to me. Adam I remember when I got a brief intro to it by you a couple weeks ago and found terms like ‘Scrum’, ‘Sprint’ and ‘Slice’ a little bewildering.
It would probably help adoption greatly if an Agile tool (if one were exist or to be developed) took on a form similar to (or used visual metaphors similar to) what clients are used to – namely, apps like Microsoft Project (I know.. ugh).
Adam, I came across a blog post from Forty that may interest you and add to this open discussion.