Does the Change Agent Networks work? In my case the Agile Champions…

Well… I just started to implement this model in the company that I’m currently working and my first feedback is positive. But only time will tell if it was a success or not 😉

Lets go back in time to understand why we are trying this model.

As you know we live in a world that is made of different people, mentalities and cultures. Due to this, we need to keep improving and find new approaches and models to help implement changes.

After working for a period of time with different environments and cultures, I’ve realised that some times it’s really hard to help people to change even when that change is beneficial to them, others and the business.

Some time has passed, conversations and discussions took place with different people, but, one person in particular asked why shouldn’t we try to motivate and empower people to be change agents?

Why not try this approach?

From that moment I started to plant this idea, like a seed, in everyone’s mind. So far so good!

Coincidently, this week I was reading a book that elaborated on this same idea and I’ve summarised their thoughts on the following quote:

“You will need executives, managers and staff to act as change agents. That’s because people are more likely to listen to, and work with, their peers rather than external consultants or dedicated change agents.

People tend to feel threatened or feel that change is being pushed on them if they don’t see their peers jumping in first. This approach helps the change go viral, and helps build the momentum.

Here are some tips for expanding our change agent team:

  • Get at least one person from each business area that is affected by the change.
  • Set strong expectations with the early adopters that being part of the change team is extra work.
  • Make becoming a member of the change agent network exclusive in order to attract the right people. I’ve always wanted to try some American Idol style audition, but that has been to crazy of an idea for the organisations I’ve worked in!
  • Agree on rotating the type of change you’re implementing.

Most of all, give early adopters support, training, and some autonomy. Notice I said some autonomy. At this point you want the people who are motivated to help execute the change, but be aware, thy may not have the necessary skills you, as a change agent, have.

Change goes viral when people start helping other people adjust.

These people, who weren’t part of the core change team, starting taking ownership of roadblocks all the teams were facing. They would provide updates to the whole departement during our monthly retrospectivs and the change team supported their efforts.” [1]

As a last thought I will be sharing with you (when possible) all the experiences, situations, issues, successes about this path that I’m taking so we all can learn together.


[1] Jason Little | Lean Change Management

Is trusting relationship and symbiosis a myth in Self-Organising teams?

As you know one of the Scrum Principles is Self-Organising Teams. This means that, the teams should include all required roles to bring the product or feature to life.  Also, all team members from the Scum Team must form a close and trusting relationship, a symbiosis in order to allow them to work together as peers. Shouldn’t exist us and them but only us.

Ir order to create this relationship and symbiosis they need pass through the four-stage model as described by Bruce Tuckman’s: [1]

  • Forming – Stage 1

In this stage, most team members are positive and polite. Some are anxious, as they haven’t fully understood what work the team will do. Others are simply excited about the task ahead.

As leader, you play a dominant role at this stage, because team members’ roles and responsibilities aren’t clear.

This stage can last for some time, as people start to work together, and as they make an effort to get to know their new colleagues.

  • Storming – Stage 2

Next, the team moves into the storming phase, where people start to push against the boundaries established in the forming stage. This is the stage where many teams fail.

Storming often starts where there is a conflict between team members’ natural working styles. People may work in different ways for all sorts of reasons, but if differing working styles cause unforeseen problems, they may become frustrated.

Storming can also happen in other situations. For example, team members may challenge your authority, or jockey for position as their roles are clarified. Or, if you haven’t defined clearly how the team will work, people may feel overwhelmed by their workload, or they could be uncomfortable with the approach you’re using.

Some may question the worth of the team’s goal, and they may resist taking on tasks.

Team members who stick with the task at hand may experience stress, particularly as they don’t have the support of established processes, or strong relationships with their colleagues.

  • Norming – Stage 3

Gradually, the team moves into the norming stage. This is when people start to resolve their differences, appreciate colleagues’ strengths, and respect your authority as a leader.

Now that your team members know one-another better, they may socialize together, and they are able to ask each other for help and provide constructive feedback. People develop a stronger commitment to the team goal, and you start to see good progress towards it.

There is often a prolonged overlap between storming and norming, because, as new tasks come up, the team may lapse back into behaviour from the storming stage.

  • Performing – Stage 4

The team reaches the performing stage when hard work leads, without friction, to the achievement of the team’s goal. The structures and processes that you have set up support this well.

As leader, you can delegate much of your work, and you can concentrate on developing team members.

It feels easy to be part of the team at this stage, and people who join or leave won’t disrupt performance.

This is why we should minimize any teams change since Its takes time to become a true team – a tightly unit with members who trust and support each other and who work together effectively.

Changing teams compositions makes the team-building process (four-stage model) all over again and in the end self-organisation suffer.


[1] Mind Tools Club | Forming, Storming, Norming, and Performing, Understanding the Stages of Team Formation

[2] Businessballs | Tuckman Forming, Storming, Norming, Performing model

AGILE ADRIA CONFERENCE 2015 :: TALKS “How” to go beyond Scrum and Agile Performance Metrics

Was with great pleasure that I found out this yesterday.

“It is a great pleasure for me to tell you that your talk proposal for Agile Adria 2015 was accepted. We’re looking forward to meet you in April.”

I’m really happy to be doing these two talks described bellow:

Also, share and learn with everyone!

Nevertheless, now is time to start working and find sponsors for the trip 😉

Should we establish Business Value per each Work item?

One of my previous posts was related with Agile Perfomance Indicators and their use in order to understand teams and business behaviour.

From that moment, I didn’t stop thinking how could we improve one of these performance indicators. In other words the “Delivered Work Items”.

As everyone knows, when we deliver a work item we are delivering or should be delivering value. Nevertheless, I do agree this is a complex and very subjective metric to try to come up with.

Screen Shot 2015-02-06 at 23.39.15

After having surfed a bit the web I found an interesting article on this topic. Why not establish Business Value Points per each work item?

Roman Pichler in the book Agile Product Management with Scrum says:

“Value is a common prioritisation prioritisation factor. We certanly want to deliver the most value items first.” [1]

Well.. I do believe that, with this approach the Product Owners have a better way to understand each work item and their priority to be implemented by the teams.

Nevertheless, after discussing this subject and article I received the following question:

“What happens when a team starts to get consistently work items that have low points? Do they get demotivated?”

My thoughts and my answer to this question was:

A team shouldn’t just receive US with low Business Value Points. What can we do to change that?

Also, should we implement a feature that has low business value, or should we pick up features with more business value?

What are your thoughts about this subject and approach?


[1] Roman Pichler | Agile Product Management with Scrum: Creating Products That Customers Love 

Jez Humble on Valuable Software

I would like to share with you this amazing talk.

Here Jez Humble – co-author of the book ‘Continuous Delivery’ – speak on how to focus on producing valuable software: designing for failure; culture change; the tyranny and irrelevance of ‘on time, on budget, in scope’; and daily practices.

Is the river the flow and the boats the user stories?

Well, during the Kanban Coaching Exchange Meetup today, Tom Sedge shared this thought “The river is the flow and the boats are the user stories”.
In my opinion I agree whit this since smaller user stories are faster to understand, implement and deliver by the team.
This also means that, big user stories are like big boats that can have hidden complexity, are harder to implement and can become the bottleneck for the flow/sprint that is been played by the team.

What do you think about this?

Agile Performance Metrics… Are they useful or not? Which should we use?

Today’s post is related with a hot and controversial topic that is the Agile Performance Metrics.

Why? Well, as you might be aware we have different opinions from from different stakeholders on what concerns Agile Performance Metrics.

  • Why should we use?
  • What value they bring?
  • How should be applied?

For some time all the discussions that I had regarding this subject I’ve encountered people with different opinions as described bellow:

  • We shouldn’t use the performance metrics because they don’t bring any value.
  • We should’t use the performance metrics because stakeholders and management will start to compare teams.
  • We shouldn’t use performance metrics because we don’t have indicators that shows the real work of the teams.
  • Etc.

Nevertheless, I also encountered positive opinions as described bellow:

  • They are great since we can understand what is going on and tackle issues as soon as soon as possible.
  • We can understand the business and teams behaviour.
  • The information is already there and this will allow us to have a clear view of what is going on.
  • We an be assertive when we need to take decisions since we have detailed information.
  • Etc.

Textbook definition tell us that “A performance metric is that which determines an organization’s behavior and performance. Performance metrics measure an organization’s activities and performance. It should support a range of stakeholder needs from customers, stakeholders to employees.”. [1]

Saying this, my opinion is that the primary objective is to provide the teams and the business with metrics that enable them to track their performance over time against its previous performance at any time.

Why should we use it?

  • We should use it since this help us to measure the impact of our initiatives.
  • For example, focusing on quality, we expect to see a drop in defects and if not, then our strategy isn’t working and we need to try something else.
  • Again emphasising that this is not for comparing teams but it’s to look at our wider initiatives, checking if they are having the desired effect.
  • Nevertheless, this will allow us to achieve our common business objectives by taking actions at the correct time and increase the performance for all our teams.

Many people believe that from an Agile perspective we should only use velocity as metric. Meaning that, with this metric they can understand the business and team behaviours.

Well… I agree that velocity is a good metric, but I also believe that in order to keep improving we should implement new indicators to have a more accurate information regarding behaviours.

Saying this, in my opinion we should use the described bellow:

  • Delivered Work Items

As you are aware one of the Agile Principles is continuous delivery of valuable software. [2]

For that we have the acronym INVEST originated in an article by Bill Wake in 2003. This helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one). [3]

A good user story should be:

  • “I” ndependent (of all others)
  • “N” egotiable (not a specific contract for features)
  • “V” aluable (or vertical)
  • “E” stimable (to a good approximation)
  • “S” mall (so as to fit within an iteration)
  • “T” estable (in principle, even if there isn’t a test for it yet)

Saying this, in my opinion Delivered Work items measures how much work a team delivers over time, based on the number of work items accepted per team member.

More work items delivered means more business value has been delivered or more technical debt has been reduced.

Never forgetting that points are a relative measure for each team. Each Item accepted applies through the DOD.

What does this implicate?

We want to give value to smaller work items (INVEST – Independent, Negotiable, Valuable, Estimable, Small, Testable).

Screen Shot 2015-02-07 at 00.07.53

Throughput is the number of items completed over a period of time per full-time person on the team. In this variant it’s the number of work items moving into the schedule state “Accepted” minus the number of work items moving out of “Accepted” within the timebox, divided by the number of full-time equivalents.

Why this is important?

Throughput shows how well work is moving across the board to accepted. This can be adversely affected if work items are frequently blocked or inconsistently sized.

  • Consistency of Delivered Work Items

Consistency of Delivered Work Items measures how consistent a team is at producing work over time. High consistency means stakeholders can confidently plan when work will be delivered.

This is also an indication that teams are better at estimating their work and flowing consistently-sized increments of value.

Consistency score is a percentile ranking derived from a three month window of a team’s Variability of Throughput. Predictability can also be configured to include variability of velocity or the standard deviation of time in-progress.

What does this implicate?

Variability of throughput is computed by finding the average (mean) and standard deviation of throughput for 3 month time periods. The coefficient of variance is the standard deviation divided by the mean.

Screen Shot 2015-02-07 at 00.09.13

For the Throughput StdDev and Throughput Mean we could use the last 3 months.

Why is this Important?

Consistency is critical to accurately planning delivery dates and budgeting.

The variability of Delivered Work Items shows if your team delivers the same amount of work each month. This can be adversely affected if Work Items are frequently blocked or inconsistently sized.

  • Work Items Lead Time

Work Items Lead Time measures the ability of a team to deliver functionality soon after it’s started. 

High Lead Time can dramatically impact the ability of businesses to react to changing markets and customer needs.

What does this implicate?

The Lead Time score is a ranking calculated by the amount of time required for a team to take a single story or defect from start to finish.

Screen Shot 2015-02-07 at 00.10.14

P50 is the Median (Sort and pick the middle for those who didn’t go to school)

Note: It’s Median and not Average because there are usual irregularities that would negatively affect the average (for example, a single user story that took 2 weeks to complete).

Why is this Important?

Low Lead Time is central to Agile. Teams that are more responsive have faster time to market, and react more quickly to customer feedback.

Time in Process is the number of business days a typical user story is in the “In-progress” or “Completed” column. Similar to lead time, cycle time, and time to market.

Accurate planning and budgeting requires work items that are estimated to be short, testable and easily deliverable. Time in Process shows how long the median of Work Items are in process.

  • Quality

Quality measures how disciplined a team is in preventing defects.

What does this implicate?

Screen Shot 2015-02-07 at 00.10.54

All defects should be assign to each team accordantly with their Product/Component ownership and User Story. Worst case scenario in case that we are unable to do that, I believe that its more fare if we count all defects from the Product/Component and then we split trough all the teams working in the Product/Component (this means that every team inside the same Product has the same Quality).

How could combine these four metrics in order to understand the global behaviour?

Please find below two exemples on how could we combine the four metrics in order to get a simple, tranparent and quick view that can be read by all stakeholders including Management.

  • Performance Chart (Higher is better)

Performance Chart

This chart provides a way for business and teams to track their performance over time against its previous performance.

  • Overall Chart (Higher is better)

In the Overall Chart, each metric (described below) weighs 25% of the performance, totalling 100%. Once more provides a way for business and teams to track their performance over time against its previous performance.

Overall Performance Chart

Its important to keep in mind that each metric should be calculated at each month. This way we can avoid any issue regarding different Sprint start and end time by any team.

Why is this important?

Sustainable delivery of value requires a consistently high level of Quality for all work delivered to production.


[1] Wikipedia | Performance Metric

[2] Agile Manifesto | Principles behind the Agile Manifesto

[3] Agile Alliance | Invest

Lean Coffee Porto Community!

Today’s post is related with the beginning of Lean Coffee Porto Community.


The story begins 3 months ago, when a group of people with the same objectives and dreams started to discuss what they could do to share knowledge and create discussions of ideas regarding different areas like Agile, Lean and Tech.

Well, we discovered that more people had the same objective and dream, but in different parts of the world.

How? With the creation of the

Just to give you more context, Lean Coffee is a non-profit world community whose main objective is the development, sharing and discussion of ideas among stakeholders in different areas of knowledge within the Technological, Agile and Lean themes.

As a result from our discussions, we agree to create Lean Coffee Porto and voluntarily organize (in cooperation with and and Tuga) meetups and events in order to drive Portugal into a world reference in Agile, Lean and Technology.

Saying this, Lean Coffee Porto is already in-progress and we have our first meetup schedule for 14th of January 2015.

Join us at UPTEC for our first event and share your experience and knowledge! We will follow the Lean Coffee format presented at

Register at Eventbrite.


Nevertheless, I would like to share with you that Lean Coffee Braga is also already in-progress. Soon, we will be sharing further details regarding the first meetup.

“How” to go beyond Scrum and use Lean in Software Development Teams?

Once more I would like to share my thoughts/opinion with everyone about this new subject – “How” to go beyond Scrum and use Lean in Software Development Teams?

In order to give you some context, I will start by explaining ShuHaRi concept, as well who introduced this concept in Software Development.

ShuHaRi as some of you might know is a Japanese martial art concept, this concept describes the different stages of learning to mastery. [1]

Aikido Master Endō Seishirō Shihan stated that “It is known that, when we learn or train in something, we pass through the stages of Shu, Ha, and Ri.” [1]



  • Stage of Shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. [2]
  • Stage of Ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. [2]
  • Stage of Ri, is the last stage where we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws. [2]

But who introduced this concept in Software Development?

This learning technique and methodology in software development was introduced by Alister Cockburn.

His idea is that every person go through the three ShuHaRi stages in order to obtain knowledge.

Meaning that:

  • In the Shu stage since it’s the first one, the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
  • Next stage is Ha, at this point the student begins to branch out. With the basic practices working, he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
  • Finally in the Ri stage, Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

The fundamental idea here is that when teaching a concept, you have to tailor the style of teaching to where the learner is in their understanding and that progression follows a common pattern. Early stages of learning focus on concrete steps to imitate, the focus then shifts to understanding principles and finally into self-directed innovation.

In my opinion it’s very important to understand the ShuHaRi concept and technic before anything, because we can understand the variation of do agile or being agile by understanding first the level of agile and lean knowledge. 

So, how should everyone see and believe in these eleven principles after blending with Lean. Well in my opinion I truly believe that should be like this:

  • Satisfy the customer… -> Delight the customer.
  • Welcome change… -> Seek change.
  • Deliver frequently… -> Deliver continuously
  • Work as a team… -> Live as a team
  • Talk, face to face… -> Talk, face to face & heart to Heart
  • Mesure working product… -> Measure value delivered
  • Maintain pace… -> Maintain pace and rhythm
  • Exceed at quality… -> Exceed at quality and get stuff done
  • Keep it simple… -> Keep it simple stupid
  • Envolve Team… -> Envolve everyone
  • Reflect regularly… -> Reflect continuously 

Quoting Voltaire “Common sense is not so common.”.

Saying this, I’ve been taking a shot on what it would take to “How” to go beyond Scrum and use Lean in Software Development Teams. In order words how we can learn, apply and practice Lean Principles to what we currently do well using Agile Scrum in Software development Teams trough the different stages of ShuHaRi in order to keep improving.

  • First stage Shu:
    • In order to start the Lean teaching/coaching, we need to have the team in a high maturity level (Ha stage in what Agile Scum regards). This will avoid any confusion and issues with the team mind set regarding what they currently do (how and why).
    • Next step is teach and coach them on what Lean concerns. Explain what is Lean, what are the principles, techniques and why everyone should be. We can achive this by trainings and workshops.
    • Now is the moment were we help them to achieve some conclusions on what they can do to keep improving. We can review what they already do using the Value Stream Map technic (Development, Testing, Scrum Ceremonies, Communication, Process,etc.) in order to raise performance by achieving more results, with less resources,  by the continuous and relentless elimination of activities (waste) that do not add value to the service or product. Its important to make them understand that Lean applies to any organisation and follows the pursuit of perfection, thus is a never-ending activity.
    • Nevertheless, during this stage we need to make them understand that this a critical period were they need to follow and practice each point without any variation. Also, that during this time they will have all the support to help them growth in maturity and knowledge.
    • Why keep the team for a period of time in this stage? Tin order to answerer that I will quote Leonardo da Vinci,  “Simplicity is the ultimate sophistication” so lets stick to this for the time being.
  • Second stage Ha:
    • In this stage they already follow the principles, meaning that we can start stepping back and give them space to be Lean. This means that they are using and combining the Agile Scrum and Lean Principles by themselves. This will empower them to transform the principles in values to follow. Act as self-organising that they are. Nevertheless, we will keep observation and coaching when its needed.
  • Last stage Ri:
    • This is the final stage and they are already confident and with maturity to follow the path by them selfs. For me this a great achievement because as we speak they don’t see the principles as principles but as values and their believe in them is high. This is the moment that they pass from students to masters. Meaning that they will start inspiring others teams , converting them to go beyond Scrum and use Lean.

After this moment they will act as master like you in order to start converting a full organisation. Thus, we need the managers support in other to achieve this faster than was expected.

I truly believe that this is the best way to change (Convert a full) Organisation.


[1] Wikipedia | ShuHaRi

[2] Aiki News | An Interview with Endô Seishirô Shihan

Alistair Cockburn | Agile Software Development

My thoughts and opinion about Lean Software Development

This is my first post about Lean Software Development. The reason why I’m writing this is to share my thoughts and opinion. Also, due to the request of several families 😉

First things first:

  • This is NOT an Anti-Scrum campaign!
  • I am NOT “selling” Lean!
  • I am NOT a Lean expert!
  • What you currently do is NOT wrong!

To start I would like to say that for me Lean is a “ Thinking” as described in many books. Nevertheless, besides that, for me is a Philosophy something that you are or not. Like one of my work colleagues said is a group of common values. I agree with him but we really need to believe in them in order to follow and apply them. In other words be Lean.

In my opinion we can say that Agile Software Development is a great example of Lean thinking in action. Why? Lets dig a little more 😉

But, in order to start we really need to know what are the key seven principles: [1]

  • Eliminate Waste
  • Amplify Learning
  • Decide as late as possible
  • Deliver as fast as possible
  • Empower the team
  • Build integrity in
  • See the whole

Lean Software Development is the application of the Lean Principles (Lean Toyota Productive System) to software development. So, once more what is Lean? [2]

The National Institute of Standards and Technology Manufacturing Extensions Partnership’s Lean Network describe Lean as:

“A systematic approach to identifying and eliminating waste through continuous improvement, flowing the product at the pull of the customer in pursuit of perfection.” [3]

“Lean Software Development reduces defects and cycle times while delivering a steady stream of incremental business value.” [4]

In other words we can say that Lean Software Development is more focused than other Agile Methodology in order to develop software in less time, using less budget and with a lower defect rate. [5]

Lean Software Development give us principles and tools that are easily used in any environment to improve software development. [6]

There are seven Lean Principles as described above, but lets understand and learn more about them:

  • Eliminate Waste: Some exemples in software development are any implementation that doesn’t improve the quality of code or doesn’t deliver business value to the customer. But we also have examples of process that doesn’t bring any value to the business and the customer.
    • Tools: Seeing Waste, Value Stream Mapping.
  • Amplify Learning: Developers implementing features that delivers business value, they will have to learn about many things. Some are technical, such as the advantages and disadvantages regarding different tech approaches. Others are requirements related, such as understanding what the customer needs versus what the developer think that the customer needs.
    • Tools: Feedback, Iterations, Synchronisation, Set-based Development.
  • Decide as late as possible: Software development is always associated with some uncertainty, better results should be achieved with an options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. The more complex a feature or system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. The iterative approach promotes this principle. In order words the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the release of the feature or system.
    • Tools: Options Thinking, The Last Responsible Moment, Making Decisions.
  • Deliver as fast as possible: This is the foundation of iterative development. Why? Because allow us to Reduced risk, have an Earlier ROI/Value, Increased visibility of progress, Increased predictability, Increased productivity, Reduced waste. Also, it is much easier to get customers happier by getting their features or systems at the end of each sprint rather than wait for a month or an year.
    • Tools: Pull Systems, Queuing Theory, Cost of Delay.
  • Empower the team: The people factor is the most important element in successfully delivering software. In order to get people motivated, happy and self-organized, they need to be able to take ownership and responsibility for the outcome. In order words authorised to make things happen.
    • Tools: Self Determination, Motivation, Leadership, Expertise.
  • Build integrity in: The Perceived Integrity is the Customer experiance. In order words the overall experience of the Product (Feature or System) how it is being advertised, delivered, deployed, accessed, how intuitive its use is, price and how well it solves problems. The Conceptual Integrity is how well the architecture and system components flow together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness. Obviously testing, unit and integration, is a major part of integrity. [1/6]
    • Tools: Perceived Integrity, Conceptual Integrity, Refactoring, Testing.
  • See the whole: We should to see and understand the system as a whole. Why? Because systems nowadays are not simply the sum of their parts, but the interactions from all parts. Being able to see as a whole, means that we are able to solve problems easily and faster. How? By breaking them them down into their constituent parts and optimize each individual piece.
    • Tools: Measurements, Contracts.

For a second post regarding Lean Software development I will focus the different type of Wastes more in detail.


[1] Wikipedia | Lean Software Development

[2] Wikipedia | Toyota Production System

[3] Kilpatrick, Jerry | Lean Principles

[4] Windholtz, Mark | Lean Software Development

[5] Highsmith, Jim | Agile Software Development Ecosystems

[6] Poppendieck, Mary and Tom | Lean Software Development: An Agile Toolkit