Our Approach :: Lean & Agile Methodology
"EVERYTHING SHOULD BE MADE AS SIMPLE AS POSSIBLE, BUT NO SIMPLER."
-Albert Einstein
We have taken the next step in the natural evolution of software development. To help our customers respond to a fast changing and economically challenging business climate, we have embraced what works and discarded what does not by combining and extending the practices of agile development with selected model-driven disciplines supported by an integrated suite of standards-based, and customized tooling that includes breakthroughs in modeling and software automation. Here are a few distinguishing characteristics of our lean approach and agile methodology:
- Fewer experts (architects, designers, and coders) are needed to ensure success providing higher scalability
- Knowledge is represented as shared, logical models keeping team members on the same page
- Development is separated into Business and Technical activities that are performed independently
- Solutions are represented as logical models focussing all activities on real business value
- Model elements are traced to requirements and value streams to ensure all features are necessary
- Models are compiled with architecturally robust Blueprints and so are high quality and defect-free
- Code is generated so there is no effort wasted producing unused code
- Project teams are small and require low management overhead and oversight (reviews, meetings)
Read more about how our unique approach of combining modeling and customized tools with agile methods achieves these lean principles:
Most agile methods bypass the labor-intensive activity of formally documenting requirements and detailed design, favoring code as the primary artifact representing the solution. Code is then compiled into the software that runs on the computer. Our approach bypasses the labor-intensive activity of writing large volumes of code, favoring robust, logical models as the primary artifact to represent the solution. Models are then compiled into the software that runs on the computer. Our model complier automates the activities of detailed design and writing code.
Most agile methods accumulate learning and knowledge by prototyping screens to solicit feedback from end-users. Our approach shortens the feedback cycle by using requirements and analysis models (Screen, Flow, and Domain models) created by non-technical analysts, which eliminates the need to write throw-away code and future re-factoring. This helps the team learn more about the problem domain, better understand the business need to contribute added value, and collectively explore solution alternatives without expending effort and cost performing complex technical activities.
Many functional and technical design decisions made at the beginning of a project are based on a set of often loose assumptions. Many of these assumptions, however, do not hold as the project progresses for a variety of reasons. These reasons include the client's evolving understanding of their needs as well as software infrastructure (e.g., development frameworks) being defective or not working as expecting in every circumstance. This leads to pervasive changes in the design of the software throughout the life cycle, spiking risk and raising the importance of making technology decisions early in the project when least is known.
Most agile methods rely solely on short iterations and constant code re-factoring for adapting to these design changes, but this approach still incurs great cost and effort, since the eveolving code rests on architectural assumptions which may well later prove false in light of changing requirements. Our approach further mitigates risk by automating design and code activities. Faulty design assumptions and unexpected side effects of software infrastructures can be easily corrected across the entire code base as they are discovered throughout the project life cycle. We incur little cost and effort since we automate most of the re-factoring activity. Re-factoring becomes a low risk, low impact activity. As a result:
- Our clients can decide what they really require as they gain a better knowledge of their domain
- Technical decisions made at the beginning of the project are less critical and can be recast throughout the project life cycle (or even delayed) with minimal impact
- Commitments to scope and technology can be deferred as late as possible
Speed should not be measured strictly on how quickly code can be produced. A better measure of speed is how quickly requirements can be elicited and understood together with how quickly those requirements can be consumed to yield a working solution. Once this is understood, it becomes clear that speed is in truth a capability of knowledge and understanding, not a technical skill such as the mastery of a specific programming language.
Our approach separates analytical activities from technical skill activities. We call these our business stream and our technical stream. In this way, we increase delivery speed by:
- raising the level of abstraction at which the knowledge worker performs (higher productivity)
- eliminating knowledge worker dependency on technically skilled coders
- achieving concurrency of business and technical activities (parallel work streams)
The business stream is engaged with busines-facing models that focus exclusively on the business domain. This in turn increases the productivity of understanding the business need and conceiving a high quality solution. The models serve to simultaneously help the team understand the problem and specify the solution so that it can be built immediately.
The technical stream, aided by our advanced software generation tools, produces the automation technology to generate high quality code that would otherwise be created with labor-intensive manual effort (with lower quality).
This combination of higher productivity through abstract modeling, parallel work streams, and automation achieves delivery speed that simply cannot be matched by approaches based on large pools of skill-based labor. Consider, also, that as pools of skill-based labor grow, keeping everyone informed of changes and updates rapidly breaks down. Our approach does not depend on these islands of knowledge being synchronized. Since all domain knowledge is captured in the model, synchronization is automatically secured.
Model-based solutions are better aligned to the business need because they are focused on the business and not the technology. Models are used to establish a shared understanding of what the solution is expected to do. UI models are used to give the end-user a sense of the user experience very early in the life cycle. Requirements are expressed in terms of model elements, so they are captured using a common "language" and can be tested early and often to ensure the solution will work as needed (as opposed to "as designed").
The architectural quality of software design is ensured by using design and code automation. Blueprints codify design guidance, standards, patterns, and best practices and are used to compile models into high quality, consistent code. The blueprints can be modified to incorporate new learnings or non-functional requirements and then re-applied to propagate across the code base. This ensures that the solutions remain flexible, maintainable, and extensible.