Agile Buddha - Page 9 of 23 - Demystifying Agile, Getting to its Core

#noprojects with Cross Functional Feature Teams

Sometimes #noprojects (deliver continuous change successfully without using a project) approach alone may not be enough for a software product. This is especially true for large enterprises where any valid business outcome requires close interactions of multiple software products.

In such cases, problem is how to resolve dependencies among software products. First approach which is also very common, is to agree upon a software interfacing contracts between software products. Each individual team then work in isolation while keeping other team’s software contract in mind. When done, teams integrate pieces together.
[Read more…] about #noprojects with Cross Functional Feature Teams

Which Agile Metrics and Why? Introducing Basili’s GQM Approach

by ShriKant Vashishtha 4 Comments

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

Sometimes people just look for an available or known set of metrics and then add more as and when they discover anything new. But does it really make sense to try and apply those known metrics to any scenario?

Why do We Need Software Metrics?

by ShriKant Vashishtha 3 Comments

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.

Mind the gap: Engineering Teams in 21st century, Management in 20th century

by Avienaash Shiralige 3 Comments

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….

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.

Distributed Agile Patterns : Define Overlap Time

by ShriKant Vashishtha Leave a Comment

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?