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
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.
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
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:
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.
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.
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.
IMO, the mainline – i.e., what you are working on every day – should be ready to release from at almost any time. This implies low technical debt, and little difference between mainline and a release branch (if you use that) – i.e., less work in progress at any time.
Limit work-in-progress (WIP), but don’t be too ambitious at first
Basic Kanban is a lightweight framework for change management.
Starting with the core concepts on top of your present process should meet little resistance, at least when coupled with focus on improving quality.
Btw, I talked at a lokal meetup earlier this year (slides here), mostly on the core concepts – why they work and how to start.
A few Kanban Practices
Flow; encourage, cultivate, transform towards
Classes of Service (CoS); visualize and track different types of work, with different demands on them
Gradually limit WIP to improve flow and to uncover your next improvement opportunity
Cadence; regular rythm of things like backlog replenishment and deployment, separate from development
Metrics; to manage flow over time
Pull; instead of mostly work with deadlines
Slack, swarming – doing it consciously
There’s more, but this illustrates the relation between the core concepts and a set of recommended practices.
You’re likely to start with a simple version of some practices, f.ex. the work types (CoS) critical items, work with deadlines, bugs. More practices can be utilized as your organization matures, and more sofisticated use of practices, like setting different target lead times for different CoS, f.ex. 50% of bugs should be fixed within a week.
Update after “conversation” with @pawelbrodzinski:
Buy-in from management and whole organization is preferable, but team buy-in is enough and necessary, in my opinion.
I think it’s important to just get started, improving step by step, and team buy-in and the Core Concepts are enough to do that.
Last week I looked at my overgrown todo list, or rather several lists, and preparation for a demo at work was coming up, and I have a long trip to prepare for… So I simply had to create a personal kanban on the cupboard behind me: Collaboration on the demo preparation led to tasks on the board, and I took the most important and urgent tasks from my todo lists onto the board. I used a form of priority filter, with a generic todo column to the left, then a “soon”/today column, then the usual doing and done columns. It worked really well to let tasks float up and to the right in the todo columns, kind of like bubbles. I got an immediate impression of relative urgency (more to the right) and relative importance (upwards), making it very easy to decide what the next task should be when I finished a task.