When Agile Works

When I started consulting on an "agile" team back in February, my first thought was, "Hey! You guys lied! This isn't agile."

The working practices were reminiscent of James Shore's recent blog post.

There was Scrum but they lacked visibility, risk mitigation and self management.
There was a morning stand up, but it was a status meeting with over 20 people -- mostly watchers.
There was a single product team, but members were broken up into domain groups with their own managers, politics and definitions of success.

There were bad practices, communication breakdowns, over-commitment, over-time, half finished features, inconsistency and plenty of technical debt.

Team members had all the stress and no power to change.

But, there was hope.

Within the first few months the company reorganized and moved towards product hierarchy eliminating the contention between groups.

=>Consistent goals and priorities.

The BAs, design and product owner worked closely with an agile coach to create a product backlog. They began having sprint reviews and retrospectives.

=>Visibility and reflection.

A few people became scrum masters. A few others scrum product owners. They started going to agile conferences and local meetings.

=>Engagement.

I left at the end of July to have Kaylee. Things were changing, but we were still far from a well functioning agile team.

When I returned in November, I heard that our agile coach said this was the best agile team he's been on.

I thought to myself, "I think he's been drinking some kool-aid..."

However, when I came in for sprint review and planning, I was amazed.

So much changed.

Team members were involved.

Practice improvements and innovations were made throughout the day.

Charts and metrics were used, not shown.

People were having the right conversations.

The differences not only showed in the team and interactions, but the product.

They had visible success.

I feel very fortunate to have the unique look into the evolution of this agile team.

When you are on the team, it can seem like things don't change. Our retrospectives are a microscopic view compared to a projects lifespan. If I was working for the past 3 months, I may have not noticed.

Maybe a periodic review of how things were/how things are would be a good motivator and illustration of how cool agile can be when its working.

More about → When Agile Works

I feel like I'm taking crazy pills..

Today, I was trying out a wpf grid control and couldn't figure out how to style or data bind or do anything with it in xaml.

I sent the sales rep an email asking for some examples and I was told data binding, templates and styles were not currently supported (dependency properties it seemed too).

With that, I thanked them for their time, and said databinding and styling were a priority so we could not consider their grid.

I didn't expect to hear much after that, but I was informed that those "bells and whistles" were not as important as the other features only their grid supports...

While I would argue these "extras" are a foundation of WPF, I don't think that should matter.

Why are my priorities not valuable?

When listening to user feedback on our applications and products, we can get defensive.

We're all human and insecure, so I guess that could explain it.

However, I would rather focus on a different issue -- what is guiding our decisions, priorities and emotional responses?

Why is the response to user feedback a reason instead of thank you?

All feedback is an opportunity to create a better product. It is great service your users provide (usually for free!).

One of the greatest technical challenges in Ript was adding the ability to rip Flash. It took many, many spikes. I think most other companies would have put it aside -- it didn't add much value, wasn't going to make us money, isn't something that will make a person use the application and certainly cost time and money.

So, why did Gerry make it a requirement?

During user testing, we noticed people thought they were doing something wrong when they couldn't rip flash. They don't understand that some images are flash and some are images.

Gerry could have said document how to determine if an image is Flash so users will know why they can't do something.

But, she understood that it didn't matter if the behavior was documented. If a person thinks its broken, begins to lose trust or feels they are doing something wrong, they are alienated. They will not feel confidence in themselves or the usefulness of the program.

Before working with Gerry I didn't understand this concept. I would have put flash aside. However, her decision is what made her a great product owner.

More about → I feel like I'm taking crazy pills..

Painless CI?

I recently started a new project and had the fun task of getting the build server up and running. Usually, I dislike the entire process -- creating a nant script, configuring cruisecontrol... so much xml... so little fun!

Since its a new project, first order of business -- rake for builds! Something we experimented with at Oxygen, but didn't add to our practice. If you have the options of putting ruby on your build server, switch to rake if you are not already using it. Its easy to read, easy to build projects and you can reuse code. Such a nice change from the copy and paste nightmare of nant.

After spending 1/2 a day working on cruisecontrol.net and trying to figure out what configuration I needed, I realized -- hey, you can use cruisecontrol.rb -- ruby is already on the build server and we're using rake.

I'd post directions on the extra steps or setup I needed to do, but the directions from the cruisecontrol.rb site left me with a working build -- imagine that?

More about → Painless CI?

Gerry Laybourne on agile

From an interview with Gerry (page 6, scroll about halfway down the page):

"...And through that, I really got to know them and decided that I really wanted to understand agile management—which is a very interesting way of managing. It's a very formal discipline that allows the team to own the work. And what happens in software development is that you can give an assignment to a software-development team, and then six months later, they deliver what the assignment was. And you look at it and say, "Oh no, that's not what I wanted." In agile management, you work on a two-week cycle. You're working. You have a "scrum master." You have priorities set. You agree on what the priorities are in the meeting. You review the priorities. You evaluate where you are, and you move to the next step..."

I love that she knows agile is a "very formal discipline."

More about → Gerry Laybourne on agile

Whatever happened to sustainable pace?

Who practices sustainable pace?

Development is an art. Its a mental challenge (emotion if you pair). As a day goes by, an individuals definition of quality changes depending on their mood and energy.

Over short periods of time a team can keep up long hours; especially if there is positive momentum or results in sight.

But permanent hours to get more out the door? Does this really work with out sacrificing quality and practices?

How many times are corners cut to meet a deadline? Was it ever too much to write that test first? Was code copied without refactoring to remove duplication? Is there spike code in production cause it worked?

Is that our risk to take?

Can a person control burnout or realize the compromises they make? People have an amazing ability to adapt to any situation. In a bad situation, we forget, we lie (mostly to ourselves), we ignore and we accept things we shouldn't.

More about → Whatever happened to sustainable pace?

Morning Scrum -- Remote Style

This is what life at Oxygen looks like in the morning (from the comfort of my home):

More about → Morning Scrum -- Remote Style

the joy of pair programming

I started speaking about pair programming because I didn't like it and I needed to understand this practice better.

Sometimes I still don't.

But, I admit this:
Pairing is a great practice.

Great, but surprisingly difficult.

The ideal pairing situation requires both people to be expert developers. They need to be open to the other person's idea. And in this case (expert developers with good, strong opinions), its likely to bring pain.

If the pair is not parallel in skill (which is often the case), the stronger person must slow down and take on a mentoring role. Being a mentor when you want to be as productive as possible is frustrating. Many developers are poor teachers, but communication and discussing ideas is key to creating a great solution.

Every person you work with is different and you create a unique pair. You will go at different speeds, create different designs, even make different jokes.

Pairing is a good mechanism for teaching, but the real strength is in design and code. I have seen no other practice keep every team member familiar with every project, design and decision.

The whiteboard is rarely used because the pairing session isn't about code, its about creating. The design decisions are made when the pair needs to make them. Any previous design or decision may not be the best solution when (and if) its needed.

If discussion can be avoided, don't do it. The best way to be productive is to keep coding and evolving. Focus on small steps to deliver functionality quickly and ensures CI success.

With pairing every moment is a code review. If the team switches pairs and owns the code, everyone is familiar with everything. No reviews, no whiteboards, no documentation.

Imagine the possibilities.

More about → the joy of pair programming

It’s more than a catchy term

Every person is different. They have different experiences, backgrounds and interests.

As we work on a team, we learn to compromise and appreciate other people’s opinions. We change and evolve our practices and create ideas together.

On an agile team this keeps improving. On a dysfunctional team, it plateaus or degrades.

We change based on our experiences and dedication to continually improve. This drives our best practices, interaction with stakeholders, technologies and tools.

We improve by changing. We rely on team retrospectives and personal introspection to guide us.

We buy into our efforts. We enjoy progress. We admit failure and move on.

In our world, stakeholders change their minds (or just don’t know), technologies emerge and practices evolve.

Change is an absolute. Adapting to it is agile.

It is not an easy path, just a possibility for success.

More about → It’s more than a catchy term