Monday, February 22, 2016

Civic participation, gamification and open government


On Saturday, my volunteering experience at “Community budget priority setting” event San Jose, CA was amazing. It was an eye opener. It just demonstrated that with interesting game a great civic participation can be ensured.

To promote open governance and residents budget preparation exercise, San Jose city is organizing a series of events. In this series, yesterday’s evet was first one. All residents of San Jose city, 12 years and older were invited to participate in game where they can allocate money ($64 M) to thirty items for “Neighborhood Services (Aesthetics, Beautification, Anti-Blight)” budget head.

The game was pretty straight forward. In Parkside Hall tables were arranged to accommodate eight hundred residents.  On each round table, there were ten seats. First two seats were for volunteers - facilitator & observer and remaining eight seats were for participants. Each table had $64 M which will be evenly distributed among residents. Each resident was provided list of items under consideration, its impact (benefits), and FY15-16 budgeted amount. In this list high ticket items were listed first. The allocated time for the game was approx. 90 minutes. During this duration, each resident has to fund items of her choice – fully or partially. She also needs to persuade other residents to fund items of her choice. Residents can choose to defund any item or increase the allocation assuming more money will bring more benefits.

Facilitator job was to maintain the money allocation across residents and items. Since residents supposed to change allocation as they discuss more about various items, so he was provided be recoding sheet, pencil, eraser and calculator.

Obliviously, observer ‘s job was to observe how discussion is progressing, which item is consuming more time, what type of discussion is taking place, etc. He was also provided an observation sheet to record his observations.

Apart from listed thirty items, residents can add two more items (per table) to the list and allocate the money. But total money on the table remain same - $64M.
The engagement level was fantastic.

The next phase will be online version of the same game. I am waiting to experience one more burst of constructive civic engagement and power of gamification in open government.

Tuesday, February 9, 2016

Agile team – empirical vs scientific methods

As we all know that human behavior does not follow strict rules. At most some statistical model can be used to model approximate human behavior. Complexity increases exponentially as more people enter into and environment has many dynamic known and unknown dimensions. On the basis of statistical model if someone attempts to predict behavior of a team member, naturally lot of probability come into play. Instead of such a scientific method, empirical analysis and model fits better with human behavior due to cost and time factors.

For any successful team (scum or not scrum), I prefer to use analogy of navigating a yacht which requires continuous adjustment to reach a destination even in calm water.

In any sufficiently complex software engagement diverse skills are required. This requires team to be consisting of generalists and specialists. This specialization breaks scrum on surface which assumes that team members have broad skill set. This may not be true when team gets formed. Team members may not have T shape skill on day one but certainly can develop (provided team sticks together long enough). If work required high level of specialization, Spotify like model (guild) may be helpful.

Monday, February 8, 2016

Agile Transformation in nutshell

Agile transformation is huge exercise and depends upon lot of factors like:

·         Size or organization;
·         Is it a department or whole enterprise?;
·         Existing work culture;
·         Business domain;
·         Existing organizational structure;
·         Degree of agile buy in at executive level; and many more

Lot of folks ask, what are the steps to transform an organization. My answer starts with famous line
“It depends”
Then I start my blabber.
I prefer to start small (one or may be two scrum/Kanban teams). As number of team grows adopt scrum of scrum (or nexus). Depending upon teams’ feedback, management feedback, business domain, technical complexity, and future vision adopt LeSS or DAD or Spotify Model. In mean times continues the transformation and keep on adding more teams in agile fold (major development, support & maintenance and minor development engagements – Scrum and Kanban). As teams get start working in scrum and Kanban,  tearing down boundaries of dev and support teams and start merging them into DevOps model ( major development efforts still work in scrum mode with few members from DevOps teams depending upon capacity of devOps teams). In parallel transformation of PMO into more agile friendly is continuing. Once sufficient momentum is acquired choose tweaked version of SAFe or LeSS Huge.
Again, these are guidelines not the steps.

Saturday, February 6, 2016

How to integrate DevOps and Agile Teams

o   Convert development teams into scrum/Kanban mode
o   Convert support and maintenance teams into Kanban mode
o   Merge support and dev teams
§  Cross train ream members ( T shape skill especially w.r.t. Dev and support work)
§  For small development work/project DevOps team will be loaning members
§  For big projects, if devops team cannot supply all members required, few members are supplied.

Friday, February 5, 2016

Release planning in nutshell

·         Say release cycle is 3 months and sprint cycle is 2 weeks
·         In the back ground PO should be in consultation with stakeholder for assigning business values to features and stories and also prioritization of product backlog items
·         During grooming sessions PO will be discussing PBI with respect to ready status and stakeholders view
·         PO consults dev team for approximate number of items should fit in next 3 month worth of sprints (past velocity, change in environment  are also considered)
·         PO negotiates items of next release with stakeholders -   considering business priorities, team’s capacity & discussion outcome.
·         PO, DevTeam and stakeholder must have shared understanding of release content and must communicate to each other if any change deemed to arise