Aug
29

Agile 2010 session materials online

I co-presented three sessions at Agile 2010. The materials for these sessions are now available:

I hope you enjoyed the session or get some useful ideas from the session materials. Let us know how you’ve applied these tools.

Jun
07

Agile 2010

I’ll co-present three sessions at this year’s Agile 2010 conference on August 9-13 in Orlando, Florida:

  • In “Pinocchio, On Becoming a Lean Leader” (Tuesday August 10, 13:30-15:00) Portia Tung and I help participants along the dangerous journey from toy boy to real boy. You’ll meet all your favourite characters from this Agile Fairytale and come away with some concrete actions to become a better leader.
  • Agreeing on Business Value using Systems Thinking” (Wednesday August 11, 09:00-10:30) is a workshop where Portia Tung and I help participants come up with a “Business Value Model” for their current project. You’ll be able to use the Business Value Model to identify the high value solutions that satisfy your customers. The number of places for this workshop will be strictly limited to 20.
  • Estimation Games” (Thursday August 12, 13:30-15:00) gives participants some rules of thumb to create reliable estimates with little effort. During the session we’ll play some small estimation games to put the lessons into practice. You need never be afraid again of estimating.

If you want to know more…

May
27

Journée Agile Belgique 2010

Je présenterai deux sessions à la conférence Journée Agile 2010 à Gosselies (près de Charleroi), Belgique ce 16 juin.

C’est la première édition de cette conférence et aussi la première conférence francophone sur l’agilité en Belgique.

“Les Boucles XP” est une introduction à la méthode Extreme Programming. Vera Peeters et moi avons créé cette présentation il y a longtemps pour donner un goût de la façon de travailler d’une équipe vraiment agile. A travers les pratiques et les exemples d’équipes avec qui nous avons travaillé depuis 1999, la présentation explique pourquoi cette méthode marche et comment procéder pour définir une méthode qui convient à votre équipe. Pour cela, il faut voir les choses comme un système où la valeur du tout est bien plus que la somme des valeurs des éléments.

“Agile + Business Analysis = Lean Projects” explique comment on peut combiner les techniques de Business Analysis avec ceux des méthodes Agiles pour “construire la bonne chose” et “construire de la bonne façon”. Le résultat: des projets vraiment “Lean”, de la demande du client jusqu’à la livraison. L’expérience nous a montré que cette combinaison nous a permis de livrer des projets en beaucoup moins de temps qu’auparavant et en même temps livrer un produit qui avait plus de valeur que prévu. Vous verrez quelques techniques que vous pourrez appliquer dès demain et des pistes pour en savoir plus.

A bientôt!

May
26

Agile France 2010

J’animerai deux sessions à la conférence Agile France 2010 à Paris ce 31 Mai.

“Définir la Valeur Métier avec le Systems Thinking” est un atélier où on utilisera quelques techniques de Systems Thinking pour définir la “Valeur Métier” des projets des participants. Pourquoi? Parce qu’une définition de la valeur métier est le premier pas pour vraiment se focaliser sur ce qui est important. La “valeur métier” n’est pas un concept nébuleux. C’est un outil dont l’équipe se sert tout le temps. On applique le principe du “project economic framework” qui est décrit dans “The Principles of Product Development Flow: Second Generation Lean Product Development” de Don Reinertsen. Après cette session vous aurez plein d’idées pour prendre des décisions produit qui rapportent plus ET prennent moins de temps. Le nombre de places sera (strictement) limité à 20 personnes.

“Les jeux de l’estimation” vous aideront de mieux répondre aux demandes d’estimations “parfaites”. Cette session est une combination de présentation avec des petits jeux dans lesquels vous pouvez mettre en pratique les astuces présentés. Après cette session, vous n’aurez plus peur de faire des estimations. Vous saurez faire des engagements fermes avec des estimations incertaines. Si vous avez à faire avec des estimations ou engagements, vous vous devez de lire “Software Estimation: Demystifying the Black Art” de Steve McConnell.

A bientôt au Chalet de la Porte Jaune!

Si vous voulez en savoir plus…

May
02

XP.BE User group meeting: Agile + Business Analysis = ?

XP user group event 05/05/2010

iLean will host the next XP user group event on May 5th 2010, in Kontich.

What can Business Analysis and Agile mean for each other?

The International Institute of Business Analysis (IIBA) has created the Business Analysis Body of Knowledge (BABoK) to capture the experience of business analysts worldwide on a wide set of projects. According to the BABoK, “Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

Meanwhile, Agile methods, with their own methods of understanding needs and proposing solutions, have been sweeping through many companies.

Is there room for business analysis on Agile projects? Can agile teams learn from business analysts? What happens when business analysts work in Agile teams?

The IIBA has started up a workgroup to create an “Agile extension” to the BABoK. This extension will provide practical guidance to do business analysis in Agile projects, based on experience. We’ll present this effort so that both communities can review and contribute to this project.

If you want to participate in the discussion, join the Agile BA Yahoo group.

Register for this free event on the Belgian XP Group wiki.

Why Agile + Business Analysis?

Why am I interested in seeing the Agile and Business Analysis communities collaborate?

Business Analysts could learn something:

  • You don’t have to specify everything upfront. You can deliver your analysis incrementally and iteratively, at the pace it’s consumed by the implementation team(s), prioritized by value and risk.
  • You don’t have to specify everything in consistently excruciating detail. You can ask your team mates what information they need and only provide just enough detail, depending on how risky the topics are.
  • You don’t have to do everything alone. You can coach other team members to apply business analysis techniques.
  • You don’t have to specify things before the project starts and move on to the next project before you see the results. You can be a full member of the team that delivers value and participate in the release parties.
  • You don’t have to be an intermediary (or worse, a “Shuttle Diplomat“) between “The Business” and “IT”. You can be a facilitator who brings out the best in the whole team.

Agile teams could learn something:

  • You don’t have to invent “Business Value”. Business Analysis can help you link the benefits the organisation expects to the capabilities it needs.
  • You don’t have to create a “Vomit of User Stories” and spend an inordinate amount of time “grooming” that backlog. Business Analysis can help you to focus on the value-adding capabilities.
  • You don’t have to make the giant leap from organisational goals to detailed user stories in one go. Business Analysis provides many techniques to gradually break down large problems.
  • You don’t have to limit yourself to User Stories. Business Analysis provides may other ways of modeling what users and stakeholders need.
  • You don’t have to go it alone as Product Owner or Onsite Customer. Business Analysts and business analysis techniques can help you get the job done, identify more value and work at a sustainable pace.

I’ve been applying business analysis techniques since my first agile project in 1999 (although we didn’t call it business analysis then). The results:

  • Our projects were smaller, cheaper and delivered faster than those of the competitors.
  • By focusing on the few high value delivering features, we were able to release incrementally, thereby generating real value quickly for the customer.
  • By focusing on what was really needed, not what was wanted, our systems were smaller, easier to understand and easier to maintain.
  • By using simple but effective business analysis techniques the cycle time from request to proposal was dramatically shorter than our competitors’.
  • By having everyone in the team working on the business analysis we often came up with innovative solutions and delighted our customers. How often do your customers tell you “Wow! I didn’t know you could do that!” ?

It’s not enough to appoint someone to be the “Product Owner” and expect to become a productive team. More likely, you’ll end up with a burnt out Product Owner. First of all, you should give effective tools to your Product Owner. Secondly, you shouldn’t build such a bottleneck into your team; provide your whole team with those tools. I know in which community you can find many such effective tools…