Best Practices

Best Practices

---

Requirements Definition

We believe in a just-in-time, just-enough level product of analysis and definition, utilizing the following process:

• The Product Manager or Owner, along with the Product Owner or Product Owner Peer and UX Designer will develop the prioritized backlog of user stories that will serve as the basis for development planning during the Implementation phase.

• For stories requiring a user-interface component, user research will be conducted to define the prototypes will be built in lieu of lengthy written requirements.  Prototypes will be supplemented by other visual models where necessary (e.g. state diagrams, class diagrams, sequence diagrams), graphical visual designs, and supplementary written functional requirements (e.g. business rules) if necessary.

• For stories with a light-to-no user-interface component, functional requirements will be documented, including the use of visual models.

Typically, functional requirements and user-interface designs will be elicited and documented in the sprint prior to planned commencement of development, and reviewed with necessary stakeholders throughout that sprint. 

We test continually throughout development, and our stories are validated within the sprint before they can be considered "done".  

Developer Testing

Developer testing covers unit and integration testing. Unit tests are run automatically and after every code check-in to verify newly added functionality and regression test existing code. Integration tests are run automatically and do not test all the business functionality or user interfaces of the application. 

Functional Testing

Functional testing incorporates both manual and automated testing, as follows:

• Writing of acceptance tests for each user story, based on the story’s acceptance criteria,

• Writing test cases for each user story, based on the story’s functional requirements,

• Assembly of test data,

• Execution of test cases,

• Logging of defects and validating bug fixes,

• Automation of functional tests, covering a target of 100% of smoke tests and 100% of sanity tests

• Automated regression testing of each release, limited to the scope of the automated tests,

• Sanity testing of each major release.

Non-Functional Testing 

Pertinent non-functional testing is conducted as necessary at various relevant points in the development process: when evaluating or verifying an architecture selection, when basic infrastructure has been established, and when nearing code completion.  Non-functional testing is most often conducted in an exclusive testing environment using tools that are selected during Sprint 0.  This includes high-availability testing and performance testing including load testing, stability testing, volume testing and scalability testing

User Acceptance Testing (UAT)

Most often, our customers will define UAT scripts and execute UAT.  Informal UAT takes place by the Product Owner(s) throughout the Development Phase, in the QA environment, in order to provide early feedback.  Formal UAT takes place during the Production Readiness phase.

Test

Deployment

Axispoint writes automated deployment scripts for our software.  Deployments to QA are completed at a frequency that supports the agile development and testing process.  We use Jenkins to support the practice of Continuous Integration (CI) to govern deployments, automatically testing code and reporting issues.  The use of Continuous Deployment (CD) varies depending on the client and project maturity.

Roadmap for Success

Roadmap for Success

Axispoint believes in iterative software development, including incremental rollout of major functionality.  We believe in starting with a MVP and iterating through phased releases.  Enter the Product Roadmap.

1. Roadmap Definition

A roadmap is the foundation for all strategic development efforts. A roadmap can be seen like a product backlog, with Themes in place of User Stories. A roadmap requires management and, like a backlog, should be periodically reassessed for validity.

2. Roadmap Planning and Reassessment

It is critical that roadmaps undergo periodic reassessments to adjust for changes in priorities, any new external business situational changes, and for duration adjustments that are necessary to correct the course of projects. On a scaled project, roadmap reassessments should be formal activities and take place around every three months. Informal reassessment can take place outside of this time frame as information comes to light.

3. Roadmap Grooming and Prioritization

Roadmap Themes must be prioritized according to business value. Where possible, this business value should be quantified to allow for ease of communication and for (somewhat) objective prioritization. Business stakeholders should be consulted for input on business value and on prioritization.

Dependencies between Themes should also be considered, however should not necessarily be a deciding factor in prioritization; if one Theme is dependent on another, consideration should be made to bringing forward the dependent component of the Theme only and not the entire Theme. The efficiency of doing this must however be considered on a case-by-case basis.

The roadmap must also be groomed.  The following activities take place during Grooming:

• Removing Themes that are no longer relevant.
• Creating new Themes in response to newly discovered needs.
• Re-assessing the priority of Themes.
• Performing an initial estimate of Themes, ideally based on MVP and subsequent work if details are known.
• Splitting Themes into smaller projects as they become closer to development.

Axispoint can assist in your roadmap development.  Learn more about our Technology Consulting services now.

The Axispoint Engagement Process

The Axispoint Engagement Process

---

Discovery

Our business process begins with internalizing your business process

In the discovery phase, we will listen to your specific goals, explore your existing systems, and craft a plan for a technological solution. Expect face-to-face meetings and interactive design sessions with our top analysts, architects and system engineers.

Out of this intensive collaboration, you’ll have a clear schedule and timeline for the project; confidence in our mutual understanding of the problem; and a scope and architecture for a solution that is tailored to fulfill your needs, hopes and wishes. Axispoint’s meticulous discovery process lays the foundation for our future success.

At the close of our discovery phase, we’ll have developed:

1. a “project vision”, consisting of epics, a model of the project domain and business processes, and the non-functional requirements.
2. an initial architecture; a high-level design of the software system to be built
3. a suggested project approach; recommendations on the delivery methodology, including duration, project cadence, and team structure.

We know your challenge, and now we pave the road to solve it.

When we have a rough idea of who you are, what you need, and how we’re going to solve it, we begin the development project with a short 1-4 week inception, or "Sprint 0" phase. (If your project didn’t call for a discovery phase, we’ll do most of those activities during this phase instead.)

During inception, we define a prioritized list of features that form the basis of future development work, then organize teams and work environments, ensuring that construction can begin unhindered.

You’ll be introduced to a project team we assemble specifically for you. Your team will work closely with you to ensure the product features meet your criteria before they’re “done,” brainstorm and storyboard user interfaces (the screens that you’ll see and work with in the final product), and prepare you for the construction process. We’ll give you a clear idea as to what we’ll need from you and how you can monitor our progress. Sometimes, we’ll also deem it useful to undertake a prototype or proof of concept to verify that we’re on the right track

At the end of inception, you’ll have:

1. a prioritized product backlog,
2. a thorough understanding of the development work that will be completed at the beginning of the development phase,
3. a scheduled cadence to follow for the remainder of the engagement, and
4. established development environments.

Inception ensures complete alignment on the expectations and activities during the development phase and will provide you a detailed path to actualizing your software vision.

Inception

Development

And now... we build

Up until now your big idea has existed in detailed plans and maybe even in dreams.

Development is the phase where it becomes reality… real reality, like the kind you can see. With our agile software development approach, you’ll be able to see working code in as little as two weeks after we begin.

The development phase is made up of successive time-boxed “iterations” (or sprints), where each iteration takes the same form. Typically our iterations last two to four weeks, depending on your project requirements.

Why iterations? We recognize that challenges arise and requirements change throughout the development process. Building a product with non-iterative, whole components, called the “waterfall” approach, makes design adaptation costly and time-consuming - just imagine altering your cookie recipe once they’re in the oven. Iterative design consists of cross-functional teams working simultaneously on a series of features, meaning not only a faster build time, but a flexible and efficient development process.

To begin, an iteration is assigned a series of features to implement in each sprint, the so-called sprint planning. You, as the product owner, will join us in a detailed dialogue about the features to implement in the next sprint, so that you can decide which stories to prioritize. Our team has daily check-ins (“scrums”) where progress is reported and issues can be raised. The features are implemented and tested, and at the end of each iteration, they are presented to you in the sprint demo. We then hand the working system over to you for feedback and review. The cadence is regular enough for you to set your watch by.

And to make sure each sprint is more effective than the last, we take a short time to reflect on what went well and what could be improved (“retrospective”). In parallel, we are also working on defining the details of features that will be implemented in the upcoming sprints by exploring possible solutions, finalizing business rules, and sketching user interfaces.

We keep iterating until your product has sufficient functionality to warrant what we’ve all been waiting for - a production release! And then, if the project calls for it, we keep iterating, building on the first release functionality to make your project even better. At the end of the development phase, you’ll have a consumable product that meets the current needs of your stakeholders.

You’ve seen it, you’ve played with it, and you’re ready to let it loose on the world (well, your users at least).

Enter the transition phase, where we successfully deploy the working system into a live and usable environment.

We’ll work with you to determine the logistics and mechanics of the release, such as where and when to deploy, whether the new system will run in parallel with the old, or if any data migration needs to take place.  

At the end of transition your software vision will be fulfilled.

Axispoint can also provide ongoing support and maintenance services beyond the Transition phase.  Our support agreements are as unique as our software, so Contact Us for more info.

Transition

Scalability

Scalability

---

How Axispoint scales to meet your enterprise development needs

Program Level Oversight

In circumstances where multiple teams and work streams exist within an overall development plan, Axispoint staff key senior roles that have oversight and contact across the teams.

This usually consists of Program Management, Program Architect, and Program Analyst roles.  Our client will appoint a peer for each. These roles are not necessarily full time roles and often shared by individuals with other responsibilities within a specific development role/team. Local US-based resources typically staff these Program Level roles.

A Core Team That Can Be Supplemented With Specialists

Another major feature of Axispoint’s approach is the recognition that, while there is a core agile team that is engaged with the project on a daily basis, the team must also have ready access to expertise to supplement its core competencies.

For example, the team will include a competency in database development. However, there will be times when deep experience in database configuration and optimization is required.

In these cases, a specialist with the requisite background and skills can be called in to temporarily augment the team. Axispoint maintains an extensive pool of talented and experienced individuals who can mobilize quickly to supplement the team as needed.

Agile Ceremonies, Agile Tools

Agile Ceremonies, Agile Tools

---

Axispoint’s development methodology is firmly based in scrum techniques. Nevertheless, Axispoint takes a practical approach and has adapted it’s approach to align with best practices for a consulting company delivering quality software to our clients.

The overarching goal of our process is to maintain transparency, demonstrate progress, deliver functionality incrementally, adapt quickly to changing conditions and manage quality, to ultimately deliver the envisioned product.

Agile Ceremonies Are Strictly Adhered To

Rigorous application of agile helps maintain focus and discipline in geographically dispersed agile teams. Our experience has proven that full participation and communication with all team members in English across the various locations is a key attribute to our success.

• Daily Stand-Up: 15 minute daily scrum attended by the project team and client Product Owner, to better team communication and identify issues
• Sprint Planning: A 1-2 hour session at the beginning of a sprint where the project team and client Product Owner plan the goals of the upcoming sprint
• Sprint Demo: A 1 hour demonstration of working software by the project team to client stakeholders at the end of the sprint to elicit stakeholder feedback
• Sprint Retrospective: A 15 minute sprint review of benefits and failings to enable process improvement
• Backlog Grooming: A weekly 1 hour backlog maintenance session for key team members (business analyst, UX designer, scrum master, tech lead, and client Product Owner) to review and manage the backlog

Collaborative and Agile Tools are Leveraged

The team is provided with the necessary tools and technologies to implement consistently effective agile deliveries. 

Distributed agile teams must take advantage of the full spectrum of tools, from web-based agile tracking tools like JIRA and VersionOne, to collaboration platforms like Confluence, to powerful and accessible voice and video conferencing systems in order to maintain the cohesion and focus that are the necessary conditions of high-quality output.

Hybrid Onshore – Offshore Teams

Hybrid Onshore – Offshore Teams

---

Axispoint senior, local staff fill key team roles,
offshore resources staff the majority of the team over time.

Many organizations have tried using offshore teams to do their development work – the cost benefits are compelling. However, these efforts have frequently been beset with problems of low quality, lack of consistency and late delivery. Axispoint has solved this problem by developing an approach that allows us to build cohesive and integrated teams that combine onshore and offshore resources.

Axispoint NYC-Based Staff Fills Key Team Roles

Local Axispoint staff plays key leadership roles in the hybrid teams. Specifically the scrum master, development lead, architect and business analyst are typically based in Axispoint’s NYC office.

Having local staff in these roles helps maintain clear and open channels of communication with clients and clear accountability within the team. Our local resources meet in-person on a regular basis to ensure there is no degradation of vision, message or direction.

Offshore Resources Form the Majority of the Team Over Time

Taking advantage of lower offshore rates means that the costs of the hybrid team are a fraction of the cost of a solely locally-based resources.

In addition, Axispoint benefits from a much wider talent pool to find the best fit for a specific project requirement.  The Axispoint local staff continue to fill key team roles, and offshore resources staff the majority of the team over time.  The ratio of resources changes as the team scales and the project matures, while the resources mix varies from project to project based on several factors.