1 / 57

Agile Methods - Enterprise v’s ISV

Agile Methods - Enterprise v’s ISV. Gary Short Senior Technologist Charteris Plc. http://www.garyshort.org. 17 years experience American Express HBOS SSE Agile since 1995 IBM Founder members DSDM Consortium. Presenter Biography. Why are we Here?.

naava
Télécharger la présentation

Agile Methods - Enterprise v’s ISV

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

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

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

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

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

  12. 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”.

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

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

  15. 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.

  16. 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.

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

  18. 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.

  19. 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.

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

  21. 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.

  22. 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.

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

  24. 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.

  25. 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.

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

  27. 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.

  28. 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.

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

  30. 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?”.

  31. 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.

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

  33. 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.

  34. 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.

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

  36. 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.

  37. 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.

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

  39. 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.

  40. 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.

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

  42. 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.

  43. 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.

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

  45. 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.

  46. 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.

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

  48. 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.

  49. 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.

More Related