Agile
Agile development is one of the more profound professional concepts I've come across. I've seen aspects repeatedly emerge organically. I've also seen a dogmatic approach fail repeatedly. I think it's largely an effort to bring order to chaos. Perhaps that could be said of all human activities :)
Standup
Whatever the period, I think the standup serves a couple purposes:
- Aligning work with goals
- Coordinating work
Regularly revisiting goals helps me stay on track and resist entropy.
I've seen attempts to organize using Agile principles fail repeatedly due to over-complicated process and tooling. The agile principles state "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." Verbal alignment structured around a simple prioritized list may be sufficient. For example, "What are our goals and how are we progressing?" Given all the tooling, processes and trainings available, this feels naive or heretical, but revisiting the manifesto, I see "Individuals and interactions over processes and tools". I think the standup might have originated explicitly to reduce tooling and process.
The idea of a daily standup might have emerged in response to chaos substantial enough to require daily alignment. The manifesto does emphasize "Responding to change". I think a one-week alignment period is a good balance of meeting overhead and mental capacity. I have the most consistently successful experience with a Monday kickoff ("What will we do this week?") and a Friday demo ("What did we do this week?"). I've also seen teams collapse this into a single mid-week alignment, starting with the demo and ending with the kickoff, and am curious to get more experience with this.
Alignment with a larger organization can use the same pattern, but with a longer period. For example, include sister teams once a month, prioritizing content accordingly.
Shippable
Always maintain a shippable product. I don't see this verbatem in the manifesto, but I associate the phrase with agile. I do see "Working software" emphasized. Perhaps that's the connection.
Failure to follow this best-practice has bitten my team more than anything else.
It's easy to forget amidst pressure to ship features requested by customers and cut costs on clean-up invisible to customers. Perhaps the manifesto emphasizes the working state because it's so easy to forget.
A common manifestation is forking a project to build a new version, and then building new features only in the new version, which blocks the release of those features on the release of the new version. The new version becomes increasingly hard to ship as the feature set diverges from the old version and regular customer feedback. Building in the new version is tempting because it's free of legacy cruft and built with latest conveniences, but the old version is also the "working software" in production. If plans change, or we just need a day off, the old version is the only version customers will see.
A few things that have helped me maintain awareness:
- clearly identify refactors
- always identify an interface, or current behavior, before refactoring
- avoid adding features while refactoring
- assert behavioral parity after refactoring
Customer
A focus on customer needs has been a critical tool for self-organization. When in doubt, we can talk to customers and/or be our own customer, see what's missing, build it, repeat. As Paul Graham wrote in his How to Get Startup Ideas post, "The very best startup ideas tend to have three things in common: they're something the founders themselves want …" In the absence of (or perhaps in addition to) hierarchical mandates, identification with the customer helps ensure self-organization accomplishes useful goals. The principles state "The best architectures, requirements, and designs emerge from self-organizing teams."
Satisfying customer needs is also a source of joy worth focusing on, as in "Something I created made someone else happy". At risk of excessive abstraction, given humans are social creatures, I think biasing towards "Individuals and interactions" is a safe bet.