Bits 'n Widgets - Team

Planning, Estimation, and Load Factor

John Boal — Thu, 01 Oct 2009 06:45:56 GMT

Sprint planning is the exercise of sizing up the work we think we can get done in an iteration. The recommended practice is to size the high-priority stories on the backlog in story points. Story points aren’t exactly well understood by most organizations, but those that do, more power to you.

We take stories off the backlog to package into a sprint not by how long we think they will take (we estimate that after we break down the tasks) but by the number of story points which indicate the complexity. On a team with at least two sprints completed, I always recommend not taking any more story points than were completely delivered in the last sprint – no matter what, even if they were really low due to some odd circumstance. We can always pull in another story if we finish early.

Now, there are teams out there that have a bit of a different mechanism. Stories are estimated in “ideal days” rather than story points. Then, each team member calculates the number of actual work days in the sprint for them (accounting for vacation and known absences etc). Then a more or less arbitrary “load factor” is applied to this number of days, a percentage of 100 (usually 66%) to find out how many “ideal days” worth of work time we have available each sprint.

There are a number of problems with this method as I see it. First, we have an issue of the remaining time – one third. A third of each day goes where? It gets spent doing what? Not counting for meetings (which almost always can be foreseen) there is a lot of time that is unaccounted. The spirit of scrum isn’t to account for each hour and track who does what when. However, there is almost certainly a lot of actual work that people are doing during this time that has no visibility in the iteration. Agile and Scrum DO require as much transparency and vision into the process of the organization, and this practice of “load factor” I think tends to hide some actual work that the team should be getting credit for doing.

My proposal was to use the ideal days estimates, but add sprint backlog tasks for the things that were being done “on the side” to make them visible, and get “credit” for the real work that was being done but not planned and estimated.

The flip side is that things like meetings, applying operating system patches, and answering email don’t have any real value they deliver. So in that sense, they should NOT be on the backlog. These things are accounted for in the number of available hours for “work” – actually developing the new software.

Leave the status reports and department meetings out of the backlog, but definitely put in that “extra report” for the boss or that batch script for the IT guy. Those are at the very least tasks, and they have customer value (to the customer who got them, not necessarily the end user). Estimate them with story points (even if it’s after the fact), and by all means include those points in the delivered stories at the end of the sprint.

This way there is complete transparency. Everyone can see the actual work that got done, nothing falls through the cracks. And later, when stories aren’t being delivered fast enough (according usually to the boss who got the extra report) then everyone can see that the extra half day spent on that report could have been used to deliver a story. The whole team can then really prioritize what the real features are.

Also – there are a couple of inherent problems in the scenario described above… a good scrum master would have blocked the addition of an “extra report” making the boss decide if he wanted to wait until next sprint or abnormally terminate this one… A second problem that is evident here is that perhaps the Product Owner isn’t perhaps taking into account the internal stakeholders and prioritizing accordingly. Either way, we still shouldn’t be randomizing the team by inserting unplanned work in the middle of a sprint. If it’s that important, stop and re-plan the sprint with the new priorities.

Scrum really does work, but only if we have a set of rules that keep everyone accountable for their contributions and the organizational structure in place to keep the team focused on completing and delivering the highest priority work first.

Making Differences Work on an Agile Team

John Boal — Thu, 16 Apr 2009 05:31:04 GMT

On an agile team, there are differences and dynamics at work that can help either make the team more successful or less successful. A good coach and/or scrum master should be able to see signs and patterns on the team where differences exist, and use dynamics as leverage to get the team moving in the right direction.

Differences
There are differences on all teams. Difference shows up in many forms and factors in an agile team. There are differences of opinion, differences in roles, even differences in genders. There are differences in seniority levels, differences in skill levels, and differences of understanding how best to serve the customer. Each of these and other differences can either drive a wedge between team members, or be used as a lever to help guide the focus.

Once we recognize that there are always inherent differences from many perspectives, we can choose to either amplify or dampen the effects of these differences. When teams have both introverts and extroverts, the behaviors of these team members can be quite different. These differences in behaviors for these two types of personalities can be quite disruptive. This is a difference we need to dampen. We can dampen this difference by choosing consciously to recognize the traits of these personality types as a team, understand how they operate and recognize behaviors. When the team understands what behaviors to expect, the behaviors become normal or expected, and people on the team can deal with them effectively. Dealing effectively with the behaviors can dampen the effect of this difference, and help guide the team towards better synergy.

There are other differences that also might be dampened. Level or seniority differences can be a big part of behaviors on a team. Because a person is a higher level in the organization than others, some people may tend to behave differently either consciously or subconsciously towards these people. These differences can and should be dampened by discussing the issue as a team, and everyone knowing what the role is and why they are there, in the context of that team. A working agreement can be struck such that within the team, everyone knows what to expect of everyone else there. The expectations and roles being agreed upon in advance can help dampen this difference.

There are other differences that perhaps should be amplified instead of dampened. Differences of opinion can be a hot topic in a team, but these differences in the end make a product and a team better. Differences of opinion should not be dampened, but encouraged. Not everyone should think alike. Different perspectives generate new ideas, and that drives innovation and discovery. Differences of opinion sometimes generate heated discussions, however the passion can be partly diffused or at least deferred. Team members may be passionate about a particular opinion, but if differences are encouraged, team members will grow to respect others with a different opinion, as they see these differences at times paying off with higher quality software. The difference in opinion can be not only healthy, but essential to the growth and well-being of a high-performance team.

Differences can be used as a tool to help guide a team, or can be its undoing as well, if left to chance. Great team leaders, coaches, and scrum masters can recognize where there are differences and use them as a lever to guide the team in the right direction.

Transparency

John Boal — Mon, 26 Jan 2009 19:07:49 GMT

One of the large benefits of agile teams should be the transparency to see how things are going at any given time. A team typically has a burn-down chart that shows daily (or more frequent) updates to tasks and stories. This chart is a key to seeing if the team is on-target for delivering what it committed to at the beginning of the sprint. Sometimes the estimated time remaining actually goes up, indicating that delivery will be delayed. This information is critical in trying to manage a project. Problems with delivery are part of the software development game, and should be visible so they can be mitigated.

If we see a trend either flat or upward in the burn-down chart (burn-up as it's called), we should be able to react to this information by talking with team members about what is preventing progress from being made. We can take a variety of actions to address impediments - cut stories, re-focus other team members to swarm on tasks, and other things to try to get back on track making progress toward delivery. However, if we don't have the rapid feedback of the burn-down chart, it's hard to see what the current status of the project is. This chart is the heartbeat of the project.

Team members should do their best to estimate stories and tasks, but as we all know, estimation is usually less accurate at the beginning of a task. When we know more, we should be updating the task estimates for time remaining. Using tools like Rally, Scrumworks, or other products, the work and time it takes each team member to add new tasks and change the time remaining estimates should be minimal and manageable. Make sure to remind team members how important it is to keep the tasks up to date on at least a daily basis.

As an agile team, we should be able to see where we are at all times. This information ideally should even be radiated real-time in the team space so everyone can see how things are going - even the casual passer-by. Problems should never be hidden. Problems always come up, and they get solved not by secrecy, but by publicity. The more minds we have on solution, the faster problems can be resolved. We should never look at problems or impediments as either personal or team failures, quite the opposite in fact.

The team should always be able to see how it is doing, and a good self-directing team will notice its own burn-down impediments and re-focus itself on solving the issue without outside help. Newer teams may need the assistance of a scrum master to call out impediments, but the team should still be responsible for addressing its own issues. Only in personnel or political issues should "management" be brought in to assist with solution. If there are roadblocks, the team should be able to call on the scrum master to assist in bringing in anything needed from outside the team.

Once a team really understands the real power of task breakdown and continuous update of time remaining, they can gauge themselves on their own progress and what needs to be done to address anomalies, avert crisis, and succeed at delivering their commitments.

Pair Programming - A Guideline

John Boal — Tue, 23 Sep 2008 13:00:44 GMT

Here is a kind of step-by-step guide to doing pair programming. If your team doesn’t adopt any other principles of XP or lean, this is the one thing that will give the greatest benefit for adoption. This is a good recipe for ROI++.

Attitudes

In my experience, programmers are the least willing of all professionals in the software development industry to be paired up on tasks. For some reason, we developers seem to have attitudes and fears about this mode of work. I have heard attitudes expressed like "I don't want someone to be nitpicking every character I type," "I dont want to share my keyboard." There are also un-spoken fears that I have heard told: "They might find out that I'm not as smart as they think I am," "the other guy might make me look stupid," and "I don't want them to know how I really write code." These attitudes and fears are the number one barrier to doing pair programming.

C4 Requirements Checklist

For people to be able to do pair programming, I suggest the following readiness checklist to determine if someone is ready. Not everyone is at a point where pairing makes sense for them. When creating a team to do pairing, it is important that everyone have an open mind to trying the process. Give the list to the people and let them do it on their own, and decide for themselves. Don't collect their lists, just their yes or no answer.

Am I willing to Cooperate – do I really want to do this or is someone just telling me I have to do it? Am I bought-in to the idea or is it being forced on me?
Am I willing to Collaborate – can I work together with others in a team environment where we all pitch in together to accomplish a task, or do I need to do things only by myself to be successful?
Am I willing to Communicate – can I tell my team mates what I am thinking? Can I get a point across verbally? Can I take a spontaneous thought and talk it through verbally and get someone else to understand me? Am I willing to work toward these goals if I’m not quite there yet?
Am I willing to Create – can I be of a mind-set that I am creating something of value regardless of the process, and am I willing to try something new to accomplish this?

Implementing It

If your team is on-board with the C4 checklist, congratulations! You now are able to start off on a wonderful process of building some great software. My suggestion now is to get some resources together. Here’s a starting recommendation.

Pair Working Space

The team should ideally have a smallish space to do their pair programming work. This should be separate from offices or cubicles. While this is not always possible, I have seen some great creativity used to put the team together in their own space. Sometimes this means just adopting a round meeting table in the middle of a cube farm. Whatever it means for your team, do establish the pair working space. Use the guideline of 6-8 square feet per person, and keep the team size under 10.

Desks, chairs

One desk for every two people, and one chair per person, with one extra chair is just about perfect. Don’t have the desks more than a few feet apart. Keep the team together in a smallish space. This will greatly aid cross-communication between pairs while development is happening.

Machines

One development machine per desk. Two team members will be sharing one machine.

Monitors, Keyboards, Mice

Two of each per desk. Space them two feet apart so that people can have a little personal space. Connect both monitors to the dual-head video card, and clone the display so both have the same image. Use USB keyboards and mice, and place one each in front of each monitor.

Orienting the Team to Pairing

Be sure to orient your team to this kind of thing first. Let them know that they will be expected to work together on one machine sharing control, but that each will have their own keyboard, monitor, and mouse. Remind them that cooperation and verbal communication is essential when working with a partner.

Hours and Etiquette

When working closely with other people in this way, we need to be polite, focused, and productive. There are times for all of us when we just aren’t all three of these, and that’s OK – it’s just human nature. We need to be able to “check out” and go elsewhere if that’s the case for anyone at a given time. [Assuming a standard 8AM-5PM day…] Start pairing at 10am, take lunch at noon, and stop by 3PM. This gives everyone some time to work on other things or take meetings outside of pairing. Adjust times accordingly for your team, but this is a good starting point. Don’t make the mistake of thinking your team can pair for 8 hours a day. A 5 or 6 hour pairing day is a lot, even for an experienced team.

Challenges

At first, there may be personality challenges. Some people are more easily able to communicate and share control. Don’t worry if the first few days are a bit rocky, this actually can be a good learning experience (as long as nobody blows up). Keep an eye on tempers to make sure that hot situations can be defused before they cause problems. One technique that works well is to switch pairing partners at the middle of the day, or at least every day. This gets people new learning experiences and moves knowledge around the team (another great benefit).

There is one specific challenge that I want to bring up, because on a pairing team it can be a real issue. Everyone should wash their hands. A lot. We shouldn’t have to remind people to wash after visiting the bathroom, but DO it anyway. I encourage and ask people to use hand sanitizer before touching the keyboard at my workstation. Bugs have really gotten nasty out there, if you haven’t noticed. If there is an illness, be sure to make the people stay at home, or a single cold or flu can wipe out all development pretty fast. I recommend spending $2 for a small bottle of hand sanitizer for every workstation and placing it in plain sight.

Benefits

Team knowledge share

Knowledge will naturally migrate through the team, since people working together will share knowledge about a task. Rotating people through tasks is a fantastic way to raise product knowledge and awareness for a low cost.

Better code

Two pair of eyes on a piece of code are always better than one pair. We sometimes call this process “real-time code review.” Mistakes are simply caught far, far sooner. Code mistakes and poor design decisions simply just evaporate as two people think about the code as it’s being written.

Quicker code

Not that it executes faster, but it probably will do that too. A pair can produce a solution to a feature request far faster than a single developer in almost all cases I have seen, and every study I have ever read. It’s not half the time, but it’s probably more like 2/3 (a 33% speed improvement for you percentage folks…)

Tight-knit team

The team will be more integrated, stick together, be more cohesive, and more social together. People on a pairing team will be united for the delivery of a product, and it the experience will form bonds between team members.

High-performance team

Pair programming teams will almost always outperform teams that don’t use this technique. The more experience teams get to have with pairing will yield even higher performance results.

Higher morale

Teams that use pair programming are almost always happier, and more positive about their working experience.

Summary

When we find the people who have an open mind, and are committed to success as a team, we have a great asset to leverage to write good software. Using the technique of pair programming in a shared workspace, we have many benefits for all - the company, the team, and most importantly, the customer. It takes a little work to get to a high-performance team, but it really isn’t much, and in my opinion, easier than finding a way to coax performance from a non-paired team.

If you have any input or feedback on this article, I welcome it – please post a comment below.

Automated Acceptance Tests - Who Should Write Them, Dev or QA?

John Boal — Fri, 22 Aug 2008 04:21:44 GMT

"Obviously, Development should be responsible for the acceptance tests. The developers are the ones on the team who are the best at writing good code. The developers are best able to turn the acceptance criteria into valid executable specifications. Development then can use the automated acceptance tests to drive the development TDD cycle."

"In QA, we never totally trust the developers. We do trust them to do the right thing. However, we have a saying in QA - Trust but Verify. QA should be responsible for the acceptance tests. At the end of the day, it is our job to make sure that the software meets the criteria for acceptance, so it's really a QA ballpark. Dev's should focus on unit tests."

Two strong opinions, and really I think both are right. Development should be using acceptance tests to drive an ATDD cycle. Developers are (usually) better at writing code than SDETs, so they do a more efficient job on acceptance tests. But QA probably has a more even overall view of the software, and from a different and more independent perspective, so they should be writing the acceptance tests as well as the other test automation. QA also has the responsibility of signing off on the code, so they should be writing the acceptance tests.

So, this may be one way to resolve the issue. Have developers and testers both work on automated acceptance tests for the first story. When the tests are completed, developers are free to begin working on the unit tests and code to satisfy the acceptance tests. QA can then begin test case generation and automation implementation.

I believe that this solution is the best of both worlds, because Development and QA will be completely in sync and on the same page for all of the stories where the acceptance tests are co-developed. There won't be any ambiguity on whether the software meets criteria, and both teams will be in agreement as to what is passing and what isn't. The tests will be well-written, and they will run as efficiently and accurately as possible. They will be written with multiple perspectives - the customer (who supplied the acceptance criteria), QA who makes sure that the test accurately guarantees the outcome, and Development, who makes automation quicker to implement and more efficient.

With automated acceptance tests co-written by dev and test, we have a great common point of communication, and a good example of how teamwork can really help software shine and inspire confidence and trust in the eye of the customer.

Become a Certified Agile Developer!

John Boal — Fri, 01 Aug 2008 20:10:31 GMT

The UW Extension for Professional Development and Continuing Education now has a Certificate Program in Agile Development. It's being taught by some guys I used to work with first-hand, so I happen to know they are all pretty good at Agile Development. They are certainly highly qualified, and this certification course is a good opportunity for those folks who may not be as familiar with Agile principles to get some good instruction on how to do it well. Be sure to apply now, as this course is likely to fill fast.

#region is a Code Smell.

John Boal — Fri, 18 Jul 2008 16:19:59 GMT

I have heard a lot of discussion lately about the use of the "#region" directive in C#. There are various camps (some religious) on this topic, so let me throw in my twopence.

Many developers like to use regions to collapse sections of the code because it makes it easier for them to focus on a particular section. That's nice.

If there is that much code in a single file (which *should* be only ONE class), then there is probably too much code in that class. Class design should be focused on one specific thing. According to good OO principles, classes should be autonomous, and do one specific thing. Classes should be intelligent groupings for functionality relating to a specific, focused purpose. The use of the region to group code bits together in a file is a good indication that there is probably too much code.

Simplicity is a highly desired principle in software development. It's the simplest thing that gets the kudos, not the most complicated. Developers who try to write complex, convoluted code so that they can look good to their peers are really doing the opposite. Added complexity is very costly, in time for other people to understand it, debug it, and maintain it.

Here are some ways to determine some code smells in this area.

Do methods have more than 25 lines of code? If so they are probably too big - this is a code smell.
Do classes have more than 12 methods? If so, this may be another code smell. Classes that have lots of methods probably are doing too much. See if they can be broken out into more focused pieces.
Are there more than 3 constructors? Sometimes a lot of constructors could be a code smell indicating using a class for different things in different places.

Anyone else have any metrics that they use? Please respond with comments below.

These kinds of things should be completely discussed on a team, and woven into working agreements, and coding standards guidelines. Teams that work within these are the most productive because everyone is on the same page and playing by the same set of rules. If your team doesn't have a guideline for these kinds of things, I would encourage you to write one up today and get input from your team.

Agile Software Design, Refactoring, and Warts

John Boal — Thu, 10 Jul 2008 15:18:51 GMT

First off, let's get something out in the open. As an agile software developer, I have a couple of strongly held beliefs.

Design isn't optional.
Architecture isn't optional.

DTSTTCPW doesn't mean "no up-front design, we'll just wing it." [That's DO THE SIMPLEST THING THAT COULD POSSIBLY WORK for all y'all who don't speak acronym.]

When we fail to refactor our new code into the existing code, we get odd bits of functionality that stick out from the existing design like warts on a bowling ball. The idea behind refactoring is that we intend to make sure that we *always* have a round ball. Refactor doesn't mean just change a signature or two. Sometimes it means we need to go back to the design white board and figure out what we need to have *now* given the current functionality requirements. We almost always need to change the existing code's design and integrate the new code so that all appears cohesive, each and every time we write new code. Iterative development doesn't intend that we make a bunch of atomic changes and just glue them together.

Code design at each check-in should be able to withstand scrutiny of any outside reviewer, and the design should be up to engineering standards. We still call it software *engineering* not software *art*. Many teams I see are missing this point completely and are producing code that should have been re-designed rather than just having new code glued on. With each check-in we should be able to look over our classes and functionality and say, "yes, this is something that would withstand the scrutiny of a code reviewer not on my team, without excuses or explanation." If I have to couch it and say "well, we will be fixing that in the next release" or "we'll revise that in a later check-in" this is technical debt, and therefore a process smell. Developers that are stuck in this rut need to be re-trained that they aren't "done" with the code until it is production-quality.

If there are warts on your software, this is a very loud process smell, and it should be addressed directly. Make sure that the team understands that this is not an acceptable way to work on an agile team. Re-design in refactoring and adding new code should be common, and discussed among the team after the stand-up meeting daily. "Yesterday I re-factored and re-engineered the Widget classes, so that they now have the new functionality we need in story XXX and are more streamlined to what we are delivering this sprint. Today I plan to have a half-hour review with the team so everyone is on the same page with the re-design. Then I will incorporate all the feedback, get the final code reviewed and coordinate the check-in with the rest of the team to make sure I don't block anyone. I'll make the appointment for the review with everyone after the stand-up."

Make sure that everyone understands that the code as a whole should be well-designed at each commit point, and that this isn't optional. It needs to be expected behavior on the team. This also means that estimation of effort may (and should) go up, for complexity on tasks in both story points and hours. We don't look at revising design as "additional work" just like we don't view unit tests as "additional work." These things are both fundamental parts of the iterative process. Without adhering to these principles, iterative development just won't work, and we might as well go back to waterfall.

If your team has the process smell of needing to budget additional work for refactoring the design, perhaps it's time to go to the team and discuss what Agile software development really means, and that it doesn't mean lower-engineering quality software.

Truck Count

John Boal — Thu, 26 Jun 2008 14:59:18 GMT

What's your team's truck count? No, not how many SUV's do your people drive... Truck Count refers to how many key team members would need to be hit by a truck before your project fails. Not a very nice thought, but it gets the point across. It means, if a key team member leaves your team (and presumably the company) how would this adversely affect the project? Lower numbers are BAD.

About the best you can do is one less than the team size. The worst you can do is "1." Think about your project, and think about who is keeping the brain-share of knowledge. Are they passing it around the team, or does the knowledge sit under one person's cap? If so, that person makes your truck count lower and your project riskier.

Team knowledge sharing is a fine idea, but it's not always easily accomplished. We use tools discussed below for information sharing and actual knowledge transfer.

Tools
First of all, let me just start out with: EMAIL IS NOT A TOOL FOR TEAM KNOWLEDGE TRANSFER. "Well, I sent you an email about that last week..." it's just not an effective mechanism. Don't be tempted to use it. Email should be for temporary and archival type information communicaton - NOT knowledge transfer. Here are some things that DO work.

Wiki

A Wiki is a good tool for a central information repository, allowing team members to add and update information easily and frequently. There are many wiki tools available, but mediaWiki currently is the leader. The ideal wiki site would allow team members to use it without having to "log in" as this is a barrier to getting the information into the site. Even more ideal would be the ability to have remote access to the site from home (with the proper security of course).

Online team services like Rally, Scrumworks, and others

Online team service sites allow individuals to have access to the stories, backlog, burndown, and other communication tools from anywhere. This removes a hurdle to information sharing by not requiring physical access or the hassle of having to fire up a VPN client.

Pair programming, and promiscuous pairing

Pair programming is probably the most effective way for knowledge sharing and information transfer in a team. Pair programming is an XP concept, but unlike Scrum, tenets of XP can be adopted individually on a team, rather than buying the whole program. Each tenet ads value on its own, even if others aren't adopted. Concepts like test-driven development, continuous integration, shared workspace are all good tools for development, but each ads its own value, and all are good for increasing truck count.

Arlo Belshee calls it "promiscuous pairing" when a team doing pair programming switches pairing partners regularly, and frequently. He advocates pairing different team members together rather than the same set day after day. I have experimented with this on a highly performing team, and with the size of the team at 5 and the dynamic there, we decided that half-days were a good mix. After lunch we would switch pair partners, and information flow among the team increased without a large adverse affect on performance.

Shared workspace

Simply co-locating team members is a fine way for information sharing to occur organically. Just simply removing cubicle walls allows sounds and communication to flow freely. Removing physical barriers is an effective way to increase information flow and increase truck count.

TDD game

The pairing game is where one person writes a test, then the other person writes the code. Then, they switch. This is a very effective way to have both parties fully engaged.

Code Review

Reviewing code from other team members is a marginally effective way to get information spread across the team. I am not a big fan of code reviews, but I recognize that they are a necessary evil for those teams not actually doing pair programming. The review must be willing to put aside distractions and interruptions to concentrate on not only what changed, but also the whole of the code - making sure to understand it and verifying that it's doing the right thing.

These are just some of the things I have used for information sharing and helped my teams in distributing the brain share for a project. There are probably others as well, feel free to collaborate by adding your comments below.

Mid-Sprint Checkpoint?

John Boal — Thu, 19 Jun 2008 04:28:03 GMT

Our scrum master on the team I am working with has advocated a mid-sprint checkpoint meeting, to see how things are going, and take a progress pulse. I said this sounded a bit like to me, but that didn't go over very well. I left it at that, but was just thinking about it some more. Why would we need a mid-sprint checkpoint meeting? The burn down chart clearly shows our progress on the sprint, trend lines are good, and everyone is reporting progress and no impediments in stand-up every day. Another meeting? Sounds counter-productive to me, just to see where we are - when we should all know where we are. There are now even have a couple new wide screen monitors displaying 4 rotating web pages, used as information radiators for the team. Everything seems to be good, and going by the book for scrum, so just little things like this that remind me of my Microsoft days cause me to take pause and say hmmm.....

Perhaps a 3 week sprint is too long if we need a mid-sprint review. See the prior article for more information on sprint lengths...

How to Implement Software Security on an Agile Team

John Boal — Sat, 10 May 2008 19:54:11 GMT

Security has always been a challenge in software development. Being in an environment that has rapid ship cycles and iterative development does add challenges of its own when it comes to security.

Here are a few of the key concepts I intend to flesh out in the next few weeks:

Security Requirements

how to come up with security stories
how much is enough?
how much is too much?

Using automated tools

what tools are available

MetaSploit - multiple vulnerabilities: http://www.metasploit.com/
Fiddler - HTTP/S proxy, inspector, injector, manipulator. Fun for the whole family. http://www.fiddlertool.com/
WireShark - network protocol analyzer and sniffer: http://www.wireshark.org/
various other network tools like Snort, RetinA, NetStumbler can be automated and scripted.

use static code analysis tools, and pay attention to their results.
I recommend also doing file and network fuzzing on system entry points, but don't have any good tool recommendations. Got some? Please leave comments!

web site testing vs web service testing
application testing
how do the fit into automation frameworks

Security Documentation (Threat Models)

Designing in Security as Feature 0
Iterative Threat Modeling
Who Reads the Threat Model?
How do we turn threat models into automated acceptance tests?

security testing strategies

white route (internal folks, given the internals of the system)
black route (for-hire hackers, given only an objective to accomplish, and no system information)

security-oriented code reviews

how to train developers and testers to look for security defects

security vs. performance

Sometimes mitigations incur a performance hit. How do we avoid this, and what are some alternatives?

This is an Agile blog, so this is the first production release of this article ... More features (content) will become available over time, so stay tuned to this RSS feed for updates and new content, as they emerge.

Coding Standards, the Team, and the Cowboy

John Boal — Thu, 08 May 2008 21:57:18 GMT

As an agile developer, I think it's fair to say that there is a bit of pressure to deliver software on a regular basis. In order to do that effectively, I need to be able to produce readable code that my team members can understand, and vice versa.

Every org I've been a part of has its own quirks about what it will allow for coding standards. The worst is when there are no standards, or they aren't "enforced." Lots of shops have these cowboy coders that love to do things their own way. It doesn't matter to them that the whole team is going to have to read, understand, and potentially update the code they are writing. The concept of "collective code ownership" is lost on these folks.

What can we do to reign in these cowboys? I proposed a coding standards guideline. It specifies in some detail how code should be written and formatted. It specifies the style, structure, and conventions. I recommended that code follow these guidelines specifically, unless there was a "really good reason" why not. "Really good" reasons did NOT include the phrase "I just didn't like it" or "I have just always done it this way." Being set in ones ways is one thing but being a professional and being part of a team is another.

Does anyone have a practical solution to this issue? If so, I'd love to hear about it... please feel free to post a comment.