Engineering the “Delivery model”

Whenever we engineer any delivery team, process or structure, we need to measure success by two factors, outcome they have achieved and habits they exhibit. Let’s elaborate what I mean by both Outcome and Habits.

Outcome

When engineering the delivery model for your team, following three factors should be considered as an outcome

outcomes

 

Habits – 7 Habit of successful delivery teams

I have covered what are the 7 habits of highly ineffective enterprises. So we should certainly avoid those. Also refer to embracing change and be aware of interpretations

This are the 7 habits of highly successful delivery teams that we should embed in the teams

  • Work smart – Always think of innovative ways to reduce waste and focus on automating anything which you do more than 2 times
  • Focus on Quality – Focusing on the smooth flow of work  and delivering high quality code. Never compromise doneness at each step of the work flow. But please note that focus is on Minimum Viable Product MVP rather than trying to go for a rolls royce
  • Self organising – make their own decisions. Rely on coaching from leaders rather than direct answers
  • Takes pride in Finishing Work rather than working multiple items in parallel
  • Openness – Be open, honest and direct to build trust. This is the way you will improve and your team will improve
  • Collaborative – Focusing on team’s performance rather than individual performance
  • Data driven – Rely on data over opinion or subjective analysis

Engineering the delivery model

Let’s look at the different phases in the delivery model, what they are, what are the recommended practices and impact on other teams in the enterprise organisation

sprints

The 4 common phases we need to understand are Define, Deliver, Acceptance and Cutover or Go live

Define

“Design is a complex, iterative process. Initial design solutions are usually wrong, and certainly not optimal”
  • The deliverable is scoped out and designed at the Define stage. The process begins with a workshop, bringing together key stakeholders, including software developers, operations team, testing, business analysts, product owners, project managers and architects
  • This is where we capture primary business driver for the change. This is broadly called EPIC as per scaled agile framework model (Relationship is EPIC -> Features -> Stories)
  • All documents produced for a product will be cumulative i.e. existing product documents will be enhanced to incorporate  these new requirements. For new projects this would be brand new set of documents.
  • Goal is to define features for each EPIC in this phase

Deliverables

  • Technical approach detailing impact to high level design and other systems
  • Features in alignment with Minimal viable production for a release
  • Testing approach , if there is any change from normal
  • Business value
  • High level estimates/points
  • Dependencies with other product teams

Impacts to other teams

Environment teams – Plan new environment if needed depending on the non functional requirements

Operations team – Define any operational acceptance test scenarios and come up with a list of alerts which need to be set up

Security – Identify involvement at future phases including need for any additional testing in the hardening phase

Performance – Identify performance impact and work towards mitigating the same


Delivery

This phase consists of majority of the activity necessary to produce an outcome. Input to this phase is the output of the Define phase. The phase is executed as series of sprints. Each sprint builds upon the previous one, allowing work to be validated and progressed. The top features of the backlog are picked up and executed. Definition of MVP may/will/should change as part of this phase as you learn more from the user feedback

Sprints can be conducted using scrum methodology and follow scrum ceremonies like Sprint planning, daily stand ups, sprint retrospective , grooming and reviews. Multiple teams can be folded into scrum of scrums for managing cross product team dependencies

There should be a common notion of “done”. “Definition of done” is a transparent and mutually agreed list of criteria that must be adhered to for the  stories to be marked as complete

All major testing including integration, component, system test are part of this phase. Acceptance test (please see below) and non functional testing should be started in this phase in staggered manner with the aim to complete as much as possible in this phase. E.g. acceptance test for Sprint 1 must be complete by Sprint 2, for sprint 2 in sprint 3 and the likes. Last sprint is the only one which should remain to be covered in the acceptance phase for the release

Epics are converted into stories with acceptance criteria and then stories is further break down into tasks. Each task should be as measurable as possible. Like if it is code then we should measure code quality metrics, code coverage, unit test execution and the likes

Also definition of done should be broken down into several done’s so it is easy to monitor the progress

Team

For multiple location scenario, communication is one of the most important things to be taken into account. Talk talk talk. You can never communicate less. Avoid too many emails and make use of phone or skype or google hangouts

For multiple vendor scenario, make sure you create an environment where they work as one team. You really don’t want people to have their own agenda otherwise you will drift from the main objective.

Deliverables

  • Convert Features into Stories with acceptance criteria
  • Updated functional specification documentation, wireframe/VD. This is quite important for multiple location teams and more importantly this will also serve your knowledge base for support teams and sprint teams for future development
  • Updated HLD or equivalent technical documentations
  • Updated automated testing scripts
  • Working code

Impacts to other teams

 Environment team – New environment or component needed will be provisioned

 Operations team – Operational service documentation updated

 Security – Updated tools or test scripts. Completed the assessment to be fit and not something which will damage brand

“The best programmers are up to 28 times better than the worst programmers” 

Acceptance

This phase accepts the MVP that comes from the ‘Delivery In Sprints’ phase. The product goes through rigorous testing by users and Ops. It is also tested to ensure that it complies with non-functional requirements. Typical tests done in this phase include the spill overs of the acceptance tests and Non functional tests (e.g. Volume & Performance, Availability etc.) for the stories completed in the last sprints.

By absorbing the majority of tests into the preceding ‘Delivery In Sprints’, the process is accelerated. It can be further sped up through automation. In advanced teams, approval can be automatic, further shortening the cycle.

End users and BA’s must be involved in the acceptance/regression testing so that complete E2E business process is executed

Volume and performance testing is conducted on the E2E flow to understand any implications

A high degree of automation is essential to ensure that the application moves through this phase very quickly.

Typically this phase should not take more than 1-2 weeks


 

Cutover or go live

In this phase, the hardened application moves into the staging environment. The environment is prepared with data from production. The solution is ‘sanity tested‘ in the staging environment and certified mostly by operations team. The existing sanity test suite is enhanced to include the new features. In mature organisations, this phase can be completely automated, although a small number of random checks will be carried out before it is cutover to LIVE

If there is any roll back needed then this is also practiced in this environment

Impacts to other teams

Environment teams – Start setting up production environment for the release

Operation teams – Get ready for the release with new monitoring, alerts set up, configuring existing tools etc


Optimisations

soptimisations

Define: Define phase should be based on the principle of  “good enough”. Try and cover as much as possible in the sprints

Deliver: In order to get most benefit of agility, it is imperative to do majority of the work in increments

Acceptance : Acceptance phase and cutover phase combined should be less than a couple of days in extremely advanced large organisations. Rule is “If it can be automated then it should be automated”

 

 

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s