Lorvenk’s software development services team utilizes a tailored version of the Microsoft Solution Framework (MSF) Agile methodology to manage and deliver projects. The Agile process enables Lorvenk to focus on delivering working software that provides the highest business value at all times. Customer engagement and collaboration is key and, employing Agile allows our Clients to see and touch the software at the end of each iteration, typically 2-3 weeks long, which allows us to be highly responsive to our client’s changing needs.
To ensure the solution delivered meets our high standards, all solutions are delivered with our quality testing services.
The Team
We have team members solely focused on the following areas to delivery better software for our customers:
Project Governance
Mainly involved with management of resources, quality, and communication between the client and the team.
Architecture and Design
Responsible for the design of the overall solution and ensuring that design optimally satisfies all requirements at scale.
Development
Develops the line of business solution based on the design and Lorvenk’s software development best practices.
Quality Assurance in Software testing
Performs independent testing, ensures quality and smooth deployment.
User Experience/User Interface
Focused on user interface and usability.
Phases
This model defines five distinct phases for a project. These phases overlap, define what needs to be accomplished and define a goal for quality. When used in combination with Lorvenk’s Agile methodology, these stages are small in scope and performed quickly.
Brainstorm with team about what ultimately needs to be accomplished, identify road blocks and determine how success will be defined.
Architect and design a solution that meets the requirements.
Change management and go-live support associated with taking a software solution live.
Agile Software Development Methodology
The Agile process works well when not all requirements are known at the onset of the project, and there is a need to be flexible to accommodate changes in requirements as the Client learns more about what they need or want in a technology solution. This process allows for changes to requirements to be made throughout the lifecycle of development. Changes are then incorporated at the beginning of each sprint where there is a deliberate and purposeful discussion about the relevant and most current requirements; as long as the Client is willing to make trade-offs regarding priority and scope of requirements, this change process will easily accommodate a need to iteratively develop a working technology solution in a phased approach, continually focusing on the highest priority features.
Managing the work
Agile processes, by definition, employ short, time-boxed iterations called Sprints to define the scope of work that will be completed, and to then complete that work. Each Sprint is 2-3 weeks long and starts with a Spring Planning meeting and ends with a Demonstration of working software, the “Shippable Increment.”
Product Planning
he Product Planning process is a pre-cursor to any development activity. Depending on the scope of the problem and solution this process can take from one to five days of effort. This typically involves all of the members of the team, but can be limited to the Product Owner, Scrum Master, and Team Members who specialize in Business Analysis and Architecture.
The Product Planning process is a pre-cursor to any development and produces the following outcomes and artifacts:
Understanding and documenting the business problem and processes
Problems/limitations of the current solution or process.
A vision for the end state
Developing an initial Product Backlog consisting of User Stories that detail the functionality required by each type of user based on role
If possible each User Story should be assigned a Business Value to help determine the priority for the follow-on Sprint Planning
Each user story should have clear acceptance criteria that will drive both developer testing and our software testing service
SPRINT PLANNING
The Sprint Planning process allows Lorvenk and our Client to work together to prioritize and schedule User Stories in the Product Backlog for development. This is accomplished at the beginning of each Sprint by pulling items from the Product Backlog into the Sprint Backlog. As the User Stories are placed into the Sprint Backlog, Acceptance Criteria are written against the User Story to ensure that developers, testers, and users have a shared understanding of the definition of “Done” for a given User Story. The end result of Sprint Planning is a Sprint Backlog that contains User Stories and Bugs the team will work on until the end of the Sprint.
SPRINT
Throughout the Sprint the Team is continuously updating the User Stories in the Sprint Backlog with effort expended and remaining effort. This provides the information needed for reporting on Sprint progress and the metrics Lorvenk uses to manage its projects.
At the end of the Sprint, a Demo is conducted to show the Client the capability that was built and to get feedback on the implementation.
This provides the Client the opportunity to see and touch the solution.
SPRINT RETROSPECTIVE
The team will continuously be looking for improvement opportunities, and will set aside a period at the end of each sprint to reflect on lessons learned. This period is called the Sprint Retrospective.
Lorvenk approaches this meeting after the demo as a start-stop-continue meeting. Each team member is asked to identify specific things that the team should start doing, stop doing, continue doing With specific items identified the team will decide which items to focus on during the next sprint.
Developing solution
This process involves using tools and Agile development practices to turn the User Stories into functional software. This is driven by the order and priority of the User Stories contained in the Sprint Backlog. Throughout the Sprint, as the User Stories are turned into functional software, the software is tested and evaluated by our developers, Quality Assurance (QA) team, and the Client against the Acceptance Criteria in the User Stories to ensure we are building the right solution. The Team will meet at the Daily Stand-up to discuss yesterday’s accomplishments, today’s planned work and any impediments to getting the work done.
To increase quality and productivity, the Lorvenk team leverages market-leading tools and Agile practices:
Static code analysis tools
Database Source Code Management via Redgate
Deployment packages
Kanban boards for Work Item Management
Unit testing
Continuous Integration
Source Code Management via TFS
Automated UI Testing
Pair-programming
Quality Assurance
Lorvenk incorporates quality into all aspects of project delivery tailored to the type of software product development we are engaged in delivering. Document-based deliverables go through internal review for content accuracy, style, and voice. Additionally, Lorvenk incorporates input from Client via draft reviews throughout the delivery cycle.
Software based deliverables are put through a rigorous independent software testing and quality assurance testing process that involves the following steps when appropriate:
Definition of Acceptance Criteria for software based functionality
Unit testing done at the developer level
Functional testing done by Quality Assurance resources
Automated regression testing intended to streamline the development and deployment process as software based solutions evolve
Software Code Reviews when appropriate
User Acceptance Testing Eliminating all defects from non-trivial software can be cost prohibitive, therefore, Lorvenk monitors the costs and effort associated with resolving defects to keep those costs within acceptable tolerances and Lorvenk company standards.
