Wednesday, July 23, 2014

Tweaking Agile/Scrum

I'm working with agile/scrum methodologies for quite some years. Generally I like Agile/Scrum , but I think some of its aspects can be tweaked to suit better.

First, I share the problems I see with agile. Especially, this is very important when you are doing a new product (or) development

1) Free thinking, experimenting environment and sharing ideas can become limited as individuals concentrate more on their current user story and tasks on hand.

2) May not fit everyone's working style.  I will explain the "working style" what I'm talking about.

Take, Person A, Person B working on your project. Now, the way they approach a same problem may be different

Person  A   -   do research --> read through API's --> do the coding--> quality deliverables.

Person B    -   do some dirty coding --> read API's --> make something works --> do the coding --> iteratively improves --> quality deliverables

Here we are more concerned about the output rather than their working style, the last step "quality deliverable" is important than anything else. We need  to see how we can make the agile/scrum fit with the different working style's like this.

3) Problems in Time sheet. I have explained about this in detail below.  Though, Time-sheet may not be tied with Agile/Scrum entirely, I'm sharing as a general perspective of product management.

4) Visibility to big picture related with company, product, vision .etc are limited to selected few who do the tasks like sprint planning.

What we can do?

I have put few suggestions to address these problems

Sprint Planning

Macro thinking, Big Picture, Overall Business/product objectives has to be part of every sprint planning meeting. Tell them where this sprint  fit in overall business/product goals. In this way, everyone get motivated towards the task in hand thinking the big picture.  It also encourages innovation, new ideas and out of box thinking from team members.

Daily Sprint Call

Daily sprint call  need not be a place to discuss only about your current sprint and work. Don't make mandatory for team members to share the status of their current work unless there is a real dependency with other team members (or) something important to share. Again, creating daily dependency between project members is not a good project planning.  Daily sprint call can also be just a causal greeting and discussion with coffee.

Time sheet

Time-sheet may be needed to see the effort spent by project members which may be needed for some  metrics (or) to raise invoice (or) for other organizational needs.

This is my take on time-sheet

1) Time-sheet need not be a daily task of the project members.

2) Encourage developers to track the things they are working daily which helps to fill time-sheet end of sprint (Most sprints are fortnightly). So in a way,  it fit's everyone's working style I was talking about. Also, it will not make them to fill just for the sake of filling.

3) Don't put micro tasks with micro time which are trivial. For example, from software development perspective, don't create a task like 'Installing xyz software' and put 1 hour for that .  Idea is overall output from a project member is important  rather than tasks in daily time-sheet.

4) Let the project lead/manger and team member sit together and fill time-sheet at the end of every sprint.  By doing so, it helps to get consistency and uniformity. It also helps in getting useful metrics and  make things more readable,manageable for future references.