Scrum

Sustainable Pace: Does Culture Play Any Role At All ?

Striving to bring agility into the organisation to adapt to changing business conditions is leading people to lose sleep and stretch more than before in some organisations. Agile thought leaders definitely envisioned this and hence recognised sustainability as one of the agile principles.

[pullquote] Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. [/pullquote]

To run a long distance you need to find a sustainable pace. But often, companies just don’t get this due to various reasons like:

Pressure from business and management to get most work from least people
Team not having an option to make their own decisions – command and control culture
Teams inability to say NO for non-realistic goals. Service industry firms – they just can’t say NO to unreasonable client demands
Utilisation of people – Planning for 100% utilisation. This makes people work for more than required hours and hence getting burnout
Unable to remove distractions to the team. Lot of unplanned, non-essential meetings taking people’s time. Questioning motives and saying NO is essential here.
Allocating people on multiple projects with allocation distributed 20%,50%,30% etc. This does not work in reality. There is a switching time between two tasks and people take around 15 mins to achieve FLOW (high productive zone)

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.

100 Practices to Form Your Dream Scrum Team

by Avienaash Shiralige 12 Comments

Today I would like to share few practices that I have seen working wonders to teams following scrum. Not all the practices are followed by all the scrum teams. But by and large you see highly successful teams has many of them from this list.

Below is a mind map which you can download to see in it a bigger view or click zoom after you click on the image to see larger view.

I would like to hear from all of you regarding what else you would like to add to this list or modify any of them. Depending upon your feedback I will update this diagram and share updated version of this for everyone to use.

On purpose, I have not included XP practices just to keep focus only on Scrum.

What practices you would like to see or have experienced in your dream scrum team? Please write to me in the comments section.

Scrum Team Dependency on User Experience/Wireframes

by Avienaash Shiralige 7 Comments

Dependency management is a key aspect in Scrum. Dependencies between Scrum team members, between User Stories, between core and extended team, between team and product owner – all have an impact on the efficiency and effectiveness of the team.

I often see Scrum teams having dependencies on User Experience/Web Developers. This is because PO has defined requirements for new sprint, and UI/Web-Developers who are part of development scrum team start working on this now. Wire-frames are yet to be created as per these requirements.