Thursday, March 17, 2011

Scrum.org Trainer Meeting in Boston


On March 14th and 15th Scrum.org had organized a get together for their trainers. On the agenda were several topics. The most prominent was to start updating the existing PSM material. Scrum.org added two new trainings. PSTM (Professional Scrum Team Member) and PSPO (Professional Scrum Product Owner). The PSTM is the fundamental training, teaching the basics of Scrum; no prerequisites are required. Whereas the PSPO covers the Product Owner site of Scrum. Those additions are making it worthwhile to look into the existing PSM content and to see what can be removed and what should be updated. On the other hand it was long overdue to meet the other trainers in person.
Needles to say that these were two intense days of ongoing discussions and creation of new ideas. When great minds think alike it is amazing what the outcomes are. Overall, it has been very energizing.
Since the complete PSM material is rather large we weren't able to complete it. Now, our colleagues will pick up our work at the next trainer gathering in Brussels and carry on the baton. Hopefully they will not only carry but also inspect our work and improve it.
So stay tuned for an improved PSM training - a training even going deeper and addressing the more challenging problems of today’s Scrum Masters.
Thanks to my fellow trainers at Scrum.org, I feel honored to call you my friends and to be part of this.

Friday, February 18, 2011

Apple, Scrum and the importance of a good Product Owner

My job as a coach and trainer gets me around quite a bit. It is always thrilling to meet new people and to learn about all types of industries. During those encounters, I often get asked how companies like Google, Apple and Facebook do work. Before I left the USA for Switzerland, I used to work for ThoughtWorks out of their San Francisco office. During that time I had the chance to peek under the covers of a couple of those well known bay area players. Pretty much all of those companies are agile, not necessarily in a Scrum or XP way but they surely value their people with trust and autonomy. Yes, these are exactly the most important ingredients for self-organization.
The one company which I never even put a foot in was Apple – I drove by twice a day – but 1 Infinite Loop is a black box for me. So how does Apple do what it does? How could this company recover like a phoenix from the ashes? I admire Steve Jobs. He does magic on stage when showing Apple’s latest products. He has a strong personality and there are quite some stories floating around about his famous tantrums. So, how did this man turn around Apple? Well, to be honest I don’t believe that it was a one man show completely; however this one man is in the exact right position.
Let me explain how I see the role of Steve Jobs though Scrum glasses.
Each Scrum team consists of one ScrumMaster, a Team and one Product Owner. For larger projects you can have more Scrum Teams working together, which is called a Scrum of Scrums. A company wide Scrum of Scrums enables the company to do agile product portfolio management , which is crucial to overcome the stasis of annual plans. At the very top of those Scrum of Scrums, you have THE Product Owner, the over-Product Owner, the one person responsible for what gets developed in which order. Steve Jobs is exactly this person at Apple. Sure, he is CEO and has absolute power. However, in contrast to other CEOs which are too far removed from the details, Steve Jobs is exactly interested in these details. He had the whole iPhone redesigned because it had more than one button. He decides to accept or not to accept the products. He gives the acceptance criteria and he has to like what he sees or it does not see the light of the day.
To me this confirms that one of the most critical roles in a Scrum Team is the Product Owner. Sure, the best Product Owner with a lousy team will not succeed either, but a great team can only be on top of the game with a great Product Owner.
The success of a project depends on the Product Owner, its role but more importantly the person, and definitely NOT how good or detailed the requirements are. A good Product Owner enables the Team to rise above and make a great product the right way.

Tuesday, February 1, 2011

PSD (Java) Train the Trainer

From Jan 20th until 28th the first PSD (Java) Train the Trainer gathering took place. It was held in Sao Paulo/Brazil. The idea behind train the trainer is to horizontally scale up our effort to teach good and emergent coding practices to developers. With more trainers there is more exposure. Let’s cross the chasm!
The training was two-fold. First Giovanni Bassi from Lambda3 held a two day PSM class to reinforce the agile fundamentals of Scrum. The potential trainers are by no means new to Scrum, most of them are veterans with years of field experience. The PSM class helped to set a common foundation and understanding within the group. The following Monday the PSD class started. One week of four mini sprints, each one with sprint planning, development, daily scrums, review and retrospective (details). The idea is to communicate what real agile development using Scrum by applying XP practices feels like. I strongly believe that once a developer has drunk the Cool-Aid, they will always try to get that feeling back. There is no way back - they are addicted, addicted to best of breed development practices. The five days are laced with theoretical blocks to explain the underlying ideas and principles. So, it is a great mixture of hands on and theory.
In contrast to the PSD (.Net) course, the Java one is less tool focused and more on the craft. Our backlog management is done with paper on a pin board and bugs are handled through the backlog – no issue tracking system. All used software is open source. (Eclipse, SVN, Ant,Hudson, Cobertura, EclEmma, Mockito, …). A low tech story board with paper is still the most effective information radiator.
The students were great, throughout they were agile-savvy and smart people. It was fun to work with them and during late night discussions I had the chance to learn from them as well.
Brazil was the perfect setting for this training. There is a vibrant agile community and Lambda3 is a driving force. I am looking forward to see more inovation coming from this part of the word. Globalcode was an excellent host and very forthcoming.
We named ourselves the Boi Tátá Team. (Boi Tátá is a mythical Brazilian creature)
There will be more PSD (Java) Train the Trainers. If you are interested please get in contact with Scrum.org.

Tuesday, November 23, 2010

Splitting CRUD stories

Two of my colleagues came across a CRUD (Create / Read / Update / Delete) story, and asked me for advice on how to convince people on splitting stories.

I typically prefer to have smaller stories. In this case, instead of having one CRUD story, I would have one for Read, another for Create/Update and a story for Delete.

Here is an example.

As a online store owner, I want to Create / Read / Update / Delete products so that I can offer my customers the top rated products

Instead of having this CRUD story, I split it like this (I will add a few sample tasks for making it more illustrative):

As a online store owner, I want to Read (view) my products so that I can review what is current available on my site

Sample tasks:

  • Create DB table
  • Populate table with a few sample data
  • Create select DB script
  • Create for viewing my products
  • Create automated functional tests for viewing functionality

As a online store owner, I want to Create / Update a product so that I can offer my customers the top rated products

Sample tasks:

  • Create insert / update DB script
  • Create UI for create / update a product
  • Create automated functional tests for adding product functionality
  • Create automated functional tests for updating product functionality

As a online store owner, I want to Delete a product so that I can offer my customers the top rated products

Sample tasks:

Create DB table for deleted products

  • Create delete DB operation
  • Create UI for deleting a product
  • Create automated functional tests for the delete functionality

This sample is very specific for CRUD stories. There are other ways for splitting stories.

Mike Cohn's book, User Stories Applied is a must read on this subject.

Splitting (or deciding the size of a story) is controversial. Mike Cohn have popularized the INVEST acronym: Independent. Negotiable. Valuable. Estimatable. Sized appropriately. Testable

agree with the S in the acronym listed above: Sized appropriately.

But when I first read the INVEST acronym, the S was for small. I know Sized appropriately is not very specific, but it is more realistic. It is not about being small; it is about being sized appropriately. For this consider several reasoning on splitting your stories. The links below have more on this subject:

http://lassekoskela.com/thoughts/7/ways-to-split-user-stories/

http://agilecoach.typepad.com/agile-coaching/2010/09/ideas-for-slicing-user-stories.html

http://xp123.com/xplor/xp0512/index.shtml

Agile Vale 2010

Last week I presented and participated at Agile Vale 2010, the first Agile event on ITA, Sao Jose dos Campos.

The event gathered 300 people including organizers, speakers and attendees (folks from local universities, industry, and near-by cities)


My presentation on story board and visualizing SW development workflow was great. It was a one hour presentation with many Agile concepts depicted as story board’ cards movements.

I also participated on a round table on Agile SW developemnt. Eduardo Guerra (ITA) was the facilitator; the participants were: Felipe Rodrigues (Lambda3), Rodrigo Yoshima (Aspercom), Fabiano Milani (AdaptIdeas), Paulo Caroli (ThoughtWorks Brasil), Juan Esteban Bernabó (Teamware).

Overall it was a great event. The attendees, organizers, and the speakers were all very excited at the end of the event.

It was nice to participate on a great Agile event in such a prestigious college—ITA.

Tuesday, November 9, 2010

Don't shoot the messenger

In ancient times, it was not uncommon to kill the bearer of bad news. It was a matter of principle. "Don’t bring me bad news. And by the way, don’t fail with your efforts." Luckily, in these days, the worst that could happen to you is to be fired – not much better in the current economy but, hey, who complains. However, still too many projects or companies are run in exactly that very way.
How does this fit together with Scrum? Not at all! Scrum is built on three legs. Transparency, Inspection and Adaption. It is the Transparency part which is in conflict by not being able to tell the truth, the naked truth. All software projects will encounter problems and are predictable only within a short planning horizon. Most non-trivial software projects belong to the complex category according to the Cynefin framework. Complex projects cannot be managed by a defined approach but require an empirical process. It is the empirical approach that is based on Transparency, Inspection and Adaption. Empiricism wants feedback; this is why Scrum has Sprints, Daily Scrum, Review and Retrospective. They are the empirical process controls. They provide feedback about the product under development, the progress and the process. All of them are subject to change when appropriate. Inspect and Adapt!
Now, imagine a company which is run top down military style. You get your orders, don’t dare to even question them and then report back. Your reports are checked against the minutiae defined plan, often a Gantt chart. You cross your fingers that you will not be the first one to bring down the plan. You know what happens to the bearer of bad news! This is a very toxic environment for any kind of agile change effort. The moment you discover or run into some serious situations people tend to loose their ability to speak up. The situation becomes a problem and looses its opportunity for improvement. Forget all about Adaption and improvement. In short, the whole effort is futile.
A successful Scrum introduction needs an open management. A management that can let go of being in control and is able to change from
Command and Control to Leadership and Collaboration
This is the most challenging part for management. Essentially they need to make themselves obsolete and become servant leaders to their teams [1]. Until this happens, it is my job as external Scrum Coach and Change Agent to shield the teams I am working with. At the beginning of a Scrum introduction, it is much easier for the teams and the management if I - as the Coach - am the one stepping up, telling how things really are and even taking the fall out. It is not always fun but it is very rewarding as it builds up the trust between the Scrum Team and myself. The individuals on the client might risk their careers; but myself, in the worst case, I only get shown the door. I am a paid sacrificial lamb.
I am a European who has worked in Germany, France, England, USA and now Switzerland all along my career and based on my experience, I am sorry to admit that there is something about the term ‘Old Europe’. In continental Europe, there seems to be a lot of rigid top down hierarchies, still. Maybe this is the reason why the agile adoption takes longer to get going over here. However, I am happy to see dramatic changes this very past year.
Give me a call if I could be of help to you or your company.
[1] Dan Pink, Drive, Kindle Location 1275, […] Autonomy over task has long been critical to their ability to create. And good leaders (as opposed to competent ‘managers’) understand this in their bones. […]

Monday, November 1, 2010

Thoughtworks Brazil at the Agile Tour

I am really proud that Thoughtworks Brazil participated on 3 great Agile Tour events held in Brazil this year: ­­Carlos Vilela presented at Agile Tour Sao Paulo, Paulo Caroli at Recife, and Pedro Pimentel at Rio de Janeiro.

And it all happened before celebrating Thoughtworks Brazil first year anniversary (coming soon in December)!

I am looking forward for Agile Tour 2011. In fact, not only Agile Tour, but all the events encouraging communication, collaboration, and sharing experiences.