Buzzwords…they are everywhere. Agile, scrum, kanban, and lean have found their way into this bucket, and for good reason. But why? When implemented correctly, these frameworks can help provide big wins for organizations and software development teams.
On the flip side, when used purely to try and replicate another’s success, failure is common. When things fail, we tend to blame the process rather than trying to determine the root cause of failure and fix what’s broken. So how do we help alleviate the pains of process change and failure?
“Agile does not fix our issues!”
I am a firm believer that being agile, using a specific framework or not, allows teams to quickly form around a problem and consistently deliver working software without large, costly upfront design and requirements gathering for things that may never be needed while missing things that inevitably will be needed but are unforeseen. Agile is not a prescribed solution to your problem. It only allows you to start testing your hypotheses quicker. In reality, if you have a problem, and you do not know the root cause or have any idea of a solution, your agile project will fail just like any other project.
“The experts all said to do it this way!”
Where agile software development is failing us is within the community. For a methodology that, by definition, means “able to move quickly and easily” and “constantly iterating” why do we see so much push back when people do exactly that? Constantly iterating should not only apply to the development work and how it is approached and finished. Why not iterate on all pieces and parts of the process and team?
- What roles are needed to make the best team?
- What happens when you decide that one co-located team is not going to work for your company or project?
- How about changing the required meetings when they are not helping you accomplish goals?
Agile has become a prescribed formula of “do this, not that” and “right versus wrong” instead of trying new things and replacing pieces that do not work as efficiently as they could.
The best agile team makeup is a group of people who can properly solve the problem at hand in an acceptable time frame, and who have been empowered (trust, budget, etc.) to do so. While it would be fantastic to have a multitude of talent on your team filling every role that may be needed, both large and small, most companies do not have the time or money to dedicate full-time members to a team “just in case” they are needed. Instead, find the right people who will be able to properly communicate the problem to an expert should they need to be brought in. For instance, database work may be needed, but instead of having a DBA sitting around waiting for questions or work, add a developer who is skilled enough to implement what is needed and know when it’s time to seek assistance or guidance.
The same principle applies to location. Year over year, more companies are going remote. This should not be an excuse to not be agile. Co-location no longer has to exist for a team to be cohesive and productive. Instead, it seems like the perfect opportunity to work each week to find solutions that allow the team to form, storm, norm, and perform without having to be in a single location. As technology continues to advance, the benefits of having remote staff will become more and more obvious, and constantly finding ways to make work better will be a standard. Not to mention, it allows companies to find the best talent for the job and not limit it to geographical proximity.
“We have to change?!”
When agile is thought of more as a frame of mind rather than a way to do work, it makes sense. Being agile has nothing to do with the meetings on your calendar. Nor does it pertain to the certifications you have earned. It has to do with embracing change and finding the best ways to respond to change to help accomplish the goals at hand.
Will all your iterating and experimenting provide huge wins? Never. But, failing will earn you the opportunity to learn what helps your team, company and yourself grow and become better than you were yesterday. And that’s where the real wins come!
I love hearing agile war stories and romance novels. Do you know of anyone who struggles with implementing agile?