When Agile Isn’t
Why has agile become so rigid? Increasingly agile is being defined as the processes you use within software development. Agile, seemingly, is synonymous with sprints and stand-ups and burn-down charts. And if you don’t follow the leader on the latest buzz words then you are not agile.
The original agile manifesto gave no consideration to the processes used to implement the principles it espoused. This was left up to the practitioner. Agile was a movement away from rigid processes. If everybody involved embodies the principles, then the practices will follow and are in fact of much less importance than the actual principles. But people, in general, are not good at following principles, they need concrete rules to remind them of how to implement the principles. This is unfortunate and, over time, leads to the loss of true agility and following rules for the sake of rules.
Your World
Processes are necessary and important but must always be refreshed considering your current environment. And this will change over time – so it’s not a once and you’re done effort.
There should be as many different agile processes as there are companies using agile. Each company needs to setup (and continually refresh) a process that is tailored to their specific needs and culture. A government department will have very different needs to a start-up software company. An agency building software for other companies has a very different set of needs to a company building in-house software.
The Stand-up
A regular, relatively quick, informal meeting is a great inclusion in any agile process. It can really add value to keep the team on track and on target. However, the insistence that is must have a universally applicable time limit, and certain words or phrases can and cannot be used, and all discussion should be discouraged, introduces rigidity. This key meeting must work for you to achieve your aims. If it is just a rote reciting of stuff you can read in a report it loses its value very quickly and becomes something the team dreads as a waste of time.
Instead, the importance of the stand-up is not just for setting of scope and determining blockages -although these things are important. The deeper value of such meetings is in setting the culture of the team. This regular time will have a key influence on how team members relate to each other and how they relate to the wider company.
If you, as a company, value a casual environment then keep the meeting light and allow friendly conversations. If you value respect, then ensure that people are treated with dignity and never put down in front of their peers. If you value truth, then ensure that the team is informed of all changes within the organisation that will impact their ability to do their jobs. If you value the efforts of your team, then ensure that regular feedback is given for a job well done. If you value openness, then invite feedback and don’t shutdown discussion simply because it is negative. Live the values you want to see expressed within your team.
Doing these things doesn’t mean the meeting has to drag on forever. Be flexible with the duration. It might only be 5 minutes or might be 30 minutes. You also don’t need to have it every day. Perhaps 3 days a week works for you.
The Cycle
The two-week sprint has almost become synonymous with agile. But this is not the only way to control the flow of development. It also has some inbuilt inefficiencies. Let’s go through the three main variations of development flow.
- Iterative Planning, Iterative Deployment. This is the traditional scrum approach. Each sprint is planned at the beginning with a fixed number of tickets. All tickets are deployed together at the end of the sprint. This makes the planning phase a critical task – too many tickets and you must cut tickets at the end of the cycle; too few tickets and you have idle developers at the end of the cycle.
- Continuous Planning, Continuous Deployment. This is a traditional Kanban model of development. Tickets are prioritised on a backlog and can come into the system at any time. Tickets are deployed as soon as they are ready. The main downside to this approach is that there is no lower limit on how often priorities can change. This can lead to churn.
- Iterative Planning, Continuous Deployment. This is a hybrid approach. Plan the priorities of the backlog and how much you think you can get done in the next cycle. But this does not have any impact on the development cycle – that continues to progress as in a basic Kanban style.
Reporting
There is a basic need to track outstanding tickets with enough information to capture the intent of the effort. Other than that, the basics of agile favour the working system over documentation. Documentation is mainly required for the following purposes.
- Tracking the outcome of planning sessions as a record of the consensus achieved
- Assistance with planning by providing metrics to estimate velocity for the next cycle
Other than these, the reams of documentation and charts are often about justification. Different stakeholders use the figures to justify the need for more staff or less staff or pinpoint a lack of effort. Too much documentation can be an indicator of a lack of trust between the development team and the rest of the business.
Reporting should not be used as a replacement for trust but as a means to build trust.
Your Experience
So, what has your experience been with Agile processes?
Bit Wrangler
6 å¹´I haven't seen anything remotely 'agile' in my last three jobs. They're all variants of a Cargo Cult--put coconut headphones on, build a bamboo flight tower and airplanes 'should' land there, right? Do the Scrum rituals and the Agile God will bless you with Good Software.?
Lead Engineer - Automation | Practice Test Lead | Program Test & release Manager | Quality & DevSecOps Enthusiast
6 年Nice write CP,we share a same view and it worked well for us in our team. It all comes to team members how they want to incorporate communication and move as one. At the same time some team it worked well to have a daily standups as well,so all comes to team and team members and how it’s benefits.
Android Developer
6 å¹´Pretty good write up! The way I feel about stand ups in particular is that they are often a bit too prescriptive and in that context I see them more of a remedial measure.? What I mean by that, is that in most teams I work in, the communication happens organically and unprompted through the entire day.? In that context I question the ceremonial gathering of bodies as it becomes a step to rectify a problem of communication that doesn't normally exist.? It of course depends on the team, some can be hopeless at communication if it is full of the types who would end up sitting on a problem without reaching out to others for help.? In reality that person is the problem in the team, but solving it by burdening those that are self managed and good communicators can sometimes frustrate them with the resulting ceremony.? Basically, agreed that Agile should be what concepts work for a team and should be tailored to that team.
Agile Consultant / Agile Coach
6 å¹´I can see we share a similar views ?? Good read.