Pages

Thursday, August 12, 2010

Does your daily stand-up stand up for you?

What’s a daily standup?
An important daily practice of various Agile teams is having a daily short team meeting. It is known as standup in XP terminology, or daily scrum meeting in SCRUM terminology. Well, it may be called anything depending upon the flavor of Agile methodology you use, the points which are discussed during a standup (we're going to use the term, standup, henceforth) are:
  • What you did yesterday
  • Problems you are facing at the moment
  • Your agenda for the day
Of course, you should jump in if you can benefit from or offer help to the person taking the turn. However, the most important part is to take it offline if you see it as a long and less-relevant-to-others discussion.

Why is it important?
This discussion helps form the basis for pair rotations considering skill sets of people, durations for the pair, and the objectives for each of those new formed pairs. A daily standup eases the intra-team communication, facilitates progress tracking, compensates for the lack of documentation, and also, it keeps a check on people who otherwise would sit idle entire day procrastinating the task at hand (Yes, there are such people present).

What are the challenges?
With so much of goodness of this indispensible practice, it is quite commonly visible that the projects don't get benefited to the entirety. Therefore, following few points make it very important for the team to achieve the benefits of a standup


Teams not understanding the spirit of the practice:
People fail to understand how the standup is actually shaping their lives if they individually haven't experienced its importance. This applies to many people, for instance, to those who have been working on a particular bit alone having not a lot of interference from peers, e.g. sometimes the API developers who work to the specs. In a huge enterprise application, few people work on view layer and need to have interaction with UI designers and sometimes with service developers. Similarly, the people working on Database design may have to interact continuously with architects and designers (especially if an ORM is being used). People who are working independently may sometimes falsely believe that they don't need to attend to standups since no one is going to help them – they are just working to specs.
Remedy: Educate people about importance of the practice or hire people who are suitable for agile. Any methodology can work only if its values and principles are well absorbed by its followers.


Long duration of a standup:
A standup is held having all the members standing on feet just to make sure that people finish their speech quickly, failing which they would be tired and would wish to run off to their desks. However, people having a lot to say sometimes seem to forget that their speech is tiring others out.
Remedy: Ideally, long discussions should be taken offline after throwing in enough clues into their standup speeches. Failing this, such discussions make others withdraw interest and stop paying attention.

Large size of the project team:
More people, more speeches, and more time spent during the discussion. Also, not all the people are always genuinely interested in listening to each single word everybody has to utter.
Remedy:
  • This can be avoided, limiting ourselves to say something like, "finished writing xxx() method to allow customer to view further details." People who are interested in this can speak to you personally after the standup.
  • In some cases, dividing the team into smaller teams can just help your standup achieve its goals.

Boredom listening to irrelevant speeches:
Again, occurs to people who are not much interested in others talks. E.g. the members of the business team are not into technology and can find technical talks very much boring.
Remedy: A smart project manager can avoid this making the talks interesting, stating the mapping of what the technical guy spoke with an appropriate business requirement, sometimes cracking few one-liner jokes and keep the odd men's interest alive.

Friday, July 23, 2010

6 Reasons Why a Wizard Is an Important UI Element



Among several ways to accept inputs from users, wizards are one of the popular UI elements. Not only the wizards offer simplicity of use, they are quite useful from the perspective of maintaining flow in a user interaction. Here are 6 reasons why you should consider using wizard when you need to accept a lot of input from the end user:

  1. They maintain the flow of user to reach a defined goal, e.g. installing a Windows based software. The objective of the entire wizard is generally (it should be) mentioned in the first screen of the wizard (as well as in the Help section if there is one). The idea is to make the users aware of the outcomes of their actions they should expect. This helps them decide whether they want to go ahead with it or not.

  2. Sets of related inputs are displayed on different screens. This avoids:
    • Cluttering of interface
    • Providing too much information on one screen and offering too much to read
    • Intimidating users with too many inputs to enter on one screen
  3. The smaller sets of inputs reduce possibilities of errors because of less information required at one stage, and because all the inputs to be provided are linked with each other. This also allows users to comfortably forget what they did in the previous screens.
  4. A wizard keeps the user engaged by displaying the progress being made in stages. Users often like to know the current stage they are at as well as any other pertinent information around their actions by that point.
  5. The most obvious and common information is already populated across screens. Therefore, a user can keep clicking the next button on most of the screens and still reaches the goal defined for the wizard.
  6. Importantly, the capability to click Cancel at any stage in the wizard and not letting any changes take effect unless the user wants, is what ensures that user can have a demo of all stages of the wizard without changing anything. This is particularly important in case of wizards on the Web pages. Quite often, you see websites requiring you to fill forms before you move on, but alternatively, you can navigate all the way through the wizard, view every stage, and then, decide if this was what you actually wanted. This results in a great user design in many cases!

Like all other UI elements, using wizards also suffers from its own downsides, and should be used with a careful consideration of alternatives.