Craig D. Wilson, MS, PMP, CSM. Matincor, Inc. IT Management Consulting

Transcription

1 Craig D. Wilson, MS, PMP, CSM Matincor, Inc. IT Management Consulting

2 IT Management Consultant 10+ years of service as an independent consultant preceded by 10+ years of senior and executive management experience in several Fortune 500 companies Graduate degree in Management Science, additional postgraduate studies at UCLA s Anderson School, Project Management Professional (PMP), Certified Scrum Master (CSM) Specializing in program / large project management, project turn-around, and team and organizational development Slide 2 of 39

3 Presentation assumption: Audience is familiar with Agile concepts and perhaps a specific Agile methodology such as Scrum or Kanban Slide 3 of 39

4 Practice & precepts based on lessons learned from 60+ years of software development experience Most key concepts in use for decades (e.g.; time boxes, iterative development, self-managed teams, colocation, rapid delivery) Now packaged in several popular frameworks and methodologies (e.g.; Scrum, Extreme Programming, Kanban, FDD, Crystal, UP lite, Disciplined Agile Delivery) No single Agile methodology addresses everything! Past experience can help with successful implementation of Agile Slide 4 of 39

5 While strongly supporting Agile Let s not turn a blind eye to the fact that many light weight Agile methodologies cover only a handful of the practices necessary for effective software development projects Nor ignore the fact that some companies do a poor job of introducing and executing Agile concepts and precepts Slide 5 of 39

6 Slide 6 of 39

7 Project management and software development, Agile or otherwise, are huge topics impossible to cover in one brief presentation This presentation is intended only to provide a few examples to get the audience to think about their experience and use it to supplement the often light weight Agile methodologies My observations are based upon personal experience and may differ from other Agile proponents. You must use your own experience to determine what will work best for your situation. (Don t follow the GPS instructions over a cliff!) Slide 7 of 39

8 Key benefits of Agile include opportunities to quickly achieve high value features and discover problems early A focus on delivering working solutions as rapidly as possible with minimal re-work However, we can have problems with a project using an Agile methodology just as we can have problems with any project approach But, if you did it correctly, you wouldn t have problems! Slide 8 of 39

9 Project results we want Project results we get discipline exercise hard work sloth lazy silver bullet Slide 9 of 39

10 The Beginning The Middle The End Slide 10 of 39

11 Inception Construction Transition Slide 11 of 39

12 Most Agile methodologies and literature focus on the middle of the project There are preliminary and follow-on activities that are required to effectively execute an Agile project or program Other areas of the organization are impacted by adoption of Agile Slide 12 of 39

13 Scrum image used by permission Mountain Goat Software Copyright 2005 Slide 13 of 39

14 Inception Construction Transition Management Team Stakeholders Scrum image used by permission Mountain Goat Software Copyright 2005 Slide 14 of 39

15 Slide 15 of 39

16 Enterprise strategic goals, PPM, ROI targets, cost-benefit analysis, feasibility studies all still exist Approach (e.g.; all Agile, combination Agile & traditional, distributed teams, shared teams) How will teams be monitored, motivated & rewarded? How will projects be terminated? Product Owner has achieved sufficient value Early results indicate potential product/project failure Slide 16 of 39

17 Build cross-functional team with shared responsibility for project success Must provide training if team new to methodology Identify Product Owner and ensure they understand their role & responsibility Define done very specifically Identify & define leader/coach role depending upon team needs Scrum Master / Agile PM role will evolve as team matures and experience is gained Scope the project Prepare project scope and initial requirements backlog Include non-functional requirements (design is emergent but architectural boundaries are up front ) Initial effort estimates Slide 17 of 39

18 Sufficient up-front analysis for understanding & risk reduction but not so much as to create rework. Beware false certainty! Scrum Ziv s Law Uncertainty is inherent and inevitable in software development processes and products Hadar Ziv and Debra Richardson, "The Uncertainty Principle in Software Engineering," 1997 Slide 18 of 39

19 Ensure that all stakeholders are identified and understand their needs / responsibilities Necessary in order to define done May help to categorize stakeholders including those external to the organization Set expectations - primary stakeholders will be more intimately and frequently involved than in traditional projects Determine how to coordinate feature and iteration planning with other teams Slide 19 of 39

20 Slide 20 of 39

21 Must support progress tracking based on feature delivery May require dropping or modifying traditional benchmarks and stage gates Earned Value becomes more effective X Agile techniques call for more frequent refinements of estimates than traditional processes Death marches have always been disruptive but even more so for Agile teams Crashing & fast tracking destroy ability to project longterm forecasts and put product quality at risk Slide 21 of 39

22 How much time for this slide? My hot buttons: Need continuous backlog grooming Beware technical debt ( done violations) Continuous builds and effective regression testing are key to quality Maintain a sustainable pace Can t build to a story need to define & design Release planning & coordination are on-going Slide 22 of 39

23 Rapid and easy access to stakeholders is critical to iteration progress & success Including up-stream and down-stream process owners Coordination with inter-dependent Agile teams is frequent (e.g.; Scrum of Scrums) Beware of delayed communications e.g.; monthly or quarterly coordination meetings Disciplines may coordinate e.g.; designers with designers, QA with QA Product Owners have an especially key role Slide 23 of 39

24 Slide 24 of 39

25 Capture project metrics and results for final Cost Benefit retrospective Perform a project governance retrospective Are we getting the information we need? How can we improve in an Agile environment? What cross-enterprise process improvements are recommended? Beware overly prescriptive procedures Slide 25 of 39

26 Agility at Scale: Economic Governance, Measured Improvement, and Disciplined Delivery By Alan Brown, Scott Ambler, Walker Royce To be published: May fc416138/entry/agility_at_scale_economic_governance_measured_improvement_and_disciplined_delivery?lang=ent Slide 26 of 39

27 May require integrated QA test, UAT, beta testers, training, phased deployment, etc. Coordinated turn-over to down-stream stakeholders (e.g.; operations, support) As built documentation including architecture and design, technical debt, and known defects Project completion retrospective and team recognition Slide 27 of 39

28 The Land that Scrum Forgot By Robert Uncle Bob Martin December 14, Slide 28 of 39

29 Acceptance of product Feedback to team and Product Owner What product improvements are needed? What inception, construction, and transition processes improvements are needed? Slide 29 of 39

30 Slide 30 of 39

31 Slide 31 of 39

32 Requirements hierarchy Communication structure Interaction coordination Integrated testing Release planning Program Product Product Theme Theme Theme Theme Epic Epic Epic Epic Story Story Story Story Slide 32 of 39

33 Quick time boxed iterations allow a team to adjust their feature priorities and iteration/release goals Changes to schedule or deliverables still need coordination with other teams and stakeholders Slide 33 of 39

34 Most Agile methodologies focus only on team dynamics Software engineering is given short shrift Your product is likely developed using Object Oriented programming and Service Oriented Architecture A basic understanding of Object Oriented Analysis and Design will greatly improve communications between team members Especially between non-technical and technical staff Slide 34 of 39

35 Team development Communities of Practice Private open source code Anyone can contribute Monitored by responsible party Slide 35 of 39

36 Strictly speaking, it isn t a failure of Agile - Not a failure of the Agile Manifesto - Not a failure of lessons learned from 60+ years of software development But more often Slide 36 of 39

37 Cause Limitations of individual methodologies. For example, limited span of project lifecycle (looking only at development and not inception, development, transition ) or lack of comprehensive requirements engineering techniques. Correction Evaluate your organization s needs and perform a gap analysis between those needs and the scope of the chosen methodology. Using your experience, knowledge, and other sources, supplement the methodology keeping Agile principles in mind. Failure to apply discipline to the application of the methodology and processes. For example, failure to groom the project backlog or allowing technical debt to build up. Enforce team discipline in the application of Agile concepts and the selected methodology. Slide 37 of 39

38 Management of software development is constantly evolving and improving Never stop learning (& un-learning!), never stop pushing the envelope Slide 38 of 39

39 to: Visit website at: Connect on LinkedIn: Slide 39 of 39