XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Archive for the ‘Planning’ Category

Use Cases v/s User Stories

Tuesday, April 20th, 2010

At the Agile Coach Camp Goa 2010, we had a small side discussion about the difference between Use Case and User Stories. More importantly, if an Use Case contains many User stories or whether an User Story contains many Use Cases.

According to Mike Cohn, User Stories are smaller in scope compared to Use Cases.

Even Martin Fowler has the same understanding.

IMHO it does not matter. But it’s important to note that when some people refer to User Stories, they really mean the final stage of the User Story. Hence they always say, an Use Case contains many User Stories. In real world, I see User Stories have a life-cycle. They start out big & vague and gradually are thin sliced to executable User Stories. Mike Cohn referes to them as Theme > Epic > Story > Task.

I’m particularly influenced by Jeff Patton’s Work on this topic. Jeff highlights that User Stories really need to be at an User Goal level rather than an implementation level (at least when you start out). Else it would lead to big-upfront-design. Also most users won’t be able to relate to really granular stories. Highly recommend reading his blog on The Mystery of Shrinking Stories.

To understand the overall approach check out his User Story Mapping Slides.

10 Most Read Posts on Managed Chaos in 2009

Friday, January 1st, 2010
  1. Agile (as practiced today) is the new Waterfall
  2. Naked Agile
  3. Biggest Stinkers
  4. Goodbye Simplicity; I’m Object Obsessed
  5. Want to Pair Program and Concerned about Productivity?
  6. Estimation Considered Harmful
  7. Refactoring Legacy Projects: Scaffolding Technique
  8. Single Responsibility Principle Demystified
  9. Primitive Obsession
  10. Cannot Evaluate a Candidate just based on their Resume

Stop Sprinting, Start Minting

Friday, October 23rd, 2009

These days, its common to see teams doing the Product Backlog Management to Sprint Planning t0 Daily Scrums to Reviews to Retrospectives perfectly fine, as described in the book (or the 2 days Certified Scrum Master course). We are doing all the process stuff correctly, except that we don’t seem to be”actually” making money (minting). But somehow along the way, we seemed to have missed the point.

The problem I see is, teams are doing all the process stuff, as they are told, except that, post demo they don’t actually release the software (deploy it into production). Most teams are very happy showing the demos at the end of the sprints. They start thinking that this new process they are following is magical. Until 6 months later, their so-called “Product Owner” comes backs saying I didn’t quite expect “this” this-way and I thought “that” would be “this” and not really “that”. That is when it hits the team that what they were really doing was building inventory and basically doing a compressed-waterfall.

Until you actually release your software and see your end-users actually use it in real life, you don’t have the most important feedback. Hence you are not “done” until you really see you users use the feature you just released (and probably you are not even done after that. “Done-Done” was a cute concept, get over it). There is no better means of feedback nor is there a better risk-reduction strategy other than releasing software to production frequently (at least every week).

Remember code that is not yet deploy and just sitting in your repository is a liability. So is, all your fancy product backlogs and grandiose plans.

Requirements Considered Harmful

Wednesday, March 11th, 2009

In the Second Edition of the eXtreme Programming Explained, Kent Beck writes:

“Software development has been steered wrong by the word ‘requirement’ defined in the dictionary as something mandatory or obligatory. The word carries a connotation of absolutism and permanence – inhibitors to embracing change. And, the word ‘requirement’ is just plain wrong.”

On his blog, Jeff Patton tries to explain why using the word requirement is plain wrong:

  • When faced with challenges or in pursuit of a goal we decide on a course of action
  • The software we eventually build is the compounding of a great number of decisions
  • “Requirement” is a label we put on our decisions
  • Decisions and requirements build on each other
  • Giving requirements stops collaboration
  • Asking for requirements avoids responsibility
  • Requirements come from outside, not inside
  • Stop using that word and start collaborating to solve problems

There are great points. In addition I feel:

Typically requirements for given business problem is derived based on some hypothesis. In today’s dynamic world, where Change is the only constant, those hypothesis can change. So instead of holding on to the by-product of the hypothesis, why not focus on the real business problem that we are trying to solve.

Requirements belongs to the solution domain. Since, there are multiple ways to solve any problem. Prematurely deciding on any one solution does not seem like a good idea. We need to spend time in the problem domain to actually come up with the closest solution.

The word requirements comes from a Target driven planning approach. Target Driven Planning has huge drawbacks that Agile methods try to avoid. Instead they focus on value driven planning.

When ever I hear about Business Analysis capturing the requirements, it reminds me of waiters in a restaurant. In most restaurant, you have a menu to select from, a waiter who will take your order (requirement) and pass it on to the chef (developers). I don’t mean to look down upon Business Analysts or Waiters.

What I’m trying to highlight is, in my experience, the BAs I’ve worked with, pretty much capture what the customer wants in form of requirements. But there is no rationale behind what is the real problem that we are trying to solve. Even if that is understand by the BA, its not communicated to everyone on the team. Do we even need some software for it? Critical questions seems to be missed out.

Also going back to the analogy, I think the analogy is flawed. In software, customers don’t get a menu. Even if they get a menu its in a language they don’t understand and to make matters worst the restaurant is serving a cuisine that the customers have no clue about. How can one possible order stuff without actually having a conversion around what kind of an appetite they have, whether they are in a hurry or not, if they like spicy food or not and so on.

Another Project Rescue Report

Monday, February 9th, 2009

Some time back, I spent 1 Week helping a project (Server written in Java) clear its Technical Debt. The code base is tiny because it leverages lot of existing server framework to do its job. This server handles extremely high volumes of data & request and is a very important part of our server infrastructure. Here are some results:

Topic Before After
Project Size Production Code

  • Package =1
  • Classes =4
  • Methods = 15 (average 3.75/class)
  • LOC = 172 (average 11.47/method and 43/class)
  • Average Cyclomatic Complexity/Method = 3.27

Test Code

  • Package =0
  • Classes = 0
  • Methods = 0
  • LOC = 0
Production Code

  • Package = 4
  • Classes =13
  • Methods = 68 (average 5.23/class)
  • LOC = 394 (average 5.79/method and 30.31/class)
  • Average Cyclomatic Complexity/Method = 1.58

Test Code

  • Package = 6
  • Classes = 11
  • Methods = 90
  • LOC =458
Code Coverage
  • Line Coverage: 0%
  • Block Coverage: 0%

Old Code Coverage Report

  • Line Coverage: 96%
  • Block Coverage: 97%

New Code Coverage Report

Cyclomatic Complexity Cyclomatic Complexity report before Refactoring Cyclomatic Complexity report after Refactoring
Obvious Dead Code Following public methods:

  • class DatabaseLayer: releasePool()

Total: 1 method in 1 class

Following public methods:

  • class DFService: overloaded constructor

Total: 1 method in 1 class

Note: This method is required by the tests.

Automation
Version Control Usage
  • Average Commits Per Day = 0
  • Average # of Files Changed Per Commit = 12
  • Average Commits Per Day = 7
  • Average # of Files Changed Per Commit = 4
Coding Convention Violation 96 0

Another similar report.

What is the Least I can do that is Sustainable and Valuable?

Thursday, January 29th, 2009

Very very powerful thought when starting something!

The Bloat Effect

Tuesday, January 20th, 2009

As time passes by we notice that

  • The Software bloats up
  • The Team bloats up
  • The Process bloats up
  • The planning phases bloat up
  • The Documents and artifacts bloat up
  • Bugs bloat up
  • Team members bloat up
  • The organization bloats
  • and so on….

What we need is some jigging to shake off all those extra fat. Unfortunately organizations adopt the “more the merrier” philosophy instead of “less is more” or “less is beautiful” philosophy.  Why not embrace simplicity? 

Simplicity is defined as “the art of maximizing work undone”.

Iterations are High Ceremony

Saturday, January 3rd, 2009

Myth: If you do iterations or sprints, you are Agile!

Few companies like Industrial Logic, Yahoo,etc and Individuals like David Anderson, Arlo Belshee, Fred George and many more have paved the way for iteration less agile. The Poppendiecks and the Lean community have been a big influence. So its perfectly fine if you think iterations or sprint are high ceremony.

Back in 2003-2004 when I was working on an offshore maintenance project, we got rid of iterations and it helped us great deal. Since then I’ve been on multiple projects where we’ve done Iterations/Sprints and I’ve always felt that we were wasting a lot of time. On some projects I’ve been able to influence the team to get rid of iterations and start focusing on our throughput. And those teams have not looked back since.

But then the question is:

Why does XP and Scrum have the whole iteration/sprint business?

As defined by original Scrum, Sprint is a fixed time box (1 month) at the end of which you deliver working software to the customers. What this really means is you deploy working software that the customer can use. So this is as good as a release. In some cases it might be internal release instead of a public release. Irrespective, I believe that Sprint == Release (some form) as originally intended.

While XP has the concept of iterations and releases. Which means at the end of the iteration you don’t necessarily release software to your customers. But you have a demo at to the customer at end of the iteration. Sometimes a demo is also a working session.

Never the less, as I understand the advantage of having a fixed time box (iteration/sprint) is to take x amount of time when the team is not really disturbed and in return the team commits to deliver x features (belonging to one or more goal). To be able to commit, the team needs to do some form of analysis and estimation to be comfortable with their commitment.

If you talk to Jeff Sutherland about why he decided to have Sprints as fixed time boxes, he will tell you that at that point the developers were constantly being interrupted by their customers/managers, leading to a context switch. This was yielding very poor productivity and lack of focus. The time box addressed this issue by keeping the customers and managers “out of the room” for the time box duration and also helped the developers to set a clear focus on what needs to be achieved.

Makes sense?

So if you don’t really have these 2 fundamental issues (or if you can educate people about them), why would you want to go thru all this ceremony of planning and estimating the time boxes? Esp. when you are not even using these Sprints as actual releases.

The time boxed way of doing things, forces you towards push scheduling. While this model is successful, it has some drawbacks and hence more and more people (esp. the lean software community) is moving towards pull scheduling. Where there are no artificial time boxes. As and when the features are ready (fully tested), they are deployed. We don’t batch a bunch of features (user stories) together as we do in Sprints. Instead we focus on the smooth flow of the features from inception to deployment. Basically trying to avoid waiting time and thus reducing inventory. Also simply applying queuing theory, you’ll understand that smaller the batch size, better the throughput.

In my case the batch size is couple of thin-sliced features. This really helps us keep the focus and we are not unnecessarily spending time context switching. Its important to note that the time it takes to build these features vary hence we don’t try to put an artificial sprint boundary around them. Whenever they are ready (ideally a couple of days), they are deployed. Zero waiting time. In some cases deployment could be internal and in some cases it could be public releases.

I strongly recommend :

    Licensed under
Creative Commons License