Li kai roll-out scrum in an intel organization


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Li kai roll-out scrum in an intel organization

  1. 1. Roll-Out Scrum in an Intel Organization Li Kai Intel ASEC PMO Leader PMP, Scrum Master
  2. 2. Agenda Who are we? Purpose for this presentation Our challenges How to Roll-Out Scrum in our organization Mind Set Ready Lifecycle Transformation Roll-out with Strategy Changes and Results
  3. 3. Who are we? Intel Engineering Computing, A group from Intel IT responsible for Intel Internal Solution Development and Deployment: Batch Computing Solutions Design Private Cloud BI Solutions Silicon Validation Solutions A CMMI organization with existing waterfall project management processes A distributed team support global customers 2-years experience in Scrum Journey.
  4. 4. Purpose for this presentation Sharing in “How” to Roll-out Scrum in an organization “Why” Scrum is out of scope
  5. 5. “How” we start Scrum? Top-down Mind-Set Ready for Changes Start Being “Agile Thinking” Common Misconception/Trap Keep Simple When Pilot Scrum is not for all projects when it is new to an orgnization Carefully in Sponsor Selection, X or Y style? Miscellaneous: Risk, Responsibility ,PAT, etc Usage Model of Scrum Prepare New Toolkits From PLC Phases to Scrum Sprints Enhanced Burndown Chart Scrum for virtual Team?
  6. 6. ❶Mind Set Ready Part One
  7. 7. - Top-down Mind Set Ready for Changes Traditional(CMMI) Agile(Scrum) Scope drive the budget and schedule Project Triple Constrain Scope (Fixed) Scope Scope is driven by the budget and schedule Waterfall Iterative Lifecycle Cost Time Time (Fixed) Cost (Fixed) “Empirical” Adaptive black box Software Craftsmanship “Theoretical” Fully defined processes Software Engineering Process
  8. 8. - Start Being “Agile Thinking” Individuals and Interactions overProcesses and Tools Working Software o Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan Start being “Agile Thinking” from management level
  9. 9. - Common Misconception/Trap Agile means no documentation Developing iteratively but in the wrong way - Creating a reporting DB that includes everything - Developing the db in the first iteration, then the business layer, then the UI Story 2 Story 1 UI UI Story 1 Business Business Data Access Data Access Story 2 DB DB Story 3
  10. 10. ❷Lifecycle Transformation Part II
  11. 11. - Usage Model of Scrum A new project Lifecycle -Implement M and A DRP Is for product development? N Y Fixed project time or scope? Fixed scope Lifecycle -PLC/PoC Fixed Time Y Are the project resource in high fragmentation ? N N Virtual team? Is the virtual team mature for Scrum? Y N Y Lifecycle -Integrated Scrum(Scrum of Scrum) Lifecycle - Scrum
  12. 12. – Prepare New Toolkits Scrum only requires three tools: Product Backlog Sprint Backlog Burndown Chart Keep it Simple when in Pilot
  13. 13. Advanced Burndown Chart Cumulative Burndown Chart Budget Chart for Scrum Project With forecast capability
  14. 14. - From Waterfall Phases to Scrum Sprints Regular sprints Sprint to launch project
  15. 15. – Scrum for distributed team? Solutions for different types of distributed team Type A: All developers are together, all customers are remote Type B: Multiple development teams in different locations (but each team is together) Type C: “Virtual” team where nearly everyone works remotely (e.g. from home, in various offices, etc.)
  16. 16. ❸Roll-out with Strategy Third Step
  17. 17. – Keep Simple When in Pilot Keep toolkits and framework simple in pilot while we can try more advanced tools once our Scrum Master/PMs are more mature New PMs will not be frustrated by detailed processed and documents. PMs can go ahead to implement Scrum to his/her project after 1-days training. Someone noticed Scrum is that not easy to report traditional PHIs (e.g. SPI/CPI). But it provide Burndown Chart for management review.
  18. 18. - Scrum is not for all projects “Scrum is a management, enhancement, and maintenance methodology for an existing system or production prototype. It assumes existing design and code which is virtually always the case in object-oriented development due to the presence of class libraries. Scrum will address totally new or re-engineered legacy systems development efforts at a later date.” - By Ken Schwaber, Co-Creators of Scrum, in his paper "Scrum Development Process" A new project Lifecycle -Implement M and A DRP Is for product development? N Y Fixed project time or scope? Fixed scope Lifecycle -PLC/PoC Fixed Time Y Are the project resource in high fragmentation ? N N Virtual team? Is the virtual team mature for Scrum? Y N Y Lifecycle -Integrated Scrum(Scrum of Scrum) Lifecycle - Scrum
  19. 19. – Carefully in Sponsor Selection, X or Y style? Sponsor’s in McGregor Theory Y : In this theory, management assumes employees may be ambitious and self-motivated and exercise self-control. It is believed that employees enjoy their mental and physical work duties. ….theory Y managers believe that employees will learn to seek out and accept responsibility and to exercise self-control and self-direction in accomplishing objectives to which they are committed. Scrum is more fit for this style Sponsor’s in McGregor Theory X : In this theory, which has been proven counter-effective in most modern practice, management assumes employees are inherently lazy and will avoid work if they can and that they inherently dislike work. As a result of this, management believes that workers need to be closely supervised and comprehensive systems of controls developed. Scrum is less fit for this style Theory X and Theory Y are theories of human motivation created and developed by Douglas McGregor at the MIT Sloan School of Management in the 1960s that have been used in human resource management, organizational behavior, organizational communication and organizational development. They describe two very different attitudes toward workforce motivation. McGregor felt that companies followed either one or the other approach. He also thought that the key to connecting self-actualization with work is determined by the managerial trust of subordinates. – Wikipedia,
  20. 20. –Others: Risk, Responsibility ,PAT, TDD, Refactory, etc Scrum project without TDD will be in risk Put refactory in your roadmap and reserve Sprints for that Risk: Scrum might degrade the CMMI compliance processes to non-compliance. Need a response plan (e.g. define and communicate constrains and measures for adoption of Scrum) Empowerment: the person executing and performing the process is also responsible for updating and maintaining the process A PATs(Process Action Team) might be needed to integrate the experience and knowledge gained from the pilots into Scrum framework shared by all projects cross teams. Force everyone to follow the standard process—The best path to success is leveraging the intelligence of “ordinary” people in the relentless improvement of your current process -- Mary Poppendieck, Co-author of the book Lean Software Development
  21. 21. Changes and Results: + - Not easy to get traditional PHI : In Scrum, the SPI/CPI can be calculated but it is easy for a new Scrum Masters/PMs. Although the BurndownChart somehow can be replacement for it but it is not traditional way. So it will be a challenge to figure out what is the metrics and measurement we need when we run Scrum for projects. Release project on time: Project will release on time with most high priority features/works done (or team use 20% of time finished 80% project value). More aligned with objective: Small release for early review and project be adaptive for uncertainty and changes More customer orientation: Embrace customer change request to be more aligned with business changes and customer needs rather than reject changes to make project running healthy. Towards a Agile org: Push EC be an Agile organization started from Scrum teams Happy PMs: “What is too much? What is enough” for documents and process? PMs will be happy if they only need focus on “Necessary” documents and projects. No need for sufficient detail planning at the beginning of project : The granularity decrease as the priority going to low for features/works in Product Backlog in planning phase. Uncertainty handled through risk management in Sprints
  22. 22. Summary Be “Agile Thinking” from management level Keep the framework simple One size does not fit all Think for yourself: Don’t believe all the success stories Be skeptical, looking for what is missing Your situation is different You don't get to be world class by chasing "best practices", you get there by inventing them. - Mary Poppendieck, Co-author of the book Lean Software Development