Agile/Scrum notes

WARNING!

This is personal notes for personal and my friends only:

http://dominiksymonowicz.blogspot.co.uk/2014/01/itnotes-information.html

You can read them,but I suggest look to link,resources only

AGILE/SCRUM NOTES

Agile is a Adaptive software development. Think "Agile " as synonym for flexibility

SCRUM:
"Scrum is a framework for developing and sustaining complex products. (...)  Scrum
employs an iterative, incremental approach to optimize predictability and control risk." (The Scrum Guide"™ -  https://www.scrum.org/Scrum-Guide)

BUSINESS VALUE DESCRIPTION:

• It is hard to write  bways to better measure and communicate the value of your code and related work. One way to solve  Think in percentages

DEFINITION OF DONE

One of the most painful thing to define. I think dod should answer these question

• Is it ready to be released?
• Definition of done, is about the quality of the code.
•  Has all of the documentation that the organization requires been updated?
• Does the code have a reasonable level of unit tests?
• the code covered by system level tests?
• Has the code been reviewed by one other programmer?
• For business people: “If we ship this today, can we make,save money ( by reduce waste)?”

DEVELOPMENT TEAM (part of the Scrum Team)

• Group of people who do the work of delivering releasable Increment of “Done” product by the end of each Sprint.
• They are self-organizing.
• Size of team starts from 3 up to 9 (on average 'best practice opinions)..

ESTIMATES:


There are many way to do estimates but I learnt one thing.
Estimates are forecast not commitment!
If business treat them as commitment then there wil

Time based vs point based.

Although ,I liked time-based  estimate tor a bit of time , because they give nice imagination and projection of what's will happen but this create a minefield ..one mistake and KABOOM
However, I discover time-based estimation suffer
It is a very danger tool for company where

It tools
Estimation of bug fixing is a mistake. I never seen this work.In fact , I prefer kanban aproach to bug fix
Problem is how

Truth is that great agile people, if you use this tool

Points are more accurate but less precised
One thing which is missing for me is defition of units we using..
For example when you using points  system like 1 2 3 5 8 ...
What's defition of 1 and How many points are more less description of 1 day of work

To remember:

• Estimates are forecast not commitment!
• Don't estimate bugs .From what I see it causes more problems and disorganize sprint.
• 
  

There should be one gold rule ,that estimate and achieve goals "on time" as part of

• Sprint Planning:
• Define the sprint goal
• For example "Add Bluetooth Test"
• Decide how much to chew off
• Decide which stories to do this sprint
• Create tasks for stories
• Check how much availability do you have during spring
• It can be Bank Holiday
• Holidays
• Company Events
• All information required for story must bed completed and  groomed 
• Decide which stories to do in this sprint
• [TIP] It sometimes makes sense to prioritise a risky story higher to just learn, 
• [TIP] leave some space for unexpected events (bug fixes ,thing can take longer due complexity
• Sprint forecast sounds better than spring commitment

PAIR PROGRAMMING:

Link to article: Pair Programming is Best in Discovery Mode

Today, I found an article about Pair programming.
I can only add ,that I agree with opinion that

Tips:

• 
  
• Product manager tend to jump to the first acceptable solution without trying to consider other, (radically) different and perhaps better alternatives. 

PRODUCT OWNER:

• PO is like an entrepreneur , an innovator , system thinker and mini CEO .  
• PO is not a Business Analyst!
• It is responsible for maximizing the value of the product and the work of the Development Team. 
•  Manage Product Backlog items (CRUD operation and prioritize list
• It must be a one person. (entire organization must respect product owner decisions)
• No one except Product Owner is allowed to tell the Development Tram what to do and when.

SCRUM MASTER

• Person is like process owner who is responsible for ensuring Scrum is implemented correctly and works smoothly.
• Update the team's definition of done (or write one if they don't have one)
• Instead of maintaining an impediment list, remove each impediment the day you hear about it
• 
  

STORIES:

• Should be described using  this formula
• Given ( context ), 
• When ( action ) ,
• Then (expected result) 

Scrum Team

• Product Owner
• the Development Team
• Scrum Master

TIPS AND TRICKS

1. Don't planning for more than 3 months.Don't bother.  from my experience, planning for longer
2. Product must share a common definition of “Done”.
3. Fix crap code immediately because bad code accumulates . If fix is more than "one liner" or  not sure about  it, consult your  technical/practical leads
4. Email is great for communication, but not collaboration. All collaboration should be done by accessible by team tools like Jira, Wiki
5. Meetings must be meaningful. “Is this meeting important to getting your job done?”
6. Don’t Estimate Software Defects
7. Pair programming  (link: http://itsadeliverything.com/pair-programming-is-best-in-discovery-mode
8. A major factor in your choice of Agile framework/methodology depends on the ‘Reaction Time’ your team needs in order to change their currently agreed scope of work.
9. For Scrum, the agreed scope is the Sprint Backlog (1, 2, 3 or 4 weeks long)
10. For Kanban, the agreed scope is staying within your WIP limit threshold(s)
    
11. Scrum is more about spirit rather than practices. I

INTERESTING READS:

• Agile Manifesto
• http://agilemanifesto.org/iso/en/principles.html
• "The Scrum Guide"™
•  https://www.scrum.org/Scrum-Guide
• Must read guide,if you planning to use Scrum.
• Peer feedback( http://java.dzone.com/articles/continuous-improvement-scrum)
• According to Wikipedia "Peer feedback is a practice in language education where feedback is given by one student to another”.
• Nice comics that explain how kanban works:
• http://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000
• http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

QUOTES:

• "A late change in requirements is a competitive advantage" 
• by Mary Poppendieck


• "As humans, we have a hard time acknowledging we don’t have control over everything. Hitting the estimates serves as compensation for not knowing everything. Drilling through the known unknowns, compensates for the unknown ones. "
• http://www.javacodegeeks.com/2015/08/estimates-jumping-to-wrong-conclusions.html

Resources:

1. https://www.linkedin.com/pulse/how-run-sprint-planning-meeting-way-i-like-sandy-mamoli
2. https://www.mitchlacey.com/intro-to-agile/scrum/definition-of-done
3. http://www.mountaingoatsoftware.com/blog/clarifying-the-relationship-between-definition-of-done-and-conditions-of-sa
4. https://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod)
5. http://blogs.atlassian.com/2013/10/8-steps-to-a-definition-of-done-in-jira/
6. http://less.works/events/meet-up-less-of-a-story-an-introduction-to-large-scale-scrum-less-56
7. http://less.works/less/rules/index.html
8. http://scrummethodology.com/scrum-backlog-grooming/.
9. https://www.scrumalliance.org/community/articles/2014/july/dos-and-don-ts-of-agile-retrospectives
10. http://www.okapya.com/jira-agile-definition-of-done-acceptance-criteria
11. http://java.dzone.com/articles/continuous-improvement-scrum
12. http://www.romanpichler.com/blog/product-owner-sprint-retrospective/
13. http://guide.agilealliance.org/guide/gwt.html
14.