Agile – my point of
view
Yogesh S. Shinde (Agile Consultant / Scrum Master)
Disclaimer

All contain appearing in this presentation are NOT
from fictitious or novel. All characters are REAL.
Any rese...
Introduction
 Agile – My point of view
 How will I get benefited from it.
 A Sprint is Not a Mini Waterfall
What is Project Success Criteria
?
Project Success Criteria
Features & Function Usage
What is trust ?
Trust
Agile - Trust
 Agile lives and dies on trust.
 Trust is a commodity in short supply in many of our

work places.
 Why d...
Agile Cultures
 Our mantra is that we deliver "business

value," not just "software," quicker, better, and
faster
 Short...
Agile
Feature Driven
Development (FDD)

Extreme Programming
(XP)

Scrum

Crystal
Clear

Kanban
Agile
Modeling
Manifesto
 Individuals and interactions over processes

and tools
 Working software over comprehensive
documentation
 C...
How Agile benefits to me

Development
Team
 Agile approaches, put great store in collaboration,
communication and knowled...
How Agile benefits to me … continue
 Removing the bureaucracy (Decentralization said by
Gandhiji)

 Only 3 roles
 Produ...
Customer
With the transparency afforded by agile development projects,
customers have witnessed stronger results and have ...
Traceability Metrics
“The use of tracking and tracing systems and processes to match the incoming product
requirements to ...
How Agile Better over
Waterfall at Traceability
The best way to put this is that where
waterfall is a translation process,...
Translation:

Requirements are never completely
understood
Refinement:
Agile Dashboard (Rally / Jira /
Strorm)
 Note that as we go, traceability doesn't need to be

maintained as a separate ac...
Is Sprint just like Mini Waterfall...
???
1. Continuous design, development,
integration, and testing
Cross-functional team members
No change in scope during Sprint
. Time boxing
A strictly defined cadence
Agile   my point of view
Agile   my point of view
Agile   my point of view
Upcoming SlideShare
Loading in …5
×

Agile my point of view

467 views
303 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
467
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • When I introduce friends to agile software development, the concept which stops them dead in their tracks is not "value points," "test driven development," or even "continuous delivery."  The seriously challenging concept is...trust.Agile lives and dies on trust, but trust is a commodity in short supply in many of our work places.  Why do we value contracts over collaboration?  Because we want to know who to blame when (not if) the project goes south, that's why, and we want to be able to sue them, fire them, or at least hold them up for public humiliation.So how do you turn on the trust spigot, the wellspring for all actual returns on your agile investment dollar?  I will confide a little known secret to you.  People do not owe you their trust.  That thing where you allow your lower lip to quiver when people don't immediately jump to support your far-fetched organizational transformation idea?  Or the thing where you wave your resume annoyingly in the face of the new people you've just met, and demand a desk by the window, and turn down meeting requests without even explaining why?  Give it up.  Trust is something which gets built up over time, and it is something you earn.Here's how:Keep your promises, large and small.  If you tell someone you'll send them an email, send them the email.  If you agree to set up a meeting, set up a meeting.  If you goofily agreed to take minutes on the world's most boring meeting, and you promised to send your notes out to all the attendees after the meeting, send them out after the meeting.  The way to earn trust is to make tens, or hundreds, or thousands, or a lifetime's worth of handshake deals, and to treat each one, however small, with the respect you'd give a contract signed in blood.  Once you become too important to show up to meetings on time or keep your small promises, you're not a trusted partner.  You're a wildcard to be exploited, at best, and a depressing, largeish obstacle to work around, at worst. Be careful about what you promise.  Here's a corollary and a tip.  To avoid collapsing under the load of your small promises, think about what to promise before you do it.  Give clear signals when you can't make a promise, and explain why you can't, if that's not clear.  In a world where your word is your bond, you need to be sparing with your word. Give the other guy the benefit of the doubt the first time.  Game theory suggests that if you're in doubt about the motivations of a person you're working with, you should go ahead and extend your own trust to them in your first interaction.  Unless you are in actual danger in the worst case scenario (for example, if you're rock climbing, and the new person you're with says you should let them secure the rope), it's a good idea to trust in your first interaction.  The other person will appreciate getting the benefit of the doubt, and you will potentially make a new friend. If that didn't work, you know better next time.  That addage "fooled me once, shame on you; fooled me twice, shame on me," is actually a helpful guideline for successful corporate living.  There is no need to trumpet to the world that you've encountered a non-trustworthy person, but now you know. There is no tool, platform, or method in the world that can help you manufacture trust.  Trust must be built one interaction at a time, and you need to allow time for the trust patterns in your environment to make themselves apparent.  But once you reap the harvest sown in time, attention, and effort, you've done the hardest thing of all on behalf of your agile revolution.
  • Agile my point of view

    1. 1. Agile – my point of view
    2. 2. Yogesh S. Shinde (Agile Consultant / Scrum Master)
    3. 3. Disclaimer All contain appearing in this presentation are NOT from fictitious or novel. All characters are REAL. Any resemblance to real persons, living or dead, is NOT considered as purely coincidental. There is NO parental guidance required. 
    4. 4. Introduction  Agile – My point of view  How will I get benefited from it.  A Sprint is Not a Mini Waterfall
    5. 5. What is Project Success Criteria ?
    6. 6. Project Success Criteria
    7. 7. Features & Function Usage
    8. 8. What is trust ?
    9. 9. Trust
    10. 10. Agile - Trust  Agile lives and dies on trust.  Trust is a commodity in short supply in many of our work places.  Why do we value contracts over collaboration?  Because we want to know who to blame when the project goes out of the track.  Trust is something which gets built up over time, and it is something you earn.
    11. 11. Agile Cultures  Our mantra is that we deliver "business value," not just "software," quicker, better, and faster  Short development cycles of two to four weeks and are     usually called “Iterations”. Almost daily communication through short meetings, called standup meetings. Over15 minutes, it’s too long. Development progress that is measured through what’s called “Burndown” and the product backlog. Everyone has a voice in “what the product is”. A process that is adapted to the team. Team own the process so they get to use elements that work for them.
    12. 12. Agile Feature Driven Development (FDD) Extreme Programming (XP) Scrum Crystal Clear Kanban Agile Modeling
    13. 13. 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 Note: “good vs. bad or right vs wrong)  It’s a list of priorities. In other words, none of the concepts on the list should be removed from your development lifecycle – they are all important… just not equally important  Value this over that (not
    14. 14. How Agile benefits to me Development Team  Agile approaches, put great store in collaboration, communication and knowledge sharing. So every day you can learn a little more from the experience of others, as well as your own. At the end of every sprint there is an opportunity for reflection and review.  While being exposed to version control, bug tracking, and continuous integration systems is great for a resume, working with other human beings is much more rewarding and fun. You develop strong relationships and you are able to learn so much from other people's experiences and perspectives.
    15. 15. How Agile benefits to me … continue  Removing the bureaucracy (Decentralization said by Gandhiji)  Only 3 roles  Product owner (Customer)  Developers (Main asset of any scrum)  Scrum Master (Non Technical)  Less Documentation*
    16. 16. Customer With the transparency afforded by agile development projects, customers have witnessed stronger results and have benefited from being provided with real-time updates on the status of set requirements. Both agile and scrum are more effective during times of lower spending because they allow for product adjustments or updates to be made quickly. Agile enables companies to fix flaws in new products or soon-to-berelease items before they can negatively impact their bottom line or budget. limits the possibility of waste.
    17. 17. Traceability Metrics “The use of tracking and tracing systems and processes to match the incoming product requirements to outgoing product attributes.“ Positively: 1. "Forward" traceability: 2. "Backward" traceability: 3. Keeping things tidy when requirements change (both during the project and during ongoing maintenance afterwards) Negatively: So you can know who to blame
    18. 18. How Agile Better over Waterfall at Traceability The best way to put this is that where waterfall is a translation process, agile is a refinement process.
    19. 19. Translation: Requirements are never completely understood
    20. 20. Refinement:
    21. 21. Agile Dashboard (Rally / Jira / Strorm)  Note that as we go, traceability doesn't need to be maintained as a separate activity, because each system feature is being built out from general description into detailed implementation, and okayed as "complete" when it meets pre-agreed acceptance criteria, and the customer herself nodding in agreement.  Agile is like that. You don't need to expend effort in agile developing a traceability matrix, because the agile requirements repository IS a traceability matrix at its core.
    22. 22. Is Sprint just like Mini Waterfall... ???
    23. 23. 1. Continuous design, development, integration, and testing
    24. 24. Cross-functional team members
    25. 25. No change in scope during Sprint
    26. 26. . Time boxing
    27. 27. A strictly defined cadence

    ×