Get low, get low...
Low Code Developer

Reading time: 2 minutes

Customer facing applications (why is this the targeted genre? – it seems because customers want short schedules and rapid change cycles (which is what?) – originally targeted at speeding up all projects, it found traction with customers’ heightened priority for customer experience software).

Key is the ability to test business ideas with working code within days or weeks (fast, continuous, and test-and-learn delivery). Hand coding is too slow – enter low code development. Firms can respond more quickly to customer feedback after initial releases to enrich customer interactions (what?)

Drives innovation in business models, brand connection (how?) and customer service.

Slash project schedules to weeks for initial delivery and days for updates (requires different software structures, project methods (such as?) and team organizations.

Old development regimes treat every project as a strategic system requiring fully articulated requirements and years of development work, which squashes promising new ideas.

Outsourcing as a coping mechanism to keep pace with the change that customers and customer facing employees (what?) demand. Packaged apps as another mechanism, some specialized middleware, but none of these help app delivery teams speed up their useful output.

Rapid assembly of customer facing apps (sounds like a pattern library) that eliminate handoffs between project phases, slashes hand coded effort, allows 1-2 person teams to compose new apps and quickly gain feedback from stakeholders and customers.

Shifts in methods, practices, and approaches to app development and delivery. Can quickly prove a project’s value (how?).

Agile’s core concepts – close connection to the business, incremental delivery, minimum viable product

New test and learn methods for software dev (1-4 weeks for MVP (minimum viable product) based on small number of requirements, live testing with intended audience and based on feedback adjusts or starts over. Doesn’t rely on guesses at requirements that often inaccurate anyway.

New project funding models that allow for uncertainty (doesn’t require well-defined requirements and features before starting development). Teams need to get comfortable funding apps that may not succeed but provide a way to quickly learn what works and what doesn’t for customers. Rather than emphasizing the “D” in R&D, it emphasizes the “R”.

While the success of internal apps is often measured by increased productivity, standardization, and quality, the success of customer facing apps relies on the customer’s perception of how useful, usable, and desirable an app is for completing given tasks. Thus metrics need to focus on convenience, engagement, and advocacy.

Reusable components.

practice changes

 

What’s out – cultures that reward specialization, top-down delivery processes, system integrity above all, and measures of success only tech professionals can understand.

What’s in – cultures that reward learning and experimentation, self organizing teams, innovation and fast time-to-market, and metrics reflecting business outcomes.

Need to balance integrity with innovation and hand-coding with low-code tools.

Realize Agile is necessary but not sufficient for rapid delivery (look beyond Agile methods to cut time to market. In addition to smaller more frequent deliverables seen in Scrum, embrace test-and-learn approaches, responsive design, and continuous deployment.

—————

8 tenants of faster app delivery:

WIP – work in progress. Reducing the WIP is the single most important thing you can do to improve delivery speed and reduce cost. Don’t clog the system with work that becomes waste when new info arrives.

Continuous integration (CI)starts with build automation that includes testing and deployment. CI enables continuous testing every time code changes are delivered (API driven testing) eliminating manual reviews, increasing speed, and improved governance effectiveness.

Brookes Law: http://en.wikipedia.org/wiki/Brooks%27s_law