Planning Poker... A Better Way to Estimate as a Group

I've mentioned in some previous post that I would explain the basics behind planning poker and how it could be used to make your team sprint planning session more fun and more accurate. This is a technique normally used for estimating the relative complexity of the items in a product backlog but it can also be applied to estimate the time for tasks in a sprint backlog. So, here it is.

Planning poker is based on the collective intelligence principal were it is said that the collective knowledge of a group will outweigh that of any one individual in that group. A detailed breakdown of this can be found in a book called the Wisdom of Crowds by James Surowiecki but I will try to sum up this idea as best as I can and explain how it applies to collective estimation.

A scrum team is generally formed of individuals having different expertise. Some people are good at testing; others at designing systems and writing code and some have knowledge relating to user interfaces. As a scrum team, each member should know enough about each feature (or user story) to implement them. This is what makes the scrum team work well as a group. Pooling this collective knowledge of the features, each member is able to estimate to the best of his knowledge and expertise the amount of time a feature can take. It is by combining these estimates that a consensus can amount to a very accurate estimation.

What planning poker brings to the table is a fun and an enticing way to get this collective knowledge out of each team member.

How to Play

1. You will need a deck of planning poker cards (index cards or Post-Its can be used as substitutes)
2. Each members of the team get a hand of cards
3. Each hand is composed, for example, of cards with the following values ?, 0, 1/2, 1, 2, 3, 4, 5, 8, 13, 20, 50, 100
4. Each number represents a unit of time such as real hours, man-hours, half-days, etc... You should define this for your group
   
5. When estimating for a feature, each member picks a card and places it face down on the table
6. When everyone picked a card, the cards are turned
7. If the estimates vary a lot, the team discusses the reason why higher/lower values were drawn within a preset time limit and the hand is replayed
8. This is repeated until the team converges to a similar estimate

Explanations

The values of the cards can vary from deck to deck but the important aspect of the series to observe is that it is non-linear. The reason for this is that bigger features are harder to estimate so; the bigger numbers represent ruff estimates. The extreme values are explained here:

• ? should not happen often but when it does, it is an indicator that the information about the feature is not know well enough by the person to estimate. This means that further explanations to the team might be required
• 0 means that the feature is already done
• 50-100 might be an indicator that a feature is too big and that in order to obtain a more accurate estimate, it should be broken down

When the estimation round is played it is essential that each team member finish picking his card before all the cards are revealed. This is to eliminate the estimation by a single subject matter expert that can potentially influence the estimate of others.

I hope I have made myself clear enough for you to better understand the usefulness of planning poker and if you are still confused, I suggest you look it up on Google for there are many explanations and perhaps variations of this out there.

Still not convinced? I suggest you try it at least once.

The Value of Collaborative Estimation

This presentation given by Mitch Lacey was essentially a case study of a team's problems with its scrum implementation and how this was eventually solved by making a few changes and introducing new practices.

My post will essentially be a summary of the case study highlighting some of the points I found to be the most relevant for any team who might want to review their scrum implementation to make it better.

One of the things that I found very interesting in this presentation was the realization of the fact that it is not because a team performs a scrum that it magically develop better and instantly deliver quality. Like any process and practices, there is a need to perform retrospectives to bring up the question of "what can be done better?" This question alone is an instigator of something people aren't always keen on doing and that is to CHANGE.

Something I've learned during this week long conference it that change is good, and when trying something such as scrum that doesn't work as well as it should (as described in the books) then change is something that should be introduced to help achieve the desired results.

Moving on to the case study; the issues experienced by the team were:

• The business unit (BU) owners needed realistic estimates
• The BU owners needed a shippable product
• After each sprint, the numbers of "Not Started" and "In Progress" tasks were significant
• The team just wasn't delivering
  

This basically broke the trust between the team and management. At some point in time, a consultant was brought in to analyze the situation as the following items were deemed to be a constant cause of these problems:

• The team had no clear definition of "done"
• There were too many open tasks per person
• There was no standard demo meeting format
  

Other causes we identified but these weren't a constant factor:

• The subject matter experts (SME) didn't participate in performing sprint tasks
• The SME did all the estimation for the team
• The sprints were too long
  

The following list of solutions were proposed and implemented immediately:

1. Have all team members participates in estimating the sprint backlog by using planning poker
2. Write a clear and comprehensive definition of DONE
3. Reduce the amount of open tasks per person to no more than 2 or 3
4. Formalize a demo meeting
5. Reduce the sprint length from 1 month to 2 weeks
   

Planning Poker

Using planning poker instead of the usual guesswork involved for estimating is a recommended technique for scrum teams. It gets the team members more involved and produces overall more accurate estimates that allows the team to deliver value in a more predictable way. I'll put up a post later which explains en greater detail how planning poker can be used to estimate a sprint backlog.

Define "Done"

Simply having a definition of the word "done" for the team can have some beneficial effects. For example:

• It provides clear communications to the stakeholders
• It drives down risk
• It bonds the team members
  

Reduce the Amount of Open Tasks

Doing too many tasks at once introduces context switching. Context switching is counter productive hence focusing your daily work on a minimum amount of tasks will reduce this effect. If you need some convincing on this subject, try the following experiment:

Ask a colleague to have a race with you. You will each need a pen and a piece of paper. The objective if to write three series in columns. The first column will be the numbers 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. The second columns will be the letters A, B, C, D, E, F, G, H, I, J. The third column will be the roman numerals I, II, III, IV, V, VI, VII, VIII, IX, X. Your colleague must write the series from top to bottom starting with the numbers, then the letters, then the Roman numeral. You must write the series from left to right, context switching from number, to letter and to Roman numeral. You should both start at the same time. See then who finishes faster.

Demo Meeting

The demo meeting is meant to demonstrate the delivered value to the product owner. This "scrum ritual" should be formal and well defined.

Sprint Length

The basic idea behind this is quite simple; by reducing the sprint length the estimates become more accurate. An estimation of what can be done over a two week period will be more accurate than that of what can be done over a one month period. Mitch posed used the following question to demonstrate this point: “If I ask you today what you will be doing in one month and then in two weeks, with which answer will you have the highest level of confidence with?”

The introduction of these changes within the team has had significant benefits and I am convinced that such changes could benefit others too. I recommend you read the full presentation and see the numbers for yourself. It is available at the following address:

http://mitchlacey.com/index.php/Resources.html

Back from Toronto

I haven't updated this blog since about Wednesday last week but I plan to post some more material this week. I got back from Toronto an hour late because of some guy who didn't deem it necessary to hurry up from his connecting flight from St-John's New Brunswick. It took him 30 minutes to get from one gate to another; his luggage even beat him to the plane. The pilot wasn't too happy about this and totally ripped on the guy on the airplane's PA system when we pulled back from the gate and made our way to the tarmac.

As I re-read my notes and draft up some more material to post, here is a non exhaustive list of various quotes I picked up during the conference... enjoy and keep reading:

“The best metric of a code review is the number of W.T.F. per minutes” – Uncle Bob

“Agile means good engineering practices” – Mary Poppendieck

“A good scrum master is seen but never heard” – Ken Pugh

“It's not an iteration if you only do it once” – Jeff Patton

“Any tool can be misused” – Henrik Kniberg

“I don’t know what I want to I know how to get it” – Sex Pistols

“The only way to go fast, is to go well” – Can't remember who said that

Impresions of the Conference so Far...

I must say that I am quite satisfied with the Agile 2008 conference so far. I was lucky enough to have picked some interesting topics with very good presenters. I also had the mischance of selecting topics which had a seemingly good title and abstract description but I ended up ditching the presentation about 20 minutes in because I didn't feel the content would be very relevant to my personal goals of being at this conference.

I would like congratulate the organizers for the smoothness of how things are going however I have the following two "complaints/suggestions" I would like to make for next year's conference.

1. There are way too many good topics to choose from. Multiple topics provide a very broad coverage of many subjects however, being only two delegates from my organization, I am sure we have missed out on some VERY interesting topics and presenters altogether.
2. In relation to point 1 is the missing presentation material from the conference CD. I understand that having all the presenters submit their material beforehand can come with its load of logistical problems but I find that many good talks which I would've liked to attend are missing from the CD.

I'm the organizers will provide us with some way to access the missing presentations because I would like to read up on some of the presentations I couldn't attend.

Tomorrow is day 4 of the conference and will be by far the busiest day with four sessions and the banquet keynote speech. I'll be posting some more info tomorrow morning because agile conference reporter is exhausted.

It's not an Iteration if you Only do it Once!

The title of Jeff Patton's conference talk was: Embrace Uncertainty, Why in Agile Development Knowing what you want may be an Impediment to Getting it.

I came into this presentation about 20 minutes in because I ditched my first choice conference due to irrelevant content with respect to my likings. I'll get more into the details of my general feelings towards the Agile 2008 conference and its enormous amount of topics in a later post.

What left the biggest impression in my mind when I stepped in was the following quote which I used as the title of this post: "It's not an Iteration if you Only do it Once!"

I found this to be quite revealing because I sometimes find that we forget what iterative and incremental development is over time and slowly fall back into the dreaded waterfall model without even knowing it. Lets take a look at what gets us into this pattern and try to find some strategies to get out of it.

The following should sound familiar: "That iteration stuff is good but we have commitments to keep...". Software is often a line item in a larger plan. Failing to release on time may put the bigger plan at risk. In order to properly plan we need to properly estimate and with estimation comes uncertainty.

Jeff proposed 3 strategies themed with musical clips to help us cope with this uncertainty.

1. Follow the Money

• Follow the user stories back to their source
  

User stories build software, software is used by user constituents and all this to satisfy one or many business goals. The purpose of this strategy is to start at the business goals and work your way down to eliminate parts of the user constituents and reduce the overall set of user stories. This helps you focus you development by selecting the stories that are related to business goal which have high business value.

2. Don't choose your solution too early

• Firstly write user stories that describe what people want to do
• Defer selection of which user stories to implement to later
  

This bit might sound a little confusing but I'll update this section later with a link to the presentation which explains this principle using a diagram.

3. Build up feature quality iteration by iteration

I found this section to be VERY RELEVANT. The following is a heuristic for slicing up quality goals:

• Necessity
• Flexibility
• Safety
• Comfort, Luxury, Performance
  

This list represents the categories for quality goals. The idea is to start by implementing goal that are necessities and working your way down to the comfort and luxury items over iterations. This basically mean that instead of fully developing a feature withing a single iteration, the feature itself should be divided in tasks that will implement a different level of quality goal per iteration. For example, you are building a text editor:

• Iteration 1: You build and implement basic text editing capabilities such as creating a file, saving a file and editing text. (Necessity)
• Iteration 2: You provide a mechanism that allows basic style such as font selection, bold typeface and italic typeface. (Flexibility)
• Iteration 3: You implement unit testing beef up the code of the basic features to make it more robust. (Safety)
• Iteration 4: You add some bells and whistles to make the application's visual style appealing and optimize the memory required. (Luxury)
  

This above example might not be perfect but I think the idea gets across.

Finally, let me know if you need some clarifications on this information for I have miss a small part of this talk. I'll be glad to provide more information once I receive a copy of the presentation from Jeff.

10 Ways to Screw Up with/despite Scrum and XP

This talk was given by Henrik Kniberg from a Swedish consulting company called Crisp.

I had the change to get a copy of his paper called "Scrum and XP from the trenches" which can be downloaded in PDF format at the following link:

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

I will summarize the content of this presentation in point form. The goal of Henrik was to expose different failure modes which scrum and XP teams can fall into. Sometimes identifying the problem is enough to get a discussion going so people address it.

1. Believing the Hype

• Believing in magic
• Not willing to change
• Throwing out stuff that works
• Focusing to much on process perfection
• Trying to get it right from the start
• Blaming the messenger
• Tools focus
• Focusing on the wrong issues

2. The Definition of Done

• Don't have it
• Don't obey it
• Outside the team's control

3. Velocity

• Isn't known
• Isn't used
• Is misused
  
• Death marches (everyone commits to something most know will fail but do it anyway)

4. Retrospectives

• Doesn't happen
• Doesn't result in concrete improvement proposals
• Changes not executed
• Unwanted people at the meeting
• Team members not participating or the product owner is not participating
• The team is penalized for bad changes

5. Team Commitment

• Team is pressured
• Team is not co-located
• Team doesn't track and learn
• Under commitment
• Over commitment
• Velocity = 0 (No fully finished user stories delivered at the end of a sprint or cycle)
• No slack time

6. Technical Debt

Quote: "We don't have time to write unit tests of refactor code". Technical debt can be compared to accumulating interest on a loan. You let it go and forget it for awhile but you'll eventually have to pay up! Examples of technical debt are: duplicate code, lack of test coverage and unreadable code. Failure modes for this are:

• Letting it pile up
• Ignoring it
• Fixing the product but not the process
• Big bang rewrites

One way of dealing with technical debt is to:

• Slow down, stop accumulating debt and adopt a sustainable pace
• Slow down even more and start repaying debt; this will eventually increase your pace over time

7. Teamwork

• Fixed roles
• Personal backlogs
• Not helping each other
• Personal incentive modes
• Implementing all the stories in parallel
• Management interference

It is important to talk to the team in order to focus their efforts.

8. Product Backlog, Product Owner and Customer

• Product backlog (PBL) does not exist
• PBL not visible
• Big or never ending user stories
• Product owner (PO) without proper domain knowledge
• Multiple conflicting POs
• PBL not maintained by PO
• PO surprised at sprint demos
• PO is the bottleneck
• PO is not prioritizing

9. Mergophobia (The Fear of Merging)

• No "done" code branch
• No branch policies
• Not integrating early enough or not often enough
  
• Hiding behind branches

Quote: "You don't get and agile organization without agile engineering practices"

10. Sprint Backlog/Taskboard

• Does not exist
• Too far from team
• Too complicated
• Not used during daily meetings
• Not owned by team
• No burndown chart
• Not updated daily
• Warning signs are ignored (such as burndown chart burning up)

11. Worrying to Much About the Other Ten (Bonus)

• Problems are normal
• Never stop looking for problems
• Don't panic, don't despair
• Visible problem = killable problem (this is an opportunity for improvement)
• Prioritize and fix problems one by one
• Look back once in awhile and pat yourself on the back

You can find some useful scrum checklist at the following link:

http://blog.crisp.se/henrikkniberg/2008/02/01/1201823760000.html

Simplified Scrum Taskboard States

Talking with old work colleagues about their implementation of the scrum process, the subject of the sprint task board has come up. My team uses a physical task board with each row representing a feature and each column representing a state. Sub-tasks are written on Post-Its and placed on the board in the appropriate state. The states we use are:

• Analysis
• Design
• Implementation
• Testing
• Done

These states reflect the states you would normally find within a unified process iteration. The problem that arises by using these states, I find, is that certain tasks such as bug clearing among other things don't really fit into these categories so they basically have two states: not done and done. This beats the purpose using the taskboard.

What I will propose to my team is a redefinition of the states to something more general which tend more to reflect the likes of the extreme programming practices. The states are:

• Not started
• In progress
• To test
• Done

I find that the four states are much simpler and all types of sub tasks can be fitted in this model; This way, the taskboard is used to its full potential which is to be able to visually see the progress of the work.

Working with Global and Distributed Agile Teams

This session was presented by Ken Pugh of Net Objectives. Although the presentation was heavy in power point slides (more than 75 packed in a 90 minute session) I collected some useful bits of information that could be useful to colleagues who need to deal with global agile teams. Starting off, the following definitions must be made:

• A dispersed team is one that is physically less than one minutes apart
  
• A distributed team is one that involves transportation if its members want to meet
• A global team usually implies different countries, different cultures and major physical separation
  

The greater part of the presentation modeled distributed and agile teams by presenting the following different aspects that need to be dealt with:

• Communication
• Trust and Us-ness
• Communication Media
• Face to Face
• Organization
  

Communication

I shall summarize each aspect of this presentation highlighting the relevant parts to my organization and in particular, my department. One of the problems inherent to working with a global and culturally diverse team is communication. The same works in one culture can have a different meaning in another. For example, define the meaning of:

• "Done"
• "I'll have that for you tomorrow"
• "Yes"

The group was polled with a suggested list of meaning and obviously the responses were different. In order to simplify communication if must define meaning in order for everyone to understand the proper meaning of things. Another aspect of communication is tokens. An example of a communication token could be honking the horn of you car or nodding you head. Once again there are as many meanings to a token as there are cultures that use them. Responses such as saying "okay" or remaining silent can vary in meaning. The important thing when dealing with communication is to define meaning, agree on interpretation of tokens and if the meaning is to embedded in a culture invent your own.

Trust and Us-ness

Speaking in an agile team can be defined as:

• Reliability
• Predictability
• Competence
  

It is important to establish trust within a team because trust reduces the need for control and management. To achieve this, it requires clear goals and commitment. However, it is important to remember that trust is a very fragile thing, it is build up incrementally but broken precipitately. As a team leader or member, you must firstly acknowledge that trust takes time. Team members should expect to earn trust; this means that actions should match words. In summary, defining expectation allow a team to self organize base on these expectation can help foster and develop trust over time.

Us-ness is a term used to define a whole. We are a team; we work as one towards common goals. The best way to explain what us-ness is would be to transform us versus them into us = whole team and them = the competition. Us-ness can be developed with different team activities or celebrations to bring the team as one.

Communication Media

This section can be summed up by the means we use to communicate. Instant messaging, teleconference calls, text communication and face to face meetings (more on this later) are all ways to facilitate communication. The idea is to use what make your team work.

Face to Face

I will quote the presenter on this: "You will pay for the cost of face to face meetings whether you have one or not". I found this quote particularly interesting because it touches a human aspect of communication. No matter how many different types of mediums we use to communication, nothing beats a simple face to face meeting. This also helps eliminate the impression that work is being "dumped" onto a team which then feels somewhat disconnected from the rest of the organization.

Organization

It is possible that certain policies intra and inter-organization could hinder the productivity of a distributed and global team, so this is an aspect that should also be considered to help you make the most of your team.

Hiring for an Agile Team

To date, this presentation was one of the most useful and relevant hands-on workshops I have done. I can say right now that this can and will be applied directly for myself and hopefully others who partake in the process of hiring either interns or permanent employees.

A definition to begin with; Agile teams tend to:

• Be more collaborative
• Be cross-functional
• Roles tend to be blurred
  
• Work in an intense environment (short work iterations, continuous releases and integration)

When looking for a good candidate for an agile team you should look at both non-technical and technical skills. For example:

Non-Technical:

• High collaboration skills such as working well across teams and being able to contribute to the ongoing product reviews cycles
• Able to take initiative
• Has respect for each team member

Technical (the first two are the most important):

• Functional knowledge (how do you work)
• Product domain expertise (problem space and solution space)
• Technology
• Industry expert

What is important when interviewing candidates is to first list the non-technical skills that are important to you and your team. This also applies for technical skills but since the talk focused more on non-technical, I'll keep it post within that subject. The following is a list of interview techniques that can be used for the interviewer to better know the candidate:

1. Using behavior-description type questions for example: "Tell me about a time when..." or "Give an example of...". This type of question has the candidate reflect on past experiences and provide valuable information to the interviewer. The best way to handle an answer to this type of question is to target recent experiences first. As Johanna best put it, "the most recent behavior is a very good indicator of future behavior".
   
2. The audition technique. This technique can be realized by submitting the candidate into a typical team scenario and have him act as if he where in the team. This allows the interviewer to see the candidate in action.
3. Hypothetical questions such as "What would you do if ..." gets to the point and allows the interviewer to get very precise information.
4. Closed questions should be used to establish facts
5. Open ended questions should be used to allow the candidate to explain his story and give you certain detail that more direct questions cannot provide.
6. Meta-question can yield VERY interesting answers such as asking "Is there something else I should be asking you?"

All of these techniques can be used and tailored to a particular organization and team however it is important to avoid certain pitfalls such as:

• Asking puzzle or riddle type questions
• Asking: "Why do you want to work here?"

The puzzle type questions have no relevance that would help you screen and good candidate for an agile team and if a candidate is really excited to work for your organization, he or she will tend to tell you without having been asked; Asking directly will most likely yield some generic answer having no useful content.

The above post is a summary of the information that has been presented and I would like to invite you to look at Johanna site at the following links:

Consulting site:
http://www.jrothman.com/

Useful templates:
http://www.jrothman.com/Templates/

Johanna's blog on hiring technical people:
http://jrothman.com/blog/htp/

Mary Poppendieck

First of all I'd like to excuse my ignorance of not knowing who Mary Poppendieck is. I had read a lot of software engineering text books back in university but, although the name rings a bell, it didn't catch much of my attention back then and I hadn't hear much about her since. I find it kind of impressive to hear a presentation from a 40 year veteran in software development citing famous people like Dijkstra.

The presentation was title "Expanding Agile Horizons, The Five Dimensions of Systems". The purpose of the presentation was to look at agile methodologies compared to what has been done beforehand and to try and explorer if agile is not just another fad. In order for agile to work, it must be a sustainable process that will not only provide immediate short term benefits but will continue to provide these benefits over time.

A history of programming practices was presented from the pre-internet era up until the World Wide Web boom of 1995. This all showed us that much of the methodologies and paradigms today aren't new. Some very similar practices were once used but had different names:

• Structured programming
• Not separating design from implementation
• Information hiding
• Top down programming
• Chief programmer teams

According to Mary, during the World Wide Web boom, these practices seemed to have been forgotten because the web was not considered software properly said... it was the Net and businesses were booming. Some lessons we can take from this time and that can be applied to software today are:

• Breaking dependencies
• Broad-based discussions
• Design systems to accommodate change
  

Emphasis was put on the importance of making a clear distinction between project management practices and systems engineering. Over time, systems engineering principles haven't much in contrast to project management practices. So in essence, the message was that AGILE = Good Engineering Practices.

This brought on the presentation of the five dimensions of systems:

1. Purpose
2. Structure
3. Integrity
4. Life span
5. Results

I will leave the details of each dimension as a link to the original presentation at the end of this post. In summary, the presentation was quite interesting, although a bit more time should have been spent on discussing the five dimensions. Finally, I think the message that was being passed on is that in order for agile to work, we need to insure that the practices are sustainable over time and that overall systems goals are achieved.

A copy of the presentation can be found at the follow link:

Official Site:
http://www.poppendieck.com/

Presentation:
http://www.poppendieck.com/pdfs/The Five Dimensions of Systems.pdf

James Surowiecki

Very interesting keynote presentation. James presented his book "The Wisdom of Crowds" which is an item I will probably suggest for our departmental library. To sum up his topic: the collective intelligence of a group of people will outperform a majority of the time any individual within this group.

To form a group of people whose collective intelligence is sharp, there are 3 conditions which must be met:

1. Aggregation
2. Diversity
3. Independence
   

Aggregation: The sum of information collected within the group gives you an overall average that is much better than reliance on a single individual.

Diversity: The more diverse a group is, the better it will perform. One major problem within groups is group think. Group think happens when a group always agrees on their own ideas and basically convinces itself that they are right. This is a major pitfall that can be avoided. One way to avoid group think is to play devil's advocate. Always challenging a group's idea will provoke a form of "good fight" that will yield a better consensus in the end. Peer pressure can also be a factor that will hinder a group's collective intelligence.

Independence: This is somewhat hard to come by in large organizations but this is a key factor for wisdom of crowds. There is a tremendous amount of knowledge in groups held in by individuals that need to come out for the benefit of everyone. We need to make sure that everyone remains independent. This is fundamental.

So there you have it. I'll post some more material on this keynote as and if it becomes available. I'll post another update after this morning's first conference with Mary Poppendieck

Keynote

We are minutes away from this year's keynote speech. Speakers include:

• James Suroweicki
  
• Robert C. Martin
  
• Alan Cooper

I'll post more details later.

Pictures

I've uploaded a few picture which are available in the sideshow viewer on the sidebar. I'll add more as the week goes on.

Research vs. Practice

As I have mentionned previously, here are the details of the today's presentations of the "research in progress" block. The sessions were presented in a 10-10-10 minutes format. Each researcher had ten minutes to present their partial paper. Tables had to nominate a chairman, a scribe and discuss the topic at hand for 10 minutes. Finally, the final ten minutes was used to provide feedback and critique to the presenters.

My overall impressions... Some presenters had interesting topics but nothing really useful could be applied directly in the "field" for everyday business problems. Topics which had potential were:

• Value-Driven Agile Adoption - Ahmed Sidky
• Beyond the Comfort Zone of Scrum - Vladimir
  
• A Theoretical Leg to Stand On: Lesson Learned Using Grounded Theory Study Agile Software Development - Steve Adolph
  

Although, the last one on the list was a little to esotheric for my liking, he had to be one of the best presenters in the bunch. I'm taking the time to point this out, but alot of the presenters could benefit from basic presentation skills such as simplifying the slides, summarizing content and not putting unreadable graphics on their slides.

Overall, the day was smooth and I'm looking forward to tomorrow's presentations. I came here to get some actual techniques and to learn new things from others' experiences with agile methologies. More to come tomorrow.

Information overload

The day just started, we were handed a bag full of pamphlets and various information at registration. There are too many conferences to select from and I hope I'll be able to cover as many topics as I would like throughout the week. This morning I'll be attending the "Research-in-Motion" portion of the conference and I'll be posting more details about what is presented to us later in the day.

Update:

I have sat through a number of partial research paper presentations. Some are interesting, some not and some totally lack content. Baring in mind that this is "research in progress", these researchers are basically polling the crowd for feedback on their papers. There is nothing very practical to use on the field as of now but this should be different tomorrow. I'll post a summary of the topics discussed today with more detailed comments later.

Agile or Bust!

I will be attending the Agile 2008 Conference in Toronto from August 3 to 8. I'll try as much as possible to keep my postings up to date with the different conferences I will be attending so feel free to post your own comments.