toniBlog

A weblog about Methodologies for Development

A very long list of Agile, Lean & C. books

I've used to have this list on a Google Spreadsheet, it took me quite a while to sort it (the first 3-5 books for each category are more essential than the others) and place the links, but here it is, more than sixty agile-related books! Agile Process Additional Context Agile Development Lean

Project Standards

I recently played a leadership role in a project where two of the biggest challenges where the time schedule and the team on boarding. I hate repeating myself, so after explaining the technology, architectural choices a couple of times I decided to write some kind of document or presentation. I've created a sample document containing for each of the areas of the project a paragraph explaining shortly all the decisions made so far. The document has been then showcased to the whole team for feedback. So, let's see some part of the document, as example: Services (A similar paragraph was written for each component of the architecture) Why?
  • To decouple layers
  • To have isolated Transactionality
How
  • POJO configured with Spring (context-service.xml)
  • @Transactional annotation on any method call that requires Transactionality
  • @Service class annotation for Spring
  • @Autowiring constructor annotation for Spring
  • Completely stateless
References
  • Domain Driven Design
Mock tests Why
  • We want a fast feedback and test only objects interactions rather than effects
  • Test Double
How
  • Mockito framework to verify objects interactions
  • A Mock test should be written at least for
  • Services (mocking DAOs, JMS)
  • DWR Objects (mocking Services)
References
  • Mockito homepage
  • TestDouble page
  • Martin’s Mocks aren’t stubs page
And then for each major framework chosen, for Spring was something like: Why
  • Lightweight solution
  • Easy to test out of the container (POJO beans)
  • Goes very well with DWR, Terracotta and Atomikos
How
  • Every bean is configured in a file called context-xxx.xml
References
  • Spring Vs EJB 3
  • New Spring 2.5 Features
  • Spring Reference Documentation
What about code conventions? Ground rules
  • All fields private, information hiding
  • Reduce as much as possible private methods (usually the logic that sits in private methods can be extracted in another class), also a private method is not directly testable by unit tests.
  • use composition rather than private methods or utility classes, with composition every object can have isolated responsibilities and isolated own test
  • Methods, variable, package, class names should be speaking and tell to who’s reading the code what they’re there for
  • Avoid code smells, in particular:
  • DuplicatedCode
  • Methods too big
  • Classes with too many instance variables
  • Classes with too much code
  • Strikingly similar subclasses
  • An instance variable that is only set in some circumstances
  • Comparing variables to null
  • Too many private (or protected) methods
  • Many messages to the same object from the same method
  • ExcessiveOverloading
  • SameNameDifferentMeaning
  • Code not actually ever used
  • Classes with too few instance variables
  • Classes with too little code
  • Methods with no messages to self
  • Empty catch clauses
  • Explicitly setting variables to null
  • Comments
  • ExcessiveLogging
  • ContrivedInterfaces
  • LawOfDemeter Violations
  • SwitchStatements
and so on... We got also a section on process, since everybody implements Scrum in its own way we highlighted our numbers: For Scrum for example the list looked like this one:
  • Daily Stand-ups 9.30 AM
  • Two weeks long Sprints
  • End Of The Sprint Retrospective
  • Planning Game at the start of the Sprint
  • Product Backlog
References
  • Control Chaos Homepage
  • Any Mike Cohn’ presentation or article about Scrum
  • Any Mike Cohn’ presentation about estimating and planning
Conclusions Documentation in Agile is often  enemy number one, however, if you are planning to scale out your project you will need some help, Office tools are a bad beast, you can always write this type of ground rules on some cards and leave them on the wall (oh well, what if you offshore the project!). This type of document helped me to do not miss anything, I kept it up to date with the code as soon as a new team member was joining it and I've got good feedback from the team (they liked the concise style and the references for further investigation). The client loved it too, finding out that we had a well defined stack of rules and process to follow, so no surprises. Technical discussion were still allowed, the document wasn't written in stone: every body in the team should feel free to criticise and then contribute to make the code/process better.

Planning extreme programming

This weekend I've managed to read Planning Extreme Programming by Kent Beck & Martin Fowler, I've been rather impressed by the book, the first edition is dated  October 2000 so it's almost 10 years old now, in this post I'll share some notes  I've taken during the reading, mostly related to the similarities with Scrum.

XP population

Kent and Fowler launched a survey on the XP mailing list asking which  size of an iteration was more popular, they got only 37 replies, in these days the list has around 9000 users, with hundreds of messages every week...

Practises

Stand-ups meetings, release planning, iteration planning, concept of done: all well described here.

Have a short meeting once a day so everybody knows what's going on, and what's not.

At the end of each iteration, the whole team would gather round and watch the developers demo the work in which each had been involved in the preceding three weeks.

A story is done when the function of that story is demonstrated to the customer and the customer agrees that the functionality substantially fulfils what is expected.

Graphs

There are no burn down or burn up charts, but few graphs are suggested (including Story Progress, does it sounds familiar?)

There's no backlog but the stories are prioritized and the ones with lower priority put into a drawer.

Wrap future stories with a rubber band and stick
them safely in a drawer.

Pairing

Pairing is mentioned just a couple of times (I'm sure just because is implied), and the first time at half of the book.

Retrospectives

There's even a first idea of retrospective:

If you have the ceremonial pushing of the acceptance test button
at lunch on the last Friday of the iteration, you can spend the rest of the day talking about your process.

Scrum master

There's no scrum master, indeed, scrum wasn't born but the tracker role sounds a lot like the SM one...

This person, the tracker, keeps an eye on which tasks are done and
how much is left on outstanding tasks.

Fine grain tracking

Last but not least there's a mention to the pomodoro technique:

(Francesco Cirillo told us he bought a half-hour kitchen timer in the shape of a tomato, so they now refer to a "six-tomato task.")

Conclusions

Great book, it gave me the impression that Scrum just adds some names and defines in a deeper details ideas and practises that have been written  years before.

I've just started to read Agile Project Management with Scrum to better understand what Scrum really adds, XP, so far, honestly seems to me more lean than Scrum.

When made in Italy is not only fashion

Francesco just published his brand new website about the pomodoro technique and Staffan just published the first draft on the technique of his book. As an additional coincidence Renzo talked about it at the Software Craftsmanship Meeting.  All around the world from Sweden to the US it's all about italian tomatoes!  

Media_httpwwwpomodoro_jvgdz

The Pomodoro Technique is a time management method that can be used for any kind of task. For many people, time is an enemy. The anxiety triggered by 'the ticking clock', especially when a deadline is involved, leads to ineffective work and study habits which in turn lead to procrastination. The aim of the Pomodoro Technique is to use time as a valuable ally in accomplishing what we want to do in the way we want to do it, and to enable us to continually improve the way we work or study.