Article – Transition from Traditional SDLC to Agile

I was called upon suddenly to see if a presentation can be made. I had the Transtion from SDLC to Agile handy. But ISQT (www.stepauto.com) also wanted me to write it as a paper, which they put together and distributed as a booklet. It took some writing. Below is the article. Tried a while to get the formatting correct after copying over with the IEEE format. Did not succeed. Apologies.


Abstract—This paper provides a snapshot on the transition required when moving from an SDLC based mindset to an agile mindset. The author argues for changes to not just the Process, but also the People and Platform side of the transformation. This article also contrasts elements surrounding the Knowledge Areas as well as the Triple Constraints as applicable to agile projects.

                                                                                                      I.                 Introduction

Agile is not a buzzword anymore. Many organizations have caught on to this concept and rolled-out agile transformations. However as all change management journeys go, there are many potholes along the way. Agile transformations especially have a penchant for failure as it is quite easy to pick up and practice agile lingos, but continue to work with old mindsets. What make it worse is, stakeholders outside of the team place even greater expectations in the name of Agile, but do not empower the team. This article talks about the unspoken aspects on Agile. Especially the ones that require investment.

                                                                                                 II.         The new paradigm – the 3 Ps

The three Ps for an agile transformation are Process, People and Platform. Reams of documents have been written up around the process angle. Professionals all over appreciate the different practices and lingos related to process, viz. stand-ups, retros, huddles etc. We will hence touch upon the other two Ps in greater detail below.

A.              People

This is an area where one can easily provide lip service. We have seen agile engagements where, one does not even have a dedicated team. There are floating resources coming in and out of the team. Management requires additional reporting. The team does not speak to the customer. Someone else (management) has sized the work, created the schedule and has asked the team to deliver in an agile manner. If any of these are happening in your projects, then you can be rest assured you are not running an agile project. A truly agile team will be empowered. A truly agile team will make demands from the management and customer. Truly agile teams will pushback to management and the customer. How one inculcates this culture will vary from organization to organization. However a few practical suggestions are given below,
·       Answer any and all questions of the team. Even if they are the most ludicrous and do not seem relevant to the project.
·       Keep communication transparent. Let everyone know how we are doing on cost, schedule and customer satisfaction as well.
·       Run feedback sessions once a month at the minimum. Everyone should get to give feedback to everyone else. To start with keep it anonymous if there is fear within the team.
·       The team ought to create the ‘Definition of Done’ and present it to the customer (product owner).
·       The entire team needs to be present for showcases.
·       Tell your customers (Business Owners) to reserve 30 minutes every week to listen to the team (not to speak to the team).

B.              Platform

This is the area where real money needs to be spent. And hence, this is the area that gets glossed over very quickly. Listed below are a few elements that are essential for an agile project,
·       One needs to have a working CI (Continuous Integration) set
·       Test automation requires effort. One cannot expect automation to occur without investing in people, licenses and hardware
·       NFT (Non-Functional Testing) environments need to be ready and available from the first sprint
·       Do not start off sprints without having your testing environments in place. Else you will always be in catch-up mode.
·       Invest in an agile tracking tool, especially if there are stakeholders in other geographies.
·       Give laptops to team members. Agile does not work well with working constraints.
To be fair, the above points are quite valid in an SDLC project as well. In an agile set-up all of these bubble up to become critical.

                                                                                                              III.               The New Thinking

Agile does not necessarily mean the fundamental tenets of project delivery have changed. We look at some of these elements in new light. Listed below are a few themes in Agile and how they map to the traditional SDLC model. While there is a tinge of sardonic humor to the mapping, most will agree to their veracity.

TABLE I

Agile
Traditional
Technical Debt
Err…lets not talk about it
Sprints and Iterations
Project Schedule
Spike
Don’t experiment on my project!
Fail-fast
Fail??!! You CANNOT fail!
Retrospectives
Post-harvest
Continuous Integration
Nice to have
Collective Ownership
Individuals need to be accountable!
Information Radiators
Let them know only as required
Huddles
Meetings
Planning poker estimation
Function Point
Showcase
UAT
Definition of Done
We are done for….

                                                                                                     IV.               The Knowledge Areas

This section touches upon how some of the Knowledge Areas (as defined in the PMP) get oriented in an Agile Project. Not all areas are covered. Only those Knowledge Areas as relevant to this article have been highlighted.

A.              Scope Management

In an Agile project, scope tends to be the most flexible. Any Agile project ought to pick up scope with a set of Must-Haves, Should Haves and Nice to Haves. A plan ought to be created with the entire scope in mind. The expectation ought to be set that all of the scope will not be delivered. However, what gets delivered gets delivered quickly. Returns on Investment (either revenue increase or cost savings) occur faster.

B.              Cost Management

The cost in an agile project is typically fixed. This should not be construed with a fixed price contract to deliver an agile project. What we mean here is to say that while cost is fixed, scope is not. It has been proven several times over that 70% of scope delivers 100% of value. The last 30% do not deliver any value. Chances of delivering 70% scope with a fixed cost are extremely high.

C.             Schedule Management

Timelines are fixed in an agile project. In fact, if anything comes with a level of rigor, on agile projects, it is schedule. This also helps drive a fixed cost within the project. The most flexible constraint is scope.

D.             Risk Management

Risks by their very nature are emergent. As with any project, one needs to keep a lookout for risks and mitigate them. The difference in Agile is, we actively try and unearth risks. And rather than managing risks on paper, we undertake agile methods to handle risks. Spikes are a great way to identify engineering related risks. A tough problem to solve can be spiked out, so the team has an early view of what is coming their way and a ready approach to tackle it with a fair bit of confidence.

E.              Quality Management

In agile projects, one ought not be defensive about defects. The team concept provides a safe environment for surfacing issues. The very nature of Agile is to fail fast, so you don’t build up moss from the rolling stone. Traditional models have a penchant to hide, ignore or transfer faults to other members and teams. Ultimately the project suffers.
Communication and HR Management has been spoken in some detail when addressing the People side of things. Integration Management and Procurement Management have been kept out of scope for this article.

                                                                                                      V.                The Triple Constraints

In a traditional model typically, the schedule gets elongated as get into execution mode. Based on the type of contract, either the customer or the vendor suffers on cost. In a fixed price contract, the vendor suffers. In T&M contract, the customer suffers.

In an Agile project, the scope is flexible. Time and cost are rigid. However, with the right mindset and an approach to creating an optimal product, all stakeholder interests can be addressed.

                                                                                                       VI.               So where does it fail?

The major reason for failure of agile projects is when stakeholders take up positions of confrontation rather than collaboration. This shows lack of trust. Some telltale signs of these are listed below,
·       Setting up a fixed price contract
·       Expecting all of the scope to be delivered
·       Pushing the team hard. Making unrealistic demands of the team
·       Focusing on project execution efficiency and forgetting the product value delivered

                                         VII.              In Conclusion

Moving to Agile based execution require fundamental changes to the way we look at projects. While basic delivery methodologies do not change, the areas of focus within them change significantly.  Answering a few of the questions below will let one know if one is ready to take the journey,
·       Do you talk stories or use cases?
·       Do you talk spikes or design?
·       Is your CI ready and running?
·       Are your test environments ready?
·       Do you know who your product owner is?
·       Can you tell your customer they are not ready?

                                                                                                                                                             

By with No Comments 0

Related Posts

No posts were found for display

Leave a Reply

Your email address will not be published. Required fields are marked *