accordion-arrow breadcrumb-separator btn-link-arrow case-studies-carousel-control-arrow-left case-studies-carousel-control-arrow-right case-studies-carousel-control-bg chess-piece cloud contact-close email-icon map-marker-icon mobile-nav-close phone-icon select-icon-arrow select-icon-tag service-transformation small-arrow smoothscroll-arrow top-right-arrow

Agility Lessons from recent experience

14th August 2019

Author Ankit Kumar

I have recently spent some time with clients in Agile project delivery and we’ve been true to the agile ceremonies – daily stand-ups, retrospectives, planning sessions, scrum of scrums.  We’ve also written user stories in the right syntax – Given, When, Then.  Hell – we’ve even done Fibonacci story point estimation and got our stakeholders on the journey of understanding these.  Definition of Ready, Definition of Done – you name it and we’ve implemented it.  On the surface – we’re Agile but are we really!!!  I’ve deduced three important lessons:

Lesson One:  Plan a better Sprint 0

Let me start by saying that there is no Sprint 0 in the official scrum guide.  However, we all easily incline towards calling it Sprint 0 since it creates an agile(ish) feel to starting work and it’s better than calling it Planning / Inception etc.

Regardless of what you call this phase – the outcome of delivering the project in an agile methodology should be kept in mind when considering the activities for this phase. 

Therefore, plan the lifecycle of an epic/user story for how it needs to be built, tested and deployed into production.  Remember we’re striving to achieve a potentially shippable product every sprint. 

Plan for:

  • Environments required to build, test and deploy. Does the scrum team have access/control over these environments.  If not, then the likes of Environment/Release managers, need to be engaged up-front. 
  • What integrations would be required. If it’s external vendors providing integrations, then have them involved in the scrum team
  • What is the path to production – deployment steps, DevOps strategy, Test automation.
  • Be flexible on starting development on loosely written user stories. Don’t get hung up on DoR and DoD.  These should be re-visited throughout the project lifecycle.  Not having all developers 100% utilised in the first sprint is a smaller price to pay than time spent down the line in re-factoring. 

Lesson Two: Hold true to the agile principle – every sprint should deliver something which is potentially shippable.

Make every effort to test your user story end-to-end.  i.e. don’t just settle for testing integration with mock-data, test api’s.  I can guarantee that each one of us have experienced problems with big-bang SIT/UAT testing after completing all dev activities – production interface/data never works the same as how it worked with a mock.  This will not only deliver Quality work but also far better customer/business engagement throughout the delivery lifecycle.

Lesson Three: Challenge the status quo

Every organisation has pre-defined processes and frameworks and all projects are expected to adhere to.  But remember that the people who have defined the processes and frameworks are usually prescribing industry best practice and it’s theoretical knowledge whereas the Do-ers have first hand experience on challenges with these.  Therefore, voice your opinion on the challenges you’re facing and your improvement suggestions.

I’m referring to challenges you may be facing around:

  • High Level Design documents to be signed off before build starts
  • Functional Spec document to be completed before user stories are written
  • Release notes to be documented before approving deployment into environments

Remind yourself and others of the Agile manifesto and spark conversations to have your project adopt these guidelines.


I’m sure that we all face challenges of sorts but if we’re tasked to operate and deliver a project in an agile manner – then the onus is on each project member to strive to be agile. 

All the best with your project delivery!