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!

Teams

MultiTeamStructure
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
Avoid
  • 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.

Formal

  • 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.

Informal

  • 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

scaledCI
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.

References

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:

TCMavenConfig

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

AddressModel

Define the ViewModel

AddressViewModel

Define the View

AddressView

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

Stub service layer with RequireJS

require While working on Single Page Apps (previously Rich Internet App), people usually end up concentrating on the server or the client side. In this situation it is handy for the UI developers to be able to work with fake/mock/stub Service layer. There are frameworks for mocking the service layer, like Mockjax, but since I was using RequireJS I went with a simpler RequireJS based solution. Basically I wanted to replicate profiles as available in the Spring framework. I got to this with a neat little trick I saw on the Forums.

In the main application, I inject a Service like so:

if (inTestMode()) {
 require.paths['app/clients/RealClient'] = 'test/clients/StubClient';
}
function inTestMode() {
 var params = document.location.search;
 return params && params.indexOf('mode=test') >= 0;
}

Note that the main Require config has previouly been done. Here I tweak it a bit for injecting the stub. The test mode is triggered from an app URL parameter. So, instead of calling

http;//myapp.com/App.html

you would call

http;//myapp.com/App.html?mode=test

At, this point RequireJS will substitute the stub client for the real one. The app code remains completely unaffected.

Posted in Uncategorized | Tagged | Leave a comment

The funny thing about non-believers

Non believers in automated testing that is !

Now that Agile is more accepted in the main stream, opposition to it has taken a different flavor. Developers never say no to writing tests but some don’t really believe that it works. Others are just lazy and undisciplined.

On teams where this is a majority opinion, failing tests are norm. They are usually ignored and code coverage is generally dismal. Now for the funny part ..

Every now and then a non-believer runs into a situation where sensitive code needs modifications. They usually change and commit without due diligence and the answer to “will this break something” is “We Have Tests” !!

Posted in Uncategorized | Leave a comment