A few months ago I was joined a software development team that had some problems getting their process right. The team was doing Scrum by the book, apart from regular production releases they were doing it all: sprints, planning, retrospectives, Scrum board etc. This team didn’t need too much explanation of Scrum so I could dive into development straight away, or so I thought. They struggled with getting the sprints right, their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.
Read more →

Will infoq.com have a “Lean” section in the near future? Given the recent rise in blogs, presentations and articles on Lean subjects, don’t be surprised if, in 2009, Lean will be the new Agile.

Lean is a process management philosophy derived from the Toyota Production System that aims to provide more value with less work. Lean originated from mass manufacturing, but has successfully been applied in other industries such as health care, travel industry, and services. That means Lean can also be applied in software development.

Although Lean is becoming more popular in the Agile community, the views on what Lean is, differ widely. Martin Fowler tries to avoid the entire Lean vs. Agile debate by stating that they are equal. Although the idea of keeping Lean within the boundaries of Agile has its appeal, not everyone agrees.

Read more →

In over two years of working with Scrum I’ve found it to be a great focus point for people who want to do projects better, faster and have more fun. The clients I’ve worked with, introducing Scrum, have all seen a surge in employee satisfaction, customer collaboration and focus on team effort. Xebia is entrenched in Scrum and we host certification, events and training. Together with some gurus like Jeff Sutherland and our colleagues we’ve trained hundreds of people in the Netherlands in using Scrum. After all this positive responses and experience, here at Xebia we thought there should be more ways of sharing Scrum experiences. So we think it’s time for a “Scrum User Group” in The Netherlands.

We’ve set up the Dutch Scrum group and named it nlscrum. We have already hosted our first meetup last month and it was a great success! We hope our next event will even draw a bigger crowd and more inspiring ideas!
Read more →

Agile 2008 is an international conference in Toronto on Agile software development. It’s held from the 4th to the 8th of August. It’s gaining in popularity with 1600 participants from all over the world. Of course most attendants are from the US and Canada.

I attended this conference and gave a presentation together with Olav Maassen. I want to share some of the inspiring ideas and ‘vibes’ that I picked up at the conference.

Read more →

The Product Owner role in Scrum

In the Lean Software Development method Scrum there are three roles: the Team, the Scrum Master and the Product Owner. In my experience the Product Owner role is by far the most confusing and hardest role to ‘get right’ and provokes the most discussion. Even the mere definition of what this person should do is under debate amongst most Scrum practitioners I’ve talked to. I want to discuss the origins of the Product Owner role and my experience in how (not) to fill this role, especially in companies that don’t do product development.

The mythical Product Owner

I’ve seen many flavors of Product Owners and none of them really worked as they should have. Actually, rumor has it that good Product Owners actually don’t exist. Now that’s something we should be frank about if that’s true. If the Product Owner is a combination of responsibilities that doesn’t work in practice, we should find some alternative. First, I’ll explain my experience so far.

Read more →

Big up front design (BUFD) is a term that finds its origin in the standard waterfall model. It is often criticized and seen as something that should be avoided. I believe we should not be so easy to dismiss BUFD. I want to discuss the good things of BUFD, because I believe there are many. For a minute, stop thinking about project effectiveness and all those agile principles and let’s zoom in on an imaginary group of people, team red, working on their Big Design. Perhaps you’ll agree BUFD has it’s merits if you look at it from a personal perspective.

Read more →

When doing any development process it’s always good to keep ourself aware of the things you intend to do. A cheat sheet or checklist is an easy way to keep your team on track and doing the right things. For me a checklist is not to be followed to the letter, it’s just a good way to start thinking about your process.

There are some scrum checklists out there: Scrum Rules Cheat Sheet, Scrum checklist. I would like to add another list. My list is not so much about the practices of scrum, but focusses more on the goals of scrum (such as communication, trust, teamwork). The list contains questions you can ask the team. Try to answer all questions within short time (say half an hour) by looking at the work space and talking to the team. If you need more time or cannot answer all questions, you might have some things to discuss during the next retrospective. I hope it will get you and your team thinking about areas of improvement.
Read more →

I’m introducing the Scrum process in the development department of a large organisation. I anticipated the problems we’re currently facing with the rest of the organisation. Specifications are vague and several months old, people we need for information and feedback are hard to find. So in short, the usual impediments. When observing development teams you’ll usually hear people complaining about these things. But the thing that is not often discussed is that developers that are new to Scrum have some things to overcome as well.

Read more →

There is one thing in software development that any developer should remember at all times: test, retest and test again. Any true Agile project revolves around testing. Test your code, screens, databases and test whether your user stories actually work. Nothing is left to chance and testing is done before everything else and after your done and your code will undergo regression testing when you’re long gone. Pretty obvious, you might say, but some parts of testing are more obvious than others. Unit tests are pretty much covered, there are dozens of tools and frameworks for that, the same goes for screen testing. But one thing that still feels like new ground is functional testing (or acceptance testing).

In Agile projects there are a two constraints that apply to the ‘traditional’ way acceptance tests are performed: test first and agile (flexible) test cases. When working with dedicated testers, the developers need to work together with them as a single team. Using the ‘test-first’ approach, you need the input from the tester before you can start coding, otherwise you won’t know when your work does what it needs to. One other problem that both developers and testers face is responding to changes. When the customer wants a new feature, you can’t reply: “It was never build to do that!”. We’re agile, so we’ll refactor the code if needed. Changes also apply to tests, requirements change and the software changes (database changes, user interface changes, etc.). So the tester needs to be able to deal with those changes.

There are a few things we can tackle. The magic word here is ‘Fitnesse’. Fitnesse allows you to combine test case specification and execution on one page. This allows for very smart test cases, you could have something as simple as:

My test data:

The test:

Read more →