Agile Manifesto and My Experiences

Here, I am sharing Agile Manifesto and my experiences with it.

Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it.

Description Experience What I feel?
Individuals and interactions over processes and tools Direct communication is better but existing culture still relies on Email communication and keeping records and taking permissions in Mail to be on safer side and keeping record. Though it was useful to have conversation with Business Analysts to understand the User stories and its requirements Trust is a very important factor in a team and Geographical distance is a challenge in the process of communication. There is a need to change the traditional culture and bring trust factor into interaction so we don’t become slave of traditional approaches while adopting new methods
Working software over comprehensive documentation Pick up the story, Create tasks and work on the task for providing resources in Microsoft Azure Environment, configuring applications for authentication and authorization or creating database from the BACPAC File. Once tasks are completed and there is a time before Demo or after the Demo, Documentation can be created at High level for Project Documentation while Lower Level Technical details can be documented based on the availability of time. Demonstrable piece is always preferable over highly documented processes which are loaded with text. Demo of 30 minutes is worth than having a 300 Page documentation any day. However, for reference purpose documentation is important part of any sprint and it needs to be a part of Habit/Practice for effective records and future needs
Customer collaboration over contract negotiation It is all about conversation and flexibility. Business scenarios and architecture of the solution changed multiple times in the initial phase considering security restrictions. Though it was not a ideal scenario and it created chaos but it was more because of lack of understanding in the Agile approach. Architecture was finally decided based on the collaboration with the Customer based on many discussions and their comfort. Being nimble or adaptable to business changes is extremely effective rather than having a rigid contract based requirements to perform tasks.
Responding to change over following a plan There have been many situations where many changes happened in the course of Sprint, at the end of Sprint or even at the beginning of Sprint. We were reluctant to those changes considering the fact that it would affect our implementation time and we might not complete existing tasks on time due to constant changes in the requirements This is a difficult part to manage initially while team is in a transition phase from Traditional approaches to Agile. However, Agile is all about change. Change is constant and it is always good to start “change” ASAP rather than waiting for specific point. The more it is delayed, the more it becomes painful. E.g. Initially we decided to have some kind of framework for application development which we realized later that was not a good and hence we need to change all the work of earlier sprints. Now, if we delay such process than it becomes more difficult and results into complete rework.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Small Sprints with demonstrable application. Suggestions from customers for improvements were also a positive change. Continuous Improvement. It is desirable to have customer with clear mindset on what she wants. Even if the requirements change, clarity on needs helps
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. We were not happy with  changing requirements, even late in development or at any time as we thought it may impact on delivery. Agile cares for better outcome and hence this is desirable. It is always a case where requirements will change in between the sprint or at the time end of sprint. We need to be prepared for such events.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. We worked in sprint of 2-3 weeks with selected user-stories. It gave us confidence on our capacity and enough time also to complete different tasks. Working application in with selected and limited features within the time-span of 2 or 3 weeks is confidence booster not only from customer’s standpoint but also it increases developers’ confidence.
Business people and developers must work together daily throughout the project. BAs and Developers (Development Team, Cloud Team, BI Team, Testing Team) worked together on a daily basis in a given sprint. Discussion for clarity in requirements was an important aspect and BAs are the only people who can give a clear picture to all different teams. Business requirements are pretty clear to them and it helps a lot in overall effort is communication takes place frequently.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. This is a difficult thing considering the culture of an organization. It was difficult to get into a individual mode and trust the work. There was an attempt to bring hybrid approach so new idea can be adopted keeping benefits of traditional approach but Agile framework wont allow it to work and here Scrum Master can be helpful. Experts to handle specific tasks are always effective and hence motivated individuals are more effective than multiple persons.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Mail and Chat conversation are prone to misinterpretation and chain of mails may not be helpful in getting issues resolved. It was easier for us to call and resolve the issue. However there was a resistance also because of the mail culture for proof on who said what. True, Words are source of misinterpretation if not accompanied by expression and positive intent. Face to face communication or a short call can resolve a issue in less time than chain of mails where we
Working software is the primary measure of progress. Demo was more satisfying to BAs and Customer more than Pin board or closed tasks or documents. To see an application in working mode is no comparison with any kind of documentation, processes or assurances.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Once we became comfortable with the Agile methodologies, we knew that we are confident to make proper assumptions and keeping the pace in accordance. Sustainability is key and Agile processes gives a proper guidance to achieve it.
Continuous attention to technical excellence and good design enhances agility. As tasks were assigned to an individual by herself, there was a tendency to become better and improve as responsibility and accountability is fixed. It is not only applicable to Agile processes but also in other processes. If we continuously focus on technical improvements and good design, it increases agility and adoptable to any changes.
Simplicity–the art of maximizing the amount of work not done–is essential. Do what is required that is what we did for each task of User stories. We used to make it simple while doing tasks and if BAs can also do the same then it is an added advantage
The best architectures, requirements, and designs emerge from self-organizing teams. Team was comprising of many small teams of different domain and inputs from all helped to create an architecture that was robust. Experts in a specific component of overall architecture can view it from a perfect point of view and
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. After each sprint, we knew what we did and what could have been better and within two sprints, we realized that it will help us to be better. It is always a case when we realize mistakes at some point of time and we should introspect and correct them accordingly.
Free Agile Scrum Cheat Sheet & Handbook:

Leave a comment

Your email address will not be published. Required fields are marked *