Digital & agile adventures in Africa

[agileafrica]

Different teams should work in different ways

Is it ok that we do this differently to my last team?  My last team were good and we did good things....

Yes.  It's almost essential that things are done differently between two teams even if you think those teams are very similar.

“Agile processes are generative, not prescriptive. Processes need to evolve as needed, not be prescribed up-front. A prescriptive approach generates complex and complicated processes whereas a generative approach begins with a set of simple processes and adds others as they are needed.” - Jim Highsmith 

"A consequence of self-adaptivity is that you should never expect to find a single corporate methodology. Instead, each team should not just choose their own process, but should also actively tune their process as the project proceeds.” - Martin Fowler 

Copying a process because it worked before somewhere else is a big fallacy.

[agileafrica]

Value Demand and Failure Demand

Food for thought when thinking about value, effort and splitting tickets:

One of the central concepts that distinguishes lean services from lean manufacturing is the distinction between Value Demand and Failure Demand (Seddon, 2003). Value Demand is the demand for service from customers, while Failure Demand is the demand caused by a failure to do something right for the customer. Failure demand is thus demand that only exists because initial demand was not satisfied properly. For example, a large proportion of calls that call centers receive are either chasing down enquiries made earlier, or to correct earlier work that was not done properly. As one of the key aims of "Lean" is to eliminate waste, Failure Demand represents an obvious type of waste in service organizations. Failure demand can also be defined as "the delivery or production of products and services downstream as a result of defects in the system upstream."(Shillingburg, 2011) This would include administrative rework, audits, inspections and enquires. This non value-added work can account for the majority of administrative work performed. By treating failure and value demand alike in statistical analysis, failure demand can give the quite false impression of greater productivity. This merely reinforces the need to look at what is really going on, and ask why the service is being rendered.

From: http://en.wikipedia.org/wiki/Lean_services#Value_Demand_and_Failure_Demand

[agileafrica]

Weighting different types of tasks

An interesting discussion that debates whether or not to give 'tech tasks' (tasks that may not provide visible progress or features to an app, but will improve or develop some back-end technical area) effort points during an sprint.  If they have points then they would affect the velocity of the sprint, if not then what we are saying is that they provide no value and should not be considered within estimation.

There are benefits and downsides to either argument, worth reading the article and the discussion points...

[agileafrica]

Documentary about applying the Toyota Production System as implemented by a warehouse supplying food after hurricane Sandy.

Prizes for spotting the Genchi Genbutsu!

[agileafrica]

FrontlineSMS stand ups

FrontlineSMS have been running scrum for nearly 50 sprints now and like any good agile team are always up for change or something new.

Adding a physical wall has really changed our stand ups; exposing stagnate tickets holding up the sprint, allowing direct re-prioritisation and getting everyone away from screens.  

Here's what they are looking like at the moment:

Construction is also in progress for an all-new kanban wall....

After a couple of weeks there are already suggested improvements and updates which is exactly what there should be!  Thank you to Mr Sean (\o/ CEO - no problem with upward delegation here) who didn't mind being our Post-It mule and smuggling in the Super Sticky 3M stickies without which none of this would be possible.

[laurawmcd]

[agileafrica]

laurawhudson:

We’ve got a spangly new scrum/kanban wall @FrontlineSMS… (at FrontlineSMS)

Well it's actually not a "/kanban" wall but it is spangly.

[agileafrica]

QA and testing environments, with my ScrumOps hat on

One of the first tasks I have found myself executing that really isn't anything to do with my roles as 'Agile Coach', 'Scrum Master', 'Producer' etc. is providing an environment where robust QA (Quality Assurance == testing) can take place.

It's all very well seeing your site running nicely on your shiny Mac-with-Chrome set up, or your iOS 6 Safari, but does it work on IE8 on 1024x768?

To answer that question we needed to set up a machine to get proper testing systems in place.  VMs (Virtual Machines - see the Vista running within Mac OSX above) are the answer, and Stan Croft (QA admiral at Delib) has the answers to the questions that everyone asks.  Using Microsoft's really thoughtful (!) offering of test suites and a handy guide by the folks at osX Daily, you can run all sorts of Windows version on your Mac for free:

The guide: http://osxdaily.com/2011/09/04/internet-explorer-for-mac-ie7-ie8-ie-9-free/

The (only ;-) helpful Microsoft page: http://www.microsoft.com/en-us/download/details.aspx?id=11575

Mobile optimisation and responsive design is becoming increasingly important no more so than here in East Africa where the percentages of users accessing websites over mobile is in the high 90s for some major national sites.  Queue Android and Opera links:

Getting Android running: http://buildcontext.com/blog/2009/installing-android-sdk-browser-testing-mac-os-x

Understanding Africa's most used browser:

[agileafrica]

...no team can estimate with perfect insight, especially at the story point level...

Yes, and that's what Mike Cohn says.

Click the above link for a useful short description of story points and answering that common question "How many hours does 1 point take?".

[agileafrica]

How to have portable scrum boards in your office that also sit on the wall nicely

Another necessary tasks for your scrumops

So they need to be...

Visible to all of the team (so everyone can double check those ticket numbers they're supposed to be working on)

Easily accessible (so tickets can be moved without too much effort)

Portable (so that the boards can be updated in meetings away from the work space)

Look nice (maybe should be higher up the list as you spend a lot of time around them)

Allow stand ups to happen nearby (maybe not that major if they're that portable)

Having scrum and kanban boards in a good place in the office is really important.  Otherwise what you will find is that they are just what you see at meetings (stand ups and set ups and closedowns etc.).  Everyone starts to be driven mainly by the online ticketing system rather than the boards and you're back to square one with your WIP and QA processes.

Solution?  Rails!

Luckily there's a lot of nice mahogany here in Africa, so our rails are probably better than they need to be:

Oh yes we do, check those out

The rails going up

Close up of the innovative board-holder-locking-mechanism utility.  Mahogany of course.

In use.  We designed for two-up so we could have a sprint up there alongside designs, notes, burndowns etc.

[agileafrica]

A note on sprint sizes

We've just completed our first 3 sprints, in 2 weeks.  That's 2 weeks for 3 full sprints.

What is the best sprint duration?

Not really a question you can answer without knowing a lot more about a lot more.

Here we have a relatively small (lean?) team doing technically simple sites with a high requirement for design and cross platform accessibility (mobile especially seeing at something like 90% of web browsing is done on phones here in Kenya).

We made it work and delivered working, tested code at the end of each sprint.  I am not sure if productively was at it's highest as we're a new team, but I would hazard a guess that we weren't.

I think I'll refrain from a specific answer but I think sprints need to be 'something between 1 week and 3 weeks' including deployment and QA.

[agileafrica]

ScrumOps

A lot of what I have been doing here in Nairobi has involved instilling processes based on agile methodologies.  Sharing tips, experiences and general problem solving is a large part of this; white boards and post-it notes are not magic stationary-based bullets.

However, there are also many many other factors involved in getting new processes in place within a team that is currently running at 100+% capacity (projects never wait patiently in line for this stuff to be in place!).

For example implementing a simple Plan-Do-Check-Act workflow with a team that is used to Planning-then-Acting requires a significant amount of work alongside the cultural changes that are easier to imagine.  There are always many engineering and technical challenges to overcome.  Moving to frequent release cycles, as below, will involve a team learning new deployment procedures, technologies and branching tools to name but a few.

In my experience the managers, production team and other staff are not going to be able to push all of this through alone.  They are always too busy or distracted by other goals to really get over the learning humps and gain proper consensus.

It all requires skills from many disciplines; technical, managerial, experiential (ahem), a lot of research & learning.  I have realised that this is a large part of what I do and cannot (and should not) be covered by a 'Scrum Master' role.  

In the same way that DevOps "is a response to the interdependence of software development and IT operations" (generic Wikipedia link alert), I think that this work is a response to the interdependence of web development and agile methodologies.  I'm calling it ScrumOps (everyone seems to call agile stuff 'scrum' as a blanket term these days anyway).  So there, you can now call me 'ScrumOps Man', or something.

Rather than finish this off with a boring task list of some ScrumOps examples I thought I'd put in a picture:

See http://devops.com for more information on that side of things, or https://twitter.com/DEVOPS_BORAT for different type of updates.

[agileafrica]

Sprint planning #1 complete!

It's done.  The first compulsory piece of admin that I've introduced is complete.  It actually went very smoothly as you can see..

Some key factors of win highlighted here;

Manageable Scrum board with MVP agreed for next deployment

One single non-distracting laptop to access ticketing system

Post it and pen ready for the off

Correctly (?) rejected tickets that were not part of the MVP and deemed unobtainable in the time.

Pile of previous ticket win

So I have to admit that we ran a Sprint #0 without a proper planning meeting (hence the win pile on the first plan) as I think this is a really good way of the team, product owner and client all appreciating why it is important for all to engage in the debate.

I think it worked but let's wait and see.

[agileafrica]

Distributed walls

At Circle we have distributed teams across multiple continents.  How to solve this without taking out shares in some airline or running a company across an unreliable Skype connection?

Our first solution; distribute the walls.

Walls are so important to a team running scrum, kanban or any agile team project (a nice summary by the good people at the UK Cabinet Office GDS).  Whilst web apps like Jira and ScrumDo replicate them well online, I don't believe they can replicate the social and cognitive benefits of physical tasks moving through your processes.  Kanban and scrum boards also provide some of the most useful information radiators.

So, the plan is to build replica boards of all our scrum projects and the mother kanban board across all (both) our offices.

The scrum masters running the boards will then communicate the updates after each stand up.

In this way all members of each offices will visibly be able to see the flow of tickets and, crucially, tickets that are stuck...

The simple solutions are often the best.

[agileafrica]

The Circle Digital wip management process aide map workflow SOP (kanban board)

Circle is starting the journey of getting into a kanban.  We have studied the art of JIT, WIP limiting, cycle time (well, not yet but one step at a time) and general visualisations.  This is what we are planning to start with:

What hasn't been discussed in detail (and usually takes many cycles of work to understand) is the number of sensible slots we have to manage throughput:

# Work in Progress slots

# Awaiting QA slots

# In QA slots

Fixing these numbers will limit our technical liabilities and ensure things get QA'ed and deployed in a sensible timeframe.  They are important but they can also vary over time with personnel change, external commitments and so soon.

At present we are have picked initial numbers:

5

4

5

Each slot should have space for the ticket as well as whiteboard space for writing up names of owners and latest date moved.  Both designed to help cross continent teams understand what's moving, what's blocked, who's a bottle neck etc etc.

There is also the working idea that we keep one slot open in all sections as an emergency slot.  This will allow us to handle client and technical 'fires' even when we have lots of work on without tipping everything on its heads.

[agileafrica]

Fitting a Circle into a kanban

<<Insert stock photograph of child's toy with square going into a circle, or something>>

One of the first tasks was getting all of the current work in progress, support projects and system improvement tasks together and into some sort of process.  It needed to be easily manageable so that everyone can have a sense of ownership, flexible so that urgent server fires & client requests can be accommodated and visible so that the teams can all follow it.

Queue some real life digital Genchi Genbutsu; I donned my Taiichi Ohno hat and 'went and saw'.  Welcome to the factory floor...

[pddngtnptkn]

My first agile adventure in Africa...

[agileafrica]

As a posted in my less work-related pddngtnptkn I have started some agile consultancy at Circle Digital.  Expect some commentary on the journey...

…started yesterday.  So far it’s been great getting to know the guys at Circle Digital.  There are going to be some very interesting projects and work that I can hopefully write and share here.  It’s all starting with some agile chatting and scrum training then from there it seems the Serengeti sky is the limit.

Actually, that’s a lie.  It’s all starting with these quite frankly awesome business cards that they made for me: