I want to preface this post by saying that I am a pretty avid practitioner and believer in Agile development methodologies. If we divide the world into Waterfall and Agile, I’m going to fall on the Agile side every time.
I have written in the past about some of the shortcomings of specific agile methodologies. I’ve even suggested a new one myself.
The truth of the matter is that agile is pretty vague.
The point of this post is not to attack Agile, but rather to honestly reflect on one of the shortcomings that I have come to realize seems to be prevalent in all of the various flavors of Agile methodologies.
Driven instead of steered
I spent a good deal of time trying to think about what seemed to be missing from software development ever since I started really embarking on that Agile journey.
Ever since I’ve been wading around in Agile-land, from Scrum to XP to Kanban, there seems to have always been something missing. Something that was there around the beginning of my career, but now seems to be somewhat lost.
I’ve noticed it in others as well. I have noticed more and more software developers becoming more passionate about their side work than their main job, even when they are working on some pretty interesting stuff.
I don’t think it is a coincidence that so many open source projects have sprung up along with the rise in Agile development methodologies.
So what am I getting at here? What do I believe is… missing?
I think it comes down to the difference between being driven and being steered.
Most Agile projects, regardless of which specific methodology they are adhering to, focus on the idea of having prioritized backlogs that are worked on in a specific period of time and measured.
The good thing about this kind of flow is that the customer or the business is setting the priority on the work being done. The bad thing about this kind of flow is that the developer is being driven down a specific path of software development.
What I mean by this is that software developers in this kind of system do not have much control over their own priorities and what they work on in their day.
Backlog work is measured, non-backlog work is not measured and even frowned upon for the most part.
A certain amount of freedom is given up in exchange for efficiency.
My business mind says this is good. My developer passion feels like it’s been stifled just a bit.
Now don’t get me wrong here. I am not exactly complaining. And I am not trying to derail Agile development or say we should stop doing it.
What I am trying to do is point out something I think many people ignore in the name of progress.
I think sometimes the whole Agile mindset has a tendency to kill the parts of developers that got them interested in software development in the first place. The idea of exploration and creativity and feeling they have the freedom to explore areas of code and technologies and projects that interest them the most.
This is why I believe so many developers have taken up side projects which do not even offer up a paycheck.
Think about it… Open source developers must be getting something they are missing in their 9 to 5 jobs or why would they be so passionate about it and be willing to expend so many hours for no monetary compensation?
Agile puts a gun to your head
Did I grab your attention with that one?
I mean it part in jest of course, but there is certainly some truth to it as well.
When I am working on an Agile project, I know that time is ticking away on the backlog I am working on and that it is going to need to be done in a relatively short timeframe.
I certainly have the tendency to look at some area of code that I would perhaps like to delve deeper into and refactor, but instead pass it by in the interest of completing the work at hand. This can be argued as a good or bad thing, but I’m not interested in debating it at this point.
What I am interested in saying is that there is certainly an amount of pressure that is applied just by having work broken down and measured. It is a constant pressure that doesn’t let up week after week.
If you complete all the items in a sprint, you’ll have new ones the next sprint.
If you complete a backlog, you’ll need to grab the next one on the pile.
Before Agile came strong onto the scene, many software projects were still doing iterative development of sorts, but not really calling it Agile.
You couldn’t really avoid it, since most work is maintenance work, and it is pretty hard to not iteratively do maintenance work.
The key difference is that we were a little less efficient, but a little more free.
We tended to be steered into areas of work, but given the freedom to work on things as we saw fit. Sure there were deadlines and certain goals that needed to be accomplished in certain timeframes, but day to day work was more about what do I feel like getting done today rather than what must I get done today.
I don’t want to paint this picture by indicating that we should get to our desks in the morning and work on whatever we want to work on each day, (I think that would be the other extreme of what I am suggesting,) but I do want to point out that there is a distinct difference in being driven and being steered and that Agile methodologies tend to drive developers down a specific path versus steering them in a general direction.
Why this problem is important
Now I could be going out on a limb here with this post. Maybe I am the only one who thinks this problem exists.
Maybe many of the newer, younger developers don’t remember the time when you came to your desk and each day was a brand new path to explore instead of having the path laid out for you ahead of time.
But, I suspect that deep down many developers, like Neo in the Matrix, feel that there is just something that doesn’t seem right and that this might be it.
If that is the case, I think solving this problem is very important, not just to software developers, but to the companies they work for.
If we can solve this problem I think we can achieve benefits like these:
- Higher retention rates. I have been on many Agile projects in the last decade and the retention rates have been pretty bad. I don’t have any data to back this up, but I suspect they run much higher than non-Agile projects.
- Improved architectures. One related problem I have noticed on Agile projects is that architectures tend to get messy, because no one ever has time to focus on the architecture. There are many things that developers would do that would improve architecture of projects that just would never make it onto a backlog.
- Improved efficiency through synergy. I strongly believe there is a strong synergy component between the work that a person wants to work on and how much they accomplish. Isn’t it amazing how fast skunk works projects end up being built? Again I don’t have statistics to back this up, but in my experience skunk works code gets written 5-10 times faster than regular project code. I think it has to do with this synergistic relationship between passion and work output.
- Increased adoption of Agile. Some “old timer” run software development shops really resist the idea of doing Agile development. Probably a large amount of this resistance comes from not wanting to give up their freedom. Agile as it is now tends to trade freedom for dependability.
- Decreased half-ass Agile adoptions. So many software development shops claim to be practicing Scrum or another Agile methodology, but they are not really doing it. I suspect some of the reason for this is related to the constant pressure they know really following an Agile methodology might impose on all members of their organization.
I think I have pretty clearly highlighted the problem in this post, and in my next post, I hope to come up with some possible solutions to address this problem.
What do you think? Am I totally off-base here? Does what I say ring strangely familiar?
