You are currently browsing the category archive for the ‘Coaching’ category.
IT people is often scared when I say that I don’t like the traditional testing phase in IT projects.
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
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
Courtesy of gluemoon, Some Rights Reserved
I remember when I did the keynote at XP2007 and someone told me: “amazing how fast you go in your company, I’m happy my users are not asking me to go that fast” I remember I said “they don’t ask because they don’t know you can go that fast“.
I always think of that moment when I see teams with slow process, full of unnecessary steps that are usually in place for at least 3 reasons:
- historical reasons (= no one knows why AND no one asks why they are doing that way)
- “because dept. XYZ/important person ABC once told us to do that way” (= no one knows why AND no one asks why they are doing that way)
- for the illusion of control
When this happens, I suggest people to try something that I’ve learnt during my hypnosis training: time is not absolute. Time is not absolute in the sense that even if it were absolute, we just perceive it (as we do with reality in general). As we perceive it, we transform it through our senses. And as we transform it, it happens time can go faster or slower depending on … us.
As an example when you are on the dentist’s chair time is soooooooo slow while when you are on holidays … it’s unfortunately too fast :).
Now what if we apply this concept to your company, team, business, task, process? Take your ‘lead time’: the time that is needed to go from the beginning to the end of the activity you want to speed up. Describe it putting everything inside: make a nice flowchart, Gantt chart, process map of what make you comfortable. Make it visual.
Now make the magic and say: what if I knew this stuff here can be done 10 times faster? Rule #1 stop saying “it is not possible” and start looking at all the components of your process as if you knew someone can go 10 times faster.
Our brain can be easily tricked: do you remember when your wife (or yourself) were pregnant? Do you remember how many pregnant girls you started noticing? Same stuff when you decide to buy a new car: it seems everyone in the world has that car all of a sudden.
This is called focus: your brain is so focused on this new important stuff that all of your energies go there and you start noticing stuff that you were not noticing before, your brain start automatically acting in a different way trying to satisfy your new needs.
Use the same trick here: convince yourself you can do it 10 times faster, 10xFaster:
What can you make differently?
Can you cut a step in your process?
Can you simplify?
Can you use different people with different skills to it more quickly?
Are different roles beneficial?
Does it help if you change the way in which people communicate?
Do you have to change software?
Are you really sure you have to do that extra manual step?
Don’t let the context (rules, politics, …) limit your new behavior: you can di it 10 time faster!
Do it. For 30′. In team. Deeply. And then leave … because you know, in the moment you start this process, your brain starts to be focused in that direction and this is the best tool I know to start changing.
PierG
Today I read this tweet from @JerryWeinberg
When managers don’t understand the work, they tend to reward the appearance of work (long hours, piles of paper, …)
This reminds me of the risk of setting (wrong) goals.
- if you are (VERY) lucky, you can just achieve them. No matter how they mach with the overall goals of the company (assuming the goal of the company is clear). No matter how you do it (the more you push on incentives on these goals, the more people will ‘act’ to achieve them .. no matter the consequences);
- when you set the goal, you alter the ‘system’ in an unpredictable way as people start behaving differently: what if the goals of different people start colliding? And this is even more visible when there are incentives related to these goals.
OK you might say that all these ‘unexpected consequences’ are because ‘they’ are not able to set goals properly: well, as my experience says that setting right goals is impossible, I think that MBOs, SLAs, KPIs tend to ruin organizations more than helping them … and give manager great excuses.
[new] What’s even worst with SLAs is that managers tend not to read contracts properly, and who read them (lawyers?) are not the ones who understand the content.
So this is a system that in theory might work but in reality it doesn’t … because we are humans and not predictable machines controlled in closed-loop.
Amen!
PierG
hiding by Lance Neilson, on Flickr – Some Rights Reserved
Procrastination is evil .. almost always. When you think it’s probably the time in which procrastination is ok, double check: you are not that smart, you are probably cheating yourself 😉 (fear?)
And there is an area in which procrastination is even more evil: when you deal with people so procrastination and people management (can be your direct, your son, a friend …).
Procrastinate a negative feedback? You enforce a wrong behavior.
Procrastinate a positive feedback? You have chances that a good behavior is changed in search of a (potentially) bad one.
PierG
Let’s face it, working in an Agile fashion is hard. It requires paying attention to what you’re doing and the results of that. It requires thinking and making choices. It requires honoring the thoughts and feelings of those around you. None of this is easy stuff.
via George Dinwiddie’s blog » Post-Agile?.
What’s your thought?
PierG
The title of this posts is probably meaningless to you (but if you know what it is, just let me know using the comments 🙂 ) but reminds me of a good time.
Yes sometimes good times come, not many usually, but they come.
I think our culture is too focused on learning through mistakes, looking at problems or failures. There is a lot of hype around the fail early paradigm. I’m not against it and I think we must start getting more from our success stories and moments.
So (1) celebrate! Yes Sir, when you do something good, you are successfully do celebrate. It’s not a sin. It’s good for our self, for our self estime, for our colleagues, for our family too. Smile. Be happy!
(2) learn. What went well? What can you do differently? But above all what was the key success factor of this success? Our brain stick to these emotions and you don’t need to be beaten to learn. Forget it. Learn from success!
(3) after a successfully project or task or … use this positive power, this power moment, to study something new. Maximize this learning moment studying something new: add a new arrow to your weapons.
PierG
There are the micromanagers. The ones who believe they can do better than anyone in their team and for this reason they use people in their teams as their arms …. just because they don’t have time enough and so are obliged to ‘use’ other people.
Then there are those who see themselves as managers who delegate. When they have something they cannot do, or don’t want to do or … they throw it to someone in their team. Almost no direction given, just thrown the activity / problem like a ball and above all no reporting / feedback model in place. When something goes wrong they start running and shouting …. and thinking ‘next time I’ll do it myself’.
Then there are those who choose what to delegate to whom, who provide proper context, proper guidance, proper empowerment, who agree in the reporting / feedback model. Those who are in touch with the activities because they are reported with the proper cadence and the proper content.
PierG
A wise friend of mine asked me:
“if a strict control is useful, why don’t we have traffic lights at every single crossroad?”
I smiled and said:
“do you want a coffee?”
What’s your answer? 🙂
PierG
Dealing with change. I believe this will be one of the most essential skills as our kids grow up, as the world is always changing and being able to accept the change, to deal with the change, to navigate the flow of change, will be a competitive advantage
via » 9 Essential Skills Kids Should Learn :zenhabits.
A very tough and very important task for us as fathers … teach to deal with change: any recipe?
PierG
Subscribe
PierG (aka Piergiorgio Grossi) 