How I started working Agile

In 2008 I was working as software developer at ScanJour A/S and assigned to one of Denmark’s largest public IT-project. The Danish national security and intelligence service (PET) needed a new internal web based application. Eighty consultants was assigned to the project.  I took the role as team lead to help out the newcomers.

Losing track

Little did I know about project delivery and how to deliver what is promised in a waterfall process. Before development started there had been an effort of three years of designing the project. There was changes to the application flow, the layouts, the core application and much much more. I was given a group of six senior consultants. They where all developers and none of them knew the core. My team and I was assigned by the project managers to develop three areas with set dates for delivery and fixed requirements. Team foundation server 2008 contained a backlog with over 300 work items for my team only. Project managers and designers had already put there effort to fill work items with description and requirements. All project members worked on the same code base with TFS as task coordinating system. Later into the development phase we lost track. In fact all teams lost track both in delivery and project and timeline. Developers took time to understand the architecture and how to develop on it. The backlog continued to grow with more work and more incoming failed tests. We had many status steps in TFS and they showed where in the process a work item is. These status per work item gave us more confusion. We could not se what is delivered or what is set to done by us or the test team. The relation between test and development was not in one place. We lost track!

The turning point

I introduced a 20 minutes meeting every morning to talk about the progress and challenges that we had in the team during the day. It helped us to clear some technical issues, understand the architecture and also to address what we worked on. Morning meetings helped us navigate one day at the time and did not give the true delivery flow. All work items was in TFS and when a backlog item was done by a developer then the item disappeared from the backlog.  We could not keep track in our backlog. The advantage in this situation was that every items could be tracked and found in TFS by work item ID. I created a query that gave me the whole backlog with my team’s work items and then exported it to Excel. I then developed a macro in Excel that filtered all items based on work item status with added specific colors per row. We can now see all status flow based for each work item, even those that was outside our team. To add more transparency and overview the Excel list was printed on A3 paper and added to the team wall. This gave us a better overview and more value to our daily discussions. After a while priorities where added to work items. The goal is to finish work items that came back from test and not having to many work in progress. We found new ways to develop and made some changes to the design, these changes took much shorter time to develop and gave the customer higher value.

The Agile part

A year later my team was more than 4 months ahead development. Other teams was at best six months behind and struggling. This was a waterfall project for sure but we did some team changes to meet requirements and me as the team lead had free hands to reach deadlines. The Agile approach was that we used Inspection to understand what was required from us and how the work should be developed and delivered. We needed to adapt so that we could change negative behavior to positive. Finding ways that made our work easier to understand and developed and collaborate in the team was the Adaptation. By viewing the  “Done” items gave the team a feel good energy and showed that we are good at delivering. It also gave courage to continue in a hectic project with frustration and anxiety. We had a long list of printed A3 papers where most of the work items was almost green. Printing the Backlog every day visualized a Kanban with WIP limit. In my opinion, crucial for progress and it gave us Transparency.

 

 

Categories: Agile Story

WP to LinkedIn Auto Publish Powered By : XYZScripts.com