This is a case study on SDLC to Agile Transformation

1. CASE STUDY
Scenario
Smartbank’s CIO feels it needs a change to compete on a level playing field with smaller, more nimble
competitors, they want their IT organization to be able to:
• respond faster to consumer demands
• increase engineering quality
• build experiences customers will like, reducing the cost of failure.
Each CIO team sits in their own directorate and are brought together on a matrix basis to deliver change,
apart from the support team who provide a ticketed service for test/prod deployments and provide 1st
and 2nd line support, 3rd line support comes from the components. The product team sits outside of
the CIO within the business of the bank.
Project Lifecycle
The e2e project lifecycle starts with an initiative from the product team, they secure early financial
approval and source a project manager to develop a high-level business case, he secures an architects
time to provide rough estimates, completes the business case allowing for the creative team and BA’s to
be funded and brought onto the project. Work requests are raised into the respective directorates to
secure them.
Once the BAs and UX designers are mobilized they begin working with the product team to define the
requirements and experience, generally these take the form of a wireframe and supporting spreadsheet
of MoSCoW requirements in user story format, they work exclusively with the Product Manager to
produce them and once he is happy these are complete he signs them off and the Project Manager
raises a work request to secure an architects time to do an e2e design identifying impacts on the
respective component teams. Once complete the work requests are raised on the impacted
components and test team requesting estimates, as trusted individuals detailed estimation is carried out
by the most senior engineers and testers in the teams.
On receipt of the estimates the Project Manger agrees any changes to the business case and forecasted
timelines with the product manager, releases funding and commits the component teams to the
delivery scope and timelines. The Product Manager breathes a sigh of relief and the Project Manager
gets ready to take the delivery into the SDLC.
Once the development starts, the engineering team starts writing code, and testing team starts writing
test scripts from the requirements. At the same time, our project manager has to request development
and test environments that have to be built by operations team and delivered by the time developers
are ready to deploy first batch of code.
Once environment is delivered, developers manually build and deploy the first release to test
environment and begin “environment shakeout”. Once environment is stable, they notify the testing
team that they can start executing tests, and continue to work on the next batch. Testing team goes
through the test scripts and raises defects. Some are related to environment instability and some to
actual bugs. Our project manager is stressed out and has to drink heavily every night (or, if he is in
California or Colorado, resort to other less liquid measures). He runs meetings every morning with
developers and testers where they review defects and negotiate their priority.

2. SDLC Process is as follows:

3. Case related Questions
1. What anti-patterns do you see in the current organization and practices, why?
Smartbank currently employs traditional SDLC or waterfall methodology for its product
development initiatives. This process is more appropriate for projects with clearly defined goals
and concrete business requirements, e.g., infrastructure build-out, building construction, car
manufacturing, etc. Modern software development is a much more dynamic process, where
business requirements change frequently based on market innovations, e.g., Virtual Reality, and
user feedback, e.g., A/B testing. Some of the major risks and potential impact associated with SDLC
software development efforts are:
Risk Impact
1. Requirement misses
2. Changes in scope mid
project
3. Poorly defined goals
and objectives
4. Insufficient change
management
• “Big Bang” approach opens product to potential feature rework
which may results in lower customer satisfaction and launch delays
– Low customer satisfaction will result in loss revenues
– Rollout delays would mean increase in development costs
• Client expectations not tested and verified on a frequent basis
• Not able to react to market changes quickly and efficiently
5. Poor Level of Effort
(LoE) estimation
6. Insufficient resources
• Product launch and rollout delays
• Slow reaction to resource gaps
7. Lack of stakeholder
involvement
8. Poor communications
• Opens stakeholder to potential surprises
• Internal clients may feel their voices or needs were not heard and
addressed
Table 1. SDLC risks and impacts.
2. How might the organizational culture be affected by the current system?
The cultural impact of employing SDLC for software development is that you expose the team to
potential risks that adversely impact team morale and job satisfaction level. This will also subject
the team to finger pointing on blame and instill a lack of trust between team members.
3. Based on the CIO objectives:
a) How would you re-organize the teams?
From the case study narrative, I surmised an organizational structure that is similar to the one
depicted in Figure 1. I would answer this question in terms of short-term, mid-term, and long-
term goals. Short term, I would not make any big changes to the organization; instead, I would
identify a pilot team to implement the agile process for product development. The makeup of
this pilot team is illustrated in Figure 2. Once the agile pilot is in-place, tested, and verified by

4. the organization on its nimbleness and effectiveness in meeting the dynamic business needs,
then I would start focusing mid-term organizational structure. For mid-term, I recommend the
following organizational changes (see grey boxes in Figure 3):
i. Hire a VP of Program Management role
ii. Move Director of Project Management under the VP of Program Management
iii. Move Director of QA under the VP of Program Management
The rationale for factoring out Program/Project Management and QA responsibilities from the
VP of Engineering role is threefold: (a) the CIO needs one person to own the true status of a
project; (b) project management and QA are orthogonal processes to development; and (c) this
structure allows the VP of Engineering to focus on design innovation and software development.
Figure 1. Current Smartbank org chart.
Long term, I fully expect the Agile/Scrum process to be promulgated and deployed across
Smartbank firmwide, at which point, Smartbank will be ready to consider the adoption of the
Scaled Agile Framework (SAFe®), as illustrated in Figure 4. SAFe will enable Smartbank
executives to run its business in an agile fashion, i.e., enable the business to rapidly respond to
competitive forces by iteratively deliver products that quickly adopt new technology, user
experience, and innovative features. As SAFe is a long term strategy for Smartbank, I
recommend a separate study to determine the appropriate organization structure to support
the Scaled Agile Framework.

5. Figure 2. Agile team members and their responsibilities.
Figure 3. Mid-term org chart.
CIO
VP of Program
Management
Director of
Project
Management
Director of QA
VP of
Engineering
Creagve
Director
Director of
Engineering
Release
Manager
VP of
Operagons
Director of
Support
Level 2 Support
Level 3 Support
VP of Customer
Service
Call Center
Level 1 Support
Business Group
Product
Management
Product
Managers

6. Figure 4. SAFe® ⎯ Scaled Agile Framwork.
b) What methods & practices might you adopt, why?
I recommend that Smartbank adopt Agile Methodology as its product development process (see
Figure 5). By embracing this development methodology, Smartbank will be able to:
Business Goal Agile Delivery Benefits
Respond faster
to consumer
demands
Agile dictates that product requirements be disaggregated into user stories
and each assigned a business value. The initial focus will be to deliver
features that deliver the highest value and require the least amount of
effort, aka Minimal Value Product or MVP.
Increase
engineering
quality
Agile also recommends that developers embrace Test Driven Development,
which requires each feature or user story to include acceptance criteria (as
defined by Product) that allow developers to include both positive and
negative testcases which will be used to validate each feature as its being
developed. This will ideally cut down the number of bugs found during QA
integration testing

7. Business Goal Agile Delivery Benefits
Build
experiences
customers will
like, reducing
the cost of
failure
By shortening the product delivery cycle or Sprint cadence, e.g., a product
release will be deployed every two weeks and introducing the concept of
A|B testing during deployment, these changes will allow the business to
deliver product features iteratively and frequently which will allow
Smartbank to quickly improve client experience and reduce the cost of
failures
Table 2. Agile benefits.
The Agile process entails the setup and running of the following meetings:
Meeting
Typical
Duration
Purpose
Daily Standup 10 – 15
min
• What did I do yesterday?
• What am I dong today?
• Is there anything in my way (blockers)? – For Scrum Master
to tackle
Sprint
Planning
4 Hours • At the beginning of each sprint, team will prioritize highest
value feature from the product backlog
• Team will select enough features to fill the sprint cycle, e.g.,
two weeks
Backlog
Grooming
4 to 6
Hours
Once a
month or
quarter
• Product owner’s meeting to review new backlog items with
developers
– Review user stories
– Assign Story Points to each user story
– Product will prioritize backlog items based on LoE
and business value
Product Demo 2 Hours
normally
on the
last day
of Sprint
• At the end of two weeks, the team has two hours to demo
the resultant work to project stakeholders
• Usually driven by Product owner because
– Gives product owner a stake in the outcome
– Solidifies the relationship with stakeholders
– Ensures stakeholders share vision with product
owner
– Developers may struggle discussion product’s value
• Get feedback from stakeholders
Retrospective 2 Hours • Review lessons learned from prior sprint
• Normally happens on the last day of each sprint
• Each team member will answer the questions
– What went well?
– What could have been done better/faster?
– This is the most important meeting because it
fosters continuous improvement of the agile process
Table 3. Agile meetings.

8. Figure 5. Agile development methodology.
c) What tools would you expect to see being used, how and in what teams?
Area of Responsibility Tools Recommendation
Executive
Management
• Atlassian Confluence for reading project dashboard, which
includes schedule and statuses
Agile Project
Management
• Atlassian JIRA for agile project management (including support for
Kanban boards)
• Atlassian Confluence for communicating project dashboard or
status
• Slack for intra and inter team communications
Product Management • Atlassian JIRA for defining product requirements or user stories
• UXPin for UX screen design and wireframes
Development • Eclipse for IDE (this also depends on the programming language,
e.g., Python, Java, PHP, etc.)
• GitHub for SCCS
• Atlassian JIRA/Confluence for user stories and product epics
Design • UXPin for UX screen design and wireframes
QA Testing • Atlassian JIRA for recording and tracking software bugs

9. Area of Responsibility Tools Recommendation
• Atlassian Bamboo for continuous integration, deployment, and
release management
Table 4. Recommended tools for Agile development.
d) What challenges are you likely to face to building the sort of team you want?
Given my experience, the major challenges in transforming from SDLC to Agile are as follows:
i. Training ⎯ It’s imperative that everyone on the sprint team gets trained on the same
agile methodology. They must practice this and evolve it to fit Smartbank’s company
culture. All of the learning from the pilot must be documented and promulgated
throughout the organization
ii. Adoption of Test Driven Development ⎯ Developers must embrace TDD as part of their
development process, otherwise, QA during integration testing will become quite
tedious
iii. Nay-sayers ⎯ As in all organization, there will always be skeptics or people that don’t
believe in your vision. One way to address these concerns is to make sure you have a
very successful pilot. The pilot must be able to demonstrate the value proposition of
agile methodology. Once the pilot program is completed and successful, a
communication program will need to be developed to advertise its success to the rest of
the firm.
e) How would you go about establishing working relationships within the organization and
managers who may or may not have bought into the CIO vision?
Given my experience, I recommend the following communication steps:
i. CIO should kickoff this change program by holding an all-hands meeting and sending out
an group-wide e-mail
ii. The Program Manager should setup individual meetings with stakeholders to reinforce
the change program messages and solicit their input and feedback on their issues and
concerns. A response to these issues and concerns must be developed and
communicated back to the key executives
iii. A website or blog site should be created to communicate the vision of this
transformation as well as capture feedback from stakeholders on their issues and
concerns
4. What are some of the high level / general risks you foresee in such an engagement?
The answer to this question similar to my response to 3(d). The biggest risk is lack of uniform
training. This is especially prevalent in teams that are already practicing Agile. I find Agile
practitioners differ from company to company because people have evolved this process to fit the
company culture or implemented workarounds unique to their products or workflow.

10. 5. What mechanisms, tools or methods would you use to identify and manage more granular risks?
The toughest part of risk management is getting the team to generate all the possible project risks
through brainstorming and collaboration. Once a list of risks is identified, any tools can be used to
track them, e.g., a simple Excel spreadsheet, Word doc, Google Doc, Google Sheet, etc. All we need
to track are:
a) Risk Event ⎯ What is the potential issue?
b) Event Trigger ⎯ How do we know when it has happened?
c) Impact ⎯ What happens when the risk occurs?
d) Degree of Impact ⎯ High/Med/Low
e) Probability of Occurrence ⎯ High/Med/Low
f) Mitigation Plan ⎯ What can we do to reduce its impact and/or probability of occurrence?
g) Risk Owner ⎯ Who owns this risk?

11. Non-Case related Questions:
1. Talk about your experiences running distributed agile teams? How distributed were those
teams? What tools were used?
Throughout my career, I have worked with onshore, near-shore, off-shore development teams
and their hybrid configurations. At UBS and Disney, the developers were based in India; at HBO,
the developers were on the west coast, i.e., LA and Seattle; and at Frankly, the developers were
in Vietnam.
The biggest issue working with distributed agile teams is picking the right time zone for
meetings. Tool-wise, I’ve used video conferencing, telephone, Gotomeeting, JIRA/Confluence,
Slack, UXPin, etc., to facilitate team collaboration
2. What's the biggest challenge you faced when supporting multiple Scrum teams within a release?
Tell us how you tracked the release?
The biggest challenge when supporting multiple Scrum teams within a release is synchronizing
the delivery as well as communicating and problem solving on inter-dependent issues between
Scrum teams. I recommend the following methods to track the release:
a. During daily standups for the scrum teams, reserve a slot of time to discuss issues that
are dependent on other scrum teams. Ideally, if possible, there could be a 5 minute
overlap time between daily standup meetings so both scrum team can hear about the
inter-dependent issues. Short of that, it’s up to the Scrum Master to communicate
these issues to the appropriate Scrum team and seek their resolution
b. Document these interdependent issues in JIRA and tag the appropriate team members
for ownership
c. If required, the Scrum Master should meet with the individual team member(s) that can
resolve the inter-dependent issues outside of the standing scrum agile meetings (see
Table 3)
3. How have you helped organizations to implement Continuous Integration and/ or
Delivery? What tools and techniques were used? What difference did CI make?
At Frankly, we used a combination of GitHub and JIRA Bamboo plugin to manage continuous
integration. CI allowed us to shorten our test and deployment timeframe from 1.5 weeks to 3
days.
4. What's your experience of DevOps? What tools and techniques were used? What differences
did it make?
DevOps is the process of automating software delivery and infrastructure changes. It aims at
establishing a culture and environment where building, testing, and releasing software can
happen rapidly, frequently, and more reliably. I had experience with DevOps at Frankly when
we migrated our infrastructure from our datacenter to Amazon AWS. We used GitHub,
Bamboo, AWS to automate our deployment scripts. It shortened our release cycle from 6 hours
to 2 hours.

12. 5. In your latest role describe any significant changes you personally made? What was the result of
those changes? How did you measure the outcome?
When I first started at Frankly, I was told that we were an agile shop but I soon discovered that
we were releasing our products on a 6 to 8 week cycle, which boggled my mind. In fact, I
discovered that Frankly was really practicing SDLC; the only thing agile about their process is
that the conducted daily standup meetings.
I took the following steps to assess and remedy this situation:
a) Embed myself in the development process
b) Observe and record my observations
c) Identify process and resource gaps relative to a standard Scrum process
d) Assess roles and responsibility conflicts
e) Develop a list of recommendation and syndicate them with the team
f) Execute against my recommendations
As a result, I was able to change our sprint cadence from 6 weeks to 2 weeks.
6. Tell us about the last time you faced difficulties? What did you do to overcome them? Is there
anything you would do differently?
The last time I had difficulty at work was dealing with a personnel issue at Frankly. This situation
arose during my Agile assessment (see my response to question 5 above). One of the problems I
uncovered was that the Product Manager was very possessive and controlling of her
deliverables. She refused to collaborate with other team members but always had an excuse for
late delivery of her end products.
The way I dealt with this situation was to conduct a RACI (Responsible | Accountable |
Consulted | Informed) analysis on her roles and responsibilities relative to other scrum team
members. I then presented this analysis to my CTO and SVP of Product to get their feedback
and buy-in. We then jointly presented our recommendation to the product manager. As a
result, she modified her behavior and became a much more collaborate team member.
In retrospect, I would follow the same process to overcome these types of issues.
7. Describe a situation where you had to transform an organization with a traditional waterfall
SDLC into one with a more Agile SDLC?
Same as my response to question 5.