Monday, September 12, 2016

Value of Sprint Planning meeting

As per Scrum Guide, "Sprint planning" meeting is held to identify/plan the work to be performed in the Sprint. It is a time-boxed event, where teams collaboratively plan the work of the entire sprint. Also, we should try answering two questions in the meeting :
  • What can be delivered in the increment resulting from the upcoming Sprint?
  • How will the work needed to delivery the increment be achieved?
In my mind, the Sprint Planning meeting should create a shared understanding of the piece of work. POs should make sure team understand the value and can visualize the real objective behind the work. 

Also, I don't like one big fat meeting. I am a big fan of backlog grooming meetings, which happens regularly and almost part of any scrum cadence. I would suggest doing it every day like stand-up. May be just after standup, team pick up one top backlog story and discuss with POs. They together try to understand the story. Doing everyday has following advantages:
  • Not taxing to your brain: Since sitting in a long meeting for hours makes every one very tired. Towards the end, everyone just wants the meeting to be over and lose the sprint of asking questions.
  • Keeps it focused: Doing one everyday is lot easier and PO feel less pressurized about the decision since it is not at the eleventh hour and he can give patient hearing to teams point without getting worries about the sprint commitments.
  • Teams can re-iterate over single story multiple times and get proper clarity. 
  • Team members are more involved during this mini planning session vs. big fat one. Also they are in the team space, which makes things lot simpler for them to look or clarify. 
  • Sprint Planning meeting becomes a breeze. We finished our meetings in 30 minutes :).
I did face little roadblocks at times in this process: 
  •  At times team member's memory needed to be refreshed because either they forgot or they were on holiday that day. 
We use to have three columns before backlog column:
  • Feature/Story Requested - PO adds them to be in the backlog as per DoR
  • Feature/Story Discussed - PO discusses them with entire team and they size the card
  • Feature/Story Ready to be prioritize - It is ready to be pulled into the sprint
Never stop the collaboration because you have time pressure, would be my suggestion. Let me know things which you might have tried in your team.


Friday, July 22, 2016

Spring-boot: java.lang.NoSuchMethodError:org.springframework.core.MethodParameter.hasMethodAnnotation

I was getting below error message for one of my spring-boot application. I realized that it was my POM file entry which was making my beautiful application throw up..

I had below entry in my POM file along with other spring boots related stuff. I removed the entry and my program started working like charm again.


I am yet to find the root cause behind. I will update the blog as soon as I have more information on it. The entire stack trace is at the end of the blog.


HTTP Status 500 - Handler processing failed; nested exception is java.lang.NoSuchMethodError: org.springframework.core.MethodParameter.hasMethodAnnotation(Ljava/lang/Class;)Z

type Exception report
message Handler processing failed; nested exception is java.lang.NoSuchMethodError: org.springframework.core.MethodParameter.hasMethodAnnotation(Ljava/lang/Class;)Z
description The server encountered an internal error that prevented it from fulfilling this request.
org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.NoSuchMethodError: org.springframework.core.MethodParameter.hasMethodAnnotation(Ljava/lang/Class;)Z
root cause
java.lang.NoSuchMethodError: org.springframework.core.MethodParameter.hasMethodAnnotation(Ljava/lang/Class;)Z

Tuesday, June 21, 2016

Bringing Fun to Team room

I am big believer of encouraging teams to laugh and have fun together. In my mind it builds team's resilience.

Is it easy! NO WAY!!! It is the most difficult think to achieve when you are around bunch of engineers. I have been part of mora than 30+ teams so far and half of my team member appreciated being left alone to code. 

I never give up and have lots of different post standup.  I have few categories

Sheer Fun:

  • Trivia after standup -  Pick a topic or theme for a week and ask one  trivia question after standup. Provide team all the details along with the answer. This way team is learning and having fun. Great for co-located and distributed teams. 
  • One Urban Dictionary word of the day - Open the webpage and ask the team to put hands together. Read the word and meaning together and say the word loudly at the end. Like sports team does. Distributed Team members can do the same as well. 
  • 15 seconds warmup - Pick any song with steps from youtube and jam together. Perfect for all teams.
  • Shake up - There are lots of games on PlanningForFailure website. These are a minute long and perfect for teams
  • Lifting weight: Start with 5lbs weight as standup token and then increase the weight slowly every iteration by 2 or 5 lbs. This will make your team strong every day and will not let them talk longer as well. 
Games for Late comers but can also be played on regular basis:
  • Sing a song in local language or some funny song
  • Tell a chuck norris joke 
  • Bring some sort of treats (donuts or cookies or fruits) 
  • Sit on a broken chair or wear a kind of hat entire day. 
  • 5 Sit-ups or push-up for every minute you are late
  • Facilitate the scrum next day
These are the few things which I have tried in my teams. Let me know if you have done something interesting and fun :).


Extrasss: I play games before Demo and Retrospective all the times as well. I get my ideas from and and tasty cupcakes site. 

Sunday, June 12, 2016

What to make big and visible in team room?

In our world metric plays a very important role in enabling us to answer questions and solve problems. A good metric would always provide valuable information to the team. There are good and bad reasons to gather metrics.

Good Reasons
  • To understand one's own progress
  • To solve a problem with the data
Bad Reasons
  • To facilitate competition between teams
  • To motivate a team to do better (Motivation should come within the team. It should not be extrinsic.) 
  • To have control over a team
  • To set a goal or incentive for a team 
A good metric should set a mood at a glance from across the room. By looking at it, you should be able to say a trend or behavior over time. A metric should either make you feel good or make you feel bad, depending upon what you see. It's aim should be to generate right behavior and discussion in the team room.

Example of few team room metrics:

1) Total # Backlog items by week

By looking at this graph you can say week 6 lots of requirement got added. How so many new requirements got discovered? what are those new functionality?  It will definitely going to make few people think about them and would make team look deeper into these new requirements. 

2) Commitment vs. Capacity per iteration:

This metric is very self explanatory. It helps team find it's true potential.

3) Product Burndown Chart with Standard deviation (More here)
By looking at it team can find out weather they will going to go live at the expected time or will need to do some adjustments.

4) Velocity chart per iteration (It is not burndown chart):
It is team's velocity over the period of time and an average line showing the trend. It is difficult to look at the raw data and infer if team is improving or not but black like clearly indicate that team is getting better over time.

5) Impediments (anything which is slowing team) per Iteration:
Simple yet very powerful metrics.

6) Risk burndown per Iteration: I follow Mike Cohn's prescribed approach and works perfectly fine in our context.

7) Product Owner's Time per day: This metric is very useful if you have same problem like ours. Our product owner was divided amongst lots of work stream. He could not spend time with team at all, so having a metric like these helped us resolve the issue with upper management.

8) Defects per demo metric: The title pretty much explains the purpose.

9) Number of unscheduled requests per iteration: Gather this data if your team getting requests from outside forces a lot.

10) Wait time per iteration: Any time team is waiting for response from DBA or Production Deployment teams or Any external dependency on regular basis.

11) Wasting of time per iteration: One of my team's lots of time was getting wasted on an old tool. We had to use that tool since it was company standard. We started tracking time we were wasting per iteration on that tool and got it replaced after 6 iterations.

12) Team Expenses vs. ROI per Iteration:  I believe this is a very important metric in agile team. How quickly are we being able to delivery value?

13) Behavior per Iteration: This can be anything which you would like to capture over time. i.e. Code coverage per iteration, number of attendees per demo etc.

These are few metrics which I have in my toolbox. Let me know anything interesting you have tried which has worked very nicely for your team.


Monday, May 16, 2016

How to effectively switch pair when adapting Kanban?

Let me start with little background. My team believes in XP practices and follow them religiously. We also followed Scrum process and use to switch our pair at the end of sprint after sprint review. It was going all smooth till that one day, when we decided to ditch Scrum and adapt Kanban as our delivery model.

We thought we will change pair after each story but stumbled upon issues, since each pair was starting and finishing at different times. We struggled for a while and then came up one idea. We decided to switch the pairs every week and made one-person owner of the story.  Owner took the story with them while switching the pair.

Bingo! Our problem was solved for time being. 


Thursday, May 12, 2016

Lean To the Point Inception for enterprise

I am working for a big retail client and we follow an inception technique which is very lean and effective. The technique is definitely leveraging Eric Ries's Lean Startup and Jeff Patton User Story mapping fundamentals but has been tailored for enterprise need. This technique address few core questions:
  • How to ensure the team starts the project with a shared understanding and an effective plan?
  • How to understand the MVP and start an agile project as quickly as possible? 
This method is based on Paulo Caroli's book called "To The Point".  This technique has some obvious benefits:
  1. It focuses on validate hypothesis based project development - Build, Measure and Lean approach. 
  2. Team comes out of inception with a value associated to every feature.
  3. Team completes higher-level features in less than a week time for a 6 to 9 months long project.
  4. Saves the work/time of breaking down all the projects work in order to get an estimate for project's length/cost.
  5. Entire team get a holistic picture of the product 
  6. Release planning can be done very quickly based on the features
This is a technique to understand and plan for incremental delivery of MVPs. The technique organizes ideas and features in a model that seeks to understand the main purpose of project. It suggests some pre-defined steps.
  1. Describe the product vision
  2. Prioritize the business goal
  3. Describe the main users, their profiles and their needs
  4. Understand the main functionalities
  5. Detail perceptions of risk, effort and business value by functionality
  6. Describe the most important user journeys
  7. Create an incremental product enhancement plan, driven by MVP
  8. Estimate effort by sampling
  9. Calculate costs and specify dates and delivery schedule 
We consolidated above steps in 7 high level categories:
  • Create the product's Vision;
  • Define the product's Objectives;
  • Identify the product's Personas;
  • Discover the product's Features;
  • Associate features to Risk, Effort and Value - Review;
  • Plan the product's Releases;
  • Consolidate Time and Cost.
Lets discuss each step in details:

Project Vision
Somewhere between the idea and the launching, the vision of the project helps team to understand the business value. In our situation project was pretty identified and had a clear goals. Hence I requested our Product Owners (POs) to come up with initial project vision and asked to field team’s questions. Book suggests involving entire team but I would suggest starting with PO if you are building a project, which has been well thought by PO. This saves lots of teams frustration, which we faces during initial adaptation phase of this technique. I would suggest you should engage your team if you are building a product whose scope has not been defined or loosely defined.  It definitely helps team in getting aligned around the product they're building, creating a clear vision of the path ahead. Ask team to think about product vision in below format.

For [final client],

whose [problem that needs to be solved],
the [name of the product]

is a [product category]

that [key-benefits, reason to buy it].
Different from [competition alternative],
our product [key-difference]

Project Objective
Each team member must share what is his/her understanding of an objective for those who use the product, and the several points of view must be discussed in order to reach a consensus on what is really important. This activity helps raising and clearing these objectives.  I again started with PO first and then asked team members to shares theirs objective.  The main aim is to know where project is going, and what it aims to achieve, ensuring a good mix of technical and business objectives are captured.
Once the vision is defined then try group they by similarity and prioritize them collaboratively. To prioritize, answer this question: "If your company only has time and money for one more objective, which would it be?"

Once goals/objectives are captured, do the activity of understanding trade-offs. Trade-off is a trade in which you let go something in order to get another one you want more. A lean product reflects decisions of the team regarding trade-offs. The activity “Understanding trade-offs” helps building and recording a common understanding about trade-offs of the lean product. Many decisions and conversations are based on individual visions and premises between choices. Some examples: what is most valuable: security or usability? And what about performance and security? And usability and performance? This activity promotes an open and collaborative conversation on trade-offs. Clearer trade- offs avoid misunderstandings and help to make decisions quickly.  Below picture is taken from the book to show the outcome of the trade-offs.


Project Personas
 To build right thing that will provide the most value, you need to keep in mind who is using your product, and what are their needs. A persona represents a user in the system, describing not only his role but also his specific needs, creating a realistic representation of users, helping the team to describe functionalities from the point of view of those who will interact with the final product.  Book suggests couple of ways to come up with them. We preferred answering below questions:
·      Who has a stake in our product?
·      What exactly do they need from our product?
     Once you have the list of personas, try answering below questions in groups:

What, I ____ (see / think / hear / say)?

Project Features
Feature is the description of an action or interaction of a user with the product. For example: print invoice, see detailed statement, and invite facebook friends…
The description of a feature should be as simple as possible. The user is trying to do something. The product should have a feature for that. To discover features make your team think about below questions:

What the product needs to do or have in order to enable the Personas to achieve the Objectives?

In a big table or whiteboard, place the cards with Personas as rows and the cards with Objectives as columns. Then, starting from the most important Objective, brainstorm on what features should be built to achieve each Objective. This technique is more like Story Mapping, where you are mapping Objectives and Persona’s need and coming up with actions/features. I am not allowed to share my project real data, hence again copied from the book for reference.

Feature Review
To plan the work and the releases, it's important to understand the levels of risk, effort and value in each feature identified by the team. This is again similar concept like story-mapping, focusing on specific target outcomes is the secret to prioritizing development work. This activity aims to discuss how the team feels according to the technical certainty and the business agreement for each feature.
Create a common canvas, a graphic, in which the axis X represents the technical certainty (how to do) and the axis Y represents the business agreement to the requirement (what to do).

Ask for a member of the team to read a feature out loud and put it on the canvas according to his/her understanding of it (technical certainty and business agreement). 
 Question if everyone in the team share the same opinion. Of somebody disagrees, the team must discuss the requirements and the technology involved in a way that an agreement is reached about the feature. Everything that is mentioned and that helps to achieve a better understanding must be noted and attached to the feature. The picture above shows features in post-its that were glued in green, yellow or pink index cards, indicating low, medium or high uncertainty levels, respectively. 
Repeat the exercise for each identified features.
Create one more canvas, which has Effort (the level of the work that needs to be done) and Value (what is the return or saving that it will bring) as their axis. Rank each Feature with the following options:
The activities Technical Certainty and Business Agreement and Effort and Business Value can and should be held together. In the first activity the feature gets a color. On the second activity, the feature gets two marks. The color represents the feature ́s uncertainty level: Red for a high level of uncertainty, Yellow for a medium level of uncertainty, and Green for a low level of uncertainty. The marks are about effort and business value, and vary on a scale of one, two or three times in comparison to each other; for example E, EE, and EEE. Such color and marks will help the team in subsequent activities to prioritize, estimate and plan.
Project Release Roadmap
Book suggests mapping the User Journey but we moved to release planning after the above outcome. I would say, do what you feel right for your project.
Based on the feature ranking now it’s time to group features together. We focused on creating multiple slices, which has equal balance of risk, effort, and value. Our main focus was building features, which will prove our idea was worth building and we can learn something for future features. We definitely selected sea level features first. Also we tried to make sure each slice can be achieved in less than 3 months and they are almost equal. We focused on measurement pieces of the feature.  This is key exercise and requires lots energy and communication.

Project Budget
We can’t move inch further in enterprise world without telling leadership, how much would it cost J. I did spend few days in Jira learning team’s working pattern by studying control charts and other reports across multiple projects. Based on my observation I created three big buckets. (Small, Medium and Large). We as a team agreed on a time range for each bucket. We start picking each slice and placed each feature into the big bucket. We only did this exercise for first two slices and left the rest of slices as is. Once we had rough timeline it was easy to put together budget for senior management for approval.
We did couple of mini-inceptions with external teams i.e. Risk/Infrastructure/Compliance/Security/Other dependent team etc. and adjusted the notes at feature level based on their feedback. We came up with multiple spikes for our iteration zero at the end of inception close and roadmap for project.

Let me know your feedback.


Sunday, April 3, 2016

Custom Control Charts for deep diving into few fun analysis

I wanted to learn, what 1, 2 or 4 Story Points (SP) means in our system. What better tool than Control Chart to gain knowledge about cycle time around Story Points?

Here are the steps for creating custom control charts:

1) Select your board whose data needs to be analyzed. Click on Board button on the top right corner. Select configuration button underneath.

2) Select the Quick Filters option from the left hand Configuration menu.
3)  Add the filters for which you would like to analyze the data. I want to compare the behavior of different Story Points in our system. Hence added custom filters for each available story points.

4) Select your project from the Projects menu and click on Reports from the left hand side menu.

5) Choose the "Control Charts"
6) Choose the custom criterias for your report: i.e.  Quick Filter (which you added above),  the time period (for which you need to capture the data) and the status. Feel free to tweak anything which makes sense for you. It's all depends upon what are you willing to comprehend from the data.

7) Observe the change in mean and stand deviation. Also chart has multiple data points for one to analyze.

I love control chart. It gives me insight into, how my team is performing. I love comparing theie performance during specific process change or during some experiment I am trying to run. This is very powerful tool and gives lots of insight into the system.

Enjoy deep diving