The stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 830 times in 2014. If it were a cable car, it would take about 14 trips to carry that many people.

Click here to see the complete report.




I’ve recently facilitated a route cause analysis for a feature that we have failed to deliver within our estimated range. Worth to mention that our estimations were adapted during our feature development, we scoped out a few functionalities but still we exceeded our maximum estimated delivery date.

The analysis surfaced a lot of issues that we didn’t consider throughout our development phase. We’ve got a lot of insights and we suggested actions that need to be considered for our new feature. Soon we are going to have our feature retrospective (a.k.a postmortem) as well, to gather even more data and get more insights on ways we could improve ourselves and our organization.

We all benefit from this analysis except our feature! Post-mortems and RCAs are really useful, we learn, we improve but not all of us! Psychologist Gary Klein described it in one of his article really nice:

A postmortem in a medical setting allows health professionals and the family to learn what caused a patient’s death. Everyone benefits except, of course, the patient.

In that article (referred in 99u’s post) Gary Klein introduced the concept of pre-mortem as a method that could be used in the planning phase of a project. As it is stated, pre-mortem can improve project’s chances for success and can help project teams to identify risks in a very beginning stage!

Based on my recent RCA experience, i’ve experimented with the pre-mortem concept for another feature team that i am coaching and had started a really challenging and complex feature. The steps i’ve used are described below

the case study

In that step it is important to “illustrate” an imaginary failed state of the current project/feature. Adding details, using pictures, creating a kind of “script” could help the team “live” that unwanted state.

The “script” in our case was a failed deployment of the very complex telecom feature we have developed for a very demanding telecom operator. The consequences for our operator and customer was a huge amount of call drops for a few hours. Our feature team has received an email from our customer’s head of sw deployment describing the impact of this failure, the urgency to find a workaround and remove our feature from operator’s network.

why this has happened

After describing the case study all team members need to take some time to think of possible causes that triggered this failure. Using sticky notes we’ve gathered all the causes and discussed on them. We then tried to group them in themes and we prioritised them based on their importance and their contribution in that imaginary failed state.

It was interesting to observe that feature team members were felt free to express all possible causes came in their minds and they were more open comparing to post-mortem or root cause analysis for failures that have actually happened!

how we could prevent this

The next step is a brainstorming session to find ways to prevent this imaginary failure and anticipate all possible causes. In our case we decided to work on the top themes, based on our ranking from the previous step. The outcome of our brainstorming was a concrete set of actions that we are following up weekly. In the meantime we are enhancing the rest of the themes with actions that need to be considered as well.

keep calm and carry on

you can close the pre-mortem session with a message just to relax all participants :-). It was just a simulation and we have done our best to prevent this happening in real life!


We have used almost two hours to gather causes, group them, prioritise them and find actions for the top themes. As facilitator you will need an hour to think of a failure scenario (ask your feature team, PdO e.t.c to get a few details) and prepare a “script”

personal reflections

The feedback i’ve received from all participants was really positive. This exercise trigger their creativity, as it is mentioned they were more open to express all their concerns,  and they had a feeling of doing their best to increase the chances of success. As facilitator and observer i really feel that most of the benefits as described in Klein’s article were gained

Although many project teams engage in prelaunch risk analysis, the premortem’s prospective hindsight approach offers benefits that other methods don’t. Indeed, the premortem doesn’t just help teams to identify potential problems early on. It also reduces the kind of damn-the-torpedoes attitude often assumed by people who are overinvested in a project. Moreover, in describing weaknesses that no one else has mentioned, team members feel valued for their intelligence and experience, and others learn from them. The exercise also sensitizes the team to pick up early signs of trouble once the project gets under way. In the end, a premortem may be the best way to circumvent any need for a painful postmortem.

Are you ready to imagine a failure? or a success (a.k.a future-spective)?


inspiring reading

avoid a failure with a premortem

performing a project premortem

29-2s It is well known that we learn the most from our failed experiences and our mistakes!  According to Thorndike’s law of effect  it is the negative outcomes that accompany a failure that increase the probability to change or adapt our behaviour in subsequent events. However a recent research attempted to answer that people could learn not only from their failed experiences but from their successes as well! In that research three functions (or methods) that enable us to learn from our successes and our failures were described:

  • Self-Explanation: analyzing our behaviour and trying to find reasons why we failed or succeeded.
  • Data Verification: brainstorming different ways we could have approached the problem and how we might affect the outcome.
  • Feedback: determining whether there is success or failure, and then reflecting on why things went right or wrong and how need to be changed in the future.

The combination of all these functions that characterize a systematic reflection, motivate people to draw their lessons from past failed or successful experiences and eventually trigger a behavioral change.

Based on that research and working in an agile environment, where the attitude on failures, problems, challenges, successes is to transform them into learning that may involve further development and improvement,  i came up with a retrospective technique, as described below, to help teams grow an agile mindset!

retrospective goal

Encourage team members to reflect on the learning (on individual, or on team or both levels) from their failed and successful experiences and based on their reflections adapt or change their behaviour that will enable them to further improve.

retrospective process and practicalities

A board that is split in the following four areas and sticky notes to let team members right their experiences and learning will be needed.

Q1: where i/we have succeed (previous sprint/project/feature e.t.c)

Q2: what i/we have learned from our successes

Q3: where i/w have failed (previous sprint/project/feature e.t.c)

Q4: what i/we have learned from our failures

For every success or failed experience the relevant learning should be written. Depending on retrospective focus, you might trigger team members to think of their personal experiences and learning or on team’s experiences or both.

If you have a large team you might split them in subgroups to work on every area. I’ve tried quite a few times with really nice results. Sharing gathered data is a really important step. More specific sharing personal experiences and learning could increase psychological safety among team members, which in turn create an environment of trust in the team.

After sharing their gathered data on experiences and learning, it is important to focus on how the learning from their experience could trigger changes on personal and team level.

For a normal team (5-7 people) and for a period of sprint, one hour would be enough to cover all the above steps! (15′ gather data,20′ sharing and discuss, 15′ move forward and you will have a few minutes to reflect on the method used!)

facilitator’s tips

As retrospective facilitator you can use some of the following questions that could prompt participants to reflect on learning

how did you contribute to the performance observed in this failed or successful experience (self-explanation)

how effective were you in this failed or successful experience (self-explanation)

consider a different approach that could have been taken. What might have happened if that approach was chosen? (data-verification)

what has been learned from this failed or successful experience? What worked, what didn’t work? How will you behave in the future? (feedback)

personal reflections

I’ve received a really positive feedback from the teams i’ve used this method and this motivated me to share it in this post. I’ve received comments as well that helped me improve it ( secure that there is time for discussion on learning, focus on how could use our learning as a trigger for behavioural changes e.t.c). This retrospective technique will be more effective if you will try it with teams that are working some time together, they had faced various experiences in the past, their members are open to share and are willing to learn! But this doesn’t prevent to use it with new team as well. In that case it might be good to discuss with them about the importance of learning in agile environments, and that learning could happen from both failed and successful experiences!

Concluding for me it was really important that people spend some time and use their failures as information for further improvements and use their successes not only to increase their self-efficacy but as a trigger to revise how they managed to succeed on sth and set even higher goals and standards!

if you’ll experiment with that method, it would be nice to share your experiences and your adaptations!


interesting research

systematic reflection: implications for learning from failures and successes


“Be Proactive” is the first habit of highly effective people as Steven Covey described in his book “The 7 Habits of Highly Effective People”. Being proactive is about taking responsibility of your actions, of your behaviours and focus your energy and time on things that you can control!


One characteristic of proactive people is that they feel responsible for what they are doing and take responsibility of their own lives. They do not blame circumstances, conditions or other people. They act from a responsibility state and take ownership of their actions, outcomes, opportunities and problems. Being proactive it means taking control and making things happen rather than just adjusting to a situation or waiting for something to happen.

Christopher Avery has made a great work on that subject. According to his research he found that people lack of problem-ownership, rather than of problem-solving ability. People will own many of the pimg_resp_processroblems related to their role but they will not take responsibility for things that are wrong in their surrounding ecosystem (teams, organizations e.t.c). And this had to do with our mental process to protect our ego from painful situations of owning things that are going wrong.

According to this model there are different “irresponsible” stages until someone reach the responsibility. We might thing that in many cases we are not experiencing all these different position while trying to deal with a specific problem but according to Dr. Avery maybe this has to do again with our minds that continuously trying to protect us owning it. Despite the fact that we experience or not all of these stages it is important that 1) we have the intention to operate as much as possible from a responsibility position, 2) being aware of the different positions we might fall while dealing with a problem, 3) learn from our irresponsible thoughts and get improved.

I will not describe the different positions but i do recommend to spend some time and learn more about this excellent model. When it first happened to learn about this mental process i was really curious to apply it for myself. Having the intention to operate as much possible from a responsibility position and practicing as much as possible this mental process i could say that it has become one of my habits. I’ve seen many positive changes in my personal and working life just trying to be more responsible and avoiding all these positions that are causing stress and pointless conflicts. This doesn’t mean that i am always acting from a responsibility state,  but i am able to observe in which irresponsible stage i’ve been stuck and why! And this is a great self awareness learning! 

I’ve tried this model with a few teams that i am coaching and it was really nice to see that whenever we had issues to overcome we were reflecting on the model. This helped us to move forward without staying in positions that were just causing more frustration and stress. Worth to mention that it is important first to teach and experiment that model with your team and discuss about the importance of shared responsibility in teamwork. When you all have a common understanding of this mental process use it whenever there are issues that the team should deal with! Coach your team to operate from a responsibility position, and support them observe in which irresponsible stage they have been stuck in. Use it in a team retrospective to reflect on the impacts operating from an irresponsible position and which were the benefits acting from a responsible one! Post the responsibility process poster in team’s area for quick reflections!

circle of influence & circle of concern

Another characteristic of proactive people is that they focus their energy on things they can control. As described in the seven habits of highly effective people, the problems, challenges and opportunities we face fall into two areas. The first is called circle of concern (outer circle) and the second one circle of influence (inner circle).

mthem3Proactive people put their energy in the circle of influence. They work on the things they can do something about. Reactive people on the other hand focus their efforts in the circle of concern, on things they have little or no control. Being aware of the areas we put our energy and effort is an important  step in becoming proactive! To understand a little bit more that concept it is suggested to imagine a circle with all the things that we care about. This is our circle of concern. Then we should imagine inside that circle all the things that we can do something about, we can affect or control. Our goal should be to expand our circle of influence and shrink our circle of concern, in other words to stop worrying about things we have no control and start working on things we can influence and change!

Experimenting with that concept and inspired by John Ryan’s  post on kaizen map, i have used a similar approach to help teams and individuals visualising their impediments. My main goal was to help them focus on things they can actually control and put their energy there instead of dealing with issues or impediments that they have no or indirect control and were causing a lot of stress and negative feelings.


For the visualisation you can use a cartesian coordinate system. In the vertical axis you put all the issues and impediments based on the priority or importance (irrespective if we can control or not). The next step is to start moving the ranked issues to the left or the right part of the horizontal axis. On the left part you move those issues that you have direct control and you can do something about and on the right part the issues that you need help of you have no control. For these items you need proactively and responsible, to think of people and networks within your organisation and your surrounding environment, that could resolve them or could provide the necessary support in order to help you gain direct control.

Whenever i am observing situations where teams and individuals are stressed due to the number of issues they need to handle, i am always discussing with them about the concept of circle of influence and concern. The next step is to use that visualisation tool to make clear the things that they need to put their effort, based on the level of control and importance! The feedback i’ve received in all the cases i’ve used it was very positive and i am really suggesting to try sth similar!

Concluding the key for a behaviour to become a habit is practice! Becoming proactive requires that you are response-able and that you put your effort and energy on things you can control! At least there are a couple of things to try for these two behaviours!

Are you still worrying about the storm that is coming?


must reading/inspiring videos

the seven habits of highly effective people, Stephen R. Covey

the mindset of an agile leader, Christopher Avery

the responsibility process, Christopher Avery


Recently i’ve decided to try the Professional Scrum Master certification provided by I have to admit that it’s not an easy assessment! It requires that you have a good understanding of roles, events, artifacts, rules as described in the scrum guide and it requires that you have made your reflection on all these aspects of scrum if you would like to go one step further!

I would like to share with you that i really enjoyed the whole process! Working for more than four years with the scrum framework, this challenge gave me the opportunity to refresh my knowledge, reflect on what i can improve in our work environment and make me feel much more confident with the framework!

While studying it helped me a lot to read the scrum guide through different perspectives, so i decided,  somehow to “re-write” most of the scrum guide contents, wearing different lenses! Hope it help you as well!

through the product owner perspective

in general as PdO

  • i am responsible for maximising the value of the product and the work of the development team
  • i am the sole person for managing the product backlog that includes:

clearly expressing PBI; ordering the items in the PB to be achieve goals and missionsoptimise the value of the work the development team performsensuring that the PB is visible, transparent, and clear to all and shows what the scrum team will work on nextensuring the development team understands items in the PB to the level needed.

it is ok some of the above work on product backlog management to be done by the development team…as long as i remain accountable!

  • i am just one person! not a committee! however i might represent the desires of a committee in the product backlog…but if you need to change the priority of any item you must address me!
  • i own my decisions and i need the entire organisation to respect my decisions. I make my decisions visible in the content and the ordering of the PB. No one is allowed to tell the development team to work from a different set of requirements.
  • Normally, i am not considered as part the development team (3 to 9 members), unless i am executing work of the sprint backlog!
  • i decide whether i will release or not  a new sprint increment that should be in useable condition

during the sprint

  • as more is learned during the sprint, it might be a need to collaborate with the development team, to clarify and re-negotiate the sprint scope (if the work turned out to be different than the development team expected ).
  • i am the only one that has the authority to cancel a sprint if the sprint goal becomes obsolete, although i might do that under the influence from the stakeholders, the development team or the scrum master. When a sprint is cancelled, if there is part of the work that is potentially releasable, typically i will accept it.

@sprint planning

  • i discuss the objectives that the sprint should achieve and the PBI that, if completed in the sprint, the sprit goal would be achieved.
  • as member of the scrum team we collaborate on understanding and planning the work of the sprint.
  • as a member of the scrum team we will craft the sprint goal!
  • i can help to clarify the selected PBI and make trade-offs.

@sprint review

  • as member of the scrum team, i collaborate with the other roles and the key stakeholders that i have invited in sprint review, about what was done in the sprint. Based on that and any changes happened in PB during the sprint, we collaborate on the next thing that could be done to optimize value, providing in that way valuable input for the subsequent sprint planning.
  • i explain what PBIs have been “done” and what has not been “done”.
  • i discuss the PB as it stands and if needed, i project likely completion dates based on the progress to date.
  • all together we review how the marketplace or potential use of the product might have been changed, what is most valuable to do next, we review the timeline, budget, potential capabilities and marketplace for the next anticipated release of the product.

@sprint retrospective

  • as member of the scrum team i participate in the sprint retrospective since it is an opportunity to inspect (people, relationships, process, tools)  and create a plan for implementing improvements in the next sprint.

PdO & Product Backlog

  • i am responsible for the PB, including its content, availability, and ordering.
  • i track the sum of total work remaining to reach a goal at least in every sprint review. I compare this amount with work remaining at previous sprint reviews to assess progress toward completing projected work by the desired time for the goal. I keep this information transparent to all stakeholders.
  • as member of the scrum team, we decide how and when product backlog refinement is done (should consume no more than 10% of development team capacity)
  • in product backlog refinement (an ongoing process), i collaborate with the development team on PBI details, and PBI are reviewed and revised. However i can update at any time the PBI or at my own discretion.
  • in product backlog refinement (an ongoing process), i may influence the development team on PBI estimates, by helping it understand and select the trade-off.

PdO & definition of “Done”

  • as member of the scrum team, i must have a shared understanding of what it means for work to be complete, to ensure transparency  – this is our definition of “Done” and is used to assess when work is complete on the product increment. As our scrum team matures it is expected that our definition of “done” is expanded with more stringent criteria.
through the development team perspective 

in general as Development Team

  • we consist of professionals who do the work of delivering potentially releasable increment of “done” product at the end of each sprint.
  • Only our members create the increment.
  • we are structured and empowered by the organization to organize and manage our own work
  • we are self-organised; we decide how to turn product backlog into increments of potentially releasable functionality
  • we are cross-functional; we have all the skills as a team necessary to create a product increment.
  • we have not titles for our members other than developer, regardless of the work being performed by the person.
  • we have no sub-teams, regardless of particular domains that need to be addressed like testing or business analysis.
  • we might have as individual members specialized skills and areas of focus, but accountability belongs to the development team as a whole.
  • we are between 3 to 9 people (excluding PdO and ScM). less than 3 members decrease interaction and results in smaller productivity gains and we may encounter skills constraints during the sprint, causing our team to be unable to delver a potentially releasable increment. Being greater than 9 members, requires too much coordination and generate too much complexity for the empirical process to manage.
  • no one is allowed to tell us to work from a different set of requirements, and we are not allowed to act on what anyone else says.

during the sprint

  • as more is learned during the sprint, it might be a need to collaborate with the PdO, to clarify and re-negotiate the sprint scope.
  • in order to satisfy the sprint goal, we implement the functionality and technology required. if the work turns to be different that we expected, we collaborate with the PdO to negotiate the scope of sprint backlog within the sprint.
  • we may influence the PdO to cancel a sprint (refer to PdO perspective).

@sprint planning

  • belonging to the scrum team we collaborate on understanding and planning the work of the sprint.
  • we work to forecast the functionality that will be delivered during the sprint.
  • the number of selected PBI for the sprint is solely up to us!
  • only we asses what we can accomplish over the upcoming sprint!
  • belonging to the scrum team we craft a sprint goal. it is an objective that will be met within the sprint through the implementation of the PB
  • sprint goal provides guidance to us on WHY we are building the increment and it gives us some flexibility regarding the functionality implemented within the sprint. The sprint goal could be one coherent function based on the selected PBIs or can be any other coherence that causes us to work together rather than on separate initiatives.
  • having set the goal and selected PBI for the sprint, we decide how to build this functionality into a “done” product increment during the sprint.
  • we usually start by designing the system and the work needed to convert the PB into a working increment.
  • we plan enough work (varying size or estimated effort) during the sprint planning to forecast what we believe we can do in the upcoming sprint. The work we plan for the first days of the sprint is decomposed by the end of the sprint planning , often in units of one day or less.
  • we self-organize to undertake the work in the sprint backlog, both during the sprint planning and as needed throughout the sprint.
  • if we determine that we have too much or too little work we may renegotiate the selected PB items with the PdO.
  • we may also invite other people to attend in order to provide technical or domain advice.
  • by the end we should be able to explain to the PdO and and ScM how we intend to work as self-organizing team to accomplish the sprint goal and create the anticipated increment.

@daily scrum

  • we use this event to synchronise our activities and create a plan for the next 24hours. We inspect the work since the last daily scrum and forecast the work that could be done before the next one. we inspect how work progress is trending toward completing the work in the sprint backlog. By doing that we optimize the probability to meet the sprint goal.
  • each development team  member explain

what he/she did yesterday that helped our development team meet the sprint goal; what he/she will do today to help the development team meet the sprint goal; if he/she see any impediment that prevent him/her or the development team from meeting the sprint goal.

  • we should understand everyday how we intend to work as a self-organizing team to accomplish the sprint goal and create the anticipated increment by the end of the sprint.
  • we often meet immediately (all or part or our development team) for detailed discussions, or to adapt, or replan, the rest of the sprint’s work.
  • we are responsible for conducting the daily scrum.
  • we only participate in the daily scrum.

@sprint review

  • belonging in the scrum team, we collaborate with the other roles and the key stakeholders about what was done in the sprint. Based on that and any changes happened in PB during the sprint, we collaborate on the next thing that could be done to optimize value, providing in that way valuable input for the subsequent sprint planning.
  • we discuss what went well during the sprint, what problems we ran into, and how those problems were resolved.
  • we demonstrate the work that it has been “done” and answer questions about the increment.

@sprint retrospective

  • belonging in the scrum team we participate in the sprint retrospective since it is an opportunity to inspect (people, relationships, process, tools)  and create a plan for implementing improvements in the next sprint.

Development team & Product Backlog

  • belonging in the scrum team, we decide how and when product backlog refinement is done (should consume no more than 10% of our development team capacity)
  • in product backlog refinement (an ongoing process), we collaborate with the PdO on PBI details, and PBI are reviewed and revised.
  • PBI that can be “done” form our development team within ones sprint are deemed “ready” for selection in a sprint planning.
  • we are responsible for all estimates.

Development team & sprint backlog

  • this is our forecast about what functionality will be in the next increment and the work needed to deliver that functionality into a “done” increment.
  • the sprint backlog makes visible all of the work that we identify as necessary to meet the sprint goal.
  • we modify the sprint backlog throughout the sprint and the sprint backlog emerge during the sprint. This happens as we work through the plan and learn more about the work needed to achieve the sprint goal. Changes in sprint backlog progress, which is a plan with enough details, can be understood in the daily scrum.
  • if new work is required, we add it to the sprint backlog.
  • as work is performed or completed, the estimated work is updated.
  • when elements of the plan/sprint backlog are deemed unnecessary, they are removed.
  • only we can change the sprint backlog during a sprint.
  • the sprint backlog, which is a highly visible, real time picture of the work we plan to accomplish during the sprint, belongs solely to us.
  • at any point of time we can track the total work remaining (at least for every daily scrum) to project the likelihood of achieving the sprint goal. By tracking the remaining work, we can manage our progress.
  • at the end of the sprint, the new increment must be “done” and meet our scrum team’s definition of “done”.

Development team & definition of “done”

  • belonging in the scrum team, we must have a shared understanding of what it means for work to be complete, to ensure transparency  – this is our definition of “Done” and is used to assess when work is complete on the product increment. As our scrum team matures it is expected that our definition of “done” is expanded with more stringent criteria.
  • the same definition of “done” guide us in knowing how many PBIs we can select during the sprint planning.
  • we deliver an increment of product functionality every sprint. This increment is useable, so the PdO may choose to immediately release it or not.
  • belonging in the scrum team, if the definition of “done” for an increment is part of conventions, standards or guidelines of the development organization, we must follow it as minimum. If “done” for an increment is not a convention of the development organization, we, as development team of the scrum team, must define a definition of “done” appropriate for the product. If there are multiple scrum teams working on the system or product release, the development teams  on all of the scrum teams must mutually define the definition of “done”.
through the scrum master perspective 

in general as ScM

  • i am responsible for ensuring scrum is understood and enacted. I am doing this by ensuring that the scrum team adheres to scrum theory, practices and rules.
  • i am a servant-leader for the scrum team.
  • i am helping those outside the scrum team to understand which of their interactions with the scrum team are helpful and which are not. I am helping everyone to change these interactions to maximize the value created by the scrum team.
  • i am serving the PdO in several ways, including:

finding techniques for effective PB management (see in PdO perspective); helping the scrum team understand the need for clear and concise PB items; understanding product planning in an empirical environment; ensuring the PdO knows how to arrange the PB to maximize value; understanding and practicing agility; facilitating scrum events as requested or needed.

  • i am serving the development team in several ways, including:

coaching the development team in self-organization and cross-functionality; helping the development team to create high-value products; removing impediments to the development team’s progress; facilitating scrum events as requested or needed; coaching the development team in organizational environments in which scrum is not yet fully adopted and understood.

  • i am serving the organization in several ways, including:

leading and coaching the organization in its scrum adoption; planning scrum implementations within the organization; helping employees and stakeholders understand and enact scrum and empirical product development; causing change that increases the productivity of the scrum team; working with other scrum masters to increase the effectiveness of the application of scrum in the organization.

  • i am not telling the development team how to turn PB into increments of potentially releasable funtionality.
  • Normally, i am not considered as part the development team (3 to 9 members), unless i am executing work of the sprint backlog!

during the sprint

  • i may influence the PdO to cancel a sprint (refer to PdO perspective).

@sprint planning

  • i ensure that the event takes place and that attendants understand its purpose.
  • i teach the scrum team to keep it within the time-box.
  • as member of the scrum team we collaborate on understanding and planning the work of the sprint.
  • as member of the scrum team we craft a sprint goal.

@daily scrum

  • i ensure that the development team has the meeting.
  • i teach the development team to keep it within the 15-minute  time-box.
  • i enforce the rule that only development team members participate in the daily scrum.

@sprint review

  • as member of the scrum team, i collaborate with the other roles and the key stakeholders that i about what was done in the sprint, what to do next, so that to provide valuable input to subsequent sprint planning.
  • i ensure that the event takes place and that attendants understand its purpose.
  • i teach all to keep it within the time-box (4 hours meeting for one month sprint)

@sprint retrospective

  • i ensure that the event takes place and that attendants understand its purpose.
  • i teach all to keep it within the time-box (3 hours for one month sprint)
  • i participate as a peer team member in the meeting from the accountability over the scrum process.
  • i encourage the scrum team to improve (identify improvement to be implemented in the next sprint), with the scrum process, framework, its development practices to make it more effective and enjoyable for the next sprint.

ScM & transparency

  • i must work with PdO, development team, and other involved parties to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency.
  • i must help everyone apply the most appropriate practices in the absence of complete transparency.
  • i can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what being said, and detecting differences between expected and real results.
  • my job is to work with the scrum team and the organization to increase the transparency of the artifacts. The work usually involves learning, convincing, and change!

ScM & definition of “Done”

  • as member of the scrum team, i must have a shared understanding of what it means for work to be complete, to ensure transparency  – this is our definition of “Done” and is used to assess when work is complete on the product increment. As our scrum team matures it is expected that our definition of “done” is expanded with more stringent criteria.
through the rules perspective


  • scrum is a framework for developing and sustaining complex products.It is used to manage complex product development. It is not a process or a technique for building products; rather it’s a framework within you can employ various processes and techniques
  • scrum is founded on empirical process control theory, or empiricism and the three pillars as in every empirical process control implementation are

transparency: significant aspects of the process must be visible to those responsible for the outcome, defined by common standards so observers share a common understanding of what is being done

inspection: scrum user must frequently inspect scrum artefact and progress towards a sprint goal to detect undesirable variances.

adaptation: if inspection determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed myst be adjusted as soon as possible to minimise further deviation.


  • consist of: PdO, development team, scrum master
  • scrum team are self organized and cross-functional. the team model is designed to optimize flexibility, creativity, productivity
  • scrum teams deliver “done” products iteratively and incrementally ensuring that a potentially useful version of working product is always available.
  • no one is allowed to tell the development team to work from a different set of requirements and the development team is not allowed to to act on what anyone else says.
  • only development team members create the increment and no one tells them how to turn product backlog into increments of potentially  releasable product
  • scrum recognises no titles other than developer.
  • scrum recognise no sub teams.
  • development team size is between three to nine people (excluding PdO and ScM)


  • four formal events for inspections and adaptation are prescribed: sprint planning, daily scrum, sprint review, sprint retrospective. These events are specifically designed to enable critical transparency and inspection.
  • all scrum events are time-boxed, such that every event has a maximum duration.
  • sprint
    • Once a sprint begins its duration is fixed and cannot be shortened or lengthened. All the other events may end whenever the purpose is achieved, ensuring and appropriate amount of time spend without allowing waste in the process.
    • sprint is a time-box of one month or less during which a “done” useable and potentially releasable product increment is created. sprints must have consistent durations throughout a development effort. A new sprint starts after the conclusion of the previous sprint.
    • during the sprint: no changes are made that would endanger the sprint goal, quality goals do not decrease, scope may be clarified and re-negotiated between the PdO and the development team as more is learned.
    • a sprint could be cancelled by the PdO when the sprint goal become obsolete.
  • sprint planning
    • sprint planning is time-box to a maximum of eight hours for one month sprint.
    • sprint planning answers the what can be delivered in the increment for the upcoming sprint and the how the work needed to deliver the increment be achieved
    • input to the sprint planning is the product backlog, latest product increment, projected capacity of the development team during the sprint, past performance of the development team.
  • daily scrum
    • is a 15-minute time-boxed event for the development team and only development team members participate in the daily scrum.
  • sprint review
    • is a four-hour time-boxed meeting for one month sprints.
    • the result of sprint review is a revised PB that defines the probable product backlog items for the next sprint. May also be adjusted overall to meet new opportunities
  • sprint retrospective
    • after the sprint review and prior next sprint planning and it is a three hour time-boxed meeting for one month sprints.
    • by the end of sprint retrospective the scrum team should have identified improvements that it will implement in the next sprint.


  • product backlog
    • ordered list of everything that might be needed in the product and is the single source of requirements and any changes to be made to the product
    • it is dynamic and it is a list of all features, functions, requirements, enhancements, fixes
    • PBIs have the attributes of a description, order, estimate, value
    • one product backlog exists for multiple teams (grouping if items may be employed)
    • the various projective practices do not replace the importance of empiricism. In complex environments only what has happened may be used for forward looking decision making
  • sprint backlog
    • is the set of PB items selected for the sprint, plus a plan for delivering the product and realising the sprint goal.
  • Increment
    • is the sum of all PBIs completed during a sprint and the value of the increments of all previous sprints
    • at the end of the sprint, the new increment must be “done”, which means must be in useable condition and meet the scrum team’s definition of “done”.

definition of “done”

  • a shared understanding for everyone of what it means for a work to be complete, to ensure transparency
  • it is used from the scrum team to assess when work is complete on the product increment.
  • each increment is additive to all prior increments and thoroughly tested, ensuring that all increments work together.
  • any one product or system should have a definition of “done” that is a standard for any work on it.
in conclusion

scrum’s roles, artifacts, events and rules are immutable and although implementing only parts is possible, the result is not scrum. scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices

effort is good!


must reading

The Scrum Guide (2013) – The Definitive Guide to Scrum: The Rules of the Game

Scrum – A pocket Guide


Research has shown that highly performing teams are better at solving problems, they have an improved quality of decision making and they are more committed to tasks. Team members are more satisfied and motivated, they support creativity and innovation and they operate in an environment of trust. While these are a few benefits of highly performing teams, ineffective teams cannot achieve business goals and performance objectives.

Under that context, developing high performing teams should be a common goal for any organization. More specific for organizations that are moving to an “agile”environment, where emphasis is given on individuals, interactions and teamwork, teams at any level that high perform should be seen as an important pillar in getting the benefits of any agile transformation.

But how to coach a team to high performance? Why just only one in five teams is high performing? What is missing and many “agile” teams, despite the agile practices and methods being used are not able to high perform?

There is no doubt that high performing is the destination where teamwork is important and It is good to know your destination! But it is also important to know how to reach it, whether you are moving to the right direction and  when you have reached your destination! Maybe this is common sense but in reality many of these steps are skipped or they stay unattended during a team’s cycle. As a consequence team coaching is not achieving the expected results or as research has shown is some cases it might do more harm than good!

High Performance Team Coaching (HPTC) system

In 2013 Dr. Jacqueline Peters and Dr. Catherine Carr published an excellent book on High Performance team coaching, where a comprehensive, modularized and an evidenced-based system, tested for more that 10 years is presented and could serve any coach to support and enable teams to high perform.

In HPTC system, a high performance team is one that meets or exceeds the goals set by the organization and/or those it has set for itself

Experimenting with that system, i thought it would be useful to share first a few more details around the way this system is organised, based on Dr. Peters and Dr. Carr article in ICF Coaching World magazine and their book,  prior sharing my own insights and reflections!


In the core of this system is psychological safety! An environment where people feel safe enough to challenge, fail, learn and succeed together is really important since without this sense of “safety” it is difficult for any group of people to become a real and effective team. As a coach demonstrating, openness, transparency, certainty, asking for permission, making clarification e.t.c are behaviours that could create the basis of a “safety first” environment and could trigger team members to behave accordingly. Trust could be seen as the outcome of “safety first” environment as defined by Dr. Peters

Trust develops over time and is an outcome of having ongoing experiences of feeling safe with others. Safety is easier to control than trust. Safety can be breached or bridged in the moment to moment interactions we have with others.

team cycle

In the peripheral of the HPTC system are the different phases of team’s cycle. While the most popular team stages are the forming, storming, norming, performing and adjourning as defined by the wok of Bruce Tuckman, in the HPTC system three main stages of team cycle are considered. These are team beginning, team midpoint and team ending as suggested by the work of Connie Gersick and have been found as the main stages in which a team could trigger significance changes.

team beginning – define & initiate

In “define and initiate” phase (new team, new team’s business cycle, new team’s project e.t.c) the main steps of team coaching includes, team assessment, coaching for team design and team launch. The HPTCH system put a lot of focus on this phase since based on the work of Richard Hackman, 60% of team effectiveness derives form the beginning of a new team cycle, 30% of team effectiveness is affected by the quality of team launch and only 10% of team effectiveness is impacted from ongoing coaching! The assessment phase (through a team effectiveness survey and even personal interviews) will collect data needed to determine if the team meets the six conditions that are important for team and coaching success, as suggested by the the work of Ruth Wageman.

a real team with clear membership and boundaries

a compelling purpose, direction that guides the team’s work

the right people that add value to the team and have the skills and knowledge to achieve team’s purpose

a solid team structure with clear roles, responsibilities, norms and agreements

a supportive organizational context that provides the needed information, time and resources to do their work

competent team coaching to help the team grow individually and as a unit (internal or external to the team)

The data collected will be used by the coach and the team to identify team’s strengths, weakness and gaps between their current and their wanted position. In the step of team design and structure is important to ensure that the six conditions are understood by the team and based on their data analysis, they are able to set their purpose and goals. It is also important to be clear that the team has the right people and as a team they have taken the right actions to achieve their purpose and goals! The last step, team launch, the team need to set their working agreements, their guiding values and review their purpose and goals towards their high performance direction! This is an important step since based on the research of R. Hackman it can affect 30% of team effectiveness!

team midpoint – review & realign

In this phase, during the midpoint of a current team’s project or business cycle,  the main steps in HPTC system are individual and ongoing team coaching. It is the time where follow-up coaching session are taking place with the team aiming to reflect on progress and team’s agreements, gather feedback from stakeholders and plan the necessary actions needed to achieve team’s purpose and goals. Individual coaching will help also to challenge team members to contribute as effectively as possible towards their own direction.

team ending – reassess & integrate

This is the last phase of HPTC system and is really important since it the time for the team to reflect on their individual and team  successes, failures and learnings. The review of their initial assessment will help the team towards that direction. This is a really important step since it gives the opportunity to the team to review their performance related to the three key main areas of team effectiveness as defined in HPTC system:

individual engagement

team capabilities and relationships

quality outputs

This closure phase is also important to help the team integrate their learnings and apply them in their new journey!

Researchers and practitioners argue that teamworking is really important for any organization and most important in cases where there is need to respond and adapt quickly to changing circumstances (agile environment?). Under that context, coaching teams for high performance that will be able to meet and exceed the goals set by the organisation and their own is really challenging! The High Performance Team Coaching is a comprehensive and modularized system that could help any coach to serve teams to high perform and as a result any organisation to get the benefits of high performance teams!

try it!


must reading

High Performance Team Coaching, A Comprehensive System for Leaders and Coaches

The HPTC model

Leading Teams: Setting the Stage for Great Performances


A few months ago i’ve read an interesting post from Leo Babauta (zen habits)  where he described a simply method that could be used as a guide to simplify any area of our life! The steps he mentioned were:

collect everything in one place
choose the essential
eliminate the rest
organize the remaining stuff neatly and nicely

Inspired by that simple method and the way it could be used, form things related to our daily routine up to our own life, i was thinking that this method could help teams as well to simplify their working life!

Working with teams for a few years and considering the changes “agile” has brought to our organization, it was obvious that there were many things each new team should  handle! New responsibilities, new expectations, new processes were just a few areas that they should take care!

My experience has shown that it is impossible to handle all that stuff at once, even if sometimes there is some pressure to have everything in place as from the beginning! You need to focus on those items that return the most value back to your team and your organization and then work on the rest!

Confucious once said that

Life is really simple, but we insist on making it complicated

Based on that belief, my hypothesis was that “agile could be really simple, if we do not insist on making it complicated”! To experiment with my hypothesis i’ve used the “Four Laws of Simplicity” during a team’s retrospective. The steps are described below.


In that phase each team member thought about everything that was related to our way of working. From practices, processes, methods, agreements, responsibilities, expectations e.t.c. There was nothing right or wrong! All notes were gathered in one box that was finally turned upside down! We continued with grouping of the common items and create a few more general themes where possible. As an example a few items are listed below

solution testing, testing on target, US preparation, US selection-sprint planning, demos, stand-up, retros, taks splitting, code quality, e2e teams, collaboration, communication, commitment, feedback, openness, initiatives, self-improvement, adapt to changes e.t.c


We then chose the “essential” items! The items that could return the most value to the team or items that could have long term benefits. We discussed on notes and themes, and we used dot-voting as a technique to reach consensus and to prioritize our pool of items!


Team decided that there was no need to eliminate any item! Every item had its own value, so everything was kept for future reference.


As mentioned above dot-voting helped the whole process  to come up with a prioritized list of items. We further agreed that there was no need to work directly on the most voted items! For that reason we added two more parameters in our decision to prioritize the list of identified items. The value that will return a specific item and the effort required! The outcome of this exercise was the creation of a “prioritized” improvement backlog including items that the team would like to keep, “tweak” and further explore!

As an example, the team decided to work on “code quality”. Worth to mention that all team members were really satisfied of the quality they produce but they were willing to further challenge their “local optimum”! A couple of actions they came up: re-activate improvement list (add items related to legacy code improvement & bring them to architecture meetings) and introduce the concept of “re-factoring US” as soon as an EPIC had been implemented.


based on the feedback i received, team really enjoyed that method! we spend almost two fully productive hours!

In my opinion team managed to express and visualize their personal thinking related to their work, reach consensus and focus on those items that could help them to get improved and could return the most value back to them and their operations! It was a start that requires effort and discipline to grow a mindset of little constant improvements!

What i would change based on the feedback i’ve received…i would introduce an estimated technique to estimate the “value” of the chosen items! it might help teams to understand the “value” of estimation as well!…and why not invite team’s group leaders/line management and PdOs to express their own thinking and contribute from their sides on the improvement board!…


inspirational reading

4 Laws of Simplicity and How to Apply Them to Life

I Manage Products


Assess your Agility - BETA

A framework to evaluate and improve your organization's agility

Lean Adaptive Leadership

Transforming technology organisations using lean and adaptive principles.

Agile, Lean, Kanban, and System Thinking

Agile, Lean, Kanban, and System Thinking

Control Your Chaos

That Scrum Girl on everything Scrum, Agile and Lean

The Product Owner Framework - BETA

Evaluate your skills and identify areas for growth

Digital Business Transformation

Inviting you to explore the world of Digital Business

Agile For Startups

Tools and Techniques for Tech - Startups .

Escape The Local Optimum

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Software Process and Measurement

Software Process Improvement and Measurement - Oh My!

Dave Nicolette

Effective software development and delivery

Arialdo Martini

Random notes about software

Agile By Culture

Doing Agile means being Agile


Thoughts on software, code, philosophy and games

InnerActive Leadership

Partnering with you to find insights that lead to results!

Agile, Data, APIs, startups and more

Everything I find out about Agile, Data, Big Data, Data Science, APIs and of course Startups.

quantum shifting

think bigger, go further

Benjamin Mitchell's Blog

Helping IT teams & their managers deliver great software solutions

Diary of a ScrumMaster

Finding a path to a new way of working

An Ethical Island

How to Teach Without a Lecture and other fun

Mike Cohn's Blog - Succeeding With Agile

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Jim Highsmith

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting


jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting