A manager has to know when to ignore a precise number. “He has to know that ‘larger’ and ‘smaller,’ ‘earlier’ and ‘later,’ ‘up’ and ‘down’ are quantitative terms and often more accurate, indeed more rigorous, than any specific figures or range of figures.”

via Fat Chance | The Drucker Exchange | Daily Blog by The Drucker Institute.

PierG

I understand, it’s so relaxing to know that you have a bunch of people to blame when projects go the wrong way: “we did 3 month of testing, we really couldn’t do more to save this project!”.

And if it’s not the testing team, you can always blame the requirements team for gathering them badly. But this is another story, another post . Let’s get back to testing.

What I generally don’t like about testing is that you do some operations based on … what the system is designed to do. Someone writes a requirement, someone (else) writes one or more test cases to prove it, someone (else) writes some code and finally someone (else) reads the test case and uses the system giving his interpretation of the behavior … giving a GO/NO GO.

Should I explain why I feel uncomfortable? I hope not but let me add an unobvious thing: where is reality in this long chain? Who’s in charge of saying if the system is doing what is needed and not what someone (else) thinks it should be doing?

Scary, isn’t it?

PierG

In life or death situations, the military needs to make sure that they can shout orders and soldiers will obey them even if the orders are suicidal. That means soldiers need to be programmed to be obedient in a way which is not really all that important for, say, a software company.

In other words, the military uses Command and Control because it’s the only way to get 18 year olds to charge through a minefield, not because they think it’s the best management method for every situation.

In particular, in software development teams where good developers can work anywhere they want, playing soldier is going to get pretty tedious and you’re not really going to keep anyone on your team.

via The Command and Control Management Method – Joel on Software.

PierG

Sorry in Italian

PierG

Nice and unique, as fas as I’ve seen in the apps I have.

Well done Google

PierG

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

Now what’s happening lately is that my 8-yrs-old digital-native heavy-iPad-user computer-enthusiast son started saying:

“OK Dad tonight we have our reading evening and you cannot read with the iPad, you have to use a paper book”

So I asked:

“why????”

And he said …. ok I don’t want to tell you the answer immediately .

You guess: why he doesn’t want me to read with the iPad?

PierG

At the beginning, it was all about technology:

IT was too far from human beings

and IT was available only in big corporations. The IT Manager was the guy with the white coat: an expert of her matter. An IT guy.

Than IT became more commodity and it was the time of business:

IT was too far from the business

and IT decided it was time to talk the language of the business. So the IT dept moved under the CFO or the COO, and the IT Manager became a ‘business man’. Technical skills were no more important for her: there was the outsourcing and the SLAs to cope with the ‘technical stuff’.

Then the internet came, and Google, and Facebook, and Twitter … and all of the sudden

IT, inside corporations, is too far from real life

and people inside the company use to have such a bad IT experience that he would never accept at home … even for free.

To manage all of this we need a new race of IT Managers: they must have deep understanding of both parties. They must know a lot about IT and a lot about making business. But today it’s no more enough. Nowadays IT tech skills and management skills can be an obstacle, sooner or later, if they are not enriched with good design skills.

In the innovation and design era, to move IT at the right speed (maybe 10xFaster) and at the right level of innovation, IT +  management + design have to be carefully used, melted, weighed out.

PierG

p.s. Thanks to my friend Nico Bigi for the inspiration of this post

Back in 2001, traditional management had the idea that if everything was documented, things would work out fine.

via Innovation: Applying “Inspect & Adapt” To The Agile Manifesto – Forbes.

Three reasons to read this article:

1. because in 2012 90% of management DO have the idea that full documentation means “it will work fine“
2. because it’s an interesting article about agility and beyond (adding some lean startup concepts too)
3. because most of the stuff that you read comes from Kent Beck and you should read everything from Kent. PERIOD.

Tell us what you think

PierG

Very interesting talk by Prof. Elena Malaguti during TEDxReggioEmilia .. in Italian

“A lezione di resilienza: Come recuperare dopo un trauma”

PierG