Kanban

I found this excellent article while researching Kanban, Lean, Agile, etc.

Lean development came into focus for me after a comment by Adam Monago about how they were using Lean internally at ThoughtWorks Studios. What I particularly latched on to was the concept of a work pipeline that was continuously being balanced rather than a product backlog + iterations + release plan + estimation pain, etc. (these are my inferences, not Adam's statements)

Given that back ground, the one of the appealing statements that Karl Scotland made in his article was:

The consequences of using a kanban system are that the Product Backlog can be eliminated, because the immediate queue is the only work of interest, timeboxed iterations (i.e. Sprints) can be eliminated, because work is pulled as necessary, and estimation can be eliminated, because work is not planned into iterations.

Does Scrum Work?

Good read.

Does Scrum Work?

How to Improve as a Software Development Team?

Joel Spolsky has some interesting ideas, but one I want to focus on in this note is his "12 Steps to Better Code"

• Do you use source control?
  
• Can you make a build in one step?
  
• Do you make daily builds?
  
• Do you have a bug database?
  
• Do you fix bugs before writing new code?
  
• Do you have an up-to-date schedule?
  
• Do you have a spec?
  
• Do programmers have quiet working conditions?
  
• Do you use the best tools money can buy?
  
• Do you have testers?
  
• Do new candidates write code during their interview?
  
• Do you do hallway usability testing?

I plan on focusing on these points over the next few weeks here at TransCore, in the 3Sixty FM Client team.

Functional Specifications

 

I'm researching Functional Specs.

 

As usual, Wikipedia has a good overview with lots of good links:

http://en.wikipedia.org/wiki/Functional_specification

 

Excerpts:

"A functional specification does not define the inner workings of the proposed system; it does not include the specification how the system function will be implemented. Instead, it focuses on what various outside agents (people using the program, computer peripherals, or other computers, for example) might "observe" when interacting with the system."

 

And:

"In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed"

My main source of good information is Joel Spolsky (again).

Painless Functional Specifications:

• Part 1: Why Bother
  
• Part 2: What's a Spec?
• Part 3: But... How?
• Part 4: Tips

My take-away?

Functional specs should be easy to read, evolutionary documents that help you think through the design and workflow of your intended application.

Development should not start while there are open issues.

On the other hand, the document should not be considerd 'done' until the project is feature complete.