Day 11, 2015. A little over a week into the new year, how are you doing, people? Enthusiastic, energetic, excited about your goals, daily workouts, and a lot of items in the bucket list for this year… Its pretty fascinating how gyms and other fitness centers, all of a sudden, see a surge in the number of members… I guess its that time of the year. Even at my gym I have been observing a lot of new faces recently… its a good thing. The unfortunate part is that it eventually dies down. People lose motivation, get entangled with their day to day lives so much that they find it hard to keep up with their yearly goals and resolutions.

Have you ever thought why we are very enthusiastic in the beginning of the year and all this excitement dies down in a few months? One of the reasons may be that its a yearly goal setting. Don’t get me wrong, its a good thing to have a yearly / long term goal and to have resolutions, but how good is it if you cannot stick to it.

One suggestion, try having weekly or monthly goals. For example, if you want to lose 20 lbs in 2105, break it down to a weekly or monthly goal. Something like, lose 8 lbs in January, 7 lbs in February, 5 lbs in March and them maintain it through rest of the year. Or you can even go further to something like better muscle definition or anything for that matter. Break your goal down to smaller executable chunks and give yourself a regular timely FEEDBACK. May be broken down into something like below:

• weigh your self everyday (Daily Scrum),
• plot your progress (burn-down graph),
• weigh yourself at end of second week in January (Frequent checkpoints / Health Checks / Review / Demo)
  • Correct your plan for the next two weeks, in case you are behind (if you have not lost at least 4 lbs)
• weigh yourself at end of January (another check point)
  • Correct again, if behind (if not lost at least 8 lbs)
• And so on and so forth, till end of March.

If we track our progress in such a fashion, there is no reason why we will not be able to keep up with our goals. YES, IT IS REALLY THAT SIMPLE! 🙂

The idea is to SHRINK THE FEEDBACK LOOP… Hence the topic of this article, ‘Show me what you got… and I will give you the feedback’

Food for thought: Is the above approach inspired by Agile / Scrum practices or was it the other way round? Chicken or the Egg? 😉

Sprint Review (aka Sprint Demo) is defined in the Scrum Guide as “time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period.”

Allow me an attempt to break it down to small, digestible chunks…

Purpose: show the work done, progress made, accomplishments, improvements (product or process) in the current sprint and gather the FEEDBACK (positive or negative).

Medium: informal conversation, no PowerPoint presentation, working piece of code and or functionality (depending on the nature of work)

Audience: Customer, all stakeholders, team members, Scrum Master, Product Owner, other scrum teams, management, executives. In short, anyone who is interested in the product the team is delivering in that sprint.

Organizer: Product Owner and/or Scrum Master

Outcome: Acceptance or Rejection of the delivered piece of work, which is determined by several factors, such as quality, change in requirements, change in market, technical dependency, or any external team/product/system dependencies.

Caution Hot! – Outcome is very crucial here, if the piece of work delivered by the team is Accepted, its great. However, in case it is rejected, or if it needs rework, or if it needs to be enhanced, you definitely want to know that sooner than later, so that you and your team won’t invest too much time into it. I’m sure anyone will appreciate a course-correction as early as possible, rather than going too far in the wrong direction, right?

Advanced Practice: Get the feedback at the earliest possible moment. How? Below are a few of the practices that I encourage within my teams:

• peer review of code – better code quality
• QA testing in development environment (even before the code is delivered to QA) – finding issues sooner, saves the cost and time of a buggy build to QA
• daily code drops – smaller feedback loop from QA
• demo to Product Owner as soon as a story is complete (do not wait for the end of the sprint) – shrink the feedback loop from business

Why wait till the end of the sprint (two, three or four weeks), if we can get my feedback today and save time, energy, resources, efforts and money.

Now, will you show me what you got? 😉 

Happy Reading! 🙂

– Nirbhay Gandhi