In our last post, we discussed about how to break performance measures into team and individual measures to bring more team behavior orientations into appraisals. 

Today, let’s talk about addressing other two issues: feedback frequency and how to make feedback effective.

continious feedback

Agile thinking is based on building frequent feedback loops within your teams and organization. Few examples of frequent feedback loops are:

  1. Sprint demos every couple of weeks, to get product feedback
  2. Sprint retros to get process and tool feedback
  3. TDD/BDD/continuos integration to get code feedback
  4. Continuous testing to get quality feedback. Check-out our new launched 2 day extensive workshop on agile way of testing

Hurry and Read the rest of this post!

{ 0 comments }

It’s well known fact that physical Scrum Boards provide many benefits over their electronic counterpart.

With physical boards current sprint state is transparently visible to anybody in the team and to the stakeholders. As a team member you no longer are required to explain someone what exactly the team is focusing on right now as anyone can look at physical board at any point of time. Also, during standup, story-card and sprint progress get more attention than individual progress. You can setup your physical board the way you want and you don’t have to work around the limitation of any electronic tool.

card-wall

Hurry and Read the rest of this post!

{ 3 comments }

Appraisals! How many of you dread this word? This is the only time in the year that you get to bargain for salary increments, everyone end-up negotiating to their best. Appraisals are closely connected with salary raise/increments, bonus payouts and it’s feedback intent takes the backseat.

Performance Appraisal

There are three major issues with traditional approach to appraisal:

  1. Measuring and rewarding individual behaviors and contributions OVER team based measurements.
  2. Long appraisal cycle(mostly once a year) discussing both salary increments and feedback.
  3. Feedback process – Filling long appraisals forms with least discussions between reviewers about reviewee.

Hurry and Read the rest of this post!

{ 1 comment }

We discussed about committing fixed number of story points and swapping any additional scope with existing backlog in our previous post “Agile for Fixed Bid Projects“. This is a great way to maximize value with minimal change in timelines and budget. This works well when there is a trust existing between product and engineering, and client/product team understands this agile approach. Still, fixing size, undermines one major aspect of an agile team – “applying learning back into the project”. Development teams while doing size estimation give higher points where there are uncertainties and risks.  Known unknowns, new technology, unclear requirements etc. are few reasons for providing higher story points. As project progresses, teams get more knowledgeable (both technology and business) and hence some tasks now look smaller than before.

Agile Contracts

Hurry and Read the rest of this post!

{ 0 comments }

Agile for Fixed Bid Projects

by Shrikant Vashishtha

The basic premise of Agile methodology is to develop software in an incremental and iterative fashion based on regular feedback that is received at the end of each sprint (i.e., 2-4 week cycle). The resultant feedback of a sprint demo often translates into change, and Agile methodology has a key tenet around embracing change.

The question that confuses software professionals for a while is – how to accommodate changes in fixed-bid projects where scope, money and time are fixed.

iron-triangle

So is it even possible to work in a fixed bid Agile mode? And if so, how?
Hurry and Read the rest of this post!

{ 5 comments }

Readers, Our “Agile Thinking” series is focussed on bringing agility into our thinking as this helps in moving from Doing-Agile to Being-Agile. You can read our earlier article in this series Agile Thinking: Stop Starting, Start Finishing.

This post talks about continuous improvement and obviously this can be applied everywhere irrespective of it is a process, practice or a role. From my recent experience, I would like to share today, how ScrumMater (SM) role evolved in some of the companies.

In many organizations, ScrumMaster role is defined something similar to what is shown below. For conversation sake let’s call it as SM 1.0 (see pic below)

ScrumMaster

In service industry projects,  SM’s playing the role by book (SM 1.0) and expecting Product Owner(PO)  from the client side to write stories, acceptance criteria and prioritization did not work due to some of the reasons stated below.

Hurry and Read the rest of this post!

{ 5 comments }

Limiting “Work in Process” (WIP) items is one of key ideas of Kanban. A natural outcome of it, inherently coming from Lean philosophy is to stop starting and start finishing.

By having too many work in process items, it looks like everybody is busy but there is no functional outcome for the end user. So, instead, it’s important to work towards completing the user-story.

From the outset it looks like, “Stop starting, start finishing” philosophy is limited to Lean and Kanban world. Scrum world is either doing it well or doesn’t need it. Right?

Wrong!!!

finishing-line

Let’s take a look at a typical Scrum standup.

Hurry and Read the rest of this post!

{ 9 comments }

Scrum and XP have been working well for small teams. That works fabulously for small organizations. However implementing the same for large project portfolios, having teams with 100+ developers has remained very challenging from organization perspective.

There are many challenges while working with large teams like:

  • Breaking silos/departments in large organizations
  • Requirements focused on changes in enterprise architecture
  • Ability to work on highest business value features for program portfolio instead of for a project
  • Eliminate waste and reduce cycle time for the whole value chain
  • ..and more

They can be mitigated by seeing scrum as organization design framework and using lean principles. In this session Shrikant will share his thoughts on how Scaled Agile Framework (SAFe) is used to solve this problem. We will take references from Spotify Scaling Case Study, SAFe and personal experiences.

Date: Feb 19th, 3:00 – 4:00 PM IST

Register Now!

{ 0 comments }

Teams are obsessive towards better customer satisfaction and rightly so. High team throughput is one of the important ingredients towards better customer satisfaction. Before we move further, let’s look at what throughput means in business context. According to Wikipedia:

Throughput can be best described as the rate at which a system generates its products / services per unit of time.

In order to achieve better throughput, it’s implicit to look inwards, within the team. However some improvement areas may lie in external quarters. Product Ownership is one of those areas. In this blog, we’ll look at some of issues in Product-Ownership which may have massive impact on team’s throughput. We’ll also look at some probable solutions and their relation with “Definition of READY”.

Hurry and Read the rest of this post!

{ 2 comments }

During sprint planning, scrum teams often face this challenge of sprint commitments. How many stories can we commit in this sprint? How to plan for the team capacity?

I ask teams to do commitment driven planning during early stages of scrum adoption.  For you to commit to a sprint goal, you need to know current team capacity. Team capacity is calculated as per people availability in that sprint.

Capacity Planning

Let’s take an example.

Hurry and Read the rest of this post!

{ 5 comments }

Scrum Teams: Slow Down, to Go Fast Later

by Avienaash Shiralige January 7, 2014

Being two months away from my passion – agile coaching, I was exploring my other interests like un-schooling my kid, learning by traveling, and spent time experiencing natural birth. I was wondering if I should share this experience on this blog which is focussed only on Agile. But being agile is about doing different experiments and […]

0 comments Hurry up and read the full article →

Story Point Mapping with Hours – Key Ingredient to Burnouts?

by Shrikant Vashishtha September 8, 2013

This is based on a true story of a project I was involved in and that was also the first ever Agile projects I worked on. As I came from straight from waterfall background and didn’t have enough Agile experience, it made a lot of sense to us to map a story point with number […]

14 comments Hurry up and read the full article →

When BDD (Behaviour Driven Development) may not work?

by Shrikant Vashishtha September 2, 2013

For quite some time there have been talks on using BDD in order to have: Better collaboration between Business Analysts (BAs), developers and testers. A common domain language for functional testing and for defining functional acceptance criteria, which everybody in the team understands. Why BDD? BDD offers following advantages: Ability to write test cases (scenarios) […]

4 comments Hurry up and read the full article →

Drive Innovation By Creating Communities of Practice

by Avienaash Shiralige August 30, 2013

In my last post, I discussed about sustainable pace and how nation and organisation culture comes in its way. One of the issues often found is people on scrum teams being too focussed and busy on the projects and having no time for their own research, self-study, upgrading themselves on new things etc.  This leads to lesser […]

2 comments Hurry up and read the full article →

Sustainable Pace: Does Culture Play Any Role At All ?

by Avienaash Shiralige August 12, 2013

  Striving to bring agility into the organisation to adapt to changing business conditions is leading people to lose sleep and stretch more than before in some organisations. Agile thought leaders definitely envisioned this and hence recognised sustainability as one of the agile principles.   To run a long distance you need to find a […]

10 comments Hurry up and read the full article →