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

Jared Richardson’s talk titled “Build Teams, not Products,” in particular, was one of the best presentations I’ve ever witnessed. It was just one of those talks where all the points seem tautologic...
-Yev Bronshteyn
Do it right from day one or you never will
-Andy Hunt
They have gathered together the ‘best bits’ of various styles and methodologies they have been directly involved with, and combined them into a practical approach with the focus on delivering a pro...
-Mitch Wheat

Topics from AgileRTP (Apr 8)
Last night we had a great meeting at AgileRTP, our local Agile user's group. Jason Tanner of Enthiosys spoke on Agile Transitions. It was more of a facilitated group discussion and went very well.

Some of the topics discussed include:

Barriers to Agile adoption.

- Perceived lack of planning
- Perceived lack of control
- Fear of transparency (from people who like to hide)

How do enable people to try something new? Create an environment of safety.

Most people assumed that "emergent design" was inherent to Agile, but as we discussed it, most people were referring to "just enough" architecture, not "make it up as you go." Just in Time Architecture? (JITA)

Developers who fear a loss of control are really fearing the exposure that Agile brings. There's no where to hide in a two week iteration.

Questions of scalability and emergent design were discussed.

Planning Poker was mentioned too.

As always, it was a great meeting with a lot of audience driven topics. The only handout was a mind map!

Category: Agile

The Case For Continuous Integration: Free Download (Apr 8)
I wrote an article for the first NFJS Magazine and it's been released as a free sample of the magazine's content. You can download the PDF from the subscription page. Scroll down and look for the Download Free Sample link.

NFJS, the Magazine

Enjoy!

Category: Agile

Trying Out a New Training Model (Mar 13)
Many of my students in recent classes have told us they can only get approval for a single event this year. They want to attend (for instance) our Test Automation Training, and a No Fluff Just Stuff event, but can only get one event approved.

We've heard you, and have an answer. We're now including an NFJS pass with our next few public training events. The price is higher to cover the two events, but you'll only have to get management approval one time.

Will this work? Will it let more people get the training they need to be the very best they can be? We hope so. This is not the time to stop "maintaining the car" and waiting for the engine to fall out. If anything, you need to be sure your "car" (or team) is top shape during this tough time, and as efficient as possible.

Let us help you stay at the top of your game. Our Hibernate training has been popular lately, as well as the test automation. (I'm told I don't do a good enough job telling people it's about complete product testing, not just unit or integration testing.)

Here are a few upcoming events. I hope to see you there.

Test Automation in Austin, April 29th.

Test Automation in Cincinnati, May 13th.

Test Automation in Boston, June 24th.

Test Automation in Minneapolis, August 19th.

Test Automation in Chicago, Sept. 16th.

btw, we've also got a software team optimization class coming up!

Software Team Optimization in Reston, June 17th.

Category: Agile

The Blue Angles Model: Attracting and Retaining Top Talent (Mar 9)
A few weeks ago in Atlanta a class attendee told me about an idea she'd been considering. A "Blue Angels" style dev group at large companies. The more she talked about it, the more the idea sounded exciting.

You set up an elite team of developers, but, like the famous Blue Angels, you force people out of it after a time. This prevents developers from stratifying, and also gives everyone at the company a shot at making the team next year.

It's an exciting way for a large company to both foster excellence and spread that expertise back to the rest of the company. This is an idea worth pursuing.

Read more about it on Blue Angels for Corporate America? by Laura Moore. I expect to see more good ideas here in the future.

This article is also on DZone

Follow me on Twitter at jaredrichardson

Category: Agile

NFJS Magazine! (Feb 27)
Today is the launch of the brand new NFJS magazine! It's a great way for you keep new development ideas percolating between the long, lonely months when the NFJS tour isn't in your city. ;)

The inaugural issue includes articles from Venkat Subramaniam (So You Want to Be Agile?), Ken Sipe (Introduction to Functional Languages), Mark Richards (Message Driven POJOs), and me (The Case for Continuous Integration).

I think you'll find a great mix of pragmatism and experience in each edition. Just like an NFJS event, use the magazine to broaden your horizons and learn about topics that don't normally cross your path. Bring great ideas to your company and your "sanity hacking" projects as well!

Subscriptions run $50 a year for 10 issues. Bringing articles from this level of technical talent into your house once a month is money well spent. It's an investment into yourself, and your team.

Category: Agile

Optimize Your Team (Jan 26)
There are a number of techniques, primarily from the Agile space, that are great for getting the best work out of yourself, and your team. They keep you focused on real problems (not anticipated or imagined ones) and focus on high levels of communication across the company.

The best way to keep people on target is to provide them feedback as often as possible. The sooner you can provide feedback, the more likely the behavior is to change. I don't wait until Christmas to correct my daughters when I see them drawing on the wall. I stop them immediately and we 'discuss' the reasons they shouldn't write on the walls. Usually this an effective feedback loop.

But we expect developers to write code that no-one looks at for weeks or months, then learn and grow from the "feedback" they get from testing or QA groups. History tells us that's a pretty inefficient way to improve. People don't remember what they were doing a week ago, much less four months. We've got to provide feedback in a more timely manner.

Use continuous integration and automated tests to exercise the code and provide feedback very quickly. If a developer writes code that breaks functionality, they can find the problem while the code is still fresh in their minds. If you cover the code you write with tests, who else on the team can break your code and not get caught? (More on your code in a future post.)

What about peer code reviews? We work differently if we know someone's going to be looking at our work. It's human nature. So let's ensure that one other person will read your code. Ideally someone who can pick on us about the hacked, junky code we write when we've got deadlines. This also lets us explain our code to another person, so that when/if we leave the team, someone else knows what our intention was. This is amazingly useful.

Tight feedback isn't just for developers though. XP advocates talking to the customer every day. Scrum wants the customer helping to evaluate the backlog frequently. And for good reason. We often build what we think the customer wants. But what if we showed the customer our "To Do" list and let them tell us what they wanted? Think of all the features you added to the last release... how many of them are used? Usability studies show that 90% of features are never touched. If you could eliminate 90% of the next release's features, and still have happy customers, what would that do for your development budget?

Why optimize now? With a global economic downturn it's more important than ever to be sure you're the best team around. If you can turn out better, more targeted product faster than anyone else, who keeps their jobs? Hopefully you will.

The truth is most teams are always behind schedule and over budget. Use these tight times as an excuse to try out some optimization techniques. Tighten the feedback loop for the developers and the customers.

We'll be discussing these ideas, and a few more, at a local meeting tomorrow night. NFJS One, my employer, is providing pizza and drinks, and I'll be discussing "Software Team Tuneups: Using Agile to Optimize Your Team. The meeting link is on Meetup.com. Come out and join us at Frankie's Fun Park of Raleigh. We'll be in the conference rooms in the back of the restaurant.

And if you like the Agile ideas, bring your manager along. Let's get them on board too!

See you there.

Category: Agile

Try What You Can't Do (Dec 18)
"Creative people should always try to do things they can't. That's when creativity is needed." -Marcel Wanders

When's the last time you tried something you didn't know how to do, just to stretch your brain a bit?

Marcel is a fashion designer (not a programmer), but his comments were very timely for our field. Think about software design when you read his next words.

"People think design is fluff, but it's a disciplined approach to something difficult. This is hard stuff that makes business better." and later "People who work in creative projects are excited to come to work. That's radical."

The really great projects are the ones we get excited about... recognizing the creative aspects of programming, including design, architecture, and implementation, is often neglected. How can we fix this?

If you're in management, recognize that an excited team works faster. Depressed teams work slowly. They come into work later. Leave earlier. Take longer coffee breaks and lunches. It's not intentional, it's just human nature. We chase what we enjoy.

Allow your teams some freedom to be creative in design, technology choices, even languages these days, and see what they give you back.

Category: Agile

Product Owner as Lifeguard (Oct 23)
I'm preparing for next week's product owner training, I'm thinking more about the lifeguard model of responsibility. I have a similar model for developers, testers, managers.... for most people I think. :)

When someone is drowning, whose job is it to reach out? Should the drowning victim be expected to meet you halfway? That's a crazy thought, isn't it? But when the project is in trouble, how often do we say "That's not my job" or "I'll do this much, but that's their job, not mine!"

At the end of the day, we're all lifeguards. When you see someone drowning, jump in! Imagine a lifeguard sitting on the tower, watching someone thrashing in the water, and saying "That's not my area. I only guard the water up to that fence. You'll need to wait for Joe to come back from his break."

If we want our projects, and our company, to succeed we've got to look around, see what's not working, and go after it. It may be someone else's area, but if it needs doing, then do it. Don't step on toes, but offer help... get the job done. If we all put out every fire we see, everyone wins.

When someone drowns, don't blame the victim... blame the lifeguards. Jump in.

Category: Agile

Developer and Tester Pairing (Oct 15)
Last week in Washington, D.C. I was teaching a test automation class. The class ended up being composed of roughly half developers and half traditional, click-through testers.

An unexpected phenomenon surfaced when we started writing our first tests. The testers were having trouble with Java syntax and the developers were writing very poor tests. Rather than try to work with everyone myself, I used one of my favorite presenter tricks. I had everyone pair up.

It would sound more clever to tell you I planned it this way, but I didn't. And in hindsight, it makes perfect sense. But the give and take, the teamwork that emerged from those exercises was pretty incredible. We had strangers, from different companies, working together like old friends. Everyone in the class said they'd never worked like that before. Testers had worked with testers and developers with developers, but this was a whole new dynamic.

So first, let me encourage you to move beyond your traditional working model and try matching up developers and testers to get your test automation effort rolling. It really amazed me to see how well that worked.

Secondly, let me make an announcement. We'll be offering a discount on future training classes ~if~ you pair your developers and testers. I think the class will be much more effective for you and more fun for the entire group. Future course listings can be found at our website NFJS One. Also, a new and improved website is in the wings! Check back soon.

Category: Agile

Time to Grow? (Oct 14)
When's the last time you made a conscious effort to add a new tool to your development toolbox? Not just the last time you were assigned to use a new tool. When did you last go to the home improvement store and just browse?

I know that you can do amazing things with that abacus and slide rule, but you should really check out this new gadget... it's called a calculator. I think you'll like it. ;)

On this vein, you should really check out Andy Hunt's latest book, Pragmatic Thinking and Learning: Refactor Your Wetware. It's a fascinating look at how we learn, and how we can do it better. If you've heard Andy speak on these topics, you've already got a good idea of what you've got in store. I've borrowed much of his content for my talks (but I always give him credit!) :) What can I say? It's great stuff.

Category: Agile

Previous page Next page


© 2007 Agile Artisans.