5. Every Project Story
The customer knows nothing
The developer thinks about new technologies
The PM thinks about the deadline
The analyst thinks he knows everything
He got ―everything‖ from the customer,
who knows ―nothing‖ ;-)
6. Every Project Story
The developer: ―I can do it in 3 months‖
The PM: ―You’ll do it in 2 months‖
The project takes 4-5 month
7. Every Project Story
1st Month: Everybody is happy
2nd Month: Customer sees ―something‖
3rd Month: Customer makes tons of changes
The developer screams
The project manager blames …. ???
Last Month: Everybody is at office till 8-10 PM
Every DAY:
The PM: Developer, you’re not done yet? LOSER!!
8. Why does it happen?
Requirements are not fully understood at the beginning of the process.
Requirements change during the process.
The process becomes unpredictable when new tools and technologies are used.
11. Agile Manifesto
Individuals and interactions
Over processes and tools
Working software
Over comprehensive documentation
Customer collaboration
Over contract negotiation
Responding to change
Over following a plan
18. Scrum Roles: Product Owner
Possibly a Product Manager or Project Sponsor
That’s what we call an ―analyst‖
Marketing
Internal Customer
etc.
Not a technical guy, BUT ….
19. Scrum Roles: Scrum Master
Responsible for enacting Scrum values and practices
Manages the sprint meeting
Does the sprint reporting
Typically a Project Manager or Team Leader
20. Scrum Roles: Scrum Team
Cross-functional
QA
Developers
UI Designers
Architect
etc
5-10 members
22. Backlog Refinement Meeting
Most Product Backlog Items (PBIs) initially need refinement because they are too large and
poorly understood. Teams have found it useful to take a little time out of Sprint Execution —
every Sprint — to help prepare the Product Backlog for the next Sprint Planning Meeting.
In the Backlog Refinement Meeting, the team estimates the amount of effort they would
expend to complete items in the Product Backlog and provides other technical information to
help the Product Owner prioritize them.
23. Sprint
A certain period of time with specific deliverables
Lasts for 2-4 weeks – NO MORE NO LESS
24. Sprint
Before Start: Sprint Planning
Starts with Sprint Backlog
Choose highest priority items remaining in product backlog
Ends with Deliverables
New Features Developed / Old Bugs Fixed
Sprint Zero and Sprint One might deliver documents!
Architecture Documents
UI Prototype
After End: Sprint Review
Product Demonstration
Product Owner declares what’s done
(Optional) Measure velocity
Stakeholder feedback
26. Sprint Daily Meetings
Stand up Meetings
15 Minutes Max.
Well, don’t exceed 30 minutes at least
Entire Team + Scrum Master
27. Sprint Review Meeting
After Sprint execution, the team holds a Sprint Review Meeting to demonstrate a
working product increment to the Product Owner and everyone else who is interested.
The meeting should feature a live demonstration, not a report. After the
demonstration, the Product Owner reviews the commitments made at the Sprint
Planning Meeting and declares which items he now considers done.
28. Sprint Retrospective Meeting
Each Sprint ends with a retrospective. At this meeting, the team reflects
on its own process. They inspect their behavior and take action to
adapt
it for future Sprints.
29. Time-Boxes
The Time-Boxes in Scrum are the:
Release Planning Meeting
Sprint
– 2 – 4 weeks
Sprint Planning Meeting
– What and how, each 4 hours for one month sprints
Daily Scrum
– 15 minutes Stand up
Sprint Review
– 4 hours for one month sprints
Sprint Retrospective
3 hours
32. The Product Backlog represents everything necessary to develop
and launch a successful product.
It is a list of all features, functions, technologies, enhancements, and
bug fixes that constitute the changes that will be made to the
product for future releases.
35. Sprint backlog
• At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting
to negotiate which Product Backlog Items they will attempt to convert to working product
during the Sprint.
• The Product Owner is responsible for declaring which items are the most important to the
business. The team is responsible for selecting the amount of work they feel they can
implement without accruing technical debt. The team ―pulls‖ work from the Product Backlog
to the Sprint Backlog.
36. Definition of Done
Designed
Refactored
Coded
Code review
Design review
Unit tested
Functional tested
Unit test harness Integration tested
Regression tested
Performance tested
Security tested
User Acceptance tested
39. Practices
Test early and often
Build and deploy continuously
Acceptance Test Driven Development
Emergent Architectures
Refactor
Test Driven Development
Agile Database Development
Pair Programming
43. TFS enables Visual Studio ALM
Team Foundation Server
Full lifecycle control for mission critical IT
projects
REQUIREMENTS
Define
•
•
Agile planning tools for stakeholder
engagement
Backlog management and capacity planning
Develop
•
•
Developer productivity enhancements
Continuous stakeholder feedback
Operate
•
•
•
Automated build-deploy-test
Detailed Reporting and Metrics
Strong integration with Microsoft on-premises
offerings
WORKING SOFTWARE
47. Plan details and subscriber benefits
Free Plan for up to 5 users Included for eligible MSDN
subscribers:
Unlimited number of projects
Version control
Work item tracking
Agile planning tools
Build (limits apply)
Cloud Load Testing (limits apply)
Additional information at http://tfs.visualstudio.com
48. Team Foundation Service
•
•
•
•
•
•
•
Source code and work items are accessible from any modern web browser
Integrates with Visual Studio and Eclipse, includes command-line client for Xcode / other
developer tools
Create an account in minutes, set up continuous integration in a few easy steps
Data is stored in the cloud, making server configuration a thing of the past
Request and manage stakeholder feedback from anyone with a Live ID/Microsoft account
From C# to Python, from Windows to Android, developers can use a variety of languages and
target a variety of platforms
Use the tools your development teams are familiar with today – Team Foundation Service helps
developers focus on what they do best: building great applications
49. Team Foundation Service capabilities
•
•
•
•
•
•
•
•
•
Store and version control code in any language
Integrates with Visual Studio and Eclipse, includes command-line client for Xcode / other
developer tools
Connectors to sync with Git repositories
Work item and bug tracking
Backlog management and capacity planning - Scrum, Agile, and CMMI project templates
Kanban board and task boards
Request and manage stakeholder feedback from anyone with a Live ID/Microsoft account
Build services will build and run unit tests in the cloud (depends on project type)
Supports deployment of web sites and web / worker roles directly to Azure as part of build
51. Uploading code is simple
Check In
Once your developer tool is
connected to Team
Foundation
Service, uploading code is
easy.
Gated check-in and code
merging are also supported.
Agile v.s Waterfall Requirements specification,Design,Construction (AKA implementation or coding),Integration,Testing and debugging (AKA validation), Installation,Maintenance
Adaptive Software Development “speculate” refers to the paradox of planning – it is more likely to assume that all stakeholders are comparably wrong for certain aspects of the project’s mission, while trying to define it. Collaboration refers to the efforts for balancing the work based on predictable parts of the environment (planning and guiding them) and adapting to the uncertain surrounding mix of changes caused by various factors – technology, requirements, stakeholders, software vendors, etc. The learning cycles, challenging all stakeholders, are based on the short iterations with design, build and testing. During these iterations the knowledge is gathered by making small mistakes based on false assumptions and correcting those mistakes,
Agile FlavorFor small teamsWorked for me
You don’t want the project manager to be the scrum master
Say it: “Sprint is the foundation of Scrum”
Consider Adding a sample screenshot
I will enable a sample excel file for this
Identifying and eliminating team integration barriers and impediments enable organizations to deliver a continuous flow of value with their software investments. Addressing such is not an all or nothing investment. Organizations can identify the value delivery impediments that impact them the most and apply contextual solutions to address. Over time, organizations can explore and adopt broader practices to further optimize value delivery cycle times.
