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).

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.

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.