Agile, but let's not get dogmatic

This post was written together with ChatGPT, it says what I want, but I don’t like the style. That’s quite hard to fix it seems.

Agile methodologies are often implemented in corporate settings for their promise of shorter feedback cycles, adaptability, and meticulous traceability. However, the true essence of Agile goes beyond mere imposition. An agile software development culture will organically grow from sound foundational best practices and a collaborative, open corporate culture. Code reviews exemplify this, serving as a best practice seamlessly harmonizing with non-dogmatic Agile principles.

Starting a project, creating a backlog Link to heading

A backlog is created by a team that defines goals that resonate with the intended purpose of a piece of software, new or existing. In an initial meeting many ideas can be gathered, or alternatively ideas are gathered asynchronously, a backlog may be open to anyone at any time, at least from a period of time. An issue tracker such as provided by popular Git based platforms is ideal for this purpose. This issues tracker will remain open for the gathering of good ideas, but also for gathering bugs and improvement suggestions as a project evolves. Old ideas may remain in there for a long time. They are not in the way, and they can be used for discussions, perhaps altering their scope or purpose.

Priority setting, aligning on targets Link to heading

The backlog, or by now “issue tracker” will be full of ideas and issues that may or may not align directly with the goals of a project. It is important to prioritize the issues, perhaps tie them to a specific release date somewhere in the future.

Small, Purposeful Changes Link to heading

Developers commit to small, purposeful changes, solving issues from the centralized issue tracker in Git branches linked to the issues.

Kanban swimlanes: communicate what you are doing Link to heading

The order in which the issues are solved stems from a deep understanding of the customer or end-user’s needs. When a dev starts to work on an issue, the issue is taken from the priority-sorted issue tracker and may be put in a column on a Kanban board labelled “work in progress”. This way, a dev communicates to the team that she has started work on an issue or feature.

Clear Scopes and pull requests Link to heading

The code that solves an issue or adds a feature is ultimately offered for review by peers in a pull request. The pull request is naturally small and limited in scope as a result of respect for other people’s time.

Asynchronous Communication Link to heading

Asynchronous communication on a platform like GitLab or GitHub facilitates efficiency and respects developers time and attention. Discussion takes place next to the code changes, fully in-context.

Quality Assurance through Collaboration Link to heading

Collaborative quality assurance isn’t mandated but stems from a strategic culture where delivering a shippable product is a point of pride. Devs understand that anyone can learn from anyone and anybody may make mistakes. This is how we learn and grow.

Strategic Agility: Moving Beyond Imposition Link to heading

The focus in corporate agility should shift from top-down imposition to strategic evolution. Agile is not a set of ceremonies dictated from above but a strategic culture growing organically through nurtured best practices and a culture valuing efficiency and collaboration.

Conclusion: enforce Agile or stimulate agility? Link to heading

Agile should be a culture, not a mandate. By integrating deeper best practices and cultivating a corporate culture valuing time efficiency, Agile becomes a seamless strategic approach aligning with the values of collaboration, adaptability, and continuous improvement.