There is no doubt that all modern software developers have gone all-in for the agile methodology. We have 100% embraced it ourselves but have discovered there are some pitfalls. One of the things that can occur is that the development team can wind-up in a week-to-week, sprint-to-sprint, rut that becomes less informed over time, and at its worst falls into pure maintenance mode. All the work that is done is prioritized by the development team almost exclusively and lacks input from outside influences such as emerging competitive threats, business drivers, analytics and user feedback.
We noticed this was happening and realized all the strategic inputs we had in the early stages of the engagement need to be refreshed periodically. This is how we came up with our hybrid software development methodology that incorporates the design-thinking and strategic principles we know and love with agile development methods. Once we are in the build phase, we work in a strictly agile methodology but on a schedule, usually monthly or quarterly, we return to our definition phase to run through a workshop designed to update or confirm our priorities and road map. Below I will describe this process in more detail.
Discovery Phase
The Discovery Phase embodies early conversations we have with clients that are researching custom software solutions. In these discussions we focus on establishing the vision for the engagement, discussing similar case studies in our portfolio, reviewing our hybrid software development methodology, and any established budget and timeline considerations. We provide high-level guidance on overall architecture and approach and get a better understanding of the state of the business we will be working with. Whether startup mode or established Fortune 500, we strive to establish very early goals for the engagement that align with our client’s business objectives.
Definition Phase
This phase is the first engagement to any new initiative or is the phase we return to after we have released software to production and gathered analytics, user feedback and other requirements from all stakeholders – typically monthly or quarterly. This phase is comprised of a 2-week sprint that includes a 1-day design sprint workshop with a rigid agenda designed to maximize time and quickly prioritize features, user stories, and ultimately create or update the product road map including estimates for design and development. The goal of this phase is to make sure our release schedule is predicated on user interest, performance improvement, usability enhancements, competitive considerations, and innovative new features.
Design Phase
This is an optional phase where the next release would undergo a detailed design effort resulting in a highly detailed, fully annotated design specification document. This document would showcase every user story for the next release in wireframe format with annotations providing the development team with a comprehensive schematic to reference in the build phase. This document allows Haneke Design to provide tighter estimates for the build phase and lower the amount of design time required in the build phase for each user story. Additionally or optionally, we can provide vision- ware prototypes of the proposed release as a form of design documentation that can be demonstrated in a format closer to the final context of the application. These are helpful when the desire is to get some user feedback or stakeholder approval prior to moving into the build phase.
Build Phase
In this phase we are actively writing code based upon approved user stories while referencing any design documentation and artifacts produced in the prior design phase in collaboration with the Product Owner. In the event that the build phase is started directly after the Definition Phase, the design portion of the build cycle may require additional hours per user story to further define the specific user interface elements and create any graphic elements or other visuals required for the finished product. Our build phase follows all standard and best practices associated with the Agile development methodology.
In some efforts the build phase is managed by Haneke Design with both internal developers and outside developers and other 3rd parties that may be associated with integration efforts and extensions into other platforms. Regardless of the distribution of the team, all project management, development oversight, quality assurance, code, and user experience reviews are managed by Haneke Design to ensure the high level of quality we demand.
Once we enter the Build Phase, we set a schedule to close the loop and return to the Definition Phase. The strategic advantage of the Haneke Design Hybrid Software Methodology is to put in place the periodic, necessary steps; to gather and review data and feedback. We strive to prevent a maintenance mode mentality and ensure the development work is aligned with user adoption and is driving business value.
The primary goal of this hybrid process is to enable teams to define requirements early on and be able to adapt to changing requirements through continuous feedback and delivery. So, on a periodic basis, we take a step back, gather data, analytics, user feedback and other key points and return to the definition phase. It is important to make sure we don’t get stuck in this development phase without taking a look at performance and making adjustments accordingly.
This hybrid methodology of software development retains the planning and structure of the waterfall method while embracing the flexibility of agile. It is important to have the right process in place in order to deliver experiences that amaze and delight, all within our clients’ timeline and budget.
