Principles for managing a Scrum-based Agile Program

Agile project management philosophy, though not very different from the traditional management practices and framework, needs to be rationalized to suit the demands of the agile methodologies. The project management practice remains the same for requirements, planning, initiating and tracking the progress of the project in line with the business vision. However, the focus is more on adaptability towards changing requirements, team work, collaboration and the ability to plan and deliver small chunks of useable software in short intervals of time

In one of my own previous client engagements we had to move out of the comfort zone of managing programs based on the more disciplined, planned and process-oriented waterfall delivery approach. Instead the business challenge ahead of us was to align all the existing programs to Scrum-based agile delivery.

The main business driver for our stakeholders to adopt this strategy was a lack of confidence in the existing delivery proposition which was based on a waterfall approach. That delivery model was resistant to changes and was inflexible to our ever changing business needs in scope and introduced delays into our expected time to market with an increased cost.

Our typical waterfall approach was predictive and well planned, but with even with a slight change in scope or requirements it inevitably added unacceptable delays, overshadowing the other unknowns which always threaten the delivery timelines and quality. Based on the organizational requirement for large programs using a Waterfall approach, typically the SDLC life cycle was divided into sequential stages of 3 months each of design, development, testing and deployment to go live.

So in effect what it meant to the business was that the lead time for solution to market effectively took a minimum 12 months after the scope of a service offering was conceptualized. This was based on the assumption that there would be no changes to the scope. This significantly affected stakeholder confidence in spite of best practices and project management methodologies being used to manage this programme since they couldn’t see tangible results quickly and there was nervousness around ROI [return on investment] and financial accountability. Scrum-based agile promised short bursts of useful code being delivered and deployed live to market in 10 weeks, which was a significant reduction in time to market.

Initially I found it extremely difficult to adapt and drive this philosophy across teams since it had very little in common with a conventional waterfall approach. This indeed was a new culture for us, necessitating the need for people from all walks of the SDLC [software development lifecycle] to adapt to this paradigm shift in thinking to improve our chances of implementing it successfully.

Philosophy behind Scrum based Agile delivery
Scrum based software development is an iterative way of rapidly delivering useful software with increased productivity and reduced time to market without losing focus on the quality of the deliverable. The emphasis is on maximizing a team’s ability to rapidly deliver software in increments and running parallel threads of delivery from the SDLC as opposed to the sequential approach in waterfall. It moves away from complex and elaborate process implementation and the need for lengthy documentation. Scrum accepts that the problem cannot be always fully defined and understood. Instead the focus is to respond to emerging requirements. This is suitable for programs where the delivery turnaround time required is a lot quicker and the emphasis is on being more adaptive than predictive to the ever changing demands on a project.

Key Principles of Scrum based agile delivery

• Collaboration and Communication – Emphasis is on face-face meetings and co-location since daily scrum calls and intense communication is an essential ingredient to success of Agile implementation. It helps make collaborative decisions more easily and seamlessly integrates feed back into the system at an earlier stage in the SDLC. If co-location is not possible then it necessitates extensive usage of communication tools and applications like live meeting, video conferencing, net meetings, teleconferences, usage of Wiki tools, and instant messaging.
• Product Backlog: Key focus here is to identify smallest workable piece of functionality, which translates to a tangible business benefit no matter how small the benefit is and that could be designed, developed, tested and delivered to live in 2 weeks iteration each. This is then maintained as a product backlog list to be delivered against incremental iterations
• Time to market: Workable piece of software is delivered to live environment incrementally in weeks as opposed to months. This decreases the time to market and increases productivity. Iterations or Sprints are planned for designing, developing, testing and deploying the code.
• Stake holder engagement: It is essential to engage developers, testers and deployment teams earlier in the SDLC life cycle. They need to be engaged right from the design stage where lead architects orchestrate the requirements into user stories. This needs to be agreed between all parties that it can indeed be delivered in planned iterations. Even business stake holders could be engaged at agreed intervals in agile delivery as check points. This gives an opportunity to all parties involved to ensure that project is progressing in the right direction.
• Capacity management: Every aspect of capacity across SDLC, right from the availability of resources to software and hardware capacity needs to be assessed and agreed, before delivering software in iterations.
• Release planning meetings – Design Iterations are planned and scheduled upfront for the designers to pick user stories from design backlog and produce low level solution design. This is then followed by release planning meeting which results in the development, test and deployment teams to pick up the designed user story, and deliver the code live in the agreed sprints. This could then be signed off by the relevant stake holders as appropriate.
• Co-coordinated Sign offs – Importance is given at every stage of an SDLC to get sign off from key stake holders involved against acceptance criteria. Designs are validated at the end of every iteration, development completion is tested against acceptance criteria which ensures that the right code is deployed live.
• Risk management - Periodic monitoring of the progress of software that is being delivered incrementally by the product owner and all the relevant stake holders involved in implementing the software gives early visibility to managing any issues or risk that might arise.
• Managing changes – Changes arising as a result of timely feed back from stake holders, scope changes or feed back from the test teams to fix a bug etc is absorbed and integrated seamlessly into an SDLC due to the nature of agile delivery. The agile project manager ensures these changes are aligned to the business vision at every stage of such a requirement and ensures that it is planned to be delivered in the respective sprints as per the schedule.
• Cost to business – Since delivery of useable software - right from design through deployment is time boxed against fixed iterations or Sprints, these results in an effective utilization of the resources. Hence this approach facilitates transparent accountability of the budget allocated to the business stake holders and ensures customer satisfaction and effective budget management.

Best practices:

• Daily Stand up calls – It’s essential to organize daily scrum calls with the relevant parties to monitor the progress of designs, development, test and deployment as per the plan. Daily scrum calls during design iterations normally involves designers, developers, process folks and testing and deployment teams. This would enable facilitation of the design specifications being agreed by all impacted parties and test cases being planned and written well in advance by the testers. This would also ensure that the completed designs are indeed in a stage where it can be picked up by the relevant teams and developed, tested and deployed in an allocated iteration slab [ Generally 2 weeks each]. It’s also essential to have stand up calls internally during development, test and deployment stage to ensure any discrepancies are ironed out at an early stage in the SDLC life cycle. The best practice is to have a quick 15-20 min stand up call per day to track the progress of the project.
• Use of collaboration tools like wiki – It’s a general practice to use Collaboration tools like Wiki for documenting and sharing user stories, completed design documents with any UML diagrams, highlighting dependencies between user stories or test dependencies etc. This facilitates exchange of information stored at one place for all involved parties.
• Co-location – Co-located teams greatly increases the inter team communication resulting in speedy decision making.
• Use of audio visual aids – In case of teams spread across locations and where Co-location is a challenge it is ideal to use audio visual aids like live meeting with white board options, net meeting etc.
• Feed back integration and decision making - Engaging stake holders like Project managers, designers, developers, testers, deployment and process teams throughout the agile SDLC life cycle, would ensure correct decisions being made at the right time and facilitates early feedback in the lifecycle making the process truly agile. Engaging business stake holders at appropriate check points ensures that the project being delivered is clearly aligned to the business vision and improves customer satisfaction.
• Re-useable artifacts - It’s a best practice to arrive at re-useable artifacts like design templates, development and test progress templates, Wiki templates, delivery progress templates, release planning sheet, Project high light templates etc, which greatly reduces the time spent on documentation.
• Group reviews and sign off – At the end of every iteration it is a good practice to have a quick group review and sign off the deliverable so that there is no discrepancy that has been missed out at any stage.
• Continuous improvement and lessons learnt – Regular feedback sessions at the end of an iteration or at specific agreed check points to look at what worked well and what didn’t for the project enables lessons learnt to be incorporated into future iterations. This fosters a continuous improvement process through out the agile delivery.

Once the decision is made by the business to go ahead with Agile delivery approach as a way forward, it is very important to form a team with clearly defined roles and responsibilities as required by the agile process. Since the approach to agile delivery needs a clear paradigm shift in thinking compared to waterfall delivery, it is important not to undermine the need of a well defined training plan. This ensures that all the involved parties receive training and awareness sessions periodically to re-enforce their understanding of the process. This also takes care of churn in the people and doesn’t affect their adherence to the best practices and agile delivery guidelines. It is also important to complement the best practices with key industry standard processes like ITIL rationalized to suit the demands of rapid delivery in agile programmes.

Though it is relatively easier to implement an agile delivery model for smaller projects with teams co-located, it is a myth that agile cannot work for larger programs with teams separated by geographic boundaries. We are in a “flat world” era and have successfully established onshore-offshore global delivery models enabled by tools and technologies. Collaboration can still be effectively achieved, which is one of the key requirements for Agile delivery.

Agile can be implemented effectively by using best practices, supported by a self motivated team under the able leadership of a dynamic leader with a clear steer from the business. I would like to conclude by saying “Agile is not fragile” and the best way to find out how solidly it works is to actually try it.

References:

http://www.mountaingoatsoftware.com/scrum

http://www.ccpace.com/Resources/documents/AgileProjectManagement.pdf

About the Author

Asha Anil Kumar has over 14 years of experience in the IT industry and is currently working with Infosys technologies Ltd. as a Senior Consultant. Program management being her core strength, she has successfully managed large programs while aligning them with agile methods for the UK's leading telecom provider for more than 4 years plus managing various other customer engagements in the past. She also has more than 25 international certifications to her credit ranging from the areas of project management to ITIL to technical certifications.