juin 2010Monthly :

Note that the ‘Scrum Team’ refers to the Product Owner, the ScrumMaster and the Team. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.

Last week I was discussing with Mathieu and he started to talk to me about a friend who is now Product Owner (previously project manager) on a Scrum project. This person wants to make sure he is doing a good job and wants to continuously improve. I said, this is really awesome!

Mathieu, then says that his friend asked him the specific question: if I want to track the time I am investing in creating user stories and prioritizing the product backlog, which work item type and fields should I use to enter actual time spent if I am using the new Scrum process template from Microsoft.

My reaction is … Interesting, why don’t you ask your friend how he is going to use this data to effectively improve as a Product Owner? If the Team is producing software that the users consider high value at an ever increasing and sustainable pace, don’t you think that those are great indications that the Scrum Team is doing good work? I believe those are much more interesting metrics to track than the actual effort he is putting in creating and prioritizing the product backlog.

Mathieu: Sure, I will suggest him that but I think he also wants to track cost.

Ha! This is getting even more interesting now. Because it leads to the questions of time and cost tracking in Scrum; a question I often get in my scrum classes, especially from participants working in large corporations.

When I started teaching Scrum in 2004, I used to answer in my classes that time tracking is not part of Scrum but if you want to track actuals on sprint backlog items for administrative purposes, you can go ahead.

Observing Scrum Teams doing time tracking on sprint backlog items invariably leads them to questions like:

• Where do we put the time for meetings?
• Do we need to have absolutely all tasks in the sprint backlog?
• When we are pairing, do we do time entries for each of us?
• When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals)

And the list goes on. All these questions are a struggle for the Scrum Team and answering them does not help them in creating high value software fast. Therefore, my answer now is: Tracking actual work on sprint backlog item is not part of Scrum. Period.

The reaction I usually get is either “this is impossible in real life” or “you are telling us that a Scrum Team is not responsible for its cost”.

I think that a Scrum Team IS responsible to be aware of their cost and the value they bring to the organization; they are software professionals and therefore they strive to maximize the ROI of their work. The Product Owner is specifically accountable for maximizing the ROI by appropriately prioritizing the product backlog.

The reaction is usually “I don’t get it. You are saying not to track actuals on sprint backlog items and at the same time that the Scrum Team is responsible for its cost.”. Here is the suggestion I usually provide. Most organizations are interested in knowing how many hours their people work to be able to produce the pay checks. Therefore they have a timesheet system where people enter their time. My suggestion is to have time entries per project (much higher level of granularities than the sprint backlog items). Therefore, a team member working on a single project will produce one time entry per period. Timesheet system or not, you should be able to easily query your enterprise systems to know salary costs for a given period. May be you are lucky enough to have a cost tracking system in place that is able to give you the answer to how much expenses directly related to the product development were made during the same period.

My point is that it should be possible to identify the total cost of an iteration and have the Scrum Team track this. Considering all of this, I have a request to make to Microsoft : Add the fields ‘Scrum Team Cost’ (numeric) and ‘Other Costs’ for iterations in the Scrum process template. This will be useful for enterprise Scrum. May be it is not too late to put it before version 1.0 goes final

Cheers,

~françois

Quick entry, it’s getting late…

Every Pythonista should have virtualenv installed. It gives you the ability to create virtual environment (duh!). That means you can create a virtualenv for a project using django1.1 and some old eggs without having an impact on your current killer app project.

To install it, just run:


pip install virtualenv
python virtualenv.py path/to/my_virtual_env
path/to/my_virtual_env/bin/activate


And you’ll be using a brand new environment that you can throw away without impacting your other python environment…. Awesome! For more go to virtualenv’s page : http://pypi.python.org/pypi/virtualenv

Now if only we do this in ruby… oh wait, it exists : http://github.com/nkryptic/sandbox
I’ll try it and see how it goes !

RVM is the way to go for ruby.. I’ll post something later on that

Starting tomorrow, I’ll dive in the world of Django, one of Python’s famous web frameworks. I messed around with in the past week and I feel like the framework is pushing me in a direction that just ain’t natural to me.

Coming from Ruby on Rails, I welcomed the idea of having a project that contains multiple apps (a concept that will be introduced in Rails 3 I believe). What I found unnatural is the way the Django generates some code for you. When you run

manage.py startapp myapp

It will create a Python package called myapp, which is great. However, it gives you a models.py, tests.py and views.py (a View in Django is the equivalent of a controller in Rails). If you follow the tutorial from Django’s website as the coding standard, you’ll end up with all your models from your app in a single file, all your views in single file, etc.

While some pythonistas will argue that if you split your apps properly the size of the models.py (or views.py) will never be a problem, I tend to believe along with a bunch of people that for the sake of readability and maintainability, each model, each controller and each test class should be in its own file. If the language allows multiple class in a file, it doesn’t mean you should do it… I mean we don’t write application on a single line even though the compiler/interpreter will accept it ’cause that’s just retarded…

If you intend to split your models and views, you’ll be in for a surprise. Django allows you to do this, but not without extra work (yes, it takes extra work to do things right when a framework steers you in the wrong direction).

You’ll want to create a models package along with its __init__.py. In it, you’ll need to import EACH AND EVERY model that you’ll create. Let’s say I have a class called Food in a food.py file, I’ll have to write this in my models __init__.py file

from food import Food

Agreed, it’s not much work, but a framework should not require you to write more code to separate your business entities.

In December 09, a colleague of ours was a tad bit envious of a great initiative leaded by Laurent Cobos.Laurent, through a collaborative effort with the Pyxis developer community created the Pyxis Developer’s Charter.

Seeing the rallying effect of the Developer’s Charter, we attempted to launch a similar initiative for Agile Coaches, but we had limited success. Coaches being in high demand these days, we had less time to invest in developing a strong and honest charter that other coaches could easily identify to.

We did however identify some conditions of success:

-The language must be business compatible

-Must show that the coach is accountable to the client

-Must show that our client is equally accountable to the coach

-Can included specific practices

-What else?

And through our internal wiki and a couple of meetings, we came up with this:

As an Agile Coach, I commit to the team and its organization to…

• Never apply recipes
• Respect your distinct culture
• Help you challenge your current culture, principles and practices
• Let you learn from your mistakes
• Not let you make irrecoverable mistakes
• Put in place an empirical process that allows learning
• Allow you to evolve within that empirical process
• Allow the process itself to evolve
• Have to courage to say No
• Guaranty bug free software

• Telling you what you must hear and not what you would like to hear.
• Not inflict help
• Help you expose the value you create
• Help you expose non-valuable activities
• Help you identify obstacles
• Help you identify solutions
• Help you to communicate efficiently
• Be continuously aware that I can be profoundly influenced by the non-Agile surroundings, immediate context and personalities. (Inspired from The Tipping Point)

• Stay true to the Agile Manifesto

What would you add, change or simply remove?

What makes uncomfortable?

Which statement makes you stand-up and cheer?!

What would be your preferred format?

Would you sign this Charter?

I recently finished reading Community, the Structure of Belonging, by Peter Block. While reading the book, I could not help but draw parallels with what I teach about Scrum.

In his book, Block talks about the small group as the unit of transformation. I already wrote about Scrum as a tool to foment change. In the context of Scrum, the Scrum Team is that small group, that unit of transformation. It changes the context of work in a way that alters how we think, behave and thus work together, which in turn can radically improve performance. François shared a similar view recently on Scrum teams, compelling goals and performance.

Block also states that for real transformation to occur, it is not more or better leaders that we need, but more care and belonging. I’m often asked what role management plays in Scrum. People ask the question : “So in Scrum, that means we don’t need managers?”. Mike Cohn has already addressed part of that question in his last book, Succeeding with Agile, by saying that management has a key role to play by creating the right environment for self-organization to occur. To add to that idea, we can say that management task is to shift the context, so that it creates in the Team a sense of belonging and ownership. Engagement from the Team will come from care so we must be careful to choose care over speed or scale.

Scale, speed, and practicality are always the coded arguments for keeping the existing system in place.

Scrum is all about changing the existing system. This is why the ScrumMaster primary responsibility is to ensure the Scrum process is followed. He or she uses Scrum as a tool to ask powerful questions to spark off change.

The ScrumMaster job is to change the conversation. The ScrumMaster is initiator, facilitator and leader of real discussions. This is a leadership role about creating commitment and accountability, which are the building blocks of self-organization.

To make a difference we must start by naming the way things are, use powerful questions as a tool, and listen, rather than advocate or defend.

ScrumMasters, take the time to master the art of orchestrating conversations, for this is what your job is about.