Agile Methods - Enterprise v’s ISV

1. Agile Methods - Enterprise v’s ISV Gary Short Senior Technologist Charteris Plc. http://www.garyshort.org

2. 17 years experience American Express HBOS SSE Agile since 1995 IBM Founder members DSDM Consortium. Presenter Biography

3. Why are we Here?

4. A group of inter-operating departments working together to form a single commercial entity. Definition: Enterprise

5. Companies making or selling software, usually in niche markets. Definition: ISV

6. Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project. Definition: Agile

7. In Other Words… • An iterative approach to software development is taken.

9. Individuals and interactions over processes and tools. Agile Manifesto #1

10. Agile Manifesto #1 - Enterprise • Prince 2 • Starting up a Project • Initiating a Project • Directing a Project • Control Stage • Managing Project Delivery • Managing Stage Boundaries • …

11. Agile Manifesto #1 - ISV • Get Requirements • Design • Build • Test • Deliver • Review • Goto 1.

12. Agile Manifesto #2 • Working software over comprehensive documentation.

13. Agile Manifesto #2 - Enterprise • Hard to do • Structure requires documentation • On time and on budget • Tracking against plan • Financial tracking • People further up the pyramid “need to know” • These people often don’t understand “software”.

14. Agile Manifesto #2 - ISV • Much easier • Owner • Developer • Customer • All understand “Software” • “Software” gives owner sense of “on time and on budget”.

15. Agile Manifesto #3 • Customer collaboration over contract negotiation.

16. Agile Manifesto #3 - Enterprise • Customer normally internal • Unlikely to sue • Don’t need to tie everything up in water-tight legal-speak • Concentrate more on software than legal issues • Symbiotic relationship • Both parties working towards a common goal • Benefits both parties.

17. Agile Manifesto #3 - ISV • Customer is a separate entity • If things go wrong they may sue • Contract must be tight to protect owner • Losing a law suit may spell the end of the company.

18. Agile Manifesto #4 • Responding to change over following a plan

19. Agile Manifesto #4 - Enterprise • Hard to do • Many stakeholders • Lots of discussion • Lots of people have a say • Lots of people must sign off • Software has dependencies • Change affects budgets • Change affects timescales • Change control process.

20. Agile Manifesto #4 - ISV • Easier to do • Software has no dependencies • Easy to communicate Change • Usually just one stakeholder • No real sign off required • Contract! • Watch terms • Should be worded to make change easy • Handled by conversation/email.

21. Agile Manifesto #5 • Deliver early, deliver often.

22. Agile Manifesto #5 - Enterprise • Harder to do • Handled by release process • QA • ISO standard documentation • Hard to control who has what version • Locked down desktop • Can all stakeholders see it at once? • Next cycle may start before last one has finished.

23. Agile Manifesto #5 - ISV • Easier to do • One customer • Easy to know that they have seen it • Easy to handle problems • No locked down desktop • Short deliver cycles • Handle with ClickOnce etc.

24. Agile Manifesto #6 • Welcome changing requirements, even late in development • Agile processes harness change for the customer's competitive advantage.

25. Agile Manifesto #6 - Enterprise • Harder to do • Change means change process • Lots of meetings • Lots of agreement required • What’s best for the customer not always best for development • Good changes rejected • Change not often embraced in the enterprise.

26. Agile Manifesto #6 - ISV • Easier to do • No change process • Few stakeholders • Easier to get agreement • What is good for the customer is good for the ISV • Change much more likely to be embraced in an ISV.

27. Agile Manifesto #7 • Business people and developers must work together throughout the project.

28. Agile Manifesto #7 - Enterprise • Stakeholders may work on other teams / projects • This project may not have focus • This project may not be most exciting • Only so many productive hours in the day • There can be only one first priority • Handled by regular scheduled meetings.

29. Agile Manifesto #7 - ISV • Customer’s business is running his business • Project may not have his focus 100% of the time • Customer may have his own problems to deal with • “Just get it done” • Not an expert in all aspects of the business • “Just do what you think’s best” • Handled by regular scheduled meetings.

30. Agile Manifesto #8 • Build projects around motivated individuals • Give them the environment and support they need • Trust them to get the job done.

31. Agile Manifesto #8 - Enterprise • Harder to do due to fixed teams • “Rockstars” • Architects • Developers • Separation between business and developer means more layers of oversight is required • More resources • Better kit (replaced cyclically) • Better working conditions • Normally handled by lowest common denominator or “who’s free to do this job now?”.

32. Agile Manifesto #8 - ISV • Easier to do in ISV • Smaller number of people • Easier to accommodate individual’s • Strengths • Weaknesses • Interests • May be natural leaders and followers in an ISV • Easier to accommodate as there may not be fixed roles as in an enterprise • ISV teams do tend to self select.

33. Agile Manifesto #9 • The most efficient and effective method of conveying information is face-to-face conversation.

34. Agile Manifesto #9 - Enterprise • Harder to do • People working on multiple projects • Departments may be split over multiple sites • Many stakeholders • Other commitments • Holidays • Training courses • Handled by regular scheduled meetings and copious amounts of documentation.

35. Agile Manifesto #9 - ISV • Easier to do • One customer or Subject Matter Expert • More likely to respond to • Telephone calls • Emails • More likely to be able to “pop in for a chat” • It’s the customer’s livelihood • More likely to be interested in the process of developing the software • Normally handled by ad hoc conversations as required.

36. Agile Manifesto #10 • Working software is the primary measure of progress.

37. Agile Manifesto #10 - Enterprise • Harder to do • Corporate structure means many degrees of separation • Many people need to be kept informed • Easiest way to do this is “The Plan” • Software means nothing to many of these people • “On time” is judged against “The Plan” • “Within Budget” is judged against “The Plan” • Normally “The Plan” becomes the focus not the software.

38. Agile Manifesto #10 - ISV • Easier to do • Customer is more focused on the software • Normally business critical • Billing • Order processing • Process management • Less focussed on cost and timescales (within reason) • Rather have it right in a month than almost right now • “The Plan” means little to the customer • Software usually the primary measure of progress in an ISV.

39. Agile Manifesto #11 • Agile processes promote sustainable development • The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

40. Agile Manifesto #11 - Enterprise • Easier to do in the enterprise • Less likely to be a “crunch” • Enterprise cost centre not a profit centre • The budget is allocated upfront • Change is managed • More requirements = more time = more budget • Easier to “rest” team members if there is a “crunch” • More people available to cover “resting” staff • Staff in the enterprise usually do work at an even pace.

41. Agile Manifesto #11 - ISV • Harder to do in an ISV • ISV is a profit centre • If development don’t make money the company goes bust • Develop software • Service support contracts • Fix bugs of already live software • Much more likely to be a “crunch” • Nowhere to hide • Can’t “rest” staff • No one to cover • Much less likely to work at an even pace.

42. Agile Manifesto 12 • Continuous attention to technical excellence and good design enhances agility.

43. Agile Manifesto #12 - Enterprise • Easier to do in the enterprise • Technical design authority • Concentrate on • Patterns • Best practices • What works in their particular enterprise • Coding standards • Disseminate this knowledge throughout the enterprise • Can attend team meetings to provide further guidance • Enterprise better equipped to maintain technical excellence.

44. Agile Manifesto #12 - ISV • Harder to do for an ISV • ISV is profit centre • Work on improving technical excellence is hard to see on the bottom line • Time is money • No time for research into • Best practices • Patterns • Coding standards • Lessons learned from one customer are hard to bring to another customer • Technical excellence not a top priority for ISV.

45. Agile Manifesto #13 • Simplicity is essential • Maximize the amount of work not done.

46. Agile Manifesto #13 - Enterprise • Harder to do for the enterprise • Requirements set up front • MoSCoW not really possible • Not much flexibility • Changes have to go through change process • Enterprise development teams can only really have an impact here at iteration level • All requirements still must be met • Just not in this iteration • Need a good BA to accomplish this at requirement time • Normally handled via slow change process.

47. Agile Manifesto #13 - ISV • Easier to do in an ISV • Customer only interested in “getting the job done” therefore more receptive to MoSCoW • If timescale or cost coming close his budget then he’ll be more likely to drop the “Could haves” from the iteration • Easier to illustrate to the customer that the “could haves” and “wont haves” can be abstracted out and put into another iteration, or another project (version 1.1) altogether • Achieved via MoSCoW analysis at project / iteration start.

48. Agile Manifesto #14 • The best architectures, requirements, and designs emerge from self-organizing teams.

49. Agile Manifesto #14 - Enterprise • Hard to do in the enterprise • Related to #8 on self organising teams • They are hard to achieve in the enterprise • Therefore this is hard to achieve • Not often achieved in the enterprise because self-organising teams are not often achieved in the enterprise.

50. Agile Manifesto #14 - ISV • Again, related to #8 • ISVs can achieve self-organising teams • Team members more comfortable in their roles • Therefore solutions they come up with are better • Achieved via use of self-organising teams which is possible as it’s less likely roles within an ISV are as rigid as those within an enterprise.