Agile Development

Value Seekers, Stakeholders, business analysts are represented by the Product Owner.

A lot of time, people don't really know what they want until they start talking with other peoples.

Sharing DBA / QA with more than one teams. Multi-task overhead.

Core teams in different locations, each team own a separate component / product.

Bring in an agile coach.

If your main development team in the US is already up to speed with agile development, but your other development team in India is familiar with agile development, or for whatever reason, is not in tune with the development team in the US, bring one person from India to US so that person get to see how agile development is implemented here, and have that person responsible for implementing agile development in India.

Teams in India need to be in tune with teams in the US. Corporate policies and values need to be the same throughout. Google have offices in India, and London, but these are not outsourced teams. These teams are really part of Google.

For dealing with vendors, write up the contract in incremental iterative way. Make sure that the team specify all features.

Everything takes time.

Creativity take time (when working in a time-constraint environment).

Do it in a controlled way so you can measure the effect.

A part of thing: people have to understand whatever they are to work on, and it take time.

Bring people to your office, working with your team, send this person to your other location, and have this person spread your process. You can send a person from the US to India for a few month if you can't get a visa for a person from India to US. It might be preferable to have a person from India come to the US, because when sending a person from US to India to train the India team, the India team may think of the person from US as a foreigner, a boss (which is not right, not what we intend), and when the boss is no longer there, they no longer have to follow the rule. When we bring a person from India to US, allow that person opportunity to see how the process work in the US, empower that person as an agent of change, empower that person to change the team in India, what we have is a responsible boss in India, who understand our way of doing business, our values, etc..

Scrum of scrums (2 levels max).

=~ 10 people per team.

32 teams (biggest)

Product owner ambassador (dealing with vendor). If our vendor does not have an agile development process in place, perhaps we can convince them to implement agile development. Perhaps we can invite our vendor to our office so that they can observe how our process work. Perhaps, one of us can participate in their development process. Perhaps, when we write our contract, we can require our vendor to be familiar with agile development, and deliver product in an incremental fashion.

Iteration Backlog, Release Backlog, Product Backlog.
Daily Cycle, Iteration cycle, Release cycle.

It is better to under-commit than over-commit. Should not be too under-committed though.

Deadlines are sacred.

Minimum Sell-able Product.

If we have to do a hot fix, should we also release other releases that are ready to ship (to minimize downtime). Will there be surprises (release a feature too early before the press release is ready)? The release team needs to keep track of all change control items. Once the release date is set, we should not pull that release to be part of a hot fix release. Doing so increase the risks of the hot fix release. The hot fix release should only contain hot fixes. For whatever reason, we failed to deliver a release on its target date, that release should not be bundled into the hot fix release.

With agile development, in theory, we have multiple release ready for deployment. Should we deploy each of these release as soon as it is ready? I had problem with remembering when a release would make it way to production. Perhaps I can use the bug tracking system for this.

Can we take a task off a sprint? Is the sprint locked in? I should be able to able to take a task off a sprint. As part of sprint planning, we should commit to user stories that we can commit to, then we should have a couple of pro-bono stories that if we have time we can do. These pro-bono stories should be ones that are likely to be part of next sprint anyway, or small stories that would be nice if we can get to it.

Product Release Calendar. Being able to see when a feature will be released.

Incremental Learning, Adaptation, and Growth.

Baby step.

Scrum, Retrospective.

DONE: code complete + documented + unit tested + validated by QA.

Customer involvement.
Understanding requirement.

The problems with having multiple backlogs.
The problems with having single backlog.
Big red dependency.

Metrics: speed, cost and quality of value delivered.

Meet and Greet sessions. Lunch over product backlog and share knowledge.

Sharing knowledge
Managing Resources
Identifying Value
Delivering Value.
ROI.

Traveling light: Do only what is absolutely needed.

Velocity / Speed should not be used to put more stuff into a sprint. Sizing the sprint should be done by the team, not by management. Management shouldn't put pressure on the team when the team feel that it can not commit to anymore user stories.

Area of specialty. Should rotate people. Shouldn't pick bugs that you are already familiar with.

If you hire a bunch of consultants at the end of the release cycle, you are putting gasoline on fire. It never work.

8 stories 100% done is better than 10 stories 80% done.

Tracking status of sprint.
Sizing
Velocity
Acceptance criteria
Lookahead sizing / backlog
Planning for defects (long and short term)
Daily Scrum
Design Documentation. Agile Development does not emphasize on documentation (our tests become our documentations), but we should still document architectural designs.

Version One
Rally
ScrumWorks
Mango by ThoughtWorks
XPlanner

The process drive the tools. Choose the tools that work for your process.

Release Planning. Longer term, strategic planning. When must / should this feature get out.

Graph of how much work has been done for this feature.
Graph of how much work remains for this feature.

The product manager / owner or scrum master, should organize meeting for planning, sizing, meet and greet, etc.

New Features
Defects
Improvement
Maintenance

75% of time is for work. 25% of time is for meeting, maintenance, bugs, other interruption, improvement, hot fixes, design documentation for future features, training.

It is better to under-commit than over-commit.

Risk management framework.
Architectural design.

Virtual Scrum board.

There are time that we must do things in an adhoc ways, and there are time that we must NOT do things in adhoc ways.

Stories per hours?
Story point? How is it map to the number of hours? Why do we use Story point instead of number of hours?

Recalculate story points in retrospective.

Highly specialized skill -> bottleneck.
Agile prefer jack-of-all-trade over highly specialized skill.

Think about test criterial early, as part of sizing.
Planning and sizing is a team responsibility (everyone on the team participate).
If you can't fit it on the card, you are trying to do too much.
If the team have too much lag time.
Scrum: synchronize and steer, not just a status report.

Agile process is a time box.

Tasks that require UI design should be at the top, or should be done prior to the sprint.
Release to customer (last final task) tie everything together.

Unexpected things / issues always crop up from time to time, but we need to plan for them.

Interrupt levels
Design Documentation
Architectural documentations
roadmap documentation
help / user manual docs
just in time
collective ownership

  1. Sprint theme
  2. Capacity Planning (who will be away)
  3. Next Story
  4. Discuss
  5. Task breakdown and estimates
  6. More capacity?
  7. Check Sprint Planning (critical paths, overloaded resources, risks)
  8. Commit and Sprint

Web-based software to manage the backlog, and tasks.

Sprint
Frequent Internal Releases
Get into a rhythm. Do not vary the length of each release cycle.
Inspect and Adapt
Deadline is sacred, functionality / feature may vary.
2 tracks teams
MSP: minimal sellable product

Collective ownership. Should not have a single person solely responsible for a component of the product.
Early feedback.
Transparency and communication.
Always potentially releasable.
Pair programming

Adaptive Software Development
Lean Software Development

Welcome change (even at the last minute)
Delivering working software frequently.
Daily cross functional communication.
Trust and Support teams
Face to face conversation.
Sustainable development.
Continuous attention to good design.
Simplicity is essential.
Self-organizing teams produce best results.
Regularly reflect and adjust.

Cross functional
Constant collaboration & communication.
Self-organizing.
Collective ownership.
Shorter cycles.
Iterations within a release (sprints)
Priority don't change.

Just In Time Design

Incremental, Iterative, Integrated Development.
Tackle high risk issues quickly.
Isolate them if we can't solve them.

What you hide, you can change.

"Writing Solid Code" by Steve Mc….
Try breaking your own code.

Separation of concern.
Retrospection.

Work on the most important thing first.
By deferring unimportant things.

http://tech.groups.yahoo.com/group/learnprogramming

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License