CAS Managing Technical Architectures
   

Topic Summary

The most important artifact in all of Scrum is the product that the Development Team is creating in each sprint. Unfortunately, too many organizations struggle to manage their technical architectures in a manner that enables them to realize greater agility.

This webinar presents specific skills that Scrum Teams can use to manage their technical architectures, how to identify "as-is" and "to-be" changes to ensure your architecture evolves, how to leverage Conway's law to your advantage by aligning technical changes to Scrum teams.

Top 3 Questions Asked

  1. Is this then a proposed format for capturing and representing an architectural item in the product backlog?

  2. Who generally makes the decision to facilitate this type of activity... how would I do this being a contract Agile Coach for a large telecom company for example?

  3. How do I integrate huge architectural changes into the feature development. I teach my POs to avoid technical user stories and don't want to contradict myself.
 

Featured Framework

     sailboat card-1

Speakers

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 KrishnamurthyVenkatesh 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 HohmannLuke 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.

More Frameworks Discussed in this Webinar

      sailboat card-1Curve Jump Cardplanning wall Basic Tree Card

Contact the Collaboration at Scale Team

Subscribe and Receive Conteneo's Newsletter and Updates

Top 3 Questions Asked & Answered

Question 1Is this then a proposed format for capturing and representing an architectural item in the product backlog?

Answer 1No. I think the right sequence is to create Visible Architectures of your current/as-is architecture and if needed your desired/to-be architecture. These should then be added to your roadmap or Prune the Product Tree framework in the roots. Once these items have been properly strategically prioritize they can be added to the backlog for execution.

Question 2: Who generally makes the decision to facilitate this type of activity... how would I do this being a contract Agile Coach for a large telecom company for example?

Answer 2: As a contract Agile Coach I think part of your job is suggesting to your client activities that you think would help them succeed. If you think this would help your client, I recommend working with your account team to develop a proposal that would either authorize new funds to invest in this activity or allow you to prioritize your backlog of work so that you can tackle it. More simply, any team that does not clearly understand their technical architecture has a significant impediment and the job of Agile Coaches are to help remove them.

Question 3: How do I integrate huge architectural changes into the feature development. I teach my POs to avoid technical user stories and don't want to contradict myself.

Answer 3: Don't confuse writing a Product Backlog Item (PBI or story) with prioritizing it. Let’s review the primary responsibility of the Scrum guide: The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. This means that the PO should clearly be prioritizing technical work because technical investments contribute to significant value.