Don’t Let Process Hold You Back: Best Practices for Cross-Functional Collaboration
•Als PPTX, PDF herunterladen•
3 gefällt mir•1,665 views
Creating great software takes many skilled people. There’s business requirements to fulfill, technical requirements to consider, development, testing, packaging, and the release. While having a single cohesive process is crucial to helping all these teams work together, they’re often working in disparate systems with their own processes and workflows. What’s more, these teams are often spread across different departments, buildings and even time zones. How can you ensure your teams stay in sync and create better processes that allow individual teams to move fast and be agile, while maintaining effective cross-team collaboration? In this webinar with GitLab, we discuss how establishing a ‘single source of truth’ is critical to functional collaboration, and cover the best practices for: - Building processes that yield better results - Keeping cross-functional teams in sync - Integrating tools for better workflows - Tips for remote teams
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Don’t Let Process Hold You Back: Best Practices for Cross-Functional Collaboration
Ähnlich wie Don’t Let Process Hold You Back: Best Practices for Cross-Functional Collaboration (20)
Mehr von Tasktop
Mehr von Tasktop (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Don’t Let Process Hold You Back: Best Practices for Cross-Functional Collaboration
- 1. Don’t Let Process Hold You Back Best Practices for Cross-Functional Collaboration
- 2. GoToWebinar Housekeeping Check your email tomorrow for recording and slides. If you are having technical problems, please contact GoToWebinar: Toll-Free: (855) 202-7959 Long Distance: (805) 617-7049 *United States Numbers
- 3. Meet the presenters Victor Wu Product Manager, GitLab Cynthia Mancha Product Manager, Tasktop
- 4. Software is created by many stakeholders Software delivery process is not limited to development and operations 05 01 02 03 04 Expected business outcomes Product requirements UX and design considerations Sales, marketing, and customer feedback Development & production Software Development Lifecycle
- 5. PLAN CODE TEST DEPLOY ANALYZE DEVELOPMENT DELIVERY Working in many, disparate systems
- 6. To quell the chaos, we create processes AgileScrum W A T E R F A L L Methodology REQUIREMENTSB A C K L O G Collaboration S T R U C T U R E PHASES IMPLEMENTATION Sprint ● Collaboration framework ● Human interfaces ● Visibility ● Efficiency Advantages:
- 7. Why do processes breakdown? ● Information silos ● Repeated information ● Broken telephone ● Compliance Why did the chicken cross the road? The Business Owner: Because I have 3 other business initiatives riding on the chicken being on the other side of the road that were supposed to start 6 weeks ago. Developer: Because the requirements said so. The trebuchet was the most efficient method. Oh, she had to get to the other side alive? Where was that in the requirements? Scrum manager: Let’s iterate, people. Let’s get the chicken to the center line today, and we’ll talk about the rest of the way tomorrow. Product manager: The chicken cannot cross until the 10 missing requirements make it back into the functionality. Process for the sake of process.
- 8. Understanding process Conway's law: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." Process is about connecting people and ensuring that they are communicating and collaborating effectively
- 9. Collaboration & communication are ongoing It’s natural to have many tools, workflows, and processes across different teams and organizations, but the people involved still need to stay connected throughout the process. This can be accomplished by: ● Async work styles ● Integrated tools ● Processes that optimize for collaboration Even when considering cross-functional workflows
- 10. Best Practices for Cross-Functional Collaboration How to be less prescriptive and more descriptive
- 11. 1. Goals first, process second. What you initially thought the goal was What the initial optimal solution was Optimal solution moved to ● Get all stakeholders (biz, DevOps, marketing, UX, etc.) together up front to determine goals and outcomes ● Establishes clear expectations and gives everyone a chance to voice their concerns about scope ● Determine the best process for reaching the desired outcome, review cycles, and communication vehicles
- 13. 2. Establish a single source of truth PLAN CODE TEST DEPLOY ANALYZE DEVELOPMENT DELIVERY Tip for remote teams: Avoid meetings, especially when stakeholders are scattered across time zones. Instead, determine a single source of truth where information can be written down, conversations documented, and collaborators can work asynchronously.
- 14. 3. Clear, visible outcomes ● We use GitLab Issues to coordinate outcomes for each phase of the project ● Issues can be linked to merge requests so stakeholders can see the changes in a production-like environment ● Everything is connected and publically accessible to those involved in the process ● Concerns or problems can be flagged at any stage of the process by any stakeholder
- 15. 4. Work cross-functionally from start to finish Instead of locking communication per-stage, per team, or per-specialty principle, leave the doors as open as possible. Tips for achieving open communication: ● Embrace principle of “Written-first online conversations”. ● Use real-time editing tools for meetings. Everyone can add to agenda, add notes, can see what was discussed, and immediately see follow-up items. ● Prevent “Not Invented Here” syndrome by practicing Innersourcing—make it possible for the rest of the organization to contribute. ● If you can make something public, make it public!
- 17. 5. Improve the process in iterations ● Avoid throwing out all process and starting from scratch ● Take advantage of the tools you have and work to pull together disparate tools & communications ● Make small changes, test them, and incorporate learnings Tip for remote teams: After each release cycle, hold an open forum retrospective to go over what worked, what didn’t, and how the process can be improved.
- 19. “Structural holes are the gaps that exist within organizations between people and groups of people. Every organization has them. They represent a lack of communication between people, and are a limiting factor on companies’ ability to be agile and responsive to changing conditions.” -Dr. Ronald Burt, Professor of Sociology and Strategy University of Chicago
- 20. Agile DevOps Nexus Methodology Soup What next??? There will always be more!
- 21. Requirements Management Agile Planning Test Management ITSM SCM Build Management IT Automation ALM Project & Portfolio Mgmt Change / Workflow Mgmt Issue Tracker Database Support Enterprise Modeling Content Management Build Management Test Automation APM Code Analysis Blueprint IBM Rational DOORS NG IBM Rational DOORS IBM Requisite Pro iRise Jama Serena Dimensions RM CA Agile Central (Rally) CA Agile Planning GitLab Issues IBM Bluemix JIRA LeanKit Mingle Pivotal Tracker ServiceNow Agile Targetprocess VersionOne IBM RTC HPE ALM Octane Microsoft TFS MS VS Team Services (VSO) Polarion IBM RQM HPE QC/ALM Microsoft Test Manager Tricentis Tosca Zephyr for JIRA SmartBear QAComplete CA (Clarity) PPM HPE PPM Microsoft Project Server Planview Enterprise ServiceNow PPM Borland StarTeam CA Harvest IBM Rational ClearQuest Serena Business Manager Bugzilla GitHub Issues BMC Remedy JIRA Service Desk ServiceNow Zendesk Salesforce Service Cloud Sparx EA Oracle MS SQL Server MySQL Git GitHub BitBucket Subversion (SVN) CVS Perforce SonarQube Coverity AppScan Veracode HPE Fortify uBuild Ant Maven Snap Grunt Selenium HP UFT Conformiq Cucumber Chef Puppet Jenkins Hudson Ansible Salt Atlassian Bamboo UrbanCode Deploy (uDeploy) Travis-CI ThoughtWorks Go OpenMake CA Release Automation XebiaLabs DeployIT JetBrains TeamCity Vagrant Windows Powershell New Relic AppDynamics Dynatrace Compuware APM BMC APM CA APM (Wily) IBM APM And more…. Microsoft SharePoint Supports 360+ tool versions Built and tested in our “Integration Factory” • 3300 API tests in spec • 500k API tests per day Security WhiteHat Sentinel
- 24. RequirementRequirement Software Developer Changeset Epic EpicRequirement Story 2 Story 1 Child Req 2 Child Req 1 Story 2 Story 1 Defect Blocks Defect Blocks Quality Assurer Business Analyst Software Developer
- 25. Best Practices for Cross-Functional Collaboration (In a multi-tool environment)
- 26. • What challenges are we facing? • What information do our teams need to share? • What do we hope to achieve? • What and Why before the How 1. Goals First, Process Second
- 27. 2. Establish a Single Source of the Truth • Artifacts as the source of the truth • Artifacts as currency of communication
- 28. Business Analyst Project Manager OPTesterDeveloper Story Epic TestcaseDefectTicket Feature Requirement Testcase Link Folder Request
- 29. 2. Establish a Single Source of the Truth ● Direct comments/discussion/decisions to the artifacts themselves Artifact
- 31. 3. Work Cross-Functionally from Start to Finish Networked Communication Slide from April Underwood Talk ‘Future of work and scaling enterprise products’, Women In Product, 2017
- 32. Feature Team Security Team Testing Team Software development and communication are not linear Architecture Team
- 34. 4. Devise Clear Outcomes and Provide Visibility
- 35. 5. Improvethe process in iterations
- 36. Bonus: Keep Scale in Mind
- 37. Model Based Integration Bonus: Keep Scale in Mind
- 38. Process is about connecting people and ensuring that they are communicating and collaborating effectively. Let it enable, rather than hinder, you!
- 39. Questions?
Hinweis der Redaktion
- Laurel
- Cynthia
- Cynthia
- Victor Process gives us a framework for collaboration Sets clear handoffs and expectations Speed and efficiency over time Visibility
- Victor Process can create silos which hinder collaboration and cross-functional communication Communication is happening in too many places Collaboration breaks down when important information isn’t communicated down the chain Process is unnatural to the way people actually work so process is broken or disregarded
- Victor Melvin Conway, a programmer in the 1960s. Observation from computer systems. But has expanded to management theory. For example, consider a company that builds a mobile app, a web frontend, and a backend infrastructure that serves both. Oftentimes, three different teams each build their separate pieces together, and they are connected together to form a coherent experience. Conway’s law is the observation that the product structure (three separate pieces), reflects the organization structure (three separate teams). This can be extended beyond software to operations and services. So if you have a well functioning and communicating org, what you produce will be coherent. If your BE team is talking to your mobile app team, then the mobile app will successfully talk to the BE infrastructure! If your call center is communicating with the product team that builds the call center tools, your support service to customers will be really good. Conway’s law: the process and communication - the business or business we’re creating is a reflection of how our process and structure is. It’s important to get that right. PRocess is not for process sake but for the sake of shipping a good product at the end of the day. Sometimes orgs aren’t showing that outward - from marketing perspective it’s a polished product but what we’re trying to say is it’s fatalistic to try and get something really nice if you don’t address the root problems and the root problems are the process behind the scenes. For example, at GitLab, we’re in the business of helping people improve their processes so we need good processes. And at Tasktop we’re in the business of helping organizations build better software more effectively, so we need to have good practices in place ourselves.
- Victor Enabling asynchronous work styles Integrating tools and systems for better communication flows Designing processes similar to the way collaboration happens
- Victor Goals GitLab uses OKRs (objectives and key results)
- Timelines
- Victor So much going on, we need SSOT Ground truth Baseline common reality Talking over each other. Using visuals. Scoping the problem Establishing the constraints of the solution space. People go on vacation
- - Measurable - Again scoping Metric, functionality is working, covered edge cases, user acceptance criteria Principle 2 and 3 -> issues Structured information Unstructured information Conversation thread
- Making sure all bases are covered earlier, reduces risk, e.g. security stakeholder Diversity of ideas for beyond basic requirements, better business outcomes At GitLab, transparency and openness make it really easy and natural for cross-functional collaboration. Ideas, code, designs, process. Open sourcing code within an org (“innersourcing”) is becoming very popular, and it is moving beyond just software, but to processes, like we talk about hee. If your org is not there yet, that’s fine. Just try to continue promoting cross-functional collaboration. Use a google doc instead of an word doc. Small tweaks
- Best practice to improve: not to throw out all process and start from scratch but improve from scratch, take advantage of tools that help you pull together disparate tools. Can’t reinvent overnight Some companies try to hire consulting companies, spend millions of dollars implementing new system and processes. That’s important, to a degree, with fresh thinking. Force compliance and culture change. Culture changes organically. We are dealing with people, not robots. Retrospective Expectation: Constant change with changes in organization, especially for startups Look at your own sphere of influence. People manager. Process manager. Individual contributor -> Communication outward
- INTRINSINCALLY SEE WHERE THERE ARE GAPS STRUCTURAL HOLES
- Need a basic recognition that you’ll still encounter the many tools challenge!
- Talk abouyt scale here. The disconnect problems become evenr worse when your software development organiztion is in the hundreds, thousands, or tens of thousands scaling=-important for large organizations with tens of hundreds of developmeers, etc
- We believe that integrat For us, process is also about enabling better communication. Maybe you layer in some development methodoligies to guide other aspects of the work, but at the end of the day, you’ve still got people who need to more easily connect and collaborate. And, we happen to think that the answer is integration. Will look at the best practices for collaboartaion ion is a crucial component of this!
- See this with integration all the time--people set out to do something without talking through what they want to achieve. Is important to figure out what needs to flow. Ointernally, with SF to TP, what info do PMs need to effectively triage and prioritize requests? What visibility do the sales people need?
- For us, single source of the truth is the artifacts themselves! Flow comments and attachments back and forth. Artifacts as currency of communication
- Flow collaboration entities like comments and attachments between artifacts in different systems
- Inherent in integration is the recognition that software delivery is cross-functional. Isn’t linear--needing to adjust to changes, incomings, etc. Evaluating fast-track request feasibility--is a product.engineering collaboartion. TA to understand options/effort, joint decision. Talking to the field to see if there are workarounds
- Request comes in … sits on the backlog for months. But then another request comes in from an important customer – and then you find other somewhat related requests that have come in. You realize you should think of them together – and so you group them, and then create two features to represent the collective behavior. The team determines those collective requests turn into 2 different features. One of which the team starts work on. They break the feature down into multiple epics and stories and low and behold, as one of the stories is being built one of the tests run for compliance fails and you realize at that point that actually the testing team has to make significant changes to how they do compliance testing in this instance. And then, a different story is being worked on and the team realizes it affects parts of the core architecture – so now a new epic for the architecture team needs to be worked on. All the while time is passing. Finally, towards the end of development, a security vulnerability is found – and the security team will have to do some work to deal with that as well.
- Each stage has clearly documented output, be it a description, a linked ta task… and it all lives on the core artifacts Not just info about one artifact, but about linkages between artifacts across entire cycle Status of different/related artifacts
- Can’t integrate entire value stream all at once… map out the value stream out as much as you can, then start with the connections that are most needed/hisghest value