What "Being Agile" is Really About
The motivation for this article came naturally working on a presentation for my team on engineering process, Agile is playing a big part there. My thought was that this might benefit others as well, if documented here.
Starting a year back I found my self in an interesting position that requires me to manage engineering for a FinTech SaaS Startup. For us like most startup agility is key, knowing that we can make quick course corrections to fix our trajectory, which always looks like it's not slowing down.
What's Is it Anyway?
To make sure no one is left behind, let me give the quick primer on agile. For this we must travel to the agile temple agilemanifesto.org. This masterpiece of HTML design, outlines the following.
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
The main takeaway is the focus of where effort is placed. It's placed to align with the mission and vision of the company. This is not a call to diminish the quality of software and the craft of engineering, but a scope to implement it in.
Agile isn't about getting that certification or using a certain process, It's about doing what's right for your business or cause.
Embodying The Manifesto
The application doesn't stop at a singular level. Some believe that agility takes place in the ideation and development cycle of a product. It's much more than that. Any surface area that's touched on the process of delivery can benefit from the agile way.
The "How?" is left vague by the manifesto for a reason. To allow for each adopter to figure out, as with circumstance there is no one size fits all solution. But here are some guidelines to adopt it,
- Start with as minimal process as possible, expecting a team to adopt a wide gamut of tools and procedures is bound to end in disaster.
- Collect Feedback, take feedback from the team. Take count of the pain points and wins, Using these make adjustments or alterations to the process.
Coming back to my point on how being agile benefits other facets of your company, The aforementioned procedure is not just scoped to get feedback on how a team operates, but the many artifacts or systems they might interact with.
For example software design, designing software that allows flexibility and collaboration which preserves agility.
Conclusion
The main takeaway is to know that there is no standard to follow. It's up to you and especially all members of your team to figure out. Hopefully it will stick. If not, don't fret as if you have followed the manifesto, course corrections shouldn't be as daunting.