With my last post, it is clear that metrics are important to tell you the transparent truth of software delivery. The question still remains – which metrics should I use and why?

Which Metrics and Why

Sometimes people just look for available or known set of metrics and then add more as and when they discover one.

With that it sounds like – they are trying to fit in those known set of metrics to any situation. Does that make sense?

Let’s go back to our analogy of metrics with health checkup. Do you congregate a set of tests and fit them in for any scenario? That doesn’t seem to work.

Instead you look at the problem you are suffering with and accordingly doctor suggests a set of tests. So for diabetes doctor suggests blood-sugar test and for fever a set of tests to verify what kind of fever it is.

If that’s the case, why should we search for metrics. Instead it sounds like, we need to first define problem-statement first.
Hurry and Read the rest of this post!

{ 0 comments }

Why Software Metrics

Humans mostly have a tendency to go by their gut feeling. At the same time, machines mostly don’t tell a lie as their only job is to emit the necessary information.

That’s the reason people like me are scared of weighing machine as that could break the myth of my handsomeness :) . Your family may be insisting you to go for full body health check up, but many fear from them as well.

Those tests will transparently tell you if anything et-all is wrong with your health. If yes, you may take corrective actions. Many people don’t go for them as they don’t want to hear bad news about their health.

You see, truth many times is beyond perceptions and feelings. Something mechanically or electronically measured is beyond feelings and is sheer truth.

Like a health checkup, software projects should also be checked for the performance of their vital organs (parameters). So that if something is wrong, that could be fixed.

Now someone may misinterpret the first Agile Manifesto tenet “Individual and Interactions OVER Process and Tools” in form of “Individual and interactions INSTEAD OF process and tools” and say, “Hey! We are doing Agile. So we don’t need Metrics. That’s so old age!”.

However truth can’t be fictionalized as has been proven in many Lean Startup experiments. Without facts, there can’t be any validated learning. Without validated learning, you never know whether your MVP is good or not.

In software development as well, one needs facts to validate the vital parameters of project delivery.

{ 1 comment }

Quite often I get to see engineering teams – upto middle management being new to agile, are ready to give it a try. But they have real problem on hand that is – coaches asking them to:

  • Embrace change from business and at technical practices level
  • Question traditional approaches of development
  • Do some planning not much
  • Do some analysis not much – leading to analysis paralysis  and list goes on…

But engineering teams have to give their management:

  • Long term plan
  • Have to commit to project estimates at the start
  • Accept all the scope changes keeping time almost same and goes on….

Culture gap

Saying “NO” to unrealistic expectations, scope and time is biggest cultural change. We see it so often. You can read more about this in my earlier post Sustainable Pace: Does Culture Play Any Role At All 

One of the biggest myths in the industry or mis-understanding is:  “Agile is for engineering teams”. It is engineering team who has to adopt to agile way of working to deliver sooner than they were doing earlier. It is them who have to accept changes from business. This kind of agile implementation fails miserably. Even business must be ready to accept surprises or changes from the engineering team. If engineering teams hit a roadblock and unable to deliver few stories(assuming product team was informed timely) then management should try to accept this. Business must be flexible to accept change.

Hence embracing change is both ways. Management can not be practicing traditional school of thought like “I want everything by this time” – “command-and-control behaviours” and expect their teams to be fast, agile and flexible.

{ 0 comments }

Distributed Agile teams are reality these days. For sure there are overheads. But it’s all about trade-off between ‘distributed Agile overheads’ vs combination of availability of talent at any given time, scaling teams at will and lower cost.

Communication overheads are mitigated through phone/Skype/hangout calls with screen-share. It’s usual for people to do remote pair programming. However many times, collaboration fails.

Distributed members/stakeholders are not available in time. Work, which could be finished within hours takes days/weeks of cycle time in to-and-fro communication. Product Owner is a busy person all the time. Getting hold of her becomes a very difficult task.

How to mitigate these challenges?

Hurry and Read the rest of this post!

{ 0 comments }

top-secret2 (1)

People move to Agile, go through required training and start working in projects. After a period of time, if you ask any team member, “what exactly is Agile?”, she’ll start talking about Scrum ceremonies, embracing change, shorter feedback cycle etc. Even after implementing all these aspects, you’ll find issues in that project.

Why?

Hurry and Read the rest of this post!

{ 0 comments }

We all know biggest risk in the product development is building a WRONG product. There are numerous examples from history to see why some products did not see light of the day or big success.

Recently, I came across a product team which took MVP approach and built a product which saw very good initial success. But with time product was unable to keep the users engaged and convert initial success to revenue to keep it floating.

lean-startup-model

Some of the questions the team started to deliberate were:

  • Is this a good product idea but a targeting wrong market segment….? OR
  • We are in right user segment but not a right product/idea – the one which does not solve user problems completely.

Hurry and Read the rest of this post!

{ 0 comments }

elephant-blind-men-600px

Implementing Agile in a big enterprise is not an easy task. The metaphor I sometimes use for big enterprise is to compare it with Elephant. It’s very easy for a small living being to move and maneuver. However when it comes to elephant, it requires time to build momentum and when it actually moves, it moves slowly.

People involved in Agile transformation get frustrated because of all perceived delays. Frustration is understandable but not sure if much can be done other than understanding the simple reality that you are dealing with an elephant and not a tiger or mouse.
Hurry and Read the rest of this post!

{ 0 comments }

Scrum_Days_vs_StoryPoints
As long as customer isn’t interested in throughput or customer trusts the team, whatever way you size or estimate doesn’t really matter. But that doesn’t happen very often. Whenever customer questions about team throughput, it becomes challenging to answer using hour-based estimation as time taken to complete any particular task deflates over time.

Some teams follow capacity based estimation technique where they identify the number of hours available in a team for the entire sprint duration. Based on that they pick up stories in a sprint. Again here as well, there is absolutely no way to know any change in team throughput as size for which capacity is defined isn’t defined.
Hurry and Read the rest of this post!

{ 0 comments }

Repeated software-development tasks are becoming automated through the application of Continuous Delivery and DevOps. If developers are taking more and more testing responsibilities into their hands, I wonder what will be the role of traditional (manual **only**) testing and testers moving forward?

newspapers-are-dead

Hurry and Read the rest of this post!

{ 10 comments }

A while back, Henrik Kniberg published an excellent case study on Scaling Agile @ Spotify. Though case study is specific to Agile scaling experiences at Spotify, some practices are equally important for smaller teams as well. This post tries to capture the essence from smaller team’s perspective.

Break Silos

A lot of organizations still works in functional silos.

For instance, in a bank, there may be one team for web banking, another team for home-loans and yet another one for mainframe based core-banking. Business features however in general cut across all these teams.

Hurry and Read the rest of this post!

{ 0 comments }

Continuous Inspection Session on YouTube

by Shrikant Vashishtha July 10, 2015

Last month I did a session on “Continuous Inspection – How to define, measure and continuously improve code quality?” in DiscussAgile conference. The session is available on Youtube now. Enjoy and feel free to ask questions related to the subject. Buffer

0 comments Hurry up and read the full article →

Agile Thinking : How Can I Help You ?

by Shrikant Vashishtha July 5, 2015

One of the key fundamental elements of Agile is its focus on delivering a testable or demonstrable end-to-end functional slice that provides business value. This approach is the key catalyst of some behavioural, cultural, and structural changes. As a product owner, I am interested more in the working functionality of a product rather than the […]

0 comments Hurry up and read the full article →

Scrum Backlog: Epic, User Story, Acceptance Criteria

by Avienaash Shiralige June 8, 2015

Often, I get to hear questions about level of details that need to go in the product backlog stories.  How detailed should be the acceptance criteria? or how small the story should be? We all know stories matures with time. I really like this post on user story life-cycle. Please take time to read this. […]

3 comments Hurry up and read the full article →

Specification by Example | Behavior Driven Development | ATDD – A Google Hangout Interview

by Shrikant Vashishtha June 2, 2015

Recently I got interviewed by DiscussAgile on a topic known by several names, i.e. Specification by Example, Behavior Driven Development or Acceptance Test Driven Development. Here’s the Google Hangout recording available on YouTube. Following topics got discussed as part of interview: Why to do ATTD? How to do it? What skills are needed to do […]

0 comments Hurry up and read the full article →

Distributed Agile Patterns – Presentation @AgileIndia2015 Live

by Shrikant Vashishtha May 27, 2015

This year I delivered a presentation on “Distributed Agile Patterns” in Agile India conference held in Bangalore based on different patterns evolved or discovered during my Agile journey. The video is available now. You may want to have a look and provide your feedback. Buffer

0 comments Hurry up and read the full article →