Transactions without Transactions
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Vikas Hazrati on Apr 21, 2009
The daily stand-up meeting helps the team to reflect on the progress of the team's commitment towards the iteration goal. It is supposed to be a fertile ground for the team members to make a commitment to each other about what they aim to achieve in the day and identify any obstacles to progress. Though, conventional stand-ups bring a lot of benefit to Agile teams however, many Agilists believe that the conventional stand-ups break down quickly as the team size increases.
Dave Nicolette mentioned that,
The scrum-of-scrums approach worked well provided there weren't enough teams to require more than one level of depth. We started to have logistical problems and communication break-downs once the overall project size reached roughly 25 - 30 people, divided into agile-sized teams. Proponents of the scrum-of-scrums approach say it scales linearly, but in my experience it has not done so. Instead, the relative amount of overhead to manage the meetings seems to increase with the depth of scrum-of-scrums meetings. Teams that need information about other teams seem to be pushed farther and farther away by this structure, too, and we start to experience some of the same sorts of communication problems as we did in the pre-agile days, when most communication was indirect.
Jason Yip mentioned a similar issue with larger teams, according to him,
With large teams, daily standups are more prone to the problems of low energy and lack of engagement. It's just too easy for the meeting to drag on and people to be apathetic in the large crowd.
David J. Anderson mentioned that though there is nothing stopping a large team from doing a stand-up, however, it does not evoke the same team feeling and the peer-pressure aspect of a scrum stand-up meeting is completely missing.
Dave also mentioned that in a larger group the tasks are not discussed coherently. Instead, they are dependent on the order in which the team members speak. As a result, it is easy to lose focus about the task.
Corey Ladas also added his concerns about the communication strategy in Scrum of scrums for larger teams. He mentioned that the Scrum of scrums would create a deep hierarchy as you scale up, which is un-scaleable and not very lean.
So what is the most effective way of doing stand-ups for larger teams?
Dave suggested a ‘Walk the task board’ format of stand-up. According to him, he setup a task board for the team. Instead of the team answering the standard 3 questions, team members moved stories around the task board according to their individual understanding of status and issues. This gave a concrete view of the work being done or held-up at a story level and reflected the progress of the project. A similar post on InfoQ, mentioned story focused stand-ups as a viable alternative to people focused stand-ups.
Jason Yip mentioned a Fishbowl dialogue format for conducting stand-ups for larger teams. According to him,
In this [Fishbowl dialogue] format, you have representatives from each smaller team in a circle in the middle with the rest of the group observing around them. The smaller number of participants actually talking means it is much quicker and because the representative is being watched by the rest of their team, it's less likely that you get mistranslation or filtering.
In practice, this form still doesn't prevent any particular team within the larger group to be disengaged from the process and share nothing. But I still find it more energetic and engaging than a massive stand-up.
Brian Marick's suggested an Actor Network Theory standup approach, which is again focused on the stories. In this format instead of going around people, the teams step through the stories in play. For each story a team member can mention what happened to that story yesterday, what’s going to be done on it today, and whether there are any risks to its completion.
Thus, some Agilists believe that practices like Scrum of scrums can only scale to a certain extent. Large teams need an alternative format for doing effective stand-ups which can be completed quickly. Story based stand-up sounds like an effective alternative for larger teams. What has been your strategy for a large team?
Case Study: IBM's Agile Transformation
A practical guide to choosing the right agile tools
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Several weeks ago we transitioned from the 3 questions to Dave's "walk the board" concept. It has provided a lot of positive changes to our standup. We are always focused on business value and deliverables instead of individuals. Based on our type of work and focus, it was a great improvement over the "standard" approach.
Kevin E. Schlabach
agile-commentary.blogspot.com/
If you are curious about my experiences walking the board, check out: agile-commentary.blogspot.com/2009/04/walking-b...
I described my experience on evolving the daily scrum (and Scrum of Scrums) for a large program in this blog post:
agiletips.blogspot.com/2009/05/three-stages-of-...
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
3 comments
Watch Thread Reply