Agile

When KISS Backfires

ShriKant Vashishtha · April 18, 2012 · Leave a Comment

I started working in software projects when C++ was the only highly popular programming language. There used to be a lot of focus in writing optimal programs or routines. So though the applications were optimal, they suffered from Waterfall mindset of thinking distant future nobody was clear on – “What if…in future…”.

Design patterns and C++ Idioms were new and that led people writing complex programs for the heck of applying patterns in the applications. Some “what if…” used to generate a lot of waste. I still remember a software project which was continuously and consciously designed for internationalized database just because what if we need to setup our company in a country like China. For years a lot of effort and money went into developing and maintaining internationalized datasets. At the end when the need really came, people realized that the same system doesn’t fit in China because the way thing works over there. So a lot of hard work simply became waste.

Agile came and along with that engineering practices Extreme Programming became mainstream. The learnings from Waterfall days gave birth to some principles which made a lot of sense in Agile perspective.

So “Keep It Simple and Stupid (KISS)” made a lot of sense to the developer community which has already seen many overengineered products and a lot of waste coming just because of “what if…” syndrome.

[Read more…] about When KISS Backfires

Worldwide Distributed Agile Team – Some Thoughts

ShriKant Vashishtha · December 23, 2011 · Leave a Comment

Question: How do you think we can handle Agile approach with a worldwide distributed team (Latin America, US, France, UK, Germany & Hungary)? I can have developers at one location, but not Product Owner nor QA team. Any experience to share?

Answer: Try using ATDD where QA creates the acceptance tests at the beginning of Sprint. ATDD which is based on FitNesse or BDD. QA/BA along with Product Owner writes the test cases and developers have to implement their code in order to satisfy the acceptance criteria. This QA sits along with product owner. Apart from that have regular testers also on each distributed location.

Use Skype group video or Google+ hangout for distributed meetings. Use sync.in to write stuff simultaneously from distributed sides within the meeting.

Have collocation between the distributed teams which are going to collaborate together. That is required to have a good personal bonding. As you said, you can have developers can be at one single location – that’s a good idea. Otherwise multiple distributed teams and then multiple time-zones are very difficult to handle.

Have local as well as distributed standup. Make sure that the entire team is working on shared user-story, shared code-base and people use distributed pair programming.

4 Agile Practices for Waterfall World

ShriKant Vashishtha · October 23, 2011 · 16 Comments

It’s pretty usual to see people from Agile world keep on bashing the Waterfall methodology because of its inherent problems. To be honest, a big majority of the organizations still work in Waterfall mode. So sometimes I used to think, why can’t people in Waterfall world do improvement in the way they do things. Though organizations are switching to Agile, you can’t deny that people have delivered a lot of successful projects in Waterfall too.

In this blog, I am not into bashing mode but would like to ensure that people in Waterfall world benefit with some of Agile practices without changing the inherent nature of methodology.

What Motivates Scrum Team?

ShriKant Vashishtha · October 21, 2011 · 2 Comments

Effectiveness of Scrum based team depends a lot on motivation level of team members. It’s important to understand the factors which motivate a Scrum team irrespective of the background of Scrum Master/Project Manager.

I this post first I will focus on the reasons of de-motivation. If we fix these problems, I see no reason why people are not happy in the team. The points mentioned below are based on the experience of working with multiple project as developer, Scrum Master and Agile Coach. Please feel free to add more based on your own experience.

Why Incorrect Agile Adoption may Invite Burnouts?

ShriKant Vashishtha · October 17, 2011 · 2 Comments

Before moving to Agile I worked with Waterfall for around 10 years. Throughout those years I could see people working day and night in development phase. Sometimes teams used to work from 9AM-8PM rhythm non-stop even without knowing why are they doing so.

Whenever product was shipped to customer or whenever any critical production problem occurred, it was quite usual and at the same time pitiful to see team staying entire night to fix the issue.

I heard the word burnout many times. I could see the signs of fatigue on the faces of some people but apart from that I never could understood what burnout actually means.

So here is a story.