There are many different approaches to the process and practice of software development. Each has its own case for adoption, benefits and a group of strong adherents. Generally, if you follow the leading advocates for a particular methodology, you will hear that it is comprehensive in its scope and useful across a wide range of situations. Our Experience At Scio, we have tried many of the core methodologies available today and we find all of them have something to offer, but none of them fit our business model, clients and team without some additions or adjustment. In the final analysis, we have developed a “stack” of methods and processes that take ideas from many experienced practitioners in the field, but fit our situation in a way that is better for our team and ultimately our clients.

The Scio Project and Development Methodoloy Stack

• Systems – Tools do not make projects successful by themselves, but if they are thoughtfully assembled and integrated, they can provide valuable support to the process and reporting.  The Scio team has spent the time to put together an integrated set of tools from the developer’s working environment, through requirements management and reporting. It sounds straightforward, but until recently there have been few systems that would support end-to-end project and developer reporting. Project systems are developed to be ubiquitous and usable in many industries. Software developer systems are focused on code production and task management. There have always been gaps between the two. At Scio, you can be assured of a unified system, tuned to our methodology and our clients needs throughout the project lifecycle.
• CCPM – In the world of project management, Critical Chain, which comes out of Goldratt’s Theory of Constraints, is a fairly new development with field use of around ten years. Critical Chain Project Management (CCPM) is especially useful in planning projects, estimating time and effort, and risk control. It provides a methodology for planning a project that builds on Critical Path and adds risk control the project in a way that creates monitoring and a focus on the progress of the entire project instead of trying to optimize each task and work item individually. This frees project managers from micro-managing each task while it keeps the team aware of “where they are” in relation to goals and deliverables. Scio uses CCPM methods in planning projects and as a part of the overall risk management structure to achieve complete, quality software, on time, within the schedule time and budget.
  
• Agile and Scrum – Once the technical environment and foundation for a project is in place, our teams use Agile and Scrum methods to manage scope of iterations and daily collaboration within the combined project team. We find Agile works well, but to take full advantage of its value, there must be a clear understanding of how the team will manage change and identify functional “bugs” versus changes in design based on a new vision gained during development. Our approach to the methodology is embodied in our user story lifecycle, and our collaborative development practice that in each practice determines how change is managed according procedures agreed on in the planning stage of the project.
  
• Gantt – A “Gantt Chart” is usually synonymous with formal project management, but it is important to understand that Agile by itself does not specify how work dependencies are mapped or project progress is reported. That is a project management function and as such, is outside the scope of the core process of development itself. We use standard Gantt methods and reporting tools to visualize and manage project dependencies and report effort against the schedule and planned deliverables. We find that while we use Agile techniques, that standard and traditional systems of project reporting work best for providing an ongoing view of progress to the project team and our clients.
  
• Scio User Story Lifecycle – Because we run the iterative development of application features as a repeatable process in an agile approach, we call our feature-level deliverables “user stories.” Outside of agile they could as easily be thought of as work packages in a formal project sense. In the nature of projects, each user story is unique but the process of analysis, task breakdown, effort estimation, development, and QA that quality software development requires is consistent. Within the process, there are a number of tasks for roles in the development and client team. The effort for the tasks varies based on the complexity of the user story.  At Scio, we have defined this core process and use it as both a template to plan development and as a quality check to ensure shortcuts are not being taken and quality is not being compromised. The Scio User Story Lifecycle defines our core development process, status, team roles and responsibilities for the cycle.
  

• Lean – The concept of Lean comes mainly from the manufacturing line, but in recent years the philosophy has been adopted as an extension to Agile. Software development, particularly in the case of project work, is by its nature a “one-off” activity because every application is different and solves different problems. But the tasks in the process of developing an identifiable feature are repeatable, even if the effort and emphasis changes from feature to feature. Scio has taken from Lean the ideas of repeatable processes with tasks that produce value, elimination of waste, and quality control and embedded them throughout our methodology.

The results from building this stack and imbedding it in our projects are predictable projects, quality software, informed clients and the value that comes from a partner-level relationship with our clients. We invite you to experience the “client-experience” this approach provides.

To find out more about our methodology, please review our:

• Agile Software Development
• User Story Lifecycle