Effectivity through good processes
Every day many employees and businesses use complexity as a way to hide issues and unprofitability. .
One should never be dazzled by complexity.
The Effectify way is, as the name suggests taken from the Toyota way. It’s about optimising the process and simplifying what we have to have better performance and make something more usable.
Our approach
The SDLC and problem solving
Though the software development life cycle is cyclical, it very often happens that the clients prefer to hand over the maintenance of the solution to their own team or hire their own software developer to maintain it.
For this reason, the process below is linear.
The Effectify Way focuses on solving customer issues.
Once a problem is defined, it’s only a matter of time until it is resolved.
As it’s important to find, define and solve the problems long before the coding starts, the focus is placed on research and understanding the problems involved.
What if the uncertainty is too great?
In certain scenarios, a problem cannot be defined as easily as the above. For example, a startup functions under extreme uncertainty.
Though many problems can be solved, one needs to solve only relevant problems. This needs to happen in bite-sized chunks.
As the answer to the current problem could determine the next question/problem to solve, it makes sense that a linear approach would be unproductive. A cyclical approach would be appropriate for businesses that have a high level of uncertainty.
Each iteration identifies the next question that needs to be asked. Once the question is identified, one can execute a test to receive the next answer.
Should my project be linear or cyclical?
Depending on the client needs, either one of the two approaches can be used.
To avoid the deadly spiral of over-engineering, it is wise to use certainty as the gauge for the decision.
Once the diagnostic phase has been completed, the appropriate approach would surface.
The diagnostic phase
Before any coding or work starts, we prefer doing a diagnostic phase.
It’s important that we understand the problem that we need to solve.
For example, a client is looking for API integration with all the major phone networks. He hasn’t inquired yet about existing APIs and current functionality. If this is part of the core functionality, this dependency could determine the success of the project. It would be irresponsible to give time and monetary estimates unless this has been unpacked.
It’s definitely not ideal to start a project and halfway into the project it is discovered that the timeline moves out with 6 months, or that the vital integrations do not exist.
Research and planning
Once the diagnostic phase has been completed, one is able to give timelines and cost estimates for the work that needs to get done.
Once the research and planning phase has been completed, a research document – a business requirement specification (BRS) will be delivered to the client. This is very similar to a business requirement specification, and developers can use this as a base for the coding that needs to be done.
In the diagnostic phase, the technical aspects such as API integration, third party requirements and the appropriate platform has been fleshed out. In the research and planning phase, the appropriate system and code architecture needs to be considered.
The research and planning toolbox
Technical and code approaches
- Appropriate technology choices
- Architecture choices
User Experience
- Personas
- Needs analysis
- Process flows
- User stories
User Interfaces
- Corporate identity and branding
- Low fidelity mock-ups
- High fidelity mock-ups
- Icons
In the research and planning phase, the user experience research and user interfaces are also included.
To understand the user better, the Effectify way does a needs analysis (which could take the form of interviews, data tracking and collection of relevant information). From the information gathered, personas are created, followed by process flows and user stories.
Execution – coding the solution
Once the blueprint is in place, the execution can start. The blueprint will dictate the following:
- the technology used – including coding framework, language and architecture
- the platform (mobile, web, desktop application, cloud, etc)
- third party integrations and external technologies leveraged
We believe in a UI first approach to get more client feedback earlier in the software development lifecycle. If one can see how a solution will look and navigate, the code logic can be set up accordingly.
It’s also important to supply weekly updates so that no one is out of the loop about where the project is and where it’s heading.
Testing and feedback
It’s worth noting that any company that claims that they write bug-free code needs to be avoided. As humans are involved, bugs are bound to creep in. For this reason, the Effectify Way avoids the ‘big reveal’ at all costs and does small incremental releases so that testing starts early in the process.
Though unit test coverage for code is vital for code stability and trust, it’s also important to do negative and functional testing.
Conclusion
The Effectify Way is about simplifying processes.
When someone uses software written by a developer, it needs to work.
More importantly it needs to be used – it needs to be relevant, easy to use and viable.
Simply put, it needs to be effective.
