Up and Running Software Development Process
Traditional product development is often achieved by one single "right" process, allowing for ease of reproduction and predictability. Software development, however, is not an exact science, where there is usually one right and many wrong ways to do things. The software development process is more of an art, and there are many possible approaches to creating a new product, depending on what the client needs.
Some clients already have a process in place. Others don’t, and they use Up and Running’s help to establish such a process. The truth is that our clients are many and varied, from single-man startups to Fortune 10 corporations. With such a variety, the one-size-fits-all approach simply does not work. What works is a lean, flexible approach that allows us to adapt to every client’s unique needs so we can respond to them successfully.
"We have processes to ensure success, but within those procedures, we have complete flexibility. Since stakeholders, client policies, scope, resources, budgets, timelines, etc. all differ, the process for each project must adapt accordingly. Consistent customer happiness is our metric of success, the constant, not that we followed a trademarked or industry-standard process."
- Ian McKilligan, CEO of Up and Running, Inc.
Our Methodology: Agile
The Agile development methodology is what helps us be so flexible and adaptive. Simply put, Agile software development is results-oriented and focuses above all on the communication among stakeholders to enable collaboration that moves the project forward. This is distinctly different from the more traditional Waterfall software development process, which involves several sequential sub-processes. These are non-iterative and much more inflexible than Agile.
In our workflow, we also leverage the Scrum methodology, an offshoot of Agile which helps carry out complex software development projects more smoothly and efficiently. The Scrum framework involves a Product Owner (the client), a Team (those working on the project), and a Scrum Master (the development lead), who manages the project. You can read more about our own version of the Scrum Master below.
Our Agile Process: High-level Planning and Two Week Sprints
The Agile process begins with high-level planning: when we define the budget, select the team, and set up the scope and initial tasks. Then hands-on work begins: the Sprint, which you can see in visual form below or download the pdf.
Our sprints take two weeks each by default and cover all aspects of development, including setting the product backlog (the items to be completed), planning, daily meetings of the team to review tasks and progress on these tasks, QA testing of the software being developed, and, finally, the release of a demo. Here's an infographic for a bird's-eye view of our methodology in this pdf.
Low Fidelity Wireframes: The Most Cost-Efficient Option
After the product backlog has been defined, it’s time to draw up the specifications as per client requirements. We have found that low-fidelity wireframes are one of the most effective forms of a specification document. Among its advantages are that low-fidelity wireframes are much cheaper and faster to make than other spec document forms and anyone who can type or write can make them. Finally, making changes to low-fidelity wireframes is much faster than making changes to a running, operating code. In short, wireframes save time and effort while accommodating all client specifications.
"The most common estimate is that it's 100 times cheaper to make a change before any code has been written than it is to wait until after the implementation is complete."
- Jakob Nielsen: https://www.nngroup.com/articles/paper-prototyping/
Low-fidelity wireframes also greatly facilitate the software development lifecycle by helping define some key features of a project and the best path to complete it, usually one of the following: a totally customized approach; using some software off the shelf; or tapping open-source resources. As the saying goes, you might not see the forest for the trees when taking approaches that are more bottom-up in nature (as is done with Lego bricks or when one is analyzing all the data to arrive at the features to achieve those).
Low-Fidelity Wireframe Example
Once the wireframe is completed, there are several ways to move the project ahead, depending on the client’s preferences. One is a brief informal discussion with the client. Another is providing the client with a prototype and a number of different approaches to consider. A third way we practice is by making an example use case. All of these methods enable the client to make a final decision on what would work best for their project.
As part of the project implementation we also put together a variety of other documents that are necessary elements of the software development lifecycle, such as a breakdown and an outline of the core services in the infrastructure, system boundary diagrams, entity relationship diagrams and workflow diagrams for the primary use cases for every project, and, last but by no means least, we also put together coding standards for our developers when they start work on a project.
The Senior Development Architect: Scrum Master Reinvented
Successfully managing such a large team scattered around the world essentially comes down to good communication. To ensure it, we have a special role: our very own version of the Scrum Master, the Senior Development Architect (SDA). The SDA is the liaison between the project team and the client. The SDAs are senior developers who can, if needed, join the developer team to help with an issue at the code level, and they can turn around a customer request very quickly when needed.
SDAs help keep the developers accountable by staying in touch with both them and the customer. They also translate business requirements into technical requirements, which is necessary to initiate work. Although scalability could be easier with traditional project managers, the specific skills that our SDAs have, which allow them to do more than just manage a project, more than make up for that.
Our version of the Scrum Master represents one of our core values: communication. Our other core value is transparency. It is particularly important in a virtual organization such as Up and Running, so we have in place four internal processes that help maintain it. One of these is creating a centralized storage hub for all information about a particular project. The second process is a daily standup meeting, where SDAs meet up with their team and review the agenda for the day and report on progress so far. The third process is a code review for each project. The fourth process is a daily time submission, which is described in more detail below.
The team members decide what the best form of review would be on a project-by-project basis. Sometimes it’s one developer writing a piece of code and another developer reviewing it; other times it's the SDA or other stakeholders doing the reviews. This provides extra validation for the implementation of the project, a second (and third, and fourth) set of eyes looking at the work, which ensures that potential issues are addressed in a timely manner and that the solution being created is effective and efficient.
How Our Developers Work: Flexibility and Maximum Motivation
One of our strongest points as a business is that we have dismissed the centralized office structure. Our developers work from home, helping to eliminate a lot of the distractions associated with a central office. More importantly, it allows us to scale quickly, as well as letting the team choose their own work-life balance, which can often be a very strong motivator for excellent performance.
Daily Time Submissions: You Know How Your Money Is Spent
Finally, developers working on a project all submit daily reports on their progress with the work. These daily time submissions are done at the end of the day and detail all the work the developer did that day on each project. These submissions are then relayed to the client on a weekly basis and included with the invoice. In other words, the client knows exactly how each minute of the developers’ time has been spent.
Our Core Values
Our core values of communication and transparency are the basis of what we call C4, which are the pillars on which our corporate culture stands: Communication, Commitment, Care, and Consistency. With these, we deliver to our clients the software solutions that would respond most efficiently to their unique needs.
"The initial software parameters were difficult to define and were changed as the event developed. Up and Running quickly adapted to this environment by providing the best customer support I have ever experienced."
- David Neeley, Army Programs Manager of Advancia