What Makes A Great Dev Team - Mike Robinson


Published on

What Makes A Great Dev Team - Mike Robinson

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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

What Makes A Great Dev Team - Mike Robinson

  1. 1. What makes a great Development Team? What are the challenges faced by development teams and how do they meet them. Mike Robinson
  2. 2. Who are you?
  3. 3. Who are we?
  4. 5. 1 - What is the problem? 2 - How do we solve the problem?
  5. 6. 1 - What is the problem?
  6. 7. From the customer’s point of view
  7. 8. From the development team’s point of view
  8. 9. 2 - How do we solve the problem?
  9. 10. Process
  10. 11. Technology
  11. 12. Tools
  12. 13. People Tools Process Technology Successful Projects
  13. 14. People
  14. 15. Different methods are usually viewed as being more or less lightweight, in practice methods contain some elements that are appropriate for different scales of Software Development RUP Scrum RAD FDD DSDM Waterfall XP Crystal
  15. 16. Regardless of scale or complexity, all Software Development projects should be based on a set of core values and practices
  16. 17. Values
  17. 18. C h a n g e
  18. 19. Simplicity
  19. 20. Quality
  20. 21. Commitment
  21. 22. v i sibility
  22. 23. C o l l a b o r a t i o n
  23. 24. Value Focus on
  24. 25. Quality <ul><li>Simplicity </li></ul><ul><li>It is not about doing more for less, it is about doing less for less. </li></ul><ul><li>Simplicity of requirements </li></ul><ul><li>Simplicity in design </li></ul><ul><li>Simplicity in Development </li></ul><ul><li>Simplicity in method </li></ul><ul><li>Change </li></ul><ul><li>On most projects change is inevitable. </li></ul><ul><li>Must expect change </li></ul><ul><li>First, avoid the need for change </li></ul><ul><li>Second, deal with it </li></ul><ul><li>Visibility </li></ul><ul><li>There can sometimes be a tendency to hide the progress from the business particularly when everything is not going to plan. </li></ul><ul><li>Build a close working relationship between the development and business teams </li></ul><ul><li>Reporting based on actual implemented requirements and business value delivered </li></ul><ul><li>Collaboration & Feedback </li></ul><ul><li>All requirements are rarely understood at the beginning of a project and those which are can be hard to communicate. </li></ul><ul><li>A strong emphasis on collaboration between the users, stakeholders, and the development team </li></ul><ul><li>Put in place short feedback cycles </li></ul><ul><li>Quality </li></ul><ul><li>Quality is not the tinsel sprinkled on the Christmas tree it is the seed from which the tree grows. Quality must exist from the start and evolve with the project. </li></ul><ul><li>Quality testing </li></ul><ul><li>Quality requirements </li></ul><ul><li>Quality in the outcomes not just the outputs </li></ul>Values should play to the strengths of the organisation and individuals within it, Deloitte has identified its Application Delivery core values as … <ul><li>Focus on Business Value </li></ul><ul><li>The goal of any technology project must be to deliver value to the business. </li></ul><ul><li>Optimise the whole </li></ul><ul><li>Think outside of the project </li></ul><ul><li>Deliver value quickly </li></ul><ul><li>Close collaboration with the business </li></ul><ul><li>Eliminate Waste </li></ul>Values
  25. 26. Core Practices Define <ul><li>Define </li></ul><ul><li>Record requirements in a consistent way that can be understood and measured by the business and development team </li></ul><ul><li>Record Requirements in a hierarchical way </li></ul><ul><li>Use consistent language </li></ul><ul><li>Use of models </li></ul><ul><li>User centric design </li></ul><ul><li>Plan </li></ul><ul><li>Deliver iteratively </li></ul><ul><li>Prioritise requirements based on business value, effort, risk removed, and knowledge gained </li></ul><ul><li>Use deferent levels of planning </li></ul><ul><li>Design </li></ul><ul><li>Artifacts reuse </li></ul><ul><li>Patterns </li></ul><ul><li>Use of models </li></ul><ul><li>Let the design evolve </li></ul><ul><li>Develop </li></ul><ul><li>Refactoring </li></ul><ul><li>Continuous Integration </li></ul><ul><li>Test first development </li></ul><ul><li>Coding standards </li></ul><ul><li>User involvement </li></ul><ul><li>Validate </li></ul><ul><li>Deliver iteratively </li></ul><ul><li>Automate testing </li></ul><ul><li>Test first development </li></ul><ul><li>Code reviews </li></ul><ul><li>Continuous Integration </li></ul><ul><li>Collaborate & Manage </li></ul><ul><li>Use the simplest process </li></ul><ul><li>Embrace and manage change appropriately </li></ul><ul><li>Manage risk </li></ul><ul><li>Measure progress based on business value delivered </li></ul><ul><li>Synchronise teams </li></ul><ul><li>Trust people to get their job done </li></ul><ul><li>Collaborate within and across teams </li></ul>Wrapped around the core values are a set of core practices which support the values. Like values, core practices will vary from organisation to organisation but we have identified our practices as …
  26. 27. Process
  27. 28. “ You improvise. You adapt. You overcome.” Clint Eastwood In Heartbreak Ridge
  28. 29. How do we select the right approach to use on a project? <ul><li>No one method fits all projects. We must evaluated projects based on criteria such as the size, culture, risk, and potential for change; before selecting a suitable approach and then the process must be adapted and improved over time to better fit the environment in which it sits. </li></ul><ul><li>By following these steps an initial approach for a project can be found: </li></ul>Evaluate Add additional Controls Select Approach Review & Adapt
  29. 30. Evaluate the project Evaluate Add additional Controls Select Approach Review & Adapt Notes Evaluate the project based on the criteria that have been selected for the organisation.
  30. 31. Evaluate the project Evaluate Add additional Controls Select Approach Review & Adapt Notes Score the project on each criteria based on a range and metrics selected by the organisation.
  31. 32. Select Approach Evaluate Add additional Controls Select Approach Review & Adapt Notes Select the simplest method which will achieve the project. Light in this case.
  32. 33. Add Additional Controls Notes Identify the areas where additional controls are required. Evaluate Add additional Controls Select Approach Review & Adapt
  33. 34. Size - Personnel 2-12 12-50 50+ Daily meetings Multi skilled team Deliver small and fast Team of teams meeting More up front planning Split work around architecture Continuously Integrate at multiple levels Hierarchical requirements Collaboration tools Start small then scale Confirm architecture first
  34. 35. Review and Adapt Notes As part of the same feedback loops put in place for reviewing the system, the process should also be review to see where it could be simplified or improved. Evaluate Add additional Controls Select Approach Review & Adapt
  35. 36. Lifecycle for Light Product Owner Project Manager Team Stakeholders Users Preparation Produce Business Case & Vision Requirements Analysis Produce Initial Project Backlog & Release Plan Iteration Planning Update Project Backlog & Agree Iteration Backlog Design Review Working Software Project wrap up Project Review & Training & Support Iterative Phase 2-4 Weeks Phases Build Deploy Test Daily 15min Meeting Roles Project & Iteration Backlog Impediments List Project, Release & Iteration burn down Working Software Artifacts Review Process
  36. 37. Conclusion <ul><li>No one method fits all projects, all of the time </li></ul><ul><li>Start with people </li></ul><ul><li>Get you principles right and the process will sort itself </li></ul><ul><li>Selecting the right method is as much an art and as it is a science </li></ul><ul><li>Review and adapt </li></ul>
  37. 38. “ If you want a guarantee, buy a toaster.” Clint Eastwood In The Rookie
  38. 39. Contact Details Mike Robinson [email_address]