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!

{ 4 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!

{ 1 comment }

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!

{ 4 comments }

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 never stopping, hence I thought its worthwhile to mention it here.

It was great spiritual learning for me to prepare and experience natural(spiritual) birthing. It really taught us how different is our body than we actually perceive. To trust our own body instincts to take its own course of action rather than relying on systems(hospitals) which was built to address emergency scenarios and not normal or natural phenomenon like birthing.

This decision to slow down or cutting myself completely helped me to understands different facets of me. Slowing down helped me reassess my priorities and how I need to take my life forward. My schooling system has taught me how to make a living, NOT a life! Pity.

Scrum Teams Slow Down

I was recently connecting with few teams and I saw teams “racing to the goal post” with NO goals scored often. Seeing such teams I feel we are used to speed in every aspect of life. Not sparing a thought to slow down to see how are we doing? And, even if we do that, we’re unable to bring any noticeable changes.

Hurry and Read the rest of this post!

{ 0 comments }

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 of hours for obvious reasons. We mapped story point with ideal hours. Initially things went well. However after a few months, we started getting into difficult waters because of following problems:

We began to witness clashes among developers over estimations. As story point was mapped with number of hours, it directly mapped with the skill of a developer. For instance, a senior developer could finish a user-story in 2 hours. Another not-so-skilled developer or new-in-the-team developer could finish the same user-story in say 8 hours. That started causing planning meetings with clashes, disagreements and also spurts of indirect bullying from senior guys. As a result, not so experienced developers started spelling similar smaller estimates even though it caused them to work longer hours. As it was a distributed augmented team, we also started witnessing lack of trust within team because of those reasons.

Also customer didn’t see any significant change in team velocity even though productivity improved multi-fold. “YOU ARE NOT PRODUCTIVE GUYS…”
Hurry and Read the rest of this post!

{ 14 comments }

For quite some time there have been talks on using BDD in order to have:

  1. Better collaboration between Business Analysts (BAs), developers and testers.
  2. 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) and acceptance criteria before performing any development. This whole idea is termed as Acceptance Test Driven Development (ATDD).
  • Provides a common domain language, which everybody across the board (developer, tester, BA and business) understands. As at the end it’s plain English, it’s simplest to learn compared to other DSLs (domain specific languages).BDD example
    bdd-sample
  • Helps in eliminating waste by minimizing handshakes. If you take a look at the above-mentioned example, testers and BAs can write a test or acceptance scenario using a BDD template (highlighted in Yellow) with plane English

Developer/tester can then fill in the blanks, i.e. implement the test case using programming language or script.

Writing text doesn’t require any IDE like Visual Studio or Eclipse. The test/acceptance scenario can be written in a Notepad too and then pushed to Version Control System, which is then picked up by developers/testers to implement.

As BAs, developers and testers work only one single source of truth (BDD test), it minimizes the handshakes and reduces waste. Also it is well understood by everyone as test-scenario is in plain English.

Hurry and Read the rest of this post!

{ 2 comments }

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 learnings from outside world and limits the growth of people.

community of practice

don’t be afraid to fail.

be afraid not to try.

Introducing or rather planning slack time on the team gives free time for people to work on their pet projects. Different organisations have done it differently, like:

  1. Giving a break between sprints
  2. Following 80/20 principle, 20% free time for people to think and work on their interest
  3. One free day in a month
  4. Having a small time reserved every sprint

Hurry and Read the rest of this post!

{ 2 comments }

 

Sustainable pace

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.

 Agile processes promote sustainable development.  The sponsors, developers, and users should be able  to maintain a constant pace indefinitely. 

 

To run a long distance you need to find a sustainable pace. But often, companies just don’t get this due to various reasons like:

  1. Pressure from business and management to get most work from least people
  2. Team not having an option to make their own decisions – command and control culture
  3. Teams inability to say NO for non-realistic goals. Service industry firms –  they just can’t say NO to unreasonable client demands
  4. Utilisation of people – Planning for 100% utilisation. This makes people work for more than required hours and hence getting burnout
  5. Unable to remove distractions to the team. Lot of unplanned, non-essential meetings taking people’s time. Questioning motives and saying NO is essential here.
  6. Allocating people on multiple projects with allocation distributed 20%,50%,30% etc. This does not work in reality. There is a switching time between two tasks and people take around 15 mins to achieve FLOW (high productive zone)

Hurry and Read the rest of this post!

{ 9 comments }

Agile Testing: An Approach to Achieve Quality Sooner

by Avienaash Shiralige July 17, 2013

Often I hear from testing folks one question. How can I apply Agile for testing? Local optimisation has been the bane of software development – viewing it from his/her activity perspective and not just as a whole. Let’s see how agile principles can be seen through testing angle? Image Source: www.testobsessed.com Tweet

0 comments Hurry up and read the full article →

Agile is Not Ad hoc

by Avienaash Shiralige May 19, 2013

Recently, I was asked to attend a leadership meeting in a company. They had representations from different business units and groups. When we hit the topic of agility within the organisation, one of the directors immediately jumped into the conversation and said his projects are very agile in nature. That made me curious and I […]

0 comments Hurry up and read the full article →

Metrics to Build Great Agile Teams: Measure Influence, Not Control

by Avienaash Shiralige April 30, 2013

Couple of weeks back, I noticed an incident that triggered this post. Senior Management in a company applauded people for showing individual heroics on the project. Some of them were: Staying late in office to address a client request? Responding to project emails at late night.. Rewarding testers on number of bugs found and more. […]

15 comments Hurry up and read the full article →

Story Points and Man Hours – When To Use Them and Why?

by Avienaash Shiralige March 28, 2013

The debate about why story points why not time goes on wherever I go for conducting coaching workshops. Hence I thought of sharing few more thoughts today. Previously we had sizing techniques like Function Point Analysis, but it was tough to understand/implement by everyone and hence was restricted to experts ONLY. But estimation is an […]

4 comments Hurry up and read the full article →

Story Mapping and/vs Process Maps

by Shrikant Vashishtha February 12, 2013

One of the key philosophies of Agile software development is to have information radiators visible on the wall so that the progress of the team as well as what team currently is working on gets clearly visible to anybody who visits to the team area. That includes stakeholders, project managers, team or anybody from the […]

11 comments Hurry up and read the full article →