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.
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.
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:
- Factor in the nonfeature requirements (NFRs) right from day one.
- 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.