Agile, IT, and the Business Community

Size: px

Start display at page:

Download "Agile, IT, and the Business Community"

Posy Poole
6 years ago
Views:

1 Agile, IT, and the Business Community Presented by: William F. Nazzaro Process Synergy, LLC (484) Version 3.00

2 Process Synergy Background A Philadelphia-based consultancy dedicated to the highest-quality delivery of project mentoring, training and organizational transformation Full lifecycle consulting, coaching and mentoring Requirements Use Cases, User-Stories, IIBA Process Agile (XP, TDD), Unified Process, CMMi Project Management Scrum, Iterative, PMI Architecture Service-Oriented Architecture Organizational Change Management and Improvement Delivered On-Site, Globally Full lifecycle software training curriculum Highly differentiated offerings Experiential approach and skills building Virtual and on-site Multi-tool vendor expertise IBM Rational, Microsoft, Borland, HP Mercury, BluePrint, VersionOne, RallyDev Page - 2

Presenter s Background Twenty years of success in delivering enterprise software solutions for Fortune 100 companies, he has provided unparalleled services in project mentoring, use case and user

3 Presenter s Background Twenty years of success in delivering enterprise software solutions for Fortune 100 companies, he has provided unparalleled services in project mentoring, use case and user story training and modeling, agile SCRUM, XP, TDD, serviceoriented architecture, Unified Process and CMMi adoption, Java, C++, C, and Smalltalk programming languages, and technical curriculum development and delivery. His pragmatic emphasis on project execution and process improvement has benefited major insurance, health-care, human resources, stock market organizations and Department of Defense where he has enabled the transformation of their corporate development processes and development teams of diverse skilllevels. He has provided in-depth talks on Agility, Use Case Modeling, Service-Oriented Architecture, Unified Process, Object Technology and Data Modeling. He has extensive background in project management, and has successfully led teams on multi-million dollar projects to provide the highest-quality technical solutions in the most efficient and effective manner. Page - 3

4 Premise IT projects are failing at a rate of 25%, and 45% of our projects are challenged for being late, over-budget, or providing less than required features and functions Unfortunately this has been a habitual problem for IT and more importantly it has been a source of conflict and contention between IT and the business community we serve Our business community, more than ever, demands speed and flexibility in taking products to market. As a result, approximately 35% of IT organizations have adopted or are in some form of adoption of agile practices and agile software development Page - 4

5 Agenda Common Agile Misconceptions Why Should the CIO or CTO Care About Agile? What Does the Business Community Need to Know About Agile? Barriers to Successful Enterprise Agile Adoption Page - 5

6 Agenda Common Agile Misconceptions 1. Agile Teams Don t Plan or Estimate 2. Agile Only Works for Co-Located Teams Why Should the CIO or CTO Care About Agile? What Does the Business Community Need to Know About Agile? Barriers to Successful Enterprise Agile Adoption Page - 6

7 1. Agile Teams Don t Plan or Estimate 1 Why do we plan? Reduce risk and uncertainty Support decision making Establish trust Convey information My one client told me she wanted to get away from the way they ran their traditional projects We spend time planning and estimating at the beginning of the project We commit to this project plan and estimate at the beginning of the project We know, and our customer knows, the plan and estimate are incorrect Historical data verifies we are typically incorrect on our plan and estimate We move forward with the expectation that the information is correct We are disappointed and our customer is upset when we fail to deliver based on our initial plan and estimate A good plan is one that support reliable decision making Steve McConnell, Software Estimation, 2006 Page - 7

8 1. Agile Teams Don t Plan or Estimate 2 Somewhere along the line a belief cropped up that Agile projects don t do planning or estimating This is a MYTH, in fact I ve found I ve done more planning and estimating it s just that I plan to certain horizons Agile teams typical focus Release Iteration There are different levels of planning Release planning determines the scope, schedule, and resources needed for a product Iteration planning determines which features will be built in an iteration, and what tasks need to be done to build them Day planning monitors progress and deal with obstacles Day Planning Onion Mike Cohn, Agile Estimating and Planning, 2006 We plan and estimate to our horizon, then we inspect and adapt Page - 8

9 2. Agile Only Works for Co-Located Teams 1 To be truthful, agility can be more difficult for teams that aren t colocated because of the expectation to communicate more So how can we over come this? We have to be more creative Shifting of hours or work schedules to create an opportunity for overlap Leveraging a variety of communication tools (e.g., GoogleTalk, IM, Wikis, virtual team rooms, digital cameras, etc.) Strive for purpose and value-driven communication Page - 9

10 2. Agile Only Works for Co-Located Teams 2 When hiring team members stress their ability to be able to communicate Communication is more than just talking, it can also be How to express an idea (i.e., Textual, UML, Architecturally, code) Do they seek to be understood or to understand How do they listen? Ironically, teams that don t communicate very well that are colocated are the first to mention that agile won t work for teams that aren t co-located Page - 10

11 Agenda Common Agile Misconceptions Why Should the CIO or CTO Care About Agile? 1. Traditional vs. Agile Processes 2. Traditional vs. Agile Budgeting 3. Some Numbers to Consider 1. What Does the Business Community Need to Know About Agile? 2. Barriers to Successful Enterprise Agile Adoption Page - 11

realization of business value Agile Processes By releasing incrementally we open up the opportunity to obtain business value much

12 Traditional vs. Agile Processes * 1 Traditional Processes Lockup capital for a long time by having significant work in process before seeing any realization of business value Agile Processes By releasing incrementally we open up the opportunity to obtain business value much earlier than would otherwise be possible and prior to the completion of the overall project This can be done by breaking the project into "feature chunks" that are delivered every few weeks * Rudd, J. The Business Case for Agility, 2009 Page - 12

13 Traditional vs. Agile Processes 2 % Working Software Agile IT Process Project halted Month % Working Software Traditional IT Process Month Page - 13

14 Traditional vs. Agile Budgeting * Traditional Processes With a fixed capital budget, larger projects mean fewer projects When no return is available until the waterfall process is complete, longer projects increase the likelihood that no return will be obtained during the annual budget cycle This leads to fewer investments and limited opportunity to offset losing projects with winning projects Agile Processes With an Agile portfolio approach, the business can break down long-term projects into short-term projects This provides more frequent opportunities to both evaluate and adjust investments so that you can:» Adjust portfolio on the basis of market changes and customer feedback» Actively reprioritize the project portfolio.» Reallocate funds to stronger performers. * Rudd, J. The Business Case for Agility, 2009 Page - 14

Some Numbers To Consider * 93% increased productivity 1 88% increased quality 1 83% improved stakeholder satisfaction 1 49% reduced costs 1 66% three-year, risk-adjusted return on investment 2

15 Some Numbers To Consider * 93% increased productivity 1 88% increased quality 1 83% improved stakeholder satisfaction 1 49% reduced costs 1 66% three-year, risk-adjusted return on investment 2 Reasons for Agile adoption include: 47% to better manage project scope 3 45% to create clear business requirements 3 40% to speed or better predict time to market 3 1 Agile Methodologies: Survey Results, Shine Technologies, Forrester Research, Agile 2006 Survey Results and Analysis, Digital Focus, 2005 * Source: Page - 15

16 I ve change our funding model by having our teams prove they are worthy of additional investment by demonstrating success early Some of my most successful projects have been the ones that I stopped early before a large investment was made Page - 16

17 Agenda Common Agile Misconceptions Why Should the CIO or CTO Care About Agile? What Does the Business Community Need to Know About Agile? 1. Agile Expects Customer Involvement 2. Fixed Bid vs. Time and Materials 3. You Prioritize Our Work Barriers to Successful Enterprise Agile Adoption Page - 17

1. Agile Expects Customer Involvement Expect the customer or Product Owner to be involved with the team Ideally the product owner should be thought of as part of the team Scenario: Customer may say,

18 1. Agile Expects Customer Involvement Expect the customer or Product Owner to be involved with the team Ideally the product owner should be thought of as part of the team Scenario: Customer may say, Perfect, I really want to get this done» On this project, we physically co-located the product owner with the team I want to be engaged but I don t have enough time» On this project, the product owner established office hours and the team knew they could call on him during those times Working with you isn t my day job» On this project, the product owner was unavailable with the exception of possibly 30 minutes at the beginning or end of day Page - 18

19 1. Agile Expects Customer Involvement (cont.) Regardless of the scenario we need to be prepared to let our customer know our expectations for their time and the amount of involvement we will require of them We can let them know we will require them for Product Backlog Release & Sprint Planning Review and Retrospective We can be creative with their involvement and work with them Page - 19

2. Fixed Bid vs. Time and Materials (T&M) * T&M is most likely the biggest deterrent and concern that a customer will have when you are trying to move towards Agile Source: http://www.rallydev.

20 2. Fixed Bid vs. Time and Materials (T&M) * T&M is most likely the biggest deterrent and concern that a customer will have when you are trying to move towards Agile Source: On an agile project the customer can set the budget they want to spend, they can set the timeline, and then they can prioritize the features * Sliger and Broderick, The Software Project Manager s Bridge to Agility, 2008 Page - 20

Customer required to specify everything upfront Any change to the original specifications goes to through a change control process Customer realizes a change is need IT doesn t want to change it

21 2. Fixed Bid vs. Time and Materials (T&M) * (cont.) Based on the Standish Group, we should remind our customers that 64% of software features are rarely or ever used The Standish Group s CHAOS Report 2006 Fixed scope / fixed price results in Customer required to specify everything upfront Any change to the original specifications goes to through a change control process Customer realizes a change is need IT doesn t want to change it because it will impact the project plan and budget Customer doesn t want to pay for the change because it should have been there all along Sligler and Broderick stated in their book Source: Changing contracts from fixed scope / fixed price to a pay-as-you-go time and material (T&M) means that customers are now more responsible for the success of the product The customer directly control the cost of the contract because they authorize its existence on a recurring basis * Sliger and Broderick, The Software Project Manager s Bridge to Agility, 2008 Page - 21

22 3. You Prioritize The Work Page - 22

23 You Prioritize The Work (cont.) Product Backlog Sprint Backlog Page - 23

24 Agenda Common Agile Misconceptions Why Should the CIO or CTO Care About Agile? What Does the Business Community Need to Know About Agile? Barriers to Successful Enterprise Agile Adoption Page - 24

25 Barriers to Agile Adoption 1 Organizational Change Management Page - 25

26 Barriers to Agile Adoption 2 Common phrases I ve heard We re agile but We re doing SCRUM but It s usually the but that makes them not agile Unfortunately for many, they are just practicing timeboxed waterfall development and calling it agile, We call it waterative approach to development Page - 26

27 Agenda Common Agile Misconceptions Why Should the CIO or CTO Care About Agile? What Does the Business Community Need to Know About Agile? Barriers to Successful Enterprise Agile Adoption Page - 27

28 For More Information If you have questions, or would like more information about our consulting, coaching, and agile training curriculum: Please call Page - 28

29 In Closing Whether you think that you can, or that you can't, you are usually right Henry Ford Page - 29

30 Agile, IT, and the Business Community Presented by: William F. Nazzaro Process Synergy, LLC (484) Version 3.00

31 Additional Supporting Material Version 3.00

32 Agile Manifesto * "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value items on the left more." * The Agile Manifesto, created in 2001 by a group of software methodologists, produced the agile revolution that has significantly impacted the software development industry in a very short period of time Page - 32

33 Implementing and Adopting Agility Depends on: Agile process/method you choose Successfully focusing your pilot agile project (not projects) Organization s culture and willingness» To adopt change» To accept limited failure and learn from it» To work in integrated, cross-functional teams, not business silos Individuals willingness to be part of a TEAM, where no one has rank Project Managers / Architects / Developers ability to let go of being the» Hero» Dictator» Star of the project» Like everyone else, is just another member of the Team Page - 33

34 Traditional Management Command and Control * Management Subordinates Manager Receives reports Makes decisions Gives orders Subordinates Reports Complies and executes * Roman Pichler, Managers in Scrum 2008 Page - 34

35 Agile Management Agile Leadership Principles * Team Servant- Leadership Management Empirical Management Empowerment Quality- First Continuous Improvement Standardisation * Roman Pichler, Managers in Scrum 2008 Page - 35

Agile Doesn t Work For Matrixed Teams Or Organizations 1 Matrixed teams are created by pulling a variety of different resources from resource managers and these resources are allocated to a project

36 Agile Doesn t Work For Matrixed Teams Or Organizations 1 Matrixed teams are created by pulling a variety of different resources from resource managers and these resources are allocated to a project manager while working on that project I m actually fine with this concept of matrixed if that s all we did and Agile does work if that s all we did However, we usually go way beyond this We ve mutated the concept of matrix into timeslicing to gain maximum efficiency of resources Bill and Patty are each allocated 50% to project A and 50% to production support OR Rick is allocated to four projects and each project is expecting that he is available to work 35% on their project (OK, who s checking the math here?) Page - 36

37 Agile Doesn t Work For Matrixed Teams Or Organizations 2 What s an interruption? 1. To break the continuity, 2. To hinder or stop the action of (someone) by breaking in on, 3. To break in on an action Why am I not a fan of time-slicing? If you're being interrupted while working on a task you re losing time For a simple IM or telephone call Microsoft 1 found it took their workers 15 minutes to get back into the task whenever they were interrupted The impact of changing projects is even greater, every time you're have a context switch, it takes even longer to remember not just the task but why you were working on the task Studies have shown that productivity can be hindered by as much as 40% 2 1 Microsoft The Grand Seduction of Multitasking 2 Mike Cohn The Dark Side of Multi-Tasking Page - 37

Agile Doesn t Work For Non Co-located Teams 1 To be truthful, agility can be more difficult for teams that aren t colocated because of the expectation to communicate more So how can we over come this?

38 Agile Doesn t Work For Non Co-located Teams 1 To be truthful, agility can be more difficult for teams that aren t colocated because of the expectation to communicate more So how can we over come this? We have to be more creative Shifting of hours or work schedules to create an opportunity for overlap Leveraging a variety of communication tools (e.g., GoogleTalk, IM, Wikis, virtual team rooms, digital cameras, etc.) Strive for purpose and value-driven communication Page - 38

Agile Doesn t Work For Non Co-located Teams 2 When hiring team members stress their ability to be able to communicate Communication is more than just talking, it can also be How to express an idea (i.

39 Agile Doesn t Work For Non Co-located Teams 2 When hiring team members stress their ability to be able to communicate Communication is more than just talking, it can also be How to express an idea (i.e., Textual, UML, Architecturally, code) Do they seek to be understood or to understand How do they listen? Ironically, teams that don t communicate very well that are colocated are the first to mention that agile won t work for teams that aren t co-located Page - 39

40 Agile, IT, and the Business Community Presented by: William F. Nazzaro Process Synergy, LLC (484) Version 3.00

Agile Projects 7. Agile Project Management 21

Agile Projects 7. Agile Project Management 21 Contents Contents 1 2 3 4 Agile Projects 7 Introduction 8 About the Book 9 The Problems 10 The Agile Manifesto 12 Agile Approach 14 The Benefits 16 Project Components 18 Summary 20 Agile Project Management