Category Archives: sglas2013

Session on Large Number of Teams and Complex Software

Convener: Scott Duncan
Participants: (probably had twice as many people attending but the
following are the only ones who identified themselves through signup sheet
or business cards): Scott Cothrell, John Gouveia, Ari Brown, Cliff Oliveira, Marc Story, Rahil Patel, Ryan Garcia, Jerry Lathem, Eric Yang


Focused mainly on scaling and team distribution and little on the complexity of the software.
With a large number of teams, where do all the Scrum Masters come from if they are to be ”just” Scrum Masters.
Agile can make distributed teams harder due to the assumption regarding direct contact between people. On the other hand, the emphasis on communication encourages not falling back on “document passing” as the default (and only) assumption for contact.
A key outcome was to collect contact information from people who wanted to continue discussion on this topic after the Gathering. Anyone else interested in such a “community” can contact me at

Also collected the following “data” from some attendees:

#Teams Company Domain

160 Intergraph “CAD”

50-65 DoD/VA iEHR

~20 Jack Henry financial

12 network platform

500? Adobe design, docs, analytics

2 NASA simulation

10 AMDOCS carrier billing

220 Splubk big data/OI

12 Cisco security

300 Vanguard financial services

Women in Scrum Open Space

The following is a list of topics discussed:

  • We introduced ourselves
  • We created a list of important topics (via brainstorming)
  • We prioritized the topics (in the interest of time I grouped them later and they could be rearranged as the group sees fit)

15- create a community outside of the conference

2- have some conversations/ connections

10- learning, supporting, mentioning

2- young women have it harder

5- how do we attract more women to scrum

20- encourage women to come forward and be visible

3- women on the board

3- no women keynote

4- blog more

0- get voices heard

#?- help people stay engaged when life happens

1- how do we observe scrum as women

Ideas for potential ways to stay connected (This will be organized by Leslie going forward with help from others)

  1. LinkedIn (SA already has some groups and could add ours)
  2. Meet Up
  3. Facebook
  4. Google Group


  1. Carol offered up the “go to meeting” acct for SA that we can use
  2. Distribution list agree a date tool
  3. Lean In book recommended

Thoughts – we for sure want to be inclusive and grow but we wanted to keep it small until we get our feet under ourselves (1 month?) and then expand it. The idea is to grow but we don’t know what we are yet…

doc iconScrum Gathering Women in Scrum notes.docx

Lean Startup Combined with Scrum

Group Learnings:

(In the Group’s words) Get the book!

Tool for Product Owner Lean Canvas [Tool to represent the business model and experiments]. Find quickest way to test assumptions.

Lean is geared towards product analysis.

Lean vs Scrum

Minimum Viable Product (MVP) Impact analysis

Lean Startup concepts help a Product Owner be a better Product Owner

Lean Start is for Product Owner

Convener: M. Kelley Harris

List of Participants: Andrew Kallman, Kevin Graves, Moonie Lantion, Robert Morris, Lynn Winterboer, Vivtek Malhotra, Bernd Klupp, Sateesh Nagilla, Vinay Nagarnj, Harry Nieboer, Ran Nyman, Pavel Dabrytski, Janet Figueroa, Rob Spieldenner

Team Motivation (Excited about Agile?)

Convener: Bill Slocum

Participants: (See below)

The purpose was to do some collaboration on how to get team members more excited about Agile so they want to do more. They need to understand that this is not just another passing fad. Key points were captured and are attached here. High level summary: We know that motivation is not easily solved. There are many factors that affect ones motivation, and what works for some teams may not work for others. Affecting factors range from external sources (such as management and others) to personal reasons for the individual themselves (some will never be motivated). A short summarization of our discussion on possible ways to increase ones motivation; through the use of continuously sharing the measurable benefits, incentives, anonymous input from the team for retrospective (on people/reasons causing motivational issues), reminding team there is not much to fall back to (waterfall is worse), small celebrations during sprint on progress (can be a simple ‘woo hoo’), and team self evals to name some. Thanks to all for their input! This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation













How to find out how good you are at agile at your company

Organised by: Harry Nieboer (

Setting: my company in the Netherlands sends out employees to conferences (like the Scrum Gathering) and training. But how good are we performing anyway, and does investing in learning really help? How do you actually find out how good you are at agile? We started the discussing with three questions:

1. Who cares? Is this something management should care about? (at least according to the developers) Is this something the Scrum Master should be held accountable for? (she is the one with the mission of making the team work well together) Is this something the Team should be held accountable for? (could well be part of self organizing)

2. How would you assess your current agile capability? Should you use independent audits? Could you let your teams fill out the Scrum Checklist from Henrik Kniberg? (

3. And then? Publish the results, to encourage competition? Act on the impediments? We discussed the above three questions and concluded the Why was missing. If you know what you want to accomplish, you can than derive what you should measure.

* For my company mostly doing projects for external clients, we are aware that we need to become a more agile company. More agile meaning being able to start up new projects fast, having environments and complete oiled agile teams available within days. The general understanding was that all should care. There were additional suggestions on how to do the assessments: surveys, 12questions (used at Nokia) and (free) checklists at . There were suggestions on metrics to look for:

* How long does it take to get an idea to production

* Bug response time

* Ratio between value delivered and failures

* Business value

* Waste due to waiting (measured in queue length or total queing time)

* Cycle time Especially, you would like to measure leading indicators (and not lagging), helping you to change directions when necessary. And what to do with the outcome?

Publishing results can be risky (people might nog want to be open in answering questions the next time), although transparency was considered important. An other outcome would also be to change teams (transfer your best developer to a team having issues in this area, so they can pair and the team can grow).

Participants were: Sami Lilja, Gil Nahmias, Erin Jostes, Boris Jurcic, Oliver Gommer, Paul McGregor, Remi Kok and David Kane, and some ten others whose names we did not get.

Agile Software Development in the Government

Convener: Charlene Cuenca

List of Participants: Charlene Cuenca, Becky Redeker, Frank Balogh, Don Macintyre, Scott Cothrell, John Duque, John Gouveia, David Kane, Tom Mellor

Topics included:

  • Project setup and composition
  • Each person discussed their company and project role
  • Team structures
  • The size, composition, and processes within the teams
  • Product owner issues
    • There were several issues revealed about product owners not being in the ideal role. They were product owner proxies or project managers but not really representative of the end user or customer.
  • Non Ideal Scrum setups
    • There was a discussion about a team that did not have release planning, a team that did not have daily stand ups, a team that had moving release dates
  • Sprint lengths
    • Sprint lengths varied from 2 weeks to 3 weeks to 4 weeks to one month
  • Certification and Accreditation issues
    • The group discussed the issues with the certification and accreditation process within the government and how it affects the development cycle. This typically resides out of the release cycle and can affect the next sprint cycle capacity.

Acquisition process
The acquisition process is known to be a cause of problems in agile development. There is an ongoing effort within the government to make the acquisition process more agile. As of today the process change has slowed but has the backing of several key members in the agile community. Discussions and recommendations: This was a collaborative round table discussion focusing on the issues within Agile projects in the government space. It was noted that different branches of the military could have different issues implementing agile processes due to the core differences in the military branches themselves. A participant stated that the Marines in general seem to be more agile – they are tasked with a problem and work as a team to resolve it out in the field. Those higher in the Marine structure will let the team form and solve the issue. In other branches, there may not be that level of cooperation. The traditional command and control structure within the government seems to hamper the agile development effort. The grassroots effort going on within the DoD seems to stall when reaching the middle management level . The acquisition process was also discussed as a reason for the slow transition to Agile processes.

Several resources were shared that were related to Agile within the Government. One was the adapt group. Also a video link was shared featuring Teri Takai.

Overall the session was useful and it was interesting to discuss the various ways that projects are implemented in various branches of the government.

No Estimates: Alternatives to Estimates

Title: No Estimates: Alternatives to Estimates

Convener: Woody Zuill

Participants: There were approx. 45 participants

Discussion:   We asked the question: Why do we think we need estimates?, and collected post-it notes with the reasons we “think we need estimates”

We then grouped them, and found the following groupings:

1 – Predictability (about 3/4 of the notes collected)

2 – “Go or No Go” decisions

3 – Prioritization

4 – “Fill” a Sprint with work

This led to a second rhetorical question: Why do we need predictability?

- We decided that a “5 whys” exercise should be done to get down to the bottom of the real reasons we insist that estimates are needed.   We discussed the idea that MUCH of the training in the Agile field is about estimates, prioritization, sprint planning, release planning and so on, and yet there is nothing in the Agile Manifesto that points to the idea that estimates or this type of planning is needed or important.   At this point we asked for discussion on possible alternatives to estimates.

A few were discussed:

- Kanban

- Pull discrete pieces of work

- Early and often delivery of working software

Some time was spent addressing the idea that “we still have to do estimates to be able to make software”.

Conlusion: While there are some people working without estimates, there are still many unanswered questions about how to go about doing that. It was observed that there are many different environments and while “no estimates” might work in some, it might not work in others.   In other words, we had no “conclusion”, but we did have a lot of ideas we can explore when we get back with our teams and daily work.

Collaborative Continuous Learning

Convener: Woody Zuill

Participants: Approx 10 people

Discussion:   We shared ideas about how we’ve been finding ways to encourage learning collaboratively on our teams.   The basic idea: Learning together as a team can be a way to identify the things we need to learn, and at the same time accelerate our learning.   I shared a few ideas that I have seen (such as Evan Gardner and Willem Larsen’s work on accelerated group learning for language fluency), coding dojos, and other shared learning experiences.   As the group discussed various experiences they have had, we captured this list and discussed each one to get the basic ideas:

- Pair programming

- Code dojos

- Actually do stuff together

- Guilds (across team sharing at “role” level)

- ”Pair” coaching

- Coaching Circle

- Coaching dojo

- Observer, both as Learning and as Master

- Expose ideas using “What I did in a similar situation” wording

- Have a “Daily Focus” each day

- like continuous integrations, TDD, etc.

Metrics That Work – Our Journey From Ugly to Effective


- Rahil R. Patel (@freemarket)

List of Participants

- I had about 40 – 45 folks in the room

- I screwed up and didn’t take attendance.

Discussion and Recommendation:

Initial 10 minute monologue from me about our journey from the Early days of metrics centered around task hours and capacity planning through the ‘middle ages’ of metrics and then what we do today. We had an engaging conversation on what others are doing in their organization, and what’s working for them. We also discussed Metrics in the tactical context (Sprint Metrics) and the backlog context. We did run out of time to be able to discuss more on what does not work with participants and their organizations. A lot of great ideas surfaced and were discussed. I’ve provided my email to participants to feel free to contact me to continue discussing and give them examples (screen shots) of metrics that help us. I’m going to post my voice file later as I’m facing technical challenges with the file.











Grass roots Agile teams surviving in a strong PMO environment

Convener: Gary Moore

List of participants: Tuyen Tran; Niloufar Dasti; Ian L.; Aleks Gill; Alex Kidd; Charles He; Raoul Kaiser; Jeremy Perdue; Charlene Cuenca; John D.; Mimi Sulfridge; Dimitri De Nil; Grant Meyer; Jimmy Strobe; Dave Limbaugh; Merland Halisky; Elaine Bulloch; Tom Cagley; Jadish Karira; Carmen MacKinnon; Vivek M.

The session began with Gary sharing his observations at the company he is working with: In an effort to be more successful, the development organization adopted Agile/Scrum and self-organized into 12 teams. For several reasons, the Project Management Office resisted the necessary change for Agile to thrive and became more stronger over time. The Agile development organization has suffered since because of this. For the next ~30 minutes the attendees that were experiencing similar challenges at their companies shared with the other attendees. A small number of attendees that have had positive experiences shared during the last ~15 minutes.

Some observations from the discussion:

o Some level of change needed to occur in the PMO for Agile to thrive and it happened over a long period of time (2-3 years) o Strong upper management support was needed to allow Agile teams to be respected by the PMO

o In the absence of this, some deception was necessarily (e.g. a “second set of books” with PMI metrics were derived from Agile metrics) in order to communicate project status to the larger organization

o A strong definition of roles needs to be communicated and understood so PMs/POs/SMs don’t work at cross purposes

How to become CSC?!

Session Host: Andreas Schliep, Certified Scrum Coach & Trainer & Friends

Session members: [many]

About: Information and insights on how to become a Certified Scrum Coach.

Brief introduction to the CSC program, application prerequisites and process. More information:

Scrum of Scrums

Discussion focused around what folks are doing in terms of ceremonies at a scrum of scrums level. Most folks had some form of daily/weekly meeting of scrum of scrums, however having planning, demo, and retros at that level was much rarer.


Growing Leaders – LEANing Academy

Convenor: Peter Hundermark

Participants: Not recorded (did include Tommi Johnstone, Rafael Sabbagh, Mark Summers)

The problem statement:

Newly minted Scrum Masters returning from a 2-day CSM class have a 1% probability of transforming their organization to Agile. We know organizations that get (good) coaching have a high probability of succeeding with their transformation. We wanted to discuss ideas for bridging the gap between these two extremes.


I gave a brief presentation to the class of my idea and the MVP I plan to execute with a group of fellow coaches and mentors in South Africa.

The basic idea for an MVP (Minimum Viable Product) to test the market is:
- A class of ~16 Apprentice leaders sign up for a semester programme.
- A group of at least 4 Mentors (facilitators, we have 6 in our case) formulate the programme and a potential core curriculum.
- The whole class meets face-to-face with the mentors on a monthly cadence.
- The initial meeting is 2 days to do group chartering and to co-create the learning objectives and course curriculum, using what the mentors provide as input.
- The final meeting is two days including assessments for each apprentice and a celebration. All mentors attend the initial and final meetings.
- The interim meetings are 1 day each. Two mentors facilitate on a rotational basis to provide continuity.
- The total class face time is 8 days over 20 weeks.
- In parallel with this programme each apprentice is assigned a personal mentor. Mentors have up to 4 apprentices. Apprentices get 1-2 hours/week of personal mentoring. Mentors also meet for supervision.
- Apprentices, their Sponsors and Mentors form a three-way contracting relationship to assure that value is provided and obtained. Sponsors are most likely to be the line managers of the Apprentices.

The flip charts tell more of the story.

















I’ve also included my presentation slides from an Ignite talk I gave at KLNA13 in Chicago a week ago.

pdf iconLeaning Academy Ignite.pdf


Some attendees shared their own experiences — see the flip charts.

There was a discussion around the challenge of valuing and selling this programme: Notionally we agreed that a CSM class will cost ~$1000 and coaching could cost $10000 to $100000+. Calculations for our MVP suggest a cost of $8000 for the programme.

















The participants showed interest in the concept. Some who shared their opinions thought $8000 to be ‘cheap’. I will try to find a way to report back to the community the outcome of our MVP, which is planned to run from July to November 2013.

Agile UX: How? Where? When?

Convener: Luke Walter, CSP

Participants: Kevin Graves, Vivek Malhorta, Carlos Morales, Margann Snider, Charlene Cuenca, Voltaire Guiyab, Jeff Meyer, Lasse Koskela, Kelley Harris, Jeremy Perdue, Matt Sharpe, Kristen Stephens, Bernie Maloney, Rob Nickolaus, Scott Duncan

Discussion and Recommendations: Attached as photos of flipchart pages generated

ux3 ux5 ux4 ux2 

SAFe and scaled agile experiences

Convener: Steve Spearman and Jaya Pattaswamy (merged sessions) List of participants: (attached picture) + Peter Hundermark, Jeremy Malin, Henry Dittmer (and likely others who missed the signup sheet) We started with a survey of participants and what they were seeking. Over half the room was looking for an introduction so Steve started with a drawing and a description – with much assistance from Al, Rachel, Henry and Jeremy. We reviewed -the 3 levels: Team, Program, and Portfolio -how Kanban is used at the portfolio level and Scrum + XP practices for the various scrum teams that make up the “value chain” -the 2 day release planning event and how that serves to create alignment and an eventual “release plan” for the 8-12 week PSI (potentially shippable increment – at a program level). We fairly quickly got into some of the concerns – like the smell of having a systems / integration team that is “centralized”. We discussed one view that the intent is to keep these levels light and that over time they might fade away. There was some skepticism on the fade away part :-) Both Al and Rachel gave some eloquent perspectives on how this approach can speak to people in ways that we’ve failed to do with basic Scrum and many of our other frameworks. Whether this “accommodation” to organizational realities is appropriate and still “agile” or a capitulation seemed to be one of the key points of disagreement. There was no real conclusion here (nor was one expected) but I think we succeeded in providing an initial introduction to the method and some of the issues (and we didn’t even talk about normalized velocity :-) Thanks to all who participated and I really appreciate all the different viewpoints. -Steve









Pin the pattern

Convener: Kevin Callahan Participants: Luke Walter Lasse Koskela Interactive game examining communication patterns and anti patterns to building collaborative space. Sent from my iPhone

Agile DW/BI: challenges and solutions

Convener: Lynn Winterboer Participants: Don MacIntyre Andrew Webster Grant Meyer Dave Limbaugh Jake Calabrese Monica Ortenzio Tom Austin Sateesh Nagilla Leslie Morse Typical Issues DW/BI teams have with agile adoption: – Design: Trained from youth to design for answering future unknown questions – Testing: Typically don’t have strong testing discipline to begin with, let alone rarely do automated testing, and testing tools aren’t often geared toward databases. – Test Data: Regulatory limitations on copying data from production to test environments (need to find ways to obfuscate the data to do this). – Documentation: Always struggling to keep the data dictionary up to date. “that was some knitting the kittens got into”. – “We’re different” – Not used to leveraging mainstream software techniques like continuous integration and automated testing (“DW folks are to the rest of IT what the rest of IT is to the Marketing team”) – Analysis: …Seeking to find “one source of the truth” – analysis takes forever. …Analysis in data projects is like building a skyscraper in London – never know when you’ll hit the remains of a Roman building, all construction comes to a stop while you figure out what it is and if it needs to be historically preserved. Solutions discussed: – Getting people past “no you can’t” and experiment, then they CAN – Honor the data team’s concerns – they have some big challenges that are legitimately hard to overcome… – Dig at “why” they struggle with the mindset of evolutionary architecture. Similar to issues BAs have – their fundamental value proposition and training goes against it. – Automated testing: …DbFIT …Custom testing mechanism: SQL that runs and builds tables, populates tables, runs ETLs, leverages excel spreadsheets – Platforms out there that allow you to do data obfuscation whereby a person gets a different name and remains that different name in the DB going forward. – Parallel production system that only a subset of people can access. – Blue/green switching, A/B switching (multiple production platforms) – A special platform that only a few key beta customers can access. – Documentation is essential – what have you “filled out” and what haven’t you! – Use a wiki for documentation – Must, Should and Could documentation. – Self-documenting code – Informatica MetaData Manager – works with Erwin. – Specification by example: Specification that’s testable without further interpretation Lynn shared the attached handout containing 2 of her favorite slides from Ken Collier’s presentations. Thank you, Lynn Winterboer Agile Analytics Coach 303-859-6233 > pdf iconAgile Analytics Handout.pdf

How to start your team: kickoff meeting

Convener: Pavel Dabrytski participants: 6 participants Discussion and recommendation: Things to discuss at team kick-off meeting: Team name Team members (name, phone, email, IM …) Tools (task board, screen sharing, video conferencing, wiki URL …) Working agreements ( individual schedules, core work hours, standup time, sprint length, meeting times, start day of sprint, PO availability, does PO attend standup …) Team values Product vision Milestones Communication with other teams definition of done Definition of ready

Agile Portfolio Management Dashboard

How can the health of the scrum teams be rolled up to a PPMO dashboard?

Convener: Hans Janggen

Participants: Andrew Kallman and 6 others


  • The Porfolio Owners (Senior Management level) value point, authorize and stop work on epic stories
  • The Scrum delivers value on the tactical level
  • The Portfolio Owners need to have sufficient information so that they can assess the health of the team and stop the project (epic)


  • Useful to have a standardized tool set used across all teams (i.e. Excel, Jira, Greenhopper, Seenowdo etc)
  • Use the burnup and team release plan (the non-gant gant chart) for PPMO dashboard reporting
  • Use burndowns charts and kanban boards on the tactical team level See also below the pictures of outcomes

1. Overview/Orientation

2. Details

3. Sources

Hans Janggen Scrum Master, Dragon SAP Project M: 508 446 5365