My Journey from Waterfall to Agile!

My Journey from Waterfall to Agile!

As I move to this new role of an Agile Coach, I guess it’s perfect time for me to blog about my Project/Product Management experiences. So, this is what I call my journey from Waterfall to Agile!

Although I’ve managed lots of different products and tons of huge projects, I would like to share the experience of two of my biggest project failures! Why failures? Because that’s the reason why I’m agile today:)

So, I still remember the excitement we all had when the organization cracked this huge deal with one of the world’s leading publishers. This was back in the year 2007 when they wanted us to create a mobile app for one of their best-selling cook books that had almost 50,000+ recipes. This was considered as huge data at that time and all this data was given to us in the raw format of pdfs and some files in word doc as well. The challenge was to convert this huge data into XMLs so that it can be later integrated in our technology platform to get the application ready. It was a very time-sensitive project as this app was supposed to come pre-loaded in the Motorola Razor devices which already had a set launch date. We had a very small window to get this product up and out!

We started-off the project well and did this laborious job of converting the content into the desired format (which was later automated) like splitting the text into different fields like ingredients, serving size, method, tips etc. Also, made sure text encoding was correct and was supported by that one handheld device.

The biggest mistake that we did was to not release the content in batches and followed the old traditional waterfall methodology to manage this project. The project timeline was only 3 months and we spent 2.5 months in just converting the content. And once the conversion was done, then the development team started coding. And then they had their own challenges like not getting the APIs on time and product not working as expected when tested. And guess what? This 3 months’ project was stretched to 3 years! We obviously missed the deadline but we did develop the product after our endless iterations.

“We failed”; “I failed”.

Another project was for a content publisher from Denver, in the year 2011. They wanted us to convert their 100 audio/video books to mobile and particularly for iOS devices. Since I was already here in the US by that time, I got this chance to meet the client on-site at their big and fancy office located in Denver, Colorado. We met this team at their office and got all the business/product requirements. We were quite confident about creating this app for them as this was the life-blood of our business. We had made similar products in past for various other different devices but we ignored the fact that iOS was new at that time. We still accepted the deal and committed them 3 months. (Deadline being set by them as the mobile apps market was hot and they wanted to be the first ones to get this kind of audio-visual mobile book out!) We had full knowledge about the required features but didn’t had any prior experience working for iOS. And we were so confident that we very conveniently ignored the risk that what if we didn’t receive the new SDK/APIs on time?

After presenting the first wireframe they wanted few changes in the design. After 3 weeks, the features were freezed and the development work started. Work was getting done but not in a way or order that it could be presented to the client and as they couldn’t see the progress they suspended the project! They thought our team was not efficient enough to handle this.

This was totally heart-breaking but we learned our lesson and moved on.

Although it was a team work and the project failed for various other reasons too, I took this a little personally. For days, I kept thinking why we failed and how we could have done things differently?

Later in 2013 my US work visa got expired and I had to move to a dependent visa. Sitting at home and not being able to do anything was highly frustrating for a workaholic like me! That’s when I decided to utilize this time and get some formal training and so I took up this Project Management in IT course at Harvard Extension School. Loved the structure and format of the course where the students were required to do a few case-studies every single week and then present their solution/analysis to the class. The whole experience of the course was amazing! I got to know many different perspectives from the students. We did our own individual projects and teamed up for group projects. So, I did this course and got rewarded as ‘The Best Project Manager’ too in the class but I still felt as if something was missing!

I got busy with my other courses and the focus got a little shifted but this year again while I was browsing through the catalogue I came across this course called “Agile Project Management”. I had heard a lot about agile but never had any chance to work using it so I took up this course.

Now, from last couple of months we are working on these two weeks’ sprint cycles, having regular retrospectives, doing scrums and making user stories day & night. The transformation is phenomenal. But it wasn’t this easy as it sounds because when you move from waterfall to agile you need to “unlearn the basics”. Those basics of project management that you have been using from decades. Every single time we started a new project, I had this fear. Fear of change, fear of scope creep! And then every single time I had to convince myself by saying that, “it’s okay to not have all the requirements in place right at the beginning” and “the scope is bound to change”.

But when I say we need to “unlearn the basics”, I don’t mean that every single project must go agile. NO! There are various other techniques available like Lean, Kanban, Hybrid. You just need to make the decision that when to use these techniques and where?

Kanban is a great fit for operations/support teams that need to react quickly and don’t have the luxury of fixed-length iterations whereas Waterfall is good when the outcome is certain.

Here are certain things that you must follow to survive in today’s agile culture:

  •  Take baby steps…Just Start!
  •  Embrace the Change
  •  Agile is all about building relationships. Choose individuals and interactions over processes and tools
  •  Focus on delivering the highest value item/feature first
  •  Be open to new ideas. It may be hard at the beginning but it’s vital
  •  Let go of knowing. When you’ll let go of the knowing, you will be open to new learning and that’s the only secret of being Agile!
  •  Communication is the KEY
  •   PRIORITIZE your work

And last but not the least: Attack ‘Issues’ and not ‘People’

With the rapidly changing technology and IOT coming into the picture, most of the IT projects should ideally go agile. Especially in the Data Analytics industry, where you need to keep up with the pace of the constantly changing data, there’s only one way – Go Agile or go Home!




Jay Logelin (lodge)

Polyglot Software Engineer ?? | Technical/Research Advisor | *?????????????? ????????

7 年

Great read Menka. I remember shifting over to agile from waterfall from the software engineering side of the house. As with any change, it was initially uncomfortable but very useful in the long run. I think a lof the of the developers I know now prefer this method of iterative development/delivery, however, perhaps surprisingly, it is hard to find a PM that "get's it". Great to see HES offering programs to address this gap and great to see you filling it!

要查看或添加评论,请登录

社区洞察

其他会员也浏览了