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.

I thought for today’s topic I would delve into something that many organizations have to confront when moving to Agile that is, how to structure their iterations. Many organizations will find that iterations work better if development, testing, and documentation are all done within the same iteration period. Other organizations prefer to offset the testing and/or documentation ½ or a full iteration period after the development is complete. Having lived through both, I thought it might be useful to briefly list the good, and not so good of iteration offsetting.

First the good:

* Testing and documentation are not given features that have been completed at 5 pm on the last day of an iteration, and then expected to have their work done by the following Monday.
* Many dev features are totally complete prior to documentation or testing, so the doc and test teams can start their iteration running, rather than crawling.
* The documentation team is provided with some insight as to the “big picture” of a feature (and not just a standalone story in an iteration) and can plan their documentation for those features with that information in mind. This could help reduce rework on their part.

Now the not so good:

* Development can be drawn back into a previous iteration for bug fixes.
* If demo’ing iterations is a standard part of your process, it could contain a number of bugs since it hasn’t been through any formal testing yet.
* Communication is fragmented…some teams talking about Iteration x, some about Iteration x-1.
* Possible confusion, and more difficult to manage since there are multiple iterations on the go.

Is this list complete? Probably not…but hopefully it will give you something to think about if you’re either starting Agile development, or are struggling with your current implementation. For many projects, the negatives outweigh the positives on this list. As a Product Manager, I’ve seen that many situations where offsets as described above just don’t work. If that’s the case for you, then one possible approach that I’ve seen work is to implement a code freeze 3 days prior to the end of an iteration, and the developers then become part of the testing team.

My personal preference having worked in both scenarios, is to have dev, test, and documentation all occur within the same iteration. Now, my reason is somewhat selfish…when an iteration finishes, I want to show what we’ve done with some level of comfort of the quality and then be able to close the book on that iteration at that point. If that is the approach you prefer, here is a good blog about how to set up such an iteration. Of course, as with most things Agile, there’s never a “right” answer; it’s about finding the right iteration methodology that works for your team’s culture and project goals.

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.