Posted by Geert Bossuyt mid-afternoon: April 20th, 2010
[EDIT : ] Go here for the REAL ACTION.
I’m proud to announce I’ll be coordinating & leading the translation to
Dutch for the Agile Manifesto in an initiative of the Agile Alliance.
It’s ment to be a community effort, so I’ll be making a lot of noise about this so that every dutch speaking soul can add his two cents to this translation.
To see more info on this initiative see here.
To help on the Dutch translation, keep an eye on this blog, I’ll post the working page soon. It’ll be in Dutch, since this is a Dutch-speaking community effort.
Posted by Gerard Janssen at around evening time: April 19th, 2010
Architecture can be divided into two categories : simple and complex.
And actually, it is the same with people. I prefer simple, humble and straightforward people. I find complex people hard to relate to, they often make a fuss about things that seem irrelevant to me and make life harder than it should be. In Holland we have a saying: “Such a person should come with a manual”. Only, I hardly ever read a manual. That is why I prefer people with a straightforward and ‘simple’ character that lack pretense and that you can take at face value. And it should be the same with architecture: let’s keep it simple. Simplicity is in fact a systemic quality that must be a driving force in architecture.
(more…)
Posted by Geert Bossuyt mid-afternoon: April 19th, 2010
When two workmen are working on the same house but each of them uses a different plan (Off course they both think they are using the same plan), the house will not end up to be the intended house. Also, these two men will have a very difficult time appreciating each others work. What will you learn if you act perfectly according to the plan and someone tells you it sucks because he’s using another plan? You will either learn that the other guy is stupid, or you will learn that clearly you’re not as good as you thought you were. Both lessons are useless. Neither you, nor your collegue will improve your individual skills or your mutual ability to work together. So, the differences between the two plans will only become bigger. It’s impossible to be succesfull in this way.
Posted by Iwein Fuld in the early evening: April 14th, 2010
A lot of automated acceptance testing pioneers have come around and denounced their fate in heavy automated test suites. A recent article on InfoQ sums up the trend quite nicely. I am not going to jump on that bandwagon, but I will try to find the safe middle ground between the overzealously created maintenance burden and anarchy. The main point is that automating acceptance tests is the way to go, you just shouldn’t automate and maintain useless tests. The tricky part is to find out what tests are useful and what tests are not.
(more…)
Posted by Jarl Meijer at around evening time: April 12th, 2010
Within an Agile project environment periodic demo`s are one of the main strongholds. Demo`s are good for the team and the customers. They set focus and make progress painfully transparent. Agile promotes demoing the teams results every iteration, so every 2-4 weeks, and from the first iteration on. In this article we will present 2 real life cases, and discuss some considerations one should take into account to prevent early demo`s to have a boomerang effect on the project. Early demo`s can set the customers expectations to unrealistic levels which will lead to frustration all around. (more…)
Posted by Geert Bossuyt at around evening time: April 12th, 2010
This curve reflects some ideas on how and when a coach can take the lead and with what purpose.
Would you agree ? Or would it need to be an ongoing wave ? What about the phases … any important ones missing ?
Posted by Wilfred Springer in the early evening: April 8th, 2010
Tonight, I stared at the http://blogs.sun.com/ site and realized that the entries I once wrote would soon have an Oracle logo on top. That’s just not right. They can’t just make me become one their bloggers. It’s unfair!
Well, anyway. While staring at the rebranded front page, I wonder how they made the transition. I remember that – in the past – Sun went over a couple of rebranding efforts. Rather than actually changing the CSS classes in use, they would actually redefine those classes. But since most of the classes were for one sole purpose only – to set the color – they used the names of these colors as the names of the CSS classes (more…)
Posted by Geert Bossuyt in the early morning: April 7th, 2010
As with many other roles, all kinds of people fill in the role of the ScrumMaster.
I see 5 types of ScrumMasters. These have nothing to do with the different responsibilities of the ScrumMaster, nor with the different functions that fulfill the SM role in different organizations. What I want to describe here are different types of people that like to be ScrumMaster and do a good job doing it.
The 5 types are
The Regulator
The Planner
The Chemist
The Director
The Adventurer
These 5 types of people seem to like the art of ScrumMastering for a different reason and get their satisfaction from different kinds of achievements
Different stakeholders can benefit from knowing what type of ScrumMaster you have at hand. More about that at the end.
Let’s have a look at who they are, what makes them happy, their blind spots and the essence of ScrumMastering for each of them.
(more…)
Posted by Serge Beaumont terribly early in the morning: April 1st, 2010
If you write user stories, it is very likely that you have been using the “As a… I want… So That…” stanza. What you might also have found is that it is hard to fill the “So That” clause with something that makes sense. “As A User I Want a button So That I can go to the next screen”… that is pretty naff, isn’t it? So how do you fix it? Ask “Why” several times!
(more…)