In Defence of Waterfall…

~ Caroline Sauve ~ Leave a comment

I recently put together a whiteboard presentation that gives an overview of 6 different software development methodologies (Waterfall, XP, Scrum, Agile Manifesto, Lean and Kanban). I started with the grand-daddy of all the methods… Waterfall.

I’m glad that I did… because doing so reaffirmed for me that Waterfall, like most software methodologies, is often misunderstood.

I want to be clear. The whole document maintenance nightmare, lack of customer feedback, hard core linear process of Waterfall is indeed still part of Waterfall. But viewing it in the historical context of the 1970s, I came to realize some of the honourable goals behind the Waterfall process. As a developer, I had to imagine a time where writing and compiling code could be extremely time consuming and costly to do. Suddenly, trying to sort out as many details before writing a single line of code started to make sense.

So when you look at a particular software development methodology, it may be worth taking into account what motivated it’s creators within their historical context. Doing so can allow you to let go of the parts that don’t necessarily fit within your own context and perhaps extract what is still meaningful for you.

Coming back to Waterfall, I extracted a few things that I think are still relevant to me today. Software development requires discipline in order to be effective and (however tempting it may be to do so) we should be careful not to skip steps in order to speed ahead. That being said, which steps are meaningful to you… well… that all depends on your context.

Compassion

~ Caroline Sauve ~ Leave a comment

Lately, I’ve been thinking a good deal about how Agile teams are able to deliver value.  I believe that a common trait shared by teams who skillfully deliver value is a shared vision centered around compassion for their users.

Teams who consistently can design, implement and test to deliver frequent and highly valuable products to their customers are connected to their users. Not just in the sense that they are able to interact and communicate with them, but in the sense that they clearly understand the user’s problems.

Understanding their problems means that everyone on the team…

…can clearly articulate the problem their work is attempting to solve. The whole team understands the rationale behind the solution they are implementing.
…understands the value of solving this problem. They understand why they are solving one problem over another.
…can identify with this problem and is empowered to do something about it. The team has a “two brains are better than one” approach to problem solving in general.

These compassionate teams understand that everyone on the team is working hard to solve these important problems for their users. It is this shared compassion that gives their work a sense of purpose and urgency. It is the fuel that keeps them focused every day.

True Leaders of Change

~ Caroline Sauve ~ Leave a comment

“Who’s the more foolish, the fool or the fool who follows him?” – Obi-Wan

One of the strengths of any Agile team is how easily the team can collectively embrace change. Conversely, this can be also our biggest challenge to remaining Agile.

In order to truly collectively embrace change, the whole team needs to opt-in.  This can be a rather daunting task for Agile leaders out there to facilitate. But there is something delightfully simple that I would like for us to consider.  For this, I’d like to invite you to watch this brief talk from Derek Sivers.

Agile coaches out there will no doubt identify with being the “lone nut”. I certainly do. But until I had seen Derek’s talk, I don’t think that I had truly appreciated the importance of that “first follower”. These early adopters are the people who..

…acknowledge when you are making sense. They are engaged listeners.

…raise concerns when you aren’t making sense. They are competent thinkers and have the respect and courage to speak up when they feel it will add value.

…try your ideas and add to them. They are true collaborators.

As Derek points out in the video, these first followers make room for change and transformation in others. They make change possible for the rest of the team. Sadly, as Agile leaders it’s all too easy for us to focus on those who won’t join in the movement… in fact, we can spend a lot of energy trying to support and help those who may never “get up and dance”. So much so, that we risk taking for granted those first followers who do have the courage to meaningfully lead change on the team.

After all, it’s worthwhile remembering, Obi-Wan wasn’t the real hero of the story.

Standup Is About Commitment, Not About “Giving Status” – The Story Continues…

~ Caroline Sauve ~ 3 Comments

In honour of Coaching Agile Teams (@CoachAgileTeams) generous cross post of my tiny blog, I thought that it would be worth putting together a follow-up to the original post Standup Is About Commitment, Not About “Giving Status”.

As you can well imagine, the story for my team didn’t end with reformulating the Standup as a commitment based meeting.  Here’s a sampling of some of some changes we’ve made to this meeting that have helped to keep us accountable…

1. We renamed “Standup” to “Team Commitment Checkpoint”.  Which sounds trivial, but it helped us to reconnect with the idea of commitment on a daily basis.

2. We mixed up the order of “who speaks next” and even allowed for “anyone to speak first”.  Previously, we would stand in a circle and take turns. Starting with the person next to the “highest ranking leader” and ending with this “highest ranking leader”. We used different techniques for this… from tossing a ball around to clapping and pointing to calling out the next person’s name. At first the team felt a bit self conscious and silly doing this but something interesting emerged from this simple self-organizing technique. It helped to create a shift in focus. One day, people stopped “talking to the leader” and started “talking to each other”.

3. We challenged our engaged listening skills with an exercise. First we would go through each person’s commitment(s) for the day, then we would go through the whole process again; in the same order, only this time we would verbalize the commitment of the person who spoke before us. Initially this created some stress on the team but, as we worked through the exercise together, we learned to relax and work together to remember what everyone committed to for the day.

4. We are currently in the process of connecting with what makes a “good commitment” and are aiming to develop a few protocol checks to ensure that we are all making “good commitments” on a daily basis. Maybe there’s a future blog post in that… stay tuned.

One more thing…  every day during Team Commitment Checkpoint (or TCC as we have come to call it), I make a point of sharing an “Agile Moment” with the team.  Often these are small quotes or “aha-moments” that I have had as I connect with the Agile community around the world on a daily basis.

Initially I was pleasantly surprised to note that the team seemed to appreciate these small gifts from the world of Agile… getting a few nods and the odd: “Nice”.  As time went on, I even got a few questions and the occasional: “I’d like to talk about that some more after this meeting”. Then, one day, I received the biggest gift of all from a team mate: “You know, I’m trying to put the Agile Moment you gave yesterday into practice…”

And so in turn, to the Agile community out there around the world and to my wonderful fellow team mates…   thank you for being such a source of inspiration and for helping to put these Agile moments into practice 🙂

A Retro on Retros

~ Caroline Sauve ~ 1 Comment

It seems clear to me that a lot of us out there don’t like retrospectives.  Ok… maybe you are an Agilist and you actually love them (me too)… but I feel pretty safe in saying that this feeling is not shared by all the members of your team.

I’ve been giving this a lot of thought lately and it seems to me that this “not liking” aspect can be broken down into two categories.

Retrospectives make me uncomfortable.  Examples of this would include: “I have trouble speaking up in a group setting.”; “I  have difficulty seeing different points of view especially when they are at odds with my own.”; “I don’t want to create conflict or hurt someone’s feelings.”

Retrospectives are unproductive.  Examples of this would include: “I prefer to focus on my core work than retrospect. That’s where I feel most productive.”; “What we talk about at the retro is less important than what I’m working on right now.”; “We talk and talk, but we don’t actually do anything.”

I would say that most participants in a retrospective will identify to some degree with the “uncomfortable” and / or “unproductive” views of a retrospective.  Rather than viewing this as a problem to solve, I would suggest that these “dislikes” are an opportunity for the team to explore with curiosity.  So consider…

Making retrospectives comfortable. Consider on a personal and team level: “What needs to happen so that everyone can engage with the activity?  What are different ways that we can share ideas, sample different points of view, and be at ease with different attitudes on the team?”

Making retrospectives productive. Consider on a personal and team level: “What needs to happen to make these gatherings productive? Are we talking about the most important problem impacting the team’s ability to deliver value?  If not, then what will it take for us to do that? How do we hold ourselves accountable to our decisions and actions coming out of the retrospective?”

If the retrospective is generating some dislike on your team, then perhaps the time has come to have a Retro on Retros?

Problem Constellation

~ Caroline Sauve ~ Leave a comment

Anyone who has tried to facilitate meaningful team discussion around a problem will know that it’s not easy. A common “team discussion problem” is to have one or two well intentioned individuals monopolize the conversation… leaving you to wonder, what are the others thinking? What are we not hearing or not talking about that we should? I’d like to suggest a quick and effective technique to help align the team when it seems like the discussion might be in trouble.

It’s a hack of the “Constellation” exercise… but it is focused on understanding problems, so let’s call it “Problem Constellation”.

Facilitator stands at one end of the room. Line up the team at the other end of the room facing the facilitator.

Facilitator will make statements one at a time and, for each statement, participants must take a step forward if they agree with the statement. If they cannot agree with a statement, they should not step forward. If at any point a participant cannot agree, he must stay put for the remainder of the activity (even if he agrees with subsequent statements).

During this exercise, no one should speak but the facilitator. The intention is to stop group discussion and take a moment for everyone to reconcile and become aware of his own state of mind on the problem. The facilitator then makes sure that everyone is clear on the instructions before starting with the first statement for consideration.

Here sample statements (order is important)…
1. I know that ____ is a problem.
2. I believe there is value in solving this problem.
3. I believe that ____ is the root cause of the problem.
4. I believe that ____ is the most effective solution for this problem.

At this point, it’s a good idea for everyone to take note where they are and where the rest of team is positioned. The participants closest to the facilitator are those who are in agreement with the potential solution to the problem. Those furthest away from the facilitator are the people who need to speak. Then the facilitator walks to the back of the room and begins reading the statements again, only this time, the team will hear from the people furthest away from the perceived solution.

I have found this activity to be very effective at surfacing assumptions and validating our understanding of a problem as a team. It has “quieted” the “solution influencers” for a moment and allowed relevant information to come forward. It has also “quieted” unqualified participants in the discussion… that is to say, if someone cannot attest to “knowing that there is a problem”, then their role might be to support, observe and understand rather than “drive or influence a solution”. Bringing this awareness is something that the facilitator can help to do.

I have used this technique for controversial problems as well as for teams with more introverted participants and found it to be very effective at gaining a collective understanding. The best part of it all is that the whole activity takes only a few minutes to setup and run.

Simplicity

~ Caroline Sauve ~ Leave a comment

I recently re-read Kent Beck’s book “Extreme Programming Explained”.  If you haven’t read Beck’s book, it’s possible that you are missing out on many of the key values and principles that help guide Agile teams through rough times.  It’s one of those books that “reads you” every time you read it… so if you haven’t read it in a while, I highly recommend the experience.

On this read through, the value of “Simplicity” really resonated with me in many ways.

This value is expressed most obviously with the work that I do as a developer on a day to day basis.  It speaks to the careful and mindful use of my craft.  No technology for the sake of technology or design for the sake of design. In everything that I do, I try to ask myself… do I really need it?

Simplicity also expresses itself in more subtle ways than craft. I try to apply the value of simplicity everyday by consciously taking the “path of least resistance” when it comes to asking questions or sharing information on my team. That is to say, I try to communicate in a way that offers the least possibility for miscommunication.

Lastly, the value of simplicity helps guide me when the endless “to-do list” either at work or at home threatens to overwhelm me.  In which case, I ask myself… what’s the most important thing for me to do right now?  I then subordinate everything else to that for a while. Warning: this can (and probably should) lead to dirty dishes sitting in the sink while you pick up your toddler to go to the park.

I’ll be the first to admit that I’m not always able to skillfully apply the value of simplicity to my work and life. But that’s one more thing that I learned by re-reading Beck’s book…. simple doesn’t mean easy.

Agile Teaching 103

~ Caroline Sauve ~ Leave a comment

At this point, you’re almost home. You’ve set the context for learning (Agile Teaching 101), you’ve created memorable lessons (Agile teaching 102), and one more thing remains…

“We learn to do something by doing it. There is no other way.” – John Holt

I’d like to advocate for the value of “homework” or practice as an invaluable teaching tool. It is every bit as important for grown-ups as it is for children because every student (young or old) experiences some level of apprehension or fear when faced with something new.

If you’ve done your job as a teacher, then you have participated in bringing your student to an uncomfortable edge by introducing something new to his reality. If you want your lesson to translate into your student’s every day life… and I sincerely hope you do, because that should be your success criteria… you will have to help him to overcome his fear of trying out his newly discovered skills.

Therefore, in all that you teach, there should be an opportunity for your students to practice what they’ve learned in a supportive and safe environment. This will give them the opportunity to gain the confidence in themselves and their team (yes, group work IS important) that will allow them to use what they’ve learned in the days to come.

Happy Teaching 😀

Agile Teaching 102

~ Caroline Sauve ~ 1 Comment

Now that you’ve created a good foundation for your teaching, you’ll be ready to dig into the some new stuff with your students.  Here’s my second tip for your consideration…

“All learning is done through meaningful association.”

This picks up directly from Teaching 101’s “Teach them where they are at” idea from last week.

If your goal is to have your students retain what you have to teach, then you’ll need to help them create connections between what they already know and what you would like them to learn. Memory is a key component to learning and your new lessons will only “stick”, if you can find a way for your student to capture and own that knowledge.

Start with what is familiar to them and create connections to the new material. In this spirit, it doesn’t hurt to throw in as many different styles of learning while you are at it. For dry material, I’ve been known to sing at my students and dance like a fool in front of them… anything to help create a meaningful and memorable connection to what’s new. If you are truly interested in teaching and haven’t read Gardner’s book Frames of Mind: The Theory of Multiple Intelligences, then you might want to put that book at the top of your reading list soon to explore different types of learning in order to integrate this into your teaching tool set.

Stay tuned next week for the next installment in this series… Agile Teaching 103… 😀

Agile Teaching 101

~ Caroline Sauve ~ 1 Comment

In Agile, we know the importance of continuous improvement and the key role that learning plays in this process. But we rarely speak of the important role that teaching plays in making it all possible.

I started my career as a high school English and Math teacher and, long before that, I worked with university students with learning disabilities. It’s from this experience that I would like to offer up a few tips for Agile teachers out there.

Here’s the first…   “Teach them where they are at.”

It’s not uncommon for novice teachers to try to pass along their agenda without consideration for their students’ context. In our eagerness to impart knowledge, we forget that our students may not be ready to receive what we are trying to teach.

Instead we need to take time to understand the current reality of our students. Consider what hurdles they are going to have to overcome before they can entertain your agenda. Keep in mind, these hurdles can be knowledge based just as much as they can be emotionally based.  Good teachers work to to fill-in those gaps…

So beyond gauging the knowledge level of your students, this implies understanding what motivates the people that you are teaching. Remember also that if your students aren’t self-motivated, then you’ll be expected to create that motivation. Motivation is important, because motivation creates active engagement in your students. Active engagement is the only way that a student can tap into the brain power they will need to learn what it is that you have to teach.

Stay tuned next week, for Agile Teaching 102… 😉