Agile Stand Ups

Agile Stand Ups

The stand up is a great way to have daily communication between team members. There has been much written about how to do a stand-up, but there are two ways. 

The most traditional way is to have each team member answer these three questions:
  • What tasks have you worked on since we last talked?
  • What tasks are you planning to work on next?
  • Is anything getting in the way of finishing the work as expected?
Another popular way, especially if you have team members that do not like to share, is to "walk the board." You have the board shared, whatever tool you use for tracking, and discuss the status of user stories in each swim lane. 

Traditionally, you have two problems with teams and stand ups. 

There is The Lottery.  In short, there is the danger of teams choosing the weakest link, and a blaming situation occurs. There can be underperformers. And teams do have to hold people accountable. But you have to treat people with respect. Leave the people problems to HR.

The other problem is No Exit. There are some truly dysfunctional teams. Hopefully, a little meditation can help people get along. Sometimes not. 

One way to help teams is to follow Agile principals. Following this is not a remedy for all, but remembering the limited scope of a stand up can avoid confrontations. 
  • How do you judge success? Working software. 
  • Welcome changing requirements
  • Business people and developers must work Together! 
  • Technical excellence and simplicity (not mutually exclusive)
Just some ideas.

Comments

Post a Comment

Popular posts from this blog

Agile Communication

Agile Communication From the 12 principals of the Agile Manifesto The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. In our group, get up and talk to the developer, business person. Or pick up the phone. Skype. If you absolutely have no other recourse then tag them in a user story. Email is for documenting. Elevating to management. Of course, to elevate is to admit you cannot take responsibility to solve a problem... so be cautious http://agilemanifesto.org/principles.html Communicate in code! This has multiple facets. First, write clear code. Another way to think of this is by doing code reviews. Our team does!  https://smartbear.com/learn/code-review/agile-code-review-process/ Today in history... August 23 The World Wide Web was introduced! Talk about communicating!
Read more

Optimistic Locking

Optimistic Locking  For Rails We had the challenge today for making forms behave well with Optimistic Locking with a rails application. Overall, this is built into the Rails eco-system, with the subtle difference in the way errors are handled. Which is to say poorly. Although this seems to be a problem at the Controller level, this is really related to the model, and the data persistence layer. Hence we chose to use a Concern to provide a method to handle the error gracefully.  We included this new concern in any model necessary, and now our apps handle this elegantly. Quick Code Glance: module OptimisticLockingNameMe   extend ActiveSupport::Concern   def update_with_opt_lock_validation(*args)     update(*args)     rescue ActiveRecord::StaleObjectError       self.lock_version = lock_version_was       errors.add :base, "This #{self.class} has modified while you were editing."       cha...
Read more