Fixing the Cause-Effect Trap in User Stories
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...)
“Committing” to a Sprint and failing is a GOOD thing!
Posted by Serge Beaumont mid-afternoon: March 24th, 2010
What does it mean when a Scrum team "commits to a Sprint"? There is a subtlety in the English language that leads to misinterpretation and misuse of the verb "to commit". I have seen too many cases where a team is held accountable ("bad team, bad!") because they did not achieve their Sprint goal in some way. And it will be accompanied by the accusation: "...but you committed to the Sprint, didn't you?". As a coach, this is the moment I step in to explain what "to commit" really means, and that you want to fail every now and then: succeeding every time is a failure mode all of its own.
(more...)
The READY Kanban: the Product Owners’ Scrum Board
Posted by Serge Beaumont in the wee hours: September 12th, 2009
In my previous posts about the definition of READY and Flow to Ready, Iterate to Done I have tried to shed some light on the Big Black Hole of Scrum: the Product Owner. This is number three in the series.
In my previous blog post I presented the stages that a backlog item flows through before it gets to Ready. But those were the ideas behind it: in this blog post I'll show how I've implemented them in practice. I'll show you two interesting examples.
Flow to READY, Iterate to DONE
Posted by Serge Beaumont at around evening time: July 4th, 2009
In a previous blog post I introduced the definition of READY, and I wanted to do another "context" blog post before starting on this one: on the difference between flowing ("kanban") and iterating. However, I had much more to say on the subject than I expected, so the thing kept expanding... I'll gather my thoughts and publish that one later. So for the purpose of this blog post just bear with me: I find that a Product Owner's job is best done in a flow style. And since my dear ex-colleague Lars Vonk told me he was waiting for this post, I'll just explain the how here. Lars, here you go... 
Update: the third of the series is also done. See here.
Not all backlog items are equal. A backlog item starts out as a rough sketch - usually just the As a.. I want... So That... stanza - and needs to be fleshed out to the extent that it can be picked up by the team in a Sprint. Just like a team has a basic workflow getting stuff to Done, the same applies for the Product Owner role. Scrum does not have any specific support for a Product Owner: somehow the Product Backlog just "happens". In this post I'll try to fill that gap with respect to the process that a Product Owner can follow.
I'll explain a partitioning of the backlog that maps onto a flow, the nature of those partitions and how you proceed through them to get enough stuff Ready for the team to pick up in the next Sprint.
Landmark reached: 20000 unique visitors per month
Posted by Serge Beaumont in the early afternoon: July 4th, 2009
It kind of snuck up on us, but when we recently checked the blog visitor statistics, we found that we had gone over 20000 unique visitors per month in april! So to all of you who've stayed with us through the past years, to all the Xebians and ex-Xebians who have been contributing posts, and to all who commented on the blog: a big thank you. We hope we can keep offering the content that will push us to, let's say, 50000!
The Definition of READY
Posted by Serge Beaumont around lunchtime: June 19th, 2009
Yesterday I gave a presentation on the Integrating Agile conference on the answers I have found in what I consider to be the Big Black Hole of Scrum: the Product Owner role. Based on the feedback I want to blog about this subject, and unblacken the hole a bit...
Edit: the link to the second post in the series turns out to be buried too much at the bottom, so I'm adding it at the top: See Flow to Ready, Iterate to Done
The Definition of Ready
I give CSM trainings with Jeff Sutherland, and about half a year ago he had put something in his material called "the dynamic model of Scrum". The essential feature was the addition of a READY state opposite the DONE state. The idea here is that a team needs to be in a stable, known situation to be able to perform well. It immediately struck a chord with me: I had seen so many teams thrash because the Product Owner could not give them a clear objective, the READY state was exactly the goal to work to. But what was it really, and how do you get there? By now I think I've got some good answers to these questions.
Do you worry about crappy code? Then face reality and grow up.
Posted by Serge Beaumont around lunchtime: April 24th, 2009
My colleague Age pointed me at a blog post by Uncle Bob about a presentation where a Mr. Josuttis presented the inevitability of crappy code because "businesses will do whatever it takes to cut costs and increase revenue, and therefore businesses will drive software quality inexorably downward". Uncle Bob proceeds to go against that argument, but I find it to be a technocratic (DSLs and produce better code) and ultimately unsatisfying answer. My answer to the problem?
Face reality, grow up.
The Task Burn Down Trap: everything finished, nothing done
Posted by Serge Beaumont around lunchtime: September 19th, 2008
In the past three projects I've been involved in (one as team member, two as agile coach) I've seen that the usual Sprint burn down based on tasks leads to a dangerous trap: you might end up with nothing done. In two cases we had nearly zero velocity for a Sprint, while the tasks were 90% done... Luckily there's a fix: burn down user stories, and toploading.
Wicket, JBoss, JAAS, LDAP
Posted by Serge Beaumont in the early afternoon: May 8th, 2008
Call me old-skool, but I don't like pulling in huge frameworks like Acegi for some simple authentication and authorization stuff. This post will show you how I connected Wicket security to an LDAP through JAAS. This leverages the LDAP configuration and access on the appserver level and keeps the application clean. This was done on JBoss, so YMMV on another server, but this post should help you along when you need to tweak the solution.
Caveat: this solution does NOT get you logged in as far as the appserver is concerned, so you'll not be able to use container calls like isUserInRole(). If you find out how, let me know. For our purposes we didn't need it, but it's nice to know anyway.
Death to workflow: long live the checklist!
Posted by Serge Beaumont mid-afternoon: March 5th, 2008
Sequential steps thinking leads to systems that are relatively complex, frustrate users and are not robust in face of unforeseen circumstances. Adopt the goal-oriented, unordered checklist style, and save yourself and your users a world of hurt!
What went before...
Last year I found out how someone can get me angry using only Post-Its.
Categories
- Java (292)
- Agile (137)
- General (98)
- Architecture (49)
- Scrum (46)
- Testing (45)
- Performance (42)
- Podcast (31)
- Middleware (34)
- Deployment (22)
- SOA (25)
- Project Management (24)
- Xebia Labs (23)
- Quality Assurance (16)
- lean architecture (15)
- Tools (12)
- Virtualization (10)
- Articles (9)
- Security (7)