A set of short notes from the GOTO Chicago 2015 conference. Notes focus on microservices and processes.

Is SAFe evil?

Lars Roost & Henrik Kniberg

Notes

SAFe assumes scrum at a team level with a team backlong, testable story and sprints of around 2-3 weeks.

It groups agile teams into teams of teams (the “agile release train (ART)”) with a higher level program backlog with product features.

Portfolio level has epics which translate to business cases. These epics generate features.

Misconception that SAFe limits releases once every x months. That’s not the case and instead simply the time boxing. Many releases can be made during that period.

Feedback on the last high level planned phase

Show a sample of what has been done

Use lightning talks to share breaking changes everyone should know about and other miscellaneous changes (legal and regulatory etc.).

Teams break out for their own planning.

Each team gives their objectives, stretch objectives, risks and the main users stories for the next 4 sprints. Things are allowed to change from this.

Dependency mapping done on a physical board with the input between teams. This is a centralised tool to enable decentralised behavior.

Risk board. Used to get teams to resolve risk on the spot.

Toward the end the day because every team does not want to know each teams plan but they do want to know about some teams plan they run a poster workshop type system where one member of the team stays behind to present and answer questions whilst the remaining team members visit other teams.

The second day is more traditional.

A retrospective occurs at the end of the second day.

Is this SAFe? Who know/who cares?

Shu Ha Ri

  • Shu = Follow the rules
  • Ha = Adapt the rules
  • Ri = Ignore the rules

Like

  • Big room planning makes it a social event. Makes it feel like a start up.
  • Dependency Board is a really useful tool
  • Risk board. Lightweight tool to manage risks

Beware

  • Dont get stuck in shu. It can get you started but important to adapt them.
  • Watch out of Queues and batches. SAFe can turn into a big monster
  • Dont belive in hype and anti-hype. Plenty of it in the agile space anyway.

Wrapup

  • It is a toolkit
  • Built on lean and agile principles
  • Use what you need only from the toolkit
  • SAFe useful when you have teams working on the same product or teams working on different products with many dependencies
  • Experiment

LEGO use the first three sprints for deliver and the last sprint as an idea sprint (and gives slack in the plan if something overruns). The Idea sprints can be used for developing new ideas, hackathons etc.

Scrum at Scale

Jeff Sutherland

Notes

“I was amazed at how many people it took to get so little. I asked how many people have working code at the end of their sprints. Only 20% raised their hands.”

Different organizations have different approaches

  • Large defense contractor
    How do they report to the government in SCRUM
  • Mid side software company - Autodesk
    The startups we buy are doing SCRUM better than us.
    Need to float their ideas up to management
  • Growing Agile Native Company - Spotify
    Inovation over productivity as 100% productivity = 0% inovation
    Self organized teams around the managers visons
    Major focus on how they deliver to the customers faster

Managers need development to make them agile, the developers already have that skill.

A lot of agile implementations are very poor

Scaling scrum requires the organization to become a generative organization where people focus on the misson and people look for basic problems in the system.

Organizational debt has just the same impact as technical debt.

Organizations are moving to becoming smaller but federated under a larger umbrella.

Lots of projects are still agile in name only as they are not delivering any working software or not satisfying the customer.

A leadership action team crushing the following type of impediments
- Too many project in pipeline (resulting in high context switching)
- Everything been top priority
- Pressure to get things done delays project and reduces quality
- Lack of understanding of scrum
- Fear of exposure of change in responsibilities
- No continuous integration or automated testing
- Coachs/ScumMaster not surfacing impediments
- Management not focused on removing waste

Evolutionary Architecture & Micro-Services

Rebecca Parsons

Notes

Data was everything and the DBA with the relational database was …

SOA made some mistakes. The largest was the monster services driven by orchestration (instead of choreography) which resulted in the product been hard to test and difficult to change.

Micro-services learns from the mistakes of SOA.

smart endpoints and dump pipes.

Monitoring is required as we now have many more components

Flexibly need to be managed.

The following must be mnanaged
Platform flexibility - Just because you can use whatever you want doen’t mean you should be duplicating what you already are doing.
Eventual constancy - Ensure stakeholders know what it means and that they are managing the potential states of data
Infrastructure churn - Control changes to interfaces

Greenfield projects are not the best projects to start with microservices.

Tolerant readers, only require your service to change if the change is within the area that affects you.

Automated contract testing. When tests breaks it should trigger a conversation.

The riggers in CD also are important for microservices.

In summary, build a good monolith first.

Challenges in Implementing MicroServices

Fred George

Notes

Everyone doing MicroServices at the moment will be doing it differently.

Event bus

Incremental applications

Need to add rivers to the event bus.

Chad Fowler vs Fred George

  • Chad argues that synchronous by default as requirements/algorithms generally defined as synchronous
  • Fred argues that asynchronous by default as that give the bigest gain

Need Asynchronous Pattern

Clever way to provide responce to a need with one or more solutions.

Consumer then picks sweet spot of what microservices is compared with SOA