Agile Buddha - Page 18 - Demystifying Agile, Getting to its Core

Agile Principle: Simplicity – The Art of Maximising the Work Not Done

Simplicity at work – I h’ve always wondered what does this mean to me, to my team and to my organization. In my quest to know more, I asked this to many Agile Coaches and enthusiasts on various groups.

In this post, I like to share what I understood and gathered from my interaction with these people: Steve Ash, Charles Bradley, Lynn Shrewsbury, Ruud Rietveld, Philip Ledgerwood, John Hebley, Jeff McKenna, George Dinwiddie, Adam Sroka, Michael James, Matt Anderson and Cass Dalton.

[pullquote]Simplicity is the ultimate sophistication. ~ Leonardo da Vinci[/pullquote]

Decluttering is a consequence of Simplicity. Simplicity leads to:

Decluttering of products.
Decluttering of your mind. Not being manipulative – being honest, open and trustworthy.
Decluttering your workspace, working in open spaces.

[pullquote]Scrum philosophy of working in small teams, small sprints, small stories imbibe simplicity thinking – Thoughtful reduction.[/pullquote]

The desirability of simplicity is sometimes expressed as the KISS Principle.

Do today only what you absolutely need to do today. No ‘future-proofing’. No ‘gold-plating’.
Achieve Just Barely Good Enough (JBGE). JBGE is actually the most effective possible.

Thanks to Scott Ambler for sharing this term JBGE. You could read more about this in my earlier post Agility is About Identifying and Achieving “Good Enough”

There is a point in time when any additional effort put into work product will increase its cost without increasing its value. If not zero, the increase in value may be insignificant compared with the increase in cost. This is the point to stop! (Achieving JBGE).

Distributed Scrum Teams: Never End a Sprint on Friday

by Avienaash Shiralige 15 Comments

Scrum team members know that things get very busy near the end of an iteration. The coding and quality activities need to be wrapped up, demo preparation occurs, the sprint review is held, the sprint retrospective is held, and the next sprint planning meeting is held.

If the onsite team team prefers to end iterations on Friday, they might naturally assume they have all day Friday until evening for these activities.

However, look at what that would do to a remote sub-team in India – it would mean working until early hours on Saturday morning. A better practice is to split the end of sprint activities across two days, ideally during the overlap time dedicated for sub-team synchronization. This insures minimal impact to normal working hours at the end of each sprint.

Distributed Scrum: A Day In The Life Of A Distributed Team

by Avienaash Shiralige 4 Comments

In my earlier post on “How to Address People and Communication Challenges on Distributed Scrum Teams” we discussed about importance of communication in building trust. Quality and Quantity of communication needs get amplified as soon your team gets distributed.

Distributed teams I have worked with have organized their schedule and overlapping hours some thing like below.

Distributed Agile: How to Address People and Communication Challenges

by Avienaash Shiralige 12 Comments

The main challenges of Distributed Agile revolve around People, Information sharing / Communication, and Project Structure.

Let’s talk about first 2 challenges and how to address them. I wrote an article couple of weeks before on “10 Best Practices of Distributed Agile“. You will find few more practices in that article to address below concerns.

People

[pullquote]Effective, honest communication and trust is the foundation of all Agile teams. Most productive development teams thrive in an environment of trust.[/pullquote]

Half or more of your development team is distributed across continents. How do you create that all important environment of trust and alignment to common vision when your team is distributed?

Your development team (onshore + offshore) now consists of engineers whose primary language is not English, or at least sounds different than your version of English. It adds another complexity to communication.

Cultural, tone and body language differences will compound the challenge. Multi-shore Agile requires changes to the norm. The best environment is when all developers (local and remote) feel part of the larger team and make decisions for the benefit of the single team. But how do you do this?

5 WHYs: Positive Root Cause Analysis To Find Good Practices

by Avienaash Shiralige 3 Comments

In my earlier article I shared my opinion about using 5 WHYs to find root causes. What I really missed to point was, it is not just applied to find root cause to problems, but it can be used to find root cause to good things that are happening on the team.

In sprint retrospectives we usually pick some problem that occurred, try to figure out why it happened, and then understand how we could prevent this problem from happening again in the future. Our root cause analysis meetings are usually always on “What is That Not Going Well”.

Now let’s apply 5 WHYs thinking to this question…