Preconference

Making the most of TFS


Rosario will have support for UML.
New licensing groups datadude and developer addition of vs together.
Now all developers can have and use database projects.
I think this is retro for us so we can start looking into using vs for database across the entire team (except testers :( ).

The first 2 hours of the class talked only about installing TFS.
Decided to move to the agile session with Poppendieck.



Agile Session

Joined when Grigoti Melnik from the patterns and practices group was talking about what they learned from implementing agile.
They always use TDD
Sometimes use pairing
Have 75 to 100 developers
Use codeplex for all work
Use customer advisory board
These two provide solid system for communicating with users.
Think in terms of stories not features.
-design software from the customer perspective.

Focused defining what success is.
On time
On budget
On scope
These three are definitions of success of project estimation not success of project.
You want to be planning driven not plan driven.
Maintain and prioritize story backlog for 2 or 3 iterations.
Choose initial tshirt size for stories. Consistent size is key.
"Plans are nothing; planning is everything!" Eisenhower


Low-Fi and High-Fi Iteration Planning
Uses post-its on wall to plan iteration.
Requirements go through iterations just like code with each iteration specifying more detail.
If you find you are rewriting any more than 15% of your requirements you are specifying too much detail too early.
Make use of Team Room!
Use burn down chart to monitor progress.
We watched the video that shows how patterns and practices sets up thier team rooms.

Team Composition:
Program Manager
Dev Lead and Developers
Test Lead and Testers
Tech Writers
Domain Experts

HighFi Planning is nothing more than entering items from lo-fi into TFS.

Avoid multiplexing. Having one person work on multiple projects is bad.
Always enforce physical presence.
Core team with consistent members (do not change team members too often).
Small teams but not too small. Need to buffer from team members leaving.
Pig - cow - chicken - sea gulls
Chicken has a negative conotation.
Do your best to convert chickens into pigs.
Two new personas - Cow and Sea Gull
Cow can help but will not on own initiative (must milk the cow)
Sea Gull does lot a squaking but does not add any value.

Lo-Fi Planning Slide:



High-Fi Planning Slide (TFS WorkItems)



The Done Done State:
Team defines what done means.
Done done state is determined by a checklist.

Add customer acceptance as a measure for reaching release ready.
Do not report on partially completed work.
The closer a feature is to deliverable the less uncertainty the team has about the true state.
Done done should push the team without breaking them.

Demo to stakeholders!
Confidence by regularly demonstrated progress.
Increases product utility.
Increases visibility.
Create architecture to enable this.
Create critical features first.
Organize toward adding customer value (determines what is critical).

Guidelines for stakeholder demo:
Vertical slices.
Do early demos even if small.
Keep short.
Don't demo partial features.
Don't resolve feedback issues in demo.
Take notes and talk later!

Bring testing to the forefront of development.
Ship with tests!
Tests should be fast and non-fragile.
Open source does this well.

4 Types of tests:
Unit, integration, system, performance

Process agnostic practices:
See picture of slide.
"Don't start by thowimg out the documentation."



Value stream maps:

Product concept - longer value chain and duration.
Feature request - Shorter value chain.
Urgent need - Maintenance Patch

See end to end value stream picture

Perform value stream for our feature process
Focus on addin value time over duration.
May take 4 months to deliver something that only took 2 man months to build and devliver. Eliminate wait times.
Try to shrink time from conception to dilivery to match the time spent.
Use limited queues to achieve lean development and shrink duration!!!!!
If a feature backlog has more than a few items in it work on getting items out of backlog rather than adding more to the back log.

Showed work stream with batching which was worse.
Value stream should go all the way till the user is happy.
Did a demo of building out a value map

In the demo stabilization process is a very bad thing!!!
Move testing into development process to eliminate the need to stablize.
Write tests before start coding!!! Group would have to agree on tests defined by QA before starting code. Team works to pass tests. Results in no QA phase.
Develop until tests are passed (not just until code is complete).

If you change 15% of requirements they have too much detail.
Write to level of detail where they are unlikely to change.
Drill down to detail iteratively.
Change control process is waste.

Two perspectives on testing:
Business (granularity of req)
-workflow-transaction / use case
-rule (calc check)
Technical (decomposition of SUT)

Better test automation strategy.
Look into FIT tests to specify user acceptance tests.
The following two slides show a transition from creating lots of highlevel tests and little low level tests (unit tests) to createing lots of low level tests with a few high-level tests. The second state results in higher test coverage with less fragility.









Spent the last part of the session talking about working with global/distributed teams and how to setup contracts with agile.