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

Advertisements

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 

11063792126_b6c1f5f89e_z

[2′]

I find my self often observing and reflecting what i am doing as an agile coach, trying to better understand my current role. I didn’t have these kind of “worries” with my previous roles and positions as a research telecom engineer, developer and project coordinator. It was just enough to follow my job/role description meet the expectations and measure the impact of my effort! I wasn’t worried about since all these different role responsibilities where close to my thinking and belief!

Why these kind of “worries” surfaced with my current role, even if there are plenty of resources and books that describe what an agile coach should do and custom made role descriptions, responsibilities and expectations written in many pages? What has changed?

In my journey to self-awareness through the lenses of my current role, i realised that i had to work deeper in my own paradigm shift. I was needing a new belief, a radical change on my thinking from an accepted point of view, established for years with certain habits,  to a new thinking  and a new set of habits.

From trying to be the best at what i was doing and resisting to change,  to start experimenting, fail, expose my inabilities, feeling comfortable to challenge my comfort zone

From an expert and having an advanced knowledge on specific areas, to a more “generalist”, trying to cover a wide area of skills and competencies.

From adherence to specific role requirements, to focus more in  becoming a team player, collaborating and contributing to the whole effort.

From seeing, monitoring and easily measuring results, to feel comfortable with long-term payoffs not necessary measurable.

From getting and keeping control, in becoming a team and trust builder while creating the conditions whereby people could grow, develop, fail, learn, synergize in achieving their higher purpose.

I had to work on my own motive system as well. Power and status, to name a few motives, had to change to match the expectations of my new role. Establishing, maintaining or restoring “healthy” relationships among the team members, understand their needs and commit to help them achieve their goals, is what motivates me now! I use my experience and knowledge to teach, mentor, coach people, help them applying agile practices, and let them grow, shift their own paradigm and enjoy their journey!

Trying to shift to a new paradigm as an agile coach is not happening from day one. Commitment, awareness, continuous observations, reflections, adaptations and effort to develop and grow new habits is needed. It’s a long journey that worth to take it!

.nikos

inspiring reading

the power of self-dependence 

the reengineering alternative. a plan for making your current culture work

attending to needs is all we need

the professional helper

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