October 8, 2016

Applying Agile beyond tech – key ingredients


This post started of as an email to Yashin Lin from Elizabeth Glaser Pediatric AIDS Foundation, Yashin reached out for advise on applying agile practices in non-technical teams in the social/international development sector.  This post is a guide I intend to keep building on, so do check back for updates or subscribe to be kept updated.

Introducing agility to teams, programs and organisations is less about selecting the appropriate agile framework and more about changing the culture, mindset of the teams and the organisation designing and delivering such programs of work.

Agile is a mindset, a worldview, not a set of how-to’s. However there are procedures and practices that teams in the development sector can borrow from Agile frameworks;

  • to introduce agility to their teams and programs 
  • to curtail waste and inefficiencies,
  • reduce time to market and ‘take-to-market’ costs
  • improve the design, delivery, monitoring and impact of their teams and programs.

At Peace Through Prosperity we have borrowed practices and tools from multiple agile frameworks to do just that. These are as follows:

1) Persona development and Empathy mapping to develop a deeper understanding of our target audience and their ecosystem. These tools have been invaluable in our ability to identify specific pain and touch points for our target audience and provided exploratory avenues/options to address them from a holistic point of view.

“Poverty, radicalisation, corruption, crime and extremism do not exist in silos, neither should transformative programs designed to address them.”

2) Touch point analysis to understand the multiple channels that can be utilised to engage our target audience (beneficiaries), as well as wider stakeholders and actors in the ecosystem to address a range of direct and indirect issues from financial inclusion to re-building the trust between marginalised communities and state institutions.

Social transformation is underway, we must align with a range of actors and stakeholders to course correct it to get to a desired and acceptable place” 

3) Möbius Loop / agile hot-housing to explore the issues with a cross functional team representing the ecosystem and it’s multiple actors and stakeholders. This approach has been invaluable, it has helped us improve the inputs to our discovery and the output of the design phase for our development programs. Although most program designs take a holistic view Möbius has allowed us to frame the challenges, options, programs, metrics and processes to inspect and adapt in a holistic canvas.

“Those familiar with Soft Systems will find many parallels between Rich Pictures and the Mobius Canvas, those not familiar with Rich Pictures from Peter Checkland’s Soft Systems Methodology, I would highly recommend reading up on it.”


4) Taking a minimum viable product (MvP) approach minimised cost and time to market for our programs. Combining a fail fast, inspect and adapt mindset allowed us to experiment with a variety of mini-projects and engagement models at the grass root level that have all lead to improvements to our main program body. Improving our ability to focus on and deliver desired impact through experimentation and incremental improvements.

5) Using Kanban boards has enabled the team to better manage work load and maintain program visibility across multiple program streams. WiP limits have been particularly beneficial in identifying bottlenecks before they become an issue and to shift resources to address them as and when identified.

6) The concept of an incrementally refined Product/Program Backlog continually proves to be invaluable in decomposing a mammoth undertaking into ‘digestible’ chunks, and to continually add to it, priorities it and track progress. User Stories continually prove to be a powerful tool in engaging our own team as well as our target audience, actors and stakeholders in the ecosystem.  In fact Peace Through prosperity’s own origin began with an Epic:

As a responsible and enabled global citizen I want to package and disseminate appropriate knowledge, tools and frameworks to grass root activists so that they are able to course correct the transformation of their communities.


7) Sprints (2 week time boxes) have been invaluable in focusing the team on short term goals and decomposing a mammoth undertaking into ‘digestible’ chunks. As well as building up team courage, commitment and visibilty to their own ability to impact affective change. Likewise ceremonies such as sprint planning, review and retrospectives have all played their part in enabling the Peace Through Prosperity team in delivering impactful work for the communities we work with.

8) Pairing (pair programming) has proved to be effective in building trust and commitment within the team. Of note is the team’s composition,  a very diverse group often at odds along ethnic and linguistic lines from the same marginalised communities Peace Through Prosperity works in. In plain English this practise equates to pairing individuals on tasks. We have found pairing to be an effective tool to build trust, openness, provide security in unfamiliar neighborhoods and communities as well as to reduce on-boarding times for new hires.

9) Daily standups have been invaluable in keeping the team focused, coordinated and able to provide on-demand support to eachother. Our field teams work in different parts of the city amongst different communities under varying types of socio-economic and civic pressures. Whilst sub-teams are responsible for particular neighbourhoods and communities, daily synchronisation allows sub teams to jump in and assist their peers as and when required in neighbourhoods beyond their direct remit, as well as benefit from the wisdom of the wider team to overcome blockers to their tasks and progress on any given day. 

10) Retrospectives – fortnightly sprint retrospectives have allowed the Peace Through Prosperity team to pause, inspect their progress and milestones in flight and adapt for the next sprint accordingly.

Its easier said than done, I plan to pen a post on my own experiences of introducing, nurturing an Agile mindset, values, practices and tools at Peace Through Prosperity, but that’ll have to wait for a bit. In the mean time I’d recommend deep diving into the tools I’ve posted above, get to know them and assess their viability for your teams and programs. Run a pilot, start small, learn, inspect, adapt and if possible engage an Agile coach to facilitate your journey towards agility.

If you are introducing Agile in a team or organization in the social/international development sector, feel free to reach out to me over Linkedin and/or Twitter, I will as and when possible make myself available for a call to assist you where I can (commitments permitting).


Lastly, If you got value from what I have shared please consider giving back by contributing to @BringPTP, you can follow, broadcast or donate: http://gofundme.com/bringptp.

Peace Through Prosperity (PTP) improves the local/domestic environment for peace by nurturing prosperity in conflict affected geographies. PTP alleviates poverty, prevents radicalisation through empowering micro-entrepreneurs with knowledge, skills, ability and increasing their access to income and opportunities. PTP supports small businesses, owned/managed by vulnerable and marginalised individuals/groups in society.

PTP is innovating social transformation program design and delivery by using Agile frameworks to create and deliver low cost, immediate and lasting impact social development programs in ‘at risk’ communities.

July 30, 2016

A product owner’s guide to writing acceptance criteria for user stories

‘I want to create a practical guide for product owners to facilitate them in writing acceptance criteria for user stories so that their output is of value to the scrum team’


You’ll find pages after pages describing what an acceptance criteria is and how to write a good one, what it should include or not, however this post takes a practical approach for Product Owners to follow. You’ll find post after post describing how product owners ought to use Gherkin script to develop/write an acceptance criteria, which in my opinion is not a practical approach, there are a few things wrong with that approach, a few come to mind right now:

a) not many product owners know Gherkin script and it’s unreasonable to expect them to adopt it when the team itself is better placed to translate their acceptance criteria into Gherkin. Doing so has its merits, the team has to analyse the acceptance criteria and develop Gherkin based test scripts from it, furthermore the product owner’s velocity for producing acceptance criteria is hugely improved as he/she is defining the fitness for purpose in a natural language.

b) calling out a product owner to write acceptance criteria in Gherkin or in a scripted fashion is prescriptive and goes against an agile approach, which is based on practicality and common sense. The Scrum master and team’s role is to facilitate the process, don’t assume your product owner can script!

Now that my preferred approach is set, lets dive into it:

For the newbies; acceptance criteria defines the intent of a user story, and is used to confirm if the user story is fit for purpose; the user story does what was intended, if so then the user story is complete. If you’re new to user stories please go here first.

Acceptance criteria must be developed by the product owner, it can be facilitated by the Scrum team but it’s responsibility must rest with the product owner.

The Scrum team’s expectations of the product owner to develop acceptance criteria must be realistic.

Things an acceptance criteria must cover (where relevant); usability, exceptions, desired output if the US is data driven, error handling, UX requirements, validations, any security and performance requirements as well as the function it’s seeking to validate.

Furthermore where applicable insist that the PO adds a wireframe or screen grab of the desired outcome for the user story. For those of you interested in a working example, there is one detailed out at the end of this post.

For those wondering when an AC needs to be in place…. It’s part of your DoD for the user story itself, your user story is not ready for technical decomposition or estimation without an acceptance criteria. 

For product owners looking for guidance to write acceptance criteria, a starter for 10:


  • Focus on the what and not the how – the team is not looking for a ‘solution’ from you as the product owner, just the ‘what’ is it that you are asking of the user story.
  • Keep the end user (and user acceptance testing) firmly in focus, it’s their point of view and value you are representing.
  • Develop acceptance criteria as a set of statements, each clearly stating a pass/fail outcome.
  • Specify both functional and non-functional requirements.
  • What are your security and performance requirements, need it be real time data display? Is the data sensitive?
  • Start with a sketch of what you are asking for, remember a picture paints a thousand words! 
  • There is no such thing as partial acceptance: either the acceptance criteria is met or it is not.
  • What is your user story? Think about what your want is? Can it be visually displayed? Is it related to display of data? Sketch out the different data entities (columns) you want to see, do you need to sort the display/view of data? Think it through in detail.
  • Is it a form to capture data? What data entities do you want captured? In what format? Think about what you don’t want in those fields (restricting input types), how would you validate the entries, what are the validation business rules?

This is a starting point for you and not a comprehensive list of do’s and don’ts, be pragmatic, and discuss the acceptance criteria with the Scrum team and your end user representatives; ‘conversation’ is a critical component of a user story and one that helps product owners bottom out the details of a user story’s acceptance criteria.

Your acceptance criteria must be acceptable to the Scrum team, if not then your acceptance criteria itself is not fit for purpose .

A tale from the trench

Our product owner’s requirement early on in the discovery stage was: ‘I want a login page to authenticate users on the site.’

So our user story would have been a simple one: ‘As a user I want to sign in to the site from a login page so that users can be authenticated.’

Then we began the deep dive conversation with our product owner; so what’s your acceptance criteria for the requirement?

and what we got was:

  • From on any page be able to access the login page via a sign in link.
  • On the site when I click the ‘sign-in’ link, I am re-directed to the login page where I can enter my email and password for authentication 
  • Upon successful login, I am re-directed to the homepage.
  • On the homepage my first name is displayed in the upper right hand corner along with the date and time of my last login.
  • If I enter an incorrect username and or password I should see an appropriate error message indicating my credentials are incorrect.
  • I should be able to retry authenticating myself three times before I am locked out of my account and must reset my password to unlock my account
  • My password needs to follow the company password policy for secure passwords
  • I must also see a link which allows me to re-set my password.
  • I must also see a link which allows me to register is i am a new user.

Can you spot the increased/emergent scope creep in the acceptance criteria as detailed by the product owner above?

Having seen the scope balloon we asked our product owner to sketch a wireframe for the login page, we were convinced there will be more that will emerge from a wireframe.

The wireframe sketched out by our product owner:

Login page wireframe  

Can you spot further scope that has emerged from the wireframe? How often has the above played out for you and your team? 

We discussed the need for the additional user stories to capture the emergent scope  as well as the necessity of keeping the acceptance criteria for the original user story narrow to the user story itself. The conversation helped us identify additional user stories we needed to capture.

Having been through the exercise/discussions our product owner revised the acceptance criteria and the package looked like:

The User Story:

‘As a user I want to sign in to the site from a login page so that users can be authenticated.’


Its Acceptance Criteria:

  • On the sign-in page I can enter my email address and password and submit it for authentication.
  • My password needs to follow the company password policy for secure passwords
  • Upon successful login, I am re-directed to the homepage.
  • If I enter an incorrect username and or password I should see an appropriate error message indicating my credentials are incorrect.
  • I should be able to retry authenticating myself three times before I am locked out of my account and must reset my password to unlock my account.
  • I must also see a link which allows me to re-set my password.
  • I must also see a link which allows me to register is I am a new user.
  • I must see a CAPTCHA to protects the site against bots

The above user story and its acceptance criteria is independent, negotiable, valuable, estimable, small and testable within a single sprint, it is a user story and not an Epic that our product owner’s wireframe represented.

“Acceptance Criteria should not go beyond the scope of the user story, if so then additional user stories need to be captured that define the feature ‘wants’.”


Well thought out acceptance criteria help us better understand the original scope, the emergent scope and create a contract with the product owner on the user story’s completeness and acceptability.

Lastly, If you got value from what I have shared please consider giving back by contributing to @BringPTP, you can follow, broadcast or donate: http://gofundme.com/bringptp.

Peace Through Prosperity (PTP) improves the local/domestic environment for peace by nurturing prosperity in conflict affected geographies. PTP alleviates poverty, prevents radicalisation through empowering micro-entrepreneurs with knowledge, skills, ability and increasing their access to income and opportunities. PTP supports small businesses, owned/managed by vulnerable and marginalised individuals/groups in society.

PTP is innovating social transformation program design and delivery by using Agile frameworks to create and deliver low cost, immediate and lasting impact social development programs in ‘at risk’ communities.

January 19, 2016

#DPSX Jan 2016 meet up – Drupal Distribution for local government

DPSX-jan-2016 Our January meet up was in the making since the #DPSX BoF at DrupalCon Barcelona in September 2015, the sign up for the 13th Jan event was great but logistical challenges mid December left quite a few folks confused. In retrospect the meet up needs a permanent abode, if you’d like to host the next meet up please get in touch.

Despite that the turn out was good, we had 11 from a possible 29 and one late arrival found the venue doors locked! apologies Chris, have expressed much annoyance with the venue management.

We had Greater London Authority, Crawley borough council and Lambeth Council representing the public sector along with folks from the Drupal community.

The theme for the evening was ‘A Drupal Distribution for Local Councils’ though discussions as always went beyond the theme, other subjects that made for a lively discussion included Agile colocation, G-cloud for local government procurement, user lead design and next steps to making a local gov distribution happen!

A Drupal Distribution for local councils in the UK

Obvious place to start the conversation was GovCMS, as it turned out Andy from Lambeth had a look but did not go with it, likewise the general consensus was there is too much there for a local council and by the time you’re done stripping stuff out and adding to it you’d have forked it significantly! and of course there is the ’not invented here’ factor too. GLA tried Panopoly with one supplier only to have the next one rip it out, which turned out to be the right decision for GLA.
General reluctance towards distributions; few found them to be cumbersome and perhaps best suited for proof of concepts and demos but not the real thing. Consensus was getting to a distribution for local councils in the UK ought to start by utilising a local council’s existing platform as the base, the requirements are likely to follow the 80/20 rule – 80% common across and 20% custom, with the custom requirements most likely to be integrations with back end systems. Questions raised included which council’s platform would be the base? this would require a discovery, setting out a minimum viable product (MVP) criteria, an evaluation criteria, getting buy-in to the concept, evaluating contenders etc.. the other key aspect to consider for a local council distribution is keeping it minimal! if overloaded with features it will fall by the wayside as cumbersome.

The discussion went on to how could we make it happen? Chandeep is certain there is an initiative in the making (shall reach out to the local community to explore further) and if you happen to be involved in it please reach out to the #DPSX community here. A to do for me is to reach out to Ben Goward from Westminster, Kensington & Chelsea and Hammersmith & Fulham councils and explore their initiatives on shared digital platform and services. For the next meet up it would be invaluable to get a few more councils represented, explore if there is an initiative on a local gov/council specific distribution and to put in a process to capture the minimum viable product (MVP) criteria. Shall update everyone with a followup post as and when I have news either way.

For this post I will pick one more topic from our meet up to keep it brief, that being User lead design at local councils and making the most of the Government Digital Services’s (GDS) user testing lab and services. Agile co-location and G-cloud shall share in separate posts. 

User testing and GDSs research lab

Graham informed the group that GLA placed a great deal of emphasis on ensuring the solution followed user lead design principles and practises, and for that the GLA called on the Government Digital Services’s (GDS) user testing lab and services, GLA accessed the GDS testing lab and had the benefit of working with the GDS’s design team. This is a huge takeaway for all local Gov representatives reading this post, for local council product owners it would be hugely beneficial to enquire that sort of access and service costs, or reach out to the GLA to share the learnings. I’d like to point out to an earlier post on better understanding your jury (your users), and if you’d like to learn more about persona driven user journeys then you’d benefit from the following resources:

This is relevant to our conversation on distributions too, for most if not all distributions appear to me as engineering lead, whereas they ought to be user-need / problem-solution driven. If approached from the problem-solution view I have no doubt we would have leaner, more focused distributions that address vertically focused user needs which in turn would mean increased uptake, lower cost of ownership and quicker release cycles. A valuable exercise to under take would be to develop a empathy map for local councils to identify their digital behaviour as an organisation, I sense a #DPSX workshop evening in the making!

The resolution for 2016 is to hold more frequent DPSX meet ups and with that in mind I’ve set up a meetup.com group which ought to make it easier to coordinate and grow the community, you can sign up and keep track of our meet ups here. The next meet up is planned to coincide with Drupal Camp London, we’ll be holding a BoF at Drupal Camp London (4-6th March 2016) (details to be confirmed).

Lastly I’d like to thank our sponsors Acquia and FFW for their support with the venue and refreshments for the evening.

December 1, 2015

An Engagement Manager’s Guide To Site Building In Drupal 8 – Week 04

This week a lot got undone, broken, recovered and then some.

Day 1

Worked on the product backlog, not quite ready for public consumption yet but getting there, sprint backlog for the week:

  • Shop for VPS
  • Setup VPS 
  • Migrate to VPS
  • Fonts – via CSS
  • Sort out Contact Form (emails not working)
  • Sort our Domain name and DNS stuff (may need an expert’s assistance)
  • Backlog grooming – WIP

Acquia Cloud Professional would be nice, would make life much easier, support would be kick ass (and needed) but is out of my budget! time to count the pennies and find a candy store that fits the budget. Bluehost.com or DigitalOcean.com…. went with DigitalOcean, gives an SSD, quite a bit of computing power on a budget, has no developer tools though, will need to get devops help and learn some devops stuff myself (kind’a and kind’a not looking forward to that) but hey you get what you can afford!

Day 2

  • Added an SSH key, instructions easy enough to follow
  • Am in as root! (nice!)
  • its an Ubuntu VPS, LAMP stack, phpmyadmin installed
  • explored setting up DNS and nada – haven’t got time for this, my sprint capacity is significantly reduced this week and possibly the next too! can’t wait, time to call in devops help, Asim enlisted to help set up DNS for agileforpeace.com for the VPS and opensocial.agileforpeace.com for my social transformation site (thank you Asif)
  • With not much to do, dived into CSS architecture (for Drupal 8)… 10 mins later… need to find an idiot’s guide to CSS in Drupal!
  • Had good wins today, the fear of the terminal is dissipating.

Day 3

  • Need to migrate my site from Acquia Cloud to the new VPS environment.
  • Installed backup and migrate, activated it and disaster strikes! backup and migrate broke the site and can not access the extend page to uninstall.


  • Looked up uninstall backup_migrate using Drush since I could not access the extend page – nada!
  • But if I go to an invalid URL it seems to work but can’t access anything in the admin menu, insanity!


  • Tried disabling using Drush (drush dis -y backup_migrate && drush pm-uninstall -y backup_migrate), did not work, tried a bunch of stuff, whatsoever google threw up as candidate solutions.
  • Decided to take the simplest option and restored the site from backup on Acquia insight, easy enough.
  • I’ll take the small win and call it a day!

Day 4

  • Started day 4 with a nice surprise, my first contribution! wooHoo.. the joy of little things!
  • It was a tough start, forgot my admin password again (blistering barnacles)! and remained locked out for the a good part of the timebox! tried a number of suggested means to recover the admin password using Drush, it was one fail after another! eventually reached out to @Dakku for help and it turns out its a pretty simple process!
  • Attempted migration from the DB back up – something migrated but not quite, need to figure out what went wrong, the theme didnt quite work even though its Bartik straight out of the box, am beginning to have doubts about maintaining a VPS by myself.

Open Social Broken 001

  • Am back in but am out of time, more on day 5.

Newbie Tip: reseting admin password

  • bulb In terminal type: cd /var/www/html/yoursite.dev/docroot/sites/default
  • Once in the directory, type: /usr/local/bin/drush8 uli
  • You will get a return value that looks like: /user/reset/1/1448057351/JY2957SilWctPfNfN1gUQ2bT5lS-NvCwjt3heDqdu5A.
  • Copy everything from “/user/….” onwards and paste it after your domain in the address bar in the browser e.g. http://yourdomain.com/user/reset/1/1448057351/JY2957SilWctPfNfN1gUQ2bT5lS-NvCwjt3heDqdu5A
  • Go to that url, this is a one off password change process, you can reset your admin password.

Day 5

Decision time! I can spend time building my site in D8 with dev tools to support me (on Acquia Cloud) or I can build without them and pick up needed devops skills to manage my VPS; time being the deciding factor am ditching the VPS route and will continue with Acquia Cloud, as for affordability found out as an Acquian I get an environment as an employee benefit! wooHoo! Though it seems this week was not as productive but got a couple of nice wins and picked up some more Drush (the fear of the terminal is dissipating! BTW DrushCommands.com is a pretty epic resource).
Retro time

      • Shop for VPS
      • Setup VPS –
      • Migrate to VPS (theme isn’t working)
      • Fonts – via CSS
      • Sort out Contact Form (so that it sends out emails)
      • Sort our Domain name and DNS stuff (may need a subject matter expert to assist)
      • Backlog grooming – WIP

Having decided to stay on Acquia Cloud I can focus on the site backlog in week 5, (mental note: need to pick up the MVP backlog items soonish).

One more option to look on her packing at it levitra vardenafil it of course to take not so simply because a form another and there is a wish to hold in hand her not so strongly. You can carry by me on a wide field.

November 28, 2015

Open Source and Cloud beyond tech – Keynote at DrupalCamp Bulgaria Nov 2015

logo_small_sx_1 The keynote at DrupalCamp Bulgaria was planned to be left field from the get go, however it went a little further out after Paris came under attack on the night of the 13th of November 2015.

#JeSuiBaghdad #JeSuiParis #JeSuiBeirut #JeSuiChibok #JeSuiKarachi #JeSuiMadrid #JeSuiDamascus #JeSuiAnkara #JeSuiLondon Dalai Lama Quote 2015 #JeSuiMali the list goes on, but other than on the bench solidarity what are we doing as individuals, as a community to facilitate and help build a better safer, cohesive and a pluralist society?

As a FOSS community we are constantly talking of give-back but are we engaged enough?

How could we take the strengths and learnings that make us a successful tech community to wider non tech audiences with a view of creating social transformation that addresses the needs of our societies in these turbulent times. What can we learn from the transformation FOSS and the Cloud has had on our ecosystem as technologists and how can we export that beyond tech to heal and build a stronger society?

I have more questions for discussions than answers however there is an inflight and successful start made by Peace Through Prosperity using Agile, Open source and Cloud to deliver social transformation programs that could be a starting point for the Drupal community to engage with in their own geographies. The open source component of this program is in development and work in progress can be seen here, if you’d like to contribute and #GiveBack beyond our bubble please get in touch over Twitter or Linkedin.

Links shared within the keynote slides:

The presentation from the keynote:


One more option to look on her packing at it levitra vardenafil it of course to take not so simply because a form another and there is a wish to hold in hand her not so strongly. You can carry by me on a wide field.