edschepis.net

Another Step

edschepis — Sat, 15 Jan 2011 14:35:06 +0000

Yesterday was my last day in Funambol.

Sad to leave great workers, people and friends… but after 4 years it’s time to do another step in my career.
I’m sure Funambol will have a bright future and I wish all the best to all of you dear Funamboli… you’re doing your work so well!

I’ve now the opportunity to join another great company: Red Hat.
I’ll work as a Solution Architect on JBoss Middleware presales area in Italy and that’s simply a great chance for me.

I’m very happy to join another open source big fan company… I’m just realizing I’ve always worked with open source addicted people… nice!

So now a relaxing weekend and then… on the road again!!!

2010 in review

edschepis — Sun, 02 Jan 2011 06:18:01 +0000

Why should I renounce to an interesting automated post from WordPress team about some stats of my website?

Here it is!

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

The Blog-Health-o-Meter™ reads This blog is doing awesome!.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 3,500 times in 2010. That’s about 8 full 747s.

In 2010, there were 21 new posts, not bad for the first year! There were 41 pictures uploaded, taking up a total of 7mb. That’s about 3 pictures per month.

The busiest day of the year was April 15th with 92 views. The most popular post that day was Certified Scrum Professional.

Where did they come from?

The top referring sites in 2010 were edschepis.net, blogs.danube.com, scrum.it, digg.com, and pragmaticagile.wordpress.com.

Some visitors came searching, mostly for rocks in the lake lean, certified scrum professional, forming storming norming performing diagram, scrum master checklist, and forming storming norming performing.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Certified Scrum Professional April 2010
1 comment

Don’t overlook the Scrum Master checklist April 2010

Foster collaboration in forming teams April 2010
1 comment

The Lean metaphor of the rocks in the lake May 2010

OpenX Ad Server Beginner’s Guide April 2010
1 comment

DroidResume… what’s that?

edschepis — Fri, 10 Sep 2010 16:54:01 +0000

What about having your Curriculum Vitae, your blog, your tweets, your Linkedin profile and your public slides in the Android Market… all in one app?

What about allowing android users to share your CV in pdf format via email?

And what about having an easy way to build your own?

That’s DroidResume.com!

Go to http://www.droidresume.com for all the details.

You can see an example (my resume actually) in the Android Market searching for DroidResume or using the following qrcode.

My Android Application: ViewTrafic

edschepis — Thu, 29 Jul 2010 21:58:47 +0000

Yes I did it again.

I’m back again on the programmer side of the moon… and I feel good!

The last time was for a cool client for push email written in JavaME.
Now it’s Android time!

This is my first application and I started to write it for myself:
“Wouldn’t it be cool if I could watch the traffic live on the main italian highways from my Android device?”

After spending some hours in the evenings (it’s so easy and nice to program with the Android API)… here it is: ViewTrafic.

Search the Android Market for ViewTrafic or, if you have a QR code reader on your droid, just point it here:

The live images and the maps come from the website of Quattroruote (Infotrafic section), so please be patient if there are few cameras: it’s not my choice.

Some stats: 570 Android users downloaded it until now and counting… and in 10 days I’ve seen a good progress in advertising clicks as you can see here from AdMob website:

Enjoy my application and feel free to provide your feedback… it’s free… with some ads to click

Noise in communications

edschepis — Tue, 06 Jul 2010 13:18:09 +0000

The noise in communications grows when the stress in people communicating grows.

Since the stress grows approaching the deadlines and the presence of noise in communications decrease the ability to understand, then we can say that:
close to the deadlines it’s very hard to understand and solve issues.

Trying to represent it in a chart, here is what I’ve done:

Funny, isn’t it?
In the exact moment (close to the deadlines) when we are required to take important decisions we are unable to understand what is right and what is wrong and what is the best path to take.
That is the reality, we can only do it better, improve, but avoiding it is really hard.

From the presentation Communicating in high stress situations found on Slideshare by Rusty Cawley:

Low Stress:

People can process an average of 7 messages

They recall information in linear order (1,2,3 …)

They process messages at an eighth-grade level

Trust is built on competence and experience

High Stress:

People can process an average of 3 messages

They recall what they perceive as most important or what is said last

They process messages at a fourth-grade level

Trust is built on listening, empathy, caring and compassion

We have only one solution to fight the stress and the noise in communications: be prepared to the change and have a good plan B.

All the activities, the processes and the steps to execute must be clear to everybody (must be almost obvious), so that people can focus only on the required change or issues.
People shouldn’t ask “Who is in charge of this?”, “What is the procedure for that?”, “Who should I talk about this issue?”… all these questions must have a prepared answer. People shouldn’t spend more than 5 minutes for such kind of questions.
Think about riding a bicycle: you should be focused on riding your bike and responding to any change needed for a hole in the street or in the tyre, not on how to pedal.

Does it mean people should have a well defined and detailed plan? No, not exactly… people should know (from the experience, from some patterns… from the past) how to respond to change… specially approaching the deadlines. Learn from the past instead of creating a useless detailed plan.

That’s what people must do: be prepared. Nothing more.

Just an additional note, very small: don’t panic!!!

Story Points: a relative measure

edschepis — Tue, 29 Jun 2010 08:13:56 +0000

Are you still trying to get the meaning of Story Points? Still trying to explain them to Management?
No better example than this coming from the latest post in Mike Cohn’s Blog:

My favorite example is of two runners at the start of a trail–one says it will take 5 minutes to run, the other says 10 minutes. Both are right. Those are the amounts of time it will take each to run. There is no time-based argument they can have to settle on the “right number.” However, both can agree that some other trail is twice as long—one runner will be thinking “Yep, 20 minutes” and the other will be thinking “Yep, 10 minutes.” But both can agree “twice as long.”

And of course a good reading like this is always welcome

Don’t miss the Essence of Agile

edschepis — Fri, 11 Jun 2010 06:58:51 +0000

Basically a whole week’s course compressed into a one hour lecture

Take a look at this presentation from Enrik Kniberg and enjoy the Essence of Agile (from Agile Spain 2010).

I really like some slides like “Agile projects are like a guided missile”, “Compare for understanding, not judgement”, “Don’t be dogmatic!” and “Perfection is a direction, not a place” (my favorite one).

Are you a chamomile or a coffee programmer?

edschepis — Mon, 24 May 2010 16:12:26 +0000

You’re in front of your favorite 24” monitor or your nicer 10” netbook, programming (code & test, code & test,…), writing your code and unit testing… do you get the same feeling I have (actually I had)? I mean: ”Just a few lines of code and I’m done. I can see this thing working and move to the next thing… almost there, almost done…”

The adrenaline is kicking in and you’re programming very fast to see something happening, something like: it compiles, green bar on unit testing, click the button, I see the results, done!

You stay there on that chair until you see that thing working and then… next one… and start again.

Well I’ve realized that this is the coffee programming: intensive, fast and furious I’d say. You just want to see your stuff working and don’t want any distraction… no pauses, no interrupts… just coffee!

But what I’ve seen during my programming days was that actually I needed a different approach: the chamomile programming.
“What’s that? Do you really mean drinking chamomile during programming? Are you crazy?”

Just a second and I explain my point of view.

Chamomile programming is the only way I’ve found to rest a little bit from the intensive pace of writing code and testing.
It’s the way I like to write code: calm, with a sustainable pace, taking time to understand the pros and cons of that technical choice, design or architecture, looking my code from a different perspective and sometime going back and re-write it.

It’s the approach that worked many times for me to find the right tradeoff between creating nice code and releasing the product to my customers.

I need time to rest and look back, I need time to understand what I’m doing and drinking a good cup of chamomile (light tea, tisana or light cold tea in the summer) is a nice way to do it.
Drinking coffee (I’m italian so you may know how much caffeine it means… 5-6 expressos in a day are really counterproductive) is not my way: working too fast is not my way.

It’s all connected to the application of refactoring: code & test all the time means refactoring all the time… there’s no other way to coding in my opinion. But to refactor your code you need time and clear vision: coffee didn’t help me, chamomile yes.

And you? Are you a chamomile or a coffee programmer?

The Lean metaphor of the rocks in the lake

edschepis — Fri, 14 May 2010 09:31:49 +0000

Adopting methods like Agile, Scrum and Lean brings many well known advantages in software development life-cycle.
But what I’d like to cover here is a more subtle advantage that you start realizing after some months you are applying them.

It’s related to the size. Yes the size.
The size of almost everything you do: artifacts, processes, methods, teams, iterations, releases and so on.

The principle behind it is the Lean principle called “the rocks in the lake“:

The depth of the water may represent the size: when the water is high many rocks are hidden and these rocks represent weaknesses.
If we are able to keep the depth of the water low then we can see the rocks: the weaknesses are visible and we can start approaching and fixing them in the most appropriate way.

Let’s see the water and the hidden rocks one by one trying to identify how to keep the water low…. comments are welcome as usual.

Water	Rocks	How to lower the water
TEAM	Big team hides: Guru effect Sub-teams working separately Poor team-working: boundaries between members and silent members following the others Work redundancy and duplication due to the poor communication within the team	Keep the team small: max 5 members with a good mix of skills
ITERATION	Long Iteration (or no iterations) hide: Issues with integration and release process Bugs proliferation (bad surprises close to the release time) No clear commitments and accountability Refuse to change (you can respond to change only after months)	Keep the iteration short: max 2 weeks with clear goal and a clear definition of DONE for the user stories Continuous integration
RELEASE	Long release hides: Issues with integration and release process No vision for the release: it’s hard to identify clear priorities	Keep the release short: max 4 months with clear goal and appropriate release planning Continuous integration
USER STORY	Big user story hides: lack of integration: software is not integrated for weeks lack of unit and integration testing strategy poor confidence on work done in short period (2-3 days) fear of commitments lack of clear understanding of requirements	Split big user stories in smaller user stories: small here means with lower complexity and therefore with lower size. Then each user story can be split in technical tasks short enough to guarantee confidence for commitments to the team Continuous integration
MEETING	Long meeting hides: Team doesn’t like responsibility People not able to communicate and take decisions	Keep meetings short (max 2 hours) Choose a chairman that keeps the focus on the main topic, avoiding diverging Prepare the agenda and close the meeting with a list of clear action items
BACKLOG	Big backlog (also without priorities) hides: Wishful thinking No clear vision on release	Focus on few user stories that are candidates for the release: the rest can wait Prioritize them
WIP	Items in progress like tasks or user stories for long time hides: lack of unit testing fear of integration issues with design (lack of modular architecture, decoupling,…)	Split tasks in smaller ones The whole team should work on one user story at time (if possible) Continuous integration
INTEGRATION CYCLE	Long cycles of integration hide: lack of unit and integration testing strategy issues with design (lack of modular architecture, decoupling,…)	Somebody says that the code should be left out of the repository no more than 15 minutes… Continuous integration

Nice quick reference for Lean is Lean Primer by Craig Larman and Bas Vodde.

My talk at BetterSoftware Italia 2010

edschepis — Mon, 10 May 2010 21:49:54 +0000

BetterSoftware Italia 2010 has been a really nice conference: interesting talks, nice people (and tweeters), and nice location… Firenze is always Firenze.

I didn’t attend many talks, but Francesco Cirillo, Fabio Armani and Giuseppe Paternò have been great talks and are my selections for this year.
I’ve been happy also to know about the information radiator open source project called doomboard from Giovanni Intini… funny and useful project!

The room for my talk was really packed (yes!) and we had a really great Q&A session. That is the way I evaluate my talks: many questions = good talk.

Thanks to everybody for your kindness and participation!!!

I hope to be there also next year talking of one of my favorite topics around the Agile theme.

Here are my slides: