About a week ago, a question was posed on LinkedIn:
Why do we hear of Coaches for Agile but not for Traditional/Waterfall? My question for the day.
I think the answer has to do with what feels natural to humans. It’s more natural for us to focus on our piece of work, do it, and then pass it on to the next set of hands.
It’s less natural for us to work on something together, each bringing our expertise to bear at the right time, and have far-sighted goals for getting the product into the hands of the customer.
Since it’s less natural, it’s more difficult, hence why we need coaching to do it right.
…Agile++?
Reading the question though made me wonder about whether there’s something else we could be doing. Something more than practicing Agile.
Because let’s face it: as far as we’ve come in software development, we’re still dropping the ball sometimes.
Even with Agile, we still haven’t quite figured out how to do software right, consistently and quickly.
And I think the reason for it is that Agile (or any methodology, really) is founded on an idea that humans have to adjust to computers, to produce excellent software.
But we haven’t arrived yet. It’d be silly to think that there’s nothing after this, and that there’s no way to improve.
What if the next step is just to flip that around–adjust computers to work well with humans?
What if we could make software development feel more natural for us?
Our Strengths and Weaknesses
What are we good at? Being creative.
We’re constantly making things, aren’t we? History’s littered with examples of things we’ve thought up and built, whether it’s physical objects or abstract ideas.
But you know what we’re not good at? Thinking logically.
When dealing with people, remember that you are not dealing with creatures of logic, but creatures of emotion –Dale Carnegie
Might sound odd coming from someone in a logic-oriented field but it’s true. And history’s littered with examples of us failing at this, for a couple reasons:
- Systems are so complex that we can’t understand 100% of everything in them,
- People can’t transmit ideas to other people 100% effectively.
Turning the Tables
It’s great to get a computer finally able to do what you want it to do. Because YAY emotions!
But, because we don’t always get it right, it’s worth considering that there might be a way to get computers to figure out what we want in lieu of us telling them.
Because that’s basically what programming is. We have an idea, we want the computer to do it for us, and then we tell it how to make our ideas reality.
I’m starting to think we could do this already, even without advanced AI. It’s possible to have computers take care of the logical part, by generating code to address a creative need we have.
Don’t know what it’d be called, but the methodology that comes from this would likely have much less structure, because the focus would be less on getting computers to behave, and even more on people relationships.
Very interesting. I’m looking forward to see what the next steps are.
testzius 
The one warning I’d give here is that all people – and so all users – are different, have different needs and motivators, and react differently to any one approach we may take in developing software. One size does not fit all.
For instance, there’s supposedly an emphasis on streamlining documentation, and I’m sure some Agile teams are streamlining it out of existence. Test scripts, if not completely obsolete, should be intuitive and respect the intelligence and experience of the person executing the test, goes the new thinking. And there are plenty of times when this is appropriate.
But the app we work on is sold around the world to a range of highly intelligent and demanding power users who are just as likely as we are to want to put the bonnet up on it and dig around in the functionality, if not the code, to fine-tune it to deliver outcomes just the way they want them.
Unlike other apps I’ve worked on, where the end user just wanted the end result to work and most of the interim stages were less important, our users for this app want and expect a high standard of accuracy in even small enhancements to functionality. So a high degree of detail is needed in our tests; and this needs to be recorded somewhere at least once.
And this is probably why I’ve never seen anywhere where Agile is done the same way twice. It shows the framework is actually sufficiently flexible to allow teams to find their own way to make it work for them. And I think this is A Good Thing.
LikeLike