Brief

All projects start at the same point, whether it be a newly formed start-up, government organisation or legacy project. Products at their core intend to solve a problem for a group of users. The purpose of the Brief stage is to ensure that everyone shares an understanding of the problem and are confident both a feasible product is possible, and a partnership can be formed. The brief phase begins with a consultation that involves the customer, Account Manager and any relevant Product team members. The Account Manager is the main point of contact for the customer during this process.

During the brief consultation, the core activity is to explore the underlying problem the customer is looking to solve. A key part of this is unpacking the business and user outcomes associated with the success of the project. The activity aims to unpack a range of problems the customer may be facing and focus in on the most valuable one. The outcome will be a defined problem statement that will be explored and defined within the brief document and form the basis for the Scope stage.

Scope

The biggest mistake in software development (and it’s one that is unfortunately repeated too often) is rushing or skipping the Scope phase. To liken it to another industry, it’s like trying to build a house without blueprints. Investing the time at the start of the project will significantly mitigate risks down the track.

The purpose of scope is two-fold, firstly to dive deeper into the problem statement and design a solution and secondly, prepare that solution for development. It is important for a scope to focus on a manageable body of work, instead of a product’s entire roadmap. Scoping out one build at a time makes the project more agile and allows the delivery team to deliver value earlier and often.

Scoping is performed by a Product Designer and a Product Developer from the Product team. Having these two specialities enables the team to consider solutions from not only the user’s perspective, but also the technical feasibility of its implementation. It is also important to involve the customer’s key decision makers and stakeholders in the process, so that everyone is on the same page and is satisfied with the direction the scope is taking. Customer Success Consultants are also involved here to educate and manage customer expectations and contribute insights from a commercial perspective.

In general, a scope should deliver the following artefacts for an upcoming build:

• Scope document
• Non-functional prototype
• Requirement's backlog
• Database model
• Estimations
• Projected roadmap for the product

Realising these deliverables for a reasonably sized build typically takes between 2 and 5 weeks in length. Teams can scope for longer, however this indicates that they are scoping out too much and introduces risk during development. Our research has found that there is a 90% correlation between the scope length and the subsequent development length. The more that is scoped out into the future, the more unknowns and uncertainties are introduced into the project.

Development

With the project successfully prepared, development can begin. The purpose of the development phase is to build software that meets the scoped requirements, in a manner that delivers value early and often to the customer. The development of a product can commence at any point after the scope has been fully delivered.

The cycle is comprised of many iterations which continue until development has been completed to the product owner’s satisfaction. Every iteration includes meetings, checkpoints and software releases to ensure the delivery of functional software and keep the customer satisfied.

The development workflow is underpinned by many product iterations that result in a releasable product version, typically called a build. An iteration is a short, time-boxed period when a delivery team works to complete a defined set of requirements. Iterations generally have project related goals associated with them, but in general should deliver an increment that can be used and tested. Defining the work to be completed during an iteration, called the iteration backlog, is a shared responsibility between the product owner and the delivery team.

The length of development varies between projects and depends heavily upon the scale and complexity of the solution. As mentioned, there is a preference toward shorter scopes, which tend to create smaller and more manageable development cycles. Reducing the size of a build not only allows for increased certainty around estimations, but also lets the Product team incorporate user feedback into subsequent scopes.

Support

The Way of Working is a recognition that the software development industry isn’t perfect, and it’s unlikely to ever be. There are constant risks that threaten to derail a project at any moment. Rather than watching the news cycle of over-budget, over-time IT projects repeat, we believe that with the right tools and tactics we can help companies deliver successful software projects.

Through our experiences and learnings in real-world projects, we have catalogued what works and what doesn’t work in the form of processes. These processes underpin everything we do. It creates a platform to share our ideas with our teams, customers and anyone else developing software. We believe this level of transparency and openness is integral to guiding our customers, competitors and any other organisation along the software development journey.

The Way of Working began as a defined process around the agile development framework, which has slowly grown into its own set of principles, tools and guidelines. Where the agile methodology sets out a vision, the Way of Working creates a more detailed framework for development teams to follow. Broadly speaking, the Way of Working processes and practices have been applied to:

• Develop bespoke web and mobile applications
• Migrate legacy software
• Maintain and enhance existing products
• Develop with teams of 3-9 people
• Release projects frequently
• Sustain and support projects and their customers

Who needs Support?

Activating a support provider once a build has been completed is recommended for any and all applications. If you intend to have users on your application regularly, a support provider will be able to help ensure your users have consistent application access.

The reality of software development is that problems occur. There is no such thing as ‘perfect software.’ Whether these problems are in the application itself or the infrastructure, at some point you are going to need a group of developers who understand your product and who are able to quickly get everything running normally again.

A lesser known, but useful benefit of engaging support is the ability to proactively improve your application. Once in production, your application should be receiving feedback from your users both directly and indirectly. Direct feedback can come in the form of scheduled user feedback sessions or through various public communication channels. Indirect feedback generally comes from integrated analytics tools or will be uncovered as part of regular application maintenance. Having a group of developers available to action the feedback in shorter bursts means an application can be continually improved, without the need for a longer- term strategic build each time

When Does Support Finish?

While an application is actively in use, it should continue to be monitored, supported, and improved upon. A familiar concept is where major software packages have become “end of life.” This generally means that the company who created the software has stopped building new features for the application and will no longer provide key fixes. Depending on the scale of the software and how many people use it, this can occur months after the initial release, or even decades after. In our experience, we are still supporting and building new improvements for applications that are up to 5-10 years old.