March 29th -LeSS Talks: Agility at Scale: Component vs. Feature Teams in LeSS

Thanks to everyone who joined the event and participated. Some great and challenging questions!  Some Kodak moments are below.  Apologies for having most of images facing the wall, next time we shall have more facing our great audience :).

12 11 10 9 7 8 1 2 4 3 5 6


Agility at Scale: Component vs. Feature Teams in LeSS

Tuesday, Mar 29, 2016, 5:30 PM

Gordon International, New York Design Center, Suite 1401 and 1412
200 Lexington Ave, New York, NY New York, NY

51 LeSS Adopters and Supporters Went

Greetings Everyone!Thanks to everyone who attended the previous session (see pics) on Large Scale Scrum Discussion on March 15th.Our next meetup is scheduled for March 29th: same place & same time.Based on the volume and type of questions, in the next session we will take a deeper dive into the discussion of Component Teams vs. Feature Teams (ne…

Check out this Meetup →


Agility at Scale: Component vs. Feature Teams in LeSS

Tuesday, Mar 29, 2016, 5:30 PM

Gordon International, New York Design Center, Suite 1401 and 1412
200 Lexington Ave, New York, NY New York, NY

20 Agile Adventurers Went

Greetings Everyone!Thanks to everyone who attended the previous session (see pics) on Large Scale Scrum Discussion on March 15th.Our next meetup is scheduled for March 29th: same place & same time. You can RSVP here or at: on the volume and type of questions, in the next …

Check out this Meetup →


March 15 – LeSS Talks: LeSS Overview and Q&A


A barrage of great questions made tonight’s session a long non-stop engaging dialogue.  As annual performance appraisal “specialists” say (I am being very sarcastic now 😉  ), the intensity of today’s discussion “EXCEEDED my expectations”, so maybe someone will give me a bonus  ;).  The collaboration system Nureva that I used in place of a slide deck was really helpful.  My personal retrospective: If I had just fewer slides on the wall, I could’ve made my presentation even more interactive.  So, for me, another lesson learned: LeSS is more.  And I promise to do it next time.  The next LeSS discussion will be a deep dive into one of LeSS topics.   Please, post questions or initiate discussions below.

And keep in mind:






Below is the screenshot of Nureva virtual board with the set of questions that were captured.  They will become an input for our next meet-up(s):

after-LeSS questions

Note: Many thanks to Adventures with Agile – UK-based Community of Practice for scaling agile and organisational change,, for organizing this great event.

“How to make your teams faster” – with Dr Jeff Sutherland & Scrum Inc


Last night, Dr. Jeff Sutherland, the co-creator of jeffsutherlandScrum and CEO of Scrum Inc., gave an energizing presentation of the Bank of Mellon NY.

The following topics were covered:

  • How to make your teams faster
  • The competitive secrets behind high-performing organizations
  • How to create value that wins using the Power of Disruptive Leadership.

If you attended, the event, have any additional questions for Dr. Sutherland or after-thoughts that you would like sharing with others, please feel free to post your comments here.  We shall consider your feedback to organize future events with Dr. Sutherland.

Note: Many thanks to Adventures with Agile – UK-based Community of Practice for scaling agile and organisational change,, for organizing this great event.








How Long Should my Sprints be?

black_green_black_thin_2Author: Ram Srinivasan

When organizations are adopting Scrum, they are always confronted with how long their Sprints should be. Scrum merely provides guidelines that Sprints can be anywhere from 1 week to 4
weeks long. The Sprint is a feedback loop, providing an opportunity for the  stakeholders and the Scrum Team to Inspect and Adapt (the product, and the way they work together, respectively).  The Sprint ends with a Sprint Review, an opportunity for the stakeholders to see what the Development Teams have built during the Sprint (i.e. the Product Increment, built as per the “Definition of Done” is made “transparent”), and discuss what might be built in the subsequent Sprint (“Inspect the artifact i.e. Product Increment, and Adapt the Product Backlog).

There are various factors which determine how long the Sprint should be. Shorter sprints have a higher transaction cost associated with them (e.g. – if the team has one week sprints, they may have four planning, review and retrospective meetings in four weeks, but if they have a four week sprint, they may only have one planning, review and retrospective meeting). Longer Sprints have a higher holding cost, and possibly also increase the risk by decreasing the frequency of feedback the team could get from its stakeholders. Also, longer Sprints will be associated with knowledge decay, if all “how to build the increment” is done during Sprint planning, not to mention that a team doing that will fail to capitalize on the knowledge that they have gained during the sprint.   It is hard to quantify “knowledge decay” and “knowledge gained” so for the sake of simplicity, let us just consider the transaction cost and holding cost alone in determining the duration of the Sprint.

This is a “U-Curve” optimization problem and for most teams a two week cycle optimizes the transaction cost and the holding cost associated with Sprints. However a two-week cycle may not work well for everyone. These are some of the factors that you may have to consider before deciding on the duration of your Sprint

  1. Stakeholder’s Risk Tolerance: How long can the stakeholders wait before getting anxious to see the working Product Increment? Lesser the risk tolerance, shorter the sprints.
  2. Market competition and market demands: Are you in an industry where your competitor is releasing a new version of their product every week, or may be multiple times a week? Not only should you have a robust “Definition of Done”, but you should also consider a shorter time frame for your Sprints. If you are in an industry where you have specific launch windows (e.g. educational industry, where the launch window is typically the Summer and Winter breaks), may be you can afford longer Sprints
  3. Complexity of your product: Scrum tries to mitigate risk by making the Product Increment transparent at the end of the Sprint. It might be tempting to think that more complex the product is, the longer the Sprint should be. More complex the product, greater the risk, and contrary to the popular belief, shorter Sprints provide better risk management opportunities. It may sound like it would be challenging for the team to build a meaningful Product Increment with a short sprint, but with a good Product Owner, big features can be sliced to multiple “micro-functionalities” and with that, the teams should be able to build a meaningful Product Increment.
  4. Size of the team/number of teams working on the product: Scrum does scale to multiple teams, and it is definitely possible to have multiple teams working on the same Product (Backlog) to create one Product Increment at the end of the Sprint. More teams working on the same product need a tighter feedback loop and again, contrary to the common belief, a shorter Sprint would give them a tighter feedback loop and would help them build the right product. Beyond shorter sprints, good technical practices (like Test Driven Development, Continuous Integration, etc) should also be followed to make sure that the product being built is a high quality product.

The Nureva™ Span™ ideation system


The Nureva™ Span™ ideation system: revolutionary collaboration tool

The Span™ Ideation System by Nureva™ helps you streamline the fuzzy front-end of innovation by bringing the innovation process into the digital age. The system provides an upgrade to the familiar tools you already use – sticky notes, sketches, images and flip charts – and combines them with cloud storage and a panoramic display for ideation that is flexible and intuitive. It’s very easy to use and incredibly engaging.

Log-in to access or request free Editor’s access, by submitting the form below.

Artificial Ring-Fencing And Separating Walls Crumble, Eventually

When it comes to defining organizational structures that support product development, it is important to remember the idea, introduced by  computer programmer Melvin Conway in 1967, later referred to as Coway’s Law: “…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations….“. Effectively, this law means that overly complex and politicized organizations, with overwhelmingly complex communication structures, will produce overly complex systems and products.

We often see companies copy-pasting complex commercial frameworks (containing the word “agile”) that can be easily ‘unpacked and installed’ or, instead, over-engineering their own, home-baked complex internal models that comfortably support existing projects, programs and portfolios (Here, “comfortably” – means seamlessly fitting and really not challenging what is already in place: hierarchical complexity.  Instead, weaving in new, over-loaded terminology to re-define old things). Usually, this is  accompanied by claims of artificial success.

One of the examples of the above is artificial ring-fencing an existing what is usually known as a strategic portfolio with an “agile ribbon”, and mapping it to a portfolio-level layer of some commercially popular scaling model or renaming a “strategic portfolio” into an ‘agile theme’ or ‘agile folder’, or ”agile briefcase’, ‘agile body of work’, while renaming its supportive organization (hundreds of humans) structures into fleets, tribes (borrowed from Spotify model, despite its co-creators’ advice NOT to do it), families, etc.

This approach usually provides a temporary sense of satisfaction for an accomplishment. However, it is an illusion and is pain-killing effect is short-lasting.

Artificial ring-fencing eventually crumble.

Perhaps, not the most popular analogy these days (usually the case, when geo-politics are used) is the example with the former Soviet Union:

For more than 70 years, the fake ‘portfolio’ of fifteen republics was united by top-down, totalitarian, centralized regime. In the end, the lack of affinity between the republics (different cultures, histories, desire to be free and independent) had prevailed and resulted in a break up of the Union into independent countries that could’ve healthily co-exist in ways, other than being united by force.

…And the opposite is true too… artificially separating structures that naturally belong together, will eventually lead to inefficiencies and dysfunctions (again, no so popular geo-political analogy begs to be used here: erecting the Berlin Wall between East and West Germany to represent political spheres of control – is a very vivid example of how separation of people that share the same culture and history led harm and unhappiness).   Of course, it takes time for an ecosystem to correct itself.  But eventually, it does.  And as in the above case…

Artificial separating walls eventually crumble.

In product development, “meant-to-stay-together” structures are often artificially separated because of internal politics and other reasons that are described by Conway’s Law: these are usually artificially separated system components (e.g. UI/front-end, business tier, back-end). This separation is the result and reflection of historical organizational design and spheres of control: each component is owned by its own component (or application) owner, who is focused on high degree of output, while designing his own component.  This approach leads to a lot of sequential, asynchronously dependent and contractual work –  a classic example of waterfall.  When backlogs are created and teams are built around components (instead of customer-centric features) we see a lot of excessive hand-overs, end-of-cycle complex integration and local optimization.

What product development boundaries, and subsequently organizational design boundaries (not the other way around!), could be more supportive of customer-centric, adaptive/agile ways of working?

You may consider the following five (5) guidelines when defining your products/services and designing your organizational structures:

  • Start small and expand, instead of starting big and then trying scale down (“sunk cost” fallacy is a well known problem)
  • Perform enough due diligence when defining your products/services, to make sure that they are customer-centric and are defined as wide as possible, but not so wide that it makes them difficult for Product Owner to manage/own.
  • Do not hesitate to challenge historically known projects, programs and portfolios.  Most likely, many of them are ‘fake’ and represent a mirror image on existing organizational structures and spheres of control, and as such do not effectively serve needs of real customers.  Therefore, they may have to be discontinued.
  • Build teams around products/services in ways that enables each team support product development cycle from ‘concept to cash’ (or ‘from soup to nuts’, if you prefer), by touching all underlining system components, sub-systems and applications. Organizational design models that rely a lot on external workers (e.g. vendors) require special attention.
  • Limit a number of teams that work on the same product/service, while servicing one Product Owner and working on the same Product Backlog (usually 2-8 teams is the recommended range).