A Partner is Good to Have, but Difficult to Be
- 1. A Partner is Good to Have, but Difficult to Be Dave Dikel – dave.dikel@acentia.com David Kane – david.kane@santeon.com
- 2. A Partner is Good to Have, but Difficult to Be Dave Dikel ● Senior Information Technology Specialist with InSysCo, A Maximus Federal Company David Kane ● Senior Agile Coach at Santeon Co-authors of the book, Software Architecture: Organizational Principles and Patterns
- 8. ...are symptoms of a lack of partnering
- 9. “We insist that key people take a workshop on partnering first.” Ron Grace Program Manager for HP’s internal software reuse initiative (1993)
- 10. Partnering Definition “Partnering is the extent to which architecture stakeholders maintain clear, cooperative roles and maximize the value they deliver and receive” Make the stakeholders partners Software Architecture: Organizational Principles and Patterns – Dikel, Kane and Wilson
- 11. Why Partnering Matters ● Architects can’t do it alone ● Improves understanding and coordination within and across IT and business ● Sharpens anticipation of surprises ● Makes work more rewarding
- 12. Partnering is Hard Work
- 13. Do you wonder where architecture meetings are going? ● Key decision makers and their trusted experts attended the first meeting ● Important partners are always represented but turnover is high ● Important concepts, processes and supporting facts are often revisited from meeting to meeting
- 14. Simple engineering courtesy ● Do your homework ● Size the meeting to get results and benefit participants ● Do everything possible to make best use of people’s time ● Document results
- 15. Pitfalls of too much focus on meeting results ● ● Prop up attendance through action items ● Over prepare for meetings ● Over optimistically present accomplishments ● Inflexible rules
- 16. Things didn’t work out exactly as planned? ● Feature you were counting on was left out of a release at the last minute ● Coordination meetings are filled with surprises ● “One line of code per meeting”
- 17. No Surprises ● Insist that project teams collaborate before presenting a solution ● Discourage surprises at meetings ● Assign cross-team roles ● View scope management with overall service delivery
- 18. Pitfalls of No Surprises Too much high-level emphasis can ● Discourage reporting of critical issues and risks ● Increase formality and stress Too much team-level emphasis can ● Lose team focus ● Drain team resources
- 19. Why are there so many people in architecture meetings? ● Too many people invited in the first place ● Fear of being surprised or left out ● Propagated invitations ● Long and ineffective meetings ● Poor architecture decisions Consequences
- 20. Identify and Engage Partners Seek a deep understanding of partners’ products and operations ● Identify value delivery chain ● Determine critical partners ● Spend time understanding their world ● What does the architecture deliver to them? ● What do they contribute to the value chain?
- 21. Tips for Understanding the Value Chain ● Who decision makers ask when they need to make a change? ● What does the data say? ○ How does it flow? ○ What is used? ● Earn the trust of partners who will need to live with what gets delivered ● Do not assume you understand how a long-standing organization or system works
- 22. Outcomes from Better Partner Identification and Engagement ● Stay connected with those who are most important to success ● Number of partners is reduced ● Partners uncover inter dependencies ● Partners uncover unsupported assumptions
- 23. Partner Identification and Engagement Pitfalls ● Death by analysis ● Conflicting Partner Expectations ● Chevronitis
- 24. Limits to Gate-Driven Architecture ● Drives focus on compliance not engagement ● Businesses have their own measures for success ● Misalignment detected too late ● Can be hard to enforce ● Many organizations are streamlining their gate models How else can you ensure architecture stakeholders are cooperative, responsive?
- 25. Build Reciprocity with Stakeholders ● Encourage a fair and proactive exchange of value among partners ● Review both formal and informal agreements to ensure fair exchange ● Encourage informal networking ● Budget time to respond to requests from other stakeholders
- 26. Service is the Foundation ● Service here is an attitude in action, not a technical term ● Gifted architects “see” how their products will help everyone concerned and strive to make it so ● The drive to serve can mean the difference between ○ Producing designs that resonate with customers and get used ○ Adapting the architecture to unforeseen changes
- 27. Benefits of Reciprocity ● You know who to call to begin to unravel complex “unsolvable” problems ● Problems can be resolved at a lower level of organization and formality ● People answer the phone when you call ● Personal interactions are more rewarding
- 28. Reciprocity Pitfalls ● Team members make commitments to peers that increase the scope of their work products ● Stakeholders can learn to rely too much on the architect ● Architects can agree to deliver requirements that are out of scope or in conflict with one another
- 29. Peer-to-Peer Relationships are the Core of Partnering ● Who are the critical stakeholders? ● What do they need? ● What will make architecture compelling to them? ● How do we build trusting/effective relationships with them? ● Are we passionate about serving them?