!Fall for faux agile:97 Things !to do
Enough ink is already spilled on this topic, nevertheless talking about it once again may not hurt.
A team that is adopting agile must adopt its underlying spirit.
Chaos is not agile; not planning is not agile. Scrum, did wrong, is not agile. In software development, doing “ceremonies” on a regular interval does not make teams agile.
To be agile in a real sense, developers should think about the entire software development life cycle, from a ticket in the backlog to the product’s build and release. Technologies, processes, practices, and the team structure should align to facilitate the business’s agility.
Agility means the ability to change over time; this agility has to be brought in by design, and every member of the team has to work towards it. Organizations should design a system’s architecture such that it allows the software to change without side effects. If there are side effects, then there should be a faster feedback cycle. Agility in software development comes by profoundly caring about what you are doing and doing the right thing.
A common anti-pattern for the development teams is to get coached on one of the Agile methodologies like Scrum or Kanban and start the ceremonies like the daily standup without any changes in the software SDLC or teams themselves.
Teams should embrace other software development tools and practices too, a few that come to mind which supports agility are
- Fully automated build and deployment pipelines
- Automated test cases
- XP Practices like TDD and pair programming
- Right workflows on the source control
- Well thought out system architecture
Finally, here are the values of Agile from the Agile Manifesto
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.