Baby steps

photo by Qole Pejorian

Baby steps is one of the principles behind the eXtreme Programming and other agile methods. It is, namely, performing changes in small steps on every level, be it implementing a feature, changing the database structure or just coding a couple of methods. The ideas behind this principle correlate well with not programming by coincidence and usually baby steps are implemented with test-driven-development based techniques.


  • On the coding level baby steps mean changing the code in small bits and verifying that it still works after every small change. Often it means using test-driven-development, running a local set of unit tests after every change and periodically running the whole test set.

  • On the architecture level baby steps mean that when the need to change or create architecture arises, the change has to be performed in small steps even though the initial and final architecture might differ much. For example, when extracting some functionality into a separate class it might be a good idea to leave “stubs” in the original place and remove those only after all the needed functionality is iteratively moved to the new place.
  • On the requirement level baby steps mean learning to apply the agile planning methods, learning to divide the user-perceivable features into not big tasks, but smaller features that can be developed, delivered and evaluated separately. User stories can be handy at this level.


The advantages of applying baby steps come from the fact that the smaller the piece of work is, the easier it is to think it over, plan and verify. Baby steps allow for verifying the direction often and for changing the plan frequently. When applying baby steps every mistake is only a baby mistake that can be noticed early and corrected easily. For example, when transforming the application from a single binary into client-server, the baby steps can help to see very early if a chosen technique (e.g. COM plugins or AJAXy web clients) fits well into your situation and adapt before months of efforts are invested into the transformation.


The biggest disadvantage of the approach is in the need to actually verify the application behavior often, be it the code or user-perceivable feature level. For the team that does not use test-driven-development and does not have an extensive set of unit tests, verifying the functions can take a lot of time. If the customer does not collaborate with the team often, it is difficult to verify early that the feature is done.

The “frequent verification overhead” might be a real problem in some circumstances. However, whenever we manage to make it smaller, whenever we manage to make the unit testing set faster and more reliable, whenever we manage to get the customer evaluation more frequently, the speed and correctness of delivery raises quickly.

Your experience

What step size do you use in your environment? Do you run the test sets every every 10 minutes, nightly or monthly? What is the verification overhead like in your environment?

Innovation games: Buy a Feature

Innovation games are a special type of activities designed for embracing the innovation by helping people to collaborate and discuss in a form of playing a game. These games are a way more useful and more interesting, than any traditional requirement workshop based on reviewing the requirement document proposal. Innovation games are one very clear example of applying the Individuals and interactions over processes and tools principle. Buy a Feature game explained in detail in the Luke Hohmann’s book* is one of the most frequently used in the course of agile software development whenever there is a need to prioritize a reasonable amount of not very well understood features.

The Rules

In the beginning of the game the team or product manager presents a list of all the features of interest with the price tags, where price means the cost of implementing the feature in whichever units. Agile teams typically use the size estimates in story points or ideal engineering days. The units used are not important, the only important thing is the approximate relation between the feature costs, so that it was clear that feature with the price tag of 100 is a way more difficult, than a feature that costs 10.

Then all the participants, which ideally include team members, marketing, sales and real customers, are given some virtual dollars that they can spend on buying the features they like. At this point there are some variations in the game. On my Scrum Master course, the whole group was given 100 “ping-pong balls” that we had to collaboratively spend on features. Luke Hohmann likes not to force the collaboration explicitly, but to give people quite limited amount of money so that participants had to ask a partner for buying an expensive feature together. Joel Spolsky vice versa prefers to give people a freedom to buy half- or double-features if they like.


Whatever the concrete method is, in the end a group of people form a collective and quantified opinion on the feature priorities, on what is really important to them, what is nice to have and what they could live without. This method works well, because it implicitly forces the participants, who should always include your customers, to leave the “we want it all” attitude and discuss the actual product priorities.


Your Experience

Did you ever use some variation of Buy a feature game? How well did it work in your environment? What did you particularly like and dislike?

*If you buy the book after clicking links in this post, I’ll get a dollar or so. Here is the non-affiliated link to the book if you don’t like the idea of a blogger earning money with the reviewed product.

Scrum customer management: not participating customer

Sometimes there are customers who “generally” agree to using Scrum as a software development process, but fail to fulfill the product owner role. What do you as a team do then?

Product owner responsibilities are the ones that virtually any customer has got. Product owner is responsible for deciding what features are the most profitable for him, for controlling the return on investment, for accepting or rejecting the work results – in essence he is responsible for making money out of the development effort. I’ve never seen a customer who would not like to to decide on what is the most important for spending his money on.

What often happens in the case of not collaborating customer is one of the following:

  • product owner simply does not have time to participate the sprint reviews every two weeks, or maybe he does not believe that his attendance will be worth the time spent

  • product owner cannot freeze his wishes for even the sprint period of time and gets new priorities every day
  • product owner is used to contracting in the waterfall manner, got used to that it is pointless to review the mid-project documents and does not really know that Scrum will make him a usable product after just a handful of sprints


Every team and every customer are unique. There is no universal answer that works for all of the situations and that’s why there is a Scrum Master role one of whose major responsibilities is exactly to help customer and the team to understand each other. However, there are some techniques that work for quite many teams. What often works is:

  • Get a proxy product owner
    If real customer is available too rarely, there could be a person who knows the customer area best, maybe travels to his site from time to time. This person can act as if he was a customer and make the decisions basing on his knowledge of the real customer interests
  • Push demos to the customers
    What worked for my own team in the past was pushing the easily downloadable demos to the customer. If they were one-click easy to install and try, than even the laziest busiest customer was curious enough to give it a try and tell the product owner what’s wrong with the current version. Naturally, unless the problems discovered were huge, it was the product owner who had to call the customer for feedback, because the real customer was too lazy busy for it.
    I’ve also head that some teams videocast their sprint reviews to the remote customers
  • Reserve some slack for urgent requests
    It is indeed not recommended to include the new content into the committed sprint. However, if you absolutely need to do it, why not to reserve some time for urgent requests in advance?
  • Explain the costs
    In many cases the customer doesn’t realize what consequences his sudden requests cause. After explaining that the urgent request can spoil the results of a week, customer might decide that his request is not that urgent and might delay his request until the next sprint.

As usual Scrum does not solve the problem. A customer not caring about the project is unlikely to get a good product whatever methodology is applied. Scrum only helps to make the problem explicit and visible. Whether to act on the process revealed is certainly up to the people and not to the process used.

Does your team have or had a problem with the customers not willing to collaborate? What was the reason for it and did you manage to fix the situation?

Scrum process overview: schedule

Scrum is the adaptive and flexible software development methodology. The possibility to adjust it according to the team preferences and organizational culture make Scrum implementations look differently across the organization. Some teams like packing the estimation session into a separate day, some like doing a little bit of estimation during every sprint planning; some teams have 5 minutes long sprint reviews, some have to make their reviews day long in order to let all the stakeholders express their opinions.

Scrum process schedule can and should be adjusted according to the retrospectives held. Therefore, it is not that important to start with the perfect schedule, it will anyway be adjusted. However, it can save some time if we start with something that works for many teams out there. Here a couple of more-or-less standards schedules to start with.

30 calendar days sprints

  • Day 1. Sprint planning meeting, 1st segment – 3.5 hours
  • Day 1. Sprint planning meeting, 2nd segment – 3.5 hours
  • Every working day between day 1 and day 30. Daily stand-up meeting just before lunch
  • Day 30. Sprint review meeting – 3.5 hours
  • Day 30. Sprint retrospective meeting – 3.5 hours

14 calendar days sprints

  • Day 1. Previous sprint review meeting – 2 hours
  • Day 1. Previous sprint retrospective meeting – 1.5 hours
  • Day 1. Sprint planning meeting, 1st segment – 2 hours
  • Day 1. Sprint planning meeting, 2nd segment – 2 hours
  • Every working day between day 1 and day 14. Daily stand-up meeting just before lunch
  • Day 14. Sprint review meeting – 2 hours
  • Day 14. Sprint retrospective meeting – 1.5 hours

What do you think about such schedules? Does it look like something that would work for your team? Is it really a good start to start with one of these schemes.