The Project Structure

Today we had a first go at creating the solution and relevant projects in Visual Studio 2008 to get the framework for writing code. Starting with blank canvas is never easy but fortunately we have plenty of examples around. We looked at the beefy solution we're working on at the moment. It has over 20 project and a deeply nested folder structure - and thus required lots of hand crafting of the solution and project files. We looked at some project hosted on Codeplex like the Silverlight & WPF Timeline Control and most importantly we looked at our draft architecture. Finally, we wanted the projects name and structure to reflect the namespaces they go to. With all this in mind and an hour later we had our first stub at the project structure and the first commit to the repository.

Introducing the LeanAndon project

LeanAndon is an open source implementation of a Scrum/Kanban board written in Silverlight.

First some background

we have been working at an organisation that has been undergoing something of a Lean transformation recently. Projects are mostly Scrum with elements XP, but distributed teams have meant that the traditional Scrum whiteboard and story cards have had limited success.

Fast forward through several months and several different Agile process management tools. Most projects have moved to Scrum Dashboard, a web front end for the Scrum for Team System process template for TFS.

Why did we decide to start LeanAndon?

For anyone working in IT, keeping up with the latest technologies is important, and for us it is no exception. There are few better ways to stay current than being involved in a project that lets us learn some new technologies and help us to really understand Lean Agile principles and practices.

On top of that we have had a chance to experience the best and worst of what is available, and we think we can improve on some of their limitations:

• Web based systems often do not act as a suitable proxy for the physical process, and so the metaphor is lost. The beauty of physical boards and cards is their tangibility. Users can add, change and update with the stroke of a pen. A product owner write out a new user story and see it added to the product backlog in seconds. A developer can pick up a card and take it away to their desk to work on. Often system limitations mean that the interaction with the electronic board and cards becomes an overhead.
  
  • 
    One simple example of where the physical and electronic process diverge is the way user stories and task move through the stages. On a physical board it is the user stories themselves that move through the stages, where as on an electronic board, more often than not, the stories remain static and the tasks move through stages. This has the effect on focusing on the low level tasks, not on the higher level story feature. For example, it doesn't make a lot of sense for a task to be at a stage of 'Ready for test'. After all, the acceptance criteria are against the story, not the task.
• Web based systems are not responsive. Any system that has to rely on an underlying sub system (such as TFS) will have some latency, but it can be made a whole lot less painful.
• Web based systems do not make it easy to perform common task such as product backlog and defect grooming. A tool has to support the things you need to do with it, if not people will not use it. It s as simple as that.

We are aiming to create a first release around the release of TFS2010.