Archive for Agile Implementation

When Should You Implement Scrum or Agile?

Posted in Agile, Change with tags , , , , , on August 19, 2009 by vikramadhiman

Are there circumstances that are more favorable for implementation of Agile and Scrum and ones that are not very favorable for its implementation. Generally, the ideal conditions for implementation and spread of Agile/ Scrum in an organization depend on the market and customer scenario, rather than the development team scenario. Some such factors or conditions include:

  1. Unclear product direction or a research oriented product – the fact that the direction is unclear, makes you plan only for a small time in the future, when you reassess and reorient
  2. Too many changes/ feedback too often in the product – again this means that you take the minimum [agreed, clear or consensus] work – complete it – get feedback and move from there
  3. Competitive industry/ market scenario – this generally would mean you have to get the features out to the market sooner rather than later as well as have more customer connect in the product [some will argue this should be the case anyways]

There are some factors at organizational end as well, which can impede/ aid the Agile Implementation. For instance, if there is no management buy in, or team buy in or worse if there is no customer buy in [in service industry scenarios]- it will be hard if not downright impossible to implement Scrum, Agile or any other framework. In addition, where a deliberate slow and assured pace is mandatory [think software for nuclear reactors or space ships] – there might be significant overhead. Hence, small increments or sprints might not be possible in such a scenario. Turning, this around, you should go all out to implement Scrum or Agile, if:

  1. There is a relative buy in at all ends – customer>>management>>team [not necessarily in this order in all organizations].
  2. The cost of a single bug is very high.
  3. Everyone understands or make attempts to understand what is Scrum or what is Agile.

When you combine the outside [market/ customer] conditions with inside [organization] factors – you get a ripe condition for implementation of Scrum or Agile.

Scrum Exposes Bad Processes and Obstacles

Posted in Agile, Retrospectives, SCRUM with tags , , , , , , , on December 19, 2008 by vikramadhiman

In our last post, we discussed the Agile Retrospective technique of Start, Stop, Continue or SSC. In this, post we discuss a technique first tried by Pete Deemer [CST, co-leader of Yahoo’s implementation of Scrum].

Often, as the end of a sprint, the team comes back and says things like

  • Its more stressful in Agile
  • Things are worse than before
  • Agile does not work
  • We were better off before

If as a Process Coach or Scrum Master you hear something like this, you can try this in your retrospectives:

  1. Ask the team to collectively come up with a list of things they thing are better than before/ is working well and also what is not working well/ worse than before. So, you have two lists : Better and Worse.
  2. Now ask each member to mark each item on both the lists from three possible options : Caused by Scrum [C]/ Agile, Exposed/ Made Visible by Scrum or Agile [E], Does not relate to Scrum/ Agile [U].
  3. Compile the score and let there be pin drop silence in the retrospective.
  4. The team may find a lot of C’s on the “What’s Working Well or is Better than Before” side of the board, and a lot of E’s on the “What Could Work Better or What is Worse than Before ”; this is good news, even if the “What Could Work Better” list is a long one, because the first step to solving underlying issues is making them visible, and Scrum is a powerful catalyst for that.
  5. The team’s opinion and acceptance of Agile/ Scrum would have undergone a complete 180 degrees turn.

It is often useful to keep a snapshot of the whiteboard where these lists are maintained and keep revisiting them in each of the Retrospectives. This is especially useful for the teams which are transitioning to Scrum or Agile way of working.