custom dot_Paint.Net

Agile Evolved

It’s natural to iterate. agile evolved from Esuasive couples the essential elements of good governance and project control with lightweight process and the speed, fluidity and visibility of agile software development techniques to accelerate software development.

agile evolved handles change naturally; iterative delivery, incorporating a 2-4 week software release cycle, allows requirements to be changed or reprioritized as the project progresses, and users are able to exercise a high degree of control over the functionality that is delivered in each release.

The agile evolved approach


No matter what approach you take, whether agile or traditional ‘waterfall’, some fairly standard activities need to take place at the start of any project. All projects are conceived to solve a business problem or to take the business forward. You need to understand project objectives and critical success factors; identify and engage key project participants; and define a plan to deliver what’s needed. In essence, you need to make sure that the project starts on a firm footing.

We don’t see why this should take a long time. In agile evolved, our Initialisation phase is short, sharp and focused. We normally complete this phase in days rather than weeks. We create a project brief (a variation on the Prince2 Project Initiation Document which better reflects the pace and flexibility inherent in an agile approach) which sets out objectives, scope, deliverables, etc.; define a high level plan, with milestone dates; establish reporting requirements; and agree the budget, along with financial controls. Our aim is to complete sufficient work to get started, but no more.


  • Project Definition workshop
  • Stakeholder workshops
  • User Stories workshops
  • Identification of Epics


  • Project Brief
  • Initial product backlog
  • High level plan
  • Initial budget estimate

Sprint Zero

Hardened agilistas advocate that iteration #1 should be just like any other; but in a corporate environment where people have day jobs and work needs to be scheduled ahead of time, that’s not always realistic. Sprint Zero is all about ensuring that the project team has just enough information to get started productively and safely on the Rapid Evolution phase. We will be scoping, registering requirements and developing the project backlog, as well as thinking horizontally, determining the application architecture and infrastructure requirements in consultation with your technical team.

Sprint Zero is sized according to project scale and complexity and the degree of up-front certainty needed over timescale and estimated cost. On a simple project Sprint Zero will be a fairly short exercise; we ratify assumptions, document key requirements, design the ‘user experience’ and determine the application architecture. On larger projects with many stakeholders more extensive interaction might be necessary to produce a reasonable set of elaborated, prioritized requirements as input to Rapid Evolution. We spend as much time as it takes to build consensus, gain commitment from the project sponsor and mitigate project risks to ensure Rapid Evolution can progress at pace.


  • Crank up / wind down
  • Planning poker
  • Agile release trains
  • Buy a feature
  • UX design workshop


  • Prioritized product backlog
  • Application architecture
  • Infrastructure specification
  • ‘Definition of done’

Rapid Evolution

Rapid Evolution describes our approach to software development: a controlled series of sprints which incrementally delivers high quality software which can be demonstrated to stakeholders and which forms the basis of a deployable release.

With a two-week sprint cycle, it’s easy to lose sight of the big picture. We use agile release trains to help stakeholders conceptualize what’s planned for inclusion in the next release. A typical release train is made up of four sprints, with the final sprint sometimes being a ‘hardening’ sprint focusing on integration testing and fixing. Typically each agile release train creates a deployable release.

The most popular agile framework is Scrum, and we follow Scrum best practice. However, Rapid Evolution can readily accommodate other frameworks. Similarly, we ensure our teams use appropriate modern coding and testing techniques. We are technology agnostic and agile evolved can be used to build applications on any platform, on premise, hosted or in the cloud.

Visibility of progress is crucial to stakeholder engagement and to retain the confidence of project sponsors. Sprint reviews go some way towards achieving this, but to encourage greater stakeholder involvement we introduce the concept of a ‘daily buffet’, where the development team is available over lunch to demonstrate the application as it evolves. This also helps stakeholders understand project velocity.

Transparency also extends to estimating. We estimate on an ‘open book’ basis as we recognize stakeholders need some sense of the cost of features to make decisions about what to include in any given release. To maintain flexibility without increasing costs we support the idea of ‘exchanging’ functionality, adding in new or more complex functionality by swapping out other functionality not yet developed.

This means we can configure agile evolved to deliver projects on a fixed price basis when corporate governance mandates strict adherence to budget.


  • Scrum
  • User stories
  • Planning poker
  • Agile release trains
  • Daily buffet
  • Sprint demo
  • Trade a feature


  • Working software
  • Deployable releases
  • Evolving documentation


Invariable on an agile project, after completing all of the sprints required to produce a fully working solution there will still be some tasks remaining before the application can be transitioned to ‘live’. Typically these tasks include data migration/refresh, end-to-end integration testing, non-functional testing (for example, penetration testing), user acceptance testing (it seldom proves possible to complete user acceptance testing during each of the Rapid Evolution sprint cycles) and resolution of issues which inevitably will have slipped through the net (proponents of ‘pure’ agile may suggest that this shouldn’t be allowed to happen, but we recognize reality and plan in the resources needed to deal with these in the Stabilisation phase).

This phase also offers an opportunity to ‘polish’ the application, for example by including low-cost cosmetic or simple usability improvements which can often dramatically improve the user experience and generate a strongly positive user response to, and take up of, the delivered application.


  • Release polishing
  • Final user acceptance testing
  • Penetration testing
  • Interactive training
  • Deployment dry run


  • Application ready to deploy
  • Approved deployment plan
  • Agreed training plan
  • Agreed support plan
  • Finalized project documentation


During transition, the application is implemented into the ‘live’ (production) environment. Typically this will include user training, training of support staff and completing any necessary support documentation. A disaster recovery test may also be required.

Transition typically also includes immediate post-go-live technical support and desk-side user support, until such time as the application is incorporated into the ‘business as usual’ portfolio. Extended or long-term support is also available for customers who do not have the capacity to support the live application in house.


  • Project retrospective
  • DR planning and test
  • Operational acceptance


  • Application implemented into live
  • Supporting documentation
  • Support processes implemented