GWT@Jazoon '08 - Available at SlideShare

Last June I gave a presentation at the Java conference Jazoon '08 in Zurich. The intention was to put the slides online available ... put it seems I kinda forgot about that one :-)

But nevertheless I found some time this morning to create an account at SlideShare and I uploaded the presentation. For convenience reasons I divided the presentation up into several parts, you can find them here:

0. Intro
1. First Impressions Count
2. Attentive Service
3. Personalization and Customization
4. Attention to Detail
5. Feedback
6. The Perfect Experience

I also created a group called Google Web Toolkit Alliance which you can join and put up your own GWT related slides!

GWT Sample | Inline Preserialized Payload

I just created a Google Code repository which I'll use to host some cool GWT or Java code samples.

The first GWT sample is about something I talked about at Jazoon '08: Inline Preserialized Payloads.

You can find the sample here.

I haven't had time yet to update the wiki, I'll do that asap!

Basically this is the scenario:

• DemoVelicityServlet intercepts the page call
• output from DemoServiceImpl will be preserialized ( = System.getProperty("os.name"))
• Payload is placed on the velocity context and rendered
• The client will retrieve payload and show it

Scrum 2.0 | Yes we can!

Would it be possible to upgrade Scrum to Scrum 2.0? What would that mean? Would it be possible to mix traditional Scrum with social networking flavors?

Scrum is partly about improving communication between all team members. Social networking is all about connecting people and improving communication between them. Both try to improve communication ... so let's try!

Let us pick a single team conversation and see how we can enhance it with some social networking tools.

Scenario 1: Daily standup meetings

Let's not go that far... the whole point why this works is because we have face-to-face contact. I would be kinda strange to replace this with everyone sitting behind his desk (micro) blogging about what they did. Let's try something else.

Scenario 2: Inter-team communication during the day

Let's imagine for a second you have a team practicing extreme programming. This team is obliged to maximize communication during the day. Some of the communication that can go on is:

• Check out this article about TDD
• We need to bring down the build server for a second, memory upgrade
• Added feature X to the base test class
• Get me some coffee ... NOW
• Mails from the CI server (broken/fixed)
• and so on ...

In the examples above we can have several ways of communicating this data, we can:

• shout it
• send an email
• put it on wiki (+ rss feed)
• send it using instant messaging
• and so on ...

You can shout it through the room and that works if you do it like once a day or you have a very small group. The usage of email is still #1, perhaps some filters can drop the number of unread messages. The wiki is fine for bigger stuff, if for every little thing you want to say you need to open the wiki, add a page (or open one), add the text, and save it ... fwiejjww. Instant messaging also sucks, some tools have grouping functionality but it keeps on blinking on my desktop, hate it. I think if I needed to summarize the problems we all of the techniques above is that they make too much noise, don't push information upon people but let them people only what they think is necessary (aka Lean). Scrum doesn't provide any insight in this so so much for that...

So I guess the second scenario can be a good one for further analysis. We know that team communication is crucial, knowledge sharing is even more crucial, but making too much noise will kill all of the benefits of trying to share. A business case for a technical tool? I guess we are kinda stuck with person to person solutions here, we could try to whisper but even then ... :-)

We need a tool that allows us to share information (crucial or not) between team members, small messages, things that pop up, things that have no need to be archived until the sun explodes messages like 'I'm feeling sick today ... give me a break'. We need to be able to send them with no ease, everyone who might be interested in what I or the team has to say can listen upon those messages but you can't force people to read everything. This latter one is very important, we want to know what is going on with everyone but we don't like the information to be forced upon us. Email has this problem, you send it, I have to read it but first I need to open the message, if I don't want to read it I still have to delete it otherwise my inbox keeps growing... It is up to the reader to decide whether or not to read the message if he doesn't want to the message should just 'disappear' (don't even have to delete them), he should be able to give feedback at no ease, look at feedback of others and so on....

What we have here is a business case for what is called Micro Blogging.

Let's look at Twitter. You either love it or hate it, but you can't get around its popularity. Twitter is all about micro blogging, a technique similar to sending sms messages. The main difference is that your audience is much, much much much bigger and secondly and not unimportant is that reading a Twitter message it is much less intrusive than having to open each sms message individually. Each sms you receive you need to open individually whereas Twitter messages are pushed to you as a continuous stream where you decide whether or not to read a message. So sms / email = push + click and Twitter = push and forget.

The biggest disadvantage currently is that you can't used it behind the company firewall. Yammer is a tool which allows you to overcome that obstacle, it lets you create a Twitter like stream behind the firewall and is only available for those have been registered and allowed to use it.

So what would happen if the team would embrace something like Yammer and use it instead of shouting, sending emails...?

First of all it would take out all the noise out of the team, don't feel obliged to use it for everything because it is still very important to keep up a good atmosphere within the team, so talk... but don't make noise!

Second, Let's say you found a great article about TDD, just put it on the stream and whoever feels like reading it will, those who are too busy will just ignore the message.

Third, no more spam in your mailbox! No more messages to delete, nothing to open just to make sure it isn't interesting...

Fourth, most of these tools even have API's which means that with some effort you could easily redirect your CI server information (build broken / fixed, what has been updated and so on) and stream it directly into for example Yammer. If someone is interested to see what is going on with the build he can, if not just skip it; it will only take a blink of an eye to do so.

I can go on but you get the picture I hope? By introducing a stream like micro blogging tool we reduce a lot of team noise and we optimize communication. We just eliminated a lot of waste ;-)

Yammer is really great, no matter where you are you can always check the team stream because they have ported the application also to a desktop, mobile and iPhone application.

Scrum 2.0, yes we can!

Scrum | Detecting waste

Waste elimination is key to Lean. Nevertheless is the approach to detecting it completely different from traditional cost cutting techniques. The latter one detects waste by appointing certain persons or committees, who's job it is - yes you guessed it right - to detect waste.

An approach which will not uncover the true problems of an organization...

Lean is all about creating an environment that makes it easy to notice problems. If people are on the alert to detect problems, and the environment is created that makes it easy to notice problems, the supply of creative idea "seeds" will not run out.

Our job as Scrum Master or Lean Leaders is to help create that environment and inspire everyone to act, to take action, to make improvements.

Scrum already provides one key ingredient to continuous improvement by stating that at the end of every Sprint a retrospective should occur. Two things are important in the previous sentence. The first one is that there is a meeting, an environment, created where all team members can look back at what happened, what went well or would could have went better and last but not least that the intention of the meeting is to create action points to improve upon all things that could have went better, dividing them between things that can be solved by the team and those that fall under the jurisdiction of the company. Secondly you should notice that it clearly states that the meeting should be held after each Sprint, the fact that this is a rule, a standard will help in the process of detecting problems. The team will exactly know when to address their issues. Short iterations will only help in quickly exposing impediments.

One of the Lean principles I try to apply on projects is Kanban, the art of visualizing everything that is going one. A Scrum implementation of this is the Scrumboard and the burndown chart. But don't stop there:

• get that full project burndown also up there


• keep the result of each previous retrospective on the wall especially when it contains impediments that need to be solved by the team or organization


• Don't waste too much time on making detailed UML driven technical design, grab a big paper, make some design sketches and put them up there


• technical issues which don't belong on the product backlog can be kept as a separate Technical Backlog on the wall by adding each technical issue as a post-it on it


• your application consists of a web front end than take a print of the screens hang them visible for everyone so that they can be discussed at any time, also having them around will make you get used to the screens and will help in detecting inconsistencies or improvements

I can go on for a while but you kinda get the picture. Get it up there, visualize it, so that everyone can start talking about it...

Lean | Quote of the day

"If you see a snake, just kill it - don't appoint a committee on snakes."
-- Henry Ross Perot

Scrum | The final battle

In ancient times, Priests, men through which God spoke, had the duty to translate the Word of God into Holy Scriptures and to spread the Word among the people.

These Knights of God who were intended to lead us through Dark times caused disasters all over the world, non-believers got hanged or burned, opinions that didn't stroke with the Word of God were said to have come out of the mouth of the Devil himself.

A world denied of creative thinking, change...
A world lead by the Holy Word of the Book of God...

Although the power of these ancient Priests seems to be disappearing in our modern society; the force is still strong; many followers that survived have been working on a smaller scale, indoctrinating the world from the inside out, infecting companies with their Scriptures and fortune telling...

We call them ANALYSTS...

Those who write the book of the World...
Those who shape, who decide upon our future...
Those who tell the future and never look back...

But things are about to change...

Meet The Scrumpies


You understand I can't reveal their true indentity

Scrumpy dislikes fortune tellers...
Scrumpy dislikes big Holy books...
Scrumpy believes in wisdom of the crowds...
Scrumpy loves and respects everyone...
Scrumpy gets grumpy from analysts...

Scrumpy is from the Order of the Scrum Masters...
Scrumpy his job is to disinfect companies from fortune tellers...
Scrumpy his job is to protect his team; defend them at all cause...

Scrumpy has a secret weapon called user stories

A tree liner that will make analysts INSANE
Scrumpy will fight Analysts on their own field...

The war has already started...

Happy birthday to me

It's impolite to ask so I'll just tell you: 29 years old.

I'm almost hitting the big 3 so perhaps it is time to do a retrospective on my own life. What happened? What went well? What went wrong? I'm actually curious about the outcome.

I'll keep you posted!

Lean | Keeping idle workers busy at Toyota

Lean states that your management decisions should be based on a long term philosophy, even at the expense of short term financial goals.

But how does Toyota, mother of Lean principles, apply these rules in financial uncertain times? Times where car manufacturing is dropping all over the world and workers need to be laid off.

The Wall Street Journal wrote an article on how workers are kept at the plant, not send home or fired when there isn't any work for them for a while. The employees spend their days in training sessions designed to sharpen their job skills and find better ways to assemble vehicles.

Some article abstracts...

Toyota is using the down time to hone its workers??? quality-control and productivity skills. The company has pledged never to lay off any of its full-time employees, who are nonunion...

Jim Lentz, president of Toyota Motor Sales, the company???s U.S. sales unit, said the company believes keeping employees on the payroll and using the time to improve their capabilities is the best move in the long run. ???It would have been crazy for us to lose people for 90 days and [then] to rehire and retrain people and hope that we have a smooth ramp-up coming back in,??? Mr. Lentz said...

In Princeton, senior plant manager Norm Bafunno said he can already see the benefits of the training. Mr. Bafunno cites a Teflon ring designed by an assembly worker during the down time that helps prevent paint damage when employees install an electrical switch on the edge of a vehicle???s door...

Mr. Mason, a 40-year-old former firefighter, added: ???One of the major things that everyone is grateful for is that they thought enough of us to keep us here"...

Toyota continues to show intelligence, long term thinking and respect for people in their management decisions.

No words ...

What if it was your son or daughter?



It makes you think doesn't it....

View this video on TED.com

Life as it should be

A Chinese zoo has given an orphan monkey its own guard dog to stop it being bullied by bigger primates.



Keepers at Jiaozuo City Zoo said the monkey was always being bullied and they had intervened to save his life several times.

The zoo said the dog, Sai Hu, does his job very well.

"Whenever the baby monkey gets bullied, he dashes up and drives the others away. And the baby monkey is also very smart. Each time he smells danger he runs to jump on the dog's back and holds on tight."

"The alpha male monkey has been really unhappy since we sent in Sai Hu. He tried to organise several ambushes on the little monkey, but they all failed because of the dog," added the spokesman."

Original source: De Morgen

Lean | Quote of the day

"The most dangerous kind of waste is the waste we do not recognize."
-- Shigeo Shingo

Lean | Quote of the day

GO SLOW TO GO FAST

"Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly"
-- Toyota Production System

Scrum | Anno 1945

I came across a quote from General George Patton who lead the U.S. Army General in World War II in campaigns in North Africa, Sicily, France, and Germany. It goes as follows:

A good plan executed today is better than a perfect plan executed at some indefinite point in the future.

I can only guess that he would have loved Scrum ;-)

Agile | Processes and tools aren't evil

The Agile Manifesto clearly states Individuals and interactions over processes and tools, better known as People over processes.

Many people I talk to interpret this definition as follows: Remove all processes and tools and base everything upon excellent communication and interaction between all parties. Processes and tools equals clutter, waste, too much noise...

Is that was is meant by 'People over processes'?

Not really, the word OVER is very important in the above definition and often misinterpreted. It means that communication and interaction are prefered OVER processes and tools. It doesn't state they should be used INSTEAD OF. There is a clear difference between both.

Let me explain...

In a healthy organization both are important and they shouldn't be treated as opposites. The process should be there to serve the people and if they become to bloated they should be fixed so that the roles do not turn around. If you look at methodologies like Scrum, Lean or XP they clearly state you should have processes, having processes is part of a good methodology and you have to grow them within your organization, constantly monitor and improve. A process you have today will probably be unproductive within the year, things change within the organization, so should your processes. But process optimization only works when people communicate and interact often.

You can talk about riding a bike from A to B but at the end you'll still need the physical bike to get there. The bike serves the person, the person doesn't serve the bike.

A while ago I found an article where someone rephrased the definition as Humans over robots.

Humans over robots, that says it all doesn't it, the message is so much clearer. Humans and robots can and should work together, but the robots are there to serve the needs of the human.

Crush ... kill ... destroy

Scrum | Story changes during Sprint

At the beginning of each Sprint the team commits to a number of Backlog stories which end up being the Sprint Backlog. Once the Sprint starts these stories aren't allowed to change, they are fixed, frozen until the end of the Sprint.

A frozen Sprint Backlog allows the team to focus on delivery instead of having to deal with change. Every change whether it is small or big is by default denied and placed on the Backlog so it can be prioritized and dealt with later. So what is delivered at the end of a Sprint isn't always according to the latests specifications. Short iterations cause these changing specifications to be implemented much sooner than later.

Or at least that is the theory...

In practice it can be up to the team to decide whether or not they can handle the change within the current Sprint iteration, just call it common sense. Some changes are small enough not to impact the Sprint iteration.

But what if business comes to you with big changes, very big changes? The team has committed to 6 stories (2 week Sprint). After 4 days business comes to you and tells you that 2 stories have been analyzed completely wrong (90% wrong), one of these stories the team has already started on. Even worse, if they implement it as-is it will have very negative impact on several upcoming tasks. What do you do?

In theory Scrum says all changes should be denied, we could do that. Practice teaches us to evaluate each change upon their impact. We can quickly conclude that the impact of these changes is a nightmare for the current iteration, so we deny the change, right?

Don't forget that denying them will cause a disaster upon upcoming tasks, what will you do? How sure is the business about these changes, or about the impact? The business has been wrong before, right? But this time they have truly done their research and it will make your life a living nightmare if you don't implement the new changes...

What do you do?
What do you do?

I know what I would do...

Scrum | Ban local optimization

Traffic jams, we all know them, we all hate them!
But perhaps there is an important lesson to be learned from them...

While I was sitting in my car, listening to the same old cd, not in the mood for an overdose morning-radio-happiness-whether-you-like-it-or-not, my mind started to drift of and before I knew it a couple of miles passed by without me even realizing it.

How did I get there?
When did I started to accelerate or brake?
Where did the people in front, next to or behind of me go?

I just got there, how I got there, or how others had got there is based upon individual driving decisions. The only rule we have is that at some point it is best to follow the herd. Each driver individually can decide when and how fast he moves from A to B, he does what he think is best, what he does, what he is allowed to do are local optimizations.

Trying to kill the time remaining in traffic I started thinking. Traffic jams are a strange phenomenon, they have been analyzed thoroughly but solving them seems to be tricky! Why is that, are traffic jams that unique from other optimization problems in different industries? Can a simple every day problem like traffic jams inspire us enough to think about related problems in our organizations? Perhaps...

To maximize throughput, all cars need to adhere to a speed limit, preferable the exact same speed. Car drivers are required to optimize only for themselves which causes the system to break down and everyone finds himself caught in a traffic jam.

This problem can be solved by synchronization of all participants. This means all cars need to have the exact same speed and its flow should never be interrupted (continuous flow). A separate acceleration / deacceleration zone allows cars to get up to the exact speed before entering the highway. At no point, not while getting on the highway nor during traffic individual drivers should be allowed to manually manipulate their speed. Comparable with an automated railway system.

Don't compare it with traditional train railway systems, they have even more bottlenecks than the highway system, up to you to detect them...



To conclude, a problem not to be solved overnight! Key to remember is that the root cause is allowing individual drivers to do local optimizations.

SkyTran is a futuristic example of such a fully optimized system.

So we learned that local optimizations are bad. Not really an innovative idea because it has been around for ages in manufacturing methodologies like Lean. Lean has taught us that optimization should take place at the project level, not at the level of the individual people or processes. Local optimization weakens the overall process.

So what about local optimization within an organization?
What about implementing Scrum on a single team within a traditional organization? Aren't those local optimizations?

Many of you who have been using Scrum have probably asked yourselves: 'How does Agile / Scrum scale?'. Can it work even when it is not supported by the the enterprise (team level)? Is it sustainable within a traditional organization?

At least that's a questions that keeps popping up for me!

Scrum equals optimization, local optimization in most cases. The companies that have implemented Scrum or Agile project methodologies fully from top to bottom or a few. Organization adaption is a hot topic during Scrum Master trainings, do we need to do it top-down or bottom-up? My experience has taught me that most companies get familiar with Scrum bottom-up (thanks to all the smart developers) but it gets stuck somewhere in the middle or even at development team level ... equals local optimization. Better would be that the vision comes from above as we have learned from Lean (aka Philosophy level), a clear vision on company wide optimization! One goal envisioned from above!

If you are using Scrum in an otherwise traditional based organizations you'll probably spot some of the typical problems ...

• No support for a Product Owner
• Waiting for resources
• Conflicting resources
• Planning requirements
• Lots of noise
• Strange deadlines
• ...

Typical problems a Scrum team has to deal with because the rest of the organization is not aligned with the Scrum vision, the way of dealing with change. The same reason why if one person in the team does test driven development it will fail, this one person is doing local optimization which are not sustainable on the long term.

I love Scrum / Agile but they only tell you part of the story, it is too fully focused on single projects, it never explains the bigger picture, the real issue, how to optimize the organization. That's why I love Lean, Lean is the bigger picture where methodologies like Agile / Scrum fit in nicely. Lean will teach you about local optimization problems, about the higher organization cause, about Kaizen, about dealing with multiple projects.

Scrum does scale, but only if an organization is prepared to adhere fully to Lean methods!

Don't stop with Scrum, it is great, but don't stop there, learn Lean, because only then you'll see why Scrum can work on organization level. Learn how to create that sustainable organization wide vision, learn how to grow that vision...

Afterwards you'll never questions yourself again whether or not Scrum will work for 1 or 50 projects.

Optimize the organization, not the projects.

Me me me ... it's all about ME !!!

Social networking sites like Facebook and MySpace are gaining popularity beyond believe. I bet that whoever is reading this already has an online profile, perhaps even multiple ones?

But have you ever considered why you have an online profile? Why you put certain pictures online and other ones not? Why you feel the need to have so many friends? ...

I'm completely fed up with people sending me invitations to join their network of friends! I'm fed up with people thinking that I would be interested in every little detail of their life... And just when I thought I had seen it all, welcome Twitter. Twitter? you ask. Twitter is what SMS is to the cell phone, but worse. It is the ultimate information cluttering system! Let's see what information people put on their Twiter stream: Out for lunch - Feeling lazy today - Just got back from swimming - Hate the weather today. I mean really, have we gone mad???

Perhaps the profecy was right, perhaps this is the year when Revelation 13 becomes a fact. Are Facebook, MySpace, Twitter and LinkedIn the 4 horsemen that where predicted to ride during an apocalyptic period with wars, weather changes, earthquakes, plagues, economic disaster, etc. Are they the downfall of mankind...

Perhaps, if only for a second, it is worth examining why we have online profile, why we have the need for so many buddies, the need to follow the life of others or for others to follow our life...

The answer to these questions is twofold.

In life we have leaders and followers. People follow leaders because they represent success and apparent likeability. Someone who has 500 online friends is perceived to be more likeable than someone who has 5.

So who are these perceived online leaders, these Gods of the 21th century?

Now it gets funny, a new study on narcissism and social networking sites has found that sites like Facebook are littered with narcissists; not really cool people who everyone wants to hang out with but narcissists!

Narcissists are people who focus entirely on themselves; they also believe everyone else should focus their attention on them as well! They are attention seekers who rarely develop any long-term relationships or any deep and meaningful relationships.

Narcissists tend to be likeable, friendly and easy to get on with; often they are fun to be with. But it is all a sham - in reality they are only behaving like this in order to get your attention and fuel their addiction for being seen as wonderful.

And followers want to be like the leaders, likeable, having many friends ...
Can we conclude we are all narcissists? But some are better at it than others? When did we stop having a life?

So ask yourself this question: Are you a narcist?
Why do did you put those particular pictures online and not those other ones?
Why do you provide people with information on yourselves?
Why do you provide people with some information and some not?
Why only the things that make you shine; make you likeable?
Why do you link to people you bearly know?
Why ...

Stupid you!
Don't say I haven't warned you!

Dreams...

Sometimes I dream...
I dream that I'm not chained behind my desk
I dream that I'm not a prisoner of bits and bytes
I dream that I have a life
A life where people still talk to each other
A life where passion is being shared
A life filled with emotions and stories
A life where I can teach
What do I love this dream ...

Unpacking my Lumix DMC-FX500

I love digital reflex cameras, don't get me wrong, but they are so big. I mean it is great having them around when you are on holiday, hiking through deserted places, enjoying exceptional scenaries, but on a daily basis for me there is just no place for them.

When I come home from work I pick up my little kid Wolf from the day care and the first thing we do - and he seems to have figured out our little routine because now when I pick him the first thing he says is 'paardje' (dutch for horsy) - is go watch the horsies, he is kinda obsessed with them. But those moments when the horse comes over and Wolf is watching him with those big eyes ... those moments are precious, moments you want to capture without having to carry around a heavy fully blown digital reflex camera.

I could go on listing all the moments where the need for such a camera just isn't convenient but I guess you kinda get the picture. So I bought myself an extra camera, the Panasonic Lumix DMC-FX500.

Some quick specs:

• 10.1-megapixel
• 25mm ultra-wide angle 5x optical zoom
• 3.0-inch LCD Touch screen

You can read the full review at DPReview

As usual I order my stuff from Pixmania (Please let me know if you know cheaper alternatives). Yesterday during lunch (at work) I got a call from the UPS guy telling me he arrived but no one was at home. So I told him he could just put the package at the back of the house, actually I told him to put it in the open shed but when I arrived at home I think he disagreed on that.




Can you see it? Look close it is in there somewhere :-) The UPS guy even made a little roof on top of the package against the rain, gotta love that guy.

Below are some pictures while quickly unwrapping the package and some first shots on how it looks.







See more pictures

Scrum | Stop the blame

Today I want to talk about something that I find particularly common for teams that are adopting Scrum for the first time ... blame.

Let's start by defining blame:

"To blame is to hold another person or group responsible for perceived faults, whether these faults are real, imagined, or merely invented for pejorative purposes. Blame is an act of censure, reproach, and often outright condemnation. Blame is used to place responsibility and accountability for faults onto the blamed person or group."
-- Wikipedia

Key to the definition above is accountability something which you will also find in Scrum, but different. Accountability within Scrum means that not a person is responsible for failure but the team as a whole.

Like any team sport, you win or loose as team. Like they say there is no "I" in team. But reality teaches us that when we loose we feel the need to make someone accountable for the loss. Even worse, blame is basic to hominid behavior. Studies have showed that blame seems to be an essential part of human development. When language skills develop, one of the first practical things which can be done with them is to apply them to blaming others for one's own misdeeds, and getting them sanctioned, or punished, while one simply continues with more of the same.

So don't get all cracked up on the fact that your team start blaming during the daily stand-up or even worse during the retrospective after a 'failed' sprint. We can't help it, it is in our nature ... see, we can even blame the fact that we blame solely on being human :-D

So why is there no place for blame within Scrum? Actually for this we need to look beyond Scrum and look at its daddy called Lean. Key to Lean is waste elimination which is achieved by continuously trying to improve the process, also known as Kaizen.

Kaizen is a daily activity, the purpose of which goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work, and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes.

To be most effective kaizen must operate with three principles in place:

• consider the process and the results (not results-only) so that actions to achieve effects are surfaced


• systemic thinking of the whole process and not just that immediately in view (i.e. big picture, not solely the narrow view) in order to avoid creating problems elsewhere in the process


• and a learning, non-judgmental, non-blaming (because blaming is wasteful) approach and intent will allow the re-examination of the assumptions that resulted in the current process.

Blaming is wasteful, a simple truth but just because blaming is part of our nature so hard to achieve. So don't go expecting team members to stop blaming from day one but guide them into the magic world of getting things done like a team. Guide them towards spotting waste, guide them towards process optimalization and continuous improvement, help them to stop thinking about blame.

I make mistakes, I do things wrong, I don't know the answer to everything, but so don't you! That's life!

An example

During a retrospective a member of the team put up a post-it saying "Commitment?" and said "I think this needs no further explanation".

You kinda get the idea that such statements are not very constructive nor are they identifying waste = the real issue. So what should have happened and what was behind his frustration?

The frustration was actually caused by team members working on tasks in parallel, doing multiple stories at the same time. And by doing so they started blocking each others work, tasks depending on other tasks. And even worse the guy that had put up the "Commitment?" paper in the first place was working on multiple tasks in parallel, blocking a complete story and was not willing to give some of his tasks to someone else and by doing so unblocking the ongoing work.

Everyone in the team got frustrated because they could not proceed, and the one doing the multiple tasks was frustrated the most because he felt he was doing all the work. Causing him to sit behind his desk until late at night.

So during the retrospective he felt frustrated and blamed the team not being committed. Should he have kept quiet? Hard to say, yes and no. Because he was new to Scrum he could not really pinpoint what went wrong so yes I believe he was in his right to do so. But then it is up to the team members to react and explain what really had happened, not that he was blocking everything but that as a team they made bad some bad decisions upon dividing the workload on the task board.

During the daily, the moment everyone was grabbing the tasks he will be working on the team or at least the Scrum master should have reacted and warned about the fact that they were starting on multiple tasks in parallel ... so actually they failed as a team.

In the story above the person should have concluded that failure of the sprint was due to the fact of badly implementing Scrum, doing multiple stories / tasks in parallel and not the fact that there was no team commitment.

It isn't always easy to spot waste, nor process inconsistencies, nor is it to keep your emotions under control! A learning, non-judgmental, non-blaming environment in which we continuously try to improve ourselves isn't something we can achieve in one day, but by practicing Kaizen we take each day a little step towards this goal.

Your slides suck!

Lately I have been looking at some non traditional presentation techniques and I discovered something that will blow your mind away. ZuiPrezi empowers you with nonlinear presentations software, I could explain but the video below will do a better job.



In essence ZuiPrezi is a zooming presentation editor which allows you to create nonlinear experiences. It is still in beta, I haven't tried it so far but it is definitely on my todo list. It seems they support their zooming facility for texts, images, PDFs and drawings.

But if you want the full blown breath taking experience you should give it a try on a tablet pc.

Scrum | What they didn't tell me ...

They told me Scrum was going to be fun ...



They told me that when you do it right you will feel like a God ...


But what they actually meant was this



A bunch of nerds standing each day around a task board

I blame my imagination, I should have known better ...

Look ... I'm up here

A while back I received an AdWords coupon from Google, I didn't gave it a lot of attention and it kinda ended up somewhere beneath a big pile of paper.

But today I stumbled upon that coupon and I thought why not give it a try. The result of a few minutes of play time with the AdWords system can be seen below (just click on it to view it at a readable format).



I have to admit that I was surprised by the extensive list the features they have in there, one could make a living out of AdWords consultancy I guess. The biggest challenge will be in finding the correct keywords. For example in my case I wanted to get up there the moment people are searching for things like 'gwt training' but not when they are just looking for the keyword GWT because with a very limited budget you can't start spamming. Very general keywords are very expensive.

I have also limited my day budget therefore it is possible when typing in keywords like 'GWT course', 'GWT trainer', 'GWT tutorial' and so on you will not see my ad just for the simple reason that my budget has already been spent for that day :-)

I'm actually very curious to see on how many people will click the Ad and what exactly they were looking for. If I come across some cool features within AdWords I'll let you know.

Geek gadgets: Web 2.0 trends map

iA has just released the ultimate Web 2.0 geek gadget. A full blown map that pins down nearly 300 of the most successful and influential websites to the greater Tokyo area train map. Different train lines correspond to different web trends such as innovation, news, social networks, and so on.



Check it out, what is hot and what isn't.

Goodbye my old friend

Everyday the same story, I come home put away my laptop, grab the key for the mailbox, walk outside and there the cat already comes running so happy to see me...

But yesterday ... I went out to empty the mailbox, a black mini-van rushed by, I heard him hitting his brakes and heard a sound I'm already to familiar to ... a loud bang. I knew what time it was, and what it could be, I rushed over to the street and I could just see my cat tumbling over the street. He was very badly hurt, his front legs looked awful, one eye was popped out and is cheek was half teared off. He was making the most awful noises, trying to breath, longs filled with blood, I know I had to end his pain ... I tried but I couldn't, I had loved this cat for too long.

I rushed inside, picked up a box, some sheets and gently placed the cat in the box, when I took him up his body felt broken, a very strange feeling, I struggled to get away, he fought against the pain, fought against death, I knew he struggle was pointless. I jumped into my car drive to the vet who just lives 2 minutes away, I already called her from the car that I was coming, car dumbed along the street, doors left open, rushed inside. She looked at the cat, I saw on her face that it wasn't good, she tried to pop the eye back in but one even that wasn't possible anymore, if she had to put him to sleep he would never wake up again, he was broken too badly ... I had to make a decision ... I had to put him down. For a second I had to decide over life and death ...

I'm sorry my old friend but I had no choice I hope you understand, I couldn't see you suffering ... I can only hope you are at peace now, joined by your biggest friend who already died a year ago ... we'll meet again one day, I'm sure of that.

I'll miss you my friend!

Show you, don't tell you

The last couple of days I have been breaking my head on a better way to explain technology during a live presentation, especially the part where you want to show real code samples.

Perhaps I have found, at least for me, a solution.

So what options do we have:

1. Code snippets divided over multiple slides
2. Manually run through code sample within the IDE
3. Live coding

So let's quickly look at the pro's and con's.

I HATE code snippets, they are always taken out of context and even worse you need to divide hem over multiple slides (especially because event organizers like to see there template wrapped around your slides = lose 1/5 of the page) making you move back and forward between slides. Very hard for newbies too follow.

Running through prepared code samples is another option. Unfortunately you are limited with what you can show with a beamer and still make it readable for everyone. Therefore to make this work you need to increase the font size in your IDE, remove all the clutter and hope you don't forget anything you wanted to show. You are also tied to your desk while showing the code making you not part anymore of the presentation.

Live coding ... hahahahhaaa yeah right!!!

But there is another option I found working for me, replay recorded coding sessions. For this I making use of Camtasia, a really great and easy to use tool to record desktop sessions. Here is how it works.

• Open your IDE
• Start the Camtasia recorder
• Get coding
• Stop recorder

Duhh ...that was easy isn't it, actually there is nothing more to it. Even more, you are probably thinking that I need to edit the movie start zooming in to text I was typing, to the items I was clicking ... WRONGGGG ... Camtasia has an auto focus option which automatically focuses on keystrokes, mouse events,... and by doing so your movie always zooms in / out on what you are doing therefore not cluttering the screen.

Next steps are adding callouts, text, title clips and so on...

But wait I haven't told you the biggest advantage, when you play the recorded session during the conference you are not tied anymore to your desk, once again you're part of the presentation. You are in the the spotlight while you explain what is happening on the screen. The recorded session that is playing at the background is supporting your story and nothing else. Add the correct right callouts and text to the recorded session and you'll have an amazing show.

I''l have a first demo video online the next couple of days, it will probably be one where I'll present how to get GWT configured within Intellij 8 EAP (DIANA).

If you want to know more about Camtasia you should check out the tutorials section.

Simplicity and why it matters

As our daily lives have become more complex, more and more people incorporate simplicity into their lives. But finding simplicity in the workplace seems harder these days, not easier. Professionally people are terrified of being simple for fear of being labeled a lightweight. So "when in doubt, add more" is often the guiding principle.

There is a fundamental misunderstanding of simplicity and what it means to be simple today. Many people confuse simple, for example with simplistic and simplism or that which is dumbed-down to the point of being deceptive or misleading. "Simple" to some people means necessarily a kind of oversimplification of an issue, which ignores complexities and creates obfuscation and outright falsehoods.

Simplicity is one of the key ideas in Zen. Arts like tea ceremony and haiku, which can take many years, or indeed, a lifetime to master. These is nothing easy about them, although when performed by a master, they may seem beautifully simple.

So simple refers to being essentially, synonymous for clarity, directness, subtlety, essentialness and minimalism. Something that has been incorporated most clearly with the user experience designer at, especially compared to the people of Microsoft (Gmail versus Outlook). The simple solutions are not necessarily the easiest for them, but results may end up being the "easiest" to use for the end user.

But there is one catch, while trying to create a simple solution it is possible to make it "too simple". Simplicity is the goal, but as Einstein said "Make everything as simple as possible but no simpler".

The problem of simplicity is present at all levels of life. Look at my day job as a software engineer, where you need to try to build a solution that has a short time-to-market period but still it needs to be one that has be designed in such a way that you can cope with change, cope with upcoming specs, cope with change in technology. As an advocate of Lean, Agile and eXtreme Programming I can feel how ever changing software specs are leading us to think about simple design instead of designs that are thought to stand the test of time ... because they never do.

Yagni (You are not going to need it) and Kiss (Keep it simple and stupid) and baked in the way of doing XP. By constantly asking ourselves whether or not we are going to need it, whether or not the specs are really frozen or if they are only 'ideas', thoughts of an optimistic future.

Because our job as a software engineer is supposed to be an 'intellectual' one, one of high expertise in building unbelievable enterprise designs that can stand the test of time, we are supposed to build complex architectures, because... that is what we do. But in reality the only thing that matters is getting your application shipped asap, released very often and having a team / methodology that can cope with extreme spec changes (.i.e. Scrum), technical design is most of the time not even an issue.

Abstractions are often the first signs of an 'evil design'. Take for example the next example. On a project I recently started working at they had designed an application which was backed by an ESB (Mule) for facilitating enterprise messaging, nothing wrong with that all services where nicely designed within the concepts of SOA but instead of just using the ESB they have wrapped it with their own abstraction so that they could plug in our out different ESBs. Sounds nice but reality and years of experience teaches us that this abstraction is pointless because technology changes so rapidly that when you come to the point where you really have problems with that particular ESB, you are not only going to change the ESB, but also the technologies surrounding it and in most cases it is just going to end up as a completely new project because the company's new technology guidelines advice even to use a new programming language (who says we still be doing ESB / SOA) ... "time has moved on" is what the Gunslinger in the "dark Tower" series would have said.

Get started, design something simple, push it to the customers asap and stop thinking ahead, you'll never get it right the first time.

This brings me to whether or not I'll be able to accomplish simplicity at my Devoxx presentation. Time will tell I guess...

Reading

I have to admit that my upcoming GWT presentation at JavaPolis Javoxx Devoxx is kinda getting to me ... the scary way :-$ Devoxx is the leading European Java developer conference and the pressure to create an inspiring presentation is ... high.

The last year I have been seeing TOO many TED talks which have raised my own expectations to an unhuman level, every slide has to be right ... it is killing and I haven't even started thinking about what I'll be presenting nor what format it will be.

So last week I bought myself a couple of books to boost my 'theoretical' knowledge of creating great slides. They arrived the day before yesterday so I hope I can read through at least one of them the next two weeks.



I'm also playing with the idea of doing some kind of cartoon like story to explain the power of GWT ... problem here is that this is probably going to take up too much time to design and implement (who's is going to create the drawings?). I also need to find a better way to present 'code'. My presentation at Jazoon learned me that all those 'code' slides are not the way to go, I was kinda bored of my own presentation. It is really hard to find a correct format to present 'code' and live coding is out of the question, I was thinking more in line of recording a coding session using for example Camtasia and reply it afterwards.

How to be interesting

Running integration and end to end tests is fun because they allow me to read up on some of the blogs I follow.

Today I read something interesting by Russell Davies - How to be interesting. He discussed how you can become an interesting person, a person other people want to meet.

He makes two assumptions:

• The way to be interesting is to be interested
• Interesting people are good at sharing

I'll not spoil the rest of the article!

Inspiring talks

If you ever need to do a presentation I strongly advice you to check out the inspiring talks on TED first.??

TED stands for Technology, Entertainment, Design. It started out (in 1984) as a conference bringing together people from those three worlds. Since then its scope has become ever broader.

This site makes the best talks and performances from TED available to the public, for free. Talks are added each week and currently alreaddy over 200 talks have been made available. These videos are released under a Creative Commons license, so they can be freely shared and reposted.

Some of the people you should definitely check out are:

• Seth Godin
  
• Larry Lessig (you gotta love his presentation slides)
  
• Jane Goodall
  
• Clifford Stoll
  
• Aubrey de Grey
  

No doubt that being able to attend one of these conferences is #1 on my todo list, unfortionately it is rather hard to get in :-)

Good news is that I found an alternative closer to home (Wales) called Do Lectures. The idea behind it is the same as TED,??getting a handful of speakers together in one place, in the hope that they may inspire you to go do something. You'll notice that 'feeling inspired' gets a whole new meaning when having watched TED talks.

And if that is not enough - Do Lectures is ALL about 'feeling inspired', just watch this picture (for some reason Blogger failed to upload my pictures today) ...??Yes, it seems they sleep in teepees.

These people represent what it means to be alive - PASSION

Devoxx - Thinking beyond Java

for those who did not receive the latest JavaPolis Javoxx Devoxx newsletter


We regret to announce that BeJUG is forced again to rebrand the conference name because of trademark issue's filed by Sun Microsystems.

Sun did offer a free license agreement for the usage of both JavaPolis and JaVoxx, which we appreciated. However we prefer to remain an independent European conference where great content, a democratic entrance fee and a nice family like atmosphere are more important than a 'restricted' Java branded conference name.

Hand in hand with Parleys.com our JUG organized gathering wants to continue to give an independent voice to the Java developers from all over Europe and beyond!

With this in mind we'll rebrand "JaVoxx" to "Devoxx" and together with 3000+ attendees and 120 speakers we're looking forward to welcome all of you again in Antwerp/Belgium during the 2nd week of December 2008!

Sun Microsystems will fully support Devoxx and again be present as a Premium partner. In addition Sun has committed to deliver a super cool JavaFX keynote...


Actually I love the new name - Developer Voices - and the real intention behind it all. Time has come that people are looking beyond Java and start exploring other things like Erlang, Ruby, Scala... and Devoxx will provide us a platform for delivering top notch presentations.

Perhaps we should do a GWT + Rest + RoR section, it would be pretty sweet!!! Charlie if you are reading this, get that Android book shipped so we can start cooking up strange GWT recipes :-D

Question remains if I should rename all my previous 'Javoxx' posts :-(