Collaboration and Agile - BA World Melbourne 2011


Published on

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Maybe we can just communicate more?But they are not the same. In fact they are totally divergent in the way they convey ideas and thoughtsCommunicationCommunication is the activity of conveying information. Communication requires a sender, a message, and an intended recipient, although the receiver need not be present or aware of the sender's intent to communicate at the time of communication.Co-operationCooperation or co-operation is the process of working or acting together, which can be accomplished by both intentional and non-intentional agents. In its simplest form it involves things working in harmony, side by side.Collaboration Collaboration is working together to achieve a goal.It is a recursive process where two or more people or organisations work together to realise shared goals For example, an intriguing endeavour that is creative in nature—by sharing knowledge, learning and building consensus.
  • Just because we can connect two or more people together and share information does not mean we are collaborating. The difference between communication and collaboration is when new concepts emerge through that exchange in knowledge & creativity.This is not to say the individual is void of their own creativity or ability to think "out of the box" but they are limited to their own insight and understanding. Only through the introduction of new information can they go beyond that. So what are the implications? Well here are 5 and there are several others.1) Just one more person adds tremendous opportunity. 2) The more diverse the individuals the more ideas in the funnel.3) Effective convergent thinking is extremely crucial.4) The "pipe" to connect people really is a "dumb pipe."5) Brainstorming can be enhanced by techniques that merge concepts.
  • There are three basic forms of communication: written, verbal, and visual. A combination of all three yields the best results. However, it's not always practical so it's important to know when you need to have a face-to-face meeting and when it's fine to send details via emailOther methods include:Printing whiteboardsPhotosWikisDesktop sharingVirtual rooms/WebexCockburn contends that the most effective communication is person-to-person, face-to-face, particularly when enhanced by a shared modeling medium such as a plain old whiteboard (POW), flip chart, paper, or index cards. As you move away from this situation, perhaps by removing the shared medium or by no longer being face-to-face you experience a drop in communication effectiveness.Strive to follow the most effective communication technique applicable to your situation.  If you're working together with someone in the same room, it's likely best that you discuss something with them face-to-face at a whiteboard than to write them a document which you eventually hand-off to them.  If you're working with someone at another location, then you'll want to set up regular video conference calls with them, have a shared information repository, and email regularly -- flying them in every so often so you can work face-to-face would be a great idea too. Be prepared to vary your approach throughout a project.  Team dynamics will change throughout a project, so the communication strategy that worked well for you yesterday may not work well today.  The daily conference call which you introduced three months ago to address communication challenges between distributed team members may no longer be needed now that people have built up a rapport and are now using a shared wiki and chat software and are making impromptu calls when needed.  The implication is that you should regularly question the ways that you're communicating, a good option is to do so at the end of each iteration during a process improvement retrospective.
  • Collaboration is not easy and in most cases I would say that bad collaboration is worse than having not collaborated in the first place : I believe that there are two types of roadblocks to good collaboration: Human beings are one and structural roadblocks are the other.
  • People working in silosTools – e.g. SharePoint. Pop Quiz:Qn: How many people have SharePoint in their company. Qn: How many use it to store and share documentsQn: How many have shared calendars that are actually usedQn: How many actively use it to collaborate on document development.Qn: How many have active discussions through discussion boards
  • Politics- Politics is part of everyday life and if people say it is not then they are kidding themselvesPeople will have personal agenda’s sometimes you will need to find out what they are first before you can start or even improve collaborationJob security / fear of the unknownDon't want to or what's in it for me (Knowledge is power)?Like the way that they are working now. E.g, Telstra architects,On many projects, never seeing a whole project to the end“Why would I want to share information, then I am not holding all the cards” I might become less important”E.g. Telstra BA: Currently they are a SME in their area and we are asking them to move into a more generalist roleCustomer: Often doesn’t have time and may initially not see the benefit of having to be involved in the project longer term Distrust or lack of trustThe stakeholder and the team doesn’t have a trusting relationship. This make good collaboration difficult. Trust is hard to earn but easy to lose and needs to built up. Don't know howOn the surface it may seem that they know but do they display the right behaviours for good collaboration: Open mindTrustfulRespectful of their peersWillingness to listen and learnKnowledge is power. Some people get into positions of power due to knowledge they have. If they share this then their position may be in jeopardy. - Lack of time. Collaboration takes time and effort. Deadlines and other priorities get in our way to collaborate.
  • James SurowieckiBook: The Wisdom of Crowds:Based on Surowiecki’s book, Oinas-Kukkonen[2] captures the wisdom of crowds approach with the following eight conjectures: It is possible to describe how people in a group think as a whole. In some cases, groups are remarkably intelligent and are often smarter than the smartest people in them. The three conditions for a group to be intelligent are diversity, independence, and decentralization. The best decisions are a product of disagreement and contest. Too much communication can make the group as a whole less intelligent. Information aggregation functionality is needed. The right information needs to be delivered to the right people in the right place, at the right time, and in the right way. There is no need to chase the expert.
  • Ad-hoc or incidental communication are often very valuable - this often undervalued.
  • Team collaboration requires a culture that values and supports specific interdependencies between people. In other words, we look out for each other and we cant succeed without each other.Do your teams have clarity around the points (listed on the slides)
  • There are a number of things that must happen in order for your team to start and continue to collaborate Common purpose or goal Complex problems that a single person could not resolve on their own An outcome that is valued Pressure to deliver (a due date) An explicit process for getting things done Clearly defined roles Knowledge of each other’s work, communication and learning styles An admiration of the skills and abilities of fellow team mates Enough resources to do the job but not so many that the team loses its resourcefulness Regular social activities to build trust among team members
  • Ground rules - Use sticky notes so everyone can contribute - They must be agreed by all - They should be reviewed regularly to make sure that they are being followedTeam Culture and behaviours - Whenever a group of people are bought together you will potentially have culture clashes and everyone will have different behaviours - Suggest that you spend some time just observing people and seeing how they act and react to one another. - This will provide you with pointers of how to work within the team and any destructive behaviours that may need to be dealt with
  • Non Musical Chairs - Origami - backlog is in the eye of the beholder - Challenge -
  • You should not become the conduit of information and knowledge into the team. Facilitate interactions between the developers and the product owner Bring Dev’s and architects into client discussions Don’t be afraid to step back but stay within the conversation so you still have an overall view of the solution
  • Collaboration and Agile - BA World Melbourne 2011

    1. 1. We’re Agile Now: So Collaborate or Else!<br />Collaboration and how to do it well in an agile project<br />Jacky Jacob<br />Supervising Consultant and Agile Coach<br />Object Consulting<br />
    2. 2. Today<br />Communication vs Collaboration<br />What collaboration means in an agile team<br />Roadblocks<br />Team collaboration<br /> Slide 2 of 30<br />
    3. 3. “When the revolution comes, machines will talk to machines and people's vocal cords will atrophy"<br />Mystery, Jonathan Kellerman<br /> Slide 3 of 30<br />
    4. 4. Early Collaboration<br /> Slide 4 of 30<br />
    5. 5. Being a collaborator<br />You can go from this<br />To this<br /> Slide 5 of 30<br />
    6. 6. Who does a BA need to collaborate with?<br />Elicit Requirements<br />Analysis and <br />documentation<br />Product Owner<br />Stakeholders<br />Product Owner<br />Dev’s, Testers<br />Architects<br />Scrum Master<br />Project Manager<br />Help to identify<br />the solution<br />Dev’s, Testers, Architects<br />Verify solution against requirements<br />Communicate to team<br />The requirements<br />Dev’s, Testers<br />Product Owner<br />Dev’s, Testers<br />Scrum Master<br /> Slide 6 of 30<br />
    7. 7. The 3 C’s in any agile project<br />Communication <br />conveying information<br />Cooperation<br />working in harmony, side by side<br />Collaboration<br />working together to achieve a goal<br /> Slide 7 of 30<br />
    8. 8. Communication vs Collaboration<br /> Slide 8 of 30<br />
    9. 9. Collaboration<br /><br /> Slide 9 of 30<br />
    10. 10. Collaboration = Trust + Transparency<br />10<br />
    11. 11. Roadblocks to collaboration<br /> Slide 11 of 30<br />11<br />
    12. 12. 12<br />Roadblocks<br />
    13. 13. Roadblocks<br /> Slide 13 of 30<br />
    14. 14. Don't want to or what's in it for me?<br />Distrust or lack of trust<br />Don’t want to share knowledge<br />Don't know how<br />Personalities<br />Lack of time<br /> Slide 14 of 30<br />14<br />Human Roadblocks<br />
    15. 15. Agile Manifesto<br />Individuals and interactions over processes and tools<br />Working software over comprehensive documentation<br />Responding to change over following a plan<br />Customer collaboration over contract negotiation<br />That is, while there is value in the items onthe right, we value the items on the left more<br /> Slide 15 of 30<br />
    16. 16. Key Agile Principles for Collaboration<br />Changing requirements<br />Face-to-face conversation<br />Team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly<br />Best architectures, requirements, and designs emerge from self-organizing teams<br />Work together daily<br />Build projects around motivated individuals<br />Extract from:<br /> Slide 16 of 30<br />
    17. 17. 17<br />Wisdom of the crowdMany Are Smarter Than the Few <br /><ul><li>Diversity of opinion
    18. 18. Each person should have private information even if it's just an eccentric interpretation of the known facts.
    19. 19. Independence
    20. 20. People's opinions aren't determined by the opinions of those around them.
    21. 21. Decentralisation
    22. 22. People are able to specialise and draw on local knowledge.
    23. 23. Aggregation
    24. 24. Some mechanism exists for turning private judgments into a collective decision.</li></li></ul><li>18<br />Collaboration and Agile Analysis<br /><ul><li>“Agile analysis is highly evolutionary and collaborative process where developers and project stakeholders actively work together on a just-in-time (JIT) basis to understand the domain, to identify what needs to be built, to estimate that functionality, to prioritise the functionality, and in the process optionally producing artifacts that are just barely good enough.”
    25. 25. Scott Ambler</li></ul>18<br />
    26. 26. Phases in an Agile Project<br />19<br />Waterfall<br />Definition<br />Build<br />Test<br />Design<br />Agile<br />Initiate<br />Evolve<br />Discover<br />
    27. 27. Opportunities to Collaborate<br />24 hrs<br />Iteration<br />Prioritised Feature List<br />Vision<br />Retrospective<br />Daily Cycle<br /> IterationPlanning<br />ProductIncrement<br />Demonstrate<br />Releasable<br />Product<br />Selected<br />Features<br />20<br />20<br />
    28. 28. Collaboration using Scrum <br />Additional meetings / workshops<br />Product backlog grooming sessions<br />Product owner, tester, developer meetings<br />Tech huddles<br />Ad-hoc discussions<br /> Slide 21 of 30<br />
    29. 29. Agile Collaboration<br />Co-Location<br />Video Conferencing<br />Walls (and lots of them) / Sticky Notes<br />Big Visible Charts (BVC)<br />Be transparent to all<br />22<br />
    30. 30. 23<br />
    31. 31. 24<br />
    32. 32. 25<br />
    33. 33. 26<br />
    34. 34. 27<br />
    35. 35. 28<br />
    36. 36. Team Collaboration<br />Priorities<br />Team success over or in alignment with individual performance<br />Targets<br />Delivering quality outcomes <br />Learning<br />Learning from within and across teams:<br />Honest, constructive feedback<br />Knowledge sharing, not hoarding<br />Explicit team processes<br />Communications<br />Working and workflow<br />All roles are clarified within the team<br />Decision making (self empowered team)<br /> Slide 29 of 30<br />
    37. 37. 30<br />Encouragement and positive feedback<br />
    38. 38. Getting collaboration to work<br />Skill<br />Respect<br /> Slide 31 of 30<br />
    39. 39. What's needed for effective collaboration<br />Everybody needs to understand;<br />WHY should we work together<br />WHAT should we do together<br />WHO should do what<br />HOW should we work together<br />32<br /><br />
    40. 40. Create a Social Contract <br />Team Culture and behaviours<br />Team Agreements <br />33<br />
    41. 41. Teaching Collaboration<br />Change it up a bit and teach <br />collaboration through game playing<br />Lego Game<br />Teaches collaboration and teamwork<br />Non musical Chairs<br />Enforce the importance of self organization, communication, simplicity and trust<br />Collaborative Origami<br />Shows that collaboration leads to faster results and better quality<br />The backlog is in the eye of the beholder<br />Demonstrates the importance of identifying and leveraging different views to better manage a  product backlog<br />Marshmallow Challenge<br />Encourages teams to experience simple but profound lessons in collaboration, innovation and creativity<br />Offing the off-site Customer<br /><br /><br /> Slide 34 of 30<br />
    42. 42. You can promote collaboration<br />Stay positive<br />Ask questions<br />Encourage information sharing / don’t become the bottleneck<br />Drive to consensus<br />Make everything highly visible<br />Take away the blame<br />Respect people's views and opinions (even if you don’t agree with them!).<br /> Slide 35 of 30<br />
    43. 43. Additional Information<br />Team Work Video<br /><br />Teleconference Video<br /><br />Game played – Collaborative Origami<br /><br />Website for agile games<br /><br />Or (Type “agile games” into your search engine)<br />36<br />
    44. 44. Thank You<br /> Slide 37 of 30<br />
    45. 45. References<br /><br /><br /><br /><br /><br /><br /><br /><br />Jean Tabaka, Collaboration Explained, Addison Wesley 2009, <br />Luke Hohmann, Innovation Games, Addison Wesley 2010<br />John P. Kotter, Leading Change, Harvard Business Review Press 1996<br />Kent Beck, Extreme Programming Explained, Addison Wesley 2010<br />M Sliger and S Broderick, The Software Project Managers Bridge to Agility, Addison Wesley 2008<br />Lyssa Adkins, Coaching Agile Teams, Addison Wesley 2010<br />Ken Whitaker, Princiiples of Softare Development Leadership, Cengage Learning 2010<br /><br /> Slide 38 of 30<br />