You Don’t Need to Change. Survival is Optional

/by

The title refers to a quote attributed to W. Edwards Deming.

Today there’s general consensus – and a lot of noise – about the need for change. Still, organizations are having a hard time with change. Most change initiatives fail. Sometimes it’s just a matter of lack of will to change. Sometimes organizations just don’t even understand why or what they have to change.

Change is often believed to be magically reachable designing new processes on paper, possibly paying huge amounts of money to consultants.

The talk introduces the Kanban Method (not to be confused with the Kanban Tool) as an evolutionary approach to managing change and as a way to build a learning and adapting organization.

 

man wearing white and black plaid button-up sports shirt pointing the silver MacBook

Have a structure for your coaching conversation

/by

This blog post is the third in our series about professional coaching skills for agile coaches. If you have not yet read the first blog post, “Listen, be curious and ask the great questions!”, or the second one, “Your strategy for formulating powerful questions”, we suggest you read those before continuing here.

A coaching conversation is not just a small talk about how things are going or not going. Coaching conversations are for committed individuals or teams, that want to make a significant change or get wiser about an important matter. To help you succeed as a coach, you can apply a structure to the coaching conversation that helps you and the coachee or team to focus on talking about the important matter and find specific actions to carry out as results of the conversation. It is important to remember that a coaching conversation is something that you design together with the one or those that you are in service of, at the moment when the conversation is wanted. As a coach you never take the coachee or team to places they do not want to go – this would be strictly out of line. What you do instead is help them to go where they want to go, while helping them reflect on the important matters.

The two levels of the coaching conversation

As shown on the figure below, a coaching conversation is conducted on two levels: A) The conversation level and B) The meta level. As coach you are constantly acting on both levels. The coachee or team is primarily on the conversation level, but will from time to time be invited to the meta level by you.

The two levels of the coaching conversation

The conversation level is where the conversation happens. Here you are using the levels of listening, and you will form questions based on keywords as mentioned in a previous post. The coachee or team will answer your questions on this level as well.

The meta level is where you are designing and reflecting on the conversation. Here you are deciding which powerful questions to ask (possibly based on the Karl Tomm model), which hypotheses to formulate and in which direction to take the conversation next. As a coach you can imagine yourself as having a third eye observing the conversation from this level and your awareness about the flow of the conversation, and the answers you get will help you make the right decisions.

Meet up at the meta level

As mentioned, you will from time to time invite the coachee or team to join you at the meta level. The purpose for this is to have a conversation about the conversation, collaborate on designing the conversation, reflect on the learnings so far and make decisions about where to go next.

There are normally at least three opportunities for meeting at the meta level: 1) establish the contract for the conversation, 2) a time out during the conversation and 3) when you do the summary of the conversation. But before digging into making the contract, you should spend a little time on establishing contact with the one(s) you are coaching. Here chitchat is okay, as long as you are steering towards starting the coaching conversation. Establishing the contact helps people relax and feel confident in speaking freely.

How you can establish the contract

When you are establishing the contract, you invite the other party to a talk about the conversation you are about to have. Here you can ask questions like: “What is the topic you want to elaborate and get insights on?”, “How can I best serve you during the conversation?”, “Are there questions you especially want me to ask or questions you absolutely do not want me to ask?” and “When this conversation is over in (for example) one hour, where do you expect to be, what do you hope to have learned?”. I find it to be good practice to have the coachee or team formulate the goal of the conversation in one short sentence – and I usually also memorize it by writing it down on my own.

Now the coaching conversation can begin – usually by formulating questions based on keywords extracted from the agreed goals for the conversation.

Make timeouts

During the conversation, you can from time to time make a timeout to evaluate the conversation. Here you can summarize the learning so far and decide where to go next. Timeouts help to co-design the conversation on the fly with the purpose of bringing the most possible value into it. Think of it as a sort of inspect-and-adapt on the meta level.

You can use timeouts when you feel the conversation is at a crossroad so you have to make decisions on which path to take next. Be humble and do not take for granted that your personal decision will be the best path. Instead ask the one(s) you are coaching and follow their choice. Remember: it is not about you! It is all about them!
You can also use timeouts to re-negotiate the contract if you realize that another topic seems to be more important.

You can make as many timeouts as you feel necessary, asking questions like: “Let us summarize: We have been discussing …. and …, figuring out that …. . Do you want to expand more on this, or would you rather move on looking at other options? What would this be?”, “As I see it, we can either go in the direction of … or in the direction of … . You might see a third direction. Where do you want to go from here?” or “In the beginning of this conversation we agreed on speaking about the topic: … . It seems to me that we are more discussing the topic: … . Do you want to return to the agreed topic or is the topic we have been discussing lately more important? Do you want to change the agreed topic?”.

When the timeout is over you can continue the conversation taking into account the decisions you have just made together.

Define the next steps, starting with a clear summary

By the end of the conversation, it is time to make a summary focusing on the specific steps the coachee or team is going to do, in order to have the desired change. Have him, her or them speak out the summary instead of you doing it. That fosters the sense of responsibility. Remember: it is not your solution – it is their solution!

It is great practice to ask, as a follow up to the conversation, about what will be the next step, when will be done, and how you will know that this has been achieved. To the last question the one(s) you coach will usually answer something like: “You will get a mail, letting you know how it went”. Your reply can, in service to the other part, then be: “And if I do not receive this mail, will it be helpful for you if I ask you about how it went?”. This attitude sharpens the awareness about the coaching conversation as something that serves a purpose, rather than just being a small talk about life, the universe and everything.

End by asking for feedback

Finally, by being a coach that wants to improve your skills, you should also ask for feedback about the coaching conversation. Ask questions like: “How was this conversation for you?”, “What did I do that was especially useful for you?” and “Which questions did I ask, that were useless or disturbing for your understanding of the matter?”. Receive the feedback with gratitude, maybe ask clarifying questions, but do not go into arguing about where either the feedback was right or wrong. The important matter is how the coachee or team experienced your coaching – there is most likely a point behind the feedback where either you liked it or not.

Previous parts published on August 16th and October 7th. Graphics from the author, accompanying illustrations from High resolution jigsaw puzzle pieces set by Horia Varlan/Flicrk.

Agile Testing Days 2013: Agile Testing is nonsense, because Agile is testing…

/by

Some impressions

The Agile Testing Days has definitely been an experience for me. I wasn’t sure what type of people I would have met at such supposedly very “vertical” and specific conference, focusing on testing in the Agile world. It’s definitely one of a kind, and I was positively surprised about the amount of people who are actually getting closer to Agile through the testing experience.

The quality of the speakers has been very high, I have attended almost all of the keynotes, and were all very well followed, and engaging too. I have learned that there are still a lot of people calling themselves tester, who are clearly willing to part themselves from the “developers”, which I find particularly strange in an Agile environment. Shouldn’t it be all about the team? Shouldn’t the team be a peer to peer team, with no hierarchy and no roles? Developing a product in Agile means making it shippable at every iteration, and that requires all the skills needed to make it happen! Which ones? It depends on the context… every product is different, and requires different skills and people to be developed.

I have met a lot of people and I have also rejoiced with some old acquaintances that I helped starting the journey toward Agile in 2009… and now they had quite some stories to tell, great! Overall it seemed a very well organized event, with fun in the evening, the right mixture of talks, workshops and also Open Space. One thing I would definitely change if I were one of the organizers, would be to cut the talk length to 45m maximum, so there would be more talks, and probably some would be more focused, I include myself in the category.

My opening keynote writeup in some way…


How it all started

It all started about a year ago, when I was asked to prepare a keynote for the Agile Testing Days, after having presented at the Agile Dev Practices in the same year. I was pleased to be asked to have the opening keynote, and on the other side also a bit puzzled, as I am no testing expert, as many of you may have noticed. I have been developing software for a very long time, and I still do it for fun, but now my main focus is on an overall organizational perspective, and definitely a mixture of Agile, System and Professional coaching (who doesn’t after all).

Still I am pretty much involved in supporting teams, and I can still teach ATDD, BDD and TDD to pretty much any programming language (well it is not about the language after all). So I had to think about what should I talk about, for 1h, one year ahead of time? How agile is that? Then I thought, maybe I should ask what sort of keynote were they expecting from me, considering that a keynote should maybe open a lot of doors to more specific and vertical talks, I was still unsure about the focus.

At the end it went a bit on the provocative side, well you can’t really argue that testing isn’t needed, or is a waste (as someone likes to say, and with whom I disagree). Testing is one of the activities required to create a product (software or not, doesn’t really make a difference), and it is not just about the compliance of what has been done with the expectations, but is about creating confidence in the team developing the product, that they are pursuing the right objectives, that what they are building is going in the right direction. Still some people tried to convince me that their job as tester is to find defects, which are a sort of trophy, a demonstration that they have been able to break the product (or even more explicitly the work those “others” developers did).

Why? As far as discovering things which do not behave as expected, or even discovering new things that nobody had thought about, testing is a discipline which helps a team refining its targets, and learning. Once it becomes a self-fulfilling prophecy, it looses pretty much its purpose and also introduces various dysfunctions. One of these, is the one I have exposed in my keynote as the “Show me the money!” dysfunction. If you are Agile, you know what I am talking about probably, such behavior is resulting from a fundamental distrust in the team and in what the team is doing. If there is no trust, then there is no Agile, but trust needs to be gained, it is not something we can “expect” as a precondition (sounds like testing a bit). And here is where I wanted to emphasize that being Agile requires to develop a certain mindset, which in particular is reinforcing the attitude to trust results based on the fact that we can validate them.

 

Testing as an attitude

This might seems natural to many, but if you have been in enough messed projects in your career, you probably will remember at least one time, in which people didn’t know exactly why they were doing what they were doing. And this is where the Agile mindset, strongly focused on results and goals, and allowing individuals to commit to achieve a goal, by allowing them to pull the work from a list of defined objectives (normally called backlog).

People start thinking about how would they know when they will be done, before starting to do anything. This attitude is required especially when working in complex contexts, where often isn’t clear what is the end results you are trying to achieve, or even it is a set of options and you need to understand if you are moving within the expected range. To strengthen the attitude, you need to practice, but before you can practice effectively, you need to try some approaches and understand what works and what doesn’t.

 

Testing as an approach

So let’s think at testing as an approach to experiment different ways in which a problem could be solved. If you think this is reflected in any sounding Agile thing you might be doing already since quite some time, you want to know what are the “Acceptance Criteria” of a User Story before committing to do any work on it. And once you have it in your hands, the first thing you start doing, in order to focus, is to identify what are the possible acceptance tests that you can derive from those agreed “Acceptance Criteria”.

Good teams at this point are already looking into automating, to be sure they are not wasting time in doing the wrong things, and to make sure there is a safety net, which will remind them to refocus on the goal of that story. As you may know it is all about shorting feedback loops, and the most valuable ones are the one you can shorten through the conversations with the Product Owner and the stakeholders, while defining what to test and how to test. Agile people do all possible things to visualize anything, because by visualizing, conversation can be more structured, and focused. This is a great approach too. Now the practices come into place, testing is full of practices.

Dan North (@tastapod) pointed out in his keynote, that there are at least 120 different testing practices that he was able to count in his experience, and decided to categorize in four quadrants (how comes are always four…) based on two dimensions: deterministic towards “random”, and manual towards automated (you can read more about this in his keynote Accelerating Agile Testing). Practices are useless if they aren’t supportive of the approach you are willing to adopt. Many people just adopt practices, such as TDD, because someone told them they are good, and they do not really think about the value nor the economical impact of doing TDD. Maybe they will eventually end up stopping doing it, because they won’t see any benefit (just another cool practice isn’t it?). Well, if more people would understand that TDD is about design of the software, and not testing.

 

Testing as a practice

This is exactly the approach that I was trying to highlight in my keynote, by explaining that Agile people might decide to approach the solution of a complex problem, by defining a set of tests which a possible solution should be able to successfully pass. This approach – writing tests first – is a well known principle of eXtreme Programming, and it is embedded with very fast feedback loops into the TDD practice.

So TDD is not about writing automated tests (that’s the output) but is about discovering the solution to a complex problem, by means of limiting the solution space through the definition of tests, which the solution has to fulfill. This leads to a more clean and focused design of the software, aiming at solving the “problem” and happens much faster (this is the outcome), than if you would sit and think at the solution from the inside out.

Finally I have made some back references to System Thinking and the Theory of Constraints, to highlight the importance of the behavior that a particular system is producing. I have presented as an example the behavior a push system is producing: focused on individual, competition, and compliance, while a pull system is normally producing a behavior focused on team, collaboration and value (as outcome). So if you really have complex problems to solve, you need people who can work in the most creative, safe-to-fail environment possible. This will require discipline, will require courage, and commitment, all of which is based on transparency, respect and trust.

With this in mind, invest in building great teams, and lead by example, coaching them developing the right attitude toward Agile. After a while, and some failed approaches, they will eventually find out practices which are supportive of their intentions, and will become more productive over time. Also don’t think you can sit on a bench and enjoy the ride, because the Agile mindset is rooted on continuous improvement, and that means, your bench will change shape, and move… probably every couple of weeks :-)

My Storify of the session.

printed sticky notes glued on board

Kanban for Portfolio Management 
talk at OSS4B in Prato

/by

On September 19, I gave a talk at the Open Source Software for Business conference in Prato.

The Conference has been very well organized and I had the honor to share the stage with the likes of Gene Kim (author of The Phoenix Project book), Dragos Dumitriu (the ‘hero’ manager described in David J Anderson’s Kanban book) and many others.

Slides for my talk Kanban for Portfolio Management are available here.

A question and exclamation mark of jigsaw puzzle pieces

Your Strategy for Asking Powerful Questions

/by

This blog post is the second in our series about professional coaching skills for agile coaches. If you have not yet read the first blog post: “Listen, be curious and ask the great questions!”, we suggest you to read that one before continuing here.

Asking the right questions is a challenging task. Especially when you do not want to pose your own opinion on to the person or team you are talking with. Great coaching questions are open-ended, non-judging and helps to foster new ideas and visions about possibilities. These kind of questions we call powerful questions.

There are several approaches to practicing powerful questions. They depend on which coaching school you are coming from. One approach is to practice a deck of questions until you know them by heart thereby being able to choose the right one in a given situation. Another approach is to learn a strategy on designing the right question in the moment. This strategy comes out of a model developed by the Canadian psychologists Karl Tomm.

The past and the future – simple and complex understandings

The approach of Karl Tomm has roots in systemic theory. It encapsulates circularity and the understanding that each of us has a different view of the facts about a given situation. No one has a monopoly on the truth. The model pictured below shows two dimensions: Time and understanding.

The past vs the future on the horizontal axis, and simple vs complex understandings on the vertical axis.

Some of our powerful questions are aimed at what has already happened, and some are aimed at what could happen. Some of our powerful questions presume that there is one and only one truth (linear questions), and some acknowledge the diversity in our understanding of the truth (circular questions).

When we ask questions that are past-oriented and linear, we ask questions like a detective in an interrogation: “What happened?”, “Who did what?”, “Who’s fault is it?”, etc. Here we are looking for facts that helps us understand the issue.

When we ask questions that are past-oriented and circular, we ask questions like a anthropologist doing his research: “What do you think was their motivation to do so?”, “From which point of view could the action he did, make sense?”, “Could it be that she saw something that the rest of you did not realize? What could it be?”, etc. We are looking for intentions and expanding our understanding of the intentions.

The questions we ask are future-oriented and circular questions with the intention of exploring opportunities and expanding possibilities. Here we ask questions like a future researcher. We might also ask questions that suggest that a miracle happened overnight: “If you come to work tomorrow and the problem has disappeared overnight, how would you notice?” “When you, in three months, have solved this matter and look back on it today, which decisions did you make that made a difference?”, etc. Questions in this category might seem a bit strange at first, but give it a try. The advantage of questions like this is that they disconnect the person or team in front of you from the constrained situation they are currently, freeing up energy to see new perspectives and decide new cause of actions based on those perspectives. They help the person or team in front of you to see which part of the miracle or the desired future is already present today and how they can be used as stepping stones towards the goal.

Finally, we can ask simple or linear future-oriented questions. They are questions that captain would ask. They are more directive and serve the purpose of setting direction for the wanted change: “What is the first thing you are going to do?”, “Who will you talk to?” and “How can he or she help you?”. Like in a retrospective, this is where the specific tasks are defined and prepared for action.

It is like driving a car

When coaching someone, we are mostly looking at the future and the change we are going to make. However, from time to time we must look back to the past to understand what have happened and why we are in the current situation. It is like driving a car: We are mostly looking out the windshield at the traffic in front of us, but from time to time we also look in the rear mirror to know what is behind us.

There is no specific route you must follow when using the model of Karl Tomm. Personally, I find  that most of the time I start as a detective, then become an anthropologist, then investigate  as the future researcher and finally ending as the captain. But on my way, I may jump back and forth when my intuition tells me to.

Asking powerful questions is a valuable tool you can use as a coach, and with practice, you can, in time, be fluent in this approach.

Read this series’s third and final part, “Have a structure for your coaching conversation”.

The State of Scrum 2013: a Report from the Scrum Alliance

/by

At agile42 we practise Scrum each day and we’ve been very pleased to see earlier this year the publication of the 2013 State of Scrum Report by the Scrum Alliance. The work is now available for free download and includes a PDF report, a webinar to watch online and a webinar presentation deck.

State of Scrum 2013Scrum Alliance is a nonprofit professional membership organization providing Advocacy, Community and Education to encourage and support the widespread adoption and effective practice of Scrum. This industry report is based on input from almost 500 business professionals in more than 70 countries. Participants represented various industries from IT to education, finance, government, healthcare, telecommunications, and more. Key findings from the report include the observation that Scrum is growing rapidly, not only in software development, but in industries far beyond. The report also reveals the leading reasons organizations are adopting Scrum and contains three recommendations for successfully practicing Scrum.

We are happy to collaborate with the Scrum Alliance worldwide, not only participating at various Scrum Gatherings and Coaches Retreats but also providing coaching services to the organization through our North American coaches Brad Swanson and David Sharrock since last summer.

agile42 is a Registered Education Provider (SA REP℠) and offers training courses leading to Scrum Alliance certifications like the CSM (Certified ScrumMaster), CSPO (Certified Scrum Product Owner) and CSD (Certified Scrum Developer). Check our offering of trainings or contact us with your team needs.

The Dark Champions of Agile: Hark… Who goes there?

/by

Click here to read “Part 1: Know Thy Enemy”, which identifies the resistors to change and how to defeat them and “Part 2: Gathering Allies for Change” which explains how to show leadership through action.

In part one of The Dark Champions of Agile we discussed the struggles of an agile transition and the forces and people, who will align against you to protect their status quo. The Dark Champion of Mediocrity and the Baron are personas we discussed with strategies on turning resistance into momentum. Part two discussed more personas and some perspectives on turning enemies into friends and ambassadors of agile. The values of Respect and Transparency dictate this proclamation; portions of this list were developed at the Coaches Retreat in Boulder, CO, Dec 2011, kudos to all whom contributed.

Knight

How to defeat the Dark Champions in your agile battles…

Anchor/Foot dragger:  This persona is openly resistant and will not accept change, even if you showed him the invention of fire, the wheel or sliced bread.  The Anchor professes allegiance to the old ways and will not accept agile.  This persona is usually banished with logic and results, the small wins you create in your agile transition.  The data and metrics collected to validate improvement to the team or product decreases the power associated with the Anchor’s voice.  Results win in any arena, so create your performance metrics to show that teams cannot afford, or tolerate, decreased work efforts.  Over time, the team will decide how best to onboard or drop the Anchor; inclusion is always preferred.  If the agile coach needs to intercede,  it is to facilitate a discussion between the Anchor and management on where best the Anchor can serve the organization.

Beware the Foot dragger, twisted cousin of the Anchor.  Foot dragger will use an ‘easy going’ attitude,  to hiding in plain sight.  Do not be fooled by the complacency that hides beneath the surface.  The Foot dragger does not impede progress but does not advance it, adding inertia to the system.  This persona is easily defeated by employing coordination tactics; have the Foot dragger run the next retrospective or lead a backlog grooming session.  Action defeats complacency.

Saboteur:  The Saboteur loves agile in public and loathes it in private.  It will conspire with others to resist agile in secret, opposite the Anchor.  It operates with non-value adding activities such as committing to work items and not finishing, derailing meetings with useless questions, hijacking demos with needless commentary.  The Saboteur is best dealt with in a two prong approach.  A particular behavior such as being late to every meeting is discussed in a one on one session.  Once the behavior is shown again, you can address the Saboteur with a “Sir, we previously discussed this issue…”. Now the power of the team can be brought to bear on the Saboteur.  Two such outings will reveal a pattern of behavior which the team will be more adept in finding sooner, as the team progresses.  Challenge the Saboteur to show deep knowledge of agile, by asking for book reviews, blog post updates, new ideas from the web, chapter reviews from books owned by the team.  Failure to produce knowledge for the team will not go unnoticed.

Dead Fish:  Go with the flow, don’t rock the boat, don’t whine, just do whatever, apathy…
The Dead Fish can be tricky if dealing with cultural diversity, gender or seniority.  My usual approach to the Dead Fish is to reinforce the authority of the agile transition.  This reassertion of management’s desire to work in a different methodology, will give you the perceived authority when establishing working agreements with this persona.  Dead Fish are first offered the gift of inclusion, ‘Please be one of us, join the team, be open minded’. If this persuasion is ineffective, then the message of discipline is delivered, “If you will not join us, do not resist or sabotage our efforts. Follow the team, the process and do as instructed.”  Although this is not the preferred way, it’s a way forward.  This tactic will help the Dead Fish participate while keeping a safe buffer between themselves and fully committing to the change.  They are usually converted over time, with some successes and hard fought changes.

Dead Fish and Foot dragger are almost the same, I see indifference in the Dead Fish and a half hearted commitment in the Foot dragger.  Perhaps its just nuance, opinion, word smithing or splitting hairs, but I see two personas.

Diva/rock star:  This persona is very prevalent, equivalent to the architect in the ‘ivory tower’ lording over us mere mortals.  The Diva has the technical expertise or seniority to hold sway over those in the lower courts, but you must not give way…You have been hired by his boss, so this conversation becomes
very focused.  I invite the Diva to meet with their manager and between the three of us, we come up with a plan to include/exclude the Diva.  When confronted with a manager or an Agile Champion farther up the food chain, the Diva is repelled but not defeated.  Beware the morphing into the Foot Dragger or Saboteur.  The more subtle approach to including/defeating the Diva is to schedule open debate sessions where attendance is optional and team issues can be discussed.  I propose a different forum than the retro, which has a higher purpose.  These battle sessions are perfect for giving the Diva the room to voice opinions, and for you to establish/demystify fact from fiction and handle/corral/gently instruct the Diva into what are the agile principles and who really holds authority in that arena.  A small, gentle display of authority, enough to show the other team members that a Diva can be managed, respectfully. Inclusion in decisions is the way to win over anyone, even those whom fight inclusion will break under team pressure to contribute.

Church Mouse:  The quiet, intelligent, introvert whom does not seem engaged.  This persona is perplexing but can be drawn out into a contributing member of a team.  The Church Mouse must be approached directly, usually with a buffering team member along for the conversation.  Space and respect are given in abundance and under no circumstance are you to interrupt when they speak.  Constant support is given in team discussions, even when disagreeing perspectives are presented.  Extroverts on the team are approached individually before meetings and silent signals are established for when discussions go long.  The usual exertion of force, see Diva, cannot be used.  One method to use is the cover of Critical Mass.  This technique involves gathering the team members that see the value in agile and have them proactively include the Church Mouse in pairing activities, demo prep activities, keeping the project board tidy and updated, lead a daily standup for the more adventurous.  The inclusion by the crowd, instead of the coach, provides the message of “It’s ok to change. Contribute to the conversation and help us grow”. 

Your Mission

Retrospectives that Rock

/by

The Team Retrospective may be the most critical activity of an Agile or Scrum team. Building the habit of learning from retrospectives is an important skill. Especially as a strong influencer (whether as a manager, team lead or simply through force of personality), there is a delicate balance between directing the outcome and allowing the outcome to emerge from the team. Ideally the team will take ownership of the learning, drive identification and collation of issues and their root causes, and brainstorm, discuss and decide on best possible actions. However, many times we see the impact of strong personalities on a team leading the retrospective in a particular direction, looking to prove a point, get the next obvious bottleneck dealt with, or otherwise guide the team’s behavior through assumptions rather than building up the mental muscles of self-awareness and self-directed learning.

Retrospectives are a delicate time for a team, in which we ask them to trust one another, follow the prime directive of retrospectives (“Regardless of what we discover, we understand and accept that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”) and challenge the status quo. In order for the team to feel safe to do this we need to manage the environment with care.

Here, we touch a little on attributes of effective retrospectives. If your retrospectives are timely, targeted and without undue influence, the tendency to skip retrospectives, or direct the outcome of the retrospective is diminished.

Respect People’s Time

Respecting people’s time is a critical aspect of this – this has less to do with preparation, though preparation is important, and more to do with respectful use of the time the team takes out of their daily work. First, the retrospective (like any meeting) should start on time, be timeboxed, and reach a real, actionable conclusion on one or perhaps two key issues. Second, the decisions made during the retrospective should be acted on in the next sprint and when impediments extend beyond what the team can own themselves, impediments should be visible and given management attention. The highest priority should be given to following through with the changes suggested by the team and quickly addressing impediments raised.

Without this commitment to resolution, the team will soon see that the retrospective is not given the priority outside the team, and stop challenging the status quo and looking for genuine improvements. Recommendations become perfunctory – simple changes that have little impact on the real barriers to high performance – rather than challenging the current product delivery paradigm and stepping into the realm of true innovation and ownership of delivery outcomes.

Provide Intent

Retrospectives on general improvement of the iteration soon reach an impasse. The team has made all the obvious changes they can and probably avoided the few critical changes they could make, assuming some things simply cannot change. At this point, the retrospective may lose impact without a change to the format of the retrospective process.

To revitalize the retrospectives, we can use different retrospective patterns, such as timeline retrospectives or sailboat retrospectives, for example (see How to Hold a Sailboat Retrospective). However, the simplest way to inject another level of energy into the retrospective is simply to provide intent by setting a clear question at the beginning around which to retrospect.

Most retrospectives revolve around an implicit (or sometimes explicit) question about how the most recent sprint can be improved. Framing an alternative question for the retrospective is a powerful way of guiding the team to discuss points of interest on the periphery of the sprint itself.

To be valuable, the intent should be clear to all, relevant and definitely not self-serving. These could be focussed on uncovering specific issues tangential to the success of the sprint itself (e.g. what would have to change for the team to deliver twice as many stories in the same amount of time?) or targeted on organizational issues being ignored by the team (e.g. how can we reduce or eliminate the wait for regulatory compliance sign-offs for new features?)

Beware of Implicit Influence

In many teams, key individuals may carry implicit authority and influence, whether through experience (e.g. the senior architect), longevity (e.g. employee #4) or previous or current position (e.g. the project manager turned scrum master). This means that one statement made by the team carries a different weight to the same statement made by a key influencer.

For example, if the team comes up with a statement like “the team should critically review the suitability of the existing software design for any new stories” this will be discussed in the context of the root cause being addressed, and whether or not this solution will cause the required behavior or outcomes. The same suggestion made by a key influencer, even in their role as a Scrum Master, Product Owner or Team Member, may be interpreted as prolonging the status quo, or defending a strongly held personal opinion by the team. This can cause the team to immediately abdicate responsibility both for the outcome (e.g. by not following through and committing to make the required changes in a timely fashion) and the resolution of the original impediment. The team as a whole loses.

In almost all cases, the most valuable behavior of any influential role model is to listen and perhaps ask clarifying questions. Any other observations or inputs can be made through the brainstorming and collation process, or through providing intent, as described above.

What other hints and tips do you recommend for maximizing the learning opportunity of a retrospective? Let us know…

Team

What does it mean for a team to be truly self-organised?

/by

I love the way Claudette Moore sums up what a self-organised team is all about:
Self Organised is the capacity you have as a team to arrange yourself in such a way that you can effectively and happily complete tasks that you have committed to within the constraints that a company puts on you. – Claudette Moore
In my opinion, a typical self-organised team needs the time and support to mature. It is not an easy process, and can’t be forced. During the process there will be laughter and tears, conflict and collaboration. This is all worth it in the end, as without going through this process, all you have is a framework. Ultimately, to become a high performance team, this path needs to be followed. The results however, are well worth it – a team that is highly collaborative, cross skilled, able to solve complex problems, remove their own impediments, delivering high value outcomes, focused and driven to achieve results and true value.

In my opinion, for a team to become self-organised, they need the following:

    • Framing / Boundaries in which they can work. It’s important to include managers in this process so that the managers understand that a self-organised team does not make them redundant.

 

    • Trust among each other and the Scrum Master.

 

    • Goals and a vision not only for the product they are delivering, but for each sprint as well.

 

    • Measurement – you need to know where you are in order to see if you are improving. Be careful with this one, using the wrong metrics can destroy a team.

 

    • Encouragement to fail early to maximise learning. This behaviour should be supported by the business and not punished.

 

    • Support and direction by business and Scrum Master so that they are encouraged to solve their own problems and not dictated solutions.

 

    • Autonomy to decide not only how but who.

Team Maturity

From my perspective, a new team will go through four levels of maturity. It is important to understand at what level the team is, in order to guide appropriately.

I use the analogy of growing up from infancy to adulthood to describe these four levels:

    1. Infancy
        • New to Agile / Scrum.
        • Haven’t actually adopted scrum in a working environment yet
        • In a dream like state after been sold all the pros of Agile and in theory it sounds wonderful and easy and their lives will be trouble free.
        • The trainers are like the parents, teaching their new borns and the new borns just accept everything they are fed.

 

    1. Toddler
        • Might still need to be micromanaged, require work to be allocated, decisions to be made for them.
        • Not willing or have the courage to challenge peers or managers. Happy to still just do as they are told.
        • Blaming external forces for non delivery and not finding ways to improve as a team (specifically retro’s).
        • Focusing on personal delivery and not the delivery of the team.
        • Don’t own or take responsibility for delivery.
        • Think being busy working on a bunch of stuff, means they are working hard.
        • Not focused on priority, but still influenced by who shouts the loudest.
        • Not very disciplined.
        • Still not able to see the real value of Scrum, no real adoption yet.
        • Level of re-work might still be high.

 

    1. Adolescence
        • Able to organise as a team, most of the time, in terms of making decisions on how the work will be completed.
        • Start to realise that starting too many things and not finishing, isn’t the best way to work.
        • Still focused on individual performance. Collaboration level still not great.
        • Start to challenge the process and Product Owner.
        • Start to reflect internally and not just externally.
        • Starting to focus on value based priority.
        • Able to deal with minor obstacles and start to solve their own problems without waiting for guidance.
        • Taking more responsibility, but will still look at someone or something else to blame.
        • Level of discipline is improving.
        • Starting to see the value of Scrum but adoption is shallow.

 

    1. Adult
        • Honest with each other, challenge each other, trust each other.
        • Able to reflect internally and find opportunities for improvements as a team and the way they work together.
        • Solve own problems.
        • Work as a team, level of collaboration high, and focus on finishing important work first.
        • Level of discipline high.
        • Able to challenge the business and are focused on delivering value for the customer.
        • Focused on quality and not quantity.
        • Understand the value and adopted Agile technical practices like continuos integration, BDD (Behavioural Driver Development) , TDD (Test Driven Development),  Automated testing etc.
        • Agile adoption is much deeper.

So as I said, the way a Scrum Master would interact and help a team develop, all depends on which level they are.

What can you do as a Scrum Master to influence self-organisation?

    • Identify at what stage the team is at and act accordingly. Let the team develop at their own pace.

 

    • Model behaviour expected from the team and by leaders.

 

    • Coach managers to become leaders.

 

    • Make sure the team understands their boundaries.

 

    • Have values and principles that you and the team stand by.

 

    • Focus on the core principles of Agile and ensure that the actions of the team supports these principles.

 

    • Keep things simple, always review what you and the team are doing. Keep looking back at the basics.

 

    • Encourage the team to try.

 

    • Ask powerful questions that make the team think rather than offer solutions e.g.
        • Is there another way?
        • Can you explain that to me?
        • How can we test that?
        • How can you help in the delivery of the Sprint?

 

    • Support the team and their decisions and protect them from the business or anything that attempts to derail them.

 

    • Coach the Product Owner and ensure they understand their boundaries.

 

    • Coach the business in terms of what Agile means, and what a self-organised team means.

I hope you are able to find some value in this and I welcome any feedback or questions.

The first Italian Certified Scrum Product Owner training

/by

One of the main activities of agile42 team between coaching assignments is to train new Scrum professionals and prepare them for Scrum Alliance certifications. Trainings are usually done in English but local communities can often enjoy a local-language course thanks to the network of coaches from different countries. It’s therefore been a thrill to witness the first Certified Scrum Product Owner training completely in Italian, run by Andrea Tomasini and Roberto Bettazzoni in Bologna at the end of July.

The training offered the full agile42 treatment consisting of background information about Lean, Agile and Scrum, teamwork games, interactive sessions with questions and answers and a full “startup” vibe for a class of 24 participants – coming from places as diverse as Florence and Canton Ticino. Thanks to everyone who took part, here’s a photo gallery of the two days.

The next official Italian CSPO will be held on September 9, again in Bologna. Please check our training list for more dates, cities and language options for all certification courses by the coaches of agile42!