Subscribe: Agile Artisans
Added By: Feedage Forager Feedage Grade B rated
Language: English
agile  developers  efficient  experience  grows method  jared  local  method  requirements  steps  team  tool  unfortunately  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Agile Artisans

Agile Artisans

Jared's Blog


Jared Richardson, 1969-2016

Sun, 01 Jan 2017 00:00:00 +0000

Jared Richardson passed away on December 7, 2016.

Jared was a beloved husband, father, brother and son who has touched many lives. In his professional career, Jared was a consultant, developer, tester, and manager, including Director of Development at several companies. He was the author of two books, Ship It! and Career 2.0, and was the 2nd public signatory of the Agile Manifesto. Jared was Screencast Editor for the Pragmatic Bookshelf, and co-founded The GROWS™ Method. He started AgileRTP in 2007 and is well known as a coach and consultant through his company, Agile Artisans.

Jared was called home on December 7th, 2016 to be with our Lord. He was surrounded by his family and passed peacefully. In accordance with his wishes, his organs have been donated so that others may benefit from this tragic loss. As he did so much in life, Jared kept giving of himself even in death.

We're collecting your stories at on how Jared has touched

GROWS Method Workshops

Fri, 15 Jul 2016 00:00:00 +0000

I'm not blogging much these days... that's an indicator of how busy life has been lately. Almost all of it is really good stuff, but I'm still swamped.

I wanted to point you to the GROWS Method Workshops that Andy and I have been running. Drop me a line if you'd like to schedule one for your shop!

Weaponized Agile

Fri, 04 Dec 2015 00:00:00 +0000

It's said that the road to hell is paved with good intentions... and that describes far too many "agile" adoptions. I've seen managers take money out of bonus pools for every broken build (in a continuous integration system). Another client tied raises to points and velocity. A vice president of a large organization explained to me that the teams doing agile should be faster than their counterparts, even though they had all the overhead of both agile and waterfall, with no freedom to reduce or change the work focus.

Agile practices are intended to be flexible... they should be fluid... liquid, if you will. Instead they're sometimes frozen and turned into clubs. Like any tool, they've only been as good, or bad, as the person wielding them.

More than a few developers have come to hate "Agile" because of how they've experienced it. Far too many have seen the word agile used to justify abusive practices at the hands of managers and executives who viewed agile as just another tool to extra

Availability in 2016

Wed, 02 Dec 2015 00:00:00 +0000

A long-term client is wrapping up after an extended engagement so I'll have more time available in January. I decided posting here was an efficient way to sharing the information.

In the past few years I've done more roadmapping engagements. It's a cost effective way of bringing in a coach without committing to the expense of a full-time engagement.

I'm also starting to use checklists from the GROWS Method as a team evaluation tool. I think you'll find it's an efficient way of evaluating your team's current state, as well providing a roadmap for the future.

I'm primarily looking for clients local to myself (in RTP, North Carolina), but I do travel for some clients. When my children grow a bit more, I'll travel more, but for now I prefer local engagements.

Contact me at jared AT and we can start a conversation.

All We Need To Do Is...

Tue, 12 May 2015 00:00:00 +0000

After Andy's article last week, many people (including quite a few I have an enormous amount of respect for, and many others I haven't met) announced that they much preferred to simply keep doing what they've been doing. One of the leaders in our industry said she preferred to "keep improving how we deliver value at sustainable pace". And you know what? She's right.

That's an idea… it's a great value. But it's only that: an intangible; which requires someone with a great deal of experience to correctly interpret and apply that advice. Someone who's been working with software for a while, and has invested the effort required to become skilled, understands exactly what she meant. The technical guru who has 10 years of experience (not 1 year repeated 10 times) can take this advice, and it's useful.

Unfortunately, in my experience, that describes very little of our industry. We do have a talented core of skilled individu

The Dreyfus Model

Tue, 12 May 2015 00:00:00 +0000

The Dreyfus Model has five stages, and understanding them has helped me decipher so many reactions I've seen, both in software and in life.

The Novice

Our first stage, also known as the beginner, is someone just learning a new skill. When you learn a new programming language or a new tool, you need steps. Most successful programming books provide a number of easy to follow steps (remember 10 print "Hello world"?). These steps help familiarize you with the environment and what things you are supposed to do. If you'd like a refresher in how this works, try teaching an introduction on Java or Junit to people with no experience. It's amazing how many things we take for granted. If you skip steps, students get frustrated and quickly let you know, or just shut down.

The Advanced Beginner

We become familiar when we've seen enough explicit examples that we can start putting them together. We accumulate code snippets that work. We're not positive why they work, but th

Do You Organize Your Work for Yourself? Or Your Team?

Mon, 16 Mar 2015 00:00:00 +0000

We tackle our work in the way that seems right to us. We look ahead at the work on our plate and do our best to get it done. I often say that everyone makes great choices... given their own context and point of view. Unfortunately, that point of view sometimes leads us to a local optimization, where things look efficient until we step back and take a look at the bigger picture. Then we realize our local optimization wasn't nearly as efficient as we thought.
This often takes shape in how we break out our team's work. Some times we break everything down into layers (horizontal slicing) while others slice the work into smaller, but working, bits of functionality (vertical slicing).

Horizontal feels more efficient because it lets different product area specialists (like SQL or UI gurus or server-side code jockeys) work quickly and knock out a lot of st

The Trap of Enterprise Requirements

Tue, 27 Jan 2015 00:00:00 +0000

The path of a requirement in a large organization is often foreign to those more familiar with small or medium companies. In smaller arenas, developers and testers help define requirements. Everyone has a clear view of what's being built because they had a hand in defining and refining the ideas. Do you have a question about what this feature should be or what this report should have? Go ask Mike or Sue. It was their idea.

Enterprise scale is different. When the program budget is half a billion dollars and there are a few thousand developers and testers involved, requirements are shifted to a specialized team. Often an entire division is tasked with searching out and documenting requirements. These requirements are compressed and converted into documents that can be shared with teams of developers to implement, and teams of testers to verify. Each team can become specialists and do their own job at peak efficiency. Unfortunately for most enterprises, this model doesn't work well.

Roadmapping and Mentoring

Wed, 21 Jan 2015 00:00:00 +0000

A coaching model that I've found very effective is something I call roadmapping and mentoring. In a traditional coaching engagement, the coach comes alongside the team and works onsite for some period of time. This is a very effective way to work and teach, but also requires a substantial budget commitment. It also needs a dedicated block of time from the coach. Lining up client needs with coach's availability is often challenging, and there are usually problems that are discovered after the engagement is complete and the coach is at a different client site. These problems are often insurmountable for the small or medium software shop.

Roadmapping puts a coach back in reach for most teams. The coach comes onsite for only few days, and that drastically reduces the cost. I meet with both the teams and the leadership. What pain points triggered this invitation? We try to identify what the existing pain is, but we also look for pain that the team has come to accept as normal. What hidden pain po

Minimum Viable Estimate

Thu, 04 Dec 2014 00:00:00 +0000

As teams adopt more responsive software practices, one area is often left behind. We believe that the development team should deliver functionality incrementally. We know about minimum viable products. But, especially in larger companies, we hold onto the requirements until they are "done" or "right". Well-intentioned requirements groups work months getting work lined up for the developers and testers.

First, requirements, when done well, are an ever-evolving view of the product and the customer's needs. Trying to get it right in one go is like trying to ship your product in one pass. It's difficult to make anything perfect, especially requirements. The law of diminishing returns (and Little's law) kick in quickly. In other words, it's just not worth it. You'll spend far more money, and lose development runway time, by trying to perfect requirements.

I'd like to suggest we start thinking in t