Organizations that came into existence recently because of current industry disruptions are built upon the agile foundations. Many of these newcomers are threatening the very existence of yesteryear’s leaders. To realign with this new normal, companies are trying to be as competitive as they can and transform themselves. Hence, more and more such organizations who have followed traditional SDLC (systems development lifecycle) for software delivery want to use Agile when delivering new IT projects.

One of the easier choices for them is to trim their workforce, get resources freed up, and use these funds to get third parties to bring about the change by doing the heavy lifting in Agile and help drive the transformation.

If your consulting company is chosen and you’re leading the delivery, you’re expected to bring about this change and deliver the project using agile while dealing with existing resources and departments. It is easier said than done due to old practices that have been institutionalized for years or even decades of operations.

If yours is an initially targeted project, agile may actually seem to be causing disruption due to flexibility and faster releases. But it can be managed if handled properly step by step. Remember that at end of the day, the customer wants to be successful and agile is only the means to reach this goal.

Depending upon the current state of affairs, some or all the distinctions (with reservations and checks & balances) of agile can be applied that can add value to delivery and satisfy stakeholders. Agree on an approach for project delivery that uses agile concepts progressively. This should focus on the following four key objectives:

• Accelerate delivery

• Align project delivery with corporate strategy

• Transform engagement teams and culture

• Enhance skill sets and technical capability

Focus on Agile Values from the Very Beginning

Agile is a journey and not a destination. Honestly, transformation can’t happen overnight, but it can happen by starting with an approach that is beneficial for both parties. The focus of the delivery approach should be improving collaboration, a faster feedback loop, faster delivery, and more business value in shorter cycles. Sometimes agile is confused with something which is enforced top-down. Other times, agile coaches focus too much on practices and frameworks. Remember, a successful project is about outcomes, customer success, and happy users.

Manage Delivery Risks – Continuously

This should go without saying, but often, managing risk does not receive due focus and is one of the main causes of project failure. When using an agile approach is one of the requirements, pure agile teams will automatically reduce risk. But till you’re there, you must keep a sharp focus on risks and their mitigation – continuously.

Align the Contract

One should review the contract for governance model, strategy, business case, management commitment, delivery approach and system access. Include the delivery approach in the contract so that the customer is onboarded on the journey. Communicate and over-communicate as necessary. Call out dependencies on third parties and who will manage them.

Often, system access is not agreed upon in advance and it takes a long time for approvals and administration. Sometimes alternate options must be explored if access can’t be granted due to regulation, privacy or liability concerns. Access to ALM, communication tools, other systems that need to be accessed inside or outside of customer’s network should be agreed to up front.

Define Delivery Approach

Fine-tune the project delivery approach to align with your realities. Stakeholder management should be one of the key aspects. Since, the organization is not agile, it would help both parties to define Quality Gates (Checkpoints). Checkpoints should be set for each phase and should consume minimum effort to prepare and administer.

Be Smart in Scope Management

To reduce the delivery risks, the scope should be agreed upon and changes should be controlled at every stage. Before starting the sprints, the product backlog should be reviewed and agreed upon with business counterparts. To control the user story changes and its impact, the user stories of each sprint should be reviewed and agreed upon before developers start their work. Product owners and functional leads should be trusted advisors of the business and able to drop some stories to accommodate new ones while keeping the end goal intact. They should keep a sharp focus on end business goals using the 80:20 rule and also define the MVP (minimum viable product). The team should accept verbal or formal approval so that stakeholders and team members on the ground are engaged and know the boundaries.

Design

Get early buy-in from the customer on architecture by using the planning stage to create the overall solution architecture design. Use the planning stage to groom and design Sprint-1 stories and review each sprint’s design with the customer’s architects one sprint in advance or at the start of sprint and seek approvals. The idea is to baseline the fundamental design and onboard all stakeholders with the design approach.

Build and Release Management

Review stories with business team prior to each sprint and get explicit approvals. Keep a close tab on progress of stories assigned to newly trained agile members. Plan mid-sprint and end-of-sprint demos with stakeholders and people who matter. Do regular code reviews and build reviews to onboard the customer architects in your solution. Create templates to set up new environments so that quality is improved upon progressively as code is promoted to higher environments

Quality Assurance

You may reduce risks in this stage by reviewing test coverage, test strategy, and test plan. Risk based testing and automation testing should be used as appropriate.

Change Management

At times, customers do not give due importance to change management. You may de-risk post go-live risks by doing reviews of end user training plan, training material and roll-out plan.

Production Readiness

The following four items should be used as checkpoint for go-live.

• Production package review (IT)

• Data migration readiness (IT and Business)

• Approved deployment runbook (IT)

• Quality assurance approvals (IT and Business)

• Change management readiness review (Business)

• Roll-back options review (IT and Business)

Many of the risk control measures are not typically done in agile, but these are must-haves in a transient organization so that risks to the project are kept to a minimum and execution is a win-win for both parties.

Set Resource Commitment Expectations

As expected, resources you bring from your organization will be 100% committed to only your project, but it will not be easy to get 100% commitment from all client resources for the entire duration and it may not be needed from all. Therefore, break your resource requests from the customer into two groups.

• Group 1: These members must provide 100% commitment throughout. Product managers, developers and testers will fall into this category.

• Group 2: For these resources, a step wise approach should be agreed upon. During the critical yet short phases, you may take their 100% commitment and reduce it in remaining phases. Customer’s key business users, business architects, program managers, enterprise architects, data migration architects, UAT users and change agents may fall into this group. Regardless of their involvement, they must take part into daily scrum meetings, end of sprint meetings, etc., during the entire project.

All resources must be in the same physical location so that communication does not suffer.

Use ALM and Collaboration Tools for Stories and Tasks

There are many ALM (application lifecycle management) tools¹ available. Most of the major tools in the market today provide commonly required functions as standards. Stories, dependencies, tasks, history tracking, and progress reports (burn-down, burn-up charts, defects) that give real-time insights are the desired minimum features.

Weekly reports must still be prepared for executives and it should consume data from these tools. Weekly report should not take more than hour to prepare and should focus on key messages – overall progress, current period achievements vs. plan, plan for next period, risks, issues and dependencies.

Communication

You should engage and communicate with stakeholders at the first signs of trouble. Timely and regularly communicating the mitigations is as important as the risks themselves. Discourage long texts – be it email or design documents in day to day activities. Encourage face to face communication, phone calls, and drawing board discussions. You should provide a way for the entire project team and stakeholders to review the progress at will. Automate daily reports, sharing over email with all stakeholders to foster transparency.

Training

Arrange an agile coach and train the stakeholders and team members. Training alone is not sufficient for successful delivery but at least this will prepare them for things to come. Try to onboard at least 20% resources who have prior experience of agile. This will greatly improve project success.

Establish product owner² role

This role is an important part of the journey. It is a critical success factor irrespective of the approach.

“The Scrum product owner is typically a project’s key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.”²

Finally, Set Outcome Expectations Early

In initial sprints (one or two), the velocity may be less than planned. This is due to the change, and it will take a couple of sprints for things to settle down. Initial slowness should be an expectation from the beginning to avoid a future surprise becoming a deal breaker. This slowness should also be accounted in the overall sprints plan.

Use initial sprints to build and showcase small wins that work functionally to set the tone and build trust in the adopted delivery approach.

Conclusion

Having delivered many engagements with this approach, I can say that it works successfully, and all the resources feel empowered and contribute to project success. But the journey will still be hectic for the lead and core team members due to additional activities that will be undertaken.

References

1. What is application development lifecycle management (ALM) software? Retrieved July 1, 2018 from https://www.gartner.com/reviews/market/application-development-life-cycle-management

2. Product Owner. Retrieved July 5, 2018 from https://www.mountaingoatsoftware.com/agile/scrum/roles/product-owner