Archive

practices

26094039844_2371b0f469_o

[5′]

Can anything be learned about the practice of an art, except by practicing it?
Erich Fromm

If you see agility as an “art” then you might have some reasons to read what follows! Practicing an art it’s not that simple! And practicing and demonstrating agility is not simple either! To my experience there are no prescribed steps that if followed will help, you, your teams and your organization to get the benefits of being agile.

For sure there are many guidelines, there are many frameworks trying to give solutions in different problems, there are many courses and certifications and hundreds of books that could help someone to get some knowledge but these are not enough. Each one of us is different and each context has it’s own specific needs. What worked in one context it’s hard to meet the needs of another one.

To get the benefits of being agile there is one and only way. You need to practice agility in your own context! And as in every art, practicing agility has certain requirements or preconditions that could be considered prior starting with. These requirements and preconditions might be helpful for all of you that you are not expecting the “10 steps to master agility” and you are willing to follow the hard way, the way that will require effort to practice, to experiment and to commit in continuous learning and improvement

Agility requires discipline. If you are willing to demonstrate and get the benefits of agility in your specific work context you need to practice the various agile practices in a disciplined way. You will not master agility if you are not following the rules when you start experimenting with the various practices. You might feel that this is not very agile but learning new stuff requires a certain degree of discipline. There are so many practices you can start experimenting and as an advice you can try those first that might help you get some quick wins. Those practices that might resolve your first observed bottlenecks in your system.

Keep in mind that if you practice them when you are in the “right” mood, when you have time, when there is no crisis it might be fun but you will never master the art of agility. You need to insist applying the various practices even in hard times even if when it’s hard to see the anticipated benefits.

Experiment with various practices in a disciplined way for as long as it is needed to create new wires on your brain and new habits! Feeling comfortable with the practices will give you the space to reflect on the outcome and think of improvements and adaptations closely to your specific context and needs.

Agility requires focus. As with every art, while practicing agility you need to be focused and concentrated on what you are doing and why you are doing. It’s really important to observe while you are experimenting with the various practices, reflect on the outcome and try always to learn either from positive or negative ones.

To keep your focus try not to start many things in parallel. Focus on a few vital practices as said that might help you get some quick wins and resolve your first bottlenecks, instead of starting a wide and complex program aiming to resolve all of your problems. Thing big, but focus on those small steps and on a few initiatives otherwise you will end up starting so many things and evaluating just a few or even get lost while trying to manage complex systems like humans, teams and organizations.

Agility requires patience. If you have ever tried to master an art you might already know that you need time and patience.  And agility requires your patience. It’s about creating new habits and change your mindset on the way you have learned in getting things done. The agile manifesto requires this shift on your mindset and the practices related to this new mindset requires effort and patience. Changing people’s mindset and expecting them to learn and create new habits,  requires time.

It’s a common belief that we are wasting our time if we are not seeing quickly some benefits of the new things that we are trying or learn. We are impatient! And for that reason many agile initiatives are abandoned when the first dysfunctions are observed or when the benefits are taking longer than expected. So patience is crucial to master agility and get at the end the benefits of it.

Agility requires a great concern. If you are not seeing agility as something really important for yourself, your  teams and your organization you might become good but you will never master it! Agility requires passion, continuous learning and improvement,  learning from either success or failures, resilience, commitment, empathy  and strong interest from all those that are involved and affected!

Discipline, focus, patience and great concern could be seen as the requirements to master agility and the get the benefits of it. You need to keep these preconditions in your mind prior starting practicing agility. It’s not a few steps that need to be followed to reach a destination, it’s a journey that you are devoted to it. You need  continuous practice to keep your self, teams and organization “fit” and ready to adapt to emerged needs!

Mastering the art of agility it’s a journey worth to take it!

.nikos

inspiring reading

zen in the art of archery

the art of loving

19612614719_d7507684ef_z

[1′]

I am pretty sure that you might have heard about Lean Coffee and how it could help you have effective, structured, agenda-less meetings. Lean Coffee format could be used in any kind of meeting so why not in a team retrospective?

If you are thinking to use it in your next retrospective consider the following steps:

  • set-up a personal KANBAN board (cards to use: to discuss, discussing, discussed)
  • reflect on your previous sprint and write on sticky notes your insights related to what worked well, what didn’t work so well and what need to be improved (you can use any other set of questions to gather insights)
  • collect all this items under the “to discuss” card. give a few details about the topic if sth is unclear
  • vote those items that you think are most important for you and your team to discuss (two votes per member)
  • prioritize them based on the number of votes received
  • move the top rated item in “discussing” and start discussions! 4 minutes might be a good duration but it’s up to you to decide if you would like to have a longer duration
  • after the four minutes for the specific topic are passed decide if you would like to give another turn! (thumps up or down). if most of the people would like to discuss take four minutes more, if it is equal take the half time
  • when you have finished with one item put it under “discussed”. suggestion: keep one minute to reflect on your take-aways , actions, conclusions e.t.c
  • repeat again with the next item until the time planned for the retrospective
  • ensure to leave a few minutes at the end to reflect on all items discussed!

give it a try!

.nikos

inspiring posts

what is a lean coffee

9988772786_ffc5218837_o

[5′]

Implementing agile in an organization could be a very hard and complicated thing and it could become even harder especially if you are impatient to see the anticipated benefits. It’s common said that it is very easy to start with agile and to my experience and observations it is even easier to fall back to old ways of doing things – maybe renamed – when you realize that you are in the middle of chaos!

Is there any way to have a successful agile change that serves its purpose? The answer is yes and Jason Little describe that way in his book “Lean Change Management” which is an excellent resource with concrete practices, that could help any agile change agent to be good at change!

Recently i had a great challenge to train a big project team in agile methodologies, that came as their need to handle a very complex product with high uncertainty in what to do and how to do it! I’ve seen this challenge as from the very beginning as a change rather than as a conventional two days training and i thought that it was a great opportunity to experiment with the Lean Change management approach!

As Jason suggests in his book, a  Lean Change cycle starts with gathering insights about the current state of the organization. There are multiple ways and models that could help someone to do that and i found really challenging to experiment with a retrospective based on Virginia’s Satir change model as one of the method i’ve used to gather insights.

v2----ch1-satir-2

I’ve made the hypothesis that making all participants aware of that change model will help to improve the way they process their own change related to their agile implementation and move smoothly from one stage to another.

In brief the model consist of the following five stages:

Late Status Quo: Everything is familiar, comfortable and performance is stable

Foreign Element (Resistance): A foreign element threatens the stability of familiar structures. Most people resists by denying its validity. That foreign element is not particularly a sudden crisis, but rather the “sudden realization that things have been very unhealthy”

Chaos: In Chaos people affected by the change try to ignore the foreign element , hide from it or actively fight it. People might even reject the foreign element so much, that they end up at Old-Status-Quo behavior! Confusion, anger, drop in performance are just a few side effects.

Transforming Idea (Practice and Integration): In that stage after coping with the foreign element, people finally discover in a transforming idea that shows how the foreign element can benefit them and they start integrating the benefits into their new identity.  People will need a lot of slack-time to try out new things. Some things will turn out to be bad ideas, others will work greatly.

New Status Quo: Performance stabilize in a higher level that the old status quo. Roles, responsibilities, ways of working are clear and a new status quo is born, just until you realize the next foreign element, and the cycle starts from the start!

I’ve started the retrospective with the description of the model and on the way people react in every stage. As a next step participants triggered to answer in sticky notes a few questions related to  model stages and we discussed as a group the different views.

The questions i’ve used, inspired by Jason’s book are listed below:

Late Status Quo, “everything being familiar and in balance”

What was working well?

What was making you feel comfortable in that state?

Foreign Element, Resistance, Chaos, “sudden realization that things have been very unhealthy”

Which are your main concerns related to this change?

Which are the main obstacles that restrain you to get the benefit of this change?

Transforming Idea, “AHA!..i learned something!”

Which are the forces that driving this change?

Which are the benefits you have seen so far?

What are you willing to do in order to make the change work?

What will you need to do differently?

What support do you need for me?

New Status Quo, “everything being familiar and in balance”

What is your VISION, your new target position with respect to this change?

How will we measure success New Status Quo

The amount of generated insights was impressive! Project team members came to a conclusion that maybe the foreign element that triggered their comfort zone was the project complexity and it was less related to their agile implementation. For sure agile surfaced even more dysfunctions that there was need to handle. However they have started seeing it as the transforming idea, the vehicle and not the impediment to succeed with their project and get out of the chaos. They were expressing some of benefits they had seen so far form their agile implementation, while reflecting on things that they need to change or challenge for themselves. It was also useful that the main barriers related to their change, like management support, product roadmap, team structure were highlighted. It was also interesting that participants thought about their new status quo and what they need to do in order to reach their wanted position. This helped the project team to co-create a list of options (second step on the Lean Change management) that they could work further depending on the value they will get compared to the effort or cost they need to invest as suggested in Lean Change Management.

If i could sum-up the whole approach we have used to generate insights in a few words i would choose awareness, alignment and co-creation! and IMHO i believe that are important  pillars for any change to happen!

Concluding, start gathering insights is the first step in Lean Change and to my experience the Satir Change model could be a really helpful way to generate them! To move forward and support any change to serve it’s purpose you just need a few more steps. Apart from insights, you need options, make a lot of experiments, learn, reflect, run more, start anew!

Would you like to be good at change? I would suggest to learn about the Lean Change Management approach and try it!

First appear as a guest post in leanchange.org 

.nikos

inspiring reading

Lean Change Management

The Satir Change Model

3 reasons why you should build your own change method

inspiring video

Creating alignment for agile change at agile and beyond 2015

58-01

[3′]

Underlying all human actions are needs that people are seeking to meet, and understanding and acknowledging these needs can create a shared basis for connection, cooperation, and more globally peace

BayNVC

Dr. Marshall Rosenberg, the founder of Non Violent Communication (NVC) language used to say that quite often we tend to use the language of  “jackal”,  we judge, lay blame, we demand and eventually disconnect. NVC is another communication process that focuses in understanding each other at the level of our needs and learning to communicate with compassion towards ourselves and others

While studying and trying to practice the NVC language (great trigger a learning lab i attended @ Ericsson’s Learnathon on that subject) i thought that it would be a great experiment to try NVC language in a team retrospective. I was curious to understand, how honestly expressing ourselves and emphatically listening others, could improve or challenge team relationships and trust among team members. It was a completely new way to communicate and express things that didn’t work well, things that worked well and areas that could be improved.

We run the retrospective using, to the extend possible, all four components of NVC process: observations, feelings, needs and requests. Since it was the first time using that language we kept some notes on every component to help us during our discussion using NVC language! Below is a short description of every component with a few examples

  • observations: in that phase we reflect on things that we have observed (hear, see, remember) free from our own evaluations or interpretations of what happened. We focused on both positive or negative observations on team or even on personal level.

ex. during our previous sprint i remember that <a team member> had to handle too many tasks

ex. i’ve noticed that we didn’t get from sprint beginning the expected support from system experts and i remember that we finally got the support after raising specific questions and setting up a couple of meetings

  •  feelings: in relation to what we have observed, in that phase we have expressed our emotions rather than thoughts which were associated with our met or unmet needs (next phase). The observations were just the triggering points

ex. […] and i felt a little bit uncomfortable

ex. […] I felt initially insecure on they way we have approached our solution and i felt more confident when finally we got the required support.

  • needs: in that phase we have tried to express our deeper needs that caused our feelings triggered by our observations.

ex. […], because i value fairness and balance on workload distribution among team members

ex. […]. My need for safety, security and support on what we are doing as a team even at later phase was met!

  • requests: in the last phase we tried to clear express our requests that will improve our personal and team’s well being. Trigger improvements that are closely connected with our expressed needs.

ex. […] Do you think that we could try in our next sprint planning to split more equally our everyday task and try offload<a team member> from tasks that for the time being his expertise in not needed and let him focus on those tasks that our team needs his expertise so to meet our goal?

ex. [..] Would it be nice whenever we have uncertainties and we need support proactively send our requests, while trying to be as specific as possible, to people that could help us?

It was interesting to observe that we have managed in a very polite & humane way to express what happened in previous sprint and identify behaviors that we would like to keep and try. It was quite impressive the way people expressed their feelings and their met or unmet needs.

We have used the same language to reflect on the hour spent so to get used on that new way of communication and once more the outcome was amazing! People felt proud of their team, observed that they have different needs not expressed so far, felt more confident to share their feelings caused by their needs and helped them alot to see that there are ways to avoid conflicts, blame and disconnection. We will definitely use that language in our retrospectives and as suggested we should even try it in our everyday work as well! I think we had just made another step while trying to grow strong team relationships!

.nikos

inspiring reading

non violent communication: a language of life

how you can use the NVC process

inspiring videos

Nonviolent Communication Part 1

Nonviolent Communication Part 2 

11610873363_c4aaa0c3e1_z

[5′]

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!

practicalities

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)?

.nikos

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!

.nikos

interesting research

systematic reflection: implications for learning from failures and successes

39-34

“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!

responsibility

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.

IMG_0643

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?

.nikos

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

I Manage Products

PRODUCT MANAGEMENT BUILT BETTER, FASTER, STRONGER

Si Alhir (Sinan Si Alhir)

© 2016 Si Alhir (Sinan Si Alhir) — All Rights Reserved.

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.

Systems Thinking and the Vanguard Method

Musings, discoveries and experiences

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

OutOfScopeException

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