Ship It! LIVEShip It! LIVE
home about services writing contact

We develop, test, and create fine software products, and design creative solutions to your problems.
The development of software is an intrinsically creative process. We are dedicated to improving our mastery of the art.
Links · RSS Feed
Popular Pages

More practical advice from the pragmatic crew. This is another excellent book from the guys at Pragmatic. In this book Jared and William cover pragmatic project management with down to earth advic...
-Jack D. Herrington
It's rare to have this much fun reading a book about software. The ideas are smart, relevant, and fundamental. I can be a better programmer today because of the things I read today.
-Joe Fair
I was amazed that these five chapters only take about 160 pages and yet tell you all you need to know about successful projects. I’ve experienced a lot of these problems myself, and so did/do you, ...

GROWS Method Workshops (Jul 15)
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!

Category: Agile

Weaponized Agile (Dec 4)
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 extract more work out of their teams. That's not why agile was created and it's not particularly good at it either.

Agile becomes weaponized in several different ways, but two of the more common ways are one-sided implementations or frozen practices.

One-sided agile is easy to spot. Those companies use agility to provide more transparency and visibility on the activities of the development team and then continue poor practices (especially micro management) that negate any benefit of agility within the organization. Management (and project management) groups use agile as a tool, but don't adopt the practices themselves. Agile practices provides a great deal of visibility into the day to day lives of the development and testing teams, but that visibility needs to be a two-way street. The visibility can't be only into the technical team's work, but must also be into the executive vision and motivations. When "agility" means the teams adopting agile practices but management continues to work as before, issuing edicts from behind the curtain, then agile practices are being abused. This is a dysfunctional relationship. These agile adoptions flare up briefly and appear to be going well before flaming out. One-sided agile adoptions don't stand the test of time. Frozen practices are also easy to spot. When iteration velocity is used at a tool for rewarding and punishing teams, instead of measuring working software, then you know your company is on the wrong path. When managers assign work to a teams instead of the team committing to their own work for the iteration, you're operating under a command and control mindset. The product developers (aka product owners) fail to attend demos or provide feedback, but later complain about the finished product and blame the teams. When the teams are forced to "sprint" over and over, and are being pushed for more and more work each time, it's an efficiency tool, not an iterative development model.

You're facing frozen agile clubs anytime an agile practice is used to justify punishing or blaming a team instead of empowering them, instead of tightening up feedback loops and directing the product focus. It's often an excuse to avoid putting in the hard work needed to ensure the team is moving in the right direction. It's easier to not fully engage, then blame development. Again.

Remember the original points of the Agile Manifesto... individuals and interactions over processes and tools. Especially those processes and tools that eliminate human interactions in favor of dictated orders. Use your agile adoption to encourage those interactions. Yes, they are "inefficient" from a time perspective, but those inefficiencies are more than recovered by eliminating many of the common misunderstandings that occur when we replace face-to-face communication with written documents. No matter how many pages you add to a requirements document, you can't the reach the level of understanding that comes from an interactive discussion. The document is faster, but the conversation is more effective.

The intention of the GROWS Method Practices is to ensure that practices won't be frozen. Practices begin with steps and advance to freedom. Try using the practice cards to help start those conversations.

If you think your company is in the midst of a weaponized one-sided agile adoption, I'd encourage you read over the Executive practices. Walk through the Vision and Progress Management sections with your manager. In my experience, many managers are doing their best to manage the work, and they're falling back to what they learned in years past. Give them a cleaner way to manage teams that involves a company-wide agile adoption and a true change of the culture and mindset all the way to the top... and you might find yourself understanding why some people enjoy agility so much.

Category: Agile

Availability in 2016 (Dec 2)
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.

Category: Misc

All We Need To Do Is... (May 12)

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 individuals in development, testing, and various flavors of management. Sadly, we have a much larger number of people who haven't reached that level, and don't know how to get there. Some just don't care, but others are struggling to get improvement, and when they get advice like "keep improving", they don't know how. As the old saying goes, they don't know what they don't know.

I frequently get emails asking which books they should read, which conferences they should attend. People want to improve, but they're often drowning in information and have no idea which information is good, bad, or ugly. For years we've been telling people to try harder, to read this book or that, attend this conference or that, and it's helped a lot of people. But many more have given up and turned into 9 to 5 wage slaves. They've retired in place and have given up seeing code as anything more than a way to pay the bills. We, as the enlightened priesthood, mock these people and talk about them at our conferences, with our enlightened friends. We're satisfied knowing that we're better, smarter and destined for greater things.

But what if these co-workers and friends want to be better but don't know how? What if offering them principles and ideas frustrates them and they want… no, NEED concrete steps. They're begging for explicit guidance, but instead we offer them values that are so nebulous as to be useless to them.

If this sounds like a scathing indictment, then good. It is. It's an indictment not of any individual, but of the industry. Most of us have fallen into the expert's trap. We've worked within a small bubble of smart, experienced people for so long that we've forgotten how to teach beginners. Let's face it... the person who knows who Martin Fowler or Andy Hunt is, and wants to bring them into their shop, is probably already very far along.

I've been lucky in my career. Many of my clients were in bad shape by the time I became involved. I've heard horror stories, time and again, about requirements, morale, quality, and so many other problems. I've worked with many talented people who didn't know anything about effective agile processes. They'd taken a Scrum class or two, read a book or two, but when things didn't work quite right, they didn't know what to do.

When Andy Hunt presented at several local user groups, during the time he'd started researching material for his Refactoring Your Wetware book, I first heard about the Dreyfus Model of Skills Acquisition. It was an eye opening view of how experts often lose touch with how people learn, and how beginners become frustrated with how experts teach.

Read my previous blog entry on the Dreyfus model for a description of it's stages.

A Solution

So what's the solution? Those of you at the Proficient or Expert stages must work very hard to relearn how to teach in steps. Precious few will ever rise above the Competent stage until we learn to teach in both steps and values. Start with steps. Show them how to work effectively, but then transition into values.

This isn't a new idea, but, as an industry, we've traditionally shunned it. Experts and Proficients are hobbled by the rules that enable workers at the lower stages. Managers, who don't really understand what we're doing, especially when we're moving in the intuition realm, are desperately trying to manage projects. They, being beginners, love steps. So if we, as experts, provide steps, we're terrified those steps will be written down, canonized, and used against us… because they have been again and again.

GROWS is an effective way to manage this problem. It provides steps for lower stage teams, but explicitly discards those steps as your teams move up the Dreyfus Model. It clearly explains to managers what the Dreyfus Model is and why their teams will require fewer steps as they become increasingly effective.

Some companies will not want their teams to operate at the highest stages. They'll want to get to Competent and stay there, and that's okay. It's not a shop most of us would want to work in, but if they're using GROWS, you can understand their operating model during your interview process instead of after you take the job.

GROWS is much more than a process-oriented application of our interpretation of the Dreyfus Model, but it does harness the model in an effective way. We must, as an industry, find a sane path to provide steps to beginners while not hobbling our experts. We can make it possible to have meaningful conversations about skill stages (especially with management) and relearn how to effectively teach others. There may be other ways to do this, but so far, I've found that GROWS, and it's use of the Dreyfus Model, extremely effective.

Category: Agile

The Dreyfus Model (May 12)

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 they do. Unfortunately, this stage is still famous for frustration. When things don't work, we still don't have the skills to debug those problems. We need things to work the way we expect them too, but we're building an experiential skillset of what works.

The Competent

This stage is what I call the recipe stage. We can finally get things working and become cut and paste gurus. We've got tons of working solutions at our fingertips. I used to carry around a CD with collections of projects and code snippets. These recipes helped me look very smart and enabled me to quickly "solve" problems and churn out working projects. We've developed enough experience to understand what's likely to go wrong and the debugging skills to solve problems. Most developers hit this stage, achieve a solid level of competence and effectiveness, and they stop learning. They're too busy working overtime and solving problems to continue learning. And why bother? I'm getting stuff done, right? This is the trap… good has become the enemy of better and best. This local optimization prevents so many in our industry from moving to the next stage.

The Proficient

Things finally become smooth. We discover patterns, principles, and values. We start to understand that we don't have a daily meeting because we're "doing Agile", but because the team needs to interact and share information with each other. And sometimes there are more effective ways to do that. We realize that test first isn't about creating a test suite, but about helping us think about the problem we're really solving. We start to use techniques like the "5 Whys" and advice like "keep improving how we deliver value at sustainable pace" finally makes sense. Sadly, as we enter this amazing new world, we often start spending time with others who've already arrived here. We begin using terms like "code smells" that our Competent Stage friends don't understand, and we slowly drift into the bubble of Very Smart People. As we're surrounded by these Very Smart People, we begin to assume everyone is also Very Smart, and we begin to forget how to provide steps to beginners, widening the gap between the stages. As we all know, smart people attract smart people, and incompetent do the same. Birds of a feather do flock after all. So the shops that have the higher-stage teams don't usually hire the lower stage applicants, and vice versa.

The Expert

The expert stage is known for intuition. In the development world, we call these people all sorts of colorful names. Wizards. Code ninjas. Rock stars. These are people who sit down, look over your architecture and tell you it won't scale. They might not effectively verbalize why it won't scale because they don't always think in steps anymore. In fact, it's often easier for them to redo your work themselves than it would be to explain the flaws in the architecture. Naturally, these 10x productivity team members are idolized, leading the ego we often seen in these people. You have a problem? Here's a value. Here's a principle. Here's an idea. You don't understand it? You must be dumb. I know I'm not. (Sound familiar?)

Category: Agile

Next page
StarEast 1/2 day ATDD class (2017-05-08)
I'm giving the 1/2 day Acceptance Test Driven Development class

© 2007 Agile Artisans.