Agile Nuggets: Common questions

Last weekend I attended ATA Vadodara Meet 3 at Baroda Management Association. We had very good and interactive sessions on-

• Introduction to Agile - Scrum Development by Mr. Khushru Doctor 
• Introduction to ASP.net core 1.0 by Mr. Afzal Qureshi

As we all know that Technical sessions always grab the attention of developers and the same happened with the session on ASP.net core 1.0. Once again I saw the charm of ‘open source’, this time with APS.net core.

The interesting and most important thing I observed was the great enthusiasm towards Agile practices being followed in software development among all the attendees. The Speaker was very open and patient. This helped attendees to ask lots and lots of queries and to quench their thirst and know more and more about Scrum.

I have listed a few topics discussed here so these could reach to other Agile practitioners who could not attend this session.

1. What should be optimum length of a Sprint?

2. Why some teams use modified Fibonacci sequence?

3. How much Buffer should we keep during estimation of stories?

4. From where we can get Planning Poker cards?

5. Can we have changes in Definition of Done?

What should be optimum length of a Sprint?
Though most of the teams in agile world (more than 70%) opt for two week long Sprints but it depends on the nature of the project. Recently two of my teams opted for one week long sprints. These teams felt that there were lot of uncertainties and ‘Fail fast’ would be more helpful for the team.

There is a misconception that in a one week long sprint the sprint ceremonies like planning, review, retrospective etc. consumes time as team has to go every week for these ceremonies. But as we all know that the duration of ceremonies are directly proportionate to the length of the sprint.

Why some teams use modified Fibonacci sequence?
The idea of story points is not to bind the thought (size verses hours) during estimation of stories. The sizing should not be so precise that it becomes hindrance during estimation.

     Excerpt from Mike Cohn’s Blog-Why do the cards deviate slightly from the Fibonacci sequence?

We’re anal software people, too. We know that the Fibonacci sequence should go from 8 to 13 to 21. We use 20, though, instead of 21. Of course we used 21 in the early days, but dropped it after meeting with a product owner who looked at the 21 and said, “Oh, a 21. You must be very confident to give such a precise estimate. Most people would have called it 20 or 25, but you called it 21.” We replied that we used the Fibonacci sequence. The product owner said, “The Fibo-what?” After which, we decided that deviating from the Fibonacci sequence would be better because the numbers started to imply a very high level of precision that just wasn’t there.

The 1/2 is included because after awhile some teams decide they want some room in between “free” (a zero) and one. Using 1/2 isn’t something a team should do a lot, but it’s a nice option to have in some cases. More on- http://store.mountaingoatsoftware.com/pages/faqs

How much Buffer should we keep during estimation of stories?
I would strongly say, NOT at all. When we go for estimation we follow sizing. This may be Story points with Poker planning, T-Shirt sizing, Animal sizing etc. Clearly we see there are slots for sizing and these are not distributed even. For example if a story is larger than 8 point which may be of 10 or 11 point but the next number in series is 13. This helps to avoid preciseness during estimation. One important point to note is that keeping buffer will lead team to be underutilized and will slow down the velocity. Also, team will lose the essence of planning and discussion over estimated points by other team-members. Team-members will agree with the largest estimation as everybody will start thinking to have buffer.

From where we can get Planning Poker cards?

Many places for example,

• leanpitch.com/playscrum-cards/ (Pune)
• store.mountaingoatsoftware.com/
• Amazon.com
• …..many other stores
• In addition, there are lots of Planning poker apps, can be downloaded from Play stores.
• For distributed teams we can use online poker planning. Please refer PlanningPoker.com .
• Even we can download printable Planning poker from internet and get it printed.

Can we have changes in Definition of Done?
Yes, we can have changes in DOD. After all continuous improvement is the success mantra for Agile teams. We inspect and adapt!

     Excerpt from Mike Cohn’s Blog-




          Excerpt from Kenneth S. Rubin’s book- Essential Scrum:


I hope you have enjoyed this post. If any reader has any question, please feel free to ask. I would also look forward to suggestions from readers as I could be wrong at places explaining these points.

Agile Nuggets: Few common dysfunctions during software development.

A few weeks back we examined - ‘Stakeholders made the things complicated than they need to be.’

Today let us continue the next – Gluttony

• Gluttony –ScrumMaster

Facilitating multiple teams simultaneously- This leads ScrumMaster losing ‘focus’ from his teams hence results being unjust with them. Generally having a team of size 5 to 9 demands a full time ScrumMaster.

• Gluttony –Product Owner

Pushing team to take-up more and more stories in one sprint- This creates unwanted pressure of delivering stories and mostly ends up with technical debt. Also team never finds time to repay any technical debt which was taken in past.

• Gluttony –Development Team

Gold Plating- Sometimes some developer puts his time adding unnecessary things, for example too much of documentation. This does not add any value to product and results in waste.

There are multiple such points but I took one point for each. Readers can share their experiences/observations.

This Sprint Future-O-Spective with Santa Claus!

Here’s the festive season again and Santa Claus is coming to town. We need to take care of the balloons during the party so they shouldn't look awful.

What may be the impediments which need to be taken care?

•       During freezing weather, balloons shrink up terribly
•       Balloons should be retained for longer period of time
•       Safeguard balloons from our pet parrot with curved beak which is keen of pricking balloons

Our futuristic actions-

• We shall use good quality latex balloons
• Coat hi-float* on the balloons
• User Cold helium or nitrogen
• Keep our naughty parrot in the cage till the party gets over.

*Hi-Float: is a gummy resin that you apply to latex balloons to allow them to retain helium for longer periods of time.

Now team can identify how to keep balloons (forthcoming Stories of the project) safe from the identified impediments by effective utilization of resources available, or by acquiring the needed resources.

Special thanks to Bhavin Shah for drawing this wonderful drawing board.

Agile Nuggets: Simplicity!

I have seen many software projects suffering from few common dysfunctions. A few dysfunctions are mentioned below:

• Stakeholders made the things complicated than they need to be
• The real customer requirement was based on a business need and was something very simple but there was a communications gap between business analyst and programmers
• Gluttony -Product Owner
• Gluttony -ScrumMaster
• Gluttony -Development team
• Habit of taking Debts (Technical/Non-technical)
• Tight coupling of features and functions
• 
  

• A few more…

Today let us see the first one- ‘Stakeholders made the things complicated than they need to be.’

A few years back I read a very interesting analogy presented by Scott Davis,U.S. Below are the excerpts I would like to share with readers.

[My microwave oven only has one button: “add a minute.” To boil a cup of water for my coffee, I press the button three times. To melt cheese on my crackers, one click. To warm up a flour tortilla, I press “add a minute” and then open the door after 15 seconds.

Would a one-button microwave oven ever make it out of the planning committee?

Probably not. I can tell by the (never used) features on my microwave that the committee favored complexity over simplicity. Of course, they probably cloaked “complexity” in the euphemism “feature-rich.” No one ever starts out with the goal of making a product that is unnecessarily complex. The complexity comes along accidentally.

Suppose that I have a slice of cold pizza that I want to warm up. According to the manufacturer’s directions, I should press the “menu” button. 

I am now faced with the options “speedcook” or “reheat.” (Um, “reheat,” I guess, although I’m kind of hungry. I wonder if speedcook will be any faster than reheat?) 

“Beverage,” “pasta,” “pizza,” “plate of food,” “sauce,” or “soup”? (I choose “pizza,” although it does have sauce on it, and it is on a plate.)

“Deli/Fresh” or “Frozen”? (Neither, actually—it’s leftover delivery pizza. I’ll choose “Deli/Fresh,” I guess.) “1 slice,” “2 slices,” “3 slices,” or “4 slices”?

I have no idea how much longer this interrogation will last, so I press Cancel and then the “add a minute” button.

Amazon.com only has one button: “one-click purchase.” Oh, sure, I had to type in my address and my credit card number the first time I visited, but now I am one click away from my impulse buy.]

The well-known 80:20 rule in software says that 80% of users only use 20% of features.

• 45% of features were never used;
• 19% used rarely;
• 16% sometimes;
• Only 20% were used frequently or always.

However the focus on making the product “feature-rich” sometime makes it unnecessarily complex. 

The other example of such feature-rich products I see is my Mobile phone. :-) 
I am not sure how many times I used the fascinating features like 'Gesture Recognizer' it offers.

There are many ways Product owner/Stakeholders can decide the priority of the features needed. One of those I have explained in my other post.

We will keep on discussing the other dysfunctions in forthcoming Agile nuggets, stay tuned!

Improvements through Scrum Ceremonies...

We all know Transparency, Inspection and Adaptation are the three pillars of empirical process in Agile development.

Our team works in a transparent way, processes are transparent and even practices are transparent. But how our team inspects and adapts?

Certainly there are well defined processes for Inspect and Adapt.

Daily Scrum: In this 15 minutes timeboxed activity, all the team members inspect progress toward the sprint goal in the form of answers of the three questions provided by each team member of development team.

• What I did since the last daily scrum?
• What I plan to complete by the next daily scrum?
• What are the obstacles or impediments preventing me from making progress? 

Based on the answers team synchronizes and adapts the plan for the work till next Daily Scrum.

Sprint review: Sprint review helps the Scrum team to inspect and adapt the product. During review team gets feedback from various stakeholders and based on that adapts what to do next.

Sprint retrospective: Sprint retrospective helps the team to inspect the processes/practices being followed and adapt accordingly. There may be something to continue, to stop or to start.

Backlog refinement: Generally teams do not count this ceremony as a inspect and adapt activity but I strongly believe that due to this ceremony, Product owner gets chance to prioritize the stories and gets to know the clarifications development team may need during next sprint planning.

So all set with the Inspect and Adapt activities! Now I need few answers from the readers.

•          If any impediment comes after the daily scrum, do we need to wait till the next daily scrum?
•          During development, for example some suggestion comes up during some implementation, should we wait till Sprint review?
•          During sprint if any team member comes across with a very effective open source tool which can save a lot of efforts and time, should he/she wait till the Sprint retrospective? And yes we should bear in mind that some teams follow 4 week sprint.
•          The Product owner senses the heat of the market and wants to add/remove some stories from the backlog, should he wait till next sprint?

You said it right! Inspect and Adapt are not dependent on any ceremonies. And that’s how we achieve “CONTINUOUS IMPROVEMENT” because we do not wait for ceremonies to take place first and then go for any improvement/adaptation.

I know enthusiastic team members want to see their great ideas start working in their sprints as soon as any such idea tickles in their mindJ. But sometimes other team members want to analyse and make sure that the point(s) suggested for improvement is valid/authentic for the team and the work being done. They want to take some time for a quick discussion on that. 

I suggest that the member who got the idea, should make a note, may be write that on a sticky note and place that on the team's board. (Sticky with a different colour works great to grab the attention of the team.) If there are distributed teams, the point can be sent to all for consideration. Team can have a quick discussion on that during some short break and sometime may ask Proof Of Concept from the team member suggesting the point. Once accepted by all, that point can be considered for the sprints as an improvement.

We do not need Product Owner in our Sprint Retrospective...seriously?

Whenever we start a new project there is always a chance of having a few new faces in our scrum development team. Also, there is a big chance of having a new client or at least a new Product Owner in our team. In a nutshell we can say that there is always a possibility of changed team composition when we start a new project. 

The biggest challenge I see (sometimes I embrace it as an opportunity to learn) is, the jelling of new member with the team or the team accepting the new member quickly. And that’s not a big surprise because the reasons are obvious. 

Some of such reasons I experienced are- 
1. Cultural variances 
2. Doubt of efficiently coping up by the new members with the rest of team 
3. Lack of skill sets required to be a Scrum player 
4. New/Immature to Agile culture 
5. … 

Yes, you got it correct! A very effective way to overcome this situation is to break the ice (3Cs…this time a bit different…communicate communicate and communicate) with openness and transparency. 

But surprisingly I have observed that sometimes a few teams tend to miss such opportunities which come in the form of Scrum ceremonies. One of such ceremonies which I experienced that teams try not to include Product Owner is Sprint Retrospective. 

I ask only one question (humbly) to team that let me know a single reason to not inviting Product Owner in Sprint Retrospective. You might think that there would be NO answer. But there always exists at least one. Team- “We would like to discuss this between development team as there are few things we want to discuss and keep within development team”. 

How does this sound? Team wants to keep something hidden from Product Owner? This seems odd. There is something seriously wrong happening with team and certainly a lack of trust and transparency? 

Ok, now you as a ScrumMaster tried to find out the root cause to know what development team wants to hide from Product owner and you find that during planning team over committed and they took some kind of debt (Not necessarily technical debt). Team thinks that it is better to hide this from Product owner and repay it in next sprints. After all development team want to see Happy Product Owner and listen “Bravo!”. 

Cool… So now team will hide this debt from Product owner and will be in a catch 22 situation. Will team repay the Debt or will it keep on increasing? Let us keep finger crossed and watch Spectre with some awesome actions by Daniel Craig :-|. 

On the contrary when you involve Product Owner in your retrospective and update him about the debt team has taken during the sprint and the plan to repay in next/subsequent sprints, there are full chances that your Product owner will understand this and you will get some user story in your backlog. Even if he doesn't appreciate you but one thing he will establish and that is your honesty, that’s the first step you took for trust building. 

And yes, team is tired after the sprint done and everyone needs a break. So there are two chances, either some of the team members will try to escape from retrospective or if they participate for the sake of ceremony then it will be boring and the outcome will be not as expected. So why not mix some fun in your Sprint retrospectives? Play some game (different with the one you played in past) for your retrospective and see the difference.

Don't forget to share your experience with your Funtrospective.

Enhance iterative development with Mikado Method...

Let us start today with Boy Scout rule.

Boy Scout rule says that- “Always leave the camp-ground cleaner than you found it.”

If you find a mess on the ground, you clean it up regardless of who might have made

the mess. You intentionally improve the environment for the next group of campers.

Bob Martin (and others) nicely explained why Boy Scout rule applies to product development

and technical debt (Martin 2008).

And that’s what we follow during software code implementation/development.

Recently I found a very interesting method Mikado Method which is companion to Boy Scout rule. Let us have a high view of Mikado Method. (I might be coming up with more details later!)

Mikado Method is very helpful while repaying Technical Debts. This method is also a very effective way to morph an existing system into a desired new shape. This is, when we try to customise existing system with the client specific modifications. Most of the time it seems to be very simple and less time/efforts consuming but most of the time it turns out to be a nightmare. 

Mikado Method works very well with Extreme Programming, Scrum, and Kanban. It has four simple concepts.

• Set a goal
• This can be in the shape of a user story.
• Experiment
• Make an experiment without analyzing the consequences too much.
• Visualize
• Verify the impediments and find out errors
• Find out the solution to fix the errors/impediments (without over analysis)
• The found solution for fixing the errors will be now the new prerequisites for the goal. This needs to be drawn somewhere, may be on team’s whiteboard.
• Undo
• Revert the code to the initial state where the errors were encountered.
• Fulfill the prerequisites.
• Perform the process of reverting and fulfilling the pre-requisites for all the errors/prerequisites till goal becomes error free.

When goal is error free, Check-in the code. Verify once and Voila! You are done.

(All suggestions are welcome!)