Agile gurgaon 2016 implementing agile in non-agile world
âąAls PPTX, PDF herunterladenâą
1 gefĂ€llt mirâą581 views
A case study of implementing agile in non-agile ecosystem. There were challenges around org structure, legacy systems etc
Empfohlen
Empfohlen
Weitere Àhnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ăhnlich wie Agile gurgaon 2016 implementing agile in non-agile world
Ăhnlich wie Agile gurgaon 2016 implementing agile in non-agile world (20)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (20)
Agile gurgaon 2016 implementing agile in non-agile world
- 1. www.agilegurgaon.com Implementing Agile in Non-Agile World By Kshitij Agrawal
- 2. Agenda Agile Implementation Challenges Case Study Context Current State and Next Steps Agile Journey Key Takeaways
- 3. Application Context 24 x 7 Multiple ChannelsCustomers Multiple Geographies Retail Corporate Private / Wealth Java Front End MF Legacy Backend Other Systems Tightly coupled system. Slow Development Distributed Team
- 4. Type of work High Work Stack Constituents Strategic Enhancement Production Fixes Regulatory Campaigns & Offers New Product Launches All these work requests were being delivered in the form of multiple waterfall projects.
- 5. Org Contextâ Matrix Organization Infra Team 5 Function 1 Function 2 Function 3 Function 4 Function 5 Infra Team 1 Infra Team 2 Infra Team 3 Infra Team 4 Model 1 Function 1 Function 2 Function 3 Function 4 Function 5 SharedInfraTeam Model 2
- 6. Org Context â Hierarchical Hierarchical Org Growth = Climbing the ladder
- 7. Org Context - Heavy Processes High Governance Multiple Approval Board Ever increasing Processes
- 8. Org Context â One size fits all More than amount of process, issue is with one size fits all approach
- 9. Application Context â Lack of IT agility Is business agility feasible without IT agility? Legacy Systems Slow development Tight coupling Complex dependencies
- 10. Agile Challenges â Tools & Infrastructure Lack of tools & infrastructure
- 12. First attempt towards agile There is serious problem of scope creep and you are suggesting we do development without covering all requirements. We think there is need of more controls to handle this chaos and what made you think that we should remove processes
- 13. Solving the right problem ⊠Million dollar question is â are we fixing the right problem? Pic from http://dilbert.com/strip/2013-02-15
- 14. Solving the right problem âą Too Many Stakeholders with no central decision maker âą Support from infra teams âą Demand Supply mismatch Causes âą Interdependencies Leading to Deadlock âą Wastage in building consensus âą Waste in wait time âą Flow Jams Effects âą Poor Time to Market âą Production Disruptions âą Demotivated team Outcome
- 15. Solving the business problem ï Dedicated Product Owner Team. Stakeholders Product Owner Business Analysts Development Team Lead / Release Manager ï Building Consensus ï Prioritization (focus on MVP) ï Managing dependencies ï Guide development ï User acceptance testing
- 16. Solving the business problem ï Combining work requests and doing quarterly releases More control, more visibility, improved time to market and less production disruption. Month 1 2 3 4 5 6 7 8 9 10 11 12 Release 1 Release 2 Release 3 ï Dedicated infrastructure resources. Slightly higher cost, still beneficial due to reduced waste. ï Work in small chunks.
- 17. Challenges post new model Month 1 2 3 4 5 6 7 8 9 10 11 12 Release 1 Release 2 Release 3 ï Six months is still long period to see outcome ï Scope creep, Adhoc work requests still causing issues ï Changes costly and discouraged ï Slow development and release overheads Not agile but a good starting point for that. Major wins were: ï Single product owner ï Dedicated infrastructure resources ï Team getting into a rhythmic frequent development mode
- 18. Agile Journey BeginsâŠ. Technical Agility Collaboration Feedback Loops
- 19. Technical Agility Technical Backlog Testing Improvements & Automation Backlog Reusable Tools Improving Infrastructure Continuous Integration Technical Agility Business Agility Leads To Supports Pair Programming & Test Driven Development
- 21. Team Collaboration Daily Stand-up with task board Brainstorming Collaboration Tools Pair Programming
- 22. Team Distribution Distributed across locations based on speciality. Throw over the wall attitude Collaboration Tools Rebalancing teams to have independent team with all specialities at each location
- 24. Agile Training and Coaching
- 26. Collaboration with QA User Stories Features Work Requests WR 1 Feature 11 User Story 11-01 User Story 11-02 Feature 12 User Story 12-01 Isnât this same as what you call as traceability Matrix? Customization of processes for agile - To fulfill the same purpose but in a different way.
- 27. Revised Model â Scrum or Kanban Iterative Frameworks No work in progress limit within iteration WIPLimit=2 Work in progress limit but no iteration boundary KANBAN ï Due to legacy code, some stories take more than 2 weeks and canât be broken functionally. ï Due to defects, prod fixes and other reasons, backlog is more fluid than ideal for iterative development.
- 28. Revised Model Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Retrospectives (4w) Planning Cadence (2w) Showcase cadence (2w) Backlog grooming discussions multiple times a week (on demand) Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Release 1 Scoping & release plannning Design Development testing in 2 weeks long iterations Deployment to test environment and skim test Combined system testing and UAT Implementation Preparations, Audit, Approvals Production Deployment
- 29. Revised Model Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 Release1 Release2 Release3 Scoping, Release plannning, Story Writing, Estimation, high level architecture discussion Development and Testing Deployment to test environment and skim test Hardening - UAT, NFT, End to End testing Implementation Preparations, Audit, Approvals Production Deployment ï Three releases running in parallel but only one development phase at a time. ï Backlog grooming during development cycle. ï Part of team capacity kept aside for test & prod support.
- 30. Next Steps ï Reduce initial planning & prioritization phase. ï Continue with technical enhancements to speed up development. ï Further automation to reduce hardening period. ï Resolving test environment constraints to have better âDONE DONEâ definition.
- 31. Summary ï Agile is not âSilver Bulletâ, the key is to understand root causes. ï Best way to sell agile is to implement some agile practices and show value. ï Avoid jargons, use the language which people understand. ï Engage organization leadership. ï Collaborate and build relationships with PMOs & support functions. ï Focus on technical agility. ï Focus on being agile rather than doing agile. ï Remember AGILE is a journey rather than destination.
- 32. Questions ?
- 33. Thank You ï
Hinweis der Redaktion
- Agenda for today is â I will start with context of my case study and specific challenges. I will then share my experiences of this agile journey, how I met different challenges in slow & steady manner. I will talk about next steps to move further on agile journey. In the end, I will wrap up with a summary of learnings during this agile journey. And of course there would be Q & A in the end So, letâs get started
- Let me begin with project context. It was a banking system supporting multiple types of customers, 24x7 through multiple channels such as direct web, telephony and branches. This system was built around 2005 to take advantage of internet boom. Rather than building the system from scratch, java front end was put on top of mainframe back end. There were multiple stakeholders constantly requesting for various changes in this system. There was a dedicated team distributed across locations to support these changes. As it was tightly coupled legacy system, the development was quite slow. In summary, complications were tight coupled system with slow development, distributed team, too may stakeholders.
- I spoke about multiple stakeholder putting requests so to give you bit more idea, let me talk about kind requests we were taking. So, there were regulatory requests. For e.g. AML â Anti Money laundering. Strategic enhancements. For e.g. changes to improve customer journey, improve conversion from browsing to actual sale. There were production fixes requested by business or production support team. Team was also supporting new product launches, customizations, sales campaigns and offers. On top of this, there were many adhoc reporting requests. All of this work was being delivered in the form of multiple waterfall projects. There were serious issues around quality and timelines.
- Let me now talk about my organization context and some of the natural challenges in implementing agile. It was a large organization. As you know, bigger organizations often get divided into departments, divisions, verticals, horizontal and so on. However, unless there is specific collaboration focus, this slowly leads to misalignment. Different groups have got their own different priorities. Between business and technology it becomes more of contract negotiation than customer collaboration. Similarly with support functions, people tend to hide behind SLAs rather than helping to achieve the goal. It becomes extremely challenging to implement agile in such environment. This was exactly the scenario here.
- The issue of misalignment becomes worse when organization is hierarchical. Hierarchy leads to slow decision making. To bring any change, we have go through hierarchy and convince many people. Sometimes their big egos comes in the way of agile transformation. Another aspect to consider here is, one of the most important agile principle is self organized team. If there is hierarchy within team than self organization canât happen. Also, in hierarchical organizations people tend to see growth as getting a bigger job title so the focus shifts from making the right kind of impact to getting a bigger job title. Organization structure is a complex subject so I am not suggesting that we shouldnât have hierarchy and job titles. Itâs just that the role of management needs to change. Instead of micromanaging people, running their performance appraisals, managers should become enablers of self-managing teams.
- There are organization with compliance culture. You would see multiple approval boards, auditing teams etc. The processes are heavy and rigid. There are loads of checklists and documents.
- The issue here is one size fits all approach. While agile is all about self organized team designing its own processes within a broader framework of agile principles.
- Last but not the least, one of the major challenge for agile is technical agility. Think of a situation wherein you want to implement scrum but technology platform is such that it takes many weeks to get even a tiny feature and then in each iteration you have to spent a huge amount of time in regression testing. Tight coupling means various components of systems are interdependent on each other. If you change one, you have to change others or at least there would be regression testing effort. When there are more and more dependencies the complexity grow exponentially.
- Other challenge often seen is lack of investment on technical tools & infrastructure. For e.g. there are only limited set of test environment and project teams sharing these. How agile it could be when you are testing in a shared environment and at a last minute your commitment goes on a toss due to someone putting a bad code. So a nice framework is not enough to bring agility. Thatâs why extreme programming had huge focus on engineering practices and XP practices are adopted by all agile frameworks.
- The issue here is one size fits all approach. While agile is all about self organized team designing its own processes within a broader framework of agile principles.
- I tried to solve this issue by moving towards agile. I tried to convince middle management. However, I couldnât gain any ground to move further. I heard comments such as: There is serious problem of scope creep and what made you think that we should start development without covering all requirements. OR how can you talk about simplifying processes while we see a need for more controls & governance to handle this chaos.
- That made me realize that my approach was incorrect. Before I move further, I let you read this Dilbert. Message here is, many times, we just solve the wrong problem. The key is to understand and articulate the problem and root causes. While I was pondering on what approach to take to correct the situation, there was a serious production issue. Suddenly I was in firing line and had full management spotlight. There is a saying that every cloud has a silverlining. These kind of crisis situations are also opportunities to get management support to bring change. The key here is to clearly articulate problem statement and action plan.
- So, this time I was more careful in explaining the issue. There were two key issues â too many stakeholders and demand supply mismatch. How these were effecting? Multiple change requests with interdependencies were leading to deadlocks. Building consensus among stakeholders about approach and priority was consuming huge amount of time & energy. As there were more requests than team could handle, there were jams in the teamâs workflow. In this pressure situation, in hurry of delivering timelines, sometimes quality was being compromised and that was causing quality issues & rework. In the end for business, time to market was poor. Each work request was taking too long. Even then often there were defects and sometimes production issues disrupting operations.
- When I explained this, management understood and asked âwhat do you need to correct thisâ. First part of my proposal was to have a dedicated product owner who is authorized to resolve differences between multiple stakeholders and can guide the team. It need not be a single person but a small team of business analysts and quality analysts led by an individual. This person will be responsible for prioritization, resolving dependencies, guiding development and user acceptance testing. This was a indeed a significant change in structure. But now since this proposal went all the way up to the senior executive whom all these business stakeholders were reporting, we had more hopes.
- 2nd part of my proposal was that we should divide the work requests into smaller features. Why divide the work into smaller chunks? Two reasons: first of all bigger size means higher complexity so dividing the work helps in containing the complexity. Secondly when you divide the work, you would come out with various chunks of different priorities so this helps in working on right priorities. 3rd part of my proposal was that instead of doing adhoc implementations, we shall combine the work requests and follow a pattern of quarterly releases. Each release was actually 6 months cycle from receiving the request till implementation but running two parallel releases, we could do quarterly release deployments. It was nothing agile, just iterative waterfall. But my belief is, a broken waterfall process is not always opportunity to implement agile. In fact, a working waterfall process is better place to start agile for further optimizations. In the end, I explained management that this will give them more control, more visibility. When you tell management that they are going to have more control, the obviously love it. And of course better time to market and improved quality.
- It took quite a while to make this model working. It was at least much better than the previous chaos. There were still issues of scope creep and adhoc work requests. So all the changes were quite costly so always it was a hard call. Either we just say NO to the change or to accommodate a change we either push timelines or push out many other scope items. So for any sizable change, we were between rock and hard place. The other issues of slow development, huge testing effort, governance overheads were still in existence. Obviously, we just fixed the issues of multiple stakeholders and dependencies.
- Now we got a working waterfall process. We also got one major hurdle of agile journey sorted by having a single product owner. So we decided to start our agile journey by creating a transition backlog to slowly and steadily bring more changes. The backlog was obviously a long list but there were three key parallel tracks: Improving collaboration, Adding feedback loops and adding technical agility. Let me talk about these items one by one.
- First and foremost my focus was on technical agility. There were different focus areas to achieve this. There was a technical backlog containing code & architecture issues which needed refactoring. Then we had an automation backlog to improve testing capability. There was focus on building reusable tools. There was also focus on infrastructure.. For e.g. building new independent test environment, getting new infra for continuous integration. We also added good engineering practices such as pair programming, test driven development to bring in more technical excellence. By doing all of these things, we improved technical agility. Itâs not that we solved all the issues but we reached to a place wherein the idea of frequent delivery was making more sense. It was like giving wheels to the snail.
- In previous slide, I talked about various things to bring technical agility. However, practically it is always challenging to get business to fund these actions. Imagine if you just tell business that we need to move from MS Access database to MySQL as its more powerful, what would be their response. Sometimes we can just get some attention by highlighting the operational risk. For e.g. we may say if we donât migrate to this new database, we may not be able to support peak sales event. Even then business is mostly reactive than proactive. Some or other functional changes will take priority over technical enhancements. There could be two types of changes.. One technical improvement to help in development processes.. For e.g. some script to automate build or code checkers.. Other type is changes in actual production code or infra.. Now these changes are more risky.. So there are other complications for e.g. if we are changing a certain architecture component, who is going to test this. We canât expect business to test & verify these components. What we did is, we created a backlog of such enhancements. So whenever we were naturally touching those module, we used to factor in refactoring effort in our estimates. For e.g. if a team member says estimate of a particular feature is X, the other team member might remind him that this module which need to be changed require lot of refactoring so letâs factor in that effort. Another thing that we did is, there were many regular activities for reporting, new product launches, sales campaigns etc so we automated these things and gave in business control so that reduced. In summary, we retained focus on strategic otherwise that generally takes back seat.
- Next thing is focus on collaboration, so multiple things such as collaboration tools, daily stand-ups were adopted. Other practices such as pair programming were already helping. We just had to maximize these by bringing in more practices such as pairing matrix so ensure proper pair rotation.
- One of the concern which I previously talked about is distributed team. We had a specialty based team like mainframe guys in Gurgaon and Java team in Chennai. The thing we need to understand about distributed team is we can bring more collaboration tools but whatever we do there is going to be some communication gap. To ensure this communication gap doesnât do much harm, we need to ensure we have got independent teams at each locations. For that we need to have all specialties at each location. So, over a period of time we rebalanced the team.
- We also added feedback loops by having practices such as regular customer showcases and team retrospective.
- We also did training and coaching for the team to ensure they understand the agile framework. Developers were more willing to adopt agile. There was slight resistance in people who were slightly senior.
- One of the major hurdle to reduce time to market was governance overheads. There were two kind of issues with that: First QA governance â organization mandate us to use a set of template but for agile these were overheads. Second multiple approval board â Before implementing anything, we had to go to multiple approval boards. We joined hand with other folks who were trying to use agile and facing similar issues. Together we used our individual networks to get ourselves hearing with the seniors. Our argument was simple, all the processes are for a good purpose. Rather than focusing on the processes, lets focus on the purpose. If we are able to meet the purpose better by slight customization in the processes, isnât that more beneficial for the organization. Some of us volunteered ourselves to work closely with the PMO and QA groups to come up with customizations for agile. It sounds simple in just telling but it was a big win in a governance heavy organization.
- Let me give you an example of the customizations. Traceability matrix is a mandatory deliverable. Traceability matrix is nothing but a mapping between top level requirement, next level requirement and low requirement. Sometimes we go all the way till build and testing artefacts. Rather than creating traceability matrics as separate document, if our backlog itself has some traceability between the epic, features and final user story or may be till acceptance criteria than we are fulfilling the same purpose. So, we agreed on a template of storing backlog which supports this traceability rather than filling that as separate document. Thatâs the kind of customizations we brought.
- During the development phase we donât follow Scrum kind of iterations. Instead we follow Kanban. Before I talk about reasons, let me just clarify the difference between these two. Iterative frameworks such as Scrum task board is reset after each iteration. So we limit work in progress on iteration boundaries. In Kanban there are specific work in progress limits but there are no iteration boundaries. The advantage is sometimes in an attempt to divide user stories to fit into an iteration, we loose the big picture. Which result in rework and unoptimized architecture. Creating an INVEST story is ideal but not always practically feasible. Kanban tries to keep the features at a level wherein they deliver visible value even if it means features takes longer than a typical iteration length. Also, this is also more accommodative of backlog changes. I am not saying one is better than others. There are specific advantages of iterations. The idea of commitment and then having formal checkpoints help in better understanding how team is doing and what to improve. In our case, we adopted Kanban for two reasons: Due to legacy nature of application, some of our big stories were taking more than 1 or two weeks. If we divide these, we were actually creating tasks rather than valuable stories. Second challenge was constant backlog changes in the form of production fixes, UAT & NFT defects and other adhoc requests. Hence, Kanban was working well for us. Afterall, agile is all about art of possible.
- Though we donât have iterations, we do have various cadences. So we have retrospectives once in 4 weeks and fortnightly planning & showcases. There are weekly meetings for backlog grooming.
- This slide shows the current model. In current model, we have three releases running in parallel. One release at a time will be in development phase which is typically 8 weeks long â area shown by arrow in this picture. Development here means design, development, testing everything will happen in this period. There is NO iterative waterfall here. Team is self organized and does whatever is necessary to create working software. In this phase, we frequently deliver software and there are client showcases. The intent is surely to create a potentially shippable working software. However, this is real world. There are specific activities which canât be done in development phase. For e.g. non-functional testing, end of end user acceptance testing, backout testing etc. There are various reasonable reasons why we canât do these things in development phase itself. Reasons are such test environment constraints. We need a dedicated separate environment for non-functional testing so that is available for short durations. We need specialization for testing such as security testing so that is done by a 3rd party consultant and we canât have that person available for each iteration. So, at a time we have one release in development, other in hardening or deployment phase and 3rd one in scoping phase. By scoping I mean a phase wherein we do high level planning, user stories writing, prioritization etc. In team one development pair supports hardening and deployment on rotation basis all the time. Some of the capacity also go in scoping phase.
- So far so good. Lot of agile purist argue that this model is not fully agile. Itâs kind of semi-agile. My response to that is, agile is a journey rather than a destination. Considering the challenges and constraints, team has really come long way and moving further for greater agility. The important thing is, its moving in right direction. Next steps are to reduce the hardening period by bringing in more automation. Also, we need to further speed up development by more technical enhancements. That will help us in more frequent delivery and more feedback opportunities. Once we sort out these things, we might move from Kanban to a Scrum framework.
- In summary, our focus should be to understand the business problem and solve it. Agile is an effective tool so that it would naturally be used in some part of problem solving. In my experience, selling agile to people who have never seen & experienced agile doesnât work. Donât even use the jargons such as sprint, backlog etc as people will be more suspicious of the kind of change you are trying to bring. Just focus on the basic ideas such as collaboration, feedback loops, frequent delivery etc and once people start seeing value in these, the journey will be smooth. Some of the us takes the idea of âpigs and chickensâ too literally. The fact is, the attempt to keep management away from the team doesnât work most of the times. The better proposition is to collaborate with management, collaborate with PMOs and support functions. Focus on technical agility as without this idea of frequent delivery is not going to work. Last but not the least focus should be on being agile rather than doing agile. Doing agile is about adopting agile practices. Being agile is about adopting the agile mindset and that is far more important. One of the key element of agile mindset is continuous adaption, improvement so remember agile is a journey rather than destination. With this, I end my presentation and floor is open for any Q & A.