Friday, November 20, 2009

I have been discovered: I am attempting against the communication of Agile teams

Today, I read a comment someone post on the google wave sample page of taskboardy (http://wave-samples-gallery.appspot.com/about_app?app_id=68026)


Bringing people apart

Google Wave may yet be great, but not for this. Remember that Agile is about bringing people together -- in person. Need a real task board for this, not another application that glues people to the computer screen.


First thought that came to my mind is: Would someone consider using Taskboardy (or any other electronic tool) being collocated? Specially a task board!!! I worked in a distributed team and therefore I am forced to use an electronic tool. However, I am always in the dilemma of whether I should also use a physical task board. I know I am loosing a great visual radiator with the tool... (I decided not to, because the team is not in an open space. Otherwise, I would maintain both).


Kept thinking and perhaps the comment makes sense. How many times someone sends an email or chat with a person 1 meter away? I've seen it many times. So what can we do when the tools are not used the way they should be used? How can we encourage the most effective communication, which is face to face conversation? If the team is collocated, perhaps it makes sense to follow the comment and suppress any channel of communication that is not face to face. Take away phone, uninstall email, chat, wave, etc, etc...


Does it make sense to blame the tools? In the case of the processes, perhaps it does :-) If things go wrong in the project, let's blame scrum. At least in this case, the enemy is invisible. It is very hard to visualize what is going on, which are the bottlenecks or which are the dysfunctions. In the case of electronic tools, it would be much harder to blame them. I can't imagine telling my team member "my code sucks and I didn't do any unit tests because of Eclipse". Or... the team members don't talk to each other because of V1. Hum


Henrik Kniberg said during QCon SF yesterday we should use the tool that makes more sense to solve our problem. Now the question is: what if we are not smart enough to choose it? Will have to ask next time I see him...



Wednesday, November 11, 2009

Couple of things that caught my attention lately

- Scrum illustration leaves out people (http://bit.ly/2sJnHj) humm interesting, ah? Anyway, the most human side of the Agile Manifesto comes from Cockburn and not from Schwaber/Sutherland, right? Does the scrum books talk a lot about people? I don't remember. I would have to check again...
- Customer value is not in the values and principles of the agile manifesto. It's true. We are always talking about customer value, but it's not there. Is it because customer value is the ultimate objective that all Agile values and practices support?

Monday, November 9, 2009

Taskboardy available

I have finished the first version of Taskboardy, a wave gadget that allows to maintain a taskboard inside a wave. The gadget could be useful for agile distributed teams using Scrum or XP.

The idea is create a wave at the start of the sprint, install the gadget and add all members of the team. Then, user stories and tasks for each user story can be created and the tasks can be moved among the different states. Participants in the wave can assign the tasks to themselves. When someone modifies the taskboard, the rest of the team can see it immediately. Wave advices of the modification showing a number on the wave and bringing the wave to the first position.

The taskboard is very basic. I thought about adding some other features, like a description for the user story or the story point estimates, but didn't because I wanted to keep the first version light.

The taskboard looks like this:


If you want to take a look now and have an account in the wave sandbox, click here.

At a technical level, the gadget is made using javascript that calls the wave api to store the state of the taskboard in the wave. The platform takes care of broadcasting this state change to all other participants. For the drag & drop functionality, I used the Google JQuery API.

To install the gadget, just select "Add gadget by URL"


And then point to http://taskboardy.googlecode.com/svn/trunk/taskboard.xml or the short url http://bit.ly/4lc6lT. The installation is really easy!!

Another 'feature' that comes out of the box because it's inserted into a wave is the possibility of replaying the whole sprint. Not sure if this could be useful, but it sure looks cool.

Of course it's free to use and open source. I haven't been able to do thorough testing, so if you find a bug please let me know and I will fix it. I don't plan to do any addition of functionality. One of the reasons is that if some people start using it, I would be changing their functionality.

Please share your comments!

Update: I was not clear on the difference between the sandbox and the preview. The gadget works on both. The only difference is in the sandbox, there is a wave already created with the gadget installed. In the preview, you will have to install it.

Update 2/7 (superbowl hour): Fixed a problem with especial characters (",', etc.)




Monday, November 2, 2009

Does a heavier process guarantees safety?

Criticality is one of the things that justifies heavier processes, but here's an example that shows you that a heavier process could result in less safety (and of course is more costly, less user friendly and VERY annoying)

This morning, I went 5' earlier to the station cause I needed to buy the monthly pass. I (wrongly) choose the machine where nobody was in, select the appropriate options, purchase it, and.. and.... and... the receipt comes, but the ticket never comes!

I think, this shouldn't be hard. I just go quickly to the ticket office (while at the same time trying to advice the people that the machine is not working) and tell them what happened, hoping they would just go to the machine, verify that what I say is true and print my ticket (while putting a sign on that machine until is repaired).

Wrongs thoughts. There is nothing they can do. I have to call the 0800 - caltrain. "In the meantime, just give the conductor the receipt". Besides, they don't do anything to prevent other users to use the broken machine... (I don't get it)

Go to the train, talk with the conductor (they are always very kind) and he let me in (he evens tell me, 'well, with the receipt and the credit card, there shouldn't be a problem to use it the whole month..'. Nooo, I speak with the operator and she told me that the conductor shouldn't have let me in, that I should've bought a new ticket and ask for the refund sending a form that I could print through the web site through ordinary mail. Noooooooooooooooo.

Result: the process is heavier and less secure.

Less secure because a non scrupulous person could ask for a 'rebate' of its ticket, even if he got the ticket printed. How can they verify that what s/he is telling is true? They lost all the insight that could have been gained should they have gone in the moment to the machine (If the non scrupulous person tries to do the same, he would have to explain why the ticket gets printed 1' later, etc..). In the more formal way, there is no way to prove the non scrupulous person wrong and they have to refund the ticket.

The oddity is that at the same time...
- The process is more costly to the enterprise because someone has to pick up the mails, process it, etc). Worst, not solving the problem soon of course derives in other complaints.
- It is more costly and annoying for the user because I need to learn how to send a regular mail, print the form, fill it, find out where is the post office, send it and 'wait a few weeks' (as the operator kindly said) for the refund. At the same time, I need to buy a new ticket (I will go back to the old fashion employee way this time!)

Come on Caltrain guys!!! It shouldn't be that hard!

This post also comes as a result of reading Alistair's book again (my hero!). There is always these people that says 'We need to use a heavier process to be safer' and when asked 'Why?' .. Just because.....

Unfortunately (for all of us), we will always have to think.