Agile Thoughts and Things

The SCRUM Master and The Manager , A Team Story

2012-02-05T03:05:00.000-08:00

Change Organisations Challenges People Positions And Redefines Missions

Every "transformation" of current status toward a "target" one is a challenge to be taken seriously. The "Toward Agile" one is even more difficult , as it demands commitment to collaborate, respect , focus on a "collective owned goal" and the courage to trust team members .

All these above are a rather difficult cha

llenges to be met , and on the road legitimate questions may be asked :" Given the current references of a regular organisation , where am I heading on?"

This question will s

plit in a set if more role-focused questions, and the one addressed in this post is the one that is asked at the beginning of an Agile Journey :

"What is the difference between the Scrum Master and the Project Manager ? Actually, can these 2 roles be completed by the same person?"

The Temptation of Easy Patterns

Human brain l

ove mental patterns .They are a good effectiveness practice. That’s why many organisations may do a quick shortcut saying Scrum Master is a new kind of boss and we better put our experienced bosses ( Team Managers, Project Managers, other middle managers) in that role. Other organisations get solely puzzled about the question “ What is the difference bet

ween the Scrum Master and the Manager” ? If they are not the same, who Is the SCRUM Master ? And what does the Manager do?

Sport Teams , SCRUM Teams

Sport teams are often used as a good parallel to create Agile team spirit. Let’s do a parallel between sport team members and sport team managers .

The Team Captain and The Team Manager

The Team Ca

ptain and the Team Manager:would anyone consider these two people to will fulfill the same role at the time ? If no, let’s think why is what that obvious ? The difference between the Scrum Master and the Ma

nager in Scrum teams should equally obvious for the very same reasons. These 2 roles have pretty much the same profile in Agile teams .

Scrum Master, Team Captain

Let's follow this pattern: A SCRUM Master, as a Team Captain

MUST

Facilitate collaboration between team members

Ensure Commitment of the team

Ensure that team deliver a Quality Game (Code)

SHOULD

Look-up on Test Coverage

Facilitate Planning Poker

COULD

Facilitate the Inrospection of former Games '( Retrospective)

Interact with the StakeHolders ( as Team Sponsors, team managers)

Host the Demo (Play !)

Have priviledged Interactions with the team owner ( Product Owner)

Project Manager, Team Manager

n the same pattern for Project Manager, like a Team Manager

MUST

Interact with the Stakeholders

Ensure ressources are available ( search the foundlings)

Coordinate with other projects

Share the global objectives

SHOULD

Report to stakeholders

Encourage team

Remove impediments

COULD

Participate to (some) Scrum Ceremonies

In my former SCRUM training session, I had a very involved discussion about the mission of Project Manager in an Agile Product focused set-up with one of the participants that thought that Project Manager and Scrum master may be the same.

The Project Manager set objectives and ensure that all conditions to meet these objectives are fulfilled, while leaving the team to self-organize . The virtue and the benefit of this re-positioning allows the Project Manager to focus on "Management" rather that "directive execution".

The Scrum Master is a player , coordinating the "sprint game" from the field and leading "his team" to the "ultimate goal".

As a conclusion of our discussion , the day after , he told me :" I think you are right, and I just lost my job!" .

"Which job is that ?", I asked.

"The SCRUM master one" , he answered.

I dedicate this post to him . I'm sure he'll do a great Agile Manager :)

Photo Credits for Liverpool football team Captain and Owner to "The Guardian"

The Product Owner as Agile Transformation Ignition Agent

2012-01-13T02:47:00.000-08:00

Scrum as part of Agile

Some Agile experts are predicting SCRUM is "has-been" and are seeking new Agile answers. There are many. If we follow the Agile values as stated in the Agile Manifesto saying "hello" to all your colleges in the morning is a valuable answer. under this perspective , SCRUM stays a great answer for building Agile teams.

SCRUM designed for effective business solutions

Now, that had been said, let's think a little who is SCRUM meant for ? Again , Agile Manifesto says Agile purpose is to build "working useful software fast" . Who would you expect will have the highest sensitivity of this purpose if not business represented by the Product Owner ?

Under these circumstances , I would say that we should't even "dare" to start an Agile transformation without involving the business . Transformations have few chances to last if you try to make them for "THE PEOPLE" instead of with " THE PEOPLE" .

Transformation golden rule

Design the best thing for someone ( may that be an organization) is not a win plan. Someone told me a long time ago, "don't think of behalf of others, they can effectively think for themselves". That is so true, that I'd like to state this as a golden rule :

"Instead of building for [users] , build with [users] "

and it's platinum corollary

" Start Agile Transformation with Agile main beneficiary which are business people".
Applying this golden rule does not mean we're all good for success. Buy-in from business people is still required and may still not be easy to achieve.

One tip to get transformation Agents ready to go

The approach we choosed was to build an Agile training with the trainees representatives, still need to mind the gap between the expectation and what people "have been told to do" and a new collaborative building approach. It may create a lot of confusions.

We presented our "lessons learned " about starting AGile Transformation with POs at Agile Tour 2011 in Paris. The presentation is here (in French for the moment )

Continous Delivery, The Software on Fast Lanes

2011-12-13T12:10:00.000-08:00

I'm working around the Continuous Delivery topic. I have to confess that the group and myself struggled a little bit around with little success to explain simply what Continuous Delivery is if that's what we aim for.
But after "throwing the copy" a couple of times , we might have done it.

Building pass-through badges instead of Defining Checklists

I confess I was never very happy with the Definition of Done term and approach. I assisted on long-lasting discussions about what Definition of Done and Done-Done ...and then Done-Done-Done. And so forth. At the end ( if there was one) of these discussions the definition of " even more Done that ever" has a lot of chances to be unachievable . That's why focusing of the ideal Done is a nice example of waste. From a pragmatic point of view , Done should be what ever is meaningful for a team to ma
ke the stream of software go further and add value. Whatever works.

That was before I dived into Continuous Delivery mindset. Because from the Continuous Delivery perspective, I realized that is far more effective to create a mode of "driving through the flow" in attaching to your executable application a "pass-through" that embeds all the requirements to pass a toll-gate ( sprint validation, release delivery, etc) rather than creating checklists.

Checklists needs to be checked. That's a source of "flow jam" and encourages a "silos" mindset :
"I have done my job, and now I PUSH it to you to check it".
Not very involving, not team oriented. Saying that , I realized also that "pull models flow" are not only more effective than ""push ones ( as Kanbans says) , but also encourage team spirit.
Just think : Building a "pass-through" is an achievement were everyone is involved. Not checklists.
If "Definition of Done" is a checklist that DoD is an Agile impediment. If you're keen on this notion, then an Agile "Definition of Done" is a pass-through badge.**

Building Fast Lanes instead of Checkpoints

Unfortunately, a lot of Agile projects remain today agile development oriented. With a waterfall start and a waterfall Go To Production. There are a lot of good reasons. The most important one is , I would

say, legacy and current organizations that are waterfall oriented. It wouldn't be respectful not to consider this reality.
Beyond this , we stick to known models that install checkpoints when someone takes her time to approve. More things she has to approve, later software will be delivered. Longer is the checklist to be checked , later the software will be delivered. More checkpoints need to be passed, later the software will be delivered.
So if we remain in a "checkpoint" mindset , we fail to align to Agile principles , that focus on delivering fast incremental value.
Continuous Delivery is not about Agile. But Agile cannot work effectively without Continuous Delivery.
Continuous Delivery asks teams and software delivery stakeholders to adopt the fast lane model.
Our common goal as an organization is to build fast lanes with automatic toll-gates where software application can pass if they have a right pass.
Our responsibility is to agree on what those toll-gates mean and what is the right badge. Then let software flow. Let people do some added value activity rather than sit in checkpoints.

Continuous Delivery , A Simple Definition

After saying all this , I remember having tried hard to explain simply what Continuous Delivery is about without success. Now I'm quite happy about this one

" Continuous Delivery is a pull flow where fast Lanes for Delivery are build and Delivered Software has a pass-through badge attached that allows it to pass on the Fast Lane instead of presenting a Checklist on a Checkpoint."

Some SCRUM cooking receipts : User Story Syntax(es)

2011-11-15T22:33:00.000-08:00

Credits to antarcticstation.org

I'm practicing Agile since a while now. During my Agile and Scrum cooker experience I gathered or changed some SCRUM recepies and I realize that I never posted any of them. The time has come to do so here I start my Scrum cook book. And yes ther are more brighter cooks that myself and brilliant books. Yet , as in real cooking, anyone can "post" their own "how-to" a flavored lemon cake. So here I go for my own "cook book" :

User Story Syntax

The User Story "User Driven" driven syntax of :

"As user I want to do action in order to goal"

is extremely popular. And very effective of course. That's why is so popular. When I first "discovered" BDD like I embraced this with a lot of enthusiasm.

Yet, some alternatives to step out from user perspective might be useful. Here are my preferred alternatives.

The "Stakeholder Story" syntax

"As stakeholder I need that user does action to obtain value"
I like to use this when Product Owner struggles to find the real business value . Simply writhing this on a paper board unblocks some thinking lockers.
Rather that asking your stakeholders to provide you a set of complex (more or less reliable documents ) you may involve them in user story writing in the "stakeholder" mode.

A good example of the stakeholder syntax is when you might have "user stories for operations".
Operations stakeholders can write the "monitoring user stories" for you.

The "Data Story" syntax

"As Analyst Stakeholder I need application to provide data"

This type of user-story is aimed to capture the non-interactive parts of your software, as not all user interactions may automatically "log" some data to be analyzed.
It mainly captures the stories that will archive data that we won't know how to process in a short term.
Why the "Data Story" is not a "Stakeholder story" ? Well ,it is ! Anyway, I would tend to find more effective to "declare passive stories" as we may not naturally consider this type of features if they are not underlined by this type of the syntax.

Cook your user stories for test !

A lot of Agilists know that , yet I would like to remember it once more :
User Stories are user experience package : behavior and examples of that behavior. Never forget the examples . That is the best way to acquire a solid common understanding.
You may call that ATDD or TDR , and so on. The most illustrating approach for me iis still the "Feature Injection" The last think I'd like to underline is the link you may never forget between your user story syntax and associated acceptance tests. If you use BDD for your tests ( as I strongly advise you to do ) , you may apply the following pattern.

As User /"Given" I need to do Action/"Given behavior; When" to obtain Goal /"Then"If you check this pattern with your "BDD - test by examples " you may acquire a pretty clear view of what is needed to be implemented, and what it will make your Product Owner happy .
So , at this pointy of implementing your user stories receipt, don't forget to ask your favorite Product Owner :
"Why won't you gine me an example?"
(e.g. if she tells you that the user story is "As a user I need to click on a button and have a comparison of all the data ", try this question and see how it works ...)

Thanks

I would like to thank Lisa Crispin, Chris Matts , Gojko Adzic and Liz Keogh for being a source of inspiration since several years.

Disclaimer

Receipts don't make people "chefs ". You need a lot more that good or bad receipts for that.

Be Agile, from Readiness to Awakening

2011-10-20T14:35:00.000-07:00

Are we ready to act Agile?

A couple of weeks ago I had a wonderful discussion about Agile Transformation and how organizations that are anchored in a given pattern can go Agile. This discussion pointed out a challenging question "What (the hell) does Agile Readiness (really) mean ? Does "I want to "Go 4 Agile" is enough for my organization to succeed? If not, what do I need more? Some goodies printed with the "energizing slogan" :GO 4 AGILE" ? Refer to Senior management willing to embrace Agile?
Even if I consider hanging-out a lot in the Agile world, I still don't have a sharp reassuring answer.

While our own good will and senior management support create good premises, this is not enough for the "Agile Ready" diagnostic.

The shape of "Agile Ready"

Agile is a mindset, and the story start there. A group ( that may be called a community, an organization or a prject) strong links are build over the logic of

Values over principles.
Principles over practices.
Practices over tools.

My personal Eureka
While thinking this I think I found the answer to my seek of Agile Readiness. An organization that is "Ready 4 Agile" is able to first recognize, then share, Agile values.

Agile Awakening and Agile Awareness
Recognizing Agile values is an important event. Make a list ( on a bullet point style would be perfect, thank you!) of the Agile values and tell a group that from now on they are meant to observe them is , most of the time, ineffective. The group has to identify their values . And set the stage.
If those values are aligned with Agile then fine. If not, fine. But there is a pretty good indicator of how much a group is willing to be Agile.

The "readiness" bit is still not there. It will (maybe) come when sharing these values is effective.
By example , if managers in this organization ask themselves on a regular basis ?

"Do we still have the courage to trust our teams?"

Coach Retreat ?

2011-09-21T00:25:00.000-07:00

Coach-retreat : the ideas exchange platform, twitter, of course

Yesterday, while twitting around, I found a great idea that Yves Hanoulle launched : What about doing coach retreats on the model of code retreats ? Yves tried it , but his feed-back says it was too much as a Coach Camp.
The idea of improving as a coach, using the code retreat framework of "persisting by repeat and change techniques " to handle a "problem" sounds great. So here I am trying to sort it out.

Coaching DoJo and Coach Retreat : the difference ?

Rachel Davies has put in place a wonderful model about Coachin DoJos. I used it several times and it works wonderfully. The first difference between coaching DoJo and CoachRetreat is, of course, the time duration. But there is more, I think. Here is why :

Coaching DoJo

One stop session, it goes this way :
I have a problem ( kata) . A pair (or team) of coaches coach me - in a free coaching style way - to realize what are the issues/some solutions, etc. The observers give feed-back about the coaching style and suggest improvements. End of the session.

Coach Retreat

Lasts on a day long with time-boxed sessions focused on the same topic. It will go like this :

I have a problem/kata.

Coach team participate to solve/have more insights about it in a timeboxed period. Retrospect, evaluate the results.

Repeat : as in code retreat, let's say that we'll use some "specified" techniques ie "double loop learning" to go through the problem. Take the time box and do the coaching session. Retrospect/evaluate the results
Repeat : Use another time box and use other techniques. Retrospect and evaluate new findings.
Repeat ...

What type of coach are you at the end of the day ?

Ideas to put in place a Coach Retreat

Feed-backs about how this could be done and improved are more than welcomed :

What about bringing observers in coach retreat sessions ?
What are good coach retreat katas ( the equivalent of the "game of life" )?
What would be favorites techniques ?

ALE2011 Berlin : the fall of the wall

2011-09-11T15:52:00.000-07:00

I dedicate this post to Berlin. May history teach us to take our future seriously

Flashback walk

"You are leaving the American sector"

I was walking in Berlin the other night , and eventually Checkpoint Charlie was not far form the ALE2011 Venue. While crossing the street at "Checkpoint Charlie" , I realized that Berlin was a wonderful choice for its first edition. Best symbol of ALE as a network of values and skills, built beyond borders and other alliances, Berlin was chosen by a bunch of people that care about sharing ideas. The wisdom of the crowd, creating the doodle poll, came up with a surprising best answer . The wall of silos thinking was hit . The rest of the story is so wonderfully written by all the organizers fellows :Olaf , Marcin , Franck , Marc , Mike , Catia, Monika, and so many others.

Talks and other stuff : breaks through the wall

ALE 2011 Day 1 : Waiting for Participants

Going fast forward to arrive directly to September 7th, the opening of ALE2011. The strongest mindset of the unconference , was the will of sharing. "ALE2011, because we share" (credits to Carlo Beschi for the nice slogan) was well on track.
There were high quality talks about Lean and its Kanban surroundings. Karl Scotland recalled us that we are continuously hallucinating, so DON'T PANIC. Gaetano Mazzatti talked about measures that matter as "how many late work pizzas have you eaten lately" or "How long since...". Claudio Perrone made a masterful A3 thinking presentation, he is a great story teller. Unfortunately I missed the talk of Stephen Parry one of the most insightful Lean thinker. Fortunately, the slides of his presentation are posted here.
The question "where are the developers?" was raised. They were were there: Willem van der Ende, Stephan Eggermont presented smalltalk reinventing the future, and there was a courageous :) Open Session by Brian Marick , "A session for developers, with developers, about developers. I missed Monika Konieczny's session about creating a Super Hero's Team , but I took a smile with me and I feel (a little bit) better.
Thorsten Kalnin presented Wikispeed , building a Lean Scrum Kanban prized race car : an Agile mindset beyond borders.
I also missed a lot of the Open Space sessions, still I had a lot of fun discovering that I'm a lousy green dots sticker for the Kanban Dot Game proposed and beautifully facilitated by Jacopo Romei . I'm also honoured to have been a witness of the 21st century definition of failure as stated by Jon Jagger and Catia Oliveira :

"Failure is a success with a lower level of usefulness".

Participants lined-up for the lightning talks , and the audience enjoyed them as hell. Some of the strongest messages came out of these spontaneous or masterly prepared maximum 5 minutes talks. As for myself, among the things I know now that I have to do are bringing a cake to celebrate failures and check the buy-in of the mouth when starting to eat an Agile hamburger.

It is not that important how much you have to share , just share

The Spouse and kids Program : the wall is down
Children were at ALE2011. Thanks Ken Power for this refreshing idea . We, plain adults, had the opportunity to be inspired by children illustration of "Agile". They had so much fun playing Where Are Your Keys Fluency Game, that they exhausted all the languages available to learn in the room (well the Finnish kids were to young, we'll have to wait a couple of years before they can teach us Finnish). Chris Matts had the benefit of a Birthday Party in the middle of his presentation.

Photo by Chris Matts , unhappy presenter

Checkpoint Charlie, no longer needed

Walk through BranderburgenTor no longer forbidden

Ken has facilitated the 200 people retrospective and taught us how to bring the rain. ALE2011 is over . The only meaning of this sentence is that September 9th , 2011 is a past date. The energy of the people that were there is still in the air. New friends; ex-strangers said to each other "Good-bye, see you at ALE2012".
Olaf, Marcin, Franck, Marc are already updating the ALE2011 website. Vaidas Adamouskas has mentioned a beautiful take away for the next step : Go Beyond.
Alexey Krivinsky has already launched the challenge of new crazy ideas for the next conferences. ALE Network is formed by solid links and ALE people can "Go Beyond" freely back and forth. The wall is meaningless, and Checkpoint Charlie can be canceled.

I won't finish this post without mentioning Jurgen Appelo who is the very effective and efficient ( thanks Dave Snowden! ) lightener of the ALE Network, and supporting it in an environment without walls.

Agile Is Like Life : Goes On and Adapts

2011-08-27T06:53:00.000-07:00

Bârsana, Maramures, Romania
2011, August 5th

Agile And Reacting
This is not an Agile post. It is a post about the life as we live it. We actually have to be Agile to survive. And that's why Agile becomes more and more popular. Because it makes sense as Mother Nature does : here is a new information, a new event. What do we do ? we want it or not, we react and follow a survival logic.
Exactly as we do when we go "Agile": react to keep your project/organisation/product/team purpose safe. (Re)act accordingly. And gather all the forces to do that.

Agile and Planning

The need for planning is not really about the need to control. There are few people that deep inside themselves are persuaded that they are as powerful as Gods and deserve to be in control of everything because of that. Average people need to plan mainly for reassuring their safe space, more than to control broadly the environment they might have been designated as accountable for. Proving they are in control actually just enforces their safe zone.

I think the need for planning is far more about defining a way to reach our dreams. Or goals , if some of you prefer being less "emotional". Following a dream can be done if we define a path. Well, planning is that path, so planning is good.

So "Agile" - what am I talking about here? -mindset? needs and loves planning. For any Agile practitioner having a vision, a way and some tools to get there is very important. As a matter of fact, more important than in some other approaches.

Agile As Everyday Life

So what we've got here ? A dream, a plan, and the big wide world out there. The big wide world that might have no (or low) priority on your plans and dreams. The big wide world that has its own logic and can blast your plans or dreams, or even could put you in danger. So what we do then? We react and adapt (our plans and "plannings") to make our dreams survive. To ensure a safe environment for people depending on us. We are Agile. And we continue planning. And dreaming. And adapt our dreams. And trying hard to stay young and full of enthusiasm.

The assumption "in Agile nothing is predicted and planned, because in Agile we only react and change incessantly" is like admitting that we never aim to build a family because we constantly react to daily traffic jams. Or of potential accidents.or, on the contrary, admitting that people that aim to build a family just won't be able to react at traffic jams, if their plans were not "accurate" enough to forecast those in detail.

For the reasons above, Agile somehow helped me to go through difficult moments when adapting and dreaming is hard. That's why I'll try to keep going on "Agile". At least as I mean it.

Profiling an Agile Coach

2011-06-23T07:19:00.000-07:00

The workshop initiated by Luc Bizeul, about Agile Coach Charter : a very interesting, not less difficult topic that we discussed about recently.
I'm grateful to the group of people there for a couple of rich ideas that came out from the workshop.

Agile Coach Deontology

Caring about an Agile Coach deontology is very powerful concern. We did struggle to have some usable ideas about it and we may not still have something coherent, but the important thing is to start.
Here are ideas that seem important to me: from a coach chart perspective, the coach must take care not to create and exploit «addiction to coaching». She also should respect the data confidentiality of the team she coaches.
What is specific about Agile Coachig Deontology ? Ongoing reflection...

The cultural dimension of the Agile Coach Profile

It might seem obvious after having thought of... but the challenge is to ... have thought of. Like all simple brilliant ideas. You are just troubled that you didn't have them before by yourself.
The brilliant, obvious idea I'm mentioning here is that "coaching activity" has a different set-up in different cultures. Let's take an "easy" comparison:

American and European (zoomed of French) coach purposes
A coach as it is understood in American culture seem to have goals linked to the performance of the people that they're coaching. The definition I'm giving of performance in this context is "understanding and achieving the set of individual or team objectives in a manner that is recognized as effective par the involved parties".
While in France, a coach doesn't have any personal objectives set. There is no engagement of the coach of achieving any goal as a coach. On the contrary, a coach should be very "objective" about the people they are coaching. She helps people of achieving their goals and be more effective but she is not accountable for the results.

Is it a better way than another, I don't even know if that's a valuable question. What matters though, is being aware and deal with the differences. Even if the description of these are not exact in this post, the important thing is to be aware that different cultures may understand coaching deontology differently.

Agile Coach : a set of conflicting skills ?

Another powerful insight I’ve got from this session is that an Agile coach may find herself at a crossing of different skills , such as facilitator, mentor, consultant... While she has to use these skills at different moments in time , the eventually conflicting position may not be an issue. But is this always true?
For example, what if an Agile Coach should be facilitator and consultant at the same time ? «Involved» and «detached»? E.g. facilitating a retrospective for a team that just adopted Agile? Is letting the team go wherever it wants is the best outcome to have?

I’ll collect a list of eventually conflicting positions of an Agile Coach and I’ll get back on this blog. Would you help me do that? The linkedIn discussion about it goes here , if anyone want ti contribute.

Aka Haikku : The Hope of Improvement

2011-06-05T02:41:00.000-07:00

Motivation and Improvement

Did you observe that teams or individuals are actually happy and motivated when they identify ways of improvement and they have an "action list" to follow-up that improvement? The energy of initial motivation is sustained by the new ides (of improvement) that allow that motivation to stay high. Or even grow.
If, on the contrary, the motivation vacillates, the group or the individual won't have enough energy to commit to further improvement. That's the moment where external energy might be needed (as coaching), but that's another story. The point here is about caring of group's energy, motivation and ...hope.

Improvement and Hope
When a group gathers and stick together around a common purpose, there is mainly a lot of hope linked to that purpose. That is the initial energy. We mainly act in our life driven by our hopes of better. "Better" means improvement. So what I'd conclude here is that we are continuously seeking for improvement. That's what makes us move forward. That's what keeps energy high : "We have to do X and Y, and then it will be great." Or , even better : "We'll see what it X and Y give and we'll improve from there".
Higher the potential of improvement is identified, higher stays the energy in the group.
Because the hope is high. Somehow the "level of hope" is proportional with the "potential of improvement".

Hope and Perfection
If hope makes groups and individuals move forward, and "do better", perfection is and end point. A very stable state. A state where better is a nonsense. And that makes hope a nonsense also: "Where is perfection there is no more hope to have". It sounds a little bit scary, doesn't it? So that's I don't like perfection. It scares me off.

WAYK at ACCT11

2011-05-22T02:35:00.000-07:00

WAYK and Agile Coaching

At Agile Coach Camp in Italy that took place earlier in May, I proposed a session of Where Are Your Keys (WAYK) learning practice. I've participated at a session hosted by Diana Larsen at the RFG11 earlier in April. I was fascinated by the velocity of learning in repeating the same example. Also, the cohesion created in the "group of pupils" is kind of magica

There should be a link between the WAYK learning technique and teaching Agile practices. Presenting WAYK technique at Agile Coach Camp in Italy, was for me the first step to explore it.

The session

I'd like to thank all the participants to let the session happen, as at least eight people should be present in this kind of exercise. I would especially thank to Carlo Beschi for his involvement in the session, that made it successful. I found out that Carlo, an Agilist and a fan developer, studied semiotics at University so this might explain that.

The link among the members created by this repeated technique, is an extraordinary one and the magic worked once again. So I continue to be enchanted.
The reliability of the learning approach was so great, that the group started to correct me, as the exercise continued for a while and I started to get tired. This "sustain of the teacher by the pupils" was the most remarkable event I observed. The way that brain works to learn by example is so reliable that quickly "pupils" know how to adapt and correct unexpected input. So really and thoughtfully, "How fascinating!"

WAYK from languages to coaching

I'm still looking for an appropriate framework to apply WAYK in coaching techniques. I'm sure that there is a lot to get from it. For example, practicing a couple of techniques with a group without explaining upfront the benefits. The expected result of that would be that the group will become aware of the benefit of that practice directly by using it. Even better, it will "naturally" improve it as it actually gains ownership of these practices. Only a starter thought...

RGF11 : About Energy, Collaboration and Talent

2011-04-25T01:51:00.000-07:00

The Place : an environment for creativity
As usually RFG was organized in a place loaded with inspiration and enchantment. A remarkable point : it is the first lodge I visited in my adult life where there was no TV set. Neither in rooms or in the lobby.

The Open Space

Skillfully facilitated by Ainsley Niels. A place of quality reflection not of outrageous speed performance.

Collection of insights

More than session minutes, hints of ideas, buzwords and takeaways stay and matter. they create the knowledge load that you can be taken away, developed further and make ideas grow.Here is my RFG11 collection of takeaways.

Build retrospectives about the Future. They will allow you to re-align teams goals and vision, and value the current work .(Josef Sherer)
Include issues in your information radiator system. making a problem visible, may halp solve it.
Extraordinary pull approach of learning : WAYK, using children learning process by using similarity. Distinguish profiency from fluency : stay focused on what you need : be fluent in the level of profiency required bay a given context. And maybe the most powerful of the Wayk experience is the collective learning and the mechanism within the group soustains the common learning process (Diana Larsen)
Checking your assumptions using the double loop of learning. (Esther Derby) This is one of my facorite topics and I would definitely like to get more insights about it. I'm currently using a special technique of challenging/outrageous question to verify our assumptions so I'm willing to make this technique evolve.
New retrospective techniques "marketplace", an excellent opportunity to exchange techniques used in retrospectives. The session was facilitated by Diana.

The Open Space Continuuum

One of the most apealling experience at RFG is the continuous exchange of ideas. Gathering a group of passionate people has a very "fruitful" effect. They will go on talking about the topics that are part of their focus, regardless of the place they are. So I'd say that the sessions were not only those displayed in the Open Space agenda. Sessions took place away and beyond Open's Space "time and space". I'd like to think of it as an Opne Space Continuoum.

The "Souvenir" and the "Symbol"

Being in such a lovely place was definitely a temptation to acquire a lot of enchanting souvenirs. Walking through Taous center boutiques, there was on that ultimately illustrates the RFG11 symbol, as it stands for me. I took it with me and you cant take a look at it :

If you want, you can take a walk in my RFG11 gallery

Agile Lean Europe Network - the wisdom of connected knowledge

2011-04-16T09:37:00.001-07:00

The starter
Europe has so many self sustained talents and energy. Transforming that self sustain in a collective network support is expected to be a very productive initiative. And very much surprising, as talent people gathered together, usually provide breakthrough ideas.
In this context, at the level of Europe's current Agile awareness Jurgen Appelo's call to link European Agilists couldn't be more appropriate. Like a planting seed in a very fertile land.

The dream
All creative initiative starts from a purpose. That purpose may not be well shaped at the beginning. It's more a dream of an inspiring future than a real Cartesian goal. That does not stop people join that call, being supportive, and contribute with innovative ideas. Dreams always inject energy into groups and make the mainstream of an appealing initiative grow.
From my own perspective, the dream of a connected supportive European Agile Lean European Network is a powerful one, although I'm not sure of the exact outcome. The image of an yarn trowed from Jurgen to each Agillist in Europe, bounding people further and further is so engaging, how not to follow ?

The journey
Volunteer representatives of each country in Europe willing to contribute, will meet at XP2011 in Madrid to build a common vision, principles and purpose: an Agile Lean European Community .
The travel to get there goes through national gatherings that tools, or will take place before XP2011. Reasoned skeptics are welcomed, as any challenge makes ideas grow, but regular lack of action, could either make the dream fall apart , or isolate a region from an enlightening initiative.
The national gatherings build the wagons of the ALE Network train.
The XP2011 Will be its first stop in the ALE Network journey.

The breakthrough
W hen so much valuable intellectual energy focus on a common vision we would experience a breakthrough happening. So whatever that will be, prepare to be surprised.

Three Favorite Anti-Patterns for Agile Projects

2011-03-22T05:20:00.000-07:00

During my experience in Agile, there are a couple of Agile implementation Anti-Patterns I think I identified. Here are three of them.

Ensure SCRUM training before starting the project

The biggest danger in Agile approach is its common sense and its intellectually "affordable" nature. So anyone that read some SCRUM book or, even better, feel comfortable and recognized because assisted to a certifying training, can deploy Agile on-the-fly.

I've had an extremely helpful exchange with a brand new SCRUM Master once, who realized after a couple of shared ideas, that he wasn't able to implement an Agile Scrum project. But he was so enthusiastic, that he wouldn't want to work in any other way than Agile. I really think that he will do a great SCRUM Master and that the training was a good one. the problem is not in training or trainee qualities. Always consider that Agile is based on experience. That's all. You have to live it to believe it. And be supported in your first steps in Agile.

If you only assisted to a nuclear physics course by Niels Bohr for one month, doesn't mean that you became a nuclear physics expert.

I also think this novice SCRUM Master story a happy ending story. He realized that he need to practice and gain trust. The sad ending story is the one when trained people believe sincerely that they acquired complete skills after certification and then quickly step into the 2nd anti-pattern:

Agile as "Do It By Yourself" process

Implementing Agile as a novice practitioner is like driving a car first time in your life after having done a 2 days driving boot camp. I wonder if you want to meet that driver in your way.

I have another example. As related by my parents, it seems that, as a one year old baby, I suddenly started to walk pretty fast crying out my satisfaction. I was pretty skilled to avoid my parents that tried to stop me. What stopped me was the wooden angle of a door. I didn't walk for a while afterwards.

For sure, an Agile novice enthusiast is not that dangerous to human life as the driver in my example or me to my own self integrity back in my baby years. But he is definitely dangerous to his Agile project. Agile will be applied as he believes it is right to, and he might fail. Then experience of waste of positive energy, flawed teams and delusion might happen.

In Agile projects adoption this pattern applies unfortunately pretty often. Guiding is a major key to avoid failure. Some people might argue that this is a fake argument to promote oneself Agile coaching services. Well, Agile Adopters, you need to choose a coach. The one you want but please do that!

Agile as a Holiday or Agile as a Prison

Even if it has opposite effects, these two situations have the same cause : loose interpretation of Agile principles.

If not explained with caution , Agile might be perceived like a Disneyland project. No limits, no constraint, just fun. "Don't need specifications, don't need planning, coffee stand-up every morning for everyone".

On the contrary, for the very same reasons - misfit adoption of Agile - it can be perceived as a "continuous tracking prison" : team are working under velocity and "burndowchart" blame pressure.

Avoiding to be locked-up in one of the 2 situations, means team (organizations) Agile true adoption : understand constraints and benefits. Build respect and trust. Trust allow people to take risks because they are allowed to fail. And that unchains creativity and improvement.

Agile 2011 - Why I enjoy session review process

2011-03-15T03:37:00.002-07:00

The #agile2011 buzz : a passionate exchange

I followed for some time the various feed-backs and shared emotions around #agile2011 tag .

I was pretty surprised about the passion involved, that should mean that people care. Then a question raised : "What about me, what are my state of mind about it?"

The benefit of an outsider

The very Zen answer I gave myself was "Well, whatever works" (thought for a moment of Woody Allen, he's quite a "take-things-as-they-are" mentor to me). I think I can afford this attitude because I never was in the top something, so there is no pressure there. Or otherwise put, the improvement potential when starting from 0 is always significant. The most important step was the first one : proposing a session. Jumping in is already a fruitful experience

The benefit of feed-backs

Feed-back from reviewers are already an award. That means that someone there volunteers (I think) and spend time on different submissions. Feed-backs keep you aware (or warn you) that other people don't have the same cognitive process that you might follow (funny enough that's somehow the subject of the session I proposed) so you have to respond to this constructive challenge.

Reviewed reviewer game

I played the game of going through the different sessions and try to understand how they will work. When I was done with it I had somehow 2 categories of sessions :

those that I thought excellent, I-wish-I-were-there.
those that are maybe highly interesting, but wasn't able to go to the end of the description, really. Well, I think that should have been because I might not know those topics well.

Then I stepped back and reviewed my own session, but , left alone some phrasing I would put differently, it's my proposal ...so I still followed the same logic. I need to re-iterate to really step out my own box.

What I would have liked more...

Would be some input about ways to improve the submission. Submitting a session is a great opportunity to evolve. People that submit sessions need a constructive feed-back.

So here is my suggestion for the review committee : Something that works beautifully is the improvement game framework( from Yves Hanoulle). That is rate a from 1 to 10 and recommend to reach 10. Would love to know how that works for the Agile 2011 "reviewer/submissioner pair" interaction.

Agile Blogs Digest

2011-02-20T06:29:00.000-08:00

The why
The end of the week was pretty cool. So I surfed on some top interesting posts on Agile (thanks all viral communication supports : tweeter, linkedIn, groups, rss feeds).
After one afternoon of enlightening reading, the retrospective of my lecture goes this way :
I discovered a lot of new angle of thinking. Taking into account all these great ideas out there, and realized why I'm not famous.
I don't think my lecture was 100% effective. Some of the ideas presented lost me on the track. I just remember that there were fine articles .
The size and the format of the posts is pretty important. That's one think that matters, and that's why I decided to write this post of Agile blog posts digest.

The how
So here are some thoughts I gathered after my half day reading experience:
Short is important. Really
Long articles can be very interesting, but it is hard to stick on it. So I definitely got the flavor of it, but I decided that I have to read it once more, with more attention., as I had no time to really finish the las paragraph. Need to prepare dinner. So will I really read it again? Will I remember the link. For those who can read brilliant long posts I recommend here : The new user story is a map and excellent post on reviewing Agile 2011 sessions by Tobias Fors, Thinking Tools for Conference Reviewers .

Illustrate
Illustration is effective and easy to remember.
Draw, build the post as a story board, make a documentary movie. No secret, memory is more sensitive to images than to written concept. Here are the favorites of my Sunday afternoon : Thinking tool called Agile , How to create your own game .
And yes, Blasting : The SpecFlow, The Awakening

Make it easy to follow
The best receipt is to build a story that seem obvious to the reader. Something like, I would say the very same thing, like in The Incident Retrospective .

My resolutions
Build posts as an elevator speeches
Illustrate with "applied work " as often as possible.
Image, image, image.

Thanks to all great people out there :John McFadyen, Jonas Bandi, Tobias Fors, Henrik Kniberg, Michael Sahota, Jeff Patton and so many others, that offered me a great Agile afternoon.

Hope it wasn't too long...

For 10th Agile Manifesto Anniversary

2011-02-12T15:02:00.000-08:00

Agile Manifesto Anniversary and my Agile Anniversary
I found out this Friday among tweets that Agile Manifesto's anniversary is now. After twitting and re-twitting the facts a couple of times, I realize that my Agile Anniversary is also in February. Well, I'm younger and I should stay humble. I'm only four years Agile old.

What did I learned?

Listen & Collaborate. The wisdom of collective thinking is huge, the results are surprising.
Continuous improvement needs continuous challenge. Stepping out form the comfort zone is stimulating and enables creativity.
Create value. When involved in product creation, ensure to provide as soos as possible a product that helps users doing their work.
Quality is not an option. Adaptive products cannot have poor quality, otherwise you loose all control.
Be the Invisible Manager. Share and support goals. Empower the team.

What do I want?
Stay Agile. Help enterprise and social environment become Agile.

Why do I want that?
Because I think that's the only reasonable solution for the modern economic ecosystem. Because collaboration creates evolutionary interaction between people that makes products and people that use them. Because "continuous improvement" is not only a point of view about how doing reliable software but a responsible approach to future.

The Rising Star : 19th centry Poem About the Relativity Theory

2011-01-01T01:13:00.001-08:00

For first day the New Year I'm thinking about one of the poem's of the most valued Romanian poet, Mihai Eminescu, that lived in the middle of the nineteenth centrury", a pem called "To the star". It goes somehow like this (I'm in no way a professional petry tranlator, so my verses are surely pretty poor):

To the rising star,
The way is so long,
That light traveled thousand years to reach it.
There it was, when it couldn't not be seen,
Now we see it but it is not up there anymore.

Well it is not as nicely put as in Romanian, still it is a very artistic description of the Relativity Theory some 130 years before its more scientific enonciation by Enstein.

Honour to these to personalities in this 1st of January 2011.

Happy New Year to all!

An Agile project Apocalypse : "UnAgilize" a team in 5 steps

2010-12-20T03:07:00.000-08:00

Here is the description of extraordinary process of going from Agile predictive "scientific Management" , defined by Ford and so popular in the 80's.

Step 1:

Declare using Agile, but put in place the "Taylorist Agile" approach: Backlog is a privilege of few, and can be used as an instrument of power and making pressure. Put in place control people that decide who/what/when can have access to the backlog.

Step 2:

Don't care about complexity, put in place an extra column of charges in human effort (in the same backlog). That will allow building a complete predictive planning and make happy whatever authority requires reporting.

Step 3:

Allocate specific tasks to team members, tasks to be done in a specific time frame. Don't care if the time frame is realistic or not, at the end someone will be guilty of eventual nondelivery. The only challenge will be to nominate her or him.

Step 4:

Nominate extra-stakeholders, to perform extracontrol on the PO and the delivery team. Eventually, PO and team are not allowed to take decisions, they can only inform and wait for permission to act.

Step 5:

That's it! As predicted, it should (IT WILL) work perfectly.

I personally won't give a try to this process, and I hope that in a future, better world of software development, none will. And that's my Christmas wish.

Agile Tour 2010 _- a local initiative a global embrace

2010-10-29T07:03:00.001-07:00

Agile Tour - International Development

I'm happy to be on the board of Agile Tour, not because I were a very active member ( on the contrary I have some moral debts to the their organizers....), but for the opportunity to be the witness of the global phenomena that has its roots in the promotion of Agile locally.

That make me think that giving autonomy, sustain and promote a set of values is as local as global.

Paris

The Location

In the south of Paris, beautiful place, comfortable rooms

The Program

Very rich, much more of "Agile way of Life" than "Agile IT".

I was very found on Damian Thauvin's Session about "how we implement Agile with our clients" in using Lean concepts. The Kanban model to manage the flow between development teams and remote client is one to remember.

The same about "bug or change request" is the same from the team workload perspective and nned to be managed accordingly

Nice work also around the (in)sustainability of Agile and how poor management likes to manipulate numbers in order to prove the effectiveness of ... her or his management.

My presentation

About how we evaluate the signes of Agile success, in respect with our professional background and personality. For some reading in french it is here

Agile Projects : is "Agile Casting" Needed?

2010-07-14T02:39:00.000-07:00

The individuals, the team

A project starts with a set of individuals that need to work together. That's quite a plain assumption. Eventually, a group of people know how to cooperate after a given time of shared experience.

Team Performance

The Team Performance Framework is one of my favorite models.
It shows how a regular (?) team is (auto)build passing from a "creation" to a "sustain" phase.

People don't quite fix in boxes

Usually team are build with "resources" that have to accomplish a task together. In this "blocks built" set-up different technical and operational skills are required.

Unfortunately, put people in skill boxes is that's not enough to build a team. Even less to build a team that performs.

This is true in any type of approach, Agile or something else.

Agile Casting

People that work on Agile projects need to share the set of Agile values, as collaboration and continuous improvement. Agile dynamics is not fit to perfect people, but to people that want to to perfect themselves, knowing that they never achieve perfection and that they are happy with that.

Get Human Resources Agile Compliant

I do think that Agile is an Enterprise project far more that a software development one. If you want to build an Agile team, you need to get support from different department. Human Resources is a major player, and you need to help them understand your objectives. So having an Agile Compliant Human Resources department is important. Share Agile values with them and help them share them with other players of your enterprise.

Now, happy Agile Team Forming & Building!

The Impact Between Agile and Authority

2010-06-09T13:58:00.000-07:00

Product teams want to stay Agile.

it ensures fluency and cohesion around the project.

Decision makers just want Waterfall Planning.

It is so reassuring, it comforts the control habits.

The Impact : Inhibition of Valuable results.

Is it a organization/project collision phenomena?

Agile, the journey from constraints to creativity

2010-05-16T10:32:00.001-07:00

About Constraints

Dealing with constraints is a a day to day task and

managing them efficiently a constant concern.

Agile frames constraint and outline their creativity enabling features.

Agile put boxes everywhere, so teams are motivated to jump out of them ... and improve continuously.

Stakes are made to be overpassed.

Constraints and Problem solving

Problem solving activity is about finding solutions.

Problems are recognized as constraints.

Finding solutions is recognized (more) easily as creative task.

So in a full transitive logical manner, we might agree that

Problem Solving is a creative activity.

Problem Solving and Continuous Improvement

Continuous Improvement is about finding the most effective, original way to solve problems.

Well, of course, not only. But I think that getting out of the comfort zone and step to the

troubleshooting outworld is a good way to improve.

Continuous Improvement and Value Creation

We want to improve to work better, be happier, and so on. That is add more value in

our lives or our enterprises. And that's all about creativity.

The Retrospective Facilitator Gathering 2010 - why I wasn't there

2010-04-22T22:41:00.000-07:00

At the beginning of the story there was the Iceland volcano

Ashes cloud freezed all travels, but I just didn't feel involved. On Friday afternoon mails about travel changes were exchanged between the participants.
I decided that I had a too busy day to take care of that - and believe (or pray, how Ilia has recommended me) - that the ashes cloud will no longer be a problem until Sunday.
Definitely it was a bad plan, because I found out on Saturday that all the airports are closed until Monday

The transition from yes to no

Nevertheless, on Saturday I decided not to take care of it before the evening came. I made that decision because if was the only single day I was ment to spend with kids in all their Eastern holiday time. (in fact my daughter was very unhappy with my journey to Denmark).

So I started to zoom on the real situation on Saturday afternoon. Obviously it was pretty hard for any type of accommodations for the very next day. So after struggling through some low probable options until midnight (calls and complex arrangements), I gave up on Sunday morning at 1:00 AM.

And the journey from "yes l'll be there" to "no I'won't be there" ends here.

The troublesome taste of failure

Haven give up brought me a moment of mental peace. But I woke up on Sunday morning with an accurate feeling of failure. Then I started doing my "intimate" retrospective about all this, and here it goes:

I started by asking a quite inconfortable question:

Did I try hard enough?

I really believe that if you want something hard enough, you can get it. So if I didn't made it is that I wasn't committed enough. That conclusion sounds quite strange to me, so I continued my own introspection, assuming that

I wasn't prepared to try hard

I was set up to focus on spending time with my children before leaving for the RFG 2010 in Denmark, changing that priority was difficult, so I decided to

Choose and assume decisions

So I was happy with that, and free to think of other amazing options, as the Openvolcano10 Agile conference in London revealed itself: when a door is closed, a window is about to be opened.

AND HOPE TO SEE ALL THAT GREAT PEOPLE AT RFG 2011

OpenVolcano2010 - announcing an emerging society behavior ?

2010-04-21T03:39:00.000-07:00

Motto:

Alice laughed. `There's no use trying,' she said `one ca'n't believe impossible things.'

`I daresay you haven't had much practice,' said the Queen. `When I was your age, I always did it for half-an-hour a day. Why, sometimes I've believed as many as six impossible things before breakfast. There goes the shawl again!'

(Lewis Carrol, "Trough the looking glass")

Turn difficulties into opportunities : when you want something hard enough you can make it

This is all about a bunch of Agile people, that were stucked in London this week (the "volcano refugees"), creating a conference and getting sponsorship in a 48 hours time over twitter.

This is the kind of experience that you have to experience to believe it.

Cloud conference organization

After "cloud computing", "cloud conference organizing" should be the next concept in line... The group acted indeed as a self-organized and self-managed, Agile mature team, and the kick-off of the initiative was launched on twitter on Sunday.

Organization time boxed to 2 days time: from Sunday morning to Monday evening. It worked brilliantly. The social media network proved how powerful and effective it can be, people are gems of valuable initiatives and effective collaboration. It took about 4 to 6 hours to sell out all the places and the organizers added some extra, the buzz around it was impressive.

The open set of tools and services available, allow today advanced facilities that are required to a conference logistic : set up the event, provide content, communicate. It's easy, everyone can contribute and improve the process.

The birth of this event took place under world's eyes, we had the privilege to be the witness of an emerging society behavior.

About the people that were there

After the first set of places were sold out, extra-entries were added. The group ended up to 75 people, Jeff Sutherland, Paul Riles, Uncle Bob Martin, Chris Matts, Paul Darrel in super-organizer role, and other brilliant people, that I had the opportunity to met for the first time. Of course Rachel Davies, as skilled facilitator needs to be mentioned.

The sessions

I was late - I've done kind of an initiation trip, a little bit like Alice on the chess plate - and missed my car-ferry -train connections, so I pretty much applied the Open Space's "law of 2 feed" when arrived.

Learning skills is definitely a topic in the focus. Groups discussed about what are the learning leverages, how to ask the good questions, how to develop learning skills (the "5 Whys" framework for detecting root causes was a favorite topic).

Kevlin Henney talked briefly about our inability to learn from failure. The idea of learning from our failures and its context ("failure and something else") reminds me pretty much of Edward de Bono's "lateral thinking".

Nice session with Roy Osherove about Agile team profile and how to grow it from chaos to maturity. Worked a lot about the leadership idea and the opportunity of authority. Some connections with team profile (from novice through expert) and Tuckman's group dynamics model (storming, informing, norming, performing) were mentioned.

We pictured our ideal Agile environment with Rachel Davies. I'm not sure of the art skills of the group, but we definitely had a lot of fun, and having a pair of dogs in our work environment was pointed out by Bob Marshall as a strong requirement. And we didn't (yet) answer the question about why it's "professional" to be be sad/unhappy at work.

Thanks to people participating in my session about "Successfully implementing Agile - signs from the trenches". The goal of this session was to list from each other what are the events & signs that made he or she think that a team has the right dynamics and is delivering a quality product.

Interesting remark and modeling proposed by Rachel Davies about signs that are different whether your project transit from chaos or from waterfall. All the signs of success that were identified are close to Agile values Hmmm, interesting. Valuable contribution from all the group, so thank you guys!

I missed the session about the future of acceptance tests, but I'm willing to follow, it's a major topic.

The "Light Open Space" Session

The last session I assisted had a very interesting formula proposed by Antony Marcano - 10 minutes sessions ( 5 min presentation and 5 Q&A), I was pretty impressed by the result of quality summaries about the different topics: BDD (Behavior Driven Development), Roles distribution and team effectiveness, human learning skills, Product value stream.

Thanks!

Thank all the group and sponsors to let this happend, it was a gorgeous learning adventure.

Quotes & Notes

Here are some quotes I wrote down

Learn from success
Decide and inform (ask forgiveness) rather than ask for permission
Make measures is a learning experience
The reward of the good work is more work
Stakeholder's story : "In order to (Goal) as (Stakeholder), I want user to (Story)
Do the relevant task for the team not the relevant task to my specialism
Learning from failure reflects our fail to learn

Hope to see you all soon !

The Pro & Cons about Majority Decisions

2010-04-19T12:44:00.000-07:00

Signes of Successful Agile

2010-02-01T13:55:00.000-08:00

How to recognize succes in Agile projects?

This is the kind of no answer - a million of answers question. Usually you may recognize a project rather when it doesn't go well, or - even worse -it fails. Why is that? Well you may set-up a retrospective session. In order cheer-up the team, you may try to do an "Appreciative Introspection" exercise and detect what team(s) are doing well, so you can all leverage on those items.

Keeping a continuous Agile state of mind is not an easy task. How would you detect it? I've collected some encouraging signs. Here they are.

The power of a quality example : Why don't we (also) work in Agile?

Some time ago, on a pretty large project, I noticed that members of a dedicated team where not really happy. More the time passed, more the people were sad.

One evening, talking with one of the team members, I asked what was wrong. "Well", she said, we're pretty isolated from the rest of the group , and we are not in Agile mode yet, when will we be included?

Take the opportunity for new ideas: That noisy "stand-up"!

Scrum teams in war rooms making their stand-up were a little bit noisy. Their Product Owner was not really concerned by their talk (much of build and class heritage discussions), and though not very happy with that moment. She proposed a new concept to the project : the "cross POs" stand-up at the same time ( different places...)

Fully Scrum Adoption : All I care of is the backlog and sprint planning

That is my favorite, as the time being. Development teams struggled over splitting/consolidation of projects managed by a bug track tool. When the plan of consolidation of different entries and the necessary follow-up was presented to one of the product owner, she had a really hard time to follow that cross-reference map. To shorten and simplify the discussion she turned to the Scrum Master and said "Hey guys, if you need all this stuff to manage your development it'o ok with me. From my point of view, all I need to know is what stories are logged into the backlog, so I can ensure that they will be prioritized and planned in the future sprints".

That was one moment of glory for Agile.

Meaningful Agile Teams

2010-01-05T14:24:00.000-08:00

"Agile is about interaction between people"

That's nearly how it is stated in the Agile manifesto. But when it comes to implementing Agile, old process oriented practices and approaches tend to be adopted. A process framework is reassuring. When you're not sure, the process might bring the answer. Eventually, this reflex is more often observed for young Agile organizations, that deploy Agile (SCrum or other) without support and/or coaching. That doesn't mean that coaching or experience bring all the answers. Value experience and coaching oriented on specific needs will help. If a coach is present, he's s just another part of the "interaction between people". He is accountable for the quality of interaction.

Roles are neither titles, nor prices

"Naming" someone as a SCRUM Master, or Product Owner, or coach or whatever accomplishes only the action to fill boxes with a content. This approach is often a serious - maybe the main - cause of failure of Agile team dynamics, because it creates meaningless teams.

A strong requirement for a successful Agile team is to evaluate how the people fit with the roles that they (have to) endorse.

A good Scrum Master is an enabler. His experience might be more important as a project manager or as a technical expert. He needs to stay operational and effectively help the team deliver. I don't really believe in a Scurm Master that passes 100% facilitating a pile of items among a pool of resources while protecting a group of smart and sensitive guys focused to deliver against the mean wild world. Where is the collaborative Agile Value in this pattern?

The Product Owner needs to have the capacity to act as such. I have experienced organizations where the role of Product Owner was assured by a pool of Business Analysts that where supported by a product manager. In another project, the Product Owner role was played by a group of users. The priorities they defined were validated at a high level by the operational manager of the business line that was the main project's customer .

The key of success for Agile team dynamics is to identify the distribution of tasks that make sense into a specific organization and fits to existing skills. While you do this exercise, keep always in mind what are the drivers to success that motivates each member of the team you're about to build.

Agile TOUR Paris 2009

2009-10-22T06:01:00.000-07:00

Organizing

It was the first time I participated in the organization team, I didn't realiza how complex this task is when it must fit into one's freetime. Although I wasn't as effective as I should in respect to other memmers of the organization team, but when you're in you have to be in and respect the committments. Basic but hard to deploy, when you need to conference skype, send mails, cook dinner and help with kids' homework in the same time.

Anyway, the team did great at the end!

Participating

Great topics there! My best indicator is the "overwhelming choice", that is when I would like to participate to three sessions in the same time.
I had the chance to participate to Mack Adams' very sensefull session about the "Insvisible Manager" but I missed Deborah Hartmann's session about "Leaderful teams".
Patrice Petit presented a very interesting conference avout "Illusions & Desillusions in Agile", my take away of this session was that "succes is a continous process", nothing is won for ever.

As usualy I enjoyed the different game set-ups in several workshops. Anytime I participate into one, I say to myself that I absolutely need to use the game with my teams. I appreciated the "Advocatus Diaboli" game where one teams presented the benefits of waterfall projects practices and the other one the benefits of agile projects. I wonder how a real waterfall convinced team would present the benefices of Agile.

Last- but not least of the games I participated in was the "perfection game" (from the Core protocols) presented by Bernard Notorianni & Emannuel Etasse. I had so much fun, that I decided to apply the evalutation from 1 to 10 and state what should be done to arrive to 10 in a lot of sensitive feed-back that I need to have/receive.

Presenting

I decided to present a session about the Profile of an Agile Coach, because "Coach " is one of the most semantically loaded words. This essai gives a view (exclusively mine, and of course not an absolute truth) of what are the qualities and the missions of an Agile Coach.
To start with, an Agile Coach coaches teams that work on Agile projects. Simple, isnt'it?
The prestentation is here (French).

See you next year in Paris!

Why "iterate & feed-back" rather than "predictive process

2009-10-02T08:15:00.000-07:00

The need to feel secure

We all feel more comfortable if we can control what will happen. We then think that a kind of forehead awareness will help us take the right decision at the right time.

The control power

Being able to predict and control is one of the valued features of managers. As they seem missioned to control, they might value a lot predictive processes. When managers are junior or unexperienced, their need to control and enhance the rigidity of this kind of interaction.

Adapt rather than limit the change

Predictive processes don't encourage change. The drawback of this kind of model is that the world has to evolve as the process has described the evolution. I cannot help being surprised as this pattern seem to be considered sensible in the business, management or software development area, as it is considered a non-sense in the out-door world.
Setting-up environments, practices, tools, teams that are able to iterate based on a PlanDoCheckAct (that's no such a new model either, isn't it?) seem so much close to the real world and to modern business change context.
So if it's that simple, why won't we do it this way? Because we still need to feel secure, to write long contracts that take into account every possible and improbable disaster and conflict. Because when you are a junior bike rider you need to "think" about your front wheel and concentrate.

How do yo drive?

The bike rider reminds me of another image that I share to compare the effectiveness of predictive process and adaptive ones. Just think about how people plan to ride by car from point A to point B.
We all plan an itinerary (no project can be done without initial planning and design). But did any of you ever made a complete inventory all the incidents that might happen on the road and logged carefully what should be the reaction plan for each case?
If you do so you might never step out your front door (well, I've seen project that never stepped out in from the analyze phase) or you might have an accident because you're to busy to review the "Detailed Specifications Reference" to be sure what case applies.

Actually, when rigidly applying predictive processes we act as junior drivers. Would be that because of this?

Design your Retrospective

2009-09-28T02:01:00.000-07:00

"Retrospective Structure Mind map" -Give the right flow

I recently used the Mind Mapping tool to build a large 360 - release retrospective. It was my first time.
I met people that are very found of Mind Maps, they take notes under Mind Map format. I was convinced by the intellectual usefulness of the exercise, but it was somehow uncomfortable for me to apply it. Well, my late Retrospective sponsor is a fan of it. He was not very familiar with a retrospective set-up, so he needed to be reassured about the meaning of the different phases.
Building the "Retrospective Structure Mind Map" allowed us to clarify the flow of exercises and point out what makes sense and what does not.

The Retrospective "Dry Run"

The same "Retrospective Structure Mind Map" revealed itself as a very useful tool to built and "rehearse" the meeting dynamics, point out the transition phases, manage logistics and negotiate time slots etc.

The Retrospective Road Map is helping the co-facilitator

Co-facilitating large Retrospective is extremely helpful. I'll get back to this topic in another story.
Anyway, for the "project 360" Retrospective I'm referring at, we decided that the sponsor of the Retrospective and myself will be co-facilitating. Having the "Retro Road Map" under his eyes helped him deal with the time boxing of the exercises, flip chart move logistics... and helped me not to forget any item on a session that scheduled to last 4h30.

Retrospective Minutes and Retro of the Retro

To end with, we did use the Retrospective Structure Mind Map as the meeting minutes framework. What I enjoyed most was to attach on the exercise branches the photos of the collective work.
Of course, as I had a lot of fun adopting the FreeMind tool, we did our Retro of the Retro on the same format. I let you guess what was one of the items we identified as something we do well.

Social Media as a Continous Improvement Tool

2009-07-27T02:50:00.000-07:00

Reaching -faster- to your center of interests through Social Media

The story of the journey into the amount of information Social Media platforms pushes to you is fascinating. First, I think their effectiveness is due to the "pushed information" system. Research onto the web is voluntary action and you have may to struggle and drug information on the web on a specific topic (that you might sometimes need to provide well formed). that means that in at a given moment of time, you are focusing on a topic, working specifically on it, etc... You are active, the web is passive.
The Social Media model turns the interaction the other way round: The net pushes to you the type of information you selected as meaningful to you. So you are "passive", the web is active

Collaboration through Social Media

When projecting this to Agile, it seems rather obvious to me that the Social Media tools - like Twitter - can be used as supports for continuous improvement. How does Social Media help to answer to the "Inspect and Adapt" questions:

What Did We Do?

To answer this question just post what you think significant on the net.

What Did We Do Well?

Share your experience with the people of your group, you'll have the feed back that helps you validate and get even more.

What Could We Do Better?

Again, share your experience, and ask for input on topics you might feel the need to improve. The reactivity of the social media environment is pretty impressive. You'll get -almost instant feed-back and valuable references that you can use.

Collective Wisdom On The Net

I'd like to give, as a conclusion of this post, the image of a "virtual collective wisdom" , enabled by the Social Media. To quote and adapt a phrase of the "World Café", you might feel its presence in the in the middle of the net.

Why retrospectives matter: Learning experience drives the way we act

2009-07-22T06:43:00.000-07:00

The car with the blue lights on

A friend from US came to visit me. We hung around in Paris until midnight, then we took our cars (she rented one) and followed me. Well, the trip was a piece of torture, the highway was blocked at night and I had a hard time to figure out the way back home. My friend behind me (first time in France, at night) was fully occupied not to loose me and wondered why we were driving in circles. I was just about to realize that the way out for getting home was also blocked and I was thinking that we'll never get home that night, when she called me. She was extremely worried, andt she told me:

"Am I following the right car? And there's a car with big blue lights right behind me, what should I do?"

I started to explain that, yes we are blocked on the highway that's why it takes so long, but we'll make it. She insistend about the car with the blue lights, and I told her not to worry, just get out of the way of the ambulance. I must (selfishly) confess that the ambulance was not among my concerns in that specific moment and tended mot to pay attention on her question about that.

I realized after that in US being followed by a "noisy" car whit impressive big lights on have a complete different signification and demands immediate response!

We translate events using our experience

The way our a learning experience make us react to a given situation might be a source of misunderstanding. The risk to stay "unaware" of situations like the "car with the blue lights" is pretty high, because we have our own set of references.

Taking time to explore, listen and understand a topic from different sides is a major team activity and an improvement driver. Retrospectives are an opportunity of choice of Agile teams.

If you skip a retrospective, you might get in a "car with big blue lights on" trouble.

Is Agile more expensive than waterfall?

2009-07-13T05:06:00.000-07:00

What do we compare there?
A parallel with measures in inertial vs non inertial referentials

A definition to start

Traditional Definition of
an Inertial Referential (IR):
set IR of referentials whose members
move at constant speed with respect to each other.

The power of numbers is fabulous, as it gives the flavor of neutrality.
For this reason, numbers and measures are powerful persuasion tool.
But we need to remember to place the measures we take
into the context and conditions of measurements.
As the above definition reminds  us (recall of  high school physics courses) ,
a speed measure of an object  is accurate if the measure tool (observer) is
located in an inertial referential in respect with the object observed.
Otherwise the measure is fake.

The IT project referential : Scope, Time, Quality, Resources (and money)

The Waterfall IR
n an waterfall project we fix all the 4 axes above, and we (hope to) create THE project IR. It is freezed, and we are supposed to evolve in it's strict boundaries in a very deterministic, Cartesian way. This model cannot take into account the changes of the outer world, otherwise it will contradict it's own prerequisites. The result is a project in a fishbowl to fulfill ocean needs. It will have fixed cost, as estimated upfront. How does that work for you?

The Agile Non-IR

Agile projects goal is adapt and take into account changes that might occur on all axes of the project referential. In Agile set-up, the referential is in continous evolution, together with the project itself. Making the same IR type measures gives false results and can lead to wrong conclusions, like Agile projects are more expensive than waterfall. We simply don't have the same measure basis. It's about the same type of observation as the one that concluded that the universe in expansion because it runs into red ( Doppler effect). How this conclusion can be reliable when measures are made from the inside of the universe?

Can you buy donuts and do a lot of other things in 5 minutes?

If the comparition with physics was too academic, let's have a quick comaration with another real life case. Buyng donuts for breakfast take 5 minutes. How can that work if - from the moment you're out of the building, you need to: help an old lady carry her packs to 20th floor, bring the neighbour's child to the hospital because the fall from his bike and seems to be hurt, make a loop to the physician to buy some drugs for your daughter influenza (just made a call to say she run out of couhg pills), and finnally arrive to the bakery to buy donuts.

Did you make it in 5 minutes? Will your wife inquiery about what you have done all this time? Will high level consulting analysts conclude that your Agile project is more expensive than the waterfall one?

PS: In General Relativity theory it is assumed that an IR referential is one where no field is observed.

Improve Agile teams

2009-06-25T07:06:00.000-07:00

Tools & Automation don't fix problems

We think so hard about topics that we care of, that often we don't state any more the issues (they become implicit), but struggle to find a solution. So the problem shifts from the real issue to what tool do I need?

Installation of shiny tools does not mean their adoption by the target users. This might mean either that the problem is elsewehre, either that people don't see the use.
Bursting in the "let's get the best tool ever" decision may be a higher level management decision that needs reporting.Higher level management may believe that providing reportings will help teams working better. From a Lean point of view, that might quickly become a serious waste source.

The negative spiral

Chose a tool for wrong reasons can make problems grow rather than reduce them. If there is low adoption of the tools by the users, they might become frustrated. Imposed tools and prcess are
percieved as disruptive control and as a sign of lack of confidence. At the and, the team is deresponsabilized, which is the very opposite effect of what we expect from Agile.

Analyze before choosing solutions

Ask questions. I'd say that a good Agile coach has a set of "questions of reference" to ask. Then adapt and make diagnostics, as reliable as she or he can. Then use the methods that work best for each coach and team to analyse the root causes of problems.
This can be a quite long way to run. Meantime the best tools evee are the flipchart, the pens and the stickers.

Same framework - opposite results

2009-06-18T05:02:00.000-07:00

It's not the tool, it is the use you're making of it
It's quite fascinating to coach different teams that implement Agile; One of the best experiences I had was applying the sanme exercise for two different teams and have specific opposite results.
The framework of the exercise was based on Diana Larsen"s Frequency Impact Model to gather data and the circle of influence technique to qualify actions.

Results for the team A: A lot of negative and frequent events in the frequency Impact graph. Team is not satisfied with the the low level of reactivity external context. But guess about the results collected: the entire list of actions identified was grouped in the team action zone. Nothing was left for the circle of influence, neither the circle of concern, even less for the big world out there.

Results for team B: A lot of nice things going on on the FRIM graph. And a lot of actions that need to be taken by the farest circle of concern.

What is the clue?
I suppose there is no such a clue. But still it is quite what king of a self image a team can work out. How can a team pretty frustrated by the lack of support of some far decision makers identify only actions to be taken by themselves? What is the point there?
On the other hand, does the lack of actions for the team itself mean that the people there are very happy about theirselves?

Don't blame Agile! ...Don't blame SCRUM! Don't blame at all!
I'm not sure that we need to answer the questions above right away. Lately there are some voices that say that "SCRUM is on a disenchanting wave". I used this example to illustrate that there isn't anything about SCRUM. Nor about another method that we might want to use as a silver bullet. Is just about people applying methods. "Inspect and Adapt".

"Enhanced Agile" - add strategic business sponsoring

2009-06-09T10:14:00.001-07:00

The self managed SCRUM team - until what point can team decide
Rather frequently, team SCRUM are doing pretty well in their SCRUM development cocoon of iterative working way. They might be more or less happy with they daily stand-yp meeting, the sprint retrospective, the cross-testing, their velocity, the code quality, the effectiveness of the improvement decision made (if the continuous build the Barney Toy is up the screen, if the build is broken, the Nabastag WiFi rabbit is crying, etc). A team can perfect its SCRUM and Agile, but if the business correspondent is missing, the added value of the improvemnt can be very low.
The lack or the poor quality of input can have two effects: the decrease of team motivation and the endorsement of the Product Owner role by a member of the team - if available thy technical guy that was in there from ages and know a lot about how IT works in the company.

In both cases, the loose connection with the business side, might make the team activity meaningless in the business context. And the management buy-in falls to big zeros (with no number forehead...)

The Product Owner: Is there anybody out there?

Why should a suposed sponsor of a product is so painfully absent? I think that's mainly because people when they act as users are used to "place an order" and skip to other activities.
Just telling to a designed Product Owner that she or he has to be present, supportive and bring business value to the team is just not enough. Is likely that these people have "other things to do", a lot of pressure and have personal and group objectives measured on other criteria.
Playing the Product Owner role is a perceived as an non-critical overhead activity.
If this is the case, the team or even the CIO chances to bring the Product Owner to provide valuable stories into the backlog, invest time to do TDR (Test Driven Requirements), or even participate to Agile team meetings are not very high.

The Difference That Matters ; User Agile Organizations

The set-up described arrives pretty soon. IT departments sponsor willingly the Agile approach.
IT teams are happy. User are happi(er) that before: "nice, we don't have to wait two years to see a tool that we don't need any longer, IT people become more sensible".
But success stagnate often there. The full benefit of Agile can be achieved if a strategic sponsoring is in place: senior management support business people to continuous creation of value through iterative results. And measure how this frequent enhancements have enhanced business. User Agile Organizations will the be the big step.

Agile - a child's game?

2009-05-25T17:21:00.000-07:00

Agile is "natural and human". The principles of any Agile Methods (Lean, SCRUM, XP) are so easy to understand that you may hear after a quick tour presentation of Agile principles : "Hey how come that we didn't think of it before"?
Agile encourages the acquiring of knowledge by the game. Because there is no better opportunity to progress and "not stress" than the games.
Agile is also encouraging the "practitioners" to keep the energy and the mind-set of children when they play. I've assisted at a very good session of this topic at XP DAY France.
With all that, I wanted to test if "playing Agile" with children is a game they like.
I won't tell you what happened right now, you'll have to wait until tomorrow evening for the rest of the story.

Retrospective Gathering 2009 - Self organized teams

2009-05-11T18:21:00.000-07:00

The "Retrospective facilitators Gathering" 2009 - were i participated for the first time- was a brilliant example about how a mature enough group can create value without individual leadership. I was not familiar with OpenSpace technology before Diana Larsen opened the OpenSpace, and my first thought was that it should work only for "experts". In fact the answer is "NO", it does work for anyone that is aware of his or her responsibility in organizing a valuabla exchange place. Giving it a second thought, there is the same mechanism that works for OpenSpaces as for Agile/SCRUM Planning Games: the team is self organized and takes the responsibility to realize what they engaged to. And they agree that they are accountable for their own engagements. That's quite powerful.

Why SCRUM is so keen on timeboxing?

2009-04-28T05:27:00.001-07:00

Rigid rings ensures chain flexibility

As the rings of a chain, timeboxing is the feature that will give to an Agile project the required flexibility, adaptability to change, capacity to manage risks, and do on.

Timeboxing sprints
The fixed lenthg of sprints allows the team to regulate their work, motivate all actors to effectively define priorities and produce the most important value first.
Timeboxed sprints allow also to the Scrum team and stakeholders to reliably predict the advancement of the project (a good Burndownchart is built on a fixed period sprint basis).

Timeboxing meetings
Retrospectives and planning games are also timeboxed, beacause is the constraint that work best for an effective meeting. That's as true for SCRUM as for any other managtement apporach.
Timeboxing a meeting hepls participants to focus on the topics and achieve the most important meeting objectives at first.

Agile principles of collaborative work at risk?

2009-04-20T08:53:00.001-07:00

This is the kind of question I have asked myself after a sprint retrospective I've facilitated lately, and here is the context:
The customer (Product Owner) has much pressure to have functionalities released in a short time, and that's due to legal changes constraints. Very well, any of you might say, that's exactly the kind of situation that Agile practices can handle brilliantly, and very reliably.
All is needed is that the Product Owner defines his or her priorities on the business value scale, the SCRUM-like organised development team will react accordingly.
That's true in perfect world. That's true in experienced teams that are used to work together. That's true if participants (development team, Product Owner) have a good level of motivation.
As for myself, I've happily experienced it in many situations.

But in the project context I'm referring here, the planning game reflects a mix of the willing of non-engagement of the team and of the fear of blame.
The Product Owner has a very modest envelope of complexity points to distribute among the stories of an iteration, and is about to ask himself a fundamental question:
What are the means I have to make the work done? Isn't here a limit of Agile methods, where business becomes fully dependent of team's will to commit to work?

I think that this kind of situation represents a risk to compromise a most sane collaboration method, and I don't know yet how to avoid it.

WEB 3.0 or "Do Androids Dream of Electric Sheeps?"

2009-03-02T04:06:00.000-08:00

Well, that might not have a lot to do with Agile project management, but I still want to talk about. It might be the another (maybe!) BIG thing of the future "data exchange" based society. As I lately am rather blocked on my sofa, I had an extra time to dedicate to professional reading (Oh, yeah, usually, I'm acting not studying...). So, in the (almost) latest number of the magazine issued by the IEEE Computer org, I found an article called "Web 3.0 Emerging". I was somehow prepared by the former reading that demonstrated how we could compute using proteins. So...

What is Web 3.0?

It's said there that it is not a technology. It's somehow linked to semantic computing. Great. I read three times the definition of OWL an RDF(S) without really getting to the point. So, what's all about, another way to call the "rosettanet" like standards stuff? After a forth pass, I think I finally got it: the goal of the web 3.0 is to put a new type of inference engines to work and enhance power of dormant "semantically meaningful" data on the web to work. Will that mean that the Internet will be "brained enough" to auto-generate knowledge?
As I reached this conclusion, I reviewed one of my favorite films (somehow it has put me on my actual professional rails, I dare say) : "Blade Runner".
Will the Web 3.0 phenomena stop "Replicant Roy Batty" fate, whose huge khowledge ("I've seen things that people won't believe are true") is to be "lost as tears in the rain"?.
Will the Web 3.0 kind of data infearence mash up technology be ready to answer, 15 years after the movie was produced, the question in the title of the novel that inspired it: "Do Androids Dream of Electric Sheeps"?
All I'd still like to say is that the story happends in 2019.

If I Had a Dream of Software Project Management

2009-02-28T02:48:00.000-08:00

What would be the most valuable feature of a software develppment department or let's say of an IT project for a pragmatic CIO, project manager?
Even if I'm steming my experience in software development and architecture, I must say that I spent the last 6 or so years more in management than in coding MVC patterns, take care of builts or implementing xUnit (either "J" or "N").
So, I'm able to answer this question from this point of view, and here is my choice:

have reliable data to enable effective decisions.

Some 2 and a half years ago (only!), I discovered SCRUM, XP, Lean. Quite a relevation of how use common sense to improve the effectivenes of project activity it was!
So what I want to submit you here, is the look on pair programming, quality testing, requirement control, and so on from this perspective.
After practicing it for this couple of years now, the best summary of this experience are my favorite citations that people I worked with have done:
"How come that we didn't think of it before, it's so simple!"
"Scrum and alike development team members can painfully go back to the classical top-down way of working"
"I cannot remember an Agile project that went wrong".

If it's interesting for you, come with me and look at Agile MashUp techniques from my side of the mirror.