Task-board Experiment

Task-board Experiment

Very recently I used a Taskboard for a couple of Sprints for one of my Scrum Teams who had not used it ever before. This article will discuss that experience of the Team. Some of the things discovered about the experience were very interesting because they were mostly so contradictory to what a task-board is perceived for doing for a Scrum Team.

Flip sides to the coins discovered (not trying to be destructive but realistic)

Transparent yet not transparent:

The work being done became transparent BUT at the same time it was not transparent because the notes on the post-its (on the task-board) were not clear to everyone because of limited real estate. Hence detail was missing.

Light weight yet not light weight:

It was very easy to add user stories and tasks because all that was needed was write the required stuff on a post it and stick it on the board BUT due to details missing for the User Stories and tasks it was considered heavier because of having to use 3rd party tool to maintain documentation that linked to the stories on the task-board.

Priority Shifts

The shifts in priority are troublesome to handle on a task-board because a lot of shifting of post its is required BUT it eventually comes down to the experience of the user using the tool, whichever tool it maybe.

Collocated Team Members:

It worked great for collaboration between Team members who were collocated BUT non collocated Team members (located in a different room next to ours) found it inconvenient to track their tasks from task-board located in a different room.

Most of the Team members agreed in the end that it was not the task-board that failed completely for them but it was how some of them used it. Some genuine limitations were discovered like non reliable archiving, and limited real estate to include detail in stories and tasks. This experience taught us that it may not work for everyone. The heaviest of tools can feel lightweight for Teams who are familiar with the particular tool.

Experiement with Sprint Review

"It's a waste of time!"

What do you think that statement really means?

One imperative question pops up in my head whenever I hear that statement.

1. What is the true meaning of "waste" and "time"?

Waste as per thefreedictionary.com is defined as "To use, consume, spend, or expend thoughtlessly or carelessly". Waste has a very specific meaning. On the contrary Time is relative. Time is defined as "An interval separating two points on this continuum; a duration". So Clearly Time is relative and changes based on the two relative points.

Let's magically teleport ourselves into the delicious world of the Cake business. Let's assume that we are dealing with a REALLY PICKY customer and several other COMPETITOR CAKE BAKERIES. The PICKY customers want their cakes super customized. They are really busy but find some time to explain what kind of cake they need. Say one PICKY Customer wants a chocolate cake with 5 layers of alternating cream and chocolate. He also wants five cherries on top of it and it also needs to have the right amount of sweetness. The cream should be medium thick in all the layers and the icing on the cake needs to be of spectacular quality.

Two broad approaches to building the cake may be taken (in the Cake builders mind). One would be telling the customer that he will receive his full cake in a couple of days and spend those 2 days making sure the cake meets his requirements. The other approach could be to build a small piece of the cake in an hour or 2 and (considering his pickiness ) have him come to taste that small piece.

Here is the point I am trying to make, the time we spend inviting the customer and having him taste that small piece and getting his feedback would be much lesser than the amount of time spent building the cake all over again because he does not like the complete cake (built in all or nothing fashion). We would rather waste a small piece of the cake than waste a whole cake. So where is the wastage happening really? In checking at regular intervals with the PICKY Customer if the cake we are building are as per his standards or in the time spent building a cake which he definitely would not approve? Why on earth would you risk throwing away a whole cake vs throwing away a small piece?

The TRUTH of software development is that it is a BUSINESS. The customers are picky. Yep there are. The customers needs are constantly changing. If we don't give them what they want they will just move to a different product without a blink of an eye.

A Sprint Review gives an opportunity for the customer to take a sneak peak at what is being built. He gets to give feedback. If he realizes that that is not what he wants, the team that is building the product has the valuable opportunity to tweak the product as per the customers needs rather than fail.

So is this really a waste of time?

Pre UAT - the notorious professor tactic!

Pre-UAT. Why it cannot be underestimated.

The importance of Pre-UAT is often underestimated. There are quite a few companies which I know which think Pre UAT is a waste of time, thank God it is not my current company. Pre-UAT in my mind is all about getting the customer involved early to deliver the most potential shippable software early. Not months down the line. Really ridiculously early. Why? Because as product builders, often times while building our awesome product using our awesome techniques we forget that the customer is the one who has enabled all this awesomeness for us in the first place. We are the flame. Never forget what sparked us into existence or else we could be extinguished without knowing when and how it happened. Unless off course you are the spark and the flame both.

I thought the best way to describe the benefit of a Pre-UAT is by

giving an example of a notorious professor I had taken a class with in school. He taught

Chemistry and Math. I remember much before the final exams he used to set unofficial internal deadlines pretty much spontaneously on the syllabus he had covered up until that moment. The internal deadlines often did not make sense to us students because they covered partial concepts and partial chapters which were a part of a bigger concept which was not yet comprehended by us yet. Well you must be thinking, how is that any different from a mid term or a surprise test? In my mind the fact that the midterm is a planned exam which happens at a fixed time and date makes it ineffective.

What the notorious professor did was announce a date for a test on the syllabus covered so far, tell us our final grades would be affected by it and then after we had focussed all day everyday until the day of that test on the syllabus he would casually announce in class on the day of the exam that he had cancelled that "life changing" test because of some petty reason. It generally used to leave us hating him and relieved at the same time. What we did not realize was that it made us really ready for whatever was taught until then. If we had to give a final exam with that scoped out syllabus, at that moment, we would kill it! In agile software industry talk, we were truly shippable. We had potentially shippable working software and the beauty of it was that we did not even know it.

Scrum in a subtle way does the same thing. Now ponder over the above paragraph for a minute and send across any questions that might pop up in your mind right this moment without hesitation to sid@sbnation.com.

Bye.