CollabNet was founded in 1999 with the goal of creating a better way to build software. At that time Brian Behlendorf’s strategy (our founder) was focused on “how to connect talented developers regardless of where everyone was physically located”. In today’s terminology, CollabNet wanted to enable “geographically distributed development teams” and provide them a way to all work as ONE TEAM. Finding that CVS, one of the most popular version control systems available at the time, had various issues, CollabNet decided to commission development of a brand new version control system called Subversion. In 2000, CollabNet founded the Subversion open source project and recruited its first developers. Since then, we have continued to sponsor and foster the Subversion project. This includes: hosting the physical project servers in our data center, guaranteeing uptime, providing technical support, and working with the press and analyst community to increase exposure and drive adoption. Perhaps most importantly, we maintain a team of full-time Subversion committers who are dedicated to contributing code and driving a product roadmap. As most of you know, we recently announced version 1.7 that finally addressed Merge Tracking, this was a big request from the community. For companies who have now standardized on Subversion and are then looking to have Technical Support (like having insurance for SVN – someone to call if there is major issue) we offer 3 levels of Support which you can find on our website. We also provide migrations services and web based training. From our openCollabNet site you can download our CollabNet Subversion that EXTENDS SVN giving you additional functionality like Certified binaries and IDE support. Along with our dedication to Subversion we also provide the CollabNet TeamForge platform which will cover shortly.
01/16/13
01/16/13
You are working with known technology Requirements are complete and unchanging The process is highly repeatable 01/16/13
A team of 100 is really no team at all. It’s a collection of 100 individuals.
In software being agile means different things to different people, but usually we all share a few basic characteristics. For inspiration lets check out our manifesto 01/16/13
A team of 100 is really no team at all. It’s a collection of 100 individuals.
If you have incompetent people, terrible managers, an awful product and no customers, Scrum will not fix that. Then again, neither will any other method. Scrum will make these things visible so the organization can work on those problems. Scrum assumes that teams are made of technically competent professionals who know how to make decisions within their sphere of expertise. Scrum will provide a simple framework to help successful systems, efforts, and people shine, while revealing things (and people) that aren’t working towards success. (This can be very painful when there are PEOPLE who are contributing to failure and it becomes visible…)
Detailed up-front planning and defined processes are replaced by adaptive inspect and adapt cycles. Pay attention Validate (Inspect/test) all artifacts Adapt to the realities you see Team is self-managing and organizes itself around goals given constraints. Team self-organization is the key difference between Scrum and other brands of agile.
Product Owner Defines the features of the product, decides on release date and content Is responsible for the profitability of the product (ROI) Constantly prioritizes the Product Backlog Can change features and priority every sprint Accepts or rejects work results ScrumMaster Helps resolve team and organizational based impediments Ensures that the team is fully functional and productive Enables close cooperation across all roles and functions and removes barriers Shields the team from external interferences Ensures that the process is followed. Invites to daily Scrum, iteration, review and planning meetings Team (Development Team and Available Customers) Cross-functional, 7 ± 2 members Negotiates the iteration goal and specifies tasks Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal Organizes itself and its work Demos work results to the Product Owner and other Stakeholders 01/16/13
Daily Stand-up (Daily Scrum) The team understands its status every day in order to do a daily “inspect and adapt” cycle. Ask three questions (what did you do today, what did you do yesterday, what’s impeding you to get done what it is you need to get done. Sprint Planning The Product Owner and team agree on the subset of the Product Backlog to work on this sprint. This subset is the Sprint Backlog. Sprint Review The Team shows their Product to their Product Owner and other Stakeholders. The purpose is to “show off” and get buyoff and feedback. Sprint Retrospective The team (or Scrum Team) analyzes its own process and modifies it as necessary Backlog Grooming Comb through the backlog and work on the building of stories, Def. Of Done of stories, etc etc
Lets study the basics and some metrics and advanced topics too… 01/16/13