Agile Way of Doing Things

Marek Kusminmarek @ codeborne.com

Codeborne as organization

CB is small and growing rather slowly.Wittingly.

CB is an organization of very flat type.Wittingly.

Different organization models:Flat vs Hierarchial

Monumental methodologies drive to hierarchy

... via copying or transformingprocesses to organization structure

Hierarchy is not always evil, but has it's dangers

More hierarchy means:obstructed information flow

more noiseslower decision making

fading responsibilitymore self-justification

rising and thickening „walls”etc.

Hierarchy is expensive

We better avoid it ;)

CB staff:Executive Manager – 1

PM* – 1Office Assistant – 1

UX & Visual Design pros – 2Developers – ~25

Analysts, Architects, Testers, Heads of Smth etc. – 0* not exactly PM in a usual meaning but we never thought much about position name(s)

Teams as are rather small – 2 or 4 developers(in rare situation 6 developers)

CB's self-organizing teams have:a) no internal borders

b) one general goal within project

Goal is valuable software, and team crafts it

Craft is a better metaphor for software development than is engineering or science (Pete McBreen)

Craftsmen really care about what they are doing

Your product is not anonymous.You put your own name on it.

Passion

Build well-crafted softwarevia steadely adding value

by a community of professionalsin productive partnership with Customer

http://manifesto.softwarecraftsmanship.org/

Specialization

We „specialize” on well-craftedtailor made software solutions

that meet exact needsof Customer

Some domains/customers:finacial institutions and investment companies,

energy and power grid, telecoms, GIS,cryptography, photography, fuel/gas,

software development, HR, education etc., etc.

We haven't met an industrywhat we would like to skip instead of learning

We will study Customer's business to be able totalk to Customer in his/her language,understand his/her exact problem,

suggest (better/less costly) solutions,provide software that has real value

There can be other reasons we refuse of contract or cooperation – ethics, for example,

or because we do not see a viability of project.

Forestalling question:What languages, tehnlogies, frameworks?

Within rational choices there are no limitations

Methodology, or How Do We Work

What is methodology?

It is an agreement about how we do things

Simplest description:

Customer describes his/her problem,we give rough estimate

We agree onhoury price, approximate scope or time

We (incl. Customer) craft the solution

Cone of Uncertainty

Customer does not know what he wants.But he knows how to go there.

Developers don't know how long it takes exactlyto create certain functionality.

But we have expertise to give good enough estimations.

„Better be roughly right than precicely wrong”John Maynard Keynes

Most important subset of our practices

Discipline

„Whole team” and „On site Customer”

Customer is a team member and is always involved

Developers can discuss with Customerand get immediate feedback

Helps to keep on right track and not to waste resources

„On site Customer” – practice has changed over time

But still – from time to time people must meet in person even if there is long distance between locations

Customer has (also) his/her responsibilities

Kick-off, story telling

Super deep analysis and specs are outdatedat the moment they are finished.

Or earlyer...

BDUF? Better to have simple „just enough” design

Are specs a waste?

Not necessarily.If done with right sense, they

make Customer to think about his/her problem,help to keep Customer on track during story telling

Iteration meeting

„By book” iteration is 2-6 weeks long,our iteration in one week long

Iteration meeting gives story details and priorities

Daily work

Working in pairs – Pair programming

„What's the point?”

Plenty of reasons:discipline, better design, less errors,

more good ideas, knowledge exchange,impressive learning curve, less risks,

etc.

Customer gets more fuctionalities andbetter quality for less

How? Why you say so?Because Customer does not come to us to order

a trivial „hello world” program

„Is it done?” – Testing

Testing is also part of development process,not totally separate process after it.

Testing must be fast.

Automate tests

Test first, TDD

Testing on different levels

Automate everything, not only tests:Packaging, deployment, monitoring,

whatever else you can

Small releases

Releasing oftenmakes Customer happy

by giving him/her new features;causes less bugs in release and

makes them easy to locate and fix

So, deliver ASAP

„When you can release?”(Practically) any time.

Code must be ready for it.

Continuous integration, continuous deployment.Automated, of course.

Refactoring

„Leave the campground cleaner than you found it!”

Sustainable pace

We do not do overtime

„How far we are?”

Burn-down and burn-up charts

... but we actually don't use them

Our story board and project management tool – PivotalTracker

Improve

Improving and tuning the way we work. Retrospectives.

Learning new things:TeX,

coding challenges,conferences,

open-source projectsetc.

@ University of Tartu Dec 4th, 2015