Should my Org/Team move to Agile?

Naturally, I’m tempted to answer “YES” to this question as I wear my Agile Coach hat at work. As I pay close attention to the person’s conversation, what he/she is really saying (screaming inside) is bunch of fears such as

  • Fear of failure
  • Fear of change
  • Fear of moving out of comfort zone
  • Fear of learning curve
  • Fear of wrong decision
  • Fear of transparency
  • Fear of losing control
  • And it’s so easy to give orders or follow orders J

So, when you want to convince your boss or your customer to go Agile, ask what challenges they think that exists currently with their organization or team. It’s much easier to focus on solutions and start that conversation when people acknowledge that a problem exists.


Just enough, just in time specifications

One of the best practices of Agile/Lean development is just enough, just in time specifications.  But this is often times misunderstood by teams and harder to align by business.

So what is a specification anyway? It’s a software feature required to meet the vision of the product. It talks about what but not how. It talks about the experience by customer rather than a database table or a technical framework.

Then, what is just enough, just in time specification? Well, let’s look at this case. If there is a steel manufacturing plant, how much raw material (inventory) should the plant hold? Should it be sufficient for next one year or for next few weeks? Of course it’s for few weeks, but with the expectation of continues supply of raw material. Before the raw material turns to steel, it goes through various stages, for heck of it, let’s say, when it’s in the earth’s ore, its 0.5% refined, after 1st treatment of the ore, its 25% refined and so on and so forth till it becomes a state when furnace can spit of the desired quality steel.

Even product backlog should be treated as inventory. It has ideas, concepts and specifications which are refined at various levels.


Now, the problem is when PO comes up with a new requirement during planning meeting for the upcoming sprint, he/she and the team should be aware how refined the requirement is.  If you see all items directly end up in “Fine Grained” state, then you know it’s not evolving. This usually results in lot of readdressing existing which could have been easily avoided.

To sum it up, Just enough, just in time specifications should be part of an evolutionary process and will work of both team and business understands the level of granularity of the requirements.

Slicing Features – Part 1

I was part of “Slicing Features into playable stories” session by Tarang Baxi in Agile 2012. Case studies Tarang presented were very effective in emphasizing the principles behind Slicing features into stories. Let me try to put down two case studies which he discussed.

First one was about an ipad app to allow users (travelers of an airline) to complete check in online via their ipad’s. This app is intended to support users in 12 countries. Also, most of biz logic is shared with website and other mobile apps which mostly is already in place.

General outline of the requirement was something like this

  1. Initiate check in
    1. Ability to search  via last name,PNR
    2. Show a reminder letting user know that his flight is open for checkin (sort of check in notification)
    3. Login into account and use a dashboard page which displays booking  history (My Trips) and check in button next to it (both already in place)
  2. Check in info
    1. Passport info etc for international travel
    2. Each country has its own UI layout e.g. Japan has last name then first name
    3. Country specify information if any
  3. Extra / check in luggage
  4. Add ons
    1. On board meal
    2. Wifi
    3. Upgrades
  5. Payment for add on’s or luggage
  6. Seat selection
  7. Check in and send boarding pass based on user option/input Via email or To ipad

Now the question is what’s the best way to slice stories out of this feature (check in feature)? Product owner also mentioned that most revenue generating piece is obviously “Add ons”.

Principle: When slicing user stories, always ensure you get one thinnest slice end to end. In this case, first story team should focus on would be to get a base minimum flow to complete check in.  It could look something like.


I’ll talk about next case study in my next blog.

Agile Transformation – Part 1 [How and Why Agile Check ]

Agile is the buzz word these days. Everyone is talking about it. Interestingly many organizations / teams think they are agile. As Pekka Abrahamsson says, Agile is a non defined term, so it seems to be everything or nothing. There is no line to say if you cross that you are opposite of agile. Agile or Agility is a positive term everybody wants to be associated with :) . Being Agile is a journey, not a goal.

This series of blogs will try to touch up on few aspects of agile transformation. Recently, I was talking to a team which said they can’t be Agile (or follow SCRUM) because they are working on legacy code and they can’t have good unit test coverage or builds on every check in etc. The team was under an impression that if they following a couple of XP practices they would be agile :) . This kind of misconception is equally true at management levels who perceive Agile / SCRUM to be a silver bullet to solve all of their problems.

Why to Transform

Organizations need to have a clear vision why they want to “Get Real Agile!”.  In my opinion, there are 2 key goals why an organization / team should go for an agile transformation.

  • Identify and effectively address challenges with their current base ground.
  • Increase efficiency/ effectiveness by changing organizational / team working structures to increase predictably, adaptability and happy peopleJ.

Common challenges I hear with traditional processes

  • Project timelines are missed.
  • Product quality concerns.
  • Project runs over budget.
  • Unsatisfied customers.

Agile Check:  Where do you stand now?

Agile transformation should be done iteratively. For this, we need a backlog of activities to deploy Agility / SCRUM into organizations.  This backlog is created (of course bound to change during deployment) during “Agile Check” with a cross section of the organization. Typically I conduct “Agile Check” with a group of 10 to 15 people which consists of managers, developers, QAs, team leads, architects etc.

Start Agile check with a stand upJ. Instead of a typical stand up, it’s about Name/Role, expectations from Agile check and anything they foresee going wrong during Agile check. This gives a fair idea of  mine as well as audience’s expectations.

Run a retrospective of their current process / structure. I like to give 6 post it notes to each individual, and ask them to write 3 positive points and challenges they currently face, one point on each sticky note.

Make groups of 3 to 4 people, don’t propose groups, instead, let me them arrive at it. Once they form groups, ask them to discuss among themselves and pick 3 positives and challenges at a group leave.

Each team presents their list then and a consolidated list of formed. Help them to arrive with top 5 positives and challenges from the consolidated list. I usually do it by voting. Each member gets 5 votes for positive and 5 for challenges. Each member can put his/her votes against the list based on what he/she feels important.

Now, we have a list of things that are working well and things to improve. Sometimes it requires some discussion around the same, but usually this is the time I give an introduction to SCRUM. Depending on the audience’s Agile exposure, this session’s focus ranges from explaining “Why Agile/Scrum” to core principles, and mapping them to retrospective list.

SCRUM Deployment backlog creation:

By now, groups would have understood what challenges they have, and how Agile/ SCRUM would help in addressing them. Ask teams to think about various activities which they feel are required to deploy SCRUM in their environment. Once every group has a list, help them to come up with a prioritized list. Usually I ask everyone what should be the first step. For e.g. someone would say, training is the first thing, someone might say, identify pilot project or management commitment. After this exercise, we end up having a prioritized backlog for SCRUM deployment.

That’s it, objective of Agile check is accomplished! A prioritized backlog for SCRUM deployment is ready.

Of course, once this is done, there is a management meeting when we identify and Agility Stakeholder, who owns this backlog and agree upon timelines, pilot project etc.

So this blog is about How and Why Agile Check. Stay tuned for more!