Managing Design and Production Implementation considerations with the Scrum process

While Scrum and Agile development practices work very well for functional software development, there are two aspects of most projects, especially new ones, which fall outside this fluid and iterative approach, if for no other reason that they cannot be contorted to well-formed user stories and hence testable, acceptance criteria. These two aspects are as follows:

I. Design & Layout (D&L)
II. Production Implementation (PI)

In the context of this article, we define the Design & Layout (D&L) phase as purely aesthetic. And although there is most certainly a large degree of iterative and synergistic interaction with the Product Owner [client] when elaborating the various facets of this work, it should not be treated in a sprint context for the aforementioned reasons of expected results (testability) and objectivity (acceptance criteria.) With this in mind, Minerva Group does not include D&L as part of our normal scrum process anymore [**].

With regards to [initial] Production Implementation there are also many practical constraints to including this in the scrum process. First and foremost is the typical lack of working production environments at the outset of a project. Likewise, many clients do not initially understand the sundry technical requirements of even smaller scale custom software platforms, and thus need time to learn about them and make an informed choice when dealing with the sometimes difficult decisions with regards to choosing hardware and data center vendors and configurations. Lastly, many times it is not until the final development sprint has been completed that the full picture of processing power and external dependencies (third party modules, plugins, libraries, etc) is fully realized and thusly only then can a practical assessment of needs be made and recommendations submitted to the Product Owner. On a corollary note, many times Product Owners [clients] have worked with a particular vendor or hosting provider in the past which only adds to a sometimes tense situation in which they question the need for any further production assessment, configuration, adaptations, etc in the face of past experience.

So how do you handle these two distinct challenges?

Most importantly: manage expectations!! Always be up-front and honest about what both processes entail and the goals for the end results. If and when possible, just like scrum, jointly develop a rubric for both processes and the definitions, or expectations, of their outcomes. Obviously the production aspect can be much more objective than the D&L, but even then, subjective expectations can still be established and achieved by agreeing beforehand to a framework and methodology to follow.

Design considerations
* Examples of taste and aesthetic concept
* Number of design proposals / revisions
* Granularity of design proposals / revisions: do they get to choose the overall design aspect and your designers will then implement based on that or will they have a finer choice of fonts/sizes, buttons, form fields, etc?
* Self-sufficiency: does the client have any graphic design or layout experience? Do they know basic HTML & CSS? Will they want the application / system to be [aesthetically] user or admin configurable? (If this is the case, then most certainly this can be worked into the regular scrum development process.)

Production considerations
* Usage (projected initial load, concurrent users, synchronous/asynchronous processes, etc)
* Redundancy & fail over implementation
* Backup & recovery scenarios
* Security (hard & soft)
* Professional support (sys admins, dba's, network engineers)

Now these are far from exhaustive and comprehensive lists which we have distilled for illustrative purposes, but at the end of the day, regardless of the format of your particular proposal, you will have to break out these considerations into initial and recurring costs. Only then will your Product Owner be able to make an informed decision.

In summary, we at Minerva Group now offer these project phases as fixed-cost “add-ons” to our normal scrum / sprint development process. It ultimately has the benefit, for both client and provider, of isolating unforeseen dependencies and changing time frames inherent with both Design & Layout and Production Implementation.

** In the past we have included D&L in sprint planning by assigning story points with specific tasks for our team, but the results have been mixed at best. Ultimately we found that timing and interdependencies on the Product Owner or client have been the major inhibition to fulfill these user stories to the expectations of all parties involved.