After around two years I started working and writing software, 17 people got together in Utah and mounted, in the backdrop of Wasatch mountains, one of the massive heists on the prevalent software development methodology those days. That methodology was called waterfall where work used to flow downstream from the project manager to the developers. And as Newton would have it, it was kind of unnatural to get the water up back. So it was pretty much a one way flow. And then if you loved coding, there was a long wait and test of patience ahead. A whole lot of fancy abbreviated documents that had to be gotten out of the way - RD (BRD, FRD), LD (HLD, LLD) … before you could get your hands on vi’s, emacs’ and eclipse’s of the world. So, after a good round of skiing, the 17 wise folks decided they have had enough and came up with a manifesto which after 21 years, still remains robustly relevant. Agile changed the way we wrote software and for good. This post is not about why agile is good - enough literature on that; I want to point out 3 key make-or-mar areas which demand highest attention if you wish to roll out successful products or products successfully.

1. A key tenet of agile is empowering the teams who are (supposed to be) a bunch of motivated individuals, are self organising and are the ones that will churn out best designs and architectures and know what will it take to deliver. Let them set the targets and then let the alignment be done in other corners from inside out. Any top down target can at best be academic and will just be a source of heartburn. While it is also important to not let overarching organisation timelines be subjected to the whims of product development methodology, but the perennial delays in projects of all shapes and sizes do tell us that traditional planning process has to be re-thought through carefully.

2. Working software has to come out sooner than soonest, no debate! Even in large (extra large or huge) product development, we have to figure out the stories that can come together and light up the epic in production. This is one of the most difficult to achieve and the most critical. You might often find yourself spraying and praying that after 100 sprints, it will be all done. How all of us wish this was as simple as that! The more you keep working without anything to show for, remote become the chances that you will ever reach the destination the one you envisioned when you started off. Especially in larger products, its very difficult but that’s where the ingenuity of team lies - how to identify, keep identifying and churning out smaller working chunks.

3. From the frontest-line business person to the engineer in a far away scrum team, the channel of communication has to be open - some way or the other. And it should always be alive and kicking. Quarterly meets are not the things any more. While agile lets you enjoy the luxury of changing the requirements whenever needed, but falling back on this attribute is not doing justice to the overall effort as you would have gone way down the road before you start correcting course. Identify the potential change at the earliest and then follow up with change execution.

If you use agile in true spirit, you won’t have to worry about burying the ghosts of dead products.