Great technique described by Shahin Sheidaei on his blog: Challenge, Estimate or Override (CEO) Game for Effective Estimations. It is much quicker than the Planning Game, and probably a bit slower than the Bucket System.
Great technique described by Shahin Sheidaei on his blog: Challenge, Estimate or Override (CEO) Game for Effective Estimations. It is much quicker than the Planning Game, and probably a bit slower than the Bucket System.
The team decides on how much work it will do in a Sprint. No one should bring pressure on the team to over-commit. This simply builds resentment, distrust and encourages low-quality work. That said, of course teams can be inspired by challenging overall project or product goals. A stretch goal for a Sprint is just a way to 100% guarantee failure. Even the team should not set its own stretch goals.
There are a few interesting principles that apply here. For example, the Agile Manifesto mentions sustainability:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The Agile Manifesto also points out the importance of trust:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Stretch goals are incompatible with both of these principles from the Agile Manifesto.
There are two types of stretch goals. The first type are those assigned by outsiders to the team. The second type are those which a team sets for itself. Both types are bad.
The worst extreme of this type of stretch goal is also the most common! This is the fixed-scope-fixed-date project deadline. In this type of stretch goal, the project team, doing Scrum or not, is forced to work backwards from the deadline to figure out how to get the work done. If the team can’t figure this out, managers often say things like “re-estimate” or “just get it done.” (Note: another thing that managers do in this situation is even worse: adding people to the project! Check out “The Mythical Man-Month” by F. Brooks for a great analysis of this problem.)
My anecdotal experience with this sort of thing is simple: quality suffers or sustainability suffers. I once worked with three other people on a mission critical project to help two banks with their merger. There was a regulatory deadline for completing the integration of the two existing systems for things like trading, etc. Fixed-scope-fixed-date. Coffee and sleepless nights were our solution since we tried not to sacrifice quality. We actually ended up working in my home for the last few 24-hour stretches so that we would have access to a shower. Suffice it to say, there’s no way we could have sustained that pace. It’s anti-Agile.
A quick search for ideas and opinions about stretch goals makes it very clear that there is no commonly agreed “correct” answer. However, from an Agile perspective stretch goals assigned by outsiders are clearly against the principles of the Agile Manifesto.
The Scrum Guide states:
The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
For emphasis: what it can accomplish – not what it (the Development Team) wants to accomplish, or what it should accomplish, or what it could accomplish if everything goes perfectly. A Development Team should be accomplishing their Sprint plan successfully (all Product Backlog Items done) on a regular basis. Of course, exceptional circumstances may intervene from time to time, but the team should be building trust with stakeholders. Here’s another story:
I had a good friend. We would always go out for coffee together. We just hung out – chatted about life, projects, relationships. Of course, from time-to-time one or the other of us would cancel our plans. That’s just life too. But there came a time when my friend started cancelling more often than not. There was always a good excuse: I’m sick, unexpected visitors, work emergency, whatever. After a little while of this I started to think that cancelling would be the default. I even got to the point where I was making alternative plans even if my friend and I had plans. I got to the point where I no longer trusted my friend. It didn’t matter that the excuses were always good. Trust was broken.
It doesn’t matter why a team fails to meet a goal. It reduces trust. It doesn’t matter why a team succeeds in meeting a goal. It builds trust. Even among team members. A team setting stretch goals is setting itself up for regular failure. Even if the team doesn’t share those stretch goals with outsiders.
Stretch goals destroy trust within the team.
Think about that. When a team fails to meet its own stretch goal, team members will start to look for someone to blame. People look for explanations, for stories. The team will create its own narrative about why a stretch goal was missed. If it happens over and over, that narrative will start to become doubt about the team’s own capacity either by pin-pointing an individual or in a gestalt team sense.
The importance of trust cannot be over-stated. In order for individuals to work effectively together, they must trust each other. How much trust? Well, the Agile Manifesto directly addresses trust:
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
Here is my recent YouTube video about stretch goals… check it out and subscribe to our channel!
Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!! It is better to wait for someone to step up than to “take over” and start assigning tasks.
Assigning tasks can be overt or subtle. Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”
In the Scrum Guide, a partial definition of self-organizing is given:
Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
A more formal definition of the concept of “self-organizing” can be found here:
Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.
The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.
People who are managers are often worried about this. What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing? Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.
Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.
Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs. Assigning tasks doesn’t make a person more productive.
Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!
There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.
And, of course, there’s always the Sprint Retrospective!
Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.
Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees). Even if this is true, it is still easy for a person to take offence. However, most of the time it is not true. People know themselves best. People are best at assigning tasks to themselves. And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.
The ScrumMaster plays an important role in Scrum. Part of this role is to encourage self-organization on a team. The ScrumMaster should never be assigning tasks to team members under any circumstances. And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks. If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening. The ScrumMaster needs to be constantly aware of the activity on his or her team.
I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:
This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.
The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track. The Daily Scrum is timeboxed to a maximum of 15 minutes, but often should be even less. With a good physical task board, a Daily Scrum can often be done in less than a minute simply by each team member pointing at the pieces of work they are working on.
From the Scrum Guide:
The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
In other words, don’t have those discussions during the Daily Scrum! The Daily Scrum is essential to creating transparency and implementing the Scrum value of Openness. The three questions of the Daily Scrum are effectively:
Each member of the team takes a turn and answers those three questions. This doesn’t have to be completely stilted, but it should be Focused (another value of Scrum) and efficient so that the need for other meetings is minimized. Accomplishing this takes some practice. The ScrumMaster helps the team to keep the timebox, but at first, a team might have challenges with this.
There are a some common reasons that a team might struggle with wanting to problem solve in the Daily Scrum:
Just beware: yet another pitfall (although not common) is to decide that the Daily Scrum shouldn’t be daily because it is taking so long. Unfortunately, making this change will often just make the meetings even longer until they devolve back into weekly status meetings reporting to the team lead!!! Remember that it’s not Scrum anymore if your team doesn’t meet together daily.
Ultimately, if a team is struggling with the Daily Scrum in any way, this is a valid topic for discussion in the Sprint Retrospective.
This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.
Very nice article called Why I Always Start a Meeting with a Check-In. From the article by Ted Lord, senior partner, The Giving Practice:
The greatest benefit of working in a group is our diversity of viewpoints and approaches; groups hobble themselves when they don’t continually give attention to creating a container of trust and shared identity that invites truth-telling, hard questions, and the outlier ideas that can lead to innovation
One antidote to over-designed collaboration is the check-in.
My colleague and friend Mike Caspar has posted another insightful article on his blog: Do not create unnecessary fear and animosity with Development Managers. From the article:
As teams grow, they build confidence and seem to become self-contained, and almost insular to some. This is normal and is not a sign of dysfunction. This simply indicates that the team is starting to have self identity. They are starting to act as a team. This is a good sign…. As the teams become more effective, the Development Manager feels more loss.
The other day a technology leader was asking questions as if he didn’t agree that things like pair programming and code review should be part of the Definition of “Done” because they are activities that don’t show up in a tangible way in the end product. But if these things are part of your quality standards, they should be included in the definition of “Done” because they inform the “right way” of getting things done. In other words, the Definition of “Done” is not merely a description of the “Done” state but also the way(s) of getting to “Done” – the “how” in terms of quality standards. In fact, if you look at most of any team’s definition of “Done”, a lot of it is QA activity, carried out either as a practice or as an operation that is automated. Every agile engineering practice is essentially a quality standard and as they become part of a team’s practice, should be included as part of the definition of “Done”. The leader’s question was “if we’re done and we didn’t do pair programming and pair programming is part of our definition of “Done”, then does that mean we’re not done?” Which is sort of a backwards question because if you are saying you’re done and you haven’t done pair programming, then by definition pair programming isn’t part of your definition of done. But there are teams out there who would never imagine themselves to be done without pair programming because pair programming is a standard that they see as being essential to delivering quality product.
Everything that a Scrum Development Team does to ensure quality should be part of their definition of “Done”. The definition of “Done” isn’t just a description of the final “Done” state of an increment of product. In fact, If that were true, then we should be asking why anything is part of the definition of “Done”. This is the whole problem that this artifact solves. If this were the case, the team could just say that they are done whenever they say they are done and never actually identify better ways of getting to done and establishing better standards. We could just say (and we did and still do), “there’s the software, it’s done,” the software itself being its own definition of “Done”.
On the contrary the definition of “Done” is what it means for something to be done properly. In other words, it is the artifact that captures the “better ways of developing software” that the team has uncovered and established as practice because their practices reflect their belief that “Continuous attention to technical excellence and good design enhances agility” (Manifesto for Agile Software Development). The definition of “Done” is essentially about integrity—what is done every Sprint in order to be Agile and get things done better. When we say that testing is part of our definition of “Done”, that is our way of saying that as a team we have a shared understanding that it is better to test something before we say that it is done than to say that it’s done without testing it because without testing it we are not confident that it is done to our standards of quality. Otherwise, we would be content in just writing a bunch of code, seeing that it “works” on a workstation or in the development environment and pushing it into production as a “Done” feature with a high chance that there are a bunch of bugs or that it may even break the build.
This is similar to saying a building is “Done” without an inspection (activity/practice) that it meets certain safety standards or for a surgeon to say that he or she has done a good enough job of performing a surgical operation without monitoring the vital signs of the patient (partly automated, partly a human activity). Of course, this is false. The same logic holds true when we add other activities (automated or otherwise) that reflect more stringent quality standards around our products. The definition of “Done”,therefore, is partly made up of a set of activities that make up the standard quality practices of a team.
Professions have standards. For example, it is a standard practice for a surgeon to wash his or her hands between performing surgical operations. At one time it wasn’t. Much like TDD or pair programming, it was discovered as a better way to get a job done. In this day and age, we would not say that a surgeon had done a good job if he or she failed to carry out this standard practice. It would be considered preposterous for someone to say that they don’t care whether or not surgeons wash their hands between operations as long as the results are good. If a dying patient said to a surgeon, “don’t waste time washing your hands just cut me open and get right to it,” of course this would be dismissed as an untenable request. Regardless of whether or not the results of the surgery were satisfactory to the patient, we would consider it preposterous that a surgeon would not wash his or her hands because we know that this is statistically extremely risky, even criminal behaviour. We just know better. Hand washing was discovered, recognized as a better way of working, formalized as a standard and is now understood by even the least knowledgable members of society as an obvious part of the definition of “Done” of surgery. Similarly, there are some teams that would not push anything to production without TDD and automated tests. This is a quality standard and is therefore part of their definition of “Done”, because they understand that manual testing alone is extremely risky. And then there are some teams with standards that would make it unthinkable for them to push a feature that has not been developed with pair programming. For these teams, pair programming is a quality standard practice and therefore part of their definition of “Done”.
“As Scrum Teams mature,” reads the Scrum Guide, “it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” What else is pair programming, or any other agile engineering practice, if it is not a part of a team’s criteria for higher quality? Is pair programming not a more stringent criteria than, say, traditional code review? Therefore, any standard, be it a practice or an automated operation, that exists as part of the criteria for higher quality should be included as part of the definition of “Done”. If it’s not part of what it means for an increment of product to be “Done”—that is “done right”—then why are you doing it?
Retrospectives are a key part of continuous improvement in Agile teams. The retrospective techniques that a team uses should be adjusted to the needs of the team. In a Scrum team, for example, the ScrumMaster will often decide on the techniques to use based on the current issues facing the team and then facilitate the retrospective for the team. There are some great resources which give you collections of tried-and-true retrospective techniques including Esther Derby’s book “Agile Retrospectives” and the amazing online tool “Retr-o-mat“. As an active consultant and trainer, I am always looking for new techniques to share with my clients. Sometimes, I even create a new one (or at least new to me). The “What Did You Learn” technique is new: I’ve been using it and testing it for a few years now to refine it.
What Did You Learn?
By itself, this is a powerful question. As part of my work with OpenAgile, I’ve been helping teams and organization to focus on learning as an even broader category than continuous improvement. The Learning Circle and the processes in OpenAgile help with focusing on learning. The question “what did you learn?” is very open ended, and can certainly work as an extremely simple type of retrospective in OpenAgile or in Scrum or other Agile methods. Often people like to have a little more structure and guidance so the “What Did You Learn?” retrospective technique provides four categories of learning for people to think about, share, and discuss within a team.
Setup for this retrospective is very simple: a flip chart or whiteboard divided into four sections or columns works fine, along with a piece of paper for each person in the retrospective, divided up the same way, and sufficient markers and pens for everyone. Here is a downloadable PDF version of the handout for the “What Did You Learn” retrospective.
The facilitator will also participate at various points if they are a member of the team (e.g. a ScrumMaster). It is easiest to do this with a group in-person, but can also be done reasonably well with video or teleconferencing.
The facilitator introduces the retrospective with a welcome and, if necessary, a recitation of the Retrospective Prime Directive. Then, the process is described to the group. Each of the categories of learning is also explained as follows:
There are three main stages in the retrospective as follows:
This is an excellent retrospective for a team that is going through a significant transition such as starting a new project, a major change in business direction for a product, or as a wrap up technique for sharing lessons learned with other parts of an organization. It is not a good technique for a brand new team that hasn’t worked together before as there will be little common ground for deciding on the importance of peoples’ various shared learning.
In our professional lives and in doing business, we commonly follow the advice to “dress for success.” We make certain to wear that business suit, or a particular pair of snazzy heels, or a certain color of tie. For better or for worse, we can be judged in the first few seconds of contact with a potential employer or customer by our attire, our hairstyle, our facial expression, our nose ring…
A more subtle way we evaluate a person is through the sound of his or her voice. The voice is a very personal instrument, and it can communicate so much about who you are, your abilities and your intentions.
The voice can tell you whether someone is nervous or at ease. Whether they’re authentic or stringing you a line. Whether they care if they communicate with you or not. When I was a kid, I thought I could detect when someone was lying to me by a certain glitch in the voice, or a tell-tale tone. Often, our brain makes intuitive judgements about what’s being said to us, and is sensitive to vocal rhythm, clarity, tones, and the use of language.
One may think it’s not fair to judge someone by their voice. Let’s face it, a voice – like being short, or having a large nose – is usually unchangeable. But it’s how the voice is used that matters. We all have an inherently full, expressive voice, but things happen to us in life that can negatively influence and/ or harm that voice.
Think of the person who speaks so quietly it’s almost a whisper – you must lean closer to catch what she says. This person may have had some trauma in her life, like being constantly told as a child to ‘be quiet’, to de-voice her. I know people whose greatest fear is public speaking, who quake inwardly and outwardly, even if they have something important to share with others.
Personality is also expressed through the voice. Imagine the annoyingly loud talker sitting nearby in a restaurant. This is certainly someone who wants too much attention and tries to get it by being overbearing. Or the fast-talker, who doesn’t want any other opinions but his own to be expressed, and doesn’t give the listener an opportunity to think or to respond, lest they disagree with him.
Anyone can be trained to use their voice for positive communication. A voice is an instrument that can become effective and optimal with practice.
Here’s a few things to think about in how you use your voice:
Are you clearly enunciating your words so as not to be mis-heard?
Are you directing your voice to the person or people you want to communicate with?
Are you speaking in a rhythm that’s neither too fast nor too slow?
Are you allowing your true feelings or intentions to come through?
Are you being honest?
The voice is just one of the important tools we use to communicate. If your work requires relating to other people in any way, for example, making presentations, or promoting a product, consider how you use your voice and what it may communicate about you!
Agile Advice was started in 2005. In ten years, we have published over 850 articles (an average of just about 2 per week!). Here are some collections of the ten “best” articles. I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.
Ten Most Popular Agile Advice Articles
Ten Most Commented Upon Agile Advice Articles
I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin). These contributors are all experts, all have great experiences, and all are fantastic people to know. I’m grateful for their contributions since they have all made Agile Advice a better place to browse!
Five Most Frequent Contributors (of Articles, besides Mishkin)
Plans for the Future – Five Top Ideas for Series
Agile methods and the culture behind them focus on teamwork, safe environments, motivation, technical excellence and lots of other things that are easy when business is good. But when business is bad, and you simply can’t afford to keep everyone around, what do you do?
… UPDATE …
Interesting: this tiny post has generated a lot of traffic… but no responses. Please feel free to offer suggestions or ideas or questions in the comments.
Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally. In some cases, management may even be hostile to the concepts and practices of Agile methods. If you are interested in Agile, you don’t have to give up hope (or look to switch jobs). Instead, here are some tips to start using Agile methods even in hostile environments.
Some Agilists claim that the retrospective is actually the key to being Agile. In some ways, this is also the easiest practice to introduce into an organization. Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“. These are retrospectives that can be done in 15 minutes or half an hour. Try to do them with your team weekly. If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting. If you are “just” a team member, you might have to get some modest amount of permission.
So why would it be good to do a retrospective? Because it’s a high return-on-investment activity. For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning. Here are a couple more articles about the importance of retrospectives:
Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start. Myself, my first formal Agile environment, I started with the Daily Scrum. Another time less formal, I started with Test-Driven Development. In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months. This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders. This is the practice-by-practice approach. Start with a simple Agile practice that you can do without asking anyone for permission. Make sure it is a practice that makes sense for your particular environment – it must produce some benefit! If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start. If you are more business-oriented, then maybe consider user stories or one of the Innovation Games. If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.
It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another. If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.
Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy. This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”. This is an opportunity to do Agile. Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.” There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support. In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it. Don’t talk about it.
The “just do it” approach requires that you have some influence. You don’t have to be an influencer, but you need connections and you need charisma and you need courage. If you don’t have at least two of those three, you shouldn’t try this approach. You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works. Here are a few comments on Stealth Methodology Adoption.
There’s nothing like working with a band of rebels! If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work. Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans. Of course, you need to actually execute some of your plans. Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.
But, like any rebellion, you really need to trust those you work with in these early stages. Lacking that trust will slow everything you do possibly to the point of ineffectualness. Trust means that you have, for some time, a formal vow of silence. Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.
Read “Fearless Change”
I can’t recommend this one enough! Read “Fearless Change” by Mary Lynn Manns and Linda Rising. This is a “patterns” book. It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use. Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent. Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.
Don’t Call it “Agile”
This isn’t really a “tip” in the sense of an action item. Instead, this is a preventative measure… to prevent negative reactions to your proposals for change. The words “Agile” or “Scrum”, while they have their supporters, also have detractors. To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names. Use another name. Or let your ideas go nameless. This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”. By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.
A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”. Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.
Get Some Training
Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program. It’s a 40-week program that takes about 12 hours/week of your time for coursework. The next cohort of participants starts in June 2015 and we are taking deposits for participants. This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.
The voting for re-introducing the five values of Scrum into the Scrum Guide is heating up with some great discussion (debate?). One person, Charles Bradley is providing some interesting arguments about why “commitment” should not be included or even changed to a different word. I have posted a response. I strongly believe that the word “commitment” is the right word. Here’s the first paragraph of my response:
Hi Charles, although I appreciate your concerns about the word commitment, there is still huge support for adding the five values back to the Scrum Guide, including using that “bad” word. I would like to present to you an argument for the use of the word commitment by telling a story.
A long time ago I had a really good friend….
Check out all the discussion on the five values of Scrum and please comment or vote (or both!)
I was recently checking my Google Analytics for Agile Advice and the article I wrote quite a while back in 2009 about teamwork skills is even more popular than the front page of this blog! I took a look at it and made some tweaks including providing some good references for more information about each of the teamwork skills. Take a look: Seven Essential Teamwork Skills. The only hard one was to find a good article about “sharing” as a teamwork skill. If you know of one, please comment so that I can add it! I’ll even be happy to take a link to an article you have written yourself.
In a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program. While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams. This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.
Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams. Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.
The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals. These teams are responsible for delivering value—business results and quality. Individuals are committed to the performance of the team and the organization. Teams develop the capacity to self-organize and focus on continuous improvement and learning. A team is usually composed of people from various roles at the delivery level. For example, and IT project team might be composed of people whose previous* roles were:
* These roles do not get carried into the new delivery team other than as a set of skills.
The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support. Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals. Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix. The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.
Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority. This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process. Usually, these steps take one or two weeks each, but sometimes they take longer. A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks. In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.
The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them. In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.
The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team. Of course, to do this requires some investment of time. Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.
See also the article on the Recommendations component of the Real Agility Program.