Intrapreneur Canvas

An internally focused exploration of an idea is different from an externally focused one. In my experience, noticeable differences have been related to market, revenue, customer etc. F.ex, relatively small potential improvements in work within main value streams could clearly dwarf size of investments, or have been considered already.

Anyway, here’s a kind of intranpreneur canvas that’s been useful for me a few times lately when thinking about building new software.

Lean Decision Filter

“What should I work on next?”

Yuval Yeret quotes David Anderson:

  • Value trumps Flow – Expedite at the expense of flow to maximize value
  • Flow trumps Waste Elimination – Increase WIP (work in progress) if required to maintain flow even though it will add waste
  • Eliminate waste to improve efficiency – Do not pursue economy of scale

See also Al Shalloway on Lean thinking about waste in software development – it’s not about optimizing and reducing the use of “resources” (to quote a tweet by @drunkcod).


Developing in the Cloud

So I don’t have much time for hobby projects… And when I do have time, it is from various computers, with various setup.

That’s why I’m testing the following combination of online services, and so far it looks promising for my needs…

Slack is Unplanned Improvement Work

Full utilization cause delays -
Full utilization is not effective, not efficient, and causes delays

Being busy all the time is bad for you, your team, and your organization.  It is far better to allow for slack, which is not a bad thing, but creates opportunities for improvement without needing to schedule them.

“Recipe” for what to work on next, incorporating slack:

  1. Can you help progress existing planned, started work?
    Work on that.
  2. Can’t do that?
    Find bottleneck and help work to release it.
  3. Can’t do that either?
    Do some (improvement) work which

    • won’t create any work downstream,
    • will improve future throughput, and
    • can be paused as soon as existing kanban related work is available.

A bit more reading related to slack.


At LKNA13 in Chicago this year I listened to @JoshuaKerievsky talk about #techsafety.

He made me think about quite a few aspects of safety and injuries for a programmer. Here’s a few quotes and elements:

  • safety on team (ref own dev competence)
  • «working with CVS is hurting my soul.»
  • safe from uncertain work situation
  • safe to deploy – bugs, crash
  • safe from pressure – politics, policies
  • Emotional Injuries: Schedule Stress, Lost Respect, Fear of Failure, Torn Trust, etc

What’s interesting is his claim that having #techsafety as a primary value would be profitable and produce outstanding results. I think I buy into that, even if he hasn’t had time to prove it yet with his own company, @IndustrialLogic.

A few twitter notes from the session.

Edit: Joshua have written on #techsafety himself:

TDC 2012

Yesterday I attended TDC.

It was fun to see so many from the software development community in Trondheim turn out all at once.

I also had a short talk about better ways to work, focusing on delays and feedback – especially how it’s more central to knowledge work than we think.

Here’s the slides if you’re curious (PDF):
201210 TDC Better ways to work

Update: I added a few slides for a talk at the office – see extended version (pdf) if you like, containing a few more links/ reading tips.



Operations Review – Health of Your Business

What is an operations review (ops review)?

To do an ops review is to take a look at your team or organization:

  • driven by data
  • involving management and business, up- and downstream in value chain
  • look at the whole, i.e., all kinds of work
  • look at both value/ benefit and cost

Why should you do ops reviews?

  • create a culture of openness and trust
  • create shared understanding across different stakeholders
  • it’s about learning
  • teaching senior exec’s about the business

Android App With Jenkins

I just got involved with a mobile project, and let my inner devop out for a moment… So, here’s how I got Jenkins to build, sign, and deploy an Android app for testing.

Our setup:

  • Jenkins CI, installed on a virtual Ubuntu server,
  • Android SDK on the Ubuntu server,
  • Android SDK compoments (including an Android profile/ target),
  • an Android project
  • keytool on Ubuntu to create a simple keystore, for signing the app

The gist of the Jenkins job is:

  • Get updated code from Git
  • Execute shell command to create an ant build file on the fly with the Android SDK tool android:
/opt/android-sdk/tools/android create project -n [name of resulting app file] -t [Android target] -p [name of temporary directory where project is copied and ant files generated] -k [package] -a [default app class]
  • Copy resulting build.xml from the temporary directory to the project root
  • Run ant targets clean release, with the following properties:
target=[Android target]
  • (Without the last four properties above the job will build an unsigned app)
  • Publish resulting .apk via FTP to a server
And on my phone:
  • Allow installing apps from unknown sources

I got useful info from an article on  Getting started: Building Android apps with Hudson. My needs were a bit simpler, so you’ll see a bit more details there than here.

A few problems I had:

  • The Ubuntu VM didn’t have X installed, and getting SDK components seems to require a GUI. I tried to go around this by copying tools and targets from SDK on my laptop.
  • A bit later I got stumped by an error message on aapt and “no such file or directory”. (This might have been related to what I did on the previous problem…) An answer on stackoverflow regarding ia32-libs provided the solution in my case.

This project is a side project with low activity compared to a day job, so right now this job is a one-click deploy job (one click plus downloading and installing on the phone…) However, I think we’ll set up nightly polling, so there’s an updated app available every morning for testers, and they can see by the timestamp  if there were any updates the previous day.