Vision >= Solution >= Problem
I'll admit it, I'm not 100% agile since I tend to like solutions. I would prefer a problem to solve, but if a problem is intangible I often find a solution is a great way to explore the potential and help express the underlying problem.
It is worth noting that innovation and invention are solutions and not problems. When you apply for a patent, you don't patent the problem, you patent the solution, why? If there are multiple solutions to any given problem then wouldn't we want to patent the problem?
I also find that quite often the solutions I am exploring are the result of a problem that I have assumed was well known and in actuality is not; it is in these moments that using the solution to derive the lowest common denominator of a problem stated as a user story can ensure that everyone is speaking the same language.
But given a solution, do we always need to know the problem? My pragmatism (and a few lean principles, i.e. waste) would state that if the solution brings value then run with it, if not ditch it. If on the other hand the solution seems too constrained or lacking in features/functionality, then why not exploit the solution as the basis for a vision? Indeed many visions are just that, solutions to problems, expressed in a language alien to most developers.
So given a vision expressed in an abstract form vs a vision that is pinned against an actual solution which is easier to understand and less likely to be misinterpreted? I know which I'd prefer...
Do solutions have value, obviously; must we always mine problems, hmmm...
Could Agile Have Evolved?
DNA
I've been researching material to support an article on my company blog entitled "Agile Dictators" and it left me thinking about how Agile started in the first place.
The more I reflect on this, the more I am left feeling that Agile is actually a mutation in software development and this is one of the major reasons why Agile is so difficult to master. I'm wondering whether agile would ever naturally evolve in a small team left to their own devices and I simply can't envisage it. Of course, this will now remain an academic hypothesis since Agile has now stamped it's influence indelibly on the DNA of software development.
Software development as a craft suffers from unnecessary complexity and I fear that Agile, which initially thrived in simplifying (or removing) this complexity, is now becoming itself encompassed in unnecessary complexity. Despite agreeing with much of the sentiment of the software craftmanship manifesto I just can't bring myself to sign up to it yet. I struggle to see the benefit of more fuzzy aspirational statements and would prefer to see a clarity of vision and roadmap to achieving it.
Fundamentally Agile is fantastic, but sadly the passionate discussions, raging debates and conflicting methodologies don't clarify anything. If Agile doesn't clearly define itself soon I fear yet another mutation may take centre stage and Agile will end up being just a blip (albeit a very significant blip, where we gained sight) in the evolution of software development.
Agile Requires Skilled Developers
In a recent tweet from @EstherDerby, she states
Some ppl complain agile only works w/ highly skilled developers. Never been clear 2 me that ANY dev. method works w/o highly skilled devs.
I think the subtle distinction is that agile REQUIRES skilled developers to be successful, whereas some of the "heavier" methodologies would be better with skilled developers but don't actually require them. I also think that when we look at many of the agile successes, it would be interesting to determine whether there was any correlation between the level of skill of the developers compared to the level of skill on the non-successful and/or non-agile projects.
And taking this just a little bit further... Would a small group of skilled developers be successful regardless of the methodology? Truly skilled developers tend to be very pragmatic and will always find ways to simplify the complexity around them, so I'm sure that if you took 8 highly skilled, highly successful agile developers and stuck them on a waterfall project they would deliver a successful result, at least in terms of the customer...
What's also quite interesting about this dynamic is that once a developer "sees the light" and becomes "agile" they can't imagine going back to waterfall, despite the fact they can add immense value by being part of a waterfall project and improving the processes. There is something very selfish about this which has not yet been picked up in the mainstream... This is also possibly one of the reasons why agile suffers an identity crisis, often being regarded as a cult.
And no, I'm not advocating waterfall, I'm just wondering whether skilled developers have more impact on success compared to the methodology.