bit.ly/justevilthings

This workflow is designed for homogeneous teams that have a fixed
scheduled workload. Requsts that come in are events that need to
be actioned within a week or so. Urgent requests are expected to
be sent through into some kind of on call event. The crux of the
whole idea is that everyone can do the work, so assigning of the
work is very simple. The calculation of how much work any one person
can get or how to determine this was left up to the listener.

This talk highlighted the issues that we face as a team that has
no standards or standardization.

The process overview is interesting and it approaches a business
problem from a novel way. The big attraction is that those who
attend these events seem to be drawn to things that would up their
status. I could be reading into it. I don't quite get why some
people go to some talks.

The process uses a kanban or other kanban like board. there is a
lane for incoming work, assigned work by member, and then additional
lanes for blocked items.  There is a weekly or twice a week meeting.
There is a member defined cycle time. Stack Overflow uses one week.
So in our example you meet twice a week and there is a someone in
charge of the board each week.  The person in charge of the board
is the one who is talking during the meeting. They go through all
the planned items and move them to completed or "punt" them to the
next week.  There is an agreed number of times an item can be pushed
to the next week.  During this meeting you acknowledge the completed
cards and the effort to do the work.  The next spot is triaging
the incoming requests.  If they are complaints they get discarded.
If they are things with a specific known resoultion they get
discarded.  Then you hand out X number of tasks. After the tasks
are handed out that's the end.  Meetings must start and end by the
designated time and have a strong demarkation.  Meetings must have
an agenda associated with them.

Below are the more raw notes from the talk. You might be able to
get more from them than I do, so I'm preserving them.

========================================
\\\\\\\\\\\\\\\\\///////////////////////
=======================================

Acknowledge people doing good work as they finish


1. Problem Statement
  - Things just happen - It works fine as long as everyone is Ok
  with the wait - Go read The Phoenix Project!
    - https://itrevolution.com/book/the-phoenix-project/ - How do
  we apply lessons learned from devops books?
    - Be a super-villains and avoid heroism because it leads to
    rushed solutions and hard to use solutions - You want to be
    lawful evil, and maliciously comply with rules and work against
    chaos.  - Example Meeting
      - https://evil.cards/ - Cycle of work
      - Pre-meeting
	- Who is the SV elected - Start
	- Review new business, assign, and acknowledge, - End
	- Same as start - Lanes should have an upper limit of work
    that can contain

_Lessons Learned_ Planning meetings are not for disagreements.
Don't spend time arguing. Instead have a breakout meeting with an
agenda.

All meetings must have an agenda

Let process define your tools.

- Mark cards as blocked, punt to push something forward one week
and increment punt counter, the third time someone has to go on
the hook for it.

- Cards are only moved in the meetings.

- https://github.com/selfcommit/evil.cards