1. From Agile Scrums to Codeless
Workshops
The Evolution of Software Development
Will the transition from Agile Scrum development to Codeless Real-Time Development
Workshops be as high impact as the move from Waterfall to Scrum?
Ian Tomlin 20 May 2014
In the Beginning
For companies that were accustomed to adopting a waterfall project approach for their
software developments, the move to agile scrum methods has been dramatic, both in terms of
its results and its impact on the size and skills of project teams.
Waterfall describes a traditional software development approach (that dates back well into the
1970’s) where different threads of development are performed by different development
people or teams.

2. From Agile Scrum to Codeless Workshops, Ian Tomlin
When development teams adopt the waterfall method, projects are scope up front and then
components are developed in parallel by different people – often employing specialist skills
and tools. The number of people involved in projects and the many threads of activity creates
a complex project model that then requires expert project management tools, methods and
skills to orchestrate (PRINCE2 became the answer to this eventually and led to a whole new set
of skills requirements for companies to mince over).
Following development of the various streams of the waterfall, these are bound together and
formed into a final ‘end-product’. This approach has been fraught with project management
issues. Delays in any of the parallel developments causes the entire project to over-run. Often,
‘next steps’ of integration with third party tools and data, and activities such as testing and
tuning, can’t be progressed until the last thread of development has been done.
This can result in huge project over-runs and costs. The article ‘Why Your IT Project May Be Riskier
Than You Think’ by HBR (November 2011), that followed a survey of 1,471 IT projects with an average
spend of $167m, found that the average overrun was 27%, one in six of the projects studied was a black
swan, with a cost overrun of 200%. And almost 70% of black swan projects also overrun their schedules.
Even when projects do get delivered on-time, the consequences of using one or many expert
programmatic tools means that documentation is more complex, testing and tuning takes
longer, and more bugs are likely to be embedded in the code. EVEN should everything go
according to plan, the remoteness of intended system users and stakeholders to the back-room
development process means that resulting systems are difficult to get right as a perfect fit to
the user community. It’s quite an art to write a paper specification for a software application
and produce a perfect system right-first-time. More like impossible in fact.
A major challenge all development teams face is application users and stakeholders rarely know
PRECISELY what they need in terms of database management, reports, process workflows and
user interfacing requirements out-of-the-box. Normal domain expert business users find it
hard to visualize end-applications and often struggle to formalize their end-product in a format
that programmers can use.
Accepting the high resourcing costs, need for costly specialist best-of-breed tools, use and
constraints of coding and its impact on testing, tuning and adaptability, perhaps the biggest
issue of traditional waterfall development tools and methods however lies in what gets left
behind. Programmed systems are inherently difficult to maintain and adapt. Companies don’t
particularly want to be left with systems they can’t change over time, or that require a team
similar in size to the team that built the application to maintain it into the future (mainly
because of the dependencies created on a smorgasbord of best-of-breed tools and skills.
The step-up to AGILE SCRUM
Advances in Integrated Development Environment (IDE’s) since the turn of the century, aided by the timely
emergence of standards around enterprise web server computing platforms, has produced a number of
capable tool-kits to enable software development teams to work more closely together with fewer tools and
fewer expert skills. This reduction in tool-kit complexity has meant the project approach has been able to

3. From Agile Scrum to Codeless Workshops, Ian Tomlin
transition more towards a team-based culture where individuals working towards a shared goal can work
together in a collegiate way.
AGILE tools are so-called because they provide development teams with more adaptive tools that produce
results faster. One aspect of the ‘agility’ comes from using bigger building blocks of code that can be shaped
to fit a variety of needs but doesn’t require programmers to start with a blank page.
The SCRUM model has evolved around the need for members of development teams to keep in close contact
with one another and stay on the same page. More frequent reviews of progress – perhaps on a weekly,
even daily basis – ensures that the streams of development stay on-track and can be regularly check to
ensure the quality of the end-product is as it needs to be and that project managers can check time and again
that ‘what is being produced’ is ‘what the internal client wants’.
AGILE tooling does not provide developers with everything they need in one box. To improve the integration
and use of third party expert tools, software providers today normally provide an Applications Programming
Interface (API) so the various tools are EASIER to integrate with one another. While this is EASIER it remains
a major overhead on developments as each API tends to be different and developments inherit any
limitations presented by the ‘black box’ of functionality provided by the best-of-breed software they are
integrating with. This inability to interplay one application with another using the same properties means
that developers find themselves constantly having to come up with work-arounds to produce the best end-
product.
SCRUM has its limitations too. While it’s great for developer teams to work towards a common goal and take
more of an active interest in making sure their contribution is producing the best ‘total’ outcome, developers
continue to work in back-rooms and continue to lack an appreciation of the domain area they are building
applications for. Any developer knows the ‘last mile’ (i.e. managing the interaction with the user and
stakeholder communities) is the most difficult part of an application to get right as different user groups will
have very different expectations and needs from the applications they use.
Like the traditional waterfall approach, AGILE SCRUM still relies on coding and that’s a problem. Not only
does it install more post–development overheads are more bugs are built into the end-product, and more
testing, tuning, integration is necessary, it means that resulting applications continue to be expensive to
maintain and adapt.
The New Age of Codeless Development
So-called ‘codeless’ development software describes Integrated Development Environments that displace
the need for applications authors to code. The leading enterprise platform for this approach is Encanvas. All
of the building blocks required to develop enterprise applications are built into a common IDE. ‘Design
Elements’ - as they are known - adopt similar properties and have been designed to provide a sufficient level
of tailoring to fit the majority of needs.
At one time, it was thought that codeless platforms would be only good enough for piloting of projects or
serve ‘little application’ needs of the enterprise where larger platforms were too costly to use. The last
decade has shown however that IDEs like Encanvas are capable of delivering enterprise, pan-regional and
cross-industry applications to enterprise scale and levels of performance.
In the same way that a step-change in enterprise web platform standards at the turn of the century led to
the evolution of SCRUM methods for software applications authoring, use of codeless tools has led to the
formation of near-real-time applications authoring methods.

4. From Agile Scrum to Codeless Workshops, Ian Tomlin
With codeless software, the removal of the programming activity in project (and the removal of best-of-
breed tools and the need for APIs) has meant that users and stakeholders can be engaged in development
workshops where applications designs are iterated in consort with the users and stakeholders who are able
to see and understand what’s being authored because they see the ‘end-product’ being formed in-front of
their eyes.
Codeless software has dramatically reduced the number of tools and the variety of skills needed to author
applications, but its biggest impact is found in the leave-behind: resulting systems can be easily adapted as
business requirements and user needs change. Neither are there any upgrade costs associated with
software; platforms like Encanvas enable hundreds of applications to be authored and do not charge for any
new improvements to the IDE. This means IT leaders seeking to reduce the number of technologies they
support in their enterprise IT architecture can shrink their footprint from 100’s of tools to less than 10.
The bi-product of this change in technology tooling and methods makes a big impact on IT budgets. The
expectation of IT leaders now is that IT operations should cost no more that 1% of operating profits.
Deployments delivered through codeless workshop development methods demonstrate a factor of 10
increase in time-to-market and a similar dynamic in the lowering of onward IT costs.
Will the move from SCRUM to CODELESS be bigger or smaller than the move from
WATERFALL to SCRUM?
I would argue the move from SCRUM to CODELESS has a greater bottom-line impact but a lesser change
impact compared to the original transition from WATERFALL to SCRUM for the following reasons:
 Many IT departments have already shrunk their internal IT teams and now use contractors for much
of the heavy-lifting in software development and support. What the move to codeless does is
internalize the support of IT systems – making IT more adaptive and better able to support the long-
tail of demand for new or better enterprise applications - while displacing the use and cost of
contractors.
 IT departments are already using IDEs and reducing their use of specialist tooling. Platforms like
Microsoft .NET and Ruby-on-Rails have done much to consolidate tooling for developers. What
Codeless platforms do is FURTHER consolidate tooling.
 IT leaders are already finding ways to embed IT development skills ever closer to the domain expert
communities that use applications. What codeless software does is take development out of the
back-room into the front-office workshop so that developments produce faster, better results that
the users and stakeholders WANT to use because they were instrumental in the design of
applications they use.
 IT leaders are already rationalizing the numbers of technologies they support in the enterprise
technology stack. What codeless software does is further reduce the footprint of technologies
employed across the enterprise to install more commonality in development methods and tools.
Arguably the biggest change factor then with codeless workshop development lies in the impact of an IT
department being able to keep-up with the ideas and process changes of the enterprise. This has surprisingly
big organizational design implications. For decades people in the business have been able to BLAME IT for
failing to support their domain needs. Consider what happens when suddenly it does: No longer is IT the
scape-goat. Also consider the impact of embedding software development into improvement teams as some
innovative companies like AUDI GROUP already do. The analysts that scope and build the applications are
PART of the improvement team, incentivized by the impact of the process changes they manifest rather than
being paid for ‘writing code’. Departmental and operational managers will be inevitably more responsible
and accountable for IT as part of their function. They have no choice but to consider the performance of the
IT they use as being part of their portfolio of responsibility. The role of the CIO becomes one of guardianship
of IT resources rather than the deliverer of every single IT initiative.