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
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
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!
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!
