Links
·
RSS Feed
Popular Pages
|
|
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, ...
-Javaddicts.net |
|
Ship It! is part manual of best practices, part software methodologies book and part a distillation of ideas and experiences of good and bad projects that the authors have been involved in. It migh...
-Tech Book Report |
|
.. it is a really special feeling when you give someone a book and it changes the way they think and act. So I'm really pleased to have just finished reading a book that I know I'll be handing out ...
-Jeffery Fredrick |
|
|
|
|
(Feb 12)
North Carolina's Research Triangle Park has a number of great local learning opportunities and conferences coming up and I wanted to help get the word out.
Citicon: Continuous Integration and Testing Conference
link
April 16th and 17th
They require a $20 deposit and it’s refunded if you attend. Otherwise it's a donation. :) If you want to take your CI or testing efforts to the next level, you shouldn't miss this one. You'll be spending time with some world-class talent in this space. We're very lucky to have this one in RTP!
Agile Coach Camp
link
March 19th-20th
Also free, but to attend you must propose a topic and be prepared to share. Again, this should be world-class. You'll be rubbing shoulders with some of the thought leaders in this space. Skipping this one should be a crime for anyone in this region who's learning how to be an Agile Coach.
Developer Day
link
Really top notch content for a low price ($50) This is a great place to get new ideas.
Scrum Training
Jeff Sutherland (co-inventor of Scrum) is teaching a local Scrum class with (another local guru) Catherine Louis
link
This one’s not cheap, but should be really good.
I have a feeling I’ve forgotten something… If I have, I’ll update it later.
Category: Agile
(Nov 11)
A topic that came up repeatedly this week at Agile Development Practices was whether we should teach people steps or principles. Most, if not all, of the thought leaders and industry experts don't want to provide steps. We've all seen people take steps and follow them religiously. Leaders don't want to see steps abused. They've seen beginners take the steps and use them... but because they never learn the principles, they don't know why a given step is important.
Lee Copeland mentioned the "if-then" process principle. "If" this happens, "then" do that. All too frequently beginners see the "then" step but never learn the "if". The results, which are often disasterous, are that the prescriptive steps are followed when they don't apply and aren't needed. The "if" gets lost.
So of course, to avoid this, many people refuse to provide steps. They fight against people who provide steps. Steps have been abused, therefore they are always evil. Let's abolish steps!
Unfortunately this view forgets one vitally important fact. Beginners need steps.
Let's emphasize that. Beginners require steps. They can't learn without them. So when we teach without providing steps, they get lost, frustrated, and they quit.
This goes back to a topic I learned about from Andy Hunt, the Dreyfus Model of Skills Acquisition. When learning a new skill, we need (not want, need!) step by step directions. Levels one through three live and die by steps. It's the only way they can get work done. Levels four and five move into the realm of intuition... they "just know" how to do the right thing. They usually forget how to even express the steps! So they naturally try to teach via these very useful, high-level ideas. And that generally frustrates the new users.
Think back to your first progamming class. Did you discuss the ideas and prinicples on day one? No... you were given precise steps on how to type in a program and then run it.
10 print "Hello world!"
20 goto 10
How about cooking? Do the TV chefs measure out and level off teaspoons of ingredients? No... they just throw in a dash of this or a dash of that. Season to taste they say. That's how experts work... it comes naturally to them. But have you ever seen a cookbook that didn't specify teaspoons and cups?
The steps are how we find our footing. They get us started. When we deprive new users of prescriptive steps, we rob them of the ability to get started easily and quickly. They're robbed of the easy wins that get them rolling quickly. We tell them that until they understand the entire ecosystem, until they can grasp the advanced principles, they aren't worthy of playing in our club. This is so wrong.
We also need to warn people about the other extreme though... that's following steps blindly. Read Martin Fowler's article on the improvement ravine. He talks about following a process religiously ~at first~. Then, after you understand it, start changing the steps, tweak, eliminate... make it fit your shop. After you've followed the steps for a while.
I try hard to provide students, especially new ones, both steps and the motivations behind those steps. I tell them there is no gospel in our field. The steps are written by flawed humans and either wrong, or wrong for their shop. Be willing to throw the steps out after you've followed them for a while.
But if you're a teacher or leader, and you want to help people get started with a new topic, from programming to cooking to agile, provide them steps. Give them the "1, 2, 3". Also explain why each step matters. Then tell them to throw your steps out in a few months.
If you don't provide steps, don't be surprised when nobody adopts your ideas. People need steps.
Category: Agile
(Nov 10)
I updated my conference slides after the submission deadline, but I still wanted to share them with everyone. So here's a link.
ADP Orlando 2009 slides link
Category: Agile
(Sep 2)
Yesterday I was asked what software practices I was passionate about. It's not a question I've tried to answer in a while and I think it was worthwhile to consider the topic for a moment. What do I (or you!) care about?
- Continuous Integration- If you've heard me speak or read this blog, you've probably heard me mention CI. It's the best way I know to provide developers with feedback quickly, and a tighter feedback loop is the best way I know to learn. Hudson has tons of mindshare these days, but Cruise Control is still my favorite. At the end of the day, use something! CI is a great gateway practice that can lead to full-scale agile adoption down the road.
- Test Automation- This is another way to tighten the feedback loop. If you cover your code with an automated test, and it's run in your continuous integration system, any breaks or problems are caught very, very quickly. Also, please note that I said automated tests, not unit tests. There's nothing wrong with unit tests. In fact, they're awesome, but too many teams only write unit tests. Put both API level, package level, and integration tests in your toolbox. Then you'll be able to test anything, anytime, anywhere.
- Daily Meetings- Get together every day and discuss what you did yesterday, what problems you encountered, and what you'll do today. This short (1 minute per person) meeting is a great way to share information, keep everyone on track, and build team camaraderie.
- Time Boxed Iterations- Providing smaller goals, 1 to 2 weeks, for your team to hit is a great way to avoid "10,000 feature syndrome," as well as quickly spotting teams that can't deliver. A time box helps introduce a false sense of urgency for developers as well as stakeholders. "We'd love to add that cool new feature, but we're in the middle of an iteration. Can we put that in the next iteration? It starts in a week."
- Peer Code Reviews- I do like pair programming, but for me it's a periodic practice. A peer code review is an everyday practice. Before you check in code, you explain it, and show it, to one other person. This keeps us honest (no one wants to explain bad code to a coworker), and also shares system knowledge with the entire team. A quick and fast one-on-one code review is a great way to keep someone from getting too far off course.
I could type a few more, but this week/months/year has been insanely, overwhelmingly busy for me. So instead, I'll ask you to continue the list. What practices are you passionate about, and why? Put them in your blog and send me a list. I'll post a follow-up blog entry when I have a few interesting posts!
Category: Agile
(Aug 18)
These conferences give you face time with an incredible cast of industry veterans, from Andy Hunt to Dave Hussman to Johanna Rothman and many more. The invited speakers are here because they have proven track records. We know they walk the walk, and talk the talk. Don't take a chance on wasting your conference dollars (and time!) listening to unprepared and unqualified presenters. Make a solid investment in yourself and your team instead.
In this tight economy, don't make the same mistakes others have made... learn from world class experts and make sure your team knows the best way to use the next wave of technology. Don't reinvent the wheel on your team... find out the best way to move your project forward. Topics from automation to team process and more will help you in the weeks and months ahead.
The Agile RX and Ruby RX combo conference is coming to Reston, but the early bird discounts expire this Friday! So far conference sign up has been weaker than hoped, so if you're thinking about coming, please sign up this week. Confirm your spot, and save your company money, all at the same time.
AgileRX
RubyRX
We'll see you there!
Category: Agile
(Aug 10)
There's a one-day, open space conference in Charlotte this week that's worth visiting. Confirmed speakers include Dave Hussman, Jeff Sutherland, Mike Cottmeyer, and Joe Little. I'll be dropping in myself, but not until lunch time. (I'm speaking at the Boston JUG the night before on Career 2.0!).
Agilepalooza
Come out! It should be a fun way to learn from a number of speakers, and others in your area. If you've never attended an open space event, it's less constrained than a normal conference. They're usually very interesting.
I hope to see you there.
Category: Agile
(Aug 10)
If you haven't signed up for the upcoming Agile RX and Ruby RX combo conference, check it out. We've got a stellar speaker lineup for you with topics from the basic to advanced level. We've got introductions to Ruby, Rails, and various Agile topics, to experienced veterans like Andy Hunt, Chad Fowler, Dave Hussman, and more.
You can find out more about the conference at the NFJS One website.
Category: Agile
(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
|
|
|
|
|