I’m happy to share that I just received the new that I’m attending: Global SCRUM GATHERING® Prague 2015.
I can’t wait to go and learn more!
I’m happy to share that I just received the new that I’m attending: Global SCRUM GATHERING® Prague 2015.
I can’t wait to go and learn more!
As promised in my previous post “Does the Change Agent Networks work? In my case the Agile Champions…” I said that I would share some conclusions about this model implementation.
During this time I didn’t said nothing because I needed some time to start seeing the first results. Well, good or bad…
As you know, transforming mentalities doesn’t work from night to day. In reality takes time and in some situations more time than expected.
Having this said, I would like to start by giving some context in case that you are reading this Blog/Post for the first time.
As an Agile Coach I’m responsible for providing guidance and support in agile concepts and principles to multiple teams distributed across 3 locations (Portugal, United Kingdom, and Romania) in the company that I’m currently working.
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.
So, during one of the many conversations that I had, one person in particular asked why shouldn’t we try to motivate and empower people to be change agents? From that moment I started to plant this idea, like a seed, in everyone’s mind.
Now it’s the time to share some conclusions but please keep in mind that this is work in progress. In other words this is on-going work will never be complete.
The first step was do a roadshow by all locations with the objective to share what was an Agile Champions and what was expected from them. The first reaction was not what I was expecting. Meaning that, almost everyone was with the suspicious look. Also, because cause some confusion. They thought that was another role or more responsibilities added to their current role if they accepted.
From this moment, I had to keep working with them. Clarifying any existing doubt what was an Agile Champion “ An Agile Champions is some one that truly believes in Agile and the change. Believes what are the benefits that can come with the change and is ready to take actions to bring more people on board”. I can say that was a motivational and coaching continuous work.
After achieving this first step, some people started to attend the weekly meetings. During this meetings we discussed what could motivate people to become an Agile Champion, to attend the Agile Communities sessions (share and learn) and to have the will to take actions and bring more people on board. Agin, this was another critical moment. Lucky went well since I had people believing in Agile and committed to this, as well, the Leadership Team support. They were the key to keep this proceed to success even in a slow pace.
It’s funny because if I go back in time, the reality was that I only had one or two Agile Champions since the beginning. Was our work together that made more people to believe and have the will to join us.
At this moment in time we had a small group on each location but I still had the need to drive these meeting and communities. Everyone was expecting that even during this time I was saying that would be really great if they wanted to do it.
Luckily or not something happen accidentally. After a few months suddenly I had the need to start traveling more. Meaning that, I was unable to attend all the weekly meetings and community sessions on all locations. The surprise was that in a natural way they were more committed and self-organised than they and me were expecting.
They started to schedule the weekly meetings, discuss what they could do to keep improving, talk about ideas for the Agile Communities on each location, how to involve and bring more people on board.
For me this was a magical moment! The moment that the Agile Champions had become Change Agents! The moment that I truly believed that the viral change was going to work!
Please let me know if you have any question or share your own experience on this subject. I would like to ear your thoughts and opinions too.
After the Lean Coffee Porto continued success, today’s post is related with the Lean Coffee Braga.
This happened yesterday in the beautiful city of Braga at Primavera Software.
If you asked me some time ago “Did you believed that in a short period of time would exist the Lean Coffee Porto and 3 months later the Lean Coffee Braga would start”, I would say no. But I was wrong!
They are real, they are a big success!
Not just due to the Co-Founders but to everyone involved. That, after a day working day, they are still motivated to attend, share experiences and learn.
I’m a truly believer that together we can grow more and faster.
For more details please check the bellow links:
Many thanks to everyone for making this real!
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:
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.
References:
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]
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.
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.
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.
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.
References:
[2] Businessballs | Tuckman Forming, Storming, Norming, Performing model
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 😉
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.
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?
References:
[1] Roman Pichler | Agile Product Management with Scrum: Creating Products That Customers Love
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.
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?
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.
For some time all the discussions that I had regarding this subject I’ve encountered people with different opinions as described bellow:
Nevertheless, I also encountered positive opinions as described bellow:
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?
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:
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:
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).
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 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.
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 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.
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 measures how disciplined a team is in preventing defects.
What does this implicate?
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.
This chart provides a way for business and teams to track their performance over time against its previous performance.
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.
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.
References:
[1] Wikipedia | Performance Metric