Posts Tagged - culture

A Thoughtful Reply

I recently participated in an online course about improving focus. Part of the course required sharing updates on my progress via email. When I started out, I wasn’t sure where my emails were going or if anyone was reading them. Then, to my surprise, I started getting responses, and they were from a real person!

These thoughtful responses were very helpful in keeping on track with the commitment I made to myself. So much so, that I was inspired to make time to help others in the same way.

That’s why today I’m sharing A Thoughtful Reply. Through the familiar medium of email, I’m hoping to share the delight and discipline I experienced by having someone who cared about my success.

A Thoughtful Reply

Read More

Retrospective: Setting Expectations

Setup

For this retrospective you’ll need sharpies, post-it notes and a wall, window or whiteboard on which they can be stuck.

Setting Expectations

At the heart of this retrospective exercise is defining expectations for yourself and your teammates. Start by explaining that on most teams, there are varying expectations. Some people expect different things from different people and from different roles. The exercise as described below is focused on a Scrum team, but the questions could be adapted for any team.

Ask the team to describe their expectations of the Scrum Master

  1. Be clear that these are not personal expectations of the particular team member who is currently in that role, but the expectations you would have of any Scrum Master on your team.
  2. Ask the participants to write down 3 to 5 ideas, each on separate notes, that describe what they expect of the Scrum Master. (Adjust the minimums and maximums for your group)
  3. Have the participants put their stickies on the wall or board in one big group

Repeat this process for the Product Owner role and the Development Team

Group Ideas

Now that some ideas have been generated, move the participants towards gaining insight by grouping them in like categories.

  1. Using Mute Mapping, have the participants group the stickies, while keeping them in their Scrum Master, Product Owner and Development Team boxes.
  2. With the help of the participants, name each grouping.

Generate Insights, Investigate Assumptions and Practice Empathy

Move through each role and explore the ideas generated by the team. Share that you hope to create a working agreement after discussing these ideas. Some questions might include:

  • Ask someone who is in a different role what might make it difficult for the Scrum Master (or Product Owner or Development Team) to live up to the expectations on the board.
  • Ask if anyone might change their behavior based on what they now know other people expect of them
  • Ask the participants if the expectations listed for a role seem too easy, too hard or just right
  • Ask if anyone is surprised by anything or if there is an expectation that they think is unrealistic
  • Ask if anyone feels strongly about a certain expectation

Create a Working Agreement

Now that the team has a more clear picture of expectations and they have thought about the difficulties of other people in other roles, work with the team to generate a working agreement. Some possibilities include:

  • No Excuses – We refuse to accept excuses when things go wrong
  • Be Brave – We will declare our intent when communicating by declaring “I’m going to be brave…”
  • Core Hours – Everyone will be physically present in the team room for at least 6 hours between 9AM and 5PM

Read More

Building a Self-Sustaining Ecosystem through Agile Coaching

I was recently fortunate enough to attend the Culture Conference in both Philadelphia and Boston. Even more so, I was able to enjoy the company, conversation and new relationships as a member of the party bus that traveled between the two conferences.

As we drove over the George Washington Bridge, I was having a conversation with Dan Mezick about the role of Agile Coaching in ethical billing and creating learning organizations. I’m a firm believer in the idea that as Agile Coaches, we should strive to foster an environment of organic learning and prescribe specific solutions only when absolutely necessary.

As Dan and I were talking, it occurred to me that an Agile Coach has a similar role to a planted aquarium hobbyist. One can think of a typical organization as a poorly maintained aquarium. There are frequent algae blooms, some of the fish have died, and the plants have discolored leaves and weak roots.

If handed over to an accomplished aquarium hobbyist, they would start by measuring chemical levels in the water to asses the environment. With continuous checking, day by day and week by week, our hobbyist would slowly adjust and improve the balance in the tank. They might add or remove certain plants, invertebrates or fish. Over time, as a result of their actions, the aquarium would achieve a state of balance and the inhabitants would enjoy a harmonious co-existence.

Similarly, an Agile Coach might enter a dysfunctional organization and begin measuring and improving the organizational environment. Again, like the hobbyist, they would help the organization adjust its culture such that it too could become a thriving, self-sustaining ecosystem where the inhabitants live in balance and harmony.

This isn’t to say that once this state is achieved, the coaches work is finished. Just as the hobbyist needs to maintain the aquarium by adding and removing plants or fish, an organization committed to continuous improvement needs the help of the coach to keep learning and improving.

As Agile Coaches, I hope that we strive to build self-sustaining learning organizations rather than insert ourselves as linchpins in the ecosystem. I strive for the self-awareness to ask of myself “Am I just adding chemicals or am I helping the roots grow deeper and fish prosper?”

Read More

Add Fun to Your Scrum Board

Physical Boards Please

I recently started working with a team who had been introduced to scrum as part of their organization’s adoption of agile. Their only experience with scrum was through the lens of a popular agile project management tool that rhymes with alley, as in “After using this software I want to vomit in an alley”. When they had the chance to use a physical board, they jumped on it. I setup a very simple scrum board on the outside of a cubicle near the team. We used index cards and colored pushpins, the normal stuff. After a few days, the team was loving it. They enjoyed moving tasks around, pushing green pins into completed cards and keeping an eye on which tasks were in-progress.

Accidental WIP

That’s when I noticed something strange. When I setup the board, out of sheer laziness on my part (I kept pricking my finger reaching into the bag of push pins) I only provided them with three yellow pins and three red pins, one for each member of the team. In doing so, I had created this artificial WIP limit. The team treated the yellow and red pins as their “own” as in, “this is my yellow pin”. At first I just though this was a neat little side effect of the circumstances, but then I realized I could capitalize on the situation by adding some personality to the board.

The last time you played Monopoly™, the board game, did anyone make a big deal about choosing their token? I bet they did, that seems to happen every time I play. There’s always the guy who has to be the race car or the top hat or whatever. People are serious about their monopoly pieces.

So back to the scrum board. I wondered to myself, could I somehow affix monopoly pieces to these push pins? With a quick trip to eBay for a bag of random monopoly pieces and some super glue, I had the answer. Yes, it can be done.

I presented the idea to the team and let them know that if they wanted to use a special push pin they could, or if they’d like to use a regular one that was fine too. The initial reaction was all smiles, quickly followed by, “I’m gonna go first before anyone else picks the race car!”

Read More

Agile Principles: Tear Down These Cubes

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

– Agile Principles

Manager, Tear Down These Walls

If you were tasked with designing a system that made spontaneous collaboration difficult, you couldn’t go wrong with the modern cube farm. Members of a “team” dispersed over an area of the office, isolated in their drab tchotchke ridden cubicles. Instant message, e-mail and chat might be great for passive communication, but when it comes to real collaboration, being physically present is essential.

But We’re Distributed!

Co-located teams are better than distributed teams. However, sometimes we cannot be co-located. That does not mean we resort to passive forms of communication and digital tools to convey our progress and ask questions. Skype is better than a phone call which is better than e-mail. Don’t underestimate your brain’s ability to gather important insight from the facial and body language of the person on the other end of that video chat.

More in the Agile Principles Series

Read More

Agile Principles: Self-Organizing Teams are Motivated Teams

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

– Agile Principles

Self-Organizing

Allow the people doing the work to self-organize and discover the best implementation they can given what they know right now. Protect them from organizational politics and outside distractions, enable them to focus on the work at hand.

Self-Directing

While we encourage self-organization, we remember the need for direction. While the team does not self-direct, they need a clear vision and an understanding of success in order to attain the autonomy and purpose required to feel motivated.

More in the Agile Principles Series

Read More

Agile Principles: Collaborate Everyday

Business people and developers must work together daily throughout the project.

– Agile Principles

Email is not Enough

Working together involves more than exchanging e-mails about the software. It’s more than passive instant messenger conversations. It’s not reviewing a digital agile tool in isolation. Working together means collaborating, negotiating and exploring the software that is being built.

Too Busy for Success?

If you’re too busy to interact, fairly frequently, on a daily basis with the rest of the team, you’re too busy to enable product success. High performance teams don’t allow their schedules to be overrun by meetings. They don’t let anything get in the way of daily collaboration, negotiating and exploration.

More in the Agile Principles Series

Read More

Let Conversations Write Your Tests

This shift in thinking is due in part to Liz Keogh’s Step Away from the Tools and Dan North’s Who’s domain is it anyway?. Both of these got me thinking about how I’m using the term BDD (rather loosely) and how much of an investment I’m making in a specific tool (Cucumber).

More Meaningful Planning

Having meaningful planning meetings with their customer/product owner is one thing with which many teams struggle. Too often, we go too fast, don’t uncover enough detail, use the wrong language, don’t understand “done” and leave too many loose ends.

To combat this we draw screens, discuss workflows, ask leading questions and a variety of other techniques. I felt that while I was doing these things, I was still frustrated with the other part of the planning process. I’ve never liked traditional tasking and I’ve never like the idea of having to translate all of the data gathered with the customer into some other form only to express it later in a test in yet another form.

What if I wrote my tests during the planning meeting?

I decided that changing the way I gathered conditions of satisfaction, defined “done” and discussed workflows with my product owner would give me the biggest boost in value delivered, so one day I did just that.

For the following examples, assume that we’re adding a feature to an e-commerce website.

As a user I should be able to manage addresses so that I don’t have to enter my information more than once

As I’m discussing the feature with my product owner, I will discuss with them the possible scenarios, including workflows, required to use the feature. Some scenarios for this feature might include:

  • When I am on my account page
  • When I am creating a new address
  • When I am deleting an address

These scenarios might have scenarios of their own:

  • When I am editing an address
    • When I successfully edit my address
    • When editing my address fails

So far I’ve been able to ask the product owner something like “So when I’m editing my address, and I miss some required fields, what happens? What do I see? Where do I go? What are the required fields?”. I can also draw pictures to explain the workflows and ask more questions “What’s on this page? Where is the error message displayed? Do I see error messages for the fields that are missing?”.

For each scenario, I can capture assertions that come from answers to the questions I’m asking:

  • When I am on my account page
    • I should see a link to “My Addresses”
  • When I click on the “My Addresses” link from my account page
    • I should be on my addresses page
    • I should see “My Addresses” in the page heading
  • When I am on my addresses page
    • When I have existing addresses
      • I should see each address listed in format xyz
      • I should see an “edit” link for each address listed
    • When I don’t have existing addresses
      • I should see help text explaining how to add an address

If you’re an RSpec user, you might be thinking, “Hey this looks like RSpec!” and it does. During the planning meeting I can capture these scenarios and outcomes and then use them nearly verbatim for my RSpec acceptance tests. Even better, when I run my tests, I can use the “documentation” format that RSpec gives you to output that’s almost identical to the scenarios above.

The conversation required to really define these scenarios and outcomes is challenging, but at the same time, very rewarding. I have also found that it’s pretty powerful to be able to sit with the product owner and view two nearly identical documents side-by-side knowing that one is automated test output.

Read More

Why Developers Avoid Testing

While the drive towards a culture of “always be testing” has existed for some time, the recent detour into software craftsmanship has helped to create a new style of getting the word out. What used to be, “Test driven development is a great way to approach solving a problem” has turned into “If you’re not testing you’re a shitty developer.” The testing evangelism going on in the community today is misguided and would convert more people if it addressed the real reason people aren’t testing.

It’s Like Losing Weight

To the ever testing software craftsman, it can be puzzling why people don’t write tests. The assumption much of the time is that developers are lazy, that they don’t care about the quality of their code or even that they think testing is an abject waste of time. In my experience this is almost never true.

People skip testing because, ultimately, it’s hard work. Think about what it takes to lose weight or to quit smoking:

  • Break familiar habits
  • Disrupt your personal relationships
  • Acknowledge that you’re deficient
  • Find help
  • Fail often before you succeed

As a developer working in an organization that does not maintain a culture of “always be testing”, it’s going to be difficult to:

  • Change the way you think about solving problems
  • Upset peers who are comfortable in the status quo
  • Admit that you don’t how how, what, when and why to test
  • Find a mentor willing to help you improve
  • Not give up every time you get stuck

End the FUD!

Think about what it means to start testing when you never have before. Not only do you have to come to terms with not knowing what you’re doing, you eventually realize that you’ve been “doing it wrong” until now. This is fearful self-doubt territory for a lot of people.

If you’re serious about getting more of your industry peers to start testing, stop:

  • Going on about craftsmanship; people don’t strive for mediocrity.
  • Playing the doomsday “If you don’t test…” game.
  • Talking about how testing makes you so much faster; their personal experience points to the contrary.
  • Overlooking their perception of testing.
  • Forgetting when you were in their shoes.

Instead, ask questions, get to the root of the problem, don’t settle for “testing makes me slow” or “that’s not my job”, dig deeper.

I believe that as an industry we should strive for increasing code quality, robust test suites and better problem solving. As the minority who are practicing TDD/BDD/test-first/TATFT etc., we need to change our tune. Let’s stop preaching the benefits and start addressing the fear, uncertainty and doubt that keeps smart, capable and dedicated developers from enjoying these benefits.

Read More

Quit Being Comfortable

If you’re heading towards that dip, or feel like you’ve been stuck there for a while, fear not, it’s easy to shake yourself out of it. Put yourself on the line and increase your expectations.

It’s easy to fall into comfortable relationships, comfortable careers, comfortable routines and lead a comfortable lifestyle. However, once you’re in that position you start to wonder where the magic went. You can recall a time when you were excited and things sparked your interest, now, they’re just boring old routines.

Imagine those exciting times. That time you spent dating, forging that good friendship, interviewing for jobs, meeting the new team, notice a pattern? They were all challenging times when you had to push yourself and risk something.

Risk being ignored, risked be disliked, risked being rejected, risked failing. You had to work hard and make things happen. Look where you are now, no risk, no challenge, no real effort.

Do yourself a favor:

  • Join a local industry group
  • Give a public presentation
  • Attend a local lunch gathering
  • Update your resume
  • Start a new project
  • Learn a new skill
  • Make a new friend

Put yourself on the line, risk something, challenge yourself, flirt with the possibility of failure. The feeling you’ll get from all of this will tear that comfy blanket to shreds.

Read More