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 Members 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: http://www.meetup.com/Large-Scale-Scrum-LeSS-in-NYC/events/229733065/Based on the volume and type of questions, in the next …

Check out this Meetup →

 

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

black_green_black_thin_2

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:

IMG_7284

IMG_7285

IMG_7283

IMG_7281

IMG_7286

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

black_green_black_thin_2

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.


jeff_presenting-2


jeff_presenting-3


jeff_presenting-1


gene_jeff-1


jeff_signing

avi_jeff_gene

20160915_092835_resized

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

black_green_black_thin_2

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

Getting to Agile

black_green_black_thin_2Author: Howard Frost

In the current US presidential primary elections there are candidates from both the far left and the far right who have taken very absolute positions on sensitive issues. However, it seems unlikely this will be the year the US votes for a revolutionary shift in policy.

Voters are digesting a mix of good news (improved job market, low inflation and gas prices, rising stock prices) and bad new (ISIS, gridlock in Washington, income inequality). The country has not made any great strides forward or fallen off any cliffs – we seem to be muddling along. Why make radical changes under these conditions?

The same thinking can be applied to large multinationals. Unless they sense an existential threat there is little appetite to make the kind of radical top to bottom changes called for by Agile. Instead these companies see Agile as a tool primarily meant for organizing software development teams.

Will a partial, imperfect adoption of Agile principals benefit a company or only provide cover for existing dysfunctions?

I have seen better software emerge when Scrum teams are formed and aligned to a Product Owner. There is more transparency around the progress and health of the project, communication between technology and business improves, people feel less isolated, and there is far more learning taking place.

Changing hierarchical decision making, organizing a company around long term quality rather than metrics and milestones, and adopting people policies that value teamwork and expertise is more difficult to achieve. I believe external competitive pressure will eventually require companies to address these core issues. In the short-term, the pressure Agile areas of company impose on the rest of the organization will continue to shine a light on these larger issues and help educate and prepare the company for the more fundamental core changes to come.

What do you think?