Agile Buddha

Demystifying Agile, Getting to its Core

The Branch Merge Hell Team Lived With – A Bank Agile Case Study 1/n

by 4 Comments


Lots of organizations are desperately trying to bring agility in their enterprise IT. In such cases,  enterprise IT stands on the worn pillars of traditional Waterfall process and legacy products.

The business in such orgs sees IT as a black hole where no business need can escape from inside it. The reason being, traditional process, and legacy systems take months of cycle time to deliver almost any business need.

This results in a frustrated and desperate stakeholders who threaten to try anything or everything under the sun to get tangible outcomes.

This case-study is a story of a bank which was almost on the verge of outsourcing its entire IT. The bank since has moved on to become one of the pioneers in banking innovation space. It focuses to serve its customers every day with innovation and agility in a faster paced competitive ecosystem.
[Read more…] about The Branch Merge Hell Team Lived With – A Bank Agile Case Study 1/n

Collaborative Daily Scrum – Alternate to 3 Questions Based Daily Scrum

by 1 Comment

Rugby Scrum

Scrum is inspired by Rugby Scrum. The entire development team works collaboratively towards one Sprint Goal.

Pretty obvious but still spelling out – Rugby Scrum can never be played individually in a team.

Working solo or without collaboration  (read pair programming, swarming or mob-programming) is not even a choice in Scrum/XP.

With this background in mind, let’s focus on Daily Scrum.

Daily Scrum

Daily Scrum is a sprint planning in small. You replan the sprint every day.   – James Coplien

A lot of Scrum teams use 3 questions based daily scrum. On the surface, it looks good but it comes with some inherent problems:

[Read more…] about Collaborative Daily Scrum – Alternate to 3 Questions Based Daily Scrum

Overcoming Cultural Differences in Distributed Agile Teams – A Case Study

by 1 Comment

Recently I had a discussion with one of my dutch friends who has a company based in India. He mentioned that sometimes it gets very difficult to understand and handle cultural issues with his Indian colleagues. Issues which he mentioned are not new and people from western countries interacting Indian teams must be very well aware of what I’ll mention here. Some examples:

  • One person speaking on behalf of the entire team and other people either keep silent or just reply in terms of yes and no
  • Always saying yes to everything even though even customer may already be aware that the task may be difficult to achieve.

As you investigate further, these instances are very common in the team coming from hierarchy centric cultures where only senior and so-called senior people have a say, while the rest just follow what’s asked them to do.
[Read more…] about Overcoming Cultural Differences in Distributed Agile Teams – A Case Study

If You Need Kanban in Scrum, You’re Probably Doing it All Wrong!!!

by 7 Comments

Rugby Scrum

The original idea of Scrum came from a 1986 HBR article “The New New Product Development Game“, written by Hirotaka Takeuchi and Ikujiro Nonaka. The teams at Honda and elsewhere reminded Takeuchi and Nonaka of the game of rugby and they called this style of project management “Scrum,” a short form of the term “scrummage” where the game is restarted when the ball has gone out of play.

So what’s so significant about rugby scrum?

In rugby scrum, the ball gets passed within the team as it moves as a unit up the field.

Scrum is all about everyone doing everything all the time. It’s an important point to remember as otherwise, Scrum becomes yet another framework with 5 events, 3 roles, and 3 artifacts.

The foundation of Scrum encourages one-piece continuous flow.

So in a Collaborative Daily Scrum, instead of answering 3 daily Scrum questions, a team looks at the Scrum board and plans on how to swarm or mob to finish the top PBI (Product Backlog Item) on the board.

It may happen, depending upon the tasks identified for a PBI, 3-4 people decide to swarm and finish it. And then the rest of the team picks the next PBI.

Daily Scrum is a sprint planning in small. You replan the sprint every day.

If a team is working like this, there should be couple of stories (depending upon size) in progress at any point in time.

So you see, if a team decides to swarm or mob, one doesn’t require to set explicit WIP limits anymore. The disciplinary act of stopping at numerical WIP limits is not required as that becomes part of the system.

The team focuses on finishing existing PBIs before picking anything new.

As we discuss the key idea of collaboration (swarming or mobbing) here, it’s important to understand that the idea of “swim-lane Scrum” (each team member individually taking ownership of a PBI through the stages of the process) doesn’t really work. It blocks the delivery pipeline as any PBI a tester may work on comes after a few days, a week or so.

At that point in time, a tester may get multiple stories to test at once and may become the bottleneck. That kind of scenario is not the ideal state of flow but is more like a Scrumfall in which work arrives in a batch after a period of time.

Kanban Mythbusters Series

There are other posts on Kanban Mythbusters series which you may find interesting

References