Fast-paced business environment calls for the constant need to adapt to the changing market conditions. This is so much true for those who are building software – to help them come up with a highly iterative process that will focus on rapid delivery of a product. Agile is a process that values collaboration, a working software, and continuous improvement so that projects can be successfully deployed.
I have always been inspired by these 12 principles of Agile Software drafted by the Agile Alliance. In fact, our team practices this by heart and we never skipped a heartbeat, poetically-speaking. It was that one fine day when I started revisiting these and I was wondering how to make it better:
1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Is it enough to simply satisfy the customer with the finished product and leave them out of all the technical spaghetti? Maybe. But wouldn’t it be better to educate the customers on how you will achieve that minimum viable product?
2 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
What if the changing requirements is at polar opposite of what you have tediously worked on? Should you still welcome it? Unpredictability will always be there so maybe we should only welcome changing requirements that makes sense and are realistic.
3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
I am all for frequent delivery and rapid cycles but then, there will be times when your client will change requirements right before you complete that delivery cycle time and the timescale becomes longer. Or, how about those who don’t give a monkeys over what you are working on right now and only cares about going live? Maybe, delivering work updates more frequently is a better term here.
4 Business people and developers must work together daily throughout the project
Some clients complained that more meetings meant we are not productive and that made me question this principle. When you are working on the other side of the world, meetings can become a burden. Maybe, this should say: Business people and developers must communicate daily throughout the project – then, this is less stressful; it doesn’t commit anyone to talk to you at 3 a.m. in their local time.
5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
This is easier said than done. Trouble is, what exactly motivates your team to do their jobs? I agree with trust though and it’s still a work-in-progress for many (myself included).
6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
This line really needs rewriting, IMHO. In this mobile age, it is tough to be in the same room with people across the world. I believe that with the deluge of online communication and collaboration tools, having clear and specific requirements are more effective than a face-to-face conversation.
7 Working software is the primary measure of progress
I totally agree, but would love it if the customer will see it as a measure of progress as well. Most often, they will find bugs or find some items not to their liking in terms of UI.
8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
Working longer hours doesn’t really mean being productive. Most often, you may run your team down, so much so it makes them sick. Let us try to define ‘constant pace’ better here like, does it mean constantly delivering work on time? Or, constantly delivering quality work all the time? Both would be ideal.
9 Continuous attention to technical excellence and good design enhances agility
I believe this line item answered my questions above. And maybe, we can also add ‘Motivation’ to have this continuous attention?
10 Simplicity – the art of maximizing the amount of work not done – is essential
I wish it were that simple when you are working on complex projects with multiple requirements. No matter how basic a concept is, if someone in your team doesn’t understand it well, you’re doomed.
11 The best architectures, requirements, and designs emerge from self-organizing teams
I want to question this a lot: What is creativity without purpose in the world of innovation? At some point, even self-organizing teams have to map out their strategy on delivering the best solutions they can come up with.
12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
In an ideal team, yes. But reality is, not everyone is a team player, no matter how you trust and believe in each person’s skills and capabilities. This is why you have a scrum master.
That’s all there is to it, I believe. No matter, these agile principles have helped us through thick and thin just to get to that phase where we launched and said: WE DID IT!
And we will definitely do MORE 😉
Looking forward to better ways to serve you this 2016. May you have a prosperous new year and all the best to come with it…
