Agile Way of Doing Things

Transcription

1 Agile Way of Doing Things Marek Kusmin codeborne.com

2 Codeborne as organization CB is small and growing rather slowly. Wittingly.

3 CB is an organization of very flat type. Wittingly. Different organization models: Flat vs Hierarchial

4 Monumental methodologies drive to hierarchy... via copying or transforming processes to organization structure

5 Hierarchy is not always evil, but has it's dangers More hierarchy means: obstructed information flow more noise slower decision making fading responsibility more self-justification rising and thickening walls etc.

6 Hierarchy is expensive We better avoid it ;)

7 CB staff: Executive Manager 1 PM* 1 Office Assistant 1 UX & Visual Design pros 2 Developers ~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)

8 CB's self-organizing teams have: a) no internal borders b) one general goal within project Goal is valuable software, and team crafts it

9 Craft is a better metaphor for software development than is engineering or science (Pete McBreen) Craftsmen really care about what they are doing

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

11 Build well-crafted software via steadely adding value by a community of professionals in productive partnership with Customer

12 Specialization We specialize on well-crafted tailor made software solutions that meet exact needs of Customer

13 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 industry what we would like to skip instead of learning

14 We will study Customer's business to be able to talk 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.

15 Forestalling question: What languages, tehnlogies, frameworks? Within rational choices there are no limitations

16 Methodology, or How Do We Work What is methodology?

17 It is an agreement about how we do things Simplest description: Customer describes his/her problem, we give rough estimate We agree on houry price, approximate scope or time We (incl. Customer) craft the solution

18 Cone of Uncertainty Customer does not know what he wants. But he knows how to go there.

19 Developers don't know how long it takes exactly to create certain functionality. But we have expertise to give good enough estimations. Better be roughly right than precicely wrong John Maynard Keynes

20 Most important subset of our practices Discipline

21 Whole team and On site Customer Customer is a team member and is always involved

22 Developers can discuss with Customer and get immediate feedback Helps to keep on right track and not to waste resources

23 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

24 Customer has (also) his/her responsibilities Kick-off, story telling

25 Super deep analysis and specs are outdated at the moment they are finished. Or earlyer... BDUF? Better to have simple just enough design

26 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

27 Iteration meeting By book iteration is 2-6 weeks long, our iteration in one week long

28 Iteration meeting gives story details and priorities Daily work

29 Working in pairs Pair programming What's the point?

30 Plenty of reasons: discipline, better design, less errors, more good ideas, knowledge exchange, impressive learning curve, less risks, etc. Customer gets more fuctionalities and better quality for less

31 How? Why you say so? Because Customer does not come to us to order a trivial hello world program Is it done? Testing

32 Testing is also part of development process, not totally separate process after it. Testing must be fast. Automate tests

33 Test first, TDD Testing on different levels

34 Automate everything, not only tests: Packaging, deployment, monitoring, whatever else you can Small releases

35 Releasing often makes Customer happy by giving him/her new features; causes less bugs in release and makes them easy to locate and fix So, deliver ASAP

36 When you can release? (Practically) any time. Code must be ready for it. Continuous integration, continuous deployment. Automated, of course.

37 Refactoring Leave the campground cleaner than you found it!

38 Sustainable pace We do not do overtime

39 How far we are? Burn-down and burn-up charts

40 ... but we actually don't use them Our story board and project management tool PivotalTracker

41 Improve Improving and tuning the way we work. Retrospectives.

42 Learning new things: TeX, coding challenges, conferences, open-source projects University of Tartu Dec 4th, 2015