Great Italian Agile Day 2011 in Rome!
On early Saturday morning November 19th, we (16 colleagues) left from Pagani (Salerno) with a mini-bus to reach the venue of the annual conference of Italian agile community. This year was more crowded and participated than ever: 600 hundred people gathered to listen to interesting sessions, exchange opinions and networking by a rich buffet of Vegan cakes, fruit and tasty coffee from fair trade. Sign of a very passionate and live community.
Here below are some notes from me and some other colleagues. Hope you find them interesting and useful.
Videos for the sessions can be found here.
Paolo Polce – Back to basics: OOP and design (Keynote)
What is SW development comparable with?
- Writing SW is Engineering?
- Engineering components are real, SW is not
- Interactions are more predictable in engineering
- SW is required to change during development
- There has always been the attempt to compare the two
- Bad news: SW is not engineering
- Writing SW is Science?
- No, it’s not! Imagine something like Debug Driven Design.
- Writing SW is art?
- Sometimes when you look at some code, you end up in wondering what the poet could mean with that 😮
- There’s only one thing in common with arts: distribution between men (90%) and women (10%)
- Very disappointing: Programming is not either an art nor perceived as an art.
There’s no book: programming sits somewhere between engineering, science and art. Do not expect “The book” that makes everything clear about SW.
Who writes SW? We always talk about SW architects, SW analysts, SW evangelists and then…resources, who simply have to push buttons on a keyboard and write code!
Instead: Technical skills matter!
Do lots of deliberate practice! Athletes know the difference between training and performing. And they know they cannot perform without training.
TDD with MockObjects (in Java).
Push your design. Try to:
- Remove getters
- Remove sigletons
- Remove train wrecks
- Refactor as you go
- Split responsibility as soon as your method reaches 5 or 10 lines of code (!!!)
- Do not make your tests more complicated than the actual code or you will have to test the tests
- Don’t be skeptical about new proposals
- Learn new stuff. You haven’t finished yet learning! No one has!
- Make your code a pleasant place to live in.
Suggestion for reading: Kevlin Henney – 97 things every programmer should know
Francesco Cirillo – Is SW evolution really effective?
Code Monsters are really common. See: http://www.antiifcampaign.com/code-monster.html
- What does SW evolution really means?
- How much should an effective SW evolution cost?
SW development is like growing green beans! Is this what really happens? Not at all.
Different SW lifecycles: some of them are considered agile, but they are not really.
Extension vs. Change. Agile principles say : Embrace Change not only extension of requirements.
Agile SW development is evolutionary. The point is that the terms evolutionary and emergent do not mean anything, because they do not say anything about what to do and when to do it. That’s why also a lot of “mature” teams are not able to make effective SW development, i.e. doing things with less effort, while sometimes agile team look to cost more.
How much does effective SW evolution cost?
Adding new features to our system should cost less moving forward (especially if we talk about adding similar features), because we gain experience and competence on the system and on the technology.
Is this really what happens? Data show this is not always the case.
Lesson #1: SW evolution cost too much.
Question: Would you buy your own SW?
Developer answers: No!
Lesson #2: “Mature” teams cost more
Because if we do not develop SW in the right way, we end up sooner or later in a code monster, which is more expensive in evolving and adding new features.
Claudio Perrone – Lean, A3 and kaizen
A3 thinking: given a theme here are the process steps.
- Background – Why are we talking about that?
- Current status – Include Value Stream mapping of the status quo
- Problem statement (A problem is the gap between a given standard or expectation and the current situation)
- Expectation – What should happen?
- Discrepancy – Expectation vs. Current situation
- Extent – How big is it?
- Rationale – What happens if no action is taken?
- Target – What? How much? By when?
- Analysis – Use “5 Why’s” technique. Analyze facts not opinions.
- Countermeasures –FutureState Map
- Implementation – Action Plan
- Follow up
The new status becomes the new starting point.
A3 thinking can be applied to quick coaching cycles to let people improve.
In order to flip the triangle of leadership, we do not need manager who are policemen, friends or absents. Or managers by status report. We need managers who fix problems.
Be soft with people and tough with processes –Toyota.
What is wrong in the process which does not allow people to do their best?
If you want 1 year prosperity, grow seeds.
If you want 10 years prosperity, grow trees.
If you want 100 years prosperity, make people grow – Chinese proverb
Alberto Brandolini – I wanted only to write code
Developing SW is a learning process.
- Seniority: Passive act of time passing by. It is tied to habits.
- Experience: Conscious act to learn from what happens.
Learning is tied to how much time you spend to reflect with others and re-interpret what happened and what you learned. Learning can only happen with Motivation.
Motivation (Sometimes there just isn’t any)
- Relatively simple to destroy
- Almost impossible to re-build
Usually you learn without asking for permission.
There is no straight training plan: simply it does not exist. It is true like Santa Claus is.
Andrea Provaglio – Overcoming self-organizing blocks
- SW is intangible – Its’ an arbitrary representation of an intention (there’s not only one solution to a given problem
- SW is collaborative – We developers make our lives complicated to make someone else’s lives easier. It is not possible solve a complex problem alone in a time which is compatible with modern business needs.
- SW is heuristic – It’s a learning process. It’s an answer to problems which are always new: if we had already a SW which solves a certain problem, we wouldn’t need to develop it.
Agile at its core
- SW development is empirical (feedback loops)
- Teams are systems (self-organizing)
Bad news is that we come from a culture of assembly lines and frontal education systems: both are phased approaches. Education systems, for instance, do not teach us working in teams: you’re not allowed to copy at school, while, if you copy something in a team and make someone else’s work better, you’re collaborating.
Good news is that our industry is evolving and moving from a fully technological approach to a more humanistic approach, including new disciplines.
Self-organization is built in Agile, it’s explicitly cited into agile principles. Self-organization is essential; otherwise you go back to Command and Control. Self-organization can only be enabled, not enforced. What kind of self-organization? Aligned with business needs.
Systemic organization charts can be Institutional, Interactional or Influential: so an organization is a system with articulate relationships.
A few dysfunctional stories from the field:
- Building Fences
- Divisive talk (i.e. reporting gossips)
- Taking side against
- Withholding information
- Being pleased by other’s failures (even your competitor’s)
- Pointing our other’s mistakes
- Blaming –> Blocks energy
- Judgment –> Carried on with superiority and an emotional quality in it
- I know what you have to do
- Transactional analysis Parent-Child approach (for Manager-Employee) instead of Adult-Adult approach
- Paddling against the river (i.e. technicians who take business decisions)