(Jul 9)
I've done a lot of interesting work at NFJS One over the last year, but I underestimated how much travel would be involved, and now it's time to find something that can keep me closer to home. So while I'll still be doing engagements with NFJS One, I'm also looking around to see which direction to move next. Talking about it on the blog seems like a good way to start conversations with more people than I could reasonably email.
One very appealing idea is to bring many of the courses I teach across the United States to the local RTP market. I've found that the price point for training in DC, Atlanta, and Chicago is a bit higher than it is here in North Carolina. NFJS One wanted to offer consistent pricing for the NFJS One courseware in all markets, so the local market struggled a bit. I've been teaching courses on test automation training, integration testing, selenium, introduction to Java, introduction to Ruby, transitioning to Agile, and team wide tune-ups. I've also done coaching and mentoring for teams. One of the more popular engagements is me teaching your team about effective test automation, while at the same time cleaning up your existing test suites alongside them.
If you're in the Research Triangle Park area (that is to say, local to me!), please drop me a line (jared@agileartisans.com) and we can discuss details. If you don't have the budget to send your entire team, I've also hosted public training events on request. Then you only need to pay for the two to three attendees you need trained, and let other companies attend too.
I’m considering some remote training, using more of a webinar style presentation as well. I’ve already had some companies express interest in that format, but please let me know if you’re interested too.
I'm also talking to a few local companies about full-time employment. I'm not religious about being independent or a full time employee. I'm passionate about working where I can make a difference. The companies I'm talking with are interested in moving various internal efforts forward, and I find that very appealing.
One of the best ways to explore options is to discuss them publicly, so that’s the reason for this blog entry. Here's hoping some interesting conversations come my way!
Category: Personal
(Jul 7)
The Ruby RX and Agile RX collocated shows are coming to Philadelphia and Washington DC (technically, to Reston), and the first round of early bird discounts are this week.
There's a stellar speaker and session lineup on both the Agile and Ruby sides of the house. We've got Chad Fowler, David Bock, Neal Ford, Johanna Rothman, David Hussman, Esther Derby, Russ Olsen, and more!
The early bird discount ends on July 13th. Register by then and save $100 per person. Bring more than 5 coworkers and save even more!
Find out more about the Philly show here and you can read up on the DC/Reston show on this page.
I look forward to seeing you there!
Category: Ruby
(Jun 2)
This is a message I sent to the members of AgileRTP, our local Agile user's group. But I wanted to share it with a wider audience, so I'm reposting it here.
-Jared
This is a quick reminder about the meeting tonight. Dr. Laurie Williams is teaching us about planning poker, and how to use it to effectively to manage security risks. It should be a very informative and educational meeting.
http://agile.meetup.com/29/calendar/9984479/
If you're not familiar with planning poker, you can learn more about it at http://planningpoker.com/.
Also, members Ben Carey and Rick DeNatale noticed the relative size of AgileRTP. We're the 5th biggest Agile meetup (on Meetup.com) in the world!! http://agile.meetup.com/ And we're #3 in the USA!! As of the new members who joined this morning (welcome Justin and Harold!), we're at 374 members. I wonder when we'll hit 500? :)
The growth of our group has been organic... completely word of mouth... so we thank you for helping us to grow (and continue to grow!) Agile RTP!
Also, let's thank Allscripts for continuing to host our meetings. It makes my 'job' much easier.
So please invite a friend... tell a co-worker... forward this email to your team's development list... twitter and blog! Help us the message of sustainable, repeatable, solid software development!
Jared
http://NFJSOne.com
http://AgileArtisans.com
Category: Agile
(May 8)
The Made to Stick authors (Dan and Chip Heath) have been discussing whisker goals (as opposed to stretch goals) as a way to get a person (or team) moving forward. And it makes a lot of sense.
How often have you decided to "lose weight" and set such a high goal that you never got started? Or asked your team to start using Cobertura for code coverage, and asked for 90%... only today you have 1%?
Setting large goals feels like a smart idea. It's something the team can aspire to. It's a Big Goal that can help motivate us. The idea makes perfect sense on paper,but the reality is different. Most people, when faced with a big goal, give up. They won't even try.
Life is tough. We get "stretch goals" everyday, in every part of our lives. Your To Do list around the house is probably filled with them. Time with your family. Features at work for the next release. Cleaning up old code. Adding automated tests.
So when one more set of stretch goals comes across our desks, we tend to ignore it. Of course, this is not the desired effect.
Instead of putting stretch goals in front of your team (or yourself!), find a very small goal. Just a whisker more than they're doing today. Something so easy to do that they'll just take a moment and do it.
You might find that a team with small, achievable goals gets a lot more done, once they get rolling with a small start. If I might co-opt a famous sentence or two...
An object at rest tends to stay at rest. An object in motion tends to stay in motion
Link: Made to Stick: Set Smaller Goals, Getting Bigger Results
Category: Agile
(Apr 22)
I was recently involved in a discussion about the role of QA, faux-agile, and development. How should they work together? What's the proper role of each?
This was my reply... it felt like a blog entry, so I turned it into one. :)
QA should be heavily investing in automated tests (both unit, package level, and integration) tests that are being moving into your continuous integration (CI) system. At least 1/2 to 3/4s of the QA team should be able to write tests in the framework of choice. (This is assumes you started with an interactive test team.)
Developers should also be adding automated tests... running all these tests in continuous integration puts a huge dent in the amount of QA time that needs to be done.
You never freeze your code during an iteration. I've heavily edited code (and had team members heavily edit code) the day it went to customers. Having a solid automated test suite, running cross platform, enables practices like "ruthless refactoring" and provides developers and QA staff a powerful level of confidence that the product still works after any level of editing.
I have taken the results of an iteration and called it "frozen" so interactive testing can have an iteration (or two) with non-moving target. The described philosophy of freezing during an iteration is a direct result of the long iterations. If your iterations are measured in months, they're not iterations. They're releases.
Sometime consultants try to jam agile into waterfall because it's what they understand. It's just a waste of time. Agile is a different mindset.
What does "done" mean? To me, it's either done enough to pass on to QA or a customer.... OR the tests pass. If I'm writing a package or API that can't be customer demo-ed, the tests can still pass and prove it works. If you're doing something "to big" for an iteration, you can still write unit tests or package level tests to prove it works.
Enjoy!
Category: Agile
|
