Agile Tools for Agile Performance

We invest these days in our team, turning it into Agile. This way we expect to bring sooner and better products to market.
We selected Agilo by Agile42 as out task, bug and Wiki product. This a Trac based product that has the following pros:

1. It is based on Trac, so it includes all the common Trac features: road map, bugs, tasks and Wiki in a single product
   
2. It is customized to Agile methodology including:
1. White board (pro version)
2. Sprints, Milestones
3. Sprint Dashboard with Sprint Burndown, closure tickets rate and commitment charts
   
3. It has better UI that Trac
   
4. It has great packaging for instant installation (Trac instant installation can be find in BitNami).
   
5. Its community version is free (it has pro version with several extra features such as white board)

 Some useful info if you turn to Agilo: 

1. Agilo installation
2. Installing Agilo as a Windows service
1.  Download the Windows Server 2003 Resource Kit from Microsoft
2.  Install the service according to MS
3. Update:  Change in run.bat the set VIRTUAL_ENV=%cd% to set VIRTUAL_ENV=%Agilo%. Create the Agilo system variable with a value that matched the path where the run.bat file is located at.
3.  Avoid errors
   
1. "The password file could not be updated. Trac requires read and write access to both the password file and its parent directory": Change TrustedInstaller and Users permissions on the tracenv directory
2. Got "acct_mgr.web_ui.MessageWrapper", well, open the trac.db and run DELETE FROM session_attribute to solve this issue.
4. Control your source code
1. If your SVN is not on the Trac/Agilo machine, you should use SVNSync to make a local SVN read only copy:
   svnsync synchronize http://localhost/svn/project --sync-username slaveuser --sync-password tjohej --source-password password
   c:\Python25\Scripts\trac-admin.exe c:\projects\trac\project\ resync
   
5. Modifications
1. Changing attached user files size for tickets and wiki (Update May 22, 2010) using the max_size parameter in trac.ini.
6. Control your sprint
1. You should add priority field to the task in order to support any prioritization
2. You should add bug association with the sprint in order to see both in the same presentation
   
3. Agilo seperates between bugs and tasks (however, you probably manage both in the same sprint), therefore we created a report that controls all issues:
   query:?status=accepted
   &status=assigned
   &status=closed
   &status=new
   &status=reopened
   &status=review
   &order=priority
   &col=id
   &col=summary
   &col=status
   &col=owner
   &col=type
   &col=priority
   &col=component
   &col=severity
   &col=remaining_time
   &col=drp_resources
   &sprint=SPRINT_NAME

More goodies to follow,

Keep Performing,
Moshe Kaplan

RockeTier Agile Development Methodology

Hi,

We at RockeTier, believe that almost any software system can do better by changing and modifying only a small portion of existing code base.
We proved in several cases that using this methodology you can gain major business value in short time. or in other words Agile.

Therefore, it was only a matter of time before we migrate our development team to Agile methodology (you guess right, our software team develops high load software systems which process hundreds of millions of events per day for our clients). This change enabled us providing business value in shorter time frames.

Our development methodology is based on the following basics:

1. System wide design - the product owner is responsible to provide long term road map for the system, including software architecture, database architecture, middleware, non functional requirements, timeline and so on based on inputs from the client or internal product manager. This is an important component which sometimes Agile evalgelists tends to neglect.

2. Product backlog - product owner is responsible for breaking the long term architecture into business processes. Each business process is analysed, confirmed by the client and used as an input for the sprint backlog. Many times business processes are not complete, but describing current days needs in order to gain business value, knowing that these requirements will be changed in the future.

3. Sprint backlog - each business process is broken into a list of tasks (usually by the programmer). This list is documented in a central repository and being written on the team whiteboard.

4. Daily Cycle Status Review- each day a peer meeting is being handled on 10AM, syncronizing open issues with closed issued, adding high priority tasks (usually bugs)

5. Daily Version - each day on 4PM we upload a new "for review" version which includes all the commited new features added to the software in the last 24 hours.

6. Weekly Version - based on the last week "for review" versions we upload a new version on Wednesday 12:00, enabling our team and the client examine the system before weekend.

7. Quality - We believe that people achieve best results when they are responsible for their products. Therefore, most QA is done by the programmers themselves and the team leader:
- Peer review and pair programming - we often use these methods when developing sensitive components and when time is short, to achieve best quality in short time, and in order to reduce the risks.
- Code review - done by the team leader before a new feature is committed to the SVN
- Code management - we use SVN as company standard, but also consider to use GIT, in order commit (locally on your computer) every change you make that way you can return to any point in time but do not break everybody's code if your changes are not complete. and only when code is ready, commit your changes in svn.
- TDD - we use test driven development to make sure that code is not broken between cycles, and making sure that new changes will not harm current business processes

8. Knowledge management - knowing that sharing a knowledge will help our people gain best results, we opened few weeks ago a new code snippets and best methodologies blog. This is an open blog by nature so the community can enjoy our insights and experience.

We seen a great improvment in our development products since implementing this method including: reducing the needed time to get new people into productivity, reducing error and misunderstandings, reducing time to market and reducing bugs,

Keep agile,
Moshe, RockeTier. The performance experts.