First Time Agility

First Time Agility

I was into my 8th year working as a Software Developer. Throughout my career, I had worked under traditional project management methodologies. Recently I heard that some modern project management methodology, known as “Agile” is getting a lot of attention. Personally I was not too thrilled to explore more as I was very much satisfied the way things were going on. I worked in a well renowned software development company with over two decades of its presence in location as well as the International market. 

My smoothly running professional life was all turned upside down when the news hit me that our company has been awarded a large scale project. Getting a new project used to be an exciting affair but this was different. The reason was that this project was supposed to be executed following Agile Methodologies and like everyone in our team, I was also totally alien to that. Problem was that it was a large project which was recognized at International level so staying out of it was not an option. 

One of our senior managers went through some “crash courses” online and the management also shared some material with us to go through and unfortunately none of it made any sense to us. Anyways the project started and a team of “Product Owners” defined the backlog and wrote the User Stories. The first sprint planning meeting went on for 4 days as the first day was totally utilized in understanding and building a consensus about the processes. The rest of the 3 says was utilized going through the Product Backlog and trying to pick items into Sprint Backlog. Since senior management was also part of this experience so we were not too worried about the outcomes. Also it was early days in the project so traditionally we were used to not to take them too seriously. 

The Sprint 1 was decided to be of 3 weeks and the team and project manager worked together for the first few days breaking User Stories into tasks and on their assignments. We started on our respective assignments and before we could really get into it, the sprint was over. Most of the developers were barely half-way through their assigned tasks which the QA team was yet to start on any activity. 

We learned that we had taken up much more work, in the sprint, as compared to our team’s bandwidth and also the QA team was not required at this stage. So we made some changes and Sprint 2 was extended to 4 weeks. We dropped half of the User Stories we committed in Sprint 1.  The QA team was also not part of any plans in Sprint 2. Sprint 2 went much better as we were able to complete all the work in the first 2 weeks as most of the work was almost half done in Sprint 1. But the last 2 weeks of sprint 2 were just passing time as there was no development work left and there was no QA team to test and report any bugs which might have required bug fixing by the developers. 

By the start of Sprint 3, the project manager was able to gain more knowledge about Agile Methodologies, so he decided to have an “Estimation Session” before Sprint 3. During the estimation session, we experienced the “Planning Poker”. Again this estimation session went on for a week because every User Story started with a lot of variations in estimates form the participants and was followed by long discussions to build consensus The other problem was that most of us were only focusing on our concerned areas. But the major issue was that most of us were used to agreeing to estimates under “Halo Effect” previously so it was really the first time for many of us to think about the estimation part. 

Anyhow the Sprint 3 started but mid-way through that we were stopped by the project manager and announced the immediate start of Sprint 4 due to change in priorities. The Sprint backlog for Sprint 4 was set by Product Owner only with having any planning meeting. The same thing happened during the Sprint 4 and was terminated mid-way due to change in priority. As a result of that the team decided to stop using sprints and just work on the User Stories like we used to do in the good old days. 

After a month or so, we were informed that the project had been taken back by the client as a result of an audit conducted by their consultant. As per audit report, we had over-run schedule and cost by a great deal and also were not following any Agile practices properly. It was really shocking for the whole organization because that was not the case. We all believed that being agile meant being able to adopt changes you feel are good for the project and mentally should be ready for change in assignment any time. 

Few years later, I happened to attend a training session on Agile Methodologies and after that I was really amused about our understanding, as well as the execution, with Agile Methodologies. 

Share this post

Leave a Reply


%d bloggers like this: