WDD: a new development paradigm

We will talk about a new development technique called WDD or Worries Driven Development.
You might know another couple of *DD techniques: TDD and DDD but they are by far less powerful than WDD.

TDD or Test Driven Development has been invented by Ken Beck (@kentbeck). As Wikipedia states “is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards”.

DDD or Domain Drive Design is a little more recent, especially it’s hype, and as Wikipedia says “is an approach to develop software for complex needs by connecting the implementation to an evolving model.The premise of domain-driven design is the following: Placing the project’s primary focus on the core domain and domain logic; Basing complex designs on a model of the domain; Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.” In Italy Alberto Barndolini (@ziobrando) is really good at it!

WDD is more powerful because it works at a deeper level. It acts at the level of motivations. We tend to do what we do for one of two reasons: to seek pleasure or to avoid pain.
Now our culture tend to push us to the ‘avoid pain’ side so we tend to use it more often as a motivation to do what we do. So what’s more relieving than solving a problem to ‘avoid pain’?
That’s where WDD come from: we do what worries us. Or better we do, schedule, put in priority what can have consequences that can worry us.
So the algorithm is: if you don’t have it, create a problem, throw it in the future, communicate it so that everybody can be worried. Now you are ready to make a lot of overtime to solve it to ‘avoid pain’.

The secret? WDD is not that new: it is quite often used as a primary development paradigm in many offices of medium-big corporations. And it works …. maybe.

PierG

Italian Agile Day 2012 #IAD12

The Italian Agile Day 2012 will take place in Milan on November, 24th at the University of Milan.

The program is ready: full of interesting lighting talks (10′), std talks (45′) and workshops (90′).

Do you want to meet me? See you there 🙂 … and don’t forget to tweet with the official hash-tag #IAD12

PierG

To prototype or not to prototype?

“create a low-fi prototype at the first responsible moment, create the hi-fi product at the last responsible moment” @aslamkhn

via Twitter / @KentBeck: “create a low-fi prototype ….

PierG

Self-organizing, self-organized or self-managed?

Time to rectify some misconceptions.

# 1. Self-organizing teams are completely autonomous, self-managing, and don’t need managers.

# 2. All you need to do to form a self-organizing team is provide a goal and apply pressure.

# 3. Since the team is self-organizing, they can accommodate moving people on and off the team easily.

[…]

Self-organizing teams are not teams gone mad. Like all teams, they need a compelling goal, skills, information, and enough time to form and perform. And they still need managers to create a supportive context, set appropriate boundaries and constraints and connect the team to the organization.

via Insights You Can Use » Blog Archive » Misconceptions about Self-Organizing Teams. Read it for detailed description of these points.

PierG

… or you can diverge

What got my attention in Don’t Plan Speculate by Jim Highsmith is this picture

and especially the “or can diverge” arrows that are everywhere.

This reminds  me that no matter which methodology you use, the chance that your project / ecosystem / team keeps diverging is present throughout the lifecycle.

Some methods are more command-and-control and give you the illusion of non-divergence. Some methods are more based on the emergency of an “order” and go more along the flow … but the facts say that:

• nature always finds a way (quote): that means that you cannot control reality. Period.
• If you want to cope with ‘the best’ you need to put (or remove) energy and this means applying a lot of effort … always.

PierG

Embracing Change

Traditional teams attempt to drive out uncertainty by planning and analysis. Agile teams tend to drive out uncertainty by developing working software in small increments and then adjusting. […] Dealing positively with uncertainty, being willing to accept that certain things are unknown and unknowable (for now), is a big part of learning to be an agile manager.

via Embracing Change | Jim Highsmith.

PierG

The Spiral of Distrust

Agile development addresses this problem [the spiral of distrust] by iterative delivery of system functionality to meet requirements that people know they need today.

via Agile Builds Trust with Fast Feedback | CIO – Blogs and Discussion.

I think this (iteratively meeting user’s expectation) is one of the best options that we have to gain trust, deliver real value, have great products and have fun but …  I don’t think it’s enough. I see for example two effects coming when the loop gets going:

1. the customer buys in: he is so fascinated by this “new” model that he jumps on board and stop challenging the team toward a better performance
2. the customer gets used and start kicking because it wants even more … and this lead to less quality (= distrust) or get pushed back.

I don’t necessarily have a solution, if you have one please feel free to share in the comments 🙂

PierG

Is quality tradable?

Here is what Martin Fowler writes in his post TradableQualityHypothesis:

I follow Kent Beck in making a distinction between internal and external quality. The pleasantness and effectiveness of a user-interface is external quality as it’s something that can be perceived by the users of a system. That is something that can be sensibly involved in a trade off – do I want extra work on making feature A easier to use or should I add feature B?

The internal structure of the software, however, is not something that’s directly perceivable by the user. I can’t tell from using a program whether its internals are constructed well or not. Internal quality is thus a more hidden attribute. When someone says we should do things reduce the design quality of a system to build more features, that person is applying the tradable quality hypothesis to internal quality.

Hidden in this reasoning there is the equation that lowering quality you can go faster: as Martin says this  is true only in a really really short time frame but this is not the worst effect:

But the tragedy is that as soon as you frame internal quality as tradable, you’ve lost. […] Instead it’s vital to focus on the true value of internal quality – that it’s the enabler to speed. The purpose of internal quality is to go faster.

What’s your experience on this topic? How’s the “quality tradable hypothesis” is seen in your team? Under which circumstances high quality means going faster?

PierG

Fixed Scope is a Win-Lose

Fixing scope up front says ‘win-lose’ to me. It’s not the basis for a happy relationship.

Read more on  We’re better off finding out than farting around up front in Energized Work blog.

PierG

Dennis Stevens – What’s Next for the Agile Manifesto

We, the undersigned, believe the Agile community must:
..Demand Technical Excellence
..Promote Individual Change and Lead Organizational Change
..Organize Knowledge and Promote Education
..Maximize Value Creation Across the Entire Process

Read the review of the gathering for the 10th anniversary of the Agile Manifesto by Dennis Stevens » What’s Next for the Agile Manifesto.

PierG