Methodology Wars Return of the Developer

Jim WalmsleyChief Architect, BIS2

bis2.netJune 2010

Case I: The Project Menace

A long, long time ago in a galaxy far, far away, it was two years into the DeathStar V2 project. The project had been falling

increasingly behind schedule. Development iterations were lengthening and “refactoring” had become the major

activity in the development team. The Project Manager Darth Vader visited

to the site to inform the Development Commander Tiaan Jerjerrod that the issue

needs to be rectified.

Lord Vader arrives in time for the morning stand-up…

DeathStar V2 Project Morning Stand-up

Lord Vader, this is an unexpected pleasure. We are honoured by your

presence.

You may dispense with the pleasantries Commander. I'm

here to put you back on schedule!!

I assure you Lord Vader my

developers are working as fast as

they can!

Perhaps I can find new ways to motivate them!

I tell you this project will be completed as

planned!

Case I continued

Then perhaps you can tell him when he

arrives.

He asks the impossible! I need more developers.

The emperor does not share your

optimism.

The Emperor is coming here???!!

Case I continued That is correct. And he is most displeased with your

lack of progress!

I hope so, Commander, for your sake. The Emperor is not

as forgiving as I am.

We shall double our efforts!!

Outline

Software Development: a Craft

What is this Thing Called Methodology?

Case Studies

Conclusion

Software Development: a Craft

•Not an art•Not a science

•A creative process

•A collaborative process

requirements

architecture standards

patterns

experience

deployment ctx ingenuity

collaboratecreate•Aptitude and attitude

•Years to learn

•Mentoring

What is this Thing Called Methodology?

A Method: a series of steps taken to achieve some end.

A Methodology:

• a description of a process

• may be expanded to include the philosophical basis

• the systematic study of how things are done

Important words: process, discipline, philosophy

Philosophy

Sometimes stated, sometimes not.

•Your staff knows what they're doing

•Simplicity

•Agility

•Focus on high-value activities

Agile UP:

Each implementation will have underlying philosophies

•Minimise risk?

•Process can make up for variable ability among the staff?

•Management must be in control?

•Watch your back?

Methodology is necessary

Industry-standard methodology:

You don’t have to re-invent

•Requirements, communication, reporting, change, risk, architecture

•Budgets, stakeholders, responsibilities

•Documentation

•Transitions, sign-offs

Software development:•Numbers of people•Limited money•Limited time•Competition

Methodology helps us manage the process of software development

It is not the key to success. Here is an example…

Case II: Attack of the Programmers

The Environment

Large banking customer

Project to replace a key online application

Overseas group companies looking for synergy

Purchased an industry-specific framework

Medium-sized team: Customer's BAs, Vendor's Dev & Test, several contractors

The Methodology

Modified RUP / Customer's

Case II: continuedObservations

Politics

Team a bit dysfunctional

Difficult to establish standards

Toolset issues

Project experienced delays: group companies requirements, framework, lab "specialists"

Mongolian Hordes approach to resourcing

The project was delivered but it was very protracted and expensive

Dilbert Factor

Lessons

Methodology would have been adequate for a smaller cohesive team.

Politics can get in the way of making the right decision.

Remember the Mythical Man Month.

The team just was not happening.

Imposing unpopular tools on the dev team as asking for trouble.

Yoda says…

“A Developer must have the deepest commitment, the most serious mind.”

"Remember, a Developer's strength flows from the Force. But beware. Anger, fear, aggression. The dark side are they. Once you start down the dark path, forever will it dominate your destiny."

Obi-wan says…

“The Force is what gives a Developer his power. It's an energy field created by all living things. It surrounds us, penetrates us, and binds the galaxy together.”

Martin Fowler says…SEMAT (Software Engineering Method and Theory) is an effort initiated by Ivar Jacobson, Bertrand Meyer, and Richard Soley. Its stated aim is to "refound software engineering based on a solid theory, proven principles and best practices“.

…I got the distinct impression that the central thrust of the initiative is to create a software meta-method-kernel - essentially a set of common process elements for software developments that you can rigorously compose into a method for your own project.

At this point I lost interest.

…since people are the central element in software development, and people are inherently non-linear and unpredictable - such an effort is fundamentally doomed.

Lots of People say…

It’s all about People, Processes and Tools!

Three things about Tools:

•Awkward or unreliable tools will impede the project. It’s worth getting it right.

•A common toolset helps collaboration.

•Imposing unpopular tools on developers is asking for trouble.

People:

Are creative

Are social

Are political

Are different

Get sick

Need respect

Need rewards

Don’t thrive on fear

Need to have fun

Have ambitions

Have families

Have issues

Have rights

Some are talented

Some are not

Some are reliable

Some are not

Some are right for your team

Some are not

In Search of the Force

Methodology does not tell us how to write good software.

May recommend practices such as:

•Continuous integration

•Iterative development

•Test-driven development

•Prototyping

In the end someone has to write and test the code.

Uber-methodologies are selectively used.

May be only Reviews, Checklists, Document templates.

May over-look the implementation phase.

Case V: The Waterfall Strikes BackThe Environment

Large M&E Programme (up to 90 people)

Key application for large customer in utilities sector

3GL

Performance, availability and reliability very important

Very short change window (about 1 hour per month)

Customer relationship often confrontational

Turbulent history at start-up

The Methodology

Waterfall

Some flexibility: lightweight version for simple changes

Monthly releases

Case V continuedObservations

Expert knowledge available from a strong group of senior APs and TAs

Estimates fairly reliable

A cross-section of senior- and intermediate-level personnel

Informal mentoring

Good team cohesion, trust within the team, low turnover

Teams co-located

Team leaders well in touch with the work

Good reporting from developers to team leaders to PM

Quality management

Good process documentation and compliance (ISO9001 Certified)

Process improvement programme

Very few unscheduled outages

Not much program documentation

Case V continued some moreLessons

Appropriate methodology for the environment

The team rocked

- good communication

- good attitude to quality

- a disciplined, capable team

Split a large team into smaller teams to get optimum size.

Colocate team

Seniors play important role

Case IV: A New Hope

The Environment

Medium web application development project

Medium-sized customer, good relationship with the vendor

Very budget-conscious

Small team: Project Manager, Solution Architect, BA, two contract Java programmers (Sun Certified)

The Methodology

Modified RUP

Case IV continuedObservations

Toolset not quite adequate

The project went through all the stages and sign-offs to UAT

Performance problems noticed

Independent review by senior developer

Code so badly written that it could not be fixed

Programmers did not produced what the architect specified – didn't know how

No effective code inspection or tech review

Case IV reloaded

Observations

Minimal toolset

Application redesigned and built using Struts

Team worked closely, communicated effectively

Application delivered, customer satisfied

The Environment

Medium web application development project rescue

Medium-sized customer, damaged relationship with the vendor

Very budget-conscious

Small team: Lead Developer, 2 Seniors, 1 Intermediate, BA, Tester

The Methodology

Very lightweight Agile-ish

Case VI: Return of the DeveloperThe Environment

Start-up company building a new BI product

Entrepreneurial phase: dev team has to be responsive

Tension between architecture and features

Multinational

Flat organisation – everyone knows everyone

The Methodology

Agile

Short sprints, well-defined stories, iterative delivery

Test-driven development

Continuous Integration

Sprint cycle: kick-off, estimate candidates, finalise sprint, develop, test, demo, sprint review

Daily stand-ups: brief

Case VI continuedPhilosophy

Trust

Shared Responsibility

Everyone can question

Fun

The Development Team

Carefully selected

Small, collocated, structured senior/intermediate/junior

Clear distinction of roles: product owner, team leader, architect, senior product designer, senior developer

Rocks

Communication

Carefully selected

Small, collocated, structured senior/intermediate/junior

Clear distinction of roles: product owner, team leader, architect, senior product designer, senior developer

Case VI continued some moreCommunication

Wiki – all documentation.

Skype & WebEx: conferencing, demos, phone

Gmail, Google group services

Big whiteboard

No process document templates, no e-mailed Word docs

Results

Innovative new product to market in less than three years.

Installed customers.

Recognition in the industry.

ConclusionChoice of methodology will be influenced by:•Commercial environment•Corporate standards•Customer standards•Experience with methodologies

I believe that a simple methodology, well-understood by all and thoughtfully applied is a powerful tool.

A complex methodology, not understood by all and only partially applied is a blunt instrument.

And The Force?

It really is about human interaction: teams that rock.