I’ve heard so many tales about how agile processes can speed up your development and help you in getting better in whatever you’re planning to do. All over the world the agile movement is celebrating the advent of latest technologies, continuous integration and the value of the MVP as the cornerstones of modern software development.
All great, as long as your engineers are willing to go this path with you. As I’ve adressed already in a previous post, one of the most important aspects in the switch from traditional development approaches over to agile, involves the commitment (no pun intended) of your development crew. It’s a shame how many companies are making a management decision to introduce agile, while not even asking the people affected by it even once.
Agile is great, if your people are willing to be agile
Efficiency does not come without cost. Efficiency comes without the general agreement of everyone involved. If you’re playing a game of football, you might have a much better chance of winning, if everyone on your team agrees on how to approach the enemy. No different is the case with SCRUM or agile. If your development team is excited to try out new processes, they might create wonderful results and futhermore the much-advertised pro’s of the agile movement.
As with every change, also the transformation to agile takes its toll on efficiency
This is my number one complaint about Scrum and other agile methods out there. Everyone working in the great agile cash machine will advertise it to you on behalf of the great benefits and the so-ho increased workload your people will be able to handle.
In reality, people aren’t getting better over night, they won’t magically superpower because now they’re having review meetings and for sure doing cross-functional will not help them to achieve more. SCRUM is like every other business process change: it needs change management, which in turn requires a sacrifice on efficiency. Someone might call this straightforward ironic, wouldn’t you agree?
Good people will acknowledge the best bits, and dump the rest
If you’re having a development team you’re trying to force agile on, be prepared to hear more than one “what’s that bullshit for” questions. And they’re right. If everything in your dev team is running like a charm, you can as well forget about agile. People get used to their environment and get good at it, if they bring the proper motivation. If there’s a chance you’ll interfere with this sensitive ecosystem and destroy it, its by forcing them into new rules they cannot understand in the first place.
If your people were used to come and go as they please, and now are forced into daily standup meetings (usually in the morning), they will not be happy. And right they are! There’s more people out there being good at working in the night as you might think. Taking that flexibility of them feels like punishment, instead of a reward. And don’t think anyone will forget those things soon, as people are going to complain about the new ruleset.
The solution is to let them try, choose and apply those bits of agile they need to get better, not the ones you present them as needed. Your engineers know how to handle every problem perfectly, that’s why they had to do a mostly cumbersome application procedure. Just don’t try to be smarter than them if it comes down to how to actually do their work.
Good People make Good Software
Although every Scrum Master will tell you different, it comes down to the individual people to make the most of their time spent at your company. Want to achieve real efficiency? Talk to your engineers, ask them where they might see benefits to current processes. And suggest, not force, to try out new things. This all will help you in advancing on a great extend. Nobody is going to get much of a SCRUM certificate anyway.
