What Makes A Great Dev Team - Mike Robinson
Upcoming SlideShare
Loading in...5
×
 

What Makes A Great Dev Team - Mike Robinson

on

  • 1,814 views

What Makes A Great Dev Team - Mike Robinson

What Makes A Great Dev Team - Mike Robinson

Statistics

Views

Total Views
1,814
Views on SlideShare
1,746
Embed Views
68

Actions

Likes
0
Downloads
14
Comments
0

1 Embed 68

http://plone.org 68

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    What Makes A Great Dev Team - Mike Robinson What Makes A Great Dev Team - Mike Robinson Presentation Transcript

    • What makes a great Development Team? What are the challenges faced by development teams and how do they meet them. Mike Robinson
    • Who are you?
    • Who are we?
    •  
    • 1 - What is the problem? 2 - How do we solve the problem?
    • 1 - What is the problem?
    • From the customer’s point of view
    • From the development team’s point of view
    • 2 - How do we solve the problem?
    • Process
    • Technology
    • Tools
    • People Tools Process Technology Successful Projects
    • People
    • 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
    • Regardless of scale or complexity, all Software Development projects should be based on a set of core values and practices
    • Values
    • C h a n g e
    • Simplicity
    • Quality
    • Commitment
    • v i sibility
    • C o l l a b o r a t i o n
    • Value Focus on
    • Quality
      • Simplicity
      • It is not about doing more for less, it is about doing less for less.
      • Simplicity of requirements
      • Simplicity in design
      • Simplicity in Development
      • Simplicity in method
      • Change
      • On most projects change is inevitable.
      • Must expect change
      • First, avoid the need for change
      • Second, deal with it
      • Visibility
      • There can sometimes be a tendency to hide the progress from the business particularly when everything is not going to plan.
      • Build a close working relationship between the development and business teams
      • Reporting based on actual implemented requirements and business value delivered
      • Collaboration & Feedback
      • All requirements are rarely understood at the beginning of a project and those which are can be hard to communicate.
      • A strong emphasis on collaboration between the users, stakeholders, and the development team
      • Put in place short feedback cycles
      • Quality
      • 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.
      • Quality testing
      • Quality requirements
      • Quality in the outcomes not just the outputs
      Values should play to the strengths of the organisation and individuals within it, Deloitte has identified its Application Delivery core values as …
      • Focus on Business Value
      • The goal of any technology project must be to deliver value to the business.
      • Optimise the whole
      • Think outside of the project
      • Deliver value quickly
      • Close collaboration with the business
      • Eliminate Waste
      Values
    • Core Practices Define
      • Define
      • Record requirements in a consistent way that can be understood and measured by the business and development team
      • Record Requirements in a hierarchical way
      • Use consistent language
      • Use of models
      • User centric design
      • Plan
      • Deliver iteratively
      • Prioritise requirements based on business value, effort, risk removed, and knowledge gained
      • Use deferent levels of planning
      • Design
      • Artifacts reuse
      • Patterns
      • Use of models
      • Let the design evolve
      • Develop
      • Refactoring
      • Continuous Integration
      • Test first development
      • Coding standards
      • User involvement
      • Validate
      • Deliver iteratively
      • Automate testing
      • Test first development
      • Code reviews
      • Continuous Integration
      • Collaborate & Manage
      • Use the simplest process
      • Embrace and manage change appropriately
      • Manage risk
      • Measure progress based on business value delivered
      • Synchronise teams
      • Trust people to get their job done
      • Collaborate within and across teams
      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 …
    • Process
    • “ You improvise. You adapt. You overcome.” Clint Eastwood In Heartbreak Ridge
    • How do we select the right approach to use on a project?
      • 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.
      • By following these steps an initial approach for a project can be found:
      Evaluate Add additional Controls Select Approach Review & Adapt
    • 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.
    • 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.
    • Select Approach Evaluate Add additional Controls Select Approach Review & Adapt Notes Select the simplest method which will achieve the project. Light in this case.
    • Add Additional Controls Notes Identify the areas where additional controls are required. Evaluate Add additional Controls Select Approach Review & Adapt
    • 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
    • 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
    • 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
    • Conclusion
      • No one method fits all projects, all of the time
      • Start with people
      • Get you principles right and the process will sort itself
      • Selecting the right method is as much an art and as it is a science
      • Review and adapt
    • “ If you want a guarantee, buy a toaster.” Clint Eastwood In The Rookie
    • Contact Details Mike Robinson [email_address]