Dealing With Challenges in Agile Methodology
How to setup your team to get the best out of agile principles
Agile gets its share of criticism.
Many articles(like this, this, and this) have talked about agile being a restrictive or bogging down teams due to the overload and rigid structure. Granted, it is up for evolution given today’s dynamic teams and products which pose challenges to the traditional application of agile. One cannot be sticking to set rules and religiously working to that tune. Priorities are changing, schedules go up and down, resources have to be moved around and more than anything, developers cannot work in isolation anymore. Departments can no longer work in silos, rather cross-functional teams are needed to work faster and more efficiently.
In this article I’ll discuss what isn’t working for agile and what works for agile.
But what is Agile?
The Agile software development methodology was born from the Agile Manifesto, which advocates four principles to be followed:
- Individuals and interactions, more than processes and tools
- Working software, more than comprehensive documentation
- Customer collaboration, more than contract negotiation
- Responding to change, more than following a plan
The problem areas with agile
Teams complain about agile being forced on them. Organizations tend to perceive it as the antithesis to waterfall and implement set rules without considering whether or not it is a good fit, and more importantly, whether it is what is needed. There’s the entire roster of what ‘kind’ of agile lifecycle you can have. Just going by Wikipedia, which very politely notes that agile can include, but is not limited to,
Adaptive software development, agile modeling, agile unified process, disciplined agile delivery, dynamic systems development method, extreme programming, feature driven development, kanban, scrum, scrumban…
No wonder people complain about the jargon. For a new team starting with agile it can obviously seem intimidating to find their way through this mess.
Once teams decide, or are told, what form of agile development they’ll be following, the rigidity of the process can become tighter. Scrum and kanban are the two most common adaptations, and they throw up their own set of challenges (product owner challenges soon to come).
Further, since agile focuses on improving in future iterations, this means more quality to be delivered in the next sprint. But that can lead to a speed vs substance issue. Can new features be delivered in a two-week sprint? Will these be a clear improvement on the previous version? Have they been validated enough to know that users are in need of them?
In a top-down implementation of agile, it can become difficult to coordinate if all the moving parts are in-sync. A mismatch between development goals and business goals show up. Teams complain that agile is an engineer-focused methodology. And more often than not, product owners are from the development team, which ends up reinforcing that idea. This is all the more of an issue because the product owner should be representing the user’s voice.
So, agile — yay or nay?
Even before that is answered, it is important to note whether agile is a way of guiding things or is it a set process.
I will argue it’s the former today. Agile can probably be best summed up as —
And it does indeed work. A great example of this is how Envato’s UX team operates.
The problem comes mostly in how agile is interpreted and executed in a team or organization.
In the article above, agile coach Dr. Jeff Sutherland discusses Spotify and Hubspot as examples of successful agile teams. Spotify does this by dividing their agile teams into what they call “squads”. These squads, in turn, are aggregated into groups called “tribes”. Each tribe has complete ownership of a part of the product and deploys at the end of each sprint without breaking anything. To make sure they deploy as quickly as possible, Spotify keeps their process such that no bottlenecks or obstructions come in the way.
So, what makes agile work for some teams and not for others?
Teams and operations have to be structured to get the best out of the particular situation. Spotify creates such an environment for their teams. Agile, at its core, is about rapid development in a flexible, need-based environment. A set of guidelines that helps boost development by dynamically re-calibrating priorities when required. Agile, as a broad framework makes more sense today, rather than following a methodology to the dot. And that applies not just to agile but to any methodology, since no one methodology is going to be fit for all.
Users Know principal and author of books like UX for Lean Startups, and Build Better Products, Laura Klein said in her interview,
“I honestly try not to tell people to follow Lean UX or anything else. These days, I tell people to figure out what they are trying to achieve and to experiment with different processes and tools to try to achieve it.”
If you want to be fast and dynamic, it makes more sense to be have an “agile mindset”. There are some very useful principles that agile throws up which can help teams today move quickly and iterate towards better products.
Collaboration
Cross-functional collaboration, to be exact. I don’t need to state how crucial design is to the developmental cycle. Whether working as 1 developer + 1 designer, or via regular meetings between the design and development teams, there has to be consensus among all stakeholders. The scope of the problem and the direction to solve it should be decided by taking on board both design and engineering viewpoints. Lack of alignment between them is majorly detrimental to moving quickly in an iteration.
Early user feedback
The voice of the user should no doubt be the guiding light of product development. The Agile Manifesto mentions customer collaboration and that is a very good point about agile. Working with users to understand their needs and pain points, their ‘user stories’ is a sure shot route to developing meaningful products. By having shorter feedback loops, development teams are not going waste time and go down alleys that lead to no value for the end user; another point that was elaborated on by Laura Klein in her interview — “The only other thing I’d say is make sure that you’re always focused on building something that is good for both your user and your company. Your user needs and your business needs aren’t in competition with each other.”
Prioritization
Aligning user goals with business goals helps empathize and build for the user. But the question of what needs to be developed before the other features come along is one that many teams can get wrong. Starting with a minimum viable product (MVP) helps get the core functionality spot on. Focus on what is absolutely essential to the user’s experience. Features that provide the most value, the soul of your product. Whether that’s sharing pictures for an Instagram like service, or pinning interesting stories on Pinterest; prioritize user feedback to isolate the basic functionality needed and start from there. Get feedback on this MVP from all stakeholders. Consider the trade-off between development time and value for your business when prioritizing features to build.
Improving and iterating
Tracking issues and managing the backlog doesn’t have to be cumbersome either. Having platforms like zipBoard with JIRA or Trello to manage bugs and issues makes it possible to be agile while making sure that they are not ignored and become overwhelming. Prioritization also helps sort issues which are critical against those that can be handled later. Being pragmatic is an important part of being agile, as also mentioned in the Agile Manifesto under “Responding to change more than following a plan”.
Final Thoughts
Getting the agile mindset in place can do wonders for the collaboration workflow. It can enable teams to move faster and develop better, keeping in mind that the user’s goal is the unifying factor. Having a solid foundation based on, among others, the factors listed above can help agile teams grow into fledgling units. Like mentioned in this article on Atlassian,
Once the team is in place, it’s important to remember that agile teams are like individuals: they take time to grow.
zipBoard gives you the power to track issues in whatever process or methodology your team follows. Contextual feedback that keeps every team member on the same page, without any hassle to share designs or live project.
zipBoard is an all-in-one issue tracker and task management tool, whether you want to couple it with JIRA or Slack — whatever your workflow.
