I was asked to write about “Points of Confusion in Agile” for SitePoint. Here’s an excerpt:

One of the most confusing things about agile may be the fact that we call the estimated units of complexity and effort that will go into completing a story, points. We also use the term velocity to help estimate the number of story points a team believes it can handle in a given sprint. As soon as you introduce terms like these, engineers and managers alike instinctively start to think of them as a way of measuring the value of what is being done.

In fact, points and velocity have absolutely nothing to do with measuring the business value of the work done by the team. They also have no use as a tool for evaluating how hard the team is working, or how much objective work they are getting done. The true value of points is that they represent an abstract and relative metric for estimating what it will take to get one story done compared to another. Ultimately they are intended to help the engineers on the team get better at predicting what will be involved in addressing new stories. But trying to convince managers and engineers of this can be confusing when they see shiny points and graphs that look like they should be going up and to the right.

Read the rest of my article about Points of Confusion in Agile on SitePoint.

I was asked to write about “Making Agile Retrospectives Productive” for SitePoint. Here’s an excerpt:

One of the greatest advantages of an agile workflow is that it makes time for intentional reflection to encourage constant improvement. The retrospective ritual, traditionally held at the end of a sprint, gives the team a chance to discuss everything that stood out in the previous sprint. This includes looking at what went well and what didn’t, and making course corrections.

But carving out time from a busy production schedule for a retrospective meeting that doesn’t produce features for the product can be a tough sell in a fast-paced and competitive industry. Here are a few possible objections that are worth listening out for, and ways to address them.

Read the rest of my article about Making Agile Retrospectives Productive on SitePoint.

I was asked to write about “4 Warning Signs that Your Team’s Agile Process Stinks” for SitePoint. Here’s an excerpt:

An agile organization needs to embody the philosophy of agile in order to get real value out of the process. Otherwise, agile can become a stand-in for whatever buzzword management technique happens to be popular, and will only serve to obscure any real problems that may exist.

In order to recognize potential agile process issues and address them, it’s helpful to have a set of signals to watch for.

Here are four such signals I’ve noticed–I call them “process smells.”

Read the rest of my article about 4 Warning Signs that Your Team’s Agile Process Stinks on SitePoint.

I was asked to write about “What’s the Point of Agile Points?” for SitePoint. Here’s an excerpt:

Agile points seem arbitrary, and it’s hard to see how they can help a team with its real-world concerns, like meeting deadlines.

Hours and days, on the other hand, are easy to understand, measure and weigh against practical external requirements.

Additionally, one of the key rewards that gets teams interested in implementing an agile workflow is the promise that they can learn to accurately estimate the amount of work the team can do in a certain number of days or weeks. Using points seems like taking a step back from that goal.

Read the rest of my article about What’s the Point of Agile Points? on SitePoint.

I was asked to write about “Why Agile Sprints Are Not Tiny Waterfalls” for SitePoint. Here’s an excerpt:

Traditional waterfall development happens from beginning to end in a sequence that’s easy to understand, and at first glance, agile sprints appear as if they’re simply shorter versions of the same workflow.

There are comparisons, but this kind of reductionism overlooks many of the true advantages of agile development.

Respecting the differences can help your team–and people watching from outside of your team–get a better understanding of agile and how it works.

Read the rest of my article about Why Agile Sprints Are Not Tiny Waterfalls on SitePoint.

I was asked to write about “3 Powerful Estimation Techniques for Agile Teams” for SitePoint. Here’s an excerpt:

Until a team has been working together for a while, attempts to generate accurate point estimates for new stories may feel awkward and loose.

Here are a few estimation techniques for agile teams that can ease the transition through this phase.

These techniques get everyone engaged in productive point estimation from the start, regardless of their level of experience with agile methods.

Read the rest of my article about 3 Powerful Estimation Techniques for Agile Teams on SitePoint.

I was asked to write about “Do You Make These 7 Agile Estimation Mistakes?” for SitePoint. Here’s an excerpt:

Until a team has been working together for a while, attempts to generate accurate point estimates for new stories may feel awkward and loose.

A number of conceptual challenges can come up for teams when estimating stories. Sometimes these can lead to confusion about how agile works, and whether its actually delivering on what it promises.

Being aware of these pitfalls, and having a clear answer to the questions they raise, can help keep the team on-track and keep observers from feeling disconnected.

1. Measuring Productivity by Points

Read the rest of my article about Do You Make These 7 Agile Estimation Mistakes? on SitePoint.

I was asked to write about “Why Managers Make Terrible Scrum Masters” for SitePoint. Here’s an excerpt:

The manager is the one person who should be most familiar with what everybody on the team is doing. A manager may appear to be in the best position to oversee the process and evaluate whether or not scrum is being followed. In fact, many of the responsibilities of a scrum master do fall upon management in a more traditional organization.

But there is a basic conflict of interest between the duties of a manager and a scrum master.

Read the rest of my article about Why Managers Make Terrible Scrum Masters on SitePoint.

I was asked to write about “Is Your Scrum Standup Slowing You Down?” for SitePoint. Here’s an excerpt:

Agile management has become increasingly popular in the tech world, in part because it addresses some of the special challenges associated with software development, such as rapid release cycles and clear open discussion of complex topics with steep learning curves. Among the most popular agile approaches is a technique called Scrum, which outlines a set of rituals, roles, and artefacts to help a team adopt an agile approach, and track its effectiveness.

One of the rituals that keeps Scrum teams working effectively is the daily standup. A daily standup gives everybody in the team the opportunity to share with the rest of the team, and anyone who cares to listen: what they’ve been working on, what they’re planning to do next, and what ‘blockers’ (or outside obstacles) they may have encountered. Handled consistently, a daily standup doesn’t get in the way of productivity, and increases the transparency of the project, so everybody knows what everybody else is doing.

Read the rest of my article about Is Your Scrum Standup Slowing You Down? on the SitePoint blog.

I was asked to write about “Agile Working for Productive Development” for Udemy. Here’s an excerpt:

Engineers and business people alike are enthusiastic about the benefits of creating an agile workplace. Not only is communication improved, and transparency increased, but the ability to produce and iterate on products in a cleaner and more efficient manner can also come out of this work approach.

If you’re considering adopting agile for your work environment for your engineers, it’s important to understand why people would be attracted to this way of working. In many engineering companies, agile is becoming the norm, but it hasn’t been that way forever.

Older approaches such as waterfall development have typically provided engineers up front with complex and detailed product requirement documents, which they then went off and developed in isolation. In an agile environments, product owners and engineers work closely together to refine and develop the features of the product as it is being developed.

Read the rest of my article about Agile Working for Productive Development on the Udemy blog.