Unkasoft's blog, where we talk about mobile games development, gaming industry, agile methodologies and all that matter we're handling every day

Wednesday, August 30, 2006

SCRUM at Unkasoft: the sprint backlog

We've been talking about sprint backlog twice.
In one hand, while we're planning the sprint, we should make the sprint backlog, and in the other hand, during daily scrum, we should update its contents.

This is the theory, but... How are we making and updating our sprint backlog here at Unkasoft?

We base our work on well-known Juan Palacio's sprint template published time ago (with some final touches made by us).
We've been evaluating some others templates, but they didn't convince us due they was too complex.

In essence, this template is something as virtual board where we drop cards for tasks to be implemented and we move them when they're completed.
During daily scrum, we update each task, making a note of remaining hours to be completed, and the template will plot burndown charts for us.

Basically, the template has three sections:

We note down some general information about the project and the sprint, like number of days for the sprint, number of hours for each working day, kind of tasks (code, meeting, test, documentation...), task states, team members and holidays.

We write here all tasks extracted durint sprint planning, with estimated hours and the kind of task. For each task, we maintain the number of hours remaining to complete it. So, if one tasks isn't progressing, we'll see this number of days don't decrease, which is a bad thing.
Basing on this data and development speed (a factor between 0 and 1 we've introduced in the template), we can compute estimated release date, different for each day of the sprint. With this date, we can see whether we're behind schedule or not.
Another stuff we've introduced is a column with real hours for each task, which we fill when the task is completed. Although SCRUM doesn't propose this estimate-real hours control, we need it for our budgets and costs.

Finally, basing on previous data, we can plot the typical burndown chart and another ones to see how tasks evolve, how release date fluctuates and the work load for each developer.
We could talk for hours about how you can interpret this charts. I recommend you this post about five signs of trouble in an iteration. We've suffered all of them (:
Also, there're more complex charts, in order to manage tasks introduced in the middle of the sprint.

Ok, it's been finishing... next day we'll talk about how we mix SCRUM with eXtreme Programming.

Sunday, August 27, 2006

SCRUM at Unkasoft: the daily meeting

Last day we’ve been talking about how you can organize SCRUM sprints, but we skipped daily meeting subject.

But before we can start, we should introduce the Scrum Master role.
SCRUM suggests three roles: product owner, development team and Scrum Master.
The Scrum Master is that person who has the whole vision and the best way to apply SCRUM methodology inside your team. He/she isn’t the typical project manager or team leader, or the all-mighty-commander-boss. Scrum Master could be a person working at partial time, combining these tasks with another ones (perhaps he/she is the product owner or another programmer too), although at large projects, perhaps he/she is working at full time.
It’s important to say that Scrum Master has to be a person with enough power inside the company to make hard decisions.

Well, now we’re all introduced, so let’s continue…
The daily meeting (as well, called “daily scrum” referring to the typical rugby game movement) is the heart beating of the SCRUM project. The meeting is the place where the team is gathered, a sharing time where people talk about their progresses, doubts, ask for help and so on.
Thanks to this daily meeting, we’re averting typical end of project delays, because you’re watching the progress (or lack of) day by day.

Several dev teams I know, the project manager goes for each desk asking about the progress, or perhaps the programmer warns their manager when he/she is done.
Let’s remember SCRUM proposes auto-management, so here, the manager (Scrum Master) doesn’t review others’ work, but other team mates do.
It is important that the whole team can see whole project progress, instead of watch only him/her part. This will raise an identity feeling which could be considered the “SCRUM’s gasoline”. Without this feeling, the SCRUM project will stop as a car without gas.
And here I should remember you again: don’t try to use SCRUM at anywhere or with anybody. Choose carefully your team and your work environment.

Daily meeting shouldn’t last more than 10-15 minutes, in order to avoid typical endless meetings without a clear goal and subject. Here at Unkasoft, our daily meeting is very informal and last about 2 minutes because of our project has only two programmers (one of them is the Scrum Master too).
So don’t concoct more excuses in which you don’t have enough time to meet with your team.

SCRUM defines a “modus-operandi” more or less established. During the meeting, each team member should answer following questions:
  1. What did you do yesterday?
  2. What are you going to do today?
  3. What do you need to progress?
In Jeff Sutherland’s blog (one of the two creator of SCRUM), he explain underlying reasons to these questions.

What did you do yesterday?
With this question we’re testing two things:
At this moment, each programmer updates the sprint backlog in order to show remaining hours to complete each task of the sprint (next we’ll explain how sprint backlog is arranged and how you can work with it).

What are you going to do today?
Here, each team member assigns remaining tasks of sprint backlog. Neither team nor Scrum Master should force anybody to do one task. Why? Because nobody will know better than developer which tasks he/she will make the best and the fastest. Everybody will choose tasks according his/her knowledge and experience, so step by step, tasks will be assigned in optimum way without external intervention (pure chaos theory :)
As sprint progresses, hard tasks will be left. Then, Scrum Master could suggest, but never force.

What do you need to progress?
Sometimes, people in charge of other people forget his/her main duty: manage the environment in order to people can work faster and better. However, most bosses don’t apply this management, but he/she just command without remembering why he/she should command.
With this question, programmers raise a warning about blocking sides. The Scrum Master has to do all he/she can to solve theses problems.
Some typical problems could be:
Some problems could be solved adding more items to sprint backlog, but others don’t.
When your project was in a tight spot, these problems could be a ton. In that moment, Scrum Master should note down all problem and make a “impediment backlog”. From here on, main team priority is remove this impediment backlog. Each item will be assigned to team member or even out of team members (network admin, for example). Next day, this impediments backlog will be reviewed to remove solved problems and release blocked tasks.

Saturday, August 19, 2006

SCRUM at Unkasoft: the sprint

Let’s follow with our SCRUM series… dealing with sprints.

We can say SCRUM’s sprints are something similar to XP’s iterations, although with several differences.

We could define a sprint as the total amount of time that development team has in order to implement, document and test a set of new functionality (this set is called “increment”). At the end of the sprint, we should have a ready-to-use, shrinkwrapped version ready to be delivered to any customer.

Typically, one sprint is split in three phases:

1.- Planning: a meeting with product owner together with development team with next goals:
All these tasks will be noted down in one new spreadsheet called “sprint backlog”. We don’t note new features (user histories), but it turn into concrete tasks (refactor X, research Y and so on).
In sprint backlog we’re going to write the amount of hours remaining until each tasks was done.

2.- Implementation: once we’ve get our sprint backlog, we can start the development. Both parties (product owner and dev team) should agree they can’t add new tasks until sprint ends. If one new feature comes up, it will be added to product backlog and it will be taken into account for next sprint.
Everyday during sprint development, whole dev team will meet to review the progress and up to date the sprint backlog. This is the “daily meeting” and we’ll tackle it next day.

3.- Review: once the sprint has been completed, product owner and team will meet every other interested part (marketing people, customers, etc) and an informal demo will be done to show new functionality (called “increment”). During this meeting could arise one or more new features and them will be noted down at product backlog.

In the other side, dev team will meet themselves and will think about:

For instance:
- Tony
: we’ve failed with new renderers test.
- Johnny: yes, it was a sheer hell
- Tony: As soon as we have some free time, we should research how we can automate it.
- Johnny: yes, I note it down to add it at next sprint.
- Tony: By the way, undo/redo prototype feature went really good.
- Johnny: it’s true. It was a good thing that we spend a couple of hours writing a small prototype in order to prove whether Command and Memento design pattern works as expected.
- Tony: OK, next chances we can use prototypes too.

Next day we'll talk about daily work of one sprint and the daily meeting.

Wednesday, August 16, 2006

SCRUM at Unkasoft: the product owner

Yesterday, we talked about product backlog. Ok, the person in charge of this document is the "product owner". In fact, it isn't a real person, but it's a role, which can be played by one or more people (Jaime and me for Battlewizard team). This role could be played by one person at parcial time (this is the typical scenario) or several people at full time (warning! SCRUM doesn't works with large projects, so if you detect this situation, think twice before applying it).

So product owner should have a clear idea about product to be built (Jaime have, I try to), he/she has to detect which features should be implemented and especially which features should NOT be implemented. It seems 45% of features never will be used. In the other hand, we have 80/20 rule, which sais more or less:
A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Unfortunately, it's never the same 20%. Everybody uses a different set of features. [...]
But that's another matter and should be told at some other time.

OK, as we said, product owner should have clear idea about project direction and keep up to dated and prioritized its product backlog. It's not about spend days and weeks analyzing and re-analyzing possible features, but it's working few hours or days in order to get most essential and basic features, suffice to begin working with first version (something could work).

This figure is similar than "client" role of eXtreme Programming, where it was the person in charge of collaborate with the team to write all user histories and decide which features will be implemented during next iteration.

Once version has been completed, product owner will review it together with dev team and see whether this version meets the expectations as he/she expected.

When product owner has completed its product backlog, then he/she will collaborate with development team to define the sprint backlog, so...
- ey! wait a minute! we don't know which "sprint backlog" is...
ugg... you're right... but I'm late, so next day we'll talk about sprints and sprint backlog (:

Monday, August 14, 2006

SCRUM at Unkasoft: the product backlog

OK, once we've been introduced to SCRUM, we're going to deal with several sides of this methodology, taking into account our own point of view and the way we've dealt with here at Unkasoft.

The First item we approached was Product backlog: it is the list of features to be implemented in the product we're creating. Theoretically, when all these features were implemented, the product will be done.

This step has been easy to implement for us, because months ago we've been maintaining a document (called "problems to solve") where we noted down all this stuff we'd like to add to Battlewizard. This document was expanded with our own experience, features requested from QA departament or from external companies using Battlewizard (like our early adopters GPM-e and Karonte).

This way, adapting to SCRUM has been as easy as convert our documento to a spreadsheet, adding all user stories subjects and a brief description using excel's comments. All these features have been arranged in four categories, in accordance to the need to be implemented: very high, high, medium and low.

And what’s all this stuff for? Because with this product backlog we’ll never forget one suggested feature and we can maintain and track a prioritized list of items pending to be implemented. Besides, this is the starting point when we're going to plan a new version.
Once a feature has been completed, it will be removed from product backlog and little by little this list will be decreased (ok, in fact I’ve never saw it decreasing, but it is always getting larger and larger. I hope one day things will change…)

Person in charge of maintain this document is called "product owner" and his/her main purpose is... ok, I think I've spoken enought for now, so next day we'll continue dealing with "product owner" figure.

Friday, August 11, 2006

SCRUM arrives at Unkasoft!

This summer is been frantic! We're rearranging our dev team (one of them has already arrived and the other going to do it soon), released two games more (we can't say anything yet but you'll get news soon) and testing one new methodology for out project management: SCRUM.

It's a long time since we're using eXtreme Programming as development methodology, especially in our Battlewizard team, but planning, managent and tracking matters have been untidier than development side. So with Juan Palacio's help we're working out with SCRUM and now we're completing our sixth sprint (:

SCRUM is a auto-management team methodology, that is: there isn't a manager who cries commands and the others obey, but the team should be auto-managed.

Well, that's right and auto-management looks great but it's quite difficult to apply. Don't try to use this methodology at any company, because I know some of companies and people who will turn it in a true failure.
Just two days ago, Joel Spolsky has published a set of articles about team management, and he tells us there're three typical categories of management inside companies:
So first advice: do not try to apply SCRUM at any place. First obtain a good working environment and then everything will be easier.

Next, you have our experience about some SCRUM sides we're using here at Unkasoft:

Thursday, August 10, 2006

Who’s going to win the mobile game match?

In the late 70’s and 80, many companies defined their strategies moved by the ideas of great “gurus” as Kaplan and Norton, they were encouraged to seek exponential growth based on economies of scale. Everyone see sweet, the market of mobile game; want to get a piece of pie?

I found the courage to create a strategy map –inspired by the useful info América passed me-.
The main idea is to share it, and do it useful for all who wants be in –for skeptics of collaborations see the following post about
'Strategy of the Dolphin'-.

We believe in one vision: be one of the best mobile game producers and not be the low cost. I know sounds as a cliché, but quality is the most important consideration; quantity is the least important. In line of that, keep improving shareholder value, shareholder trust in our idea and respond gracefully to this confidence.

Wednesday, August 02, 2006

Difference from failing and meeting with success with mobile games

Talking with some developer about mobile gaming, we always finished asking the same question: What is the difference between failing and success with mobile games? At least, the market and the technology limitations answer that question with coldness.

Nowdays, meeting with success needs of standing out with some of mobile games developed, where we must define “standing out” as selling success over production costs.

If we follow the market, we must look for the selling success inside popular brands and of course, into the cost saving in producing the games that need of moving the use of human resources to low cost countries. Then, success need of having a popular brand, create a game about that brand and having low production cost. Then, failing must be considering as the lack of popular brand and no way of porting games with a low cost mechanism.

As a message from the market and from technical limitations, we can consider this answer as the logical answer, but insufficient for us. We are going to change the success concept inserting new variables. Now, we think that success need of an automation of the porting games between mobile phones process, almost to the null cost. Also we will need of simple and easy games. We look for the developer comfort, distributor comfort, aggregator comfort, operator comfort and at least the fun for the user/player. If we are able to do and to package a funny game in two weeks with a 2.000 € production cost, and later we obtain revenues about 10.000 €, then we would meet with success because of the cost-effectiveness.

We don’t need of the popular brand; we need of adapting small companies, like us, to the market capacity. We need of process automation and need to parallelize our game developing. Making 10 casual games in a month with an average cost of 2.000 € per game, with revenues near to 10.000 € as objective per game, will meet the small developer with success.

Of course we will need of creative people for making funny and striking games. If we don’t have budget for advertising, leave the distributors and aggregators make their work moving the catalogs, with some downloads from each country we could be profitable.

We continue supporting quality games and popular brands games with quality, but while a small company can’t make a quality game with popular brands, they need of creating a catalog for getting money. You must automation the processes or ask for help to people like us that are automation our processes. It is a step of the way in this market.

The complete success, will be publishing a popular brand game with a low production cost.

This page is powered by Blogger. Isn't yours?