This document discusses agile project delivery methods used for a project to develop and maintain a product managing network equipment. It involves breaking down requirements into stories, prioritizing stories, delivering in two-week sprints, and maintaining documentation iteratively. The author discusses challenges of maintaining process and documentation in an agile approach, and solutions tried like maintaining lightweight documents with each story and release.

1. Agile Project delivery Methods and Leadership<br />Author: Ranjith Varghese<br />Email:Varghese.ranjith@gmail.com<br />Date: 20/05/2010<br /> “ Do it first, then do it right, then do it fast “<br />This document is written for Agile Project Leader Practitioner Certification with DSDM Consortium. All Customer, project and vendor related information is removed from this doc due to confidentiality requirements. No information in this document should be replicated without author’s permission.<br />Introduction to the project<br />The project involves development upgrade and maintenance of a product to manage CMSANS and DSLAMS in customer Network. It is a component of the customer OSS stack within 21CN Program which provides an interface between the customer order stack and the Multi-Service Access Node (MSAN) management systems. This supports the capacity management and provisioning of DSL services and the configuration of voice ports for the 21st Century Network. The 21C Network intends to replace classic network with IP based network. The product is developed using C++, Java and Oracle.<br />The customer 21C programs involve replacing the classic network with IP based equipments. The design and development of such a work in waterfall methods will be extremely difficult and near to impossible. Customer adapted agile scrum methodologies for delivering the 21CN stack and forced all vendors to do the same. I have been working on this project for past 4 years and I am leading the Design and work backlog creation team for past 2 years.<br />Project delivery mechanism<br />Work Backlog creation<br />The customer work backlog is created by the CFT (Cross functional Team). The CFT is set of designers from different components discuss together on the requirements. I lead this process from our component. Each requirement comes as a Demand story which is further broken down into CE story, DOMAIN story and component story. The initial requirement is raised as a Demand story which states the business initiative. This will be broken down into different End to End design story, there will be different design required to satisfy above business initiative like building infrastructure building service capability etc. Separate stories will be created for each. Now that the requirement is clear in terms of technical impact the story is further broken down into component impact. The process in illustrated in figure 1<br /> <br />Figure 1<br />The designers discuss the impact on each component and dependencies, if any of the stories need to be blocked due to dependencies then other stories are progressed and impact identified. The component stories might be further broken into chunks to enable delivery. Once this process is complete the story will be marked as Ready to build. A light weight design document will be produced by each component. Customer uses a tool called STORM to organize this process. This iterative process is continued for all business demands. My involvement in the above process is to identify the reusable building blocks, indentify the impact of new blocks, advice on best practices and priorities the blocks for solution delivery. Agile delivery requires building meaningful testable chunks which can be enhanced to reach the final solution.<br />Prioritization and Release planning <br />Customer conducts Release planning meeting for every release. The stories are assigned priority according to the business demand. Then stories are picked from the pool, the delivery capacity of each component and team is analyzed. The above process is coordinated by Customer release Manager, Customer Delivery Manager and My Component project Manager. Once the all teams and dependencies are aligned for a story then that story is committed for the release. Each release is split into 6 sprints and each story will be committed to a particular sprint and components will align to this commitment.<br />This iterative process is continued for all stories and all release planning meeting. My involvement in the above is to lead the release manager to identify the correct dependencies and identify deliverable chunks. Sometimes business initiatives will demand a particular story delivery but if that can’t be delivered as a testable and extensible chunk then I advises the release manager accordingly.<br />Development, Delivery, testing and deployment<br />Once the scope is committed for a release then the development work starts for the release. We maintain baseline documents which are updated every release, for each story we create small documentation which is subset of baseline documentation. Once the release is complete we update the baseline document with the release changes. We have a development environment where we do unit testing in simulated environment and we have CIT (Continues Integration Test) team which will test each sprint with real equipments. We follow Test driven development were the test scripts are written first and the code to pass the test is written. Most of the time more than one person will be working in the same area. Every 2 weeks the code will be delivered in to CIT environment as per the release planning commitment. This will happen 3 times for a release .Once the testing is complete for a release and if the testing is successful then the code is deployed on live .The complete cycle of release planning, testing and deployment repeats ever 6 week. We have a regression test suite to which we add test cases every sprint, the code will be automatically build every night and the test will be run every night. This helps us to become extreme agile, if any urgent requirement comes up, we change the code and allow the nightly test to run, this will enable quick delivery of fully tested code. Figure 2 explains agile delivery process<br /> Figure 2<br />I involve extensively in the above process. I involve with project manager indentifying the resources and planning the timelines. We follow test driven development. All test cases are reviews and finalized before the development work starts. Code will be changed only to pass the test cases that are already written. I involve key stakeholders and Customer architects to get approval for key design decisions. Changes are made to the process and delivery mechanism as per the feedback from Customer delivery management, Architect, Component management and team. We adapt to meaningful suggestion immediately and with Agility. <br />Bug fixing and Extreme Agility<br />For every two weeks sprint there could be bug report which will be fixed immediately and deployed back into CIT. Apart from bugs there could be some urgent requirement stories scoped in after release planning, we take this up if there is enough team capacity, we call this extreme agility. We train the team such that each resource can work on different areas so that any urgent requirements can be taken up.<br />Difficulties with Agile definitions and solutions<br />Most of the time agility is misunderstood for less documentation and less process oriented approach. The actual definition is giving priority to delivery over documentation and process instead of ignoring documentation and process. I believe correct and tightly couples process can be created for agile projects. I don’t believe in delivering software without all necessary documentation like high level design, low level design and user documentation. This is very critical is big projects like 21C. It becomes extremely difficult to follow process and documentation when we have to deliver software every two weeks. We found very good mechanism to overcome the problem. I create a small high level document for each story which clearly states the dependencies and requirement of a particular story, this is called the CFT document. This document just states the requirement without the implementation details and it’s done as part of work backlog creation. Once the work is scoped in the developer will create something called RDD, again this is a small document which will explain which all part of the baseline document will be changed. At the end of each release we update the baseline document with all the changes of that release and we do this every 6 week. By this approach we effectively maintain all the documents and we are truly agile.<br />Another problem in our project is recourse locations. Our project resources are spread across three Geographical locations in two countries in UK and India. Earlier this used to be three countries including Denmark. Agile methodologies give importance to face to face communication which is practically impossible in our case even though sometimes design work is done in hot house where designers get together in to a room. We work around this problem using communicator session. Everybody opens a communicator session and joins the conference. Any problem or roadblock is immediately discussed in the room. I see this more effective that face to face communication because in this case there is record of conversation, don’t have move from the seat and all are informed of the discussion. Apart from this we conduct standup calls every day morning where in which daily actions are discussed. <br />Agile methodologies encourages delivering fast and quick, often this is misunderstood for delivering unusable software. Our customer strictly imposes RFT (Right First Time) in delivery and operations. RFT doesn’t mean what delivered should complete but the trick of agility is identifying that chunk which is correct and extensible to match the full functionality.<br />Another definition of Scrum method states that the scrum master is the only position and rest is team members. Most of the time this is highly misunderstood. I believe each member of the team should be given responsibility and accountability. The project manager should make it clear who is solely responsible for each area of functioning and make the resource responsible. If this is not done then it will create unwanted tension in the team<br />Conclusion<br />I find agile method extremely beneficial and helpful. Agile method actually reduce the pressure of huge delivery and pressure to complete full testing and deployment. Agile keeps the team always busy with work and sufficient work. It’s like a conveyer belt which keep moving bags from one place to another safely, just that more intelligence is put in to understand important and essentials bags.<br />