Get certified - Transform your world of work today


My Agile Expedition

Agile experiences

9 March 2016

My first encounter with Agile was in 2009. When I was brought on to a project, I was told that my role would be that of an Agile project manager. Although I could identify with the role of a project manager, the word "Agile" didn't quite ring a bell. "What is Agile?" I asked myself, my supervisor, and pretty much everyone around me. The answers that I got varied from the vague "A new methodology or a new style of management," or "The client is keen for Agile" to "Your first interaction with the client is scheduled after today, so be prepared, and all the best."

I did what seemed like the logical thing to do at that time (of course, we had experts and information available in the organization, but I didn't know whom to approach, or how). I googled to gain insight into Agile. The search results were irrelevant; it didn't matter whether it made complete sense to me at that time, or that the answer has evolved to be more sophisticated over the years. What I knew at that moment was that this Agile expedition was going to be quite an interesting ride, venturing into unknown terrains with my best companion, Google. (Though I later relied on the organization's internal knowledge base as well.)

When I reflect on the past (or should I say, "retrospect"), it was indeed a bumpy ride, pretty much like when you learn how to ride a bicycle for the first time. However, that first raw Agile experience taught me one key Agile mantra: Inspect and adapt. With a minimal understanding of the processes, guidelines, tools, and ceremonies to follow, my team and I tried pretty much everything. We strived to bring out the best possible solutions while learning new technologies. We were free to commit small mistakes, and to gracefully accept this reality. I experienced many sunny days and sometimes a few rainy days as well.

Above all, we were a great team in the making, and we shared a good rapport and journey with the client and other internal groups. It was a professionally fulfilling moment when our project was considered as the best tool ever developed for that client. We were not only practicing but also living the Agile Manifesto and principles every day without realizing it. In 2010, I was finally able to connect the dots when I went through my formal Certified ScrumMaster® training. Finally, I had the professional terms to appropriately label what we were doing.

So, after being on an Agile expedition for all these years, having executed many projects in various flavors of Agile (mainly Scrum) spanning multiple geographies, clients, teams, domains, and technologies, the key mantra for me still holds true: Inspect and adapt.

As I heard earlier, there are no best practices, only better practices developed over a period of time. While most of the practices will resonate with general best practices of Agile, these are frequently missed. So, below is a sincere attempt to share my key learnings to date.


Although plenty has been said and written about the importance of having a good team of self-motivated individuals for Agile, I can't emphasize enough that this is the most valuable aspect that needs to be cultivated throughout the organization.

Any investment made (collaboration, competency building, skill mapping, workshops) in team building, including the client, will go a long way in ensuring a successful outcome. Motivated teams can really turn around any difficult situation and actually look forward to such opportunities to test their mettle as a team. Maximize each opportunity for team collaboration. The motto that worked for us was, "Those who eat together stay together." As a team, we went out and had lunch or dinner, went to parties, or played sports together.

The other aspect is to be cross-functional. It's important that the team not only possess the varied required skills but is also ready to step out of their technical/functional/domain comfort zone and work together for what is necessary for the project. For example, in some of my projects, testing that was performed by business analysts and database members turned out to be very effective for early detection of errors and confirmation of requirement specifications.

Information availability

Real-time updates and availability of information is actually a good way to track progress without putting too much effort into separate tracking. Maximum use of collaborative tools, information radiators, or automated dashboards will provide a good mechanism for a continuous focus on output.

A team that is colocated and is able to have a daily stand-up meeting near the whiteboard area will find the practice to be very useful. In fact, updating a burn-down chart with the help of a pencil during the daily stand-up meeting is also perfectly fine if the team feels that it helps with the overall tracking. However, electronic dashboards and tools will be required for a distributed team. Personal updates (like someone being blessed with a baby) were also included on information radiators so that the team could celebrate together and plan to take care of that member's work accordingly and collectively.

Productive retrospective

The key indicator of a productive retrospective is that the team is open to discusssing key challenges or mistakes and will strive for improvement. Any key learnings and ways forward are discussed, agreed on, and put into practice immediately. The environment of trust facilitates an effective retrospective.

Definition of Ready and Definition of Done

A high likelihood exists for delivering a quality product if the Definition of Ready and Definition of Done are discussed and agreed upon at the beginning, and the team (including the client) commits to ensuring that it happens. Although this is a very obvious aspect, often this is not fully defined, the entire team is not made aware of it, or it is missed during the verification. A discipline to stick to these two definitions will help with effective planning, producing a quality product, and reducing cycle time.

Consider scalability and configurability from the beginning

One of my projects was developing a rapid prototyping model. It was going to be used at the beginning for demo purposes only, and for a selected user group. It was quick and dirty work (well, not so dirty, really, but it did not have a very robust architecture). Later, we were requested to add a few new features because the business users liked our prototype. It was put into production with access limited to only a few. Based on rave reviews and the ability to grab peak holiday season business, it was rolled out to almost 20 times more users than originally anticipated and, boom! The system crashed. It not only impacted their business for two days but the team had to work 24/7 for more than a week to stabilize the system.

The key lessons learned:
  1. Factor in the nonfeature requirements (NFRs) right from day one.
  2. Undertake separate development, including all NFRs (scalability, performance, accessibility, etc.) and discard the prototype even though it can cater to the immediate need "as is."
I am sure that all agilists out there must have experienced some or all of these challenges. Feel free to add your leg of the journey. As for me, I am still on and will continue to be on my lifelong expedition.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.4 (32 ratings)


Jayarajkumar ayyappan, CSM, 3/9/2016 10:16:50 AM
Good one,being scrum master you should have faced the situation two people complaining each other or compete each other...can you share your experience on that..better way to handle it...
Prerna Kale, CSM,CSPO, 3/9/2016 11:11:38 PM
Good article
Prerna Kale, CSM,CSPO, 3/9/2016 11:18:18 PM
Can you elaborate when you mention undertake seperate development and discard prototype?
Architecture vis evolving in agile project. So considering NFR like performance etc should be definitely thought about in advance but can be tested during sprinting so if challenges persist you may need to evolve your arch needs. why do we discard is something I would want to understand.
Ajaykumar Kolte, CSM, 3/10/2016 4:18:08 AM
Thanks for the marvelous article! I seriously enjoyed reading it, you can be a great author...and I want to encourage yourself to continue your great work...
Priti Vyas, CSP,CSM, 3/10/2016 7:40:40 AM
Hi Jayarajkumar, While healthy competition should always be encouraged, if associates are complaining about other unnecessary, the best thing to do is to bring perspective within the team. Listen to both sides of stories and coach them to resolve their internal differences. Agile facilitates more collaboration by daily stand up meetings, planning and retrospectives. Once team understands the importance of team work and outcome lots of differences will decrease. The key as a SCRUMMaster is to always facilitate neutral view and lots of opportunities for collaboration.
Priti Vyas, CSP,CSM, 3/10/2016 7:51:13 AM
Hi Prerna, The options I mentioned was either of them. For ex, either think about all NFRS (even though not explicitly mentioned during requriements) and build a robust backbone that can evolve to undertake new changes. The other option is treat development of prototype as POC only (the example that I have provided) but in that case since you have not spent much effort on building a robust backbone, you should discard (of course you can pick up code of some reusable components) the prototype and build a new system considering NFRS. What happened in our case that since prototype was serving the need, we added new features to same prototyppe which was not built considering scalability ). Hope it answers your query.
Pranav Gupta, CSM, 3/14/2016 9:36:41 AM
Nice article!!! Very well expresses the journey a person goes through when beginning with the Agile experience :-)
Durba Biswas, CSM, 5/11/2016 11:38:00 PM
Well articulated Priti
Darryl Williams, CSM, 5/12/2016 4:37:22 PM
Nice job, Priti. I would like to add that prototypes constructed by business-directed resources separate from the Agile development teams is a great communication tool for the Product Owner in team discussions but has no place being injected as product, ever. They can also put a face on those pesky NFRs.

Thanks for contributing your experiences and insights.


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up