I’m starting to get my feet wet with Twitter…I’ll admit I was (perhaps still am) a little sceptical, but it did inspire me to write this short blog on something that, for those who have been practising Agile for some time, tend to take for granted…the stand-ups. While this topic has probably been blogged to death, here is my perspective on what the stand-up (or scrum) should be.

First and foremost, keep it short…if it goes longer than 15 minutes, then something is wrong. Have a clock in the room so that you start on time, and finish within that 15 minute window. Be militant about this. In that 15 minutes (or less) each developer should have the opportunity to discuss what they have finished (since the last meeting), what is next on their plate, and if they have any roadblocks preventing them from doing anything. This meeting is not the time for Bob to ask Mary what the different options need to be in the new UI they’re designing…break that out into a separate meeting.

A couple of other minor things about stand-ups…as a product manager, I always tried to be at as many as possible to lend support for the team, and to just be available for them. Secondly, feel free to make the stand-ups open to anyone in the company…but as observers only…for those of you familiar with the chicken and pig story, remember, these observers are chickens and as such, should stay silent in this meeting.

There is certainly more that could be discussed about stand-ups , but my clock is showing me that I’m out of time…
Technorati Tags: agile, scrum, stand up, product management

As a Product Manager, I’m a huge fan of Agile. Sure there are the obvious issues to contend with such as trying to nail down an exact date to release the product, or the fact that it doesn’t work real well with larger development teams, or that it can suffer the classic, “that’s not how we used to do things” syndrome. In my opinion, these all pale in comparison to the benefits that I, as a PM, get from Agile.

First, is there anything cooler than showing a totally awesome new feature to a customer and be in the position to gather their feedback (usually applause and cheers of joy…sometimes not so much…) right then and there…not after the release?  It is great to know that you are hitting the right notes so early on, and if not, then having the time to adjust. If you’re not able to demo to a customer liver, then take a few minutes and record a demo for each feature and post it somewhere they can retrieve it from. This is a great way to scale and while the feedback may not be immediate, it still comes in. Secondly, no more Requirements documents that are obsolete a week after delivery of them to development…again, requirements need to be well defined and communicated, but continuously revving a document gets old very quickly. Finally, I love the fact that people (whether internal or external) know stuff about the release. Try running Iteration planning meetings at the start of every iteration, and invite all relevant stakeholders. Here you can outline what is coming for that iteration, and for those unable to attend, post the decks for their review later. This is a great way to increase awareness and communication both within and outside of the team. Surprises are minimized (for those that paid attention), and if done right, these people have had their chances to provide feedback throughout the release cycle. No more Monday-morning quarterbacks telling you that you should have done this or that…

So, if you’re a Product Manager and you’re hearing rumors about your organization going Agile…jump on board, I think you’ll like it.

Testing can have many goals: to assess quality, to assess conformance to specification, to help managers decide whether or not to ship, etc. These all affect a test team’s approach.  Very often, it seems that “Finding Important Bugs Early” is the tester’s primary goal during a development cycle in an agile environment. It’s the ideal: find a quality impacting issue as quickly as possible after it was introduced so that the code is fresh in developer’s minds. “Finding Important Bugs Early” is a goal shared by countless test teams.

It struck me as odd, then, that James Whittaker of JW on Test in his excellent “The Future of Software Testing” series (Part 4), stated that in the future, we need to “close the gap between when a bug is created and when that same bug is detected.” In my opinion, why wait? There are plenty of things we can do to close that gap right now!

The most efficient tactics I’ve seen are the following: early involvement of testers in the development process, good unit testing, code inspection, static code analysis, continuous integration, and effective use of stubs.

Early involvement of testers is not a new concept; it’s already a part of good test process practices. For example, it is a key area of TPI (Test Process Improvement) known as the “moment of involvement”. As a bonus, I’ve always found that testers make great requirement appraisers; not only can they help assess that a requirement is verifiable, but also that it is complete, consistent and unambiguous.  Keeping testers in the loop is especially important in an agile setting where it can help make the documentation barely sufficient, as recommended by this type of development process.

We all know that unit tests are your “first line of defence” for testing executable code. To the developers to whom this task most often falls, I encourage you to ask your test team for help should the need arise. A good test team member has a way of seeing testing from a unique perspective. Use this hidden resource! You can pay the favour back when it’s time for them to use a new automation framework. It’s worth it: a good unit test suite can find many problems early that can be hard to diagnose later downstream.

Code inspection is another early detection tool. Used effectively, it can find logic and design problems at the source, not as a symptom (i.e. when system testing will stumble upon the issue). Moreover, there is no prerequisite of compilation to start it! The same is true for static code analysis. We all know the benefits so apply early, apply often, and save a lot of trouble later on.

For environments that are not of that kind where you “throw the product over the wall” to be tested, continuous integration is necessary. Otherwise, your process may be hindering the test team’s effort to Find Bugs Early. Should your testers be validating last week’s code? Last month’s? If they are, they have no chance of finding your most immediate problems. Don’t forget about bug interactions. It frequently happens that a bug is hidden behind another bug; fix one and possibly expose a slew of others. I heard a question asked once that truly captures the idea: “Why is it that when a bug dies, all the others come to its funeral?” You won’t know who’s in attendance if you’re not testing the latest code.

You may recall that I mentioned the effective use of stubs at the beginning of this post. I hope it piqued your curiosity. It’s something I learned by observing effective testers over the years. When a widget comes off the conveyor belt, they don’t wait for the thingamajig it screws into to start testing. The thingamajig may not be ready for another week! They instead whip up a mock-up of the thingamajig that works somewhat like the real thingamajig and try out their widget, pronto! Very often, the combination doesn’t work as expected and they must ask themselves: are their assumptions about the thingamajig wrong or is it the widget itself? It’s a good thing they didn’t wait until next week to discover this potential problem! This type of experiment enables early integration testing: the component didn’t work correctly in its intended environment. This prompts an investigation into the root cause: is it a bug in the component or a poorly defined interface between two components? Beware however, software stubs can fall into the same trap as a test oracle: you can make it as complex as the real thing if you’re not careful.

These are but a few of the tools for Finding Important Bugs Early. There are many other testing approaches that are not addressed here (so don’t throw away your regression tests!) This post focussed on the “early” part of the goal. What about tactics for the “important” part? Good question! I might be coerced into a follow up post one day…

Here’s Gwyn chatting about general software development challenges, in particular the whole goal of “in-phase defect containment” – i.e. identifying and correcting defects in the same development phase they’re created. Near the end of the video, there’s a short discussion on how this objective fits in an Agile context. With Agile’s focus on the frequent delivery of working software, in-phase containment becomes even more important, even though it’s more often associated with more formal methodologies such as CMMI and Six Sigma.

I like statistics. I always have and always will. I remember manually keeping track of all the statistics for my favourite baseball team by going through the box scores everyday in the newspaper (obviously this was well before the internet came around).  I would manually calculate batting average, slugging percentage, strikeouts per 9  innings and so on. Yup, I lived a pretty exciting youth! Anyways, that love for statistics continued with me, but now I like to know things like how much snow has fallen overnight, and how much more we can expect over the next few days, or what my accuracy is in Guitar Hero, so I can try to beat my 9 year old daughter on Black Sabbath’s Paranoid.

Why am I telling you about all this? Well, I was recently participating in a tour of 5 different cities in Scandinavia over a 5 day period, delivering a presentation on how Source Code Analysis fits in Agile development environments. Fun topic really, but one of the points I raised in each of the 5 sessions I did was that more and more organizations using Waterfall development techniques are moving to Agile.

After being asked by one of the participants to provide an example of this, I brought up some things that I have personally seen over the past couple of years. So I rattled off how in a previous “life” I worked in a mid-sized company where my team was the first Agile team formed. Over the course of 6 months I saw a few more teams show up, and that continued on (and still does from what I hear). I then pointed to the Agile 2008 Conference which, from what I understand, grew in both attendees and vendors, from the previous year, and the expectation is for that trend to continue for 2009. Finally, in talking to people at different trade events (non Agile), training sessions, or customers, etc. I just keep hearing that more and more teams are adopting Agile. But I didn’t have any concrete numbers that illustrated that Agile really was becoming widely adopted.

So I spent a couple hours later that evening (after the usual trains, planes, trains, taxis routine) to try and find some real statistics on this. Well, to continue with the baseball metaphors, I probably hit a solid double. I was able to find a lot of good statistics on typical length of iterations, whether an organization has adopted one or more Agile “techniques”, average Agile team size, and so on, but I just could not find a definitive statistic saying that Agile now is being done in x% of development organizations worldwide. What is Agile’s worldwide market share? That is all I really want. Then I’ll know without question or hesitation that Agile is the approach of choice for software development.

So, from everything I’m *hearing*, I have to believe that Agile is really becoming more and more prevalent. It would just be nice to open up the paper, and see in black and white if Agile is a singles hitter or a home run hitter.

BTW, here are a few other statistics I gathered while on my trip:
•    93% of plane/train food is bad regardless of the carrier.
•    I forgot my hotel room number 60% of the time while over there.