Agile Manifesto — in the beginning….
My daughter starts Year 2 Software Engineering in university next year. Due to a series of events, life has presented to her a mini express path and she entered university at an early age. Kids like her, and many young people in this new generation have developed multiple websites, Python programmes, own multiple AWS accounts, and a kanban board to visibly track things. Embracing and practising Agile like a fish in water, she is the new breed of software developers who has been taught Agile right from the start, and started it right. To contribute to her growth in learning, it is my honour and pleasure today, to take you back to the very beginning, and share with you the Agile manifesto.
Here’s to you, Megan and all your university mates. :)
In the beginning…
The Agile manifesto was first conceived by 17 people who met in a ski resort called Snowbird in the Wasatch mountains of Utah, USA. They were looking for better ways to develop software. While there is value in the items on the right, we value the items on the left more.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Individuals and interactions over processes and tools
Processes can no longer be blindly followed for the sake of following the process. Process in itself is not a bad thing at all. Especially in large enterprise organisations, processes are required to keep things in a neat and orderly fashion. It is the individuals and interactions that are more valued over merely following processes and tools.
New ideas and innovation happens when you have conversations with individuals and people to gather insights and feedback.
How often have we gained so much from a good unconstraint brainstorming session in a cross-functional Agile team where the diversity helps bring a different view point to the problem you are trying to solve.
I have seen the magic of getting end-users and a cross-functional team of developers and testers, and including external vendors, all into one room. The reduction of processes and bureaucracy resulted in such productive meaningful discussions around the table.
The question to ask here is: How can we make this better? How can we help improve things?
It could involve sending surveys, reaching out in social media, attending Meetups, or the good old coffee chat. The benefits you reap will be huge as golden conversations will spark new ideas and get early valuable feedback for that amazing software that you are developing.
Working software over comprehensive documentation
Documentation is written when necessary and written for the sake of adding value. Not just for ticking a box, not for the sake of following a process (refer to the previous manifesto), and definitely not for the sake of printing and binding it up into a huge thesis. Imagine if you paid the Consultant an hourly rate to write a 1000 page document that who will read. What time wasted, money wasted, talent and opportunity loss it will be.
Most sadly, not a single line of software code has been written. Say for whatever reason, the project financial sponsor decides to stop the project, you will be left with nothing but a 1000 page document. Instead the valuable time could be used to develop a small PoC (proof of concept) working software that experiments a key competitive advantage or proves a solution to a technical challenge. Wouldn’t that be more valuable?
The analogy that I often use here is the electrician that comes to your house to re-wire your electric wiring. Sure you would like him to put some stickers at your sockets and plugs to label the wires that go to your TV, or HiFi. But you sure don’t expect him to produce a Word document detailing where all the wires behind the walls go to which part of the house. It is the working electrical lights that is more valuable. Similarly, it is the working software that is more valuable over a 1000 page document that will be never-ending to read and often very soon out-of-date in this age of technology.
The keyword here is value.
Customer collaboration over contract negotiation
A scenario is when the software developer is the supplier working to develop software for a customer. Legal contracts are still required. But the focus is on the collaboration. Contracts should be put in place to foster collaboration and benefit all parties. Contracts should ethically not be a win-lose situation. And this is where Agile nicely disrupts the legal world. The key to this is to get your lawyer or legal rep engaged right from the start.
In this fast pace modern world, the value is in establishing partnerhips and trust with your customers. The software that you develop will need to be iteratively released to experiment and get learnings quickly without the heavy overheads of writing and revising contracts back and forth.
Responding to change over following a plan
Last but certainly not least, responding to change is one of the key strengths of Agile. When you see a change coming, assess the change and respond accordingly. Be comfortable with unknowns. Be comfortable with re-plans. It ain’t gonna be perfect the first time, and it’s completely ok.
The analogy that I often use here is the family vacation. How often have you planned for a family vacation and no matter how detail or precise the plan was, how often have you found yourself having to change the plan? Take detours due to roadblocks?
Enjoy the scenery as you take the other path!
It does not mean you do not plan. You still do need to make a plan. In Agile, we plan even more regularly - on a daily basis.
Relax and enjoy. Change is the new normal.
Summary
And so, Megan, this is the Agile manifesto. Who knows, true to Responding to change, the Agile manifesto may one day evolve again, or fade away into the distance in galaxies far far away. My wish for you is that you will keep the true spirit of Agile burning brightly with you always. One day perhaps you will bring your children and grandchildren once more, back to the beginning….
