Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile case study

This is a case study on SDLC to Agile Transformation

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

Agile case study

  1. 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. 2. SDLC Process is as follows:
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

    Be the first to comment

    Login to see the comments

This is a case study on SDLC to Agile Transformation

Views

Total views

2,795

On Slideshare

0

From embeds

0

Number of embeds

62

Actions

Downloads

86

Shares

0

Comments

0

Likes

0

×