January 15, 2017

Bringing Peace Through Prosperity – reflecting on years past #SocialTransformation #Delivered

Peace Through Prosperity #SocialTransformation #Delivered

Theses are not bold hashtags! six years on Peace Through Prosperity’s programs, team and beneficiaries have delivered exactly that. Its Fact not Fiction!

For the unfamiliar Peace Through Prosperity aims to stimulate growth of micro-businesses operating in vulnerable or underserved communities, particularly those affected by conflict and terrorism. Peace Through Prosperity set out to empower individuals and to prove to them that they themselves can affect positive change and progress, to build a better future for themselves, their family and community.

The approach also provides a counter narrative to social transformation than that peddled by extremist organisations.

Peace Through Prosperity’s ethos is a leg up and not a hand out! Their mini-MBA and Coaching programs have delivered the desired outcomes:

  • Double digit revenue and profitability growth for the participant’s micro-enterprise
  • Created Employment within the micro-enterprises via business growth
  • Social mobility
  • Improved quality of life
  • Financial independence and awareness for the micro-entrepreneurs
  • Inclusion of participant’s children in mainstream education
  • Improved Self-esteem and sense of ‘right’ amongst participants
  • Improved understanding of and appreciation civic rights and duty

There are two artifacts from Peace Through Prosperity‘s programs that I’ll share with you here:

A) Financial data (revenue and profitability) for 304 micro-entrepreneurs from 11 communities in Karachi over a 6 month period (with month 1 used as a baseline) from the 2016-2017 mini-MBA cohorts (demonstrated 8% growth in revenues and 91% growth in profits):

Team Figure. 1. 6 months Revenue & profitability growth of BringPTP’s mini-MBA participants.

B) Before and after SWOT analysis conducted by the beneficiaries/participants themselves over the same period (demonstrating considerable transformation in soft skills and world view):

Figure. 1. 6 months Revenue & profitability growth of BringPTP’s mini-MBA participants. B) Before and after SWOT analysis conducted by the beneficiaries/participants themselves over the same period:

Figure. 2. SWOT analysis over the same period (click to enlarge)

This remarkable outcome is not a one off, Peace Through Prosperity‘s programs and team have delivered similarly outstanding and impactful results for 214 beneficiaries in 2014-15 in Karachi and for 150 beneficiaries prior to that in Northern Pakistan. 

In doing so Peace Through Prosperity (PTP) improves the local/domestic environment for peace by nurturing prosperity in engaged communities. Their programs demonstrably alleviates poverty, empowers micro-entrepreneurs with knowledge, skills, ability and increases 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.

Lastly please consider giving back by contributing to Peace Through Prosperity, you can follow, broadcast or donate.

January 9, 2017

Pause, reflect – lets celebrate journey of a team #SocialTransformation #Heroes

Team

What better way to spend a Sunday in Karachi than reminiscing and sharing Peace Through Prosperity (BringPTP)’s success with y’all.

Let me set the scene real quick!

2014

  • Peace Through Prosperity (BringPTP) brings its social transformation programs to Karachi. See this if you’re not familiar with BringPTP’s work.
  • BringPTP set’s about building the delivery team for what is to be the largest engagement in what is and remains a very challenging engagement.
  • Attempt 1 fails fast, and the delivery team is down to three! that reflection is for another post but it’s worth stating; for this program BringPTP hired MBAs, Tech and Social sciences graduates, of the seven hires all but one made the cut in the field, it was a brutal sprint and bloody retrospective!… and yes there was a lot of drama!
  • Attempt 2 yields a team of 9 all potential (very rough) gems, all hired from within marginalized communities they are soon to engage. There are two team members  with Higher Education qualifications, some have secondary schooling but others are only literate. None have ever been through any formal professional training of any sort or undertaken anything like this. Overall the team is hired on their street smarts, courage and a hunger for socio-economic transformation in their communities.
  • The newly formed team’s training and coaching lasts for two weeks with key areas of focus being; BringPTP’s programs and Agility (Scrum), Majority of the training and coaching delivered was in the field itself.
  • The team takes a cautious start to the project. There are many failures along the way, the team inspects, learns, adapts and keeps moving forward whilst delivering phenomenal, phenomenal results!
  • The team isn’t quite self organizing yet, but they are well on their way!

2015

  • The program concludes and is hailed as a huge success.
  • The learnings are flowed back into the program design, content and processes.
  • The team is inching closer to self-organisation… not there yet but doing better than expected!
  • Their very achievement begins to prick some folks the team had to interact with!… the issue is one of class unfortunately!  Where others with specializations in social development were (and remain) missing the mark BringPTP’s team was (and is) batting 1000! and delivering tangible benefits and a pathway to positive social transformation in marginalized and conflict effected communities.
  • BringPTP proposes an ambitious leap for the 2016-2017.

2016

  • BringPTP’s proposal is accepted and its on!
  • BringPTP rinses and repeats with a min. 275 and a max. of 400 micro-entrepreneurs to be enabled and empowered.
  • The team take on additional areas and more challenging marginalized communities to work with.
  • To work with a min. of 25 female micro entrepreneurs.
  • The 9 potential (very rough) gems, are now are lot less rough, there are new 4 additions to the team with min. resource turnover, with potential of reaching immense heights.

By December 2016 this team had delivered: mini-MBA classes to 547 individual micro-entrepreneurs of which 27 are female, delivered 17000+ hours of post-mini-MBA coaching and consulting to participants. They delivered the planned outcome and immense value!

The outcome : socio-economic transformation delivered!

Class of 2014-2015 over a 8 month period

Team
Figure. 1. Revenue & profitability growth of BringPTP’s mini-MBA participants.

Class of 2016-2017 over a 6 month period

Team Figure. 1. Revenue & profitability growth of BringPTP’s mini-MBA participants.

7th Jan 2017

The team delivered a ‘Peace Conference’ worthy of its title!
The Chief guests at the conference were the 300+ micro entrepreneurs in attendance who have been a part of the journey from 2014 onwards with us, the conference host was a career host of much acclaim, there were 16 news channels there to cover the event, lastly the event was at the Karachi Press Club.
None of the issues faced in BringPTP’s 2 previous large scale peace conferences were faced or ever became a point of concern, new processes introduced worked well!
Yes there were in-flight issues and big ones! all being actively managed by the team itself. To give you some sense of their woes…two guest speakers bailed out on the last minute! an occasionally over zealous host had to be managed with post it notes! and the one that concerned most was our entire cohort (from Lyari) missed out on the conference due to a security operation in the neighborhood.
 
 
The ‘proof of concept’ team has and continues to prove itself, it keeps pushing the envelope of their capabilities and the opportunities open to them!
 
 
Thank you Abdul Rasheed, Abdul Rasheed (Orangi Town), Abdullah Qureshi,Amjad Hussain, Ammad Aslam, Ashfaq Ahmed, Arsalan Siddique, Baber Qureshi, Faheem Qureshi, Imran Siddique, Mashkoor Ahmed, Muhammad Amin Memon, Muhammad Lateef, Nasir Shah, Rashid Ali, Ubaid Aleem, Umair Ahmed, Waqas Abbas for being a self organized, driven and committed team!
…and Thank you Sahar.
 
To infinity and beyond.. to peace and prosperity…

…………….

Lastly please consider giving back by contributing to Peace Through Prosperity, you can follow, broadcast or donate.

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 by 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.

October 8, 2016

Applying Agile beyond tech – key ingredients

Ingredient

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.