I saw Elsa Vezino speak at the Twin Cities .NET User Group on "Everyday Agile for One" on Thursday night.

You probably should have a little standup with yourself as a mental exercise when working alone. It will mentally prepare you to speak to what you are doing when someone asks. You should probably also break things up into stories and the like. Elsa put an emphasis on estimating Scrum points and also a metric for how much of a value a story is really worth regarding just how much it matters big picture (i.e. can you live without it?) and with these metrics you can have a conversation with your stakeholder about what's what and what's next a lot better than is the case in the absence of such a structure. A lot of this talk was stuff I had already heard about as Agile isn't new and a lot kinda strayed beyond Agile (for example, Elsa encourages you to bold text the one line of an email someone should read if someone only reads one line of any email you send and for that line to be at the top of the email), so I will focus on what was new to me. Crystal was mentioned as an old out of vogue practice. I Googled it and Crystal was a lightweight form of Agile which assumed that each project required a slightly tailored set of rules. Someone in the crowd mentioned that where they work all of the various teams do Agile but they are allowed to define how to do Agile themselves and they each do Agile their own way. In a demo, let your stakeholders take the mouse and drive themselves. It will allow for better feedback/commentary. Coding Horror as a blog offers a lot on the dangers of coding alone, falling behind in tech, no one to sanity check your stuff, etc. stackexchange.com is QA tool. Stop, start, and continue are things to think about in a retrospective. What should you stop doing? What should you start doing? What should you continue doing? "Lean Software Development: An Agile Toolkit" by Mary and Tom Poppendieck (Minnesota locals) was suggested to be a pretty good book and I think a quote from that book is "Quality in design means realization of purpose or fitness for use rather than conformance to requirements." and in other words quality code should enhance Agility not get in the way. The book suggests there are seven types of waste:

1. unfinished work
2. extra features
3. relearning
4. handoffs
5. delays
6. task switching
7. defects

Elsa Vezino sighted the twelve principles behind The Agile Manifesto a few times:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.