Tag Archives: Agile

Agile Coaches’ Corner Podcast

Leave a reply

I’m pleased to share that the relaunched AgileThought podcast: Agile Coaches’ Corner is now live and available on Google Play, iTunes, TuneIn Radio, Stitcher, and other podcast listening platforms!
Please help us get the word out by listening, subscribing, providing a review, and suggesting topics for future shows.

You can listen on:

Agile Coaches Corner on Google Play
Agile Coaches Corner on Apple iTunes
Agile Coaches Corner on TuneIn 
Agile Coaches Corner on Stitcher 
Agile Coaches Corner on Android
Agile Coaches Corner on our source, LibSyn

This milestone would not have been possible without the the collaboration of several colleagues at AgileThought, including Sam Falco and Emily Culclasure, along with the support of other AT leadership. Thank you, all.

There is an “i” in “Agile”

Leave a reply

There’s a popular phrase that states “there is no ‘I’ in ‘team.'” This slogan appears on shirts. It appears on posters. It is popular enough that the phrase has been “hacked” and now there is a funny graphic that says “There is an ‘i’ in Team. It’s in the a-hole.”

There is an “i” in “TEAM.” Hidden in the A-Hole. (Copyright belongs to the image’s creator)

What might that phrase mean to an agile team? There is a SolutionIQ article that states “There is no I in Agile” and discusses how teamwork can make or break an agile team. I agree that teamwork is important. But, contrary to the SolutionsIQ heading, there is an “i” in “agile.” And it is important that we remember that the agile team is made up of a whole bunch of “i’s.” Here are some of the ways to make the “i” in “agile” effective. Work to help each “i”:

  • i realize that i cannot be successful if the team fails
  • i look for ways to help teammates
  • i bring new ideas into the team
  • i am willing to take risks
  • i admit when i need help
  • i admit when i am wrong
  • i grow my skills over time
  • i build upon other people’s ideas with my own
  • i bring my whole self to the team
  • i try to not be defensive
  • i realize others bring their whole self as well
  • i realize that the world outside work impacts people at work
  • i take small risks and learn from the outcome
  • i respect my teammates
  • i foster collaboration across the team
  • i use my eyes to observe what is happening on the team
  • i am a “little i,” not demanding the attention of a big “I”

Remember that your team is composed of many individuals, each with their own background, values, and perspectives. Work to be inclusive of those differences as you work toward a common goal.

Agile Meme

Agile. You Keep Using That Word.

Leave a reply

Agile MemeHow many times do you hear somebody blurt out that something is “agile?” And how many times, after they describe a behavior, you feel like our good friend Inigo Montoya listening to Vizzini?

As an Agile Coach, it is important to explore the “agile” behavior that people are referring to.

Here are a couple ideas for how to explore the use of the word “agile” and what it might mean:

The Principles Behind the Agile Manifesto

Go back to “the source” of what is defined as Agile and explore how the behavior described aligns with, or contradicts not only the Agile Manifesto, but the 12 principles behind the agile manifesto. Sometimes you can simply have a conversation about the principles. More often, it is helpful to have some type of lightweight activity, such as the one that follows.

Reflective Active On The Principles

I created a worksheet for exploring the agile principles. The worksheet gives a framework for exploring the presence, or absence, of individual Agile Manifesto Principles in your team or organization. For each principle, there is a space for indicating that the principle is present (write a “+”), absent (write an “-“) or ambiguous (write a “?”) and then jot a few words about why you thought it was the case.

Conclusion

First, I want to thank my colleague Frank Rios for pairing on generating the meme. Hopefully you find it as funny and memorable as we are. Second, be curious about the use of “agile” and get more specific about what people are thinking when they say it.

 

Agile Sustainability

Leave a reply

What makes an organization that has decided to “go agile” one that is able to sustain the transition?

This week, Susan DiFabio and I presented on the topic of Agile Sustainability to the Chicago Agile Project Manager Meetup. The objective of the presentation was to have people leave the presentation with some ways that they could take action to make their Agile environments more likely to be sustained.

Click below to download the presentation and speaker notes.

Agile Sustainability

Activity Bingo – Make a game out of promoting cross-functional behavior

Leave a reply

Are siloed activities hampering your Agile team’s ability deliver work within an iteration? If so, consider encouraging more cross-functional activities. But, how do we make that happen? Let’s start by making cross-functional activities visible, and making it fun. We can set it up as a Bingo game.

Setup

Create a table with each team member’s name on the left column of each row, and the activities required to deliver the iteration work at the top of each column.

Make the charts big and visible. The more aware team members are regarding how they stand, the more motivated they will be to fill in the gaps.

Now let’s play the game

During the iteration, track the types of work that each team member contributes to meeting the overall iteration goal. To track the contribution, simply put a mark at the intersection of the activity and the person’s name. At the end of the iteration, look at the pattern that has shown up on your Activity Bingo board. If you are like some new Agile teams, the grid starts out sparsely populated (a holdover from siloed organizations).

Horizontal Bingo

As team members increase the number of ways in which they contribute to the team, your team may score a horizontal BINGO.

Vertical Bingo

Similarly as more team members swarm on specific activities and you develop real depth on the team, you may score a vertical BINGO.

Speed

If you want to try to build on the game, consider seeing how early in the iteration the team can end up with either a row or a column filled up.

Celebrate

Be sure to recognize the team’s accomplishments toward being a more effective team.

What techniques have you used to foster cross-functional behavior?

A special thank you to Susan DiFabio, Agile Coach, for co-authoring this blog. Thanks, Maria Matarelli, for your assistance in naming the game.

p.s. Check out another article on Agile teams, tasks, and limiting WIP.

Is Kanban really Agile?

5 Replies

Short Answer

Honestly, it doesn’t matters. If it helps an organization create value for its customers in a way that allows employees to experience freedom while solving challenging problems, it doesn’t matter what label the method carries! But, that would be too short a response.

Longer Answer

One way to decide if something should wear the label “agile” is to look at how it reflects the values stated in the Agile Manifesto. Of the Agile Manifesto statements, this is how Kanban values the “items on the left” over those on the right.

Individuals and Interactions over Processes and Tools

The visibility that Kanban provides to teams is a key contributor to facilitating interaction amongst individuals. The kanban board gives visibility to impediments that individuals are encountering makes resolving the impediment of prime importance.

Unlike Scrum, Kanban does not explicitly encourage generalization of skill sets. While Kanban does not force you to have a role for every queue, it is often easy to start by mapping the roles to queues and then inspect the bottlenecks and address those by helping the team develop more generalized skills.

Kanban is not a tool or a process that supersedes the importance of the individuals and their interactions. Yes, Kanban provides a lot of metrics that can be used to inform planning. However, the metrics are to facilitate interaction among team members, between team and stakeholders, and between team and customers.

Working Software over Comprehensive Documentation

When using Kanban to produce software, there are specific characteristics of Kanban that allow you to value working software over comprehensive documentation; small batches, WIP limits, measuring and managing flow. Perhaps your workflow will have a step or steps related to creating documentation.

Kanban does not prescribe working software, other than through mapping your value stream. If the last step in the value stream is working software, you can use Kanban as a tool to make sure you do that.

Customer Collaboration over Contract Negotiation

Kanban encourages customer collaboration through the prioritization of the backlog. Prioritization of the backlog is an ongoing process. Agile Kanban practitioners often use user stories or minimal marketable features (MMF). Use of either of these approaches supports customer collaboration in creating those items. The person who provides the detail on the stories or MMF is also available to the team to respond to questions.

As in Agile, daily standups are also present in Kanban. Unlike Agile, only people with issues speak in the daily standup. The standup meeting is an opportunity to speak up, whereas in Agile the traditional “three questions” are often present. This gives the team an opportunity to elevate issues to the Product Management representative’s attention, allowing them to be a partner in the process.

Silver Bullet Policy (see slide 20 for a brief overview) allows the customer to swap out an extremely high priority item for the current work in progress. There needs to be a swap so that WIP limits are not exceeded. Silver Bullet Policy may never be used, but can give the business the feeling that if there is an emergency, they can use this policy.

Responding to Change over Following a Plan

Agile teams often plan on a regular cadence. In Kanban, planning events can be triggered on an event. For example, your team may have a rule as follows: When the backlog backlog has dwindled to ten stories, a planning event will be held.

Unlike Scrum or XP, where the teams try to identify a piece of stability to work on for a period of time, Kanban allows the team to re-prioritize the backlog at any time and take something new off the backlog. This allows the team to respond to change sooner than if they were locked into a set sprint duration.

Summary

While Agile is primarily focused on software, Kanban is more focused on developing a lean organization . In fact, the business-oriented language that surrounds Kanban may make it an easier Agile model to embrace than Scrum.

While an organization or team can claim to be using Kanban and use it in non-agile ways, that will not be the case when done well. If the team and management use visualization, set WIP limits, and iterate on the value stream, Kanban is an excellent option for Agile teams.

Find More Information

There are lots of excellent resources on Kanban. My favorite reference is a book called Kanban – Successful Evolutionary Change for Your Technology Business. Thank you, Eric Landes, for loaning me your copy for a while. For further reading, check out the InfoQ version of the Kanban and Scrum Book.

A special thank you to Eric and Susan for co-authoring this blog.

Susan DiFabio, Agile Coach

Eric Landes, Agile Coach

Agile Community in Small Cities

Leave a reply

I attended Agile Coach Camp United States (Twitter #ACCUS) this weekend. ACCUS is an open space, self organizing conference. I created a video to share the results of the open space topic I proposed, building Agile community in small cities:

[youtube=http://www.youtube.com/watch?v=0ZcjCyY9I6M]

Please feel free to comment on other ideas for building community, especially if you have tested those ideas and have learned from it.

There can be only one

Leave a reply

Are you on a team where tasks seem to get started but not finished? Does the daily standup involve updates where individuals work on what seems like the same handful of tasks for multiple days?

Here’s a technique you can try for limiting work-in-progress. Instead of identifying task ownership whereby team members write their name on multiple task cards, ask each to use a single PostIt note with their name on it. Each person gets only one note with his or her name on it. Let’s face it, even if you have more than one task in the “In Progress” column, you can only work on one at a time. The sticky note is to be placed on the task that is being worked on at that moment. The note is moved throughout the day when changing tasks.

Here are some benefits of this approach:

Token to help address too much WIP

  1. Only one task can be claimed by any individual.
  2. The team now sees exactly who is doing what work at any moment.
  3. The team sees which tasks that are “In Progress” but not being worked on.
  4. Knowing what each person is working on makes it safer for team members to begin work on idle tasks.
  5. By no longer staking your claim to a whole set of tasks, you invite more collective ownership of completing the team’s work.

In addition to simply putting your name on a single sticky note, you could also capture data about context switching with this simple method. Write the date on your token. For that day, put a tally mark on the note each time the token moves from one task to another.

By using the date and tally marks on the card, you can get a sense for how much context switching is happening throughout the day. Perhaps thrashing is an impediment for your team. Of course, if you switch tasks six times and 5 tasks are completed, you probably don’t have a problem. If you switch six times and nothing gets to “Done,” there may be an impediment’s root cause to search for. Collect the notes throughout the iteration and look for trends in the data.

I hope you find this technique useful. Feel free to comment on the post.

Failure or Success

Effective Agile Teams Begin with the End

4 Replies

Failure or Success“If you don’t know where you are going, any road will get you there,” said Lewis Carroll. Not only does this statement apply to individuals, but also to teams. In either case, you might not like the destination when you get there.

Stephen Covey’s second habit is “Begin with the End in Mind”. Before you can effectively create the physical manifestation of the product you want to create or the team you want to be, you have to first create a mental representation of that end state.

One exercise he proposes for helping to clarify what is supremely important to you is to visualize your own funeral. When you visualize your family, friends, or coworkers speaking about you after you have passed, what would you want people to say? As helpful as this visualization exercise can be for individuals to recognize what is important in their lives, it is also important for teams to determine what is important to them.

If an article were written about your team and preserved for the future, what would you want people to know about your team, about how you treated each other, and the way you went about your work? To help determine what is important to your team, consider your team’s ultimate goal. What do you want people to say about you, your team, and your work. Consider your teammates, your Product Owner, your stakeholders, and your customers. What about your functional manager? Consider involving your stakeholder community in the discussion.

Going through such an exercise can result in identifying a common view of what the team wants to become and how they want to operate. Without agreement on what the team values, the urgent demands of the project can keep you from becoming the team you need to become. Symptoms of teams without a compass may be that your team becomes myopic, focused on creating features to the detriment of sustainable pace or maintainable code. Alternatively, your team could become paralyzed by analysis and architecture debates, not recognizing when the analysis is sufficient to allow it to move forward.

To create your team vision is to “begin with the end in mind.” It is more than an elevator statement that captures the 30-second pitch for your product, and it is also more than a list of user stories that you intend to complete within a particular timeframe. What you want to distill from this exercise is a set of principles that can inform the decisions that you and your team will have to make through the course of your work. Take the information you collect and use it to create a mission statement for your team. When creating your mission statement, ensure the involvement of all team members; perhaps have a facilitated discussion led by somebody from outside the team can help ensure that all voices are heard. As Mr. Covey puts it: “No involvement, no commitment.”

Make your mission statement visible in your team room, on its wiki, give printouts to each team member, and anywhere else you feel is appropriate. If somebody is violating the mission statement, inquire about the deviation and determine if the mission statement has become outdated or if the behavior is perhaps not correct. Include a review of the mission statement as part of your retrospective.

Remember, if you are on an team and don’t know where you are going, you won’t get anywhere you want to be. Keeping the end in mind and using the mission statement as a team compass can help the team stay on track toward its desired goal.

Effective Agile Teams Are Proactive

Leave a reply

Proactively addressing risks is one of the major strengths of Agile methods. Not only do Agile teams have “spikes” to try to eliminate technical risks, but effective Agile teams have a mindset of eliminating a wide array of risks.  Here are some examples of ways risk is proactively addressed in Agile environments:

If a technology approach is of concern, we do a design spike and find out quickly if the approach isn’t feasible.

In Scrum, the retrospective is an explicit opportunity to look for ways to continue to improve, not resting with “we’re good enough”.

The “test first” approach is a proactive approach to quality.*

If the budget gets cut, we have working software created, not merely the requirements document, design document, and a pile of untested code.

The description of “Be Proactive” in the 7 Habits is “Proactive people take responsibility for their own lives. They determine the agendas they will follow and choose how to respond to what happens to them.” I don’t think I’ve seen an Agile book put it more succinctly. This excerpt could easily be rewritten for Agile teams: “Proactive [agile teams] take responsibility for their own [work]. They determine the agendas they will follow and choose how to respond to what happens to them.”

The Agile Manifesto’s 12 Principles has three in particular that stand out to me as having proactive risk mitigation components to them. These three are:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So, what do you do if you are on a team that has not embraced their responsibility to be proactive? Here are a couple of suggestions:

Consider whether or not your team has the trust necessary to be comfortable identifying risks. I suggest reading the book “Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators (J-B Lencioni Series)“. This book is a follow-up to the book “The Five Dysfunctions of a Team”. The “Overcoming….” book offers specific activities  and suggestions that help address the dysfunctions identified in the earlier book.

Is the team able to communicate in a high bandwidth mode? If risks are getting lost in low-bandwidth communication, consider moving to a collocated room. Eric Landes authored a DevX article entitled “Team Rooms Breed Highly Productive Agile Software Development Teams“.  FYI: You will have to register to read the article.

Model proactive behavior. One of the best ways to show that something is important is to do it yourself.

 Encourage your teams to be more proactive about their work, and I believe you will find that good things follow.

*See the “Being Proactive – Getting to the Triangle of Happiness” blog about testing as it relates to happiness on a blog by Daniel Wintschel and humandoing software.