Notes from NYC AgileDay 2015

Scaling Agile @Spotify


– Should feel like a startup
– Distributed!
– Usually aligned by feature
– End to end responsibility – Include deploy n support?


– Do have a chapter lead
– Servant leader
– Management is still hands on – BA manages BAs and so on

Management structure is feature oriented

– Still have traditional functions – example managing building seating


– Are organic – Reddit model – they die out or are born – so motivated community can drive
– Community might not be working because people don’t want to do that!

Alignment vs Autonomy

– Aiming for Autonomous but aligned
– Low/no barriers to communicating between Squads/Guilds/etc. – people try and actively connect

Disseminate top level info to the squads so they could shuffle their own work ***

– Town hall, wiki, email
– Strategic docs are distributed to everyone > so teams can adjust
– People take on tasks because they *want* to take on those tasks > not because X said so

Posted in Uncategorized | Leave a comment

Notes from NYC AgileDay2015

Self managed org.Doug Kirkpatrick

Alternate system to traditional bureaucracy

Only 29% of the employees are engaged
Claims to have setup ad run a large factory without any bosses – self managed – Morning star
Human beings are the ultimate movers – org is just a structure to facilitate

Millennials are used to instant communication

– Don’t work well with chains of command, waits and approvals
– Think Fractal in terms of scaling out

Total responsibility

– Do not get to ignore things which come up in your scope of the world

Freedom to lead and innovate > Autonomy

– Propose an idea and be able to run with it through to the end
– Doesn’t depend on your rank or place in the company
– Colleague pitch in to drive the change
– No inherent barriers

Everyone has an overarching mission

– And a personal mission …
– Why are you here?
– What does excellence look like?

Support/check n balances system of colleagues

– Colleague ‘letter of understanding’ is the cornerstone
– Most important decision have to go via peers/have their blessing
– Commitment should be clear and transparent – honoring them is vital
– People self appraise and determine how they can get closer to excellence
– Benchmark is excellence – mastery at your process
– Drive org from core principles
– Do not have to worry about policies and restrictions
– Self management is power itself – is not revocable
– No one can unilaterally fire anyone

Everyone is a professional

– Paid well and expected to excel
– No distinction between man. and workers (white vs blue)

Emphasis on anticipating the rocky start – Saturn video

Posted in Uncategorized | Leave a comment

Scaling Teams

A lot has been written about this and as always the final solution seems to depends on the teams and the nature of the system. My team is finally at a stage where we need to grow up from a team of 8 – 10 to about 30. This is our stab at organizing ourselves while keeping our Agility. The days to come will tell us how this plays out!


Recommended team structure is to organize teams by customer-centric feature sets (sizable number of related features).
System components still exist, and we strive to create good components, but we do not organize teams by these.
  • Long-lived—the team stays together so they can gel for higher performance; they take on new features over time
  • Cross-functional – has members from Dev/BA/QA needed to go from requirements to delivery
  • Cross component – typically a team would work more on certain components but they can enhance any/all components needed for feature set delivery
  • Multisite – spread over at most 3 offices – to avoid regional silos
  • 6 ± 2 people
  • Single-function specialist teams (UI, DB and such)
  • Non-dedicated team members or “partial allocation.”​
Component owners
  • All components have an owner or a pair of owners
  • Is the ‘go to’ person(s) for any technical or architectural issues related to that component
  • Promotes buy in and active involvement from team members
Team leads
  • Hands on dev – at least 50% of their time
  • Focus on conceptual integrity between components
  • Day to-day co-ordination for delivery
  • Tie breaker(s) if team can’t reach a consensus

Inter team communication

  • Multiple teams need to agree on cross-team working agreements—standards. Over time, the working agreement evolves because teams reflect, learn, and improve.
  • No separate group owns the cross-team working agreement; the teams own them together.


  • Scrum of Scrums can be the formal co-ordination mechanism. Weekly. More high level in nature.
  • Ambassador activities each team to send a team representative (chicken) to the Daily Scrum of other teams they are interested in. Either the same day or the following day, the chickens report back to their team so that their team can determine the needed coordination actions.


  • Roaming specialist moves between teams to pair and bring people up to speed quicker on niche tech.​
  • Open Space is a method for airing current issues and self-organizing around them. Team driven according to needs. Members of relevant teams get together, create topics related to coordination, and organize around them.

Shared infrastructure

Avoid…Separate architecture group
Evolutionary design culture — the initial design vision is rarely great, and in any event since software is ever-changing, encourage a culture in which people view the design or architecture as a living thing that needs never-ending incremental refinement
For broad architectural issues joint design workshops (held repeatedly) can help.
  • Interested representatives from different feature teams spend time together on common infrastructure design
  • Once decided – all teams must strive to comply
If needed we can form an infrastructure team
  • Works on infrastructure for a few iterations (incremental delivery)
  • A temporary role until they return to normal feature team responsibility

When multiple teams start working on related features with a common theme, joint requirement workshops can be useful. The Dev teams get a joint walk though of the ask and they can evaluate the impact on relevant components 

Code Structure

All components should auto deploy into QA – Functional test suite (Selenium et al) runs over the end to end scenarios
  • Avoid … long-lived branches – Branching during development breaks the purpose of CI
  • Useful… Release branches – snapshot of code in production
  • Very short-lived branches that are automatically integrated in the mainline—adopt Git.


Posted in Uncategorized | Leave a comment

Why is Functional programing better?

Wanted to get a deeper understanding of the principles which make functional programming an attractive choice. Why is it better for multi-core and such? Is Lambda calculus related to Newton’s calculus? How are we so certain that we can manage without global state?

So i went back and dug up some more basics on Lambda calculus and evolution of the paradigm. Here is a small talk I did at work.

Posted in Uncategorized | 2 Comments

Embedded Tomcat command line config

The Tomcat maven plugin is great. It lets you build executable Jar files from your regular maven web project.

With the embedded Tomcat you loose the usual conf directory, so you need to think a bit about putting the config some where. You can specify it inline with the code like so:


Maven plugin config for embedded Tomcat

This is ok, until you want to run multiple server instances on different ports etc

Properties can also be overriden on the command line. However, this does not seem to work properly. Some digging around the plugin code revealed that the plugin runner (org.apache.tomcat.maven.runner.Tomcat7Runner) looks for the server.xml first. If, found it ignores other flags! So if you need to configure your Jar with embedded Tomcat, you need to provide the server.xml on the command line like this:

-serverXmlPath qaServer.xml

Now you can start multiple instance with the same Jar and safely externalize server config.

Posted in Uncategorized | Leave a comment

Knockout JS – Separate Model from View Model

Knockout JS follows a MVVM approach. In the simple examples the ViewModel seems to hold two kinds of things:

  1. attributes of the Model object
  2. functions operating on the Model – typically via GUI interaction

While this is fine for smaller apps, as apps get bigger there is a growing need to define the Model clearly and separately. After tinkering a bit and some help from Stackoverflow I settled on this scheme. It has worked well for our app.

Define the model separately


Define the ViewModel


Define the View


Posted in Tech bits, Web development | Tagged , , , , | Leave a comment

Knockout performance tip

KOLogo As our SPA app grows we need to be more conscious of browser performance.

One handy way is to keep the DOM tree light(er). Knockout offers an easy way to remove unused DOM fragments: By using the ko:if binding – instead of the ko:visible binding.

On the UI both of them serve to show/hide widgets. The difference is that the, if binding removes DOM elements if they are not being displayed as opposed the visible binding which only toggles visibility. Official docs.

Posted in Tech bits, Web development | Tagged | Leave a comment