with Dave Laribee
No direct access to the customer or How do we work with indirect customers? (15)
·Bring them in
·This is one of the highest risk type of client
·You need a continuous presence / continuous access
·You don't want any barriers to communication
·You need to have a good working relationship with the client. You really can't do this unless you have actaully met the person.
·Move us to them
·Customer proxy can fill in a pinch.
- Needs customer level authority / responsibility
Agile in a waterfall org? (13)
·Focus on the agile principles and not on Agile itself
·Don't call it agile and let your results sell your process
·Start with things that'll make the customer happy
- A CI server so the customer can see the build and you'll seem more trustworthy and transperent
- The customer has to be aware of what they're seeing
·Have success and show your success and be aware that others will push back
·A whole bunch of short iterations can fit inside a CMMI cycle
- You will have points of synchronization
·How do you eat an elephant? One bite at a time.
·Solve pain
How do we not get mired in the details of the process? (10)
· Ensure the goal does not become Agile, it should always be the product
· Get a Champion
· Build up rules of etiquette
· Learn from your peers and resources
· Don't let estimation session turn into design sessions
How to start with Agile? (9)
Can we use Agile engineering practices without the management practice? If so, which ones yield the best results. (9)
· Yes
· CI and automated build are an easy start
· Focus on frequent releases
How do we involve customers and stakeholders? (9)
Agile as a one-man-band or small shop? (8)
Where's the Agile NorthWind? (8)
How to maintain velocity near the End of a release? (7)
How to we sell Agile to Suits? How to we sell Agile to our technical leaders? (6)
How do we foster an environment of continues improvement when "Agile" adoption is surface of mediocre? (6)
Distributed Teams (6)
Books and Articles
· Scott Ambler article on blocking
Notes
· Self organizing teams are very risky as they do have clear authority and reasonability
· With estimation the SD will average out over time
§ You want stories around the same time so you can keep the same velocity
§ Break tasks up into the same point stories so all your work is a similar size
§ You just want to know if something is so big it need to be broken down
§ We are good at determining relative size, but not exact size
· Agile in not just Scrum, Scrum is not the only Agile