“Design is not just what it looks like and feels like. Design is how it works.”
— Steve Jobs
“Design-thinking firms stand apart in their willingness to engage in the task of continuously redesigning their business…to create advances in both innovation and efficiency – the combination that produces the most powerful competitive edge.”
— Roger Martin, author of the Design of Business
Design thinking is not just about making objects, but is at the core of effective strategy development and organizational change. The biggest barrier to implementing digital transformation rapidly is that design thinking results in new ideas that may require technical solutions using features such as; big data, AI and IOT. These solutions can be very complex and time consuming to implement.
Umajin has developed the Design Led Agile methodology to combine Design Thinking and Agile Engineering. This methodology supports a collaborative approach to delivering innovation. It does so efficiently by delivering small bite sized processes built on top of existing business software and systems in a way that revolutionizes DevOps. Umajin improves enterprise agility by fundamentally changing BOTH the technical and the organizational processes for delivering innovation:
- The platform provides pre-built building blocks, a turnkey server environment, a multi user visual editor and the ability to instantly deploy content / process / native apps.
- The platform puts digital transformation into the hands of the functional teams. They can quickly digitize and update their business processes with input and feedback from customers and partners.
With this methodology the bulk of the development is performed very quickly and with a very light DevOps requirement. Only then are the small and clearly defined requests for connectors, protocols or transformations made to engineering. These new modules go through the organization’s full DevOps process as they are built. When they are tested and complete they rejoin the design process.
Design Led Agile Methodology
Design Thinking is a well-established approach to define and frame problems, ideate and explore options, prototype, test, and iterate in a way that drives continuous improvement.
Similarly, Agile Software Engineering is a widely used set of values and principles that allows for the collaborative iteration of software specifications during development. It supports engineers in delivering quality software.
 |  |
The challenge is that at its core, delivering reliable software engineering is at odds with continuous process redesign. This conflict is directly expressed in the paradox organizations face daily when balancing the ongoing requirement to innovate and compete at a business level and yet manage the budget, quality, security and capability required.
To make it possible to continuously redesign business processes without causing a huge engineering workload we need to create a positive relationship between design and engineering. In the Umajin methodology, we essentially combine the traditional model for Design Thinking with Agile Engineering. This creates a new lightweight model called Design Led Agile.
Design Led Agile
Design Led Agile starts with the traditional design process. This identifies customer problems moving through the process to get to the scope, goals and function. Once this design is validated, the team can rapidly build a functional prototype in Umajin. This prototype can be developed into a production system that can be properly secured, managed and maintained.
This functional prototype involves creating the visuals, workflow, actions and test data sets. This can all be created using the drag and drop Umajin editor in very rapid daily sprints. This allows the stakeholders and users to quickly test and evolve the design until it is fit for purpose.
When users have defined how everything will actually work – any connectors, actions or components that are not already available from the deep library of Umajin capabilities can be handed to the agile engineering process as a REQUEST. These requests are now clearly specified and can be built using the tools and agile processes the developers prefer. Importantly this is also delivered on timelines and at quality levels that make efficient use of engineering resources.
After suitable development and testing throughout the agile engineering process these requests are OUTPUT so they can be immediately used and tested inside the project. Even better, these connectors, actions and components are lightly coupled so they can be reused in other projects and upgraded with minimal effort from either the design or engineering perspective.
This is a massive change from the practical frustrations and feelings of lack of control that regularly occur on all sides of development, design, business and engineering. Design Led Agile means people are able to manage their own outcomes and work together in real time inside the same project using the same assets and terminology.
This “Edge Execution” model requires a change in responsibility and control along with a new approach and resourcing model. It means embracing design thinking, doing a larger volume of smaller projects, and delivering projects as a layer on top of the core IT systems – all while still providing high quality, security and stability.
In Design Led Agile, DevOps requirements are reduced exponentially as well as the need for outsourced resources. All of the engineering DevOps requirements around code quality, testing and security will have already been met during the agile engineering process when creating the connectors, actions and components. So for example functional testing and release management are comparable with the effort in publishing an important document – rather than the overhead on a full engineering QA process.
The Reality Of Most Software Development Today
It is typical today that projects are built in a monolithic fashion with requirements gathered from many stakeholders. It’s common to accumulate requirements over the duration of the project sign off phase and to have large lists of “MUST HAVE” features resulting in heavy project management requirements and long, cumbersome development cycles.
If you are reading this, you may well have been part of a project like this in the past or are currently in the middle of one or more. Projects often start behind schedule due to delays in scope, acceptance, third party vendor requirements and budget approvals. During the lifetime of a project it may be re-scheduled several times to accommodate changing requirements or the realization that it is bigger and more complex than first thought. This is due to any number of reasons; supposedly ill-formed requirements, discovering complications in the implementation and technology, changes of client requirements and changes in third party software or tools.
During the project the developers will be frustrated by ‘trivial’ UI/UX changes being asked of them while they have large engineering sprints to complete. Designers will be frustrated that the application didn’t meet the user experiences they intended and stakeholders will be frustrated with the slow progress and financial implications.
Upon delivery there is almost always a series of challenges reaching acceptance of the final product, often requiring additional rework. This will be followed by challenges with implementing, training and rolling out the solution to users, along with fixing the issues which almost certainly are discovered during early usage despite QA efforts.
Monolithic Applications
- Overall project completion measured in years
- Interdependencies mean that nothing is available until all parts are complete
- UX nightmare of buried functionality and navigation trees to fit everything into the application
- Code is fragile under changing requirements
- Original developers hold the arcane knowledge of the system due to complexity and opacity
- Developer controlled processes prioritize function over form – resulting in rework
- Lack of early/fast iteration can cause large parts of the application to need rework
- Large numbers of stakeholders can cause conflict resulting in potential delays in critical-path decisions
Given the limitations of Monolithic Applications, many teams have avoided it and turned to Google Sheets, Excel and other ad hoc Low Code environments to improvise applications, creating both complexity and control issues in managing key processes.
Proliferation of Ad Hoc Applications
- Important business logic is housed in hard to quantify silos
- Data is not properly backed up or managed (with mixtures of client or cloud spreadsheets)
- Single citizen ‘developer’ has knowledge of the single application
- Improper development techniques used can cause maintenance problems
- Different versions of data stored in multiple applications cause conflicts – which data is correct
- No ability to control access to the application
- Sensitive and private data may be exposed causing business, regulatory or even legal problems
- Quality Assurance is unlikely to have been implemented leading to instability and even loss of important data
Design Led Agile In Practice
Design Led Agile has been developed to deliver better outcomes, to be faster and more responsive to change, to encourage more iteration cycles, to promote more reuse, to layer on top of the underlying IT ecosystem and to create more robust solutions. Here is how this works in practice compared to traditional software projects.
Design within the Umajin platform covers the spectrum of visual design through to writing script code. It is important that the workflow between these elements is fluid not rigid. Team members can work together in real time moving through parts of the spectrum that suit, rather than being bound by their traditional title or role.
Product Owner driven design: For example, a project could be started by the product owners who rather than spending weeks on a detailed specification and wireframes, make the layout in Umajin. Then they can layer in basic interaction, actions and temporary data to test this functional prototype with users. The prototype can now be extended, working with design in real time to complete the visual elements and tweak the layout. In parallel developers can tackle creating the database and any scripts required to make it production ready.
Designer driven design: Where design owns the project kickoff it will begin with a layout, basic behavior and be followed by a visual design. The design team then cycle with the product owners until they are happy with the look and behavior. Once that’s all locked down developers can join the project and create the secure/scaleable database and any custom scripts required. All the while the look and behavior adjustments can continue.
Developer driven design: It’s also very common to have development start the design process (how things work, not just how they look). In this scenario developers would create a rough layout and actions, fleshing out the code and database until they feel they have achieved the desired behavior. Then they work with the product owners to ensure everything behaves as intended, collecting feedback from users. Then designers come in to adjust the layout and create the visual design and styling.
Conclusion
Umajin’s Design/Develop/Deploy platform enables the Design Led Agile process for teams. At a high level it moves more of the transformation control and implementation into the design side, while improving communication with and reducing workload on engineering. It also respects the different responsibilities and mandates of the lines of business and the business’s IT function.
This whole approach is intended to reduce the scope and complexity of projects. The improved efficiency is multiplied as Umajin makes it easy for teams to reuse design elements, connectors, actions and even whole projects!
Umajin is fundamentally re-inventing the process of digital transformation.