The Product Owner as a team member

Hello Agilers!

How are you doing? I hope everything is on the way for you.

This time I want to share a reflection about the Product Owner Role.

How can we know if the Product Owner is part of the team?

When is it a Team-member?

And When not?

How do we know?

My opinion is that it will be a part of the team, when all together shares goals and fate. Did you ever had an experience where people don't collaborates, but cares only by its individual responsibilities or worse: to compete inside the team.

First sympthom: competition.

Level 1: The Group

Level 2: The Team

Level 3: The Collaboration

Level 4: Welcome the Conflicts

Level 5: The Autonomous Unit


Webinar series ended! Thank you all...

Hello agilers...

This time I want to thank everyone that supported me to perform this Webinars series.

It was a great learning experience, that I will never forget...

I take with me the learning that I must take more risks and try new things always.

I share with you all the presentation's portraits.

Love you!



TDD Testing with JavaScript, new version!

Hello Agilers! 

This time, I dedicated some time to re-use my old JavaScript TDD library.

My next goal is to make an online Webinar to show you how to use it, but more important over is that you can learn the basics of TDD concept.

var tdd_live_online = new Webinar('js-tdd');

See you online!

Dan (the man)


You are not really "Agile" while you don't do these 9 things

Hi folks,

This article comes from another one, with the same title. I will not link it, because I'm going to make a derivate and the most important content here is not the origin, but the new thinking... the ideas.

The title caught my attention, then I said:

- "yes! I will read it! I want to check how much Agile I am"

Some minutes later I was disappointed:

More or less the article explained these 9 elements:
  1. technical practices
  2. set-up continuous integration
  3. automatic environments 
  4. put the customer first ("Agile teams are servants of the customer")
  5. your teams are real teams
  6. limit your "work in progress"
  7. the business goals are clear
  8. you evaluate teams, not individuals
  9. you have a risk-friendly culture  
On my opinion, this looks like a "definition of Agility" from an engineer perspective.  It is not wrong, I think the problem is that it is not complete and as always... remains in the surface. So I will provide some complementary ideas.

Let's challenge the ideas ;)

Think for a moment: If the Humanity was not "Agile" before 2001, then where is the innovation?

Which was the new solution that this Agile movement brings?

Just go faster?

Just do less documentation?

That's all?

If then, why it works so good, and why the classical methods failed hard?

Team-working, prioritization leadership, process optimization and even automation already existed before.

Then the questions today to think are:
  • Which is the innovation that Agile brought to the Software World?
  • Why Agile was Born? 
  • Which was the Change? 

If we talk about an "Agile Team", usually people will think something like this:
  • some people in charge of implementation, (dev team) 
  • 1 person in charge of design (product owner) 
  • 1 person in charge of "team velocity" (scrum master) 

... then there is not so much difference with the methodology applied to Pyramids construction 7.000 years ago.

But in the middle we lived many change eras:

  • roman empire, 
  • middle ages, 
  • feudalism, 
  • capitalism, 
  • industrial revolution, 
  • scientific management... 
  • and now we coexist with "millenials" generation.

Where is the difference?

Which is the new Thing?

- "...but you must put the customer first!"

Really? That's older than Colosseum.

Ok, if you pay attention, you can see that one of the most important differences on each "change era" was: Leadership.

On each era the "Leadership" became a little bit more "soft", "light" or "open". Or "less vertical".

But, why "Leadership" is so critical on each innovation era?

The answer is quite obvious: The Leadership is the social-class that injects culture. They are "Culture Ambassadors". You cannot change or stablish nothing if Leadership won't support it.

So then, let's take a look into some of the innovation elements that this new "Agile Era" represents:

Self-organized Teams

More or less this is related to the point 8 of the original article.

Also to have "Self-organized Teams" (that still no-one understands exactly what it is) you need "self-organized team-players".

And of course, to have self-organized teams, you need a compatible leadership.

Facilitator Leadership 

A "facilitator" enables the Team to Flow on performing, and assist it on every impediment that can hold it back from reaching goals.

Even the facilitator is frequently consider "part of the team", what I can strongly recommend.

Many times, the facilitator is in charge of providing the context the team needs to be fluent. To create the space: culture, rules, tools, trainings, coaching, mentoring and whatever is needed to have a healthy echosystem.

The other innovative element from this era is:

Self-learning Teams

In Scrum, and in Agile Manifesto, this is represented by the Retrospective meeting. I think there is a good point where you can "evaluate" a team maturity.

An entire Team is like a Big Brain. Which will be glad and joy to learn something new. Will be strongly motivated to take down challenges, and will cultivate its self-esteem on the way.

Learn is Change. Learn is Evolution. Learn is Adapt. Learn is Grow. Learn is Performance...

In the past eras, someone was already prepared for a position, or not. You needed a lot of studies, certifications, courses and permits to work.

In this new era, one of the most important skills is: Adaptation.

There is a lot of more elements we can explore, but for this post I think this is enough. These are the main values I would check to evaluate "Agility". If not we fall to believe that it is a set of "Practices". (what is partially True, but not complete)

Of course you can keep reading more deeply, this topic and many others in my last Book: 

Make Scrum Great Again

Thanks for reading,

Happy Flow!

Daniel Ceillan


Free online webinar: Agile Coaching

Hello Agilers!

This time I share with you a Free Online Webinar!

Yes, this time you are not only reading, watching a video, or listening to me. This time we can discuss together on live about Agile Coaching topics.

You can find this event in Xing, or if you don't use Xing, and want to be part, send me direct an e-mail.

Here you can see the first delivery:

I hope you enjoy it, and you can be part of this history with me! 

Thank you and see you online! 



Agile = Hardware + Software

Hello Readers!

Today we are going to explore an alternative perspective to evaluate the "Agility" of a Team, Project, Organization, etc.

One way I like to explain it, is to compare with the concepts of Hardware and Software from the computer science.

Hardware are those part of a computer that we can see, touch, weight. The physical side.

Software is the computer reality that we cannot touch or weight.  (many people says that it is that part that you can only blame).


To understand the alternative model that I propose to you today, we need to distinguish between these two kind of components: tangible and intangible.

There is many common assumptions, that Agile is for example:
  • “to do iterations” 
  • a set of practices that must be well done
  • to go faster
  • tests automation

These assumptions and generalizations are partially true, but they are a little bit problematic: they skip us to think that Agile could be something more than that. They stay in the "surface".

Starting from these assumptions, we can make the mistake to focus only on the "Hardware" side:
  • how to write a User Story
  • how to Estimate
  • the Backlog
  • team structure
...every other reality that is visible and obvious. We could say: the "Mechanic" part.

We can say that a "Mechanic Mindset" will see everything as a process, and will try to manipulate the "pieces" without understanding reality's intangibles.

Robot, Woman, Face, Cry, Sad

The problem indeed is that we can do all practices right and good, and anyway our project can go down and out. We can fail. People abandon the company, there is conflicts, apathy, lack of commitment and trust.

Everything that I've just mentioned are related to the "software side" of our Agile reality. That's why today I want to offer you a model to understand the hole reality:

Agile = Hardware + Software

Of course process and methods are important, but the "invisible" side has its own importance. To have a "Mechanic Mindset" in the Leadership can create problems.

One example, that affects directly team's "self-organization", is when the teams are restructured by top-bottom decisions. As a metaphore, People are reassigned to other teams like moving pieces in a chess board. (like "resources")


How can we classify all factors into Hardware and Software? Let's take some examples:

Hardware (methods, tools, processes):
  • How to write a User Story
  • Meetings duration and structure
  • Post-its color and quality
  • Team structure and “resources” assignment
  • Estimation method
  • Code Coverage
  • Feedback method

Software (feelings, values, believes):
  • Trust 
  • Motivation 
  • Business Values
  • Fear 
  • Commitment 
  • Respect 
  • Culture 
Then, how many times we worry a lot about processes and tools? How many times we worry more about the "Hardware", than the "Software"?

Is your Scrum Master / Agile Coach taking care about both: "Hardware" and "Software"? 

Ok, once we got awareness about this reality, the next question is: "what can we do about?". 

Which Tools do we have to work with the "Software" side of Agile?
  • Motivation and engagement: coaching, mentoring 
    • To make a general "happiness review" once a year is not good enough. The year has 365 days, and every Human Being is different. The Coaching and Mentoring methods are focused on individual and its necessities. 
  • Trust: fail-friendly environment, free speech, no judgments, respect. 
    • Strong Hierarchies with a control-oriented Mindset will be the "Trust predators". An environment where everything that you say, could be used against you, or any minimal failure will be punished, is a desert where the Trust seeds will not find where to grow.
  • Culture: meetings, values, learning spaces, hiring and firing
    • The Culture is one of the invisibles that may more impact on success chances could make. Its a part of the solution or part of the problem. The companies, normally, don't have budget problem, or lack of opportunities. They usually have Cultural problems, that holds them back to be able to escalate, retain talent and succeed. 
    • More over, to implement Scrum or Agile without a cultural change, don't have sense. Is what is commonly called a "cosmetic" solution.
The important point right now, is to relect about what is a True and Authentic Agility.
  • To be Agile is to write User Stories? you can be agile without User Stories
  • To be Agile is to do iterations? you can be agile without iterations 
  • can someone be Agile without respectful relations?
  • can someone be Agile without Trust?
  • can your team be Agile without Motivation?
I leave the answer open, each one can find your own opinion.  

Thank you for reading! Your feedback is welcome.

Agile Regards,


PS: I explored this topic and many others in my last Book: 

Make Scrum Great Again


In Memory of Mike Beedle

The Agile - Scrum world mourns the lost of Mike Beedle.

Mike Beedle (1962 - 2018) was a Signor of the Agile Manifesto, the Second adopter of Scrum and one friend of mine.

I have the pleasure to receive my first Scrum Master course with him in Buenos Aires, during 2011.

I remember how he eplain to me the concept "adaptative team", he gave an example of a robot, during one of his academic works, and how this robot avoids dangers through sensors. This robot was able to avoid to fall down the staris, by turning direction. And that's only possible through Feedback.

Also I remember how he insisted into Motivation as a great responsibility for Scrum Masters, and he describes this roles as the "chearleeder" of the team.

He was a Genius, he understood how to deal with chaos, and gave great contribution to Scrum conception. He was always very low profile, and not only apply his ideas to make his own companies successful, but also shared his knowledge and traveled the world spreading the new way to work.

Thanks Mike! You are now in Scrum's history.

Colleagues for ever.



Believe it or not...

Now I remember that there is things that are like the gravity force... we don't need to understand it to make it works...

One guy starts to float and to elevate to the infinite and starts to scream "SOMEONE PLEASE EXPLAIN ME THE GRAVITYYYYYY IT IS NOT WORKIIIIIIIIIIiiiiiiinnnnggggg....."


Gravity works instead you like it or not, you understand it or not, you believe it or not.

Also in the ancient ages there was people that won battles thanks to the gravity force, letting some rocks dropping from a hill, and those who won the battle didn't have any idea about what the fuck was moving the stones drop down.

Some people will think "this about gravity is a fashion, I'm now in the post-gravity stage". Others will think that "this about gravity is a process and to make it works you must do it always the same way". And others will think "gravity is an spirit that binds as to the Earth, is the Love of the Planet that keeps us attached to our fate"

The truth is that doesn't matters what you think, what you believe, what you understand, what you reject... gravity will be working for you, or against you and maybe that will be the difference between win or loose today's battles.

Agile has some relation with this, is to recognize thing's nature, human's nature and team's nature. Is to accept that nature, and to put it to work for the results. Without care how much intangible or incredible it should appears some times...

Send me your opinion!

Understanding Transparency

Hi All!

This time we will review the concept of Transparency.

Let’s read the Scrum Guide:

Definition of “Done” When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

Now we are going to analyze this story:

  • Hi Tom! Welcome back! Hey we are defining the next business objective, can you view it?
  • Hi Peter! Yes of course! I can see it, very nice draw! What you need to know?
  • I need to know if you agree that it is a number…
  • Yes, for me it is a number! so we are ready to go for the next business objective. 

Some weeks later they discover, too late, that Tom understood the number was a 6, and Peter understood it as a 9. So we can have visibility, we can have an agreement… but transparency starts when we have the same understanding about the same thing.

Thanks for reading!

Send me your opinion!

An example of Product Ownership

Hi All!

Today, I want to share with you this video. It could be considered a reality film about a Real successful Product Ownership Process.

This video really made me think about Product Ownership. What caught my attention was the emphasis that the Leader makes over the people. And most important how he pushes constantly with the VISION.

I hope you enjoy it and this will be useful for you.

Thank you!

An Agile view to Optimize your Business

If you don’t know how an Agile view could optimize your startup business, here you have an example.

"37 signals" are the creators of tools like Basecamp, and they tell their story in this book.

“Getting Real”


I strongly recommend to read this book if you are at least thinking on starting a new business. This can save a lot of waste in the process, and help you to “feel” the market and find the best business opportunities.

For an entrepreneur, is very important to develop his “explorer” skills, and to keep his mind open and wide.

You can have the pdf book for free.

Send me your opinion!

Comparison of software development processes.

Hi All!!
This time I created for you a little story, you might like it.

Once upon a time there was a Customer who meet with several development teams.

The Customer wasn't able to pick one team, so he setted up a match with all of them, and the Winning Team will win the hole customer's portfolio.

Curiously, each team informed that they will use a different development methodology. Everyone started at the same time ... while some moved directly to develop after a little customer's introduction, others meet with him and make some questions.

Of those who stayed chatting with the client, some developers maked requirements quickly and the rest made ​​requirements using arduous and endless meetings to define the product specs to develop ...

After a few days we have the first teams that presents their final product. Those who used light requirements begin development and get meeting weekly with the client. Those who use hard requirements were still working on specs.

After three months most of the teams deliver the product, including those who made light requirements too. The group behind hard requirements is still working hard behind closed doors.

After a few months some groups surrender and deliver the product as it is.

In a couple of months more, the more strict teams finish and deliver ...

Go now and see the result...

Here is what the customer had in mind:

Some Teams made commercial proposals:

These are the hard functional specs:

These are the quick and light specs:

These Teams used old solutions:

Those fans of propietary software:

Those who chose a Software as a Service:

Those who chose closed solutions:

Those fans of reusing what exists:

Those who hired a freelancer:

Light spec, but without approximation:

Incremental method. They don't start a module, until finish another first:

These guys used an ego approximation:

These guys used an evolutive approximation process:

What Waterfall could deliver:

These had budget problems:

I hope you liked this.

Match's winner: "The evolutive approximation process". Will talk about that later.

Send me your opinion!