Agile is not strict. In fact, agile is meant to be flexible. The concept comes with choices. Does your team use Scrum or Kanban? Are your retrospectives long or short?
This article examines the deployment of Agile, knowledge gleaned from deployment in multiple organizations.
- simplicity by maximizing efficiency at work
- early and continuous release of product
- cross-organizational communication
- working software as the primary sign of progress
- embracing change
The agile concepts and practices are some of the easiest to learn but maximizing efficiency does not mean having seven hours of meetings. It does not mean creating an unproductive comradery either.
Some of the pitfalls of deployment include:
- meetings that eat away at productivity rather than help due to their length
- a barrage of questions from various project managers that further eat away at productivity
- stakeholder meetings that degrade into requirements analysis if there is no product to release yet
- tickets that move into a Sprint or up a Kanban board in a way that slows the process down
Issues in deployment can cause a backlog to grow uncontrollably. The amount of work can grow if agile is not deployed correctly and flexibly.
For instance, at a recent company I worked for, the daily barrage of questions and meetings for the better part of a morning or day caused a significant slowdown in release times. The backlog grew by up to twenty tickets each week as pressure to complete tickets created more bugs.
Mounting pressure nearly created legal problems. In fact, as a new developer, I was the scapegoat for at least one problem, having a ticket offloaded onto myself only after a client demanded resolution and threatened a lawsuit.
Alleviating the Headaches
It is possible to alleviate the pain of deployment with a few simple measures including:
- finding effective project managers and team leads for each team that are the sole source from which questions and tickets are generated
- keeping meeting times small and encourage team members to find problems and solve them by embracing analysis of problems and their solutions at the appropriate meeting (some organizations look at an attempt to find the source of an issue as making excuses)
- finding an effective meeting length, often dedicating less time than recommended
- planning stakeholder meetings effectively around the release of tangible product and using the project manager wisely to keep in contact with and update clients
- utilizing software appropriately, keep teams as separated as needed
Clearly, there are decisions to be made regarding separation and time. Failing to address these problems can be deadly.
Tinkering with these resolutions, I have found that stakeholder meetings happen sporadically at first, ensuing as recommended after a product becomes substantial. Requirements gathering is itself a continuous project. I have also found that early stage projects can often make better use of Kanban, allowing for more flexibility, while established projects make better use of Scrum, when tickets are defined at the backlog grooming and retrospective.
While agile methodologies are effective, they are by no means inflexible. They were not intended to be. Using your time effectively is at the root of any project management philosophy.
Proper use of agile with a precise application for your organization is the key to maximizing effectiveness.