Rewriting the Agile Manifesto for the New Year

Agile Methodology | 0 comments | by Shaz Ide

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…

Tags: , , ,
Image MapDesignImplementAcceptDeployAnalyze
Close

DESIGN

We will prepare the experts, process, environment and roadmap needed to achieve your goals

Close

IMPLEMENT

We will bring together talent, innovation and technology to work on your project's blueprint.

Close

ACCEPT

We will give you quick access to our people, methods and infrastructure to help improve on each project iteration.

Close

DEPLOY

We will execute the solutions to complete your --' project and transfer knowledge, while protecting your intellectual property.

Close

ANALYZE

We will define, study and clarify with you the scope and limits of your requirements.