The document summarizes the software process at FountainPark, which consists of two sub-processes: Software Development (SD) and Software Process Improvement (SPI). SD is based on the agile Scrum process and involves product planning, release planning, sprint planning and execution. SPI aims to continuously improve the software process through characterization, goal-setting, improvement selection, execution, evaluation, and packaging future improvements.

1. FPWiki - Software Process http://devel.fountainpark.com/phpwiki/index.php/SoftwareProcess
Software Process
Our Software Processes currently consist of two sub-processes: Software Development (SD) and Software Process Improvement (SPI) process.
Software Development (SD)
Our SD process is based on Scrum (http://www.controlchaos.com), an agile, lightweight process that can be used to manage and control software
and product development using iterative, incremental practices. Values behind the Scrum process are:
1. Commitment: Be willing to commit to a goal. Scrum provides people all the authority they need to meet their commitments.
2. Focus: Do your job. Focus all of your efforts and skills on doing the work that you'va committed to doing. Don't worry about anything else.
3. Opennes: Scrum keeps everything about a project visible to everyone.
4. Respect: Individuals are shaped by their backgrounds and their experiences. It is important to respect the different people who comprise a
team.
5. Courage: Have the courage to commit, to act, to be open and to expect respect.
Product planning (workproduct: product backlog)
Product development ideas (new features or enhancements) are collected from users' feedback or face to face ProductDevelopmentMeetings ? and
entered to the product specific ProductBacklog ? as UserStories. About four times in a year FountainParkPartners ? discuss and finally decide by
voting how resources will be shared between different product development projects.
Products are developed in an iterative, incremental way. Implementation of the new features are break into releases and releases are break into
three or more 7-28 day development sprints. Each sprint (a.k.a. iteration) produces new working version of the software (a.k.a. increment) for internal
regression and acceptance testing purposes.
Release planning (workproduct: release backlog)
1 of 4 5/6/07 22:24

2. FPWiki - Software Process http://devel.fountainpark.com/phpwiki/index.php/SoftwareProcess
User stories are prioritized in a ReleasePlanningMeeting ? using AspectBasedPrioritySorter ? application by the ProductOwner ? and
ProductDevelopmentTeam ? . Set of the most important user stories are selected to be implemented in the next release. Selected stories are then
classified to must, should and could have classes. Classification expresses how important it is to have each of the stories implemented in the next
release.
Sprint planning (workproducts: sprint backlog, reviewed release backlog)
Product owner and Product development team helds a SprintPlanningMeeting ? before starting a new sprint. In this meeting they decide which user
stories will be implemented in the next sprint, refine selected user stories into technically specified Tasks ? , estimates effort needed to finish the tasks,
defines acceptance tests for the tasks and assigns each tasks to one of the team members.
After the first sprint, release backlog will be reviewed by the product owner in each sprint planning meeting. If business needs have changed, new
must have user stories have appeared or it looks like we cannot finish all the must and should have user stories selected for the release until the
deathline, the release backlog will be reprioritized. To protect the product development team's peace of mind and quality of the product, scope of the
active sprint will never be changed!
Sprint execution (workproduct: product increment, software development process increment)
Implementation shall conform to all relevant (coding style, product architecture, etc.) conventions. Task statuses and effort estimations shall be
updated daily to the software development management system. All product development team members are required to keep Skype client running
24h/7d, keeping it visible while working and reading backlogs from the time they have been away. Developers shall immediately report obstacles
preventing them from working efficiently to the product development manager. Developers are encouraged to independently arrange a face to face
user story and user story implementation review meetings whit the users. Sprint progress is reported shortly in a product development team's daily
ScrumMeeting ? and discussed more extensively in a product development team's weekly face to face ProductDevelopmentTeamMeeting ? . Sprint
progress can be followed anytime from the software development management system's automatically generated reports.
2 of 4 5/6/07 22:24

3. FPWiki - Software Process http://devel.fountainpark.com/phpwiki/index.php/SoftwareProcess
When the sprint is finished, product owner, product development team and relevant users or customers of the product have a SprintReviewMeeting ?
where all the new feature of the product are demonstrated. Change requests and other issues raised are attached as DevelopmentTaskNotes ? to
the tasks in the software development management system. After each sprint product owner and product development team have a
SprintRetrospectiveMeeting ? where they discuss what went well and how software development process could be improved for the next sprint.
Software Process Improvement (SPI)
SPI is a continuous, iterative project that aims to incrementally develop software process. Development ideas are first discussed in the
ProductDevelopmentTeamMeeting ? or SprintRetrospectiveMeeting ? and then moved on to the SPI project's backlog as user stories, if they need
somekind of real implementation work. ProductDevelopmentManager ? is responsible to prioritize and implement or delegate implementation of the
SPI user stories. We use the best practices of the agile development processes (Scrum, XP, etc.) as a roadmap and the Quality Improvement
Paradigm (QIP) as a process model for our SPI efforts.
3 of 4 5/6/07 22:24

4. FPWiki - Software Process http://devel.fountainpark.com/phpwiki/index.php/SoftwareProcess
1. Characterize and understand the state of our current process based on our experience, existing models (Scrum, XP, CMMI...), experts'
insights and discussion. Maintain the documentation of the current process (this document).
2. Set goals for the improvements and make them measurable, so we can assess the the success of the improvements in the forthcoming SPI
discussions.
3. Choose processes, techniques and tools for improvement on the basis of the improvement goals. Discuss about the execution plan and
document it (SPI blog).
4. Execute the improvements, collect experiences from executions, analyze results of the executions, introduce improvements to users, collect
first-hand reactions and write down lesson learned from execution (SPI blog).
5. Analyze results of the improvement project in real use. Use quantitative statistics (success metrics defined earlier) and qualitative feedback to
evaluate the success of current practices, determine problems and make suggestions for future improvements.
6. Package and store improvement propositions to SPI project's backlog as user stories.
See what has happened from SPI-EventLog.
SPI establishment project:
from 2004-10-25 to 2004-12-23: SPI-Iteration1 "Software process establishment"
Last edited on May 31, 2007 7:42 pm.
4 of 4 5/6/07 22:24