Links
·
RSS Feed
Popular Pages
 |
 |
Even though our group was already following many of the practices outlined in Ship It!, I believe the book paid for itself within the first day of purchase. When one considers the burn rate of a ty...
-Steve Mitchell |
 |
.. 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 |
|
...It would be really nice if, as an industry, we could stop being such a bunch of screwed-up clowns and start living up to our potential. Ship It! is one of the things that could help, if only tho...
-Mike Gunderloy |
|
|
|
|
(Nov 9)
I'd updated my slides after they were submitted for the conference CD, so I told the attendees I'd post the version as presented.
Continuous Integration: The Sign of a Great Shop
Category: Agile
(Aug 24)
Lean Dog is bringing their Acceptance Test Driven Development class to RTP and I wanted to remind you to share this with your organization. It's targeted at QA professionals and junior developers. It starts at a fairly basic level, but the concepts are powerful. It's on Sept. 12-16, 2011 so don't wait to sign up.
Acceptance Test Driven Development
The Lean Dog team has a ~great~ reputation and I'm hoping we generate enough turnout for the class to be a success.
Category: Agile
(Jul 22)
Here's a PDF of the talk. Practical Test Automation.
Update: Here's link to the video, taken with my cell phone using Qik. Practical Test Automation
Category: Agile
(Jul 21)
Just a quick reminder that Southern Fried Agile is Friday, July 22nd in Charlotte, North Carolina. If you're in the region, this will be a great event to catch.
Southern Fried Agile: This is Your Brain on Agile!
Here's the list of speakers:
- Andy Painter
- Bill Krebs
- Cory Foy
- Jared Richardson
- Joe Little
- Ken Pugh
- Mike Cottmeyer
- Mike Cox
- Sara Welch
And the topics include practical test automation (that's my topic), Kanban, an introduction to agile, an introduction to agile planning and project management, and more.
You can find the entire list on the topics page
It's a great event and I hope to see you there!
Category: Agile
(Jul 13)
Quite often (and again very recently) I've run into a simple, but frustrating, misunderstanding. I'll often come to work with a team, evaluate their current state, and chart a path for them to move forward. For many of the teams I encounter, this ends up starting with continuous integration and test automation (along with a few other practices).
And I'm repeatedly finding that some developers, but nearly all managers, assume that I'm focusing on QA, or worse, that I'm in a QA role.
It's not that being equated with QA is bad. It's a compliment if you've known some of the testers I've worked alongside. The problem is with the fundamental misunderstanding about the role of automated testing. Automated testing isn't something you hand off to someone else; it's a function of your job if you're a senior software developer (or ever hope to be).
A sure sign of an immature or prima donna developer is the thought that writing automated tests are beneath them, and that someone else should write those test for them. Having someone else write your tests for you is what I call being a software pooper scooper. You're agreeing to follow someone else around and clean up their mess.
What's that you say? There is no mess? Really? If you think that you, or your team, can write tests with no bugs, then you're deluded. You're simply fooling yourself, but not the people who use your code.
Writing software is difficult. There are so many moving parts and we have to line them all up perfectly. Clicking through by hand isn't cost effective, or especially repeatable. If you want to KNOW that your code runs as you intended for it to run, then wrap it with an automated test. There's a small learning curve, but not much of one. Once you've written a handful, you'll find they take very little time at all to create. In fact, compared to sitting at a keyboard and debugging for an hour or two, you'll find writing an automated test takes no time at all.
And that's when you'll be on the road to being a real senior software developer.
Here are a few links for those of you just getting started:
My Junit tutorial
TDD for Embedded C
An Introduction to GTest
An NUnit Tutorial
Category: Agile
(Mar 8)
The really hard part of changing an organization is changing the people, and that's not something I can tell you how to do in a blog post. However, I can tell you about five great practices that will boost your team's productivity, increase quality, and improve communications.
First, use continuous integration. It's a very simple tool with an enormous impact. A CI tool compiles source code after every check in, then runs every available automated test. This means that a developer who checks in code knows as soon as possible whether they've missed a file (oops!), or whether they've broken a test in another area. This type of rapid feedback means that your developers fix their own bugs, and learn from them, instead of having some poor dupe fix all the problems once a week. (See Jenkins for a good CI server.)
Second, require Defect Driven Testing (DDT). How often do you find bugs? Fairly often if your shop is typical. How often do you write automated tests? Infrequently, if your shop is typical. :) Instead you put in a large number of prints, or you step through the debugger for hours. And next week, when you find anther bug in the same area, you'll do it again. Instead, write a JUnit or Nunit test. It's simple, it's easy, and when the bug comes back, your CI system will flag it in seconds, saving you hours of debugging.
Thirdly, stop allowing groups to ask for features using Word docs. English (or any other written language) is very bad way to say something precisely. That's why lawyers make so much money trying to make it precise, then other lawyers always seem to manage to find loopholes. Instead, write simple tests. The automated tests we mentioned before aren't always unit tests. (In fact, they usually aren't!) If you ask for a new API, write a test showing how it'll be used. Need a new feature on the database API? Add a test. When the test passes, it's done. This is called executable documentation and it's an incredible communication tool. Use it between teams that are co-located, but especially when they're not. (Cucumber is a great tool for readable executable docs.)
Fourthly, use time-boxed iterations. Work for a month, or a week, and then stop. When you time box your work, it forces you to break down your work into more manageable amounts. We developers tend to be optimists and quite often (okay, ~always~) take on more work than we can complete on time. A time box lets us say "Done" or "Not done" in a very short amount of time. We get trained on breaking down our work, and our managers (or customers) gets to re-evaluate the work every so often and say "I wanted that feature when it was going to cost two iterations, but now that it's costing me 12, I don't want it this bad! Drop it out."
Finally, get developers talking with your customers. The perspective this interaction brings changes the way your team writes features, and it changes the way your customer sees your development shop. Both sides stop seeing stereotypes and start seeing real people.
There's a lot more you can do to change a shop, but these five tips will start you moving in the right direction.
Category: Agile
(Jan 25)
I'm working on the requirements chapter of Ship It! That work led to a spirited discussion of the ideal (iterative requirements) or real life (we're rushed, on a schedule, and underfunded. Can't be done right. Just has to be done.)
This paragraph (which may or may not be in Ship It!) was inspired. I'm tired and it's been a long day, so take it for what is. :) I'd love to hear your thoughts.
This sounds like a lot of work! We're under extremely tight schedule pressure. We simply don't have the time to revisit requirements. What can we do?
Consider that by not taking the time to revisit requirements, you're instead choosing to build similar to, but different from, features than what your customer wants and needs. How close will you be? That's the dice you're rolling.
If you're really lucky, you'll be close enough to still get paid. Is the product what you agreed on? No. Is it what you promised? No. But they can use it, and your parents are friends of theirs, so, sure. You get paid. What's that you say? The next contract? No, they won't be using you again.
If you're moderately lucky, you'll be able to spin your entire team back up for "minor" retooling that changes half of your application's behavior and introduces a whole new set of bugs. Somehow the "minor changes" the customer asked for have very little in common with the "minor changes" to the code base, or the development team's sleeping schedule!
If you're entirely unlucky, you'll throw away everything your team spent the last six months building and start over. Sure, the team will tell you they reused parts, but that's to make you feel better. They won't reuse anything that couldn't be rewritten in an afternoon. And by the way? You now have six weeks or we not only withhold payment, we also sue you for breach of contract. Sure, it might bankrupt your firm, but that's your problem not mine.
So tell me.
Requirements punk.
Do you.
Feel.
Lucky?
---------------
I've gotten a few replies offline. Since this blog doesn't take comments, I'm posting a few as I get them.
From Tim Wingfield
Whether you build it beautifully or crappily, if you build what the customer doesn't want it's 100% waste.
Category: Agile
(Jan 18)
Technical training is widely available. We've got great books, conferences, and lots of user's groups. Unfortunately, managers aren't that lucky.
Mostly they're expected to just figure things out as they go, and sadly, the results are all too often what you'd expect. Many bad managers float from department to department (or company to company) while never becoming great. They don't lack the desire, and they're very smart people, but they end up trying to re-invent the wheel. Instead of learning and applying tried and true principles, they end up scrambling to learn and understand while also trying to meet challenging deadlines.
Here's a chance to change the status quo. Mary and Tom Poppendieck are bringing their Lean Leadership Workshop to the Research Triangle Park in North Carolina. The lean software concepts are designed to help your team focus on the parts of software development that provide the most benefit, and eliminate the wated effort. This idea has been used for years in manufacturing, and those same ideas map very well to the software space. Mary and Tom were the two pioneers who championed that idea in our field.
In a time of increasing competitiveness... when the economy is still struggling and your company needs every advantage to pull ahead of the rest of your industry, can you really afford to ignore this type of world-class training? Invest in your managers and senior developers, and you'll reap the benefits for years to come. Remember the old proverb. If you think education is expensive, try ignorance.
Register now at Event Brite. Act quickly and you can get the early bird discount. It's expires February 2nd.
Here's some text from the workshop description:
As global competitiveness comes to the software development industry, the search is on for a better way to create first-class software rapidly, reliably and affordably. Lean initiatives in manufacturing, logistics, and services have led to dramatic improvements in cost, quality and delivery time; can they do the same for software development?
The short answer is ..absolutely!
Many methods are improving software delivery, but Lean is emerging as one of the best. It is grounded in decades of research and practical day-to-day usage. Lean leverages this incredible investment into making e processes better. Lean thinking focuses on giving customers what they want, when and where they want it, without wasted effort or wasted time.
Tom and Mary speak all over the world, but we've been able to bring them in at a very special rate. If you've ever considered taking this class, it'll be cheaper to travel to RTP and take the class than wait for it come to you locally! If you're in RTP, please take this opportunity to improve your team, but to also help make the entire RTP area even better. We're already a high-tech hotspot. Let's continue to build up RTP and make it the number place to come when you want software built right.
Category: Agile
(Dec 21)
Winter has arrived here in the US. Even here in the normally temperate North Carolina, it's been 5 to 10 degrees below freezing for the last several weeks. A number of local lakes are frozen... or are they?
When you look at a lake with ice on top, it's a lot like looking at a software project that's "doing fine." It's very difficult to tell how thick the ice is. Will it support you? Is it paper thin or six inches thick? Can you walk on it? Or drive a truck on it?
There are a few different ways to understand the ice. You can look at historical data (it's been well below freezing for the last month), run a few experiments ("Joe, you go first!"), or ask a few people who live beside the lake ("It's never safe this time of year.") Or you could just be stupid and drive your truck onto the ice.
Software is very similar. Are you taking a naive approach? "Look! Everything's working. Keep moving forward." Sure, you're not automating builds. Your automated testing coverage is minimal. Most of the essential bits of knowledge around your system are in one or two people's heads. But it looks like everything is working fine. The water "looks" frozen. Why can't I drive a truck on it?
The problem with software, like ice, is that things can look pretty safe from shore, but still be very dangerous. Putting any weight on a thin project can bring everything crashing down very quickly.
Take some time this week and look at your project. Are there key factors you know your missing? Are there good practices you know you should be introducing, but you've been too busy? Frequent code checkins. Peer code reviews. Defect driven testing. Test driven design. Time boxed iterations.
Nothing? Okay, but watch your back... that water can be very cold, and it's usually deeper than it looks.
Category: Agile
(Oct 7)
There's an upcoming one-day Agile conference here in North Carolina. Catherine Louis and Patrick Wilson-Welsh have been working hard to bring a world class set of speakers for a short, very affordable conference to RTP.
If you're involved with bringing Agile into your organization, you shouldn't miss this event. There will be content for developers and testers (including a remote tester/developer pairing session. The tester will be in the room and the developer will be in another country!), but there's a strong focus on management as well. We'll have Tom Grant, a Senior Forrester analyst, talking about Agile and innovation, Andy Hunt, Jeff Patton, and more.
Between now and October 22nd you can register for $50. After that it's $100.
Sign Up now
You can read more here:
Take Back the Park
Here's the press release:
Agile thought leaders come to you, Thursday, October 28th, in the Triangle.
Come hear Andy Hunt (of Pragmatic Programmer fame), Jeff Patton (agile planning and UX expert), and Dr. Laurie Williams (agile researcher) share their latest observations, discoveries, and passions.
Come meet others in the Triangle who are practicing, learning, teaching, or coaching agile software development. Ask questions, share your stories, join the discussion. Learn how agile principles and practices actually do scale to large organizations, fit in well in regulated environments, and help even the largest organizations increase ROI, morale, and fun, while reducing waste, re-work, and turnover.
Register now at Take Back the Park
For more information on Agile Software Development, we suggest starting with these on-line resources:
http://en.wikipedia.org/wiki/Agile_software_development
The Agile Manifesto
http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/
We can't wait to see you there!
Category: Agile
|
|
|
|
|
