<Agile In the Enterprise>

1. <Agile In the Enterprise> “can’t we all just get along?” Presented by: joe.ocampo 05/17/2008

2. What we will cover • Approaches to instituting Agile in the Enterprise. • Maybe, Scaling models for Agile • Format • Me talking a lot • Q/A with the “A” consisting of mostly “It depends…”

3. What we will _not_ cover If you don’t know who this character is go ask your parents. If they don’t know I am officially old!

4. What makes project successful? • People communicating successfully to accomplish accomplish a common goal • Without communication and people projects will always fail • Simple in concept but often over looked or neglected

5. You need to understand the big picture but not the brush strokes • Traditional process is prescriptive • Emphasis on getting all the requirements right and written early in the project. “get it right the first time” • Agile process accepts change • Requirements gathering as ongoing, iterative, discovery process • Acknowledge that it’s impossible to get all of the requirements up front • Acknowledge that there is a time value dimension to requirements Start now- evolve to “right”

6. Shifting Agile Pardiggums (paradigm) Waterfall Agile Fixed Requirements Resources Time Value Driven Plan Driven Estimated Features Resources Time The Plan creates cost/schedule estimates Release themes & feature intent drive estimates

7. Anyone heard of these??? • Dynamic System Development Method (Dane Faulkner) • Adaptive Software Development (Jim Highsmith) • Crystal (Alistair Cockburn) • SCRUM (Ken Schwaber) • XP (Kent Beck) • Lean Software Development (Mary Poppendieck) • Feature Driven Development (Jeff DeLuca) • Iterative/Agile – Open UP • What do all these methodologies have in common?

8. Summary of methodologies

9. So what Agile methodology works? • It depends… • They all have a context on which they are applicable but culture and organizational maturity impact their acceptance

10. Standard Team Structure • Optimized for vertical communication • Causes friction across silos • Location via function • Political boundaries between functions Product Mgt Architecture Test and QA Development Management Challenge: Connect the Silos

11. Composite Team Structure

12. Composite Team Char. • Communication is optimized across disciplines in co-located team • Teams have all disciplines necessary • Self-organize and self-manage • Bid, elaborate, execute • Adjust scope and reprioritize • Integrate, test, accept • The functional and social network are optimized to Elucidate/Generate/Validate a potentially shippable increment of software

13. Composite Team Char.

14. There are a lot more Pigs in the Enterprise

15. There are a lot more Pigs in the Enterprise

16. Line of sight planning? • Release Plan at the System Level • Release theme and prioritized feature sets for each release • High visibility and confidence near term (Release “next” and “next+1”). Lower visibility longer term • Three to six to nine months planning horizon • Iteration Plan at the Component Level • Define story cards and tasks for next 1-3 iterations • Adapt and adjust at each iteration • 3-4 weeks planning horizon

17. Line of Site Planning system Release Planning System imposed FEATURES features dependant Iteration Planning requirements Components stories I1 I2 I3 I4 I5 I6 Defects, test cases I1 I2 I3 I4 I5 I6 results components

18. Release Planning

19. Iteration Planning

20. Mechanics of an Iteration

21. Iteration Length • Literature recommends 1 week (XP), 30 days (Scrum Sprint), to 2-6 wks (Agile RUP) • Experience has shown that optimum iteration length is one-two weeks • Short enough to limit procrastination • More times to fail soft per release • Natural weekly calendar cadence

22. Smaller Frequent Releases • Fix release dates • 60-120 days • Releases defined by date, theme, planned feature set, quality • Scope is the variable • Release date and quality are fixed

23. Benefits of Smaller Releases • Rapid customer feedback reduces waste • Earlier value delivery against customer’s highest needs (no fluffy features) • Frequent, forced system integration improves quality and lowers risk • Low cost to change • Accepts new, important customer features • Reprioritize backlog at every iteration & release • Reduced patching headaches • “It’s only X days the next release, that feature can wait” • Smaller increments for higher productivity • Leaner flow through the entire organization to customer

24. Mandatory Continuous Testing • Early and continuous testing is mandatory • Because the system is developed in short, workable increments of functionality: • various kinds of testing that used to be deferred until “delivery” must now be immediate. • Forces a “test early and often” cycle which becomes integral to the iteration process • The programmers and testers write and execute tests as they write the code. • Learn valuable lessons sooner • Peer review of program logic • Risks are discovered and addressed earlier • Quality is improved

25. Concurrent Testing • Unit Testing • Developer written • Functional Testing • Development team/tester/test automation • Acceptance Test • Demo to, and acceptance by, product owner every iteration • System, Performance and Reliability Testing • QA/Test Automation/Developer Written

26. How do we know what to test

27. Practical Issues • The iteration goal is to have tested and accepted software at the end of every iteration • But automation of testing may lag by one or more iterations • Over time: • the set of accumulated functional test cases • + system level and performance test cases serve as full regression tests for iteration and release • The release goal is to execute a full suite of release level acceptance testing, full regression and system and performance testing in less than one iteration • Often, a typical release pattern develops • Initially you must plan for a stabilization iteration

28. Practical Issues cont. Week 1 Week 2 Week 3 Week 4 Modeling/Planning Iteration A Acceptance Test 1 Release Iteration B Acceptance Test Close/Stabilize

29. In case you haven’t been listening… Automate Now! • You have no choice: • Manual tests bottleneck velocity • You can’t ship what you can’t test • Higher development productivity drives more tests

30. Continuous Integration • Continuous integration is neither new nor invented by agile • It has been applied as a best practice in many methods for at least a decade • However, continuous integration is mandatory with agile the teams ability to build continuously is a critical bottleneck to delivered velocity

31. Adapt, Overcome, Improvise • Iterative development processes are organized so that the entire team, including end users • reflects on the results of the process • learn from that examination • adapt the process - and organization - to produce better results • At the end of each cycle, the team decides what to keep doing, what to stop doing, and what to do differently next time

32. What are you building?

33. You can’t do it alone • Involvement of the Product owner is paramount • Don’t attempt to think you know what the business wants!

34. You need to plan, that’s right plan! • I didn’t say architect the space shuttle! • Feature Breakdown/Future Storm • Product Tree/Prune the tree • Sail Boating

35. Planning Games “innovation games”

36. Development Estimation Game • Great Dane (high) (30+ points) • Golden Retriever (medium) (20 points) • Chihuahua (low)(<10 Points)

37. The Secret Sauce • Confidence Level Project Factor • Team Maturity Factor • Your gut and experience as an APM

38. Projects have end dates software doesn’t • Remember to always factor in the cost of maintenance • Tie this back to quality up front • Addressing technical debt early minimizes rework and maximizes value • Your maintenance cost will kill your software but not your project • Understand that maintainable software not completed projects make companies great!

39. Modeling the Domain • All pigs must be present • Start with the domain model • Validate with the UI Sketches • Assure with the acceptance test

40. Get finer grained estimates from the models • Use the domain model along with the screen sketches to drive stories • Stories must have business value! • should be ATOMIC • should be small but valuable • should relate to a compliment or relate to a feature • should be estimatable

41. Task are related to Stories • Avoid Stories that define task • “create Item table” • “create Controller” • A Task is part of a story • A Task means nothing to the business • Try to order your task to maximize collaboration and output • Identify dependencies and atomicity

42. Establish Guiding Principles • Subjective in nature • The “Road Turtles” of agile • Validated by Team when story is delivered • “Screens should allow for entry level personnel to execute with minimal training” • Avoid, “System must use Oracle” • Try “Should allow for high record transactions and high availability”

43. Start at the foundation Building the foundation

44. Stabilize and the end of every release • Now is the time to include the rest of the Chickens • Get infrastructure involved • Talk to compliance • Comply with barely sufficient documentation

45. Your Checksum “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individualsandinteractions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 the items on the left more.”

46. What about compliance and regulatory • Establish the bare minimum to be compliance • Don’t go above and beyond: avoid waste • Think of ways to abstract away from the development stream • Try to achieve automation • Be as transparent as possible

47. What about testing • Automation must be achieved as early in the process as possible • QA is a first class citizen treat them a such • Expect resistance at first “We need requirements in order to test”

48. Watch out for Matrix environments • Matrix styles can impede progress of Agile project • Remember the Iron Triangle • Fixed Resources • Fixed Time • Very challenging for new organizations and often the result of a failed adoption

49. Do you need a PMO • The short answer, “Yes” • The real question is, “Do I need a traditional PMO?” • Since Agile does not promote matrix management PMO must adopt a new strategy to manage resource, value and time lines. • Be creative, but not careless

50. People have to be team players • If you have big Ego’s or Hero personalities expect challenges in adoption • Agile is about the Team not the individuals • You succeed from the effort of the whole and not the one • Koby Bryant : not agile