XP and Design at the Agile Brazil 2009 conference

Where did the Design phase go? There is a misconception that XP does not promote design. In fact, it is quite the opposite. And I will be talking about it at the Agile Brazil 2009 conference in Rio de Janeiro, Brazil on June 27th.


I have been presenting on XP and Design, where I share my experience on how XP promotes continuous design improvement through Simple Design, Continuous Integration, Test Driven Development (TDD) and Refactoring.


This session was very successful when presented in other conferences (please see history of this session below), bringing the mixed audience (junior and senior developers, as well as coach, testers and managers) into what felt like a good conversation about XP।Similarly to XP’s Evolutionary design, this session has evolved into its current form. The feedback from every time the session has been presented was reincorporated as improvements. I don’t try to sell XP as the silver bullet for software development. Instead I talk about my experience in traditional and agile development approaches, and what I have seen working (or not working so well) in the projects I have been exposed to.

History of this Session

From the past three years, I have been giving training on Introduction to Agile, and Agile development practices, such as Test Driven Development, Continuous Integration and Refactoring.

In the beginning of 2007, I created the Introduction to Test Driven Development and the Continuous Integration sessions for internal training at ThoughtWorks.

In October 2007, I gave the Refactoring to Patterns – a practical look into the Agile approach on Evolutionary Design session at the IndicThreads 2007 conference, Pune, India.

In March 2008, I refactored the previous given presentation into its new form: Evolutionary Design through TDD and Refactoring practices. This session was presented with Kurman Karabukaev at the Google TestaPalooza 2008 conference. This session was awarded the conference’s Certificate of Excellence. The audience really liked the pair-presenting style during the session, and the discussion on different Agile (and non-Agile) experiences by the presenters.

In June 2008, the session evolved into the Agile Evolutionary Design for the Agile China 2008 conference. Once again the session was well received by the audience of 300+ people.

In October 2008, I invited Sudhindra Rao to improve the session and co-present in an upcoming conference. Sudhindra and I had been pair-presenting on ThoughtWorks internal Agile training. The session re-emerged as its current version: XP and Design - Where did the Design phase go? This session was given at the IndicThreads 2008 conference, Pune, India. This session was very successful, bringing the mixed audience (junior and senior developers, as well as coach, testers and managers) into what felt like a good conversation about XP and how we saw it working previously.

Speaking at home country

I am very excited to be speaking at my home country and present on one of my favorite topics: XP Design. Also it is an honor to be speaking next to amazing speakers and agilists such as Jason Yip, Adam Monago, Manoel Pimentel, Rodrigo de Toledo and Alisson Vale.

Three stages of the Daily Scrum

Lately I have been working in a large Agile program. With large Agile programs, comes common large team challenges, and the need to adapt the Agile development and management practices to better suit the large team challenges.

Currently the program has 180 people distributed over 12 teams. Each team is formed by 15 people (project manager, business analyst, quality assurance and developers; for short: PM, BAs, QAs and Devs). All teams are following agile practices such as 2 week Iterations, Daily Scrums and End of Iteration retrospectives.

In this blog entry I will describe how the daily scrum (or daily stand-up) meeting went through 3 different stages as the program grow from one team to 12 teams (of 15 members), adding up to 180 people on the program.

Stage 1: The Daily Scrum meeting

When the program was small (up to 2 teams of 15 people), each team had a daily scrum. The teams were getting good value out of the daily update. The three questions answered by each team member (what did you work on yesterday, what are you working on today, do you have any blocker?), and some informal catch up by the PMs, BAs, QAs and Devs of the two teams was enough to keep all program members in sync.

Stage 2: Scrum of Scrum with PMs and non-PMs

As the program was growing (consider now 5 teams of 15 people) the teams were still having the daily scrum meeting. However the individual teams started losing context on the status of the program, and important inter-teams updates and communications were not flowing as easily as when the overall program size was smaller.

We started having Scrum of Scrums after the teams’ daily scrum. The Scrum of Scrums (SoS for short) had the same format as the daily scrum: the participants would stand in a circle and would quickly give status update by answering a few questions. The questions were slightly different than the daily scrum questions. The SoS participants would answer the following 4 questions: What did your team do yesterday, What will your team do today, is anything blocking your team, is your team about to put anything in other team’s way?

The participants of the SoS were PMs and non-PMs: team member, such as BA, QA or Dev. The PMs presence was mandatory and they would drive the meeting (answer the 4 questions.) Each team had two representatives: the PM, and the non-PM team member. The PM would daily select the non-PM team member to attend the SoS (this was done in the team daily scrum). At times a team member would volunteer to come, as he/she had to give some important update to the overall program.

The non-PM SoS participants brought very important aspects to the SoS. First they would complement their PM with the extra detail (not too much detail, but enough for spawning the interest for the other program team members.) Second, they were effective radiators of information. They would bring information back from the SoS to their teams (at times the PM was pulled into other meetings prior to returning to their teams.) And last, the non-PM SoS participants made sure that the SoS did not become a PM update meeting.

Stage 3: Scrum of Scrum for PMs

The program was growing in size. Consider the phase where the program reached 12 teams of 15 people. The SoS with PMs and non-PMs became less effective. First, it was taking too long for 24 people to talk. Second, the SoS was becoming a mixed forum of discussion. The PMs wanted to go into further project management details, while the Devs wanted details on the development activities.

We changed the SoS format. At this stage, we broke it into several SoSs: The PM SoS, the Dev SoS and the QA SoS. In fact the PM SoS called was named SoS: Scrum of Scrums. The Devs and QAs meetings had other names such as Dev hurdle and QA catch up. The PMs kept the SoS in a daily basis; the other roles varied the frequency of their catch up meetings.

The SoS became a PM update, but it was an essential (and quick) PM update. Actually, the SoS still kept the stand-up in circle format, which prevented the PMs form giving long updates (specially after standing up in each team stand up, and then in the SoS). Also the PMs were still focusing on answering the original 4 questions of the SoS (described in stage 2).

The art of facilitating the SoS made an enormous difference. It was simple: whenever a PM would go into a detailed update (for example, I found a bug pattern in my team that …), or two or more PMs would repeat the same information (e.g. blocker: my team could not commit because the Continuous Integration server was down) the item would be added to the Parking Lot.

The Parking Lot items would be discussed at the end of the SoS. PMs that were not required could leave the meeting. If other people would be required, they would either be dragged into the meeting room, or a meeting would be scheduled later.

In summary, the described stages of the daily scrum worked for the program in different stages of the program. My main learning from this experience: try what works for your team, but do not hesitate on adapting.