Agile Methods - Enterprise v’s ISV

Gary Short

Senior Technologist

Charteris Plc.http://www.garyshort.org

1

Presenter Biography

17 years experience– American Express– HBOS– SSE

• Agile since 1995– IBM

• Founder members DSDM Consortium.

2

Why are we Here?

3

Definition: Enterprise

• A group of inter-operating departments working together to form a single commercial entity.

•

4

Definition: ISV

• Companies making or selling software, usually in niche markets.

•

5

Definition: Agile

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

6

In Other Words…

• An iterative approach to software development is taken.

7

8

Agile Manifesto #1

• Individuals and interactions over processes and tools.

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– …

Build

Test

Design

Deliver

Review

10

Agile Manifesto #1 - ISV

1. Get Requirements

2. Design

3. Build

4. Test

5. Deliver

6. Review

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

Agile Manifesto #15

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

51

Agile Manifesto #15 - Enterprise• Easier for the enterprise

– Enterprise a cost centre• Does not have to drive the profit of the

company– More time to spend on reflection at the end of

an iteration / project– Any spend on technology required to make

improvements does not affect the company’s bottom line

– Usually a better spend on automatic testing software within an enterprise

– Achieved via end of iteration / project reviews and peer review / automatic review of code.52

Agile Manifesto #15 - ISV• Harder to achieve for ISVs

– Profit centre• Anytime spent away from fee earning

affects company’s bottom line• Service support contracts• Fix bugs on delivered software etc

– Less likely to spend on automatic testing and code coverage tools

• Thank God for open source!

• Can be achieved with the use of tools but less likely to be. 53

Biggest Takeaway

• No plan survives first contact with the enemy.

54

Changing Plan Makes Software Development Hard

• When you are up to your arse in alligators, it’s hard to remember your plan was to drain the swamp!

55

It’s Worth Persevering!

• Agile is the best way to deal with changes to– Requirements– Timescales– Resources– Cost.

56

Questions?

57