Coolpointer.007

What is Coolpointer ? Check this : http://dominiksymonowicz.blogspot.co.uk/2015/12/coolpointerintroduction.html

Retrospective is my favourite part of the Scrum and most important one.
Why ? 
In biggest shortcut, retrospective is a event to do  health check of your team and process. It allows you praise people for hard work and  solve  problems about things  that didn't go perfectly well. Anyway , I am sure you know these things already (if not , check  Scrum Guides ) .

This article helps you investigate reasons why people do not enjoy retrospective anymore and how to make changes to make retrospective valuable and enjoyable again.

Nothing to talk about on Retrospective, huh?

https://www.linkedin.com/pulse/nothing-talk-retrospective-huh-marcin-konkel?trk=hp-feed-article-title-like

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. 
    

What I learnt from 007: Evening Session - Large Scale Scrum (LeSS) by Craig Larman

I went to meetup "Large Scale Scrum (LeSS)" by Craig Larman .
Event was organized by Adventure with Agile.

Craig Larman:

"He serves as an organizational design consultant, with a focus on organizational redesign and systems thinking, for flexible, high-value-throughput product organizations. His emphasis is Large-Scale Scrum, and scaling agile principles and practices and lean thinking to very large, multisite, and agile offshore development (often, embedded systems, telecommunications, or investment banking), and coaching executive teams to succeed with larger enterprise-level agile and lean methods adoption."

 source: http://less.works/misc/about.html

It was quite interesting QA session ,when people asked more or less interesting question with very useful answers from Craig Larman. I like also introduction by organizer  who said that "meetups are about Learning and making connection".

What I learnt :

• Many people ask about changing organization to adapt Scrum.
• Craig responded that In order to succeed you need start from flip organization system before start Scrum and Less. He added later that problem with organization is an organization . You need change organization before changing Scrum.
• They was question was How to start with Less ?
• Craig started from bullet point about and then add that It depends on size of team . You should start for up to 50 people with One backlog , one product owner, because in Less always have one backlog and one product owner.
• Some people asking about Tailoring down rules as many frameworks has many many rules.
• Craig said that one reason of the main reasons to create Less was that Tailoring down hardly ever works. Tailoring down fails over and over and over again  , so he used opposite approach which is Tailoring up (scaling up) , because more you learnt from retrospective more rules you apply. This is a reason why core elements known as less rules are on 3 pages only. He learnt in order to start with framework rules should be as small  and descriptive as possible and then scaling up as you get more and more experience . Craig called this as "barely sufficient methodology".
• Less is very simple and as it based on  Shu Ha Ri learning phases (from Aikido):
• First , You follow kata.
• Second , You mastered kata and ask for exception.
• Third you create new katas.
• Scrum team is not a IT team , it is a solution team.
• Less worships customer not code. He said "My mother don't care about microservices , she want to watch  a movie on Netflix. When you focus on architecture ....then you lost a plot".
• Some people asked about skills needed to be a great Scrum master. 
• Scrum Master  must have a social network and political power  to do things and influence changes. 
• Patience
• a lot of humour
• It must follow a 11th rule of system thinking which is "there is not blame".
• I was expected to hear some punchline against SaFe  and this almost didn't happen with one exception when somebody asked about SaFe, then Craig said that he has almost no experience with SaFe so he can not say anything as for him Safe is a just a traditional waterfall with fancy agile vocabulary :)
• Less rule 1 product owner  ... that has 2 main focuses
• product vision
• priorities
• Team focus on clarification and something else that I forgot :(
• Performance based bonus are counter-productive and root of all evil. According to research, it has signification factor in decrease of the  performance. Sadly is very popular in finance based companies and team and scrum master should do reduce harm caused by performance bonus as much as possible .
• If you cannot eliminate , you should move performance bonus from personal to team .
• Performance based bonus is root evil .
• Sprint planning 1 should have timebox of  45 minutes or less.
• On question about How Less work with distributed team Craig said that answer is in 2nd LeSS book, chapter 12 to make multi site teams (he said that answer will take 1,5 hour).
• Continues integration is to integrate continuously . It is not a building tool but It is a behaviour.
• Naming wise, people should replace Continues integration with integrate continuously to avoid confusion with building tools!
• In XP you commit your changes in shortest cycling time which is usually 1 TDD cycle:
• Write 1 test 
• Write small amount of code ,
• Refactoring
• Commit
• (and it should go through rest CI process)
• This should happen every several  minutes.
• If u do slower than 30 minutes then u don't integrate continuously.
• CI system it is run 24/7

It was quite interesting meetup.

Resources:
Less -  http://less.works
Adventures with agile - http://www.adventureswithagile.com

What I learnt from 005: An Introduction to Second Generation Lean Product Development by Don Reinertsen.

I attended to another meetup organized by Adventure with Agile .
It was An Introduction to Second Generation Lean Product Development by Don Reinertsen.

Don is well known person and apparently it doesn't need introduction. Sadly, as usual I didn't have idea who he is due my lack of focus on names.
According to his company website :

"Don is President of Reinertsen & Associates, and the author of three best-selling books on product development. For 30 years he has focused on creating fundamental changes in the way organizations develop products. "  Source: http://reinertsenassociates.com/about/

My first impression from this meetup was that I felt like I went for quantum physics lecture. This meetup was for people who need deep knowledge about product development processes in general and this meetup was an excellent introduction .for second generation of product development processes. It was even more useful for people who  plan to read his famous book and trying to understand "black magic" of product development processes.

Is it means that it was useless for people who just start journey with  agile/lean development ?
No. It turns out to be quite useful .

Why? Don talked in deep details about his 7 ideas ,which are:

•     Understanding your economics
•     manage your queues
•     exploit variability 
•     enable smaller batches
•     Control WIP and start rates
•     Prioritize  based on economics
•     Accelerate feedback

You will notice many things mentioned there can come useful ,when you are developer/scrum master  and trying understand business point of view and it helps you to talk to business  in way that will be see business value of it.

Below ,you can find some loose points  from Meetup (I miss 80% of goodness probably)

• When Don talks about understanding your economics. He focus on cost of delay and explains why Quality analysis is better than intuition.
• It is myth that higher utilization means faster development,where truth is that going above 80-85% is worthless and it will cause more harm and problems than benefits. I agree with this. Some people expect from you near 100% time utilization which is simply unreal and force provide false data to cover real time utilization.
• Use queue size not capacity utilization ,because managing queue is key for economics of product development.
• It was very interesting for me to hear about difference between lean product development in manufacturing and software .It's true as not all measurements in manufacturing product development doesn't have the same impact in software development.
• Quick feedback is crucial as it means cheaper fix, easier to change. That's one of important points , because it ensures that product is build according to expectation and requirements as quicker you spot difference then easier is back to track.
• Control WIP is one of key element of Kanban and it seems Don prefers Kanban approach . My little experience  gives me impression than Kanban works great for support team who focus on fixing bugs or team that are constantly disturb by external request that ignore current plan. 

Sadly, I didn't remember more from his meet up,

Best quote from Don's meetup was when he talk about interview with engineer about how he develops software that was so successful.

Why product was so successful? 

"Engineer answered: because we develop software so fast that marketing didn't have chance to change their mind."

Networking after Meetup turns up to be very useful too as I talk with some awesome people about ...retrospective and how to do it and how to evolve retrospective over time.
I will try to use these knowledge on Retrospective when I will do it next week.

If you looking for useful meetup about Agile. Advanture with Agile (AWA) seems be worth to join in.

What I learnt from 004: LeSS of a Story: An Introduction to Large-Scale Scrum (LeSS) by Bad Vodde

I attended to Meetup organized by Adventures With Agile (AWA).
Introduction to Large scale scum (less) by Bad Vodde

Bad Vodde is apparently a guy who doesn't need introduction ...but I didn't have any clue who is he (because i never pay attention to authors :( ,sorry ). As it turns out , Bas Vodde is a co-Creator of Large Scale Scrum (LeSS).

Well, shame on me.Anyway ...according to Less website:

"Bas Vodde is an experienced coach in agile and lean development (with a focus on Scrum and LeSS). He enjoys debugging organizations and has served on the leadership team of a large telecom product. He has worked for years on the largest LeSS Huge adoption he is aware of – large groups require patience. He also enjoys the actual software development and is an active contributor to Open Source (mostly in C++ and Ruby)"  Source:http://less.works/misc/about.html

It was an interesting story telling (not lecture ,not Talk,it was .. a story telling) about history about roots of Less and its evolution based on experiments. He used unusual way to do his talk as instead of show slides and talk through various aspect of LeSS ,he decided to do story telling with 2 slides and video of fireplace to make atmosphere for real story telling. He explained his approach that "every talk about Framework is boring" and he believes that story telling is more interesting way to do introduction.

What I learnt:

•  Scrum is an Empirical process control. His journey with Scrum on Large Scale based on various experiments that he described in his book (more than 600) .
•  It is very important to do Overall retrospective.
•  According to Bas ,Less can works even with 2500 people but it is a bad idea and we should do it.
• There was problem with Scrum from day 1 because scrum was Designed for 1 group only.
• On LeSS website,you can find case studies about adopting LeSS. However these case studies are written in unique way as they are experience report where they talk about ...experience. I need to check this as I wonder is it more interesting way compare to classic marketing blablabla.
• One product has one backlog .You can read more about it here:  http://less.works/less/framework/product-backlog.html
• Dynamic of software development (feature team and  daily build) .Component teams for example front end and back end team. Problem is when feature. Async due unbalance between front end and Back end . Planning is not a solution.  Split into feature teams from component teams.
• Gaining experience with Scrum is similar to Aikido. In Aikido like in Agile you start as beginners who follow given receipt, in middle you learn when you can break rules on master level you don't need rules, you create your own.
• Don't write book, because it is a pain in the ass. It is not Scrum related, but it seems many speaker who is author of famous book hates ... writing a book. I wonder, if is a requirement to be good speaker to complain about writing book .
• Scrum master is full time job in Less.
• Coordination role is not a role as it takes responsible out of the team.
• Less rules has  3 pages. They are split into 2 pages for small team and additional page for large teams (more than 8). Rules can be found here: http://less.works/less/rules/index.html .   To be effective, though, the set of rules has to be small, and must be clear enough that it can easily be understood and remembered.
• Bas said that they don't want any rules in LeSS, but they must be some basics rules to help people on beginning. Rules in Scrum came from retrospective. It is the same in LeSS. Retrospective is a key element of Scrum/less because it helps you to constantly add , remove and adapt rules to allow team work better and better. This is reason why LeSS gives minimum principles/rules,because additional rules should came from feedback on retrospective.It is easier to have fundamental rules and add on top of them rather than tomes of rules and  tailor them down as you don't know enough on beginning what you don't need. I think ,that is one of the most valuable element of LeSS because different project/team/company has different needs and these needs change due changes in team and projects.
• Meta principle is lean thinking(itself is bigger than agile). It was an interesting point, but I forget what was about it. 
• Large scale scrum is Multiple team scrum  (LeSS in not scrum on team level) . Multiple team scrum (less) vs Scrum of multiple teams. (Other frameworks).  
• Sprint Bazaar is a  .I never heard about it before bit it is interesting idea . More explanation can be found here: http://less.works/less/framework/sprint-review.html
• Spring planning 2 are different LeSS (Multiple team scrum) in comparison to  Scrum of multiple teams.  If you are interesting ,you should read these articles : http://less.works/less/framework/sprint-planning-one.html and http://less.works/less/framework/sprint-planning-two.html
• Spring review is a parallel activity.
• SaFe sucks . I have no idea what safe framework is but it sounds like waterfall with 'agile vocabulary' . It seems most people I met so far really don't like Scaled Agile Framework (SAFe).
• Multi-team plan meeting is good if many teams works on the same feature.
• Clarification is a team responsibility .
• Architecture community rather than architect role. I don't agree with this partly . I prefer to have an architect whose response is to take care of fundamentals of project and focus on high level vision of architecture . There is an amazing book that explain that in details called .
• Less avoid roles assignment. I believe that some role assignment should exist . It helps efficiency of team , specially that some people likes/hate do specific thing.

Resources:

If you are interesting in Less ,then check their website : http://less.works
More about Adventure with Agile can be found here : http://www.adventureswithagile.com