Retrospective Activity; I do not settle with only one

I have been running retrospective activities for a long time. I really like retrospective activities.

Interesting enough, I have not married with one activity. I try new activities. I brag to my friends about the latest one. Many times I repeat old ones. But I do not settle with only one.

 I look around. And I find people that also like many retrospective activities. I also find people that did  settle with one activity (well / less well seems to be the most married type).  They seem happy with the the same routine.

For the ones who like varying retrospective activities, check out the Agile Retro Activities catalog.

Agile Testing Days 2012 - Take Away

Last week I’ve attended the Agile Testing Days 2012 Conference in Potsdam, Germany. It has been a great conference with great talks from various well known thought leaders. I for myself was invited to talk about  'Sprint Backlog in ATDD’.

Every conference has its take away the one thing you take home nagging your mind. For me it was the talk from Gojko ‘Reinventing Software Quality’.

Here my current take away:

1. Measurement

We/business usually measure the wrong thing. In his example he took his book 'Specification by Example’. In the print he found over 20 P1 bugs like sentence cut off, over 70 P2 bugs and so on. So he was very upset with the printing house which allowed the bad quality. However, in the end it has a five star review at Amazon. The errors did not matter as the final product still provided excellent value to the end user. His understanding of quality was different then the readers ones.  

(source: amazon.com)

2. The third Wheel

Gojko’s lesson learned was that we should aim to create the right high quality product but that this is only the beginning. With the two wheels of Sprints and Daily work we only address our internal point of view. We need to make sure that we have delighted customers who are willing to pay for our product and like to use it. 

Therefore we need to add a third wheel powering the other two - the business measuring the satisfaction of the end user.

In my opinion, this is were we will see a future connection between requirements engineering and idea behind ‘The Lean Startup’ of  Eric Ries.

This is also in alignment with the quote (can’t remember the exact words) from Jim Highsmith where he challenges business: If you want us (development) to measure our productivity you (business) need to measure the benefit for the company. 

(source: Gojko Adzic)

3. Agile Testing Quadrants

I am a big fan of the Agile Testing Quadrants which were first described by Brian Marick in 2003 and became famous through the ‘Agile Testing’ book of Lisa Crispin and Janet Gregory. 

The quadrants Q3 and Q4 which are described as to ‘Critique the Product’ are in Gojkos mind wrong as they are still in house before the product hits the market. Essentially we test our process and not the product. We test the adherence to the agile requirements, not how satisfied our customers are. In this regard it should be renamed ‘Critique Process’.

(source: Brian Marick)

How could we then integrate the ‘Critique Product’ testing? I had a great talk with Janet Gregory about how this could be visualized but there is nothing firm yet. We talked about various add-ons and shapes. 

Final thought

For me the circle from Agile to Business and Business to Agile is slowly starting to close - the time to merge management and development has the chance of becoming reality.

I for myself, will dive straight into learning and using Impact Mapping ....

an awesome presentation on usability testing

Usability Testing Intro from Erica Burnett

A really cool presentation on retrospectives

Guilherme Lacerda gave a really good presentation on retrospective at Agiles 2012.

The Power of Retrospectives from FACENSA, UniRitter, Wildtech

It has some really cool activities, and great references. I will definitely add some of it to the Agile RetrospectiveActivities blog.

AgileDay at Porto Alegre

Porto Alegre has an amazing Agile community. Many of the Agile people in Brazil live in this city.

The GUMA AgileDay is a clear indication of this high concentration of Agilistas.

Tomorrow, 200 hundred people will get together to talk about Agile. Many of hte sessions are a replay of the AgileBrazil 2012 sessions.

Gladly, tomorrow I will be joining the presenters and will repeat the workshop on Agile RetrospectiveActivities.

 

Checklist: the Story is Ready for Development

Here is a simple check list for verifying a Story is ready for development. 

• I have considered the high level design change for this story
• I know the code area which need to be modified / created for this story
• I have thought and considered the flow changes introduced by this story
• I have looked at the existing test automation for the current flow/behavior (as is)
• I have thought and described how I will validate the flow/behavior changes introduced by this story (to be)
• I understood all the current acceptance criteria (ACs) for this Story
• I am happy with the current ACs for this Story  (I don’t see the need to create a new or remove any of the ACs for thÌs story)
• I thought about it, and I believe this story should not be split into smaller pieces
• I thought about it, and I believe this story should not be merged with another one

A missing checked item will trigger a Story huddle, and the story will not be considered ready for development.

Enterprise Team Spike

When faced with new technology or other not well understood programming problems we like to implement a spike. What is a spike? I like the definition from  

http://www.extremeprogramming.org/rules/spike.html

Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only address the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate.

Well, this spike is of technical nature and does an excellent job to mitigate technical risk. However, I am suggestion another type of spike:

Enterprise Team Spike

What do I mean with Enterprise Team Spike? Before answering this, let’s look at why a spike is a good thing. In my opinion it sheds light on dependencies, weak spots and all other kind of problems. During this discovery process it creates a possible path and provides alternatives. It mostly generates knowledge of how to solve the problem in the given context. So, it is all about generating information and to extract knowledge. How could information and knowledge help us in an enterprise team spike? In Scrum we favor cross-functional teams featuring all skills needed to deliver a done, high quality product increment at the end of the Sprint. Sounds good and works even better when we really do have a cross-functional team. The reality is that too often we have external dependencies to other systems. In large enterprises this could be an ERP, CMS or any other back end system. Typically, those departments we are depending on aren’t working in iterations and increments but with one or two releases a year in a strict serial defined process. In short we cannot be really be done at the end of the Sprint unless it coincides with a release of such a department (and their deliverable actually works out of the  box).

An enterprise team spike is not of technical nature but addresses the team's skill composition. In an enterprise team spike we identify all the skills we need from the very top to the very bottom and aggregate these into our development team. I am sure that once you start to pull this thread all the way out you will discover far more dependencies and skills than you actually thought possible. Once you have this knowledge we can start the HR game in order to get the right people into our team. In my experience this is the biggest problem as we fight existing company structures and believe systems, and worse, attack long established empires within the corporate empire.

It will be a long battle, but once you have the enterprise team spike in place you have a proof of concept that shows how to generate value quickly and reliably. 

In contrast to the technical spike, this spike is absolutely of production quality and must not be thrown away! 

Agile retrospective activities presentation given at AgileBrazil 2012

Here are the slides I used on the Agile Retrospective Activities workshop on the Agile Brazil 2012 conference.

I will be adding all the activities on this deck (and many more) to the following site: http://agileretroactivities.blogspot.com

Please note that these slides were not intended for sharing or reading. The site should be a much better place for looking for agile retrospective activities ideas.

Agile Brazil 2012

Another great Agile Brazil! This year, the main Agile conference on South America happened in São Paulo, from September 4^th-7 ^th.

Agile Brazil is the most relevant conference regarding Agile Development Methodologies in Brazil and it is driven by the Agile community leaders from all regions of the country, sharing the same goal: foster and spread the Agile culture.

Aiming to be the largest community driven conference in the whole Southern Hemisphere, the organizers put together relevant leading companies and experienced Agile professionals in the Brazilian market, plus some of the most skilled agile practitioners. Participants had the opportunity of sharing and deepening their knowledge through courses, lectures, workshops, case studies, debates, and much more!

My special thanks to Thoughtworks for organizing and fostering so many co-workers to get together in such great environment! These were the TWers presenting at the conference this year: Aaron Erickson, Camilo Ribeiro, Carlos Palhares, Danilo Sato, EduardoFayh,  Fernando Freire, Fernando Kakimoto, Fotina K., Gabriel Notari, Guilherme Prestes, Guilherme Motta, Jenny Wong, Hugo Corbucci, Ivayr Netto, Juliana Dornelles, Julio Maia, Mozair Carmo, Neal Ford, Paulo Caroli, and Sunil Mundra.

Multitasking vs a 100% Commitment

I recorded a small webcast to visualize the difference between multitasking and a 100% commitment and how this can lead to functional releases - essentially to being agile!

Enjoy,
Ralph
effective agile.

Firefox OS hackday at Thoughtworks Porto Alegre

Last Saturday Thoughtworks Porto Alegre hosted the awesome Firefox OS device hack day!

The day ended with 6 demos and 10 new technical documents about apps published in Portuguese

Here is a really cool app created during the hackday:

https://developer.mozilla.org/en-US/demos/detail/run-little-boy-run

Here are a few photos from the day:

 Here is the invitation for hte event:

"Join us in Porto Alegre for a great day of open web hacking at ThoughtWorks. Come build HTML5 web apps for the Firefox OS device or help localize web documentation for MDN (Mozilla Developer Network) at a day-long event on Saturday, September 1, starting at 9:30 am.

Meet web developers working on Firefox OS and developer tools, Open docs experts and local community members. We'll open with a short introduction Firefox OS, the Apps platform and the latest tools for apps developers.

Most of the day will be hands-on. We'll show you how to start building apps for Firefox OS and the Open Web, then hackers will hack and writers will write. We hope you'll share your projects at the end of the day. Food will be served.

BrazilJS attendees are invited to stay in Porto Alegre an extra day to attend. But you don't have to be at BrazilJS to register. Just sign up here so we'll plenty of refreshments: light breakfast, lunch and snacks - free for everyone. 

Schedule:

• 09:30 AM: Breakfast & Coffee
• 10:00 AM: Welcome, Brendan Eich
• 10:15-10:45 AM: Introduction to Firefox OS & Apps, Fabio Magnoni
• 10:45 - 11:15 AM : Apps are boring, games are fun, Matthew MacPherson
• 11:15 - 11:45 AM : Intro to MDN & localization, Janet Swisher
• 11:45- 12:15 PM: W3C Decoders, Yasodara Cordova & Reinaldo Ferraz
• Let the hacking begin!
• 13:30 PM Lunch
• 16:00 PM: Snacking & hacking | Coffee break
• 17:30 PM: W3C Decoders winners' demo & project demos (5 min each)"