Pragmatic Agile Weblog

Agile software development in real life

Agile lectures

Recently Edo, our scrum master, introduced a new initiative that I particularly like: agile lectures. From his presentation:

What is it?

30 minutes of our time every week to read and comment together some excerpts of Agile (Books, Articles, Tutorials, Videos).
We’ll start with some paragraph from the book “The Art of Agile Development”.

Why?

Because learning is an on-going never ending process, we still need to learn something and Agile is hard to maintain

How?

With a projector in a relaxed environment with coffee, tea, cookies. Reading and commenting together. Remote people will join via webex and have virtual cookies 😉

When?

Every Tuesday at 4.30pm until 5.00pm (CET).

Where?

In the meeting room in Pavia’s office (the cave) and via webex for remote people

Who?

Everybody is welcome to the lectures. No need to send confirmations, just come in the cave and join the lectures.

The reason why I like it so much is because we have been realizing that between agile and pragmatic agile there is a huge distance. I see pragmatic agile as the every-day agile, with the environment you are in, the people and the teams you have, the habits and cultures each group of people establishes over time. These lectures are a way to understand how agile and pragmatic agile can get closer. With this I mean that we see how things could be done differently, so that we talk about it and internalize it. I learned that at the end some people are not interested in principles or values at all. They are just interested in their daily job and in how make it better. Agile lectures are a good way to talk about real every-day experience in the context of agile practices.

September 26, 2009 Posted by | Agile, Funambol | Leave a comment

Mike Cohn on user story writing

http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template

September 20, 2009 Posted by | Agile, SCRUM | Leave a comment

As a … I want …

One of the key aspect of agile development is expressing requirements in user stories. It is one of the things that I like more, because it encourages developers to think always like a user.

However, in our switch to agile I’ve seen US using the most disparate roles between “As a” and “I want”. The most common mistake is when a technical task is expressed as a US using expressions like “As a developer I want to merge the tag into the trunk” or “As a product owner I want to know the size of a the MEA feature”.

For this reason I decided to identify which roles we use and introduce them to the team at the last demo meeting. Using a role not in the set below should be a big smell that there is something wrong.

The first role we use is the user:

The user role

The user role

The user is who is using the user interface of our software. This is primarily client oriented, but not in all cases.

As some of you is wondering, yes, the command line is a user interface as well. But it is a particular one, used mainly not from the final users, but most likely by system administrators. The system administrator is one the roles we selected from our us:

The system administrator role

The system administrator role

With our software there are also users whose duty is to help other users. These person are the portal administrators, who administers the portal users and other portal functionality. The portal administrator is therefore one of our selected roles:

The portal administrator role

The portal administrator role

Finally, an important aspect of our software is that it provides APIs and SDKs other developers can use to build application on top of our framework. These are definitely a special case of users, for which we want to build features. The developer is therefore the last one of the roles we use in our backlog.

The developer role

The developer role

Note that “this” developer is not the development team, which therefore has visibility to all Funambol code. This is a developer that wants to access a limited set of the source code, or maybe not even the source code, but libraries or APIs delivered in binary form. It is who uses our software to build something else, not who develops the software itself.

Many thanks to Francesco Mapelli, the author of the nice “omini” that represent our user stories roles.

September 13, 2009 Posted by | Agile, Funambol, Software engineering | Leave a comment