Collaboration at scale means managing the dependencies and relationships that exist naturally within architectures and Scrum teams.
In this webinar, We'll also explore techniques to create increasingly effective relationships among teams that can help Scrum teams maintain high degrees of productivity even when they must manage complex dependencies.
Brent Barton: Brent Barton’s executive management background and nearly two decades of experience in software technology give him the ability to provide valuable guidance concerning engineering capability and organizational proficiency. He has used Agile practices for a decade to help organizations overcome seemingly intractable problems and successfully deliver mission-critical solutions. Brent has written several important papers on Agile and organizational change: “Implementing a Professional Services Organization Using Type C Scrum", “Establishing and Maintaining Top to Bottom Transparency Using the Meta-Scrum” (Agile Journal), and “All-Out Organizational Scrum as an Innovation Value Chain” (IEEE). Brent also helped develop AgileEVM, connects Scrum and traditional earned value management techniques.
Venkatesh Krishnamurthy: Venkatesh Krishnamurthy is a computer scientist, Agile coach, LeSS practitioner, and Conteneo certified collaboration instructor with more than 20 years of experience working with several start-ups and IT companies across the United States, Europe, Asia, and Australia. Venkatesh (aka Venky), has rich experience applying various scaling techniques while working on large product developments with geographically distributed teams. He believes that ideas from systems thinking, Lean, and Agile methods need to be applied with patience and sense of humor in order to thrive in challenging environments. He currently lives and works in Melbourne, Australia. Venky is an avid blogger and a frequent speaker at international conferences.
Luke Hohmann: Luke Hohmann is the founder and CEO of Conteneo In.(formerly the Innovation Games Company). Conteneo's enterprise software platforms and professional services merge collaboration frameworks, data analytics, and domain expertise to help organizations optimize decision making in the areas of strategy, innovation, sales, product development, and market research. Luke is also co-founder of Every VoiceEngaged Foundation, a 501(c) 3 nonprofit that helps citizens, governments, and other nonprofit organizations collaborate at scale to solve technical and wicked problems.
Question 1: Dependencies can be across higher-level entities, like programs or portfolios (or Agile Release Trains or Value Streams if I indulge in SAFe terminology)?
Answer: Certainly! Business dependencies exist even if a SAFe program is fully decoupled. I gave the example of choosing a 3rd party standards group. Within Programs, you can have significant business and technical dependencies. At large scale, this is why I found SAFe 3.0 inadequate because the ART's were really delivery streams and in order to deliver value, many ART's would have dependencies. This made the notion of a 3.0 portfolio flawed. SAFe 4.0 tries to address this with a 4th layer, which aligns somewhat better from the perspective of dependency management.
Question 2: Should a dependency story complete in an earlier sprint, or 2 dependent stories be completed in the same sprint?
Answer: I prefer aligning dependency in parallel so we can integrate often. Left to organic behavior, the further from the customer the system is, the more the group starts asking for more and more requirements so they can analyze all possible scenarios. This creates huge delay and causes the front end to violate the principle in the Agile Manifesto to "deliver working software frequently, from a few weeks to a few months with a preference to the shorter timecycle (IN Scrum, this should mean every Sprint). So the front end team is forced to deliver with back end stubs. The Producer/Consumer pattern in practice often starts with the backend starting just in fron of the front end, then the front end gets going quickly. The goal is they finish together. If you are waiting on the backend team all the time, this is an indicator to revisit the organization.
Question 3: What is the difference between a Customer Centric Feature Teams vs. Component Teams?
Answer: Think of a component team as one that delivers a piece of a "marketable feature." An example of a marketable feature would be allowing customers to verify an item is on hand in a store before ordering on line for pick up in store. In slide 12 you see two systems. Assume for the moment you have an order system team and also an inventory management system team. They rarely will deliver marketable features without work from both. If the team is equipped to deliver on all the parts needed to deliver the marketable feature, then they are a customer-centric feature team.