Resources:

Scrum and XP in the trenches

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

 

Notes:

'How are you going to test that?'

'Test to reproduce bugs first'

'If it is hard you're doing it wrong'

 

Moving a team (10 or 11) to move to scrum/xp

    - forced team to switch to scrum/xp

        - this caused 100% turn over on the team.

           - details and clarification - The entire dev organization at the company was 11 people. The initial team was 3, and that team did experience 100% turnover within 6 months. There were various reasons for that, only one of which was related to the change to XP/Scrum.

    - forced to move into a team room

        - he laid down the law, did not waiver

 

Team with no process, no methodology

    - team struggles with lack of direction

    - team struggles with lack of delegated authority

 

Getting started with TDD/agile process

    - start by asking where are your tests

    - start by keep mentioning that tests are needed

    - using tests to explain intent of code via completed tests

    - mentoring developers

    - Small pieces, baby steps

    - explaining the value

 

What can we do that provides the most bang for the buck in the short term

    - remove scope

    - create priority of items that MUST be delivered

    - force the company to make decisions, or you will make the decision

 

Done/Releasable is defined as 'what is good enough to be able to produce a release'

 

Learn to use metrics to lean to convey the status of the project and how

    if they want more features in less how this may or may not be possible.

 

Need to get everyone on the same page in terms of business terms.

    - how did you did do your job before we had 'technology'

 

We need to remove the term 'The business' and turn it into 'our business' (Tom on his soap box)

 

 

 

Minutes: 

Scrum and xp from the trenches – brought to a new team in a ‘team room’

 

Stand ups with different projects is demoralizing

 

Turnover went to 100% -- “change your organization or change your organization” – brute force

 

Having an automated reminder to do stand ups forces to job w/o blame

 

Start with continuous integration when coming from chaos

 

Pairing can easily turn to heckling if the personalities don’t match or the rules aren’t there

 

Small digestible chunks can work for TDD

-using a test to explain how things work can help with understanding and buy in

 

The word ‘agile’ is meaningless

 

First step is to measure before you can change

 

Systems test shouldn’t be necessary when doing QA work as early as possible – TDD or bring QA type people into the team during dev

 

‘pain in the ass’ = ‘agent of change’

 

Prioritization of Staories - Write a number on cards and you cannot use the same number again. Or, order them yourself and say you will deliver in order – they will push back and order them

 

‘see how fast you can stop adding features’

 

‘what are you willing to lose’ can be an opposite way to look at the ‘what do you need to have’ question

 

‘when is it going to be done’ is a perfectly valid question, but process and lack of real engineering lead developers to recoil in disbelief that they can estimate that way

 

Pushing pain up the chain can help create an advocate for the business that is not a manager

-product manager can push back and negotiate with business to ensure value

 

‘Meet date cuts hope’

 

Managers sees agile as an excuse to do no work

-or a union

 

Doing estimates with a burn-down and tracking velocity can help business understand the equation for estimation

 

Product manager is a customer proxy – project manager schedules and runs the project

-cant be the same person because of conflict of interest

 

As #of people grow, dysfunction grows – managers try to throw more managers or force to get it done

-managers shouldn’t decide when you need more resources

-should be pull from developer

 

You must measure your work before you can convince anyone outside the team, or even yourself

 

Don’t label ‘agile’ – just tell them you want to show them demos every week, people love demos

-don’t use the words, just do the behavior

 

Change is a game of applied psychology

 

‘Building software is a grand conversation that culminates in a system’

 

Change can come by explaining a problem, explain a solution, and measure the change

 

Quality assurance (1 out of every 100 is good)

-in manufacturing, when you see that you stop the whole process

-why do we accept this in software engineering

 

When talking to ‘the business’ use a game of going back in time and thinking without computers/systems … this can help bring out the real requirements

 

Repeatedly asking ‘why’ can lead to real business value rather than nuts and bolts of operations

 

Learning is the bottleneck to change

 

Pair programming can create an environment of learning

 

Trust is based on confidence – you have to build confidence – you have to measure to build

 

Lets banish the term ‘the business’ – it lends to slavery

-our business lends to pride

-in the absence of business pride, developers will waste time to create technical pride

 

Mentorship works, training sessions do not

-you have to be patient

-you have to be humble

-hard because lots of devs  are arrogant

 

‘you have to take the agile approach to pitching agile’

 

‘why do I wear my seatbelt; I’ve never been in a fatal accident’ – you have to show value from the outside

 

Quality is a feature

-start with value, bring in labels later if needed

 

The most important help is wisdom

-ask for help

-offer help

 

Explain pain or problem, show a solution, don’t need to use labels for people to buy in

-can’t teach a tool and follow with the problem it solves

 

‘junior developer writes simple code, senior developers writes complicated/bad code’

 

Start with the question ‘how are you going to test that’

 

When you have a bug you always reproduce it … when you do, write a test that will make sure it doesn’t happen again

 

if it’s hard, you’re doing it wrong – mentorship can help – can lead to giving up if it’s too hard for too long

 

with change, you have to prove WIIFM – what’s in it for me

 

using the word done is misleading – use the idea of ‘what can I minimially give you that will provide you any value’ then adding features to work toward more ‘doneness’