We had a small Dev & QA team, trying to adopt more Agile Principles, and aware of the growth we were going to face soon. Current setup & structure of the team required transformations so that we could scale, help improve low morale and disconnect within the team. Tried few changes but ‘flat’ with no managers didn’t work at all for us. Our talk will be about what we ended up doing that enabled us to get to a high energy agile team!

Kaikaku refers to big revolutionary change whereas Kaizen refers to evolutionary change. The changes we did with our team with respect to the structure of the team and the development process, were big in magnitude and the requirement to change was big too. With this major shift, we could scale the team and take on big projects associated with new clients, could deliver quality product every release and changed many of our clients’ perspective to a positive one and could attract lot of good talent.


Outline/Structure of the Talk

Introductions – 5 mins

  • Introduction to speakers & company
  • What’s the talk about and why should anyone care?

 Starting Point – 5 mins

  • Smaller team of around 20 devs as 1 unit
  • Created teams out of the bigger group on demand
  • Dev cycle followed by QA cycle and then release

Issues – 5 mins

  • Dev & QA separated into different cycles
  • Late feedback & unpredictability
  • No team like feeling for individuals
  • Devs ended up with shallow understanding of the domain
  • Hitting a growth period and existing model was not scalable

Big Change – 10 mins

  • Created smaller subdomain based teams
  • Dev & QA brought together
  • Senior devs as team leads & given scrum responsibilities
  • Flat structure
  • Go be self-managed!

Results of the change – 10 mins

  • Chaos
  • No one knew what to do with the process, where to begin?
  • Senior devs dragged into day to day process stuff
  • Productivity hit
  • No one was happy!

Introduce some structure – 10 mins

  • Dev Managers introduced as Scrum-masters
  • Hired an Agile Coach
  • Let’s get QA caught up first
  • Work with teams to define
    • Dev Ready
    • Definition of Done
    • Sprint commitments
  • Established key meetings

Key observations – 5 mins

  • Teams loved it!
  • High energy
  • Customized changes done by each team
  • Introduced ideas like Guilds
  • More participation in Book Clubs and Lunch N Learns
  • Felt like a Team!

Future – 5 mins

  • Self-aware & directed teams
  • No estimates
  • Kanban

Learning Outcome

Attendees will learn about

  • Team Transformations
  • Handling team growth
  • Flat vs ‘Some’ Hierarchy for Agile teams

Target Audience

Teams going through transformation right now or planning to do so with respect to structure. Also for teams looking at significant growth in size in near future and how to handle that.


schedule Submitted 4 years ago

Public Feedback

    • Chris Edwards

      Chris Edwards - Agile Introverts, an Oxymoron?

      Chris Edwards
      Chris Edwards
      Sr. Manager
      IHS Markit
      schedule 4 years ago
      Sold Out!
      45 Mins

      Collaboration, collaboration, collaboration. This is probably the most used word you'll hear from agilists. It sits right at the core of agile principles. How do we reconcile this with the fact that 30% of the population is introverted?

      There has been extensive research around introversion that can help us understand this apparent contradiction better. This talk will explore the complexities of introversion, from the distinction between shyness and introversion to the complexities of pseudo-extroverts and "high active" babies. 

      Finally, what can we learn from companies like Menlo Innovations and Hunter Industries, where they have high collaborative environments with introverts that say they would not work any other way.

    • Sean Dunn

      Sean Dunn / Chris Edwards - Scaling Your Continuous Deployment Using Docker and Containers

      90 Mins

      How can new tools and technologies shorten our feedback cycles, and reduce pain and frustration of deployment and maintenance of systems? How do you scale your continuous deployment system to support more developers? This hands-on technical session demonstrates how new containerization technologies like Docker and Concourse CI can be used to build deployment pipelines. Sean and Chris will show how to build a deployment pipeline, configuration-manage it, and deploy software through it. 

      No previous technical knowledge of Docker or Containers is needed. 

      This will be a 2 part. The first 45 minutes will go into the basics of docker. The second 45 minutes will show how to setup a Concourse.CI continuous delivery pipeline.

    • Ravdeep sekhon

      Ravdeep sekhon / Sheldon Fuchs - Kaizen in Hiring

      45 Mins

      Everything a dev team does can borrow from Agile Principles, including hiring great developers. We as a company are customers of our own hiring process, our requirements have changed significantly from once hiring 6 people in 2 years to hiring over 20 this year alone, and we have to experiment and adapt over time in order to hire the best people for the job. This talk is about how at Solium we realized the core Agile Principles can be applied to hiring and iterated the process during the last 18 months. During the course we got rid of some sacred recruiting beliefs (hint: "culture fit" means nothing!)

    • Chris Edwards

      Chris Edwards - The Agile Architect: Turning Followers into Leaders

      Chris Edwards
      Chris Edwards
      Sr. Manager
      IHS Markit
      schedule 4 years ago
      Sold Out!
      45 Mins

      "The higher you go in an organization, the more your suggestions become interpreted as orders." - Marshall Goldsmith

      An Architect garners a high level of authority by being an expert. People will follow their lead. But what if the Architect is wrong? They will follow right off a cliff.

      How do we get people to think like the Architect? Use the principles of Intent-Based Leadership to decouple the success of your project from the personality of the architect. By creating clarity around architectural goals and by engaging people in problem solving rather than defining rules and standards we can divest control and create an organization of leaders.