• We build in powerpoint or prezi these gorgeous training decks and train up people new to Agile
• We outsource our training to groups who do the same as the above
• We build intranets, wikis or documents worth of content on “how to do <insert Agile activity here>”
• We teach the “Shu” rulebook without constantly re-enforcing the need to progress to “Ha”
• We have embed games to re-enforce and experience learnings from training sessions
• We mentor through SODOTO (See One, Do One, Teach One), but often never get to the TO bit

We talk a lot about innovation and radicalizing the business and yet some of the training techniques we still use are from 1990s. How many Scrum Masters open up this content and use it? How many Scrum Masters experiment and adapt how they work? How transparent, engaging and interactive is this content? Playing games and implementing SODOTO is a great start to interactivity and real-time knowledge sharing, but can we do more?

Recently I have had an awesome opportunity at Charter Hall innovate, experiment and enhance the experience of learning differently. Rather than build decks I have spent many hours building an interactive wall to people new to Agile. It is more an experience than a training session. It is one massive wall that flows a conversation about Agile quite naturally before the tour moves further into the working space.

The “basics” tour has the following elements:

1. The background of Agile
2. The Agile Values
3. The Agile Principles
4. The Agile Process
5. The Agile Roles
6. The Portfolio Wall
7. The Pipeline Activities Wall
8. One of the Project Walls

The principles behind the learning wall are quite simple:

• Create a natural flowing experience
• Introduce concepts with visual drawings to enable better retention
• Make the process introduction really simple, bare bones, but…
• Have the ability to drill through into detail without it overloading the audience. This would help when having more detailed role training.
• Make everything transparent, no content is hidden in a tool
• Break up content so that as things change it is a simple matter of changing one small picture

Now before I show you the pictures of what I have created I do want to highlight some intended future changes:

• Extend the values section to include the Scrum values and the company values
• Make pictures for the Agile Principles
• Add in Lean Principles
• Add in an “other section at the tail end”
• Maybe add in a visual around all the different Agile methods, edgy and support methods
• In addition to the wall I am also building a series of agenda cards – these are re-usable packs for Scrum Masters and coaches to use for workshops and key Agile activities (eg Iteration Planning, Retrospective, etc). These cards have some spares so that facilitators can adapt away from the standard set of agenda ideas. On the back of the cards are tips of the purpose of agenda activity and how it could be facilitated.
  What does this mean for a new facilitator? Well they have the clear activities they need to do with how to do it without having to open up a tool (which they don’t ever do), but most importantly this is real time – exactly when they need it. It also provides great clarity to everyone else in the room around what is happening and what still needs to happen when it is utilised as a backlog against a simple wall of “To Do”, “Doing” and “Done”.

Anyway, now for the pictures of the Learning Wall (it runs right to left due to the entrance point, but normally I would have preferred a left to right run). Taken from the right:

Taken from the left:

The Agile Values (some references taken from Rally’s awesome values picture):

The Agile Principles:

The Agile Process (note this is naturally a very specific organisational tailoring, I am by no means saying this is the one and only process for Agile). Specifically, this is the bare bones view. The number of iterations is just for an example.

And now the interactive version (note how the interaction points line up with the number of iterations).

With a detailed closeup on the iteration portion:

A high level overview of the Agile Roles. The three key Scrum Roles are here – Scrum Master, Product Owner and the Team. In addition I have added in our organisational specific governance roles which includes a high level organisational wide steering group, a Business Scrum and the PMO. Again I would like to highlight that some changes have been made to normal roles to suit the specific culture and needs of the organisation.

Detail on the Scrum Master role (interactive side showing):

Detailed view on the Product Owner role (bare bones side):

Detailed view on the Product Owner role (interactive side):

Detailed view on the Team role (bare bones side):

The Business Scrum role:

The Steering Group role:

The PMO role:

And that is the Agile Learning Wall! Please feel free to comment on any thoughts and suggestions to enhance the route of complete transparency and no tools that I am on.

I would like to thank both Nicki Doble and James Doust from Charter Hall who gave their support for my experimentation and for their willingness to expose to the world what we are doing.

The key to a workshop like this is the slides with the code examples and the labs to practice the learnings, Nonetheless, here are my notes from the course on some of the concepts that I picked up.

Introduction to Clojure

• designed to fix shared state concurrency, designed to run on the host platform
• ClojureScript designed to target devices that cannot run a full JVM like mobile platforms, browsers, etc..
• most of this course is applicable to ClojureScript, just the interrops to the host environment are different
• BigInt (trailing N), BigDecimal (trailing M)
• Strings in double quotes, characters in “”, reg ex are started with a #
• literal true and false, nil is the same as Java null
• symbols are words in your program you want to reference from somewhere else, always resolve to something else
• keywords are a special type of symbol, start with a colon :, fixed labels that have no meaning, used for names of fields often, close to enum in Java
• REPL – read, eval, print, loop – from LISP, all the steps are separate which is different to interactive terminal
• every expression starts with an expression, everything returns an expression which is why you get nil when doing a println
• REPL *1 will get you most recently used expression
• print and println will give you human readable, prn and pr will give you the machine readable output
• list are written in parens, usually represent function calls
• vectors usually reflect collections, in []
• maps are key value collections, in {}
• set starts with a hash and curly brackets
• commas are whitespace in Clojure
• first is the function position, usually starts wuth a function or an expression that returns a function
• quote (‘) is syntactic sugar for quote, prevents evaluation, common issue when starting Clojure when dealing with lists
• doc – built in documentation
• Leiningen – built on Maven, hides complexity but gives you its goodness
• project.clj – dependency file

Functions

• functions are first class and values, most of the core code are pure functions (no side effects)
• defn defines a named function (defn greet [name] <body>) is a definition called greet, passes a name and runs some functions, then call as (greet )
• can have multiple aritys, [] is no arguments, others are the named arguments, useful way to provide defaults
• & in argument vector says next arguments gets all the remaining arguments in a list (0 or more)
• fn is anonymous function with no name (fn [parms] body), to call it you can stick it at the head of a list, use this if you need to do something one time
• shorter synatx is #(), and use % sign for the arguments, syntactic convenience
• usually invoke a function by putting it at the head of the list
• apply takes a function and list or collection or arguments, same as invoking a function on those arguments
• let used for local variables, uilt into the compiler, takes a pair set of bindings (symbol and an evaluated expression) and then a body of any number of expressions
• fn creates a closure, locals are stored and kept with the function
• invoking Java – instantiation (Class. argument)
• read Clojure inside out, read the inner most function and then read out

Expressions and Loops

• in Clojure everything is an expression, always return a value even if that is nil, multiple expressions always return the last value
• flow controls always return a value as well
• logical false is false or nil, everything else is true, similar to the semantics in Ruby and Python
• when is a macro – check and do a buch of things if evaluates true
• cond – tree of if then else without lots of nesting, test – expression pair, stops when it hits the first true test, can end with an :else default by convention only
• case – occasionally useful, like switch in Java, takes constants and returns value, if you don’t define a default you get an error, odd number of expressions, the last one is the default
• dotimes – basic loop (dotimes [i 3]), only useful for side effects as it never returns a value
• doseq – iterates over a collection, like for-each
• for – not for looping, generates data, returns a sequence
• recur – for recursion, rarely used, loop defines bindings which you recur
• exceptions – don’t use them much in Clojure, no checked exceptions, try-catch-finally as per Java, throw to throw an exception
• ex-info and ex-data that allows you to pass back a map
• with-open – convenience wrapper, works with any method that needs to be closed

Namespaces

• Clojure runtime is a singleton within the JVM
• namespaces allow you thave the same name mean different things in different places
• ns – use macro at the top of the source file to create a namespace, :require keyword to load the dependent libraries
• implicit mapping between namespaces and files, dots into slashes and hypens into underscores
• ns :use : only is deprecated form of :require from 1.4 up
• ns :import for importing Java classes, every namespace imports java.lang
• in-ns to change namespaces
• equivalent macros for when using the REPL instead of a file
• a bunch of functions for returning namespace information, but would rarely use these
• private vars are just a metdata symbol, use ^:private, not truly private or hidden

Collections

• a class or a struct becomes a map in Clojure
• clojure.set – mathematical set operations
• vectors are functions, can call using the indices
• mostly use vectors, lists are useful when you want to work at the head of the list as it is more efficient, like simulating a stack
• seq – returns a sequential view of something, like an iterator but it is not an iterator, can get first or rest
• range – infinite lazy sequence of integers
• into – puts a sequence into a collection
• take / drop – take the first n in the sequence, drop the first n in the sequence, also filter and remove
• map – the essence of functional programming – calls a function on a sequence and returns a sequence, the functional equivalent of for/each
• reduce – powerful, uses first element if not initiated
• some – to return the first logical true in the sequence

Concurrency

• concurrency – multiple things happening concurrently that are sharing the same state
• deref – returns current state, shortcut is @<ref>
• atom – basic container with mutable state, changes are atomic, synchronous
• ref – coordinate and share identities, synchronous, must be iolated in a transaction, uses locking under the hood
• ensure – ensure the state is the same when the transaction is completed
• alter – change the value of a reference in a transaction, if another transaction tries to change it gets aborted
• commute – same behaviour as alter but allows concurent updates in a transaction, use for counters, adding elements to a map, if you are not sure use alter
• agent – asynchronous communication, atomic updates, ensure only one thing done at a time, every agent has its own queue
• send – send an action (function) to an agent, execute in the order that you send them, can’t guarantee that other threads are not sending action, fixed size thread pool
• send-off – variable size thread pool
• vars – thread safe, global identity, alter-var-root to modify global state created by a def, by convention dynamic var is surrounded by * (called earmuffs)
• swap! and reset!, convention to put a bang at the end of functions that have side effects or shouldn’t be put inside a transation
• watches – experimental, takes 4 arguments – key, reference, old state and new state, you can then add-watch
• future – background process, if you de-reference the future it will block (@<ref>)
• promise – like a future but no running process, like a container, can wait for it to deliver that promise to another thread, can only be delivered once
• realized? – to ask if a promise has been delivered

Polymorphism

• polymorphism – two types protocols and multi-methods
• type – what is the type of class using class or type
• maps do not have a notion of type, record allow you to give a type to a map, defrecord creates a record, by convention the name has a capital, records are maps so we can call all the map functions
• record automatically creates the constructor function called -><function>, map-><function> takes a map
•  when you create a record you are generating a Java class, useful when creating a lot of maps with the same structure or to implement protocols
• protocol – like a Java interface, group of functions that do not provide an implementation, called based on the first argument, defprotocol to create the functions
• convention _ is an argument I don’t care about
• reify – creates anonymous types
• extend-type and extend-protocol – allows you to create new interfaces to existing types, solves the monkey patching issue
• multimethods – generic methods, much more flexible than protocols, uses defmulti and defmethod, an extensible switch

Macros

• macro – pure functions – defmacro – code is input and output, define the symbols to reflect the code that we want, macroexpand-1 is used for testing and debugging to see what that macro does
• syntax quote `
• unquote ~ and unquote splicing ~@
• most of the core language where not functions are macros, write macros for syntactic convenience

Clojure and the JVM

• Clojure is tightly integrated to the JVM, is unlikely to be the bottleneck performance wise
• arrays can use aset and aget to access, use Clojure Collections but maybe needed for interoperability, can use to-array and into-array
• types and collections are all mapped over to Clojure
• built in benchmarking in Clojure using time function, time a loop to get a better indication rather than just time on its own
• by default everything is boxed in Clojure, but Clojure has limited support for long and double primitives
• compile – pass your namespace, will give you ahead of time compile which gives a modest (30% – 40%) speed increase amongst other benefits, usually will us leinengen or another tool (lein compile)

ClojureScript

• ClojureScript is designed to deliver optimised JavaScript
• two pieces – ClojureScrpt compiler written in Clojure on the JVM, compiles Clojure to JavaScript, then the Google Closure compiler optimises for space for performance
• lein-cljsbuild makes ClojureScript tolerable
• ClojureScript One but is superceded by Pedestal now
• testing frameworks – Clojure.test, Midje testing framework written by Brian Marick and Simulant