#techsafety

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

Lean Coffee: Democratic, Responsive Meetings

Lean Coffee is a meeting format where you don’t finalize the agenda before the meeting starts.

It can take place in a café, but also in a meeting room, living room, or almost anywhere.

The topic is often Lean, Kanban, agility in business and product development (like software development), but the format lends itself to any topic.

An example of established groups meeting for lean coffee is Lean Coffee Oslo.

These groups are people meeting on their own time to learn, but this format has big potential benefits in business context as well.

Lean Coffee at a café

A few quotes from LWS on Lean Coffee:

Essentially, a Lean Coffee is a group of people working together to learn … in an informal setting.  It’s like a mini-unconference where the participants decide on the schedule.
….

Step 1: Everybody writes down topics they’d like to discuss on stickies ….
Step 2: Each topic is briefly described …
Step 3: … votes …
Step 4: … stickies with the most votes at the top
Step 5: Each of these stickies are discussed
Step 6: If enough time … do another stickie

A few quotes from @ourfounder and @sprezzatura on why democratize meetings:

Agendas are so 20th Century.
….

When you set an agenda, you control the conversation. …. When you control the agenda, you control the lessons learned. Since we enter a meeting with only our assumptions to guide us, agendas follow our assumptions. Our assumptions are based on what we already know. But what about the things we don’t know? Quite often, it’s the conversations we don’t plan on that give us the most insight. Why not instead run our meetings to learn or to discover?
….

Conventional wisdom suggests that businesses hold far too many meetings attendees deem a waste of their time. ….  To combat this, some call for meetings with rigid agendas.
….

the discussion of a stated topic is a conversation. In fact, the entire reason we are calling the meeting is to have a conversation.
….

If we want to learn from our meetings, we need to allow the conversation to be set by the very professionals we invited to the meeting in the first place.  …. Allowing the group to have a say in setting the agenda gives them buy-in for the importance of the topics.
….

as the person who called the meeting, you can now direct the overall topic and even seed a few of the initial sticky notes. You can even set a few “must discuss” stickies at the top of the board and prioritize them the highest.

Notes:

  • Takeaways
    • either privately or f.ex a right-most column on the board
    • per topic or sharing takeaways in general at the end of the lean coffee

Read more:

 

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:
sdk.dir=/opt/android-sdk
target=[Android target]
key.store=path-to-keystore
key.alias=[alias]
key.store.password=[pw]
key.alias.password=[pw2]
  • (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 jenkins-ci.org:  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.

Case Study on Lean-Kanban in BBC

David Joyce and Dr Peter Middleton have studied the application of (what I call) Lean-Kanban in BBC.

From the abstract:

The evidence shows that over the 12-month period, lead time to deliver software improved by 37%, consistency of delivery rose by 47%, and defects reported by customers fell 24%.

The significance of this work is showing that the use of lean methods including visual management, team-based problem solving, smaller batch sizes, and statistical process control can improve software development.
….

The faster delivery with a focus on creating the highest value to the customer also reduced both technical and market risks.

There’s more info on David’s blog, and you can also read the case study itself prior to publication from there.

Update: The case study was published in 2012.

What’s In a Kanban Standup?

First and foremost:

Focus on work items, not people.

Then:

Finishing is more important than starting.

Practical tip: start to the right/ at the end of your board, and identify impediments to finishing tasks as you go upstream on the board.

Only two questions are really necessary in the actual standup if the team’s real process is reflected on the board:

 The team will be asked if the board accurately reflects what is being worked upon. The team will be asked if there is anything that is slowing down or stopping throughput. After these two questions are answered by the team, the stand-up is over.

(Karl Scotland via @dpjoyce.)

Update: a few more reading tips.

Agile Version Control

The goal is to enable you to be more agile, i.e., to improve your ability to change and adjust.

Here’s what I think:

Mainline and CI

Branches and merging
  • Beware of feature branches, and kill them as soon as you can if you do use them. (One tip: feature toggle)
  • Branches: Merge from mainline every day if you have them.
  • Good naming goes for build code and infrastructure, too, so I’d prefer branch names like mainline, release, featureA, fixB
  • Limit branches agressively – they represent more work in progress (and you want less work in progress) including risk of big merges
  • Agile version control for multiple teams
    Illustration from Henrik's article

    Merging: merge down, copy up – always accept stabilizing changes, never impose destabilizing changes.

Inspiration:

Martin Fowler: articles on continuous integration

Henrik Kniberg: Agile version control with multiple teams

Støtt ein barneheim i Uganda

Ein kar eg kjenner, Werner, har vore på besøk til ein kombinert barneheim og skule i Uganda som treng støtte – Sky Orphans.  Dei som jobbar der er frivillige, og dei tar hand om over 100 ungar.

Det finnest ei facebook-gruppe og ein presentasjon med litt info, sjølv om det er litt gamal info der.

Under er ei lita hugseliste for å setta opp fast betaling til dei.

  • Du kan bruka kontoen til Stiftelsen Dina, konto-nr 3080 21 65400
  • Merk betalinga med “Uganda”
  • Det skal gå melding til skatteetaten om skatte-trekk for frivillig gåve, men det er sikkert greitt å sjekka når sjølvmeldinga kjem