- Not timeboxed
- Focussed on the flow of work, removing sources of variability
- Work is pulled from the back of the flow (rather than pushed from the front)
- WIP == limits how much work can be in any one flow state at a point in time.
- Encourages"swarming‟ around roadblocks to ensure removed ASAP
- "Lead time‟ == Measurement of flow (instead of Velocity )
- Cumulative Flow Diagrams and Variability Diagrams track progress (rather than Burn Up or Down charts)
- Work broken down to roughly similar size.
- Tracks flow of stories and associated "epic" ("minimum marketable feature")
- Embedded process for handling:
- expedited items
- fixed delivery dates
- work type splitting (e.g. enhancements, production defects, and text changes)
- Slack deliberately encouraged to allow for CI to process to be identified/actioned
- Prioritisation of backlog performed just in time
Snippets and thoughts from a passionate software developer interested in all things DevOps, Continuous Delivery, Functional Programming, Distributed Systems. Also on Twitter as @mcallana.
Saturday, October 27, 2012
Agile Academy Kanban
http://www.agileacademy.com.au/agile/sites/default/files/Kanban.pdf
Thursday, October 25, 2012
Henry Kniberg: Cause and Effect & A3 Problem Solving
Cause & Effect Diagrams: www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf
A3 Template: http://www.crisp.se/gratis-material-och-guider/a3-template PDF, Word
On the A3 template, the steps are typically laid out like this:
- Also Ishikawa Fishbone Diagram
- Benefits:
- Creates a common understanding - practical collaboration
- Focuses on most important problems first
- Helps turn vicious cycles into positive reinforcing loops (good stuff leading to more good stuff, instead of bad stuff leading to more bad stuff)
- All problems are systemic - don't point fingers - the systems broken to allow this to happen
- Until you find the source of the glitch, most attempts to fix the problem will be
futile or even counterproductive. - Used as the root cause analysis of A3 problem solving (more below)
- Basic process:
- Select a problem – anything that’s bothering you - and write it down.
- Trace “upwards” to figure out the business consequences, the “visible damage” that your problem is causing.
- Trace “downwards” to find the root cause (or causes).
- Identify and highlight vicious cycles (circular paths)
- Iterate the above steps a few times to refine and clarify your diagram
- Decide which root causes to address and how (i.e. which countermeasures to implement)
- Countermeasures are just experiments - prod the system to see how it will work
- If they don't work, analyse, update diagram, try other countermeasures
- Follow-up is important
- Failure == system trying to tell you something, better listen
- "Only real failure is failure to learn from failure"
- Ask "so what" until get to problem(s) that conflicts with goal
- Analyse consequences of problem:
- Quantify: How much revenue/customers lost?
- How do you know when you've solved problem?
- Ask "why" until dig down towards the root
- Vicious cycles: recurring problems usually involve re-inforcing loops
- Spotting them increases likelihood of solving
- Easy to miss important causes on first pass - go back and ask more "why"s
- Label root causes, propose countermeasures
- Root causes:
- only have arrows going out
- further whys don't feel meaningful
- issues is something we can address with significant positive effect
- It typically takes about 5 whys to get to the root
- In between problems and root causes are symptoms
- Without analysis, jump to conclusions & execute ineffective/counterproductive changes.
- E.g. adding more people, though head count had nothing to do with the problem.
- E.g. changing the incentive model (reward people for releasing on time or punish people for releasing late)
- How to create
- Alone: powerpoint/Visio
- Small group: whiteboard with post-its, everybody helps
- Large group (>8): split into groups, same problem, compare at end
- Maintaining: Worth keeping in Visio/Powerpoint, replicating on whiteboard for updates, synchronising with soft copy
- Pitfalls:
- Too complex
- Remove redundant boxes
- Focus depth first, write one or two most important problems, dig deeper
- Problem too broad? Limit to narrowly defined problem
- Split diagram into pieces (point to stack of "etc" boxes)
- Too simple
- Never perfect: "all models are wrong but some are useful"
A3 Template: http://www.crisp.se/gratis-material-och-guider/a3-template PDF, Word
- More info:http://www.reliableplant.com/Read/22984/a3-problem-solving-lean
- A3 problem solving steps:
- Identify the problem or need
- Understand the current situation/state
- Develop the goal statement – develop the target state
- Perform root cause analysis
- Brainstorm/determine countermeasures
- Create a countermeasures implementation plan
- Check results – confirm the effect
- Update standard work
On the A3 template, the steps are typically laid out like this:

Wednesday, October 24, 2012
Henri Kniberg Kanban Links & Comic
- Mini book: http://www.infoq.com/minibooks/kanban-scrum-minibook
- http://blog.crisp.se/2009/11/19/henrikkniberg/1258614240000
- http://www.crisp.se/gratis-material-och-guider/kanban
- Know your goal
- Hint: Agile/Lean/Kanban/Scrum isn’t it.
- Never blame the tool
- Tools don’t fail or succeed. People do.
- There is no such thing as a good or bad tool. Only good or bad decisions about when, where, how, and why to use which tool.
- Don’t limit yourself to one tool
- Learn as many as possible.
- Compare for understanding, not judgement.
- Experiment & enjoy the ride
- Don’t worry about getting it right from start; you won’t.
- The only real failure is the failure to learn from failure.
Comic Strip: http://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000
"The change from 2 to 3 developer limit was mostly to show that it can change. In this case to accommodate a higher variability"
"To be for or against Kanban would be as silly as being for or against staplers. It’s all about context"
Sunday, October 21, 2012
HTTP Draft
HTTP/1.1: Semantics and
Content
Application-level protocol for distributed,
collaborative, hypertext information systems.
Table of Contents
Friday, October 19, 2012
Bash tips
https://github.com/wayneeseguin/rvm/blob/master/binscripts/rvm-installer
shopt -s extglob
Turn on glob pattern matching of filenames.
shopt -s extglob
Turn on glob pattern matching of filenames.
sort -t. -k 1,1n -k 2,2n -k 3,3n -k 4,4n -k 5,5n
Sort lines containing version numbers such as:
1.2.3
1.16.2
e.g. curl -s https://api.github.com/repos/wayneeseguin/rvm/tags |
sed -n '/"name": / {s/^.*".*": "\(.*\)".*$/\1/; p;}' |
sort -t. -k 1,1n -k 2,2n -k 3,3n -k 4,4n -k 5,5n
typeset
Declare semi-strongly typed variables.
builtin cd
Execute "cd" - useful for redefining a
function whose name is the same as a shell builtin
Richard Branson on Entrepreneurship
http://www.marieforleo.com/2011/07/qa-tuesday-richard-branson/
#1 Lesson
- Key is how good you are with people
- Genuinely care
- Surround yourself with ppl excited about what you're doing
- Draw out the best in people
- Lavish praise
- Inspire
- Never use the "I" word - you're a team: "we're doing this"
- Never centre on yourself
- Be a great leader from day 1 even if only 1 or 2 people
- there will be bad times - people will work day and night to keep whatever you're creating alive
Next stage in bulding businesses
- Be a great delegator
- Find someone who is better than you - to replace you so you can move onto the next thing
- Entrepreneur is not a manger - a starter of ideas who hands over
- Manager on the other hand - immerse yourself in the busines and don't worry about moving on
- Steve Jobs more a manager than a entrepreneur
Get to know people in fun situations = learn a lot more than in meetings.
Meetings, meetings, meetings = burnt out
Sunday, October 14, 2012
Cassandra
http://en.wikipedia.org/wiki/Apache_Cassandra
http://perspectives.mvdirona.com/2008/07/12/FacebookReleasesCassandraAsOpenSource.aspx
http://perspectives.mvdirona.com/2008/07/12/FacebookReleasesCassandraAsOpenSource.aspx
- Designed to handle very large amounts of data
- Spread out across many commodity servers
- Provides highly available service with no single point of failure.
- Initially developed by Facebook and powered Inbox Search until late 2010
- Jeff Hammerbacher: BigTable data model running on an Amazon Dynamo-like infrastructure (distributed storage system)
- write ahead logging and indexing
- Structured key-value store
- Tunable consistency
- Keys map to multiple values, which are grouped into column families.
- Column families are fixed when database created
- Columns can be added to a family at any time.
- Hybrid between column-oriented DBMS and row-oriented store.[
- BigTable modeling
- eventual consistency
- Gossip protocol for cluster membership maintenance
- master-master serving read/write requests inspired by Dynamo
- Writes:
- Write to arbitrary node in Cassandra cluster
- Request sent to node owning the data
- Node writes to log first and then applied to in-memory copy
- No locks in critical path
- Sequential disk accesses
- Behaves like a write through cache
- Atomicity guarantee for a key
- Always writable
Thursday, October 11, 2012
CRDT: Conflict-free Replicated Data Types
http://hal.inria.fr/docs/00/60/93/99/PDF/RR-7687.pdf
"It leverages simple mathematical properties that ensure absence of conflict, i.e., monotonicity in a semi-lattice and/or commutativity."
https://github.com/ericmoritz/crdt
Monday, October 8, 2012
Subscribe to:
Posts (Atom)
