6 Signs Your Agile Project Isn’t Really Agile
More and more organizations are adopting agile software development processes and practices. But in many cases, these organizations have declared they are agile without actually changing how they develop software. Declaring that an apple is an orange doesn’t make it so.
These six key indicators can help you determine whether your agile project isn’t really agile after all—and if that’s the case, read on for some solutions.
1. Unrealistic user story planning
Your organization has user stories defined for a year or more. Those stories are also dependent on the completion of other stories, and changes in requirements require massive user story updates across the backlog.
This is typically a result of pulling your entire waterfall plan and placing it into a backlog.Try to adopt minimum viable product practices to select the most important features and break down stories so that they have no dependencies.
2. Irregular feedback
Developers lack context about the user experience. Feedback mechanisms from the end-users to the development team, such as user acceptance testing, bug reports, and user assessments, are not available, and no one on the agile team observes the actual end-users using the application.
Start by implementing a user acceptance testing session and expose the whole team to user assessments so they can better understand how to deliver for real end-users.
3. Stagnation over improvement
Despite a new software development lifecycle, things don’t seem any different. The team lacks any mechanism to learn or discuss areas for improvement, and no one takes any action to change.
Start with a retrospective at the end of each sprint and determine what actions you’ll take. Larger organizations can even do a retro of retros to roll up ideas, or used-focus retros to address one aspect of the process.
4. Lingering releases
You wait months between releases, and functionality never seems to be done. You are not able to deliver user stories to the end-users after each sprint. For your organization, meeting requirements is more important than delivering value rapidly.
Have each user story provide end-to-end, releasable features whenever possible. Using minimum viable products will ensure that “perfect” is not the enemy of “good enough.”
5. Silos over collaboration
There are long delays getting through one part of the process, and each stakeholder has their own backlog in a sprint. Stakeholders required to deliver software act in isolation. They are not part of the stand-ups, sprint kickoff, or sprint review.
The agile team is more than a bunch of developers and testers; it should include all the required stakeholders to get a feature designed, built, tested, and deployed. Separation guarantees delays, rework, and misunderstandings.
6. Bottlenecks
You often wait on a single person to package, deploy, or test your application. Manual processes are tolerated when they could be automated. Bottlenecks slow or halt progress when someone is not available.
Iteratively adopt a DevOps culture by adding practices such as automated testing, continuous integration, and continuous delivery. With each sprint the team should identify bottlenecks and work to address them. Some capacity is committed to automating a practice that was manual in the previous sprint.
