You need more than hope and good intentions if your startup relies on viral growth. You need data and metrics to drive decision making.

Going viral isn’t an exact science, but data plays an important role in gauging how successful your customer acquisition efforts will be. Focus on the virality coefficient before all other metrics. It shows the impact of each product choice on growth. The formula, developed by David Skok, illustrates how each new feature impacts your customer base.

Virality-dependent businesses need to craft their strategy, and every decision they make, around the virality coefficient to be successful..

Otherwise, you’ll sound like these businesses.

(Not) Finding Growth

A number of companies have pitched me by saying they will “go viral” and attract users when it’s obvious that they have no believable plans to make it a reality. Many don’t even have share buttons on their apps!

One company made it so difficult to share their app with others that I never used it again. That’s a virality coefficient of -1. Clearly, their focus wandered.

Virality in Action

Let’s say you have ten users and send them ten invites each (100 total invites). With a 20% conversion rate, you’ll finish with a total of 30 customers after the first campaign. Using the sheet I linked to previously, that gives you a virality coefficient of two. Invites * the conversion rate or rather 100 * .2 = 2.

For the next campaign, send out 10 invites to the 20 new users (200 total invites). Assuming there’s no churn or change in the virality coefficient, a 20% conversion rate will bring in 40 new users for a total of 70 users.

Look at the below chart to see just how much of impact each campaign can have. Due to its compounding effects, even small changes in your virality coefficient will have massive impacts on your business.

Cycle 1

Cycle 2

Cycle 3

Cycle 4

Cycle 5

Cycle 6

Cycle 7

Cycle 8

Cycle 9

Cycle 10

Starting Customers

10

30

70

150

310

630

1,270

2,550

5,110

10,230

Invites Sent

100

200

400

800

1,600

3,200

6,400

12,800

25,600

51,200

Conversions to New Customers

20

40

80

160

320

640

1,280

2,560

5,120

10,240

Total Customers

30

70

150

310

630

1,270

2,550

5,110

10,230

20,470

There needs to be a coefficient of at least one for there to be growth. Anything less means you’re churning customers.

Crafting a Plan

To determine which feature to develop in your product backlog, sort the features based on the predicted increase in the virality coefficient. The backlog should look something like this chart.

Feature

Increase of Virality

Share Button

2

Social Login

1.8

Cool Feature

1.5

Photo Sharing

1.4

Logout

1

You need a virality business plan to map out exactly how you’re going to acquire new customers. The plan should determine what features to prioritize, what incentives there are for users to share, and what level of engagement you want to focus on. Don’t forget to determine which promotion channels to use too.

Determining what makes user acquisition work might seem like an art, but using the virality coefficient can change that. Use your data to drive the decision-making process. Even a small increase could mean (hundreds of) thousands of new customers over time.

This past week was the 4th week of the Accelerator HK program. We are already 1/3 of the way through the program!

This week we had mentor Michael Michelini, founder of Weibo Agent come in and speak to the teams. Mike is an American living in Shenzhen, China and working on his own startup called Weibo Agent. Weibo Agent is a graduate of the accelerator Chinaccelerator in fall 2012. Mike came in and talked Social Media strategy and about his experiences in an accelerator.

Later in the week we had Cory Kidd, co-founder of Intuitive Automata come in and speak to the teams. Cory is an American living in Hong Kong and running a startup that is building a robot to be used as a weight loss coach. It is always awesome for me to listen to Cory speak since he runs a hardware company and I think hardware is the new software.

Cory also took advantage of some Hong Kong government grant money for startups and explained how to take advantage of those.

This Friday at the Friday check-in we worked on presentation skills with many presentations and demos going on. We even challenged members to deliver the 1 minute elevator pitch for other startups in the cohort! Now that most of the cohort have done the “Founder Friday” talk about themselves, Paul and I were able to give everyone feedback based on the skills we saw them demonstrate in their personal speeches.

Paul of course was dressed down again for Friday Hoodie Day (where we channel our inner Zuckerberg). We will see if he buys a pair of jeans this weekend.

Lastly, most of the cohort attended the Agile Tour Hong Kong all day seminar on Saturday. We had five speakers from around the world talking about DevOps, Scrum, Distributed teams, Agile Estimation, and TDD.

I am happy to be part of the organizing committee for the Agile Tour in Hong Kong on December 1st. I also convinced Telerik to send me 30kg of Tee-shirts for attendees of the event. Details are below, register today, space is limited (only about 30 seats left)!

Agile Tour is finally coming to Hong Kong! We organize a full day with international and local expert speakers on a variety of Agile topics:

Title : How to suck less with distributed teamsSpeaker : Emerson MillsAbstract:

We all know that distributed teams suck. ( Don't we? ) They perform much worse than co-located teams. Unfortunately for places just starting to move to Agile methodologies, it's often a impediment that has to be worked around or removed. In this session we'll discuss some of the illusions about distributed team productivity and how to get around some of the problems before you can move to co-located teams.

Why did we even use them?!

Distribute teams not people

Giving teams ownership of features and not tasks

Sharing a product development culture

Title: Inject start up spiritSpeaker: Wang XiaoMingAbstract:

During the past a couple of years I heard many complains from CEOs and senior management that there was unavoidable bureaucracy and large company problems which were their big pain. Many teams suffered unclear project goals, small team but many management layers, ineffective meeting, tons of reports and unstable products. Those problems caused project failure or delay. In this presentation I will lead you to experience a real project in a large company who saved themselves from failure and transferred to a team with start up spirit and doubled their velocity in 4 months.

A real project, double velocity

The pain of founders

Inject start up spirit

Lightweight Agile.

Title: Test Driven DevelopmentSpeaker: Ian LucasAbstract:

In this session we will explore Test Driven Development (TDD) utilizing XQuery, the XML Query Language. TDD helps facilitate higher quality software solutions, and the modular nature of XQuery lends itself well to the practice.

Among the biggest reasons for the reluctance of organizations in adopting Agile is their belief in the effectiveness of traditional models in estimation and planning. The fear of losing their perceived predictability through their conventional techniques. Agile erases these all and leaves you with a chaotic view of what is to come. But is that truly the case?

We will first explore the assumptions behind traditional estimation and planning techniquesWe will then counter that with the assumptions behind Agile estimation and planningWe will show the different features of traditional estimation and planningWe will then show the different features of Agile estimation and planningWe then compare what we actually lose and what we gain when we move toward Agile estimation and planning

Title: Introduction to DevOps (topic to be confirmed)Speaker: TBDAbstract:

DevOps is a response to the growing awareness that there is a disconnect between what is traditionally considered development activity and what is traditionally considered operations activity. This disconnect often manifests itself as conflict and inefficiency.

You will have a chance to meet and talk to international and local Agile experts!

Over the past year I have been a mentor at an accelerator called Haxlr8r. Haxlr8r, based just north of me in Shenzhen, China, is a unique accelerator since it is the only accelerator to focus exclusively on hardware startups. The targeted hyper-focus of the cohort paid dividends as everyone is in the same space and learned from each other and shared their experiences.

That got me thinking, why not do the same for software!?!? Over the past few months, I’ve been helping organize the first ever early-stage startup accelerator in Hong Kong. This accelerator is not like any of its kind. It is the only accelerator to focus exclusively on startups doing hybrid mobile development. Why the focus on hybrid? Gartner predicts that by 2015, 80% of all mobile applications developed will be hybrid or mobile-Web-oriented. Just like at Haxlr8r, the laser beam focus of the cohort on hybrid mobile development will only enhance the experience. Why Hong Kong? There are two mobile phones for every man, woman, and child in Hong Kong. In a country of 7 million people, there are 7 independent 3G mobile phone providers with coverage everywhere, even in the subway and on top of the tallest mountain. Facebook penetration in Hong Kong is one of the top per-capita in the world. Hong Kong is not only all over Twitter, but Weibo as well. This is one mobile crazy town, the average taxi driver even has 2 phones. Hong Kong is a great place to validate your mobile app and one of the top places in the world to do business.

The accelerator runs from Nov 5th to Feb 8th and we are going to to provide mentors, investment ($15k USD), lean startup education, co-work space, demo day with investors, just like the gazillion other accelerators out there. In addition, we will also add a little on software development best practices, provide access to free developer tools (Telerik’s Icenium and KendoUI), do agile development training (I think accelerators forget about item #2 in the Customer Development Manifesto), and include free Pluralsight subscriptions.

I think that this represents the next stage of accelerators; laser focused with a little extra love for the tech team.

Want in? Apply today, we close out the cohort applications in a few weeks.

Yesterday I blogged about using a spreadsheet in your Agile Estimation efforts. We left off after the first sprint and had an estimated time to completion of 15.14 weeks. Now let’s take a look at how this works after another sprint.

The spreadsheet is the same, however, now we have data for sprint 2. Cell C2 represents the backlog size in story points after sprint 1. In this case if you remember from the blog post yesterday, our backlog is 106 story points. The team is going to commit to 8 story points worth of work (cell C3) and completes 8 (cell C4, told you the team gets better. ) This makes our Team Velocity 7.5 (cell C5), which is just the average of the total story points completed in sprints 1 and 2 (cells B4 and C4) or B4+C4/2.

The users added 4 story points worth of work to the backlog (OBTW, cell C6) and the bugs were 2 story points worth of work (C7). No items were removed (C8). Now time for the math. If you remember from yesterday, it looks like this:

Total Backlog/Team Velocity

or

((C2+C6+C7)-(C4+C8))/C5

or

((Total story points at sprint start + OBTW in points + Bugs in points)- (Total points removed from backlog + Total Story Points Completed in This Sprint)) / Team Velocity

or

((106 + 4 + 2)-8) / 7.5 or

104/7.5= 13.87

This means that it will take approximately 14 sprints to complete this project, fairly consistent with the 15 in the last estimation. But what about allocating time for OBTW and bug assessments as well as rework. Meaning, we have to allocate time to asses the bugs and OBTWs and estimate the ones that we decide to add in the backlog. This takes time, usually in the first sprints you work overtime and your Team Velocity goes down, however, we don’t want that to happen for the rest of the project. The way to work some of that time back into your estimate is to discount the Team Velocity and redo the math. Let’s take a look at our spreadsheet again, this time discounting the Team Velocity.

What we are doing here is providing a second estimate (C11) that will take into account the time added to the project for assessment of bugs, OBTWs, research spikes, etc, and the time it takes to estimate them. If you remember that we got an estimate of sprints to completion as 13.87 by 104/7.5= 13.87 where 7.5 was our cumulative Team Velocity.

Now we will discount that 7.5 by 5% and recalculate. Why 5%? Gut feel, you will eventually replace that 5% with a more precise number, but in absence of any real data, I just discount by 5% up front. You could either discount the Team Velocity by an additional 5% every 1-2 sprints, or you can try to calculate your bug rate/OBTW rate and replace the approximation by a different number. To be honest, it is easier to just use the sliding scale of –5% every 2nd or 3rd sprint to get started.

So the new math looks like this:

104/(7.5 * .95) or 104/7.125= 14.60. Almost 15 sprints, slightly more than our original estimate at the end of this sprint of 13.87 or 14 sprints. Our new, more accurate estimate takes into account the time that will be added to the project for new items, bugs, and R&D spikes.

The second discounted or “Weighted Sprints to Completion” (C11) is optional, however, it is more accurate. I like using that number since it attempts to account of the unknown. While it is impossible to predict the unknown, it is a scientific way to at least acknowledge that there will be bugs, OBTWs, and lots of other unaccounted for stuff.

Lastly, let’s take a look at how this progresses over more sprints.

As the screen shot above shows, as you progress to the next sprint, you are going to do the exact same thing, except that over time you will discount your Team Velocity by a larger percent, for example, in sprint 4, we reduce Team Velocity by 10% and 15% in Sprint 5. You increase the discount rate to account for more uncertainty in your project, the longer the project goes on, the larger the bugs and OBTWs get. Again, it is up to you how to adjust the percent used.

Hope that this helps everyone out there looking for some guidance on the spreadsheet.

During the recent conference season, I did a lot of presentations about Agile Estimation based on my Pluralsight course of the same name. At the end of the sessions I showed an Excel spreadsheet that shows how to take the concept of Agile Estimation one step further by measuring what actually happened and using that as part of your estimation. I am assuming that you know something about Agile Estimation, however, at BarCamp Hong Kong, I got a request to further explain this spreadsheet in a blog post. As promised, here it is.

Let’s take a look at the spreadsheet after your first iteration (Sprint 1). Let’s assume that our iterations (sprints) are two weeks long. To keep things simple, let’s say that our product backlog had only 100 story points worth of work in it. (Remember this can represent 10 or 25 user stories, doesn’t matter.) This is shown in cell B2.

I like to track everything. Cell B3 shows how many story points the team took out of the product backlog and put into the sprint backlog. This is what they committed to do during the sprint. Remember for Sprint 1 the team will always over commit and under deliver. Who cares? We care more about what they can do averaged out over time (the Team Velocity.) After two or three sprints, the team will start to commit to the correct number and Team Velocity (the average of the total story points completed) will even out. But let’s not get ahead of ourselves.

Cell B4 shows us how many story points the team actually completed in the sprint (in this case 7 story points) and cell B5 shows us the cumulative Team Velocity, which in this case is also 7 since it is the first sprint. After the next sprint we will start to average this number.

Now it gets fun. Cell B6 shows how many story points of work were added to the backlog during or after the sprint. This is what the users forgot or got inspired to add by looking at your work in sprint 1. I call these affectionately OBTWs, for “oh, by the way..”

Cell B7 shows us how many story points worth of bugs were added to the product backlog. (More on bugs in Part II.) Cell B8 show us how many story points worth of work were removed from the backlog during the sprint. (This *does* happen but not usually on the first sprint.) Cells B6-8 assume that the team had time to do an assessment and estimation in points (planning poker, etc) of the new items/bugs during or immediately following the sprint.

Now for the estimate. At the end of each sprint you have to re-estimate the duration of the project. You do this by dividing the total backlog size by the cumulative team velocity. This is done by:

Total Backlog/Team Velocity

or

((B2+B6+B7)-(B4+B8))/B5

or

((Total story points at sprint start + OBTW in points + Bugs in points)- (Total points removed from backlog + Total Story Points Completed in This Sprint)) / Team Velocity

or

(100 +10 + 3) – (0 + 7) / 7 = 15.14

Noticed that we had 100 points in the backlog and completed 7, bringing our backlog down to 93. However we added 13 points worth of work (OBTWs and Bugs), bringing our backlog up to 106 (93 + 13). So the math is factored down to:

106/7 = 15.14

What this means is that after the first sprint, our estimate is that the project will take 15.14 sprints to complete. Since our sprints are 2 weeks long, the project should be completed in 30 weeks. We also know that due to the cone of uncertainty and future bugs/feature requests, that this number is not super accurate (more on that in Part II tomorrow). That is ok, as you know from the theory of Agile Estimation, our estimate for the project completion will only get better over time and after about 5 sprints, it will be pretty dead on.

In Part II tomorrow, we’ll look at how this works over a few more sprints.

Earlier this week the voting was completed and I was elected to the board of the Scrum Alliance for a three year term. It is a great honor to have been elected to the Board of Directors; I hope my experience will be valuable to the board and further the aims of the Scrum community.

My congratulations also go out to Daniel Mezick and George Gosieski who were also running. Daniel and George are both very impressive individuals and their selection as candidates only shows how strong the Scrum community is.

If you are a member of the Scrum Alliance you should have gotten an email asking you to vote for a new member of the board. Please vote! I am one of the three people who are standing for election, below is my candidate summary statement that I submitted to the Scrum Alliance.

Scrum Alliance Board Candidate Summary Statement:

I am honored to stand for election as a board member of the Scrum Alliance. If elevated, I feel that my education (MBA) and past industry experience as a developer, venture-backed entrepreneur, consultant, CIO, and senior management at an ISV will bring a unique perspective to the board.

Having managed both a P&L at an established firm as well as my own self-funded startup, I think my business experience will contribute to the financial and legal health of the Scrum Alliance. I understand what it is like to sit on a board of a high profile industry organization: I have served on the board of similar organizations and take the role very seriously. During the “.com” era, I was on the board of the New York Software Industry Association (NYSIA) from 1998-2004, and served as vice-chairman from 2001-2004. (NYSIA has now merged with the NY Tech Council.)

I am motivated to serve on the Scrum Alliance board since as a professional, I have implemented Agile and Scrum at the places I have worked. I would consider my experience very diverse. For example, I have implemented XP at Zagat (venture backed consumer site) during the “.com” era, as well as Scrum at Telerik (an ISV) in the post- “Lehman” economy. I have also implemented Scrum at my startup that was acquired by a larger non-Agile company and had to re-implement it as part of the merger. Additionally, I visit several Telerik customers in Asia who are bumping into some of the limits of Scrum and are implementing some of the “Lean” practices such as Kanban and “Software Kaizen.”

While my experience with Agile and Scrum comes as a practitioner, not a trainer, I do speak on Agile and Scrum at several industry events a year worldwide, so understand the educational and certification side of the organization. In 2011, I have spoken about Agile several times in many countries, reaching thousands of practitioners.

As a Certified Scrum Master (#37679) and member of the Scrum Alliance’s insiders “Agile Leaders” Google email group, I feel that I know the organization well and can contribute to its mission. I am familiar with the Scrum Alliance’s 2010-11 Strategic Plan and Certified Scrum Professional Program (I volunteered as a beta tester of the exam and passed, so I am now a CSP as well). I also feel that the Scrum Alliance’s goal of larger community outreach fits in with my experience as a conference speaker and user group leader.

While based in Asia, I am a New Yorker, and am an executive at a European company, so I have a truly global reach. I speak about Agile, Scrum, Lean, and Kanban all over the world. My company, Telerik, makes Agile tools and also has a global reach. (This year I helped Telerik open offices and launch new business in the UK, India, and Australia.) I’ll bring a global perspective, and if desired, I can also help the Scrum Alliance expand outside of its core markets.

I have a long history of volunteering and giving back to the community. I have been running user group events since 1996 and have been awarded an “MVP” award from Microsoft for my community outreach. I also am heavily involved with charity, helping raise money and organize a charity, Education Elevated, dedicated to building schools in remote villages. I lead treks to Mt. Everest Base Camp each year to raise money for the school.

I can wear jeans and a tee shirt (preferred) and speak to developers about deep technical and process issues and then turn around and put on a suit and talk to a CEO about business models, strategy, and macroeconomics. It would be an honor to bring my experience and creativity to the board of the Scrum Alliance. I have a passion for Agile and Scrum since they truly have changed the way I do business, and I want to help spread the word and adoption of Scrum worldwide. Lastly, I want to “give back” to Scrum by volunteering my time on the board since I feel Scrum has given me so much over the course of my career.

Thank you for considering me; it is an honor to even be considered for the board of directors.

Over the weekend I had the privilege of being a judge for the Startup Weekend Hong Kong. We had eight very impressive teams ranging from consumer apps to enterprise software. After the “speed dating” five minute presentations with only three minutes of questions, myself and the other judges went to deliberate. We could not agree on a winner at first and debated and took two votes where nobody had the same identical #1 and #2. The fact that it took a few rounds of votes by the five judges to come up with a winner shows just how much quality there was in the startup teams. The winner, Awesome-Ship, was a team that wants to revolutionize shipping and be a platform for companies that ship products.

On Wednesday I will be speaking at the Hong Kong International Computer Conference event and my session, “The Use of Knowledge in Today’s Society” is about information overload, knowledge management, and entrepreneurship opportunity in Hong Kong. I make the case that with the super fast broadband, great business environment (ranked #1 by the World Competitive Index), access to the Asian markets, and a Facebook/iPhone obsessed society, Hong Kong is a great place to start a business.

My talk today is on Lean Manufacturing's influence on Agile methodologies: The Past, the Present, and the Future. I talk about how XP was a reaction to Waterfall’s “batch” mentality and heavily influenced by Lean’s notion of units of work v batch and reducing lead time (which heavily influenced iterations.) Then I talk about how Scrum and Kanban come directly from Lean, but with modifications for software development. I stress how lean is about eliminating waste by reducing the quantity of what is produced at one time (translations: very small iterations, if at all) and building a culture of continuous improvement. Sessions are only given 25 minutes, so I had to to this at a high level. I’ll work on a longer more in depth one for TechEd and the speaker circuit in 2012.

The night before the conference started (Halloween!), I had the pleasure of spending an hour with Li Ming, the deputy mayor of Shenzhen and ten fellow speakers. It was all very official; we were in a big room with name cards and we sat in big chairs drinking Chinese tea. Joining me at the meeting and then at dinner were very prestigious speakers, including a member of the board of directors of Microsoft and the CTO of Toyota (Info Technology Center). There were many toasts, something you can’t avoid in China. I feel that Telerik has made it to the big leagues.

I give a talk on Wednesday: “Lean Manufacturing's Influence on Agile Methodologies: The Past, Present, and Future.”

In the past, most developers’ approach to code is that you should write it once and hopefully never have to debug or revisit it again. This stems from the traditional waterfall approach of software development where we were trying to completely describe the entire system up front perfectly. Change was bad and bugs were not accounted for and left for the end.

The Agile movement ushered in the first change to this mentality. Agile introduced the concept of refactoring, or writing your software once and then revisiting it (often if needed) and restructuring its internals for improvement (without changing its external outputs). Refactoring is a core tenant of test driven development, where you are encouraged to refactor each method you write at least once.

The Lean Manufacturing movement is built around the concept of Kaizen, or Japanese for “improvement” or “change for the better.” Last week at the first even Lean and IT summit in Paris, France, I heard once or twice about the concept of writing code as a Kaizen event. Software Kaizen goes a step further than refactoring.

The Lean guys were talking about Kaizen as the removal of waste by the improvement of your own work. It is about understanding waste derived from your own decisions, looking at the unnecessary costs created by our wrong assumptions and decisions. The Lean guys spoke about how Kaizen is cultural shift that gets people thinking.

While refactoring addresses each individual method, Software Kaizen takes a much broader approach and looks for waste in your entire work. A lot of time we developers build features and stuff that are not needed. Where did you create a library that you only call once in the name of “maintainability?” Where did you make something unnecessarily complex in the name of “extensibility?” Where where your assumptions incorrect and caused problems or ambiguity in your code? When have you over engineered a feature? Refactoring only partially addresses this, we’ll go in on a regular basis and refactor a few complex methods, but we rarely ask ourselves if we need that entire method in the first place, or an entire feature. Software Kaizen asks us to look at our code and asks us why did we do it this way, with a “cut first” mentality. It challenges the assumptions we made at the time we wrote the code.

Traditional waterfall approached code as something you should write and be perfect the first time and only revisit it when you find bugs. Agile encourages refactoring your methods for improvements in the way it runs and reads internally. Software Kaizen encourages looking your system and looking at the choices you made in the name of maintainability, extensibility, etc, and ask yourself where you were wrong. Software Kaizen focuses on approaching your code knowing you are going to change it often. In the past we fought change, Software Kaizen embraces change as part of the process.

Give it a try, it is harder than it seems. (“Of course I need that really really complex method, I may one day port this code to a Mainframe!”) Good luck and happy coding.

Announcing a unique opportunity coming to the Philadelphia metro area in early September 2011:The Philadelphia Day of Agile Conference!Building on the success of similar events over the past three years in the Midwest, Philadelphia Day of Agile is a single-day, three-track conference introducing the elements of Agile Software Development to newcomers as well as fostering stimulating conversation for those more advanced in the subject.Conference TracksAt this one day Conference on Saturday, September 10th, 2011 you will have the opportunity to attend sessions in any of three different tracks:

TRACK 1: focusing on those new to Agile

TRACK 2: targeting those with some agile experience who want to grow their skills

TRACK 3: for experienced agilists interested in exploring new horizons in their Agile adoption

There is a strong possibility for a fourth track that will focus on "hands-on" workshops for both beginner and advanced alike

Attendance for this conference is $50 per person and covers the costs of the facility, breakfast, lunch, and beverages throughout the day. Registration will remain open until all tickets are sold but seats are going fast so RSVP as soon as possible to guarantee yourself a seat at this exciting conference event! Register now athttp://phillydayofagile.eventbrite.comRegister before midnight on August 28 and be entered to win a 5-User License for Telerik's TeamPulse ($1,295 value), or a Telerik Ultimate Collection License ($1,995 value)!For the most current information, please see http://www.dayofagile.org orhttp://phillydayofagile.eventbrite.com.

When people think about Kanban, they usually get the impression that Kanban is either an inventory control mechanism or a system to manage an assembly line of workers. This is due to Kanban’s historical roots as part of Lean Manufacturing and the Toyota Production System.

When I talk about Kanban, especially in reference to using Kanban with software development, I stress the importance of flow; how you pull items through the production system while limiting the work in progress. My favorite thing about Kanban is the Kanban card itself. Kanban gets its name from the card; Kanban translated from the Japanese means “signal card”. According to Lean definitions a Kanban card contains information about a part used in production. It is a signal that tells someone upstream to order more of that part, or move more of that part (from inventory to a production queue for example), or build more of that part. In essence a Kanban card is a visual signal that triggers an action to happen in the workflow.

Kanban has evolved to be used outside of the manufacturing world and has started to gain acceptance in software development. Kanban is also being used in operations outside of manufacturing and software. In his book, Kanban, David Anderson described how Kanban is used to do crowd control at the Imperial Gardens in Tokyo, limiting the inventory or “work in progress” (visitors.)

I had a similar experience this past weekend in Japan. I was on a short weekend vacation in Tokyo with my wife. What had started out as a trip to watch some professional Japanese Baseball, slowly was evolving into a shopping trip for my wife. Hot, tired and trying to avoid shopping for shoes, I suggested we duck into the local Starbucks. As my wife snagged us a table, I tried to order by pointing, smiling, and hand jesters. Somehow I was able to order my old reliable a Tall Soya Chai. After I paid, I was handed my receipt (never walk away in Japan without first taking the receipt) and a strange looking card.

I did not really know what this card was for, but it did say “Soymilk” in English as you can see from the photo. I was intrigued and figured that maybe it was information about the Soya Milk that they use or maybe it was something about the organic certification.

Then I figured that it was probably some rock star Japanese targeted marketing, the Soya Milk company probably paid Starbucks to place an advertisement for their soya milk so you can buy it for use at home. I decided to flip it over since, this being Japan, I figured that there was probably a bar code for my Android phone to scan and I can see the ad. I wanted to see if there was a link to buy it, with a discount, with one click. (I’m sorry, but this is how my mind works.)

To my shock, when I turned it over, I realized that I was holding not a marketing ad, but a real-life Kanban card! The back of the card read in both Japanese and English: “Please hand this card to our Barista at the hand off.” It went on to say at the bottom: “We sincerely serve our soymilk beverages to our customers by using this card to prevent milk allergy incident.”

Wow! As someone with a milk allergy and someone who teaches Kanban, I was blow away. I have been drinking Soymilk Chai for almost 10 years and have been to tons of Starbucks around the world and never have been given anything to signal to the Barista that I received the correct beverage. (Actually I find that the Barista’s in New York consistency screw up my order.)

Now you may be thinking, “Steve, this is a stretch. Kanban is about work in progress and just in time delivery, not coffee.” At the surface you are correct, but Kanban is about using a physical visual signal card (Kanban Card) to trigger an action in a workflow. Usually this trigger is to order more inventory. Sometimes that inventory is car tires (as in the assembly line in Toyota) and sometimes it is people (as in David Anderson’s visit to the park.)

In this case, Starbucks in Japan (I went to several other Starbucks to be sure), uses Kanban to manage the ordering, making, and drink pick-up workflow by verifying (or limiting the work in progress) inventory of Soya beverages made. In the “Soya” case, the cashier starts the workflow by processing the Soya request and gives the Kanban card to the customer and alerts the Baristas to the order. When the customer hands the Kanban card back to the Barista, one Soya beverage is removed from the queue; the number of Kanban cards must equal the number of Soya beverage inventory at the counter. In essence, the Customer “pulled” the work (the Soya beverage) through the system and the Kanban card is ensuring quality.

Remember, a Kanban card is about a visual signal that triggers an action in a workflow. The Soya Milk Kanban card signals to the Barista that they must remove one Soya drink from the inventory of drinks in front of them. (If you have ever been to Starbucks, you know that the Barista may have 5 or even 10 drinks in front of them in “inventory” at any given time.) When you look at this system as a whole, it is pretty simple, yet brilliant. Maybe we can start to use visual signal cards as part of the QA process in software development. I left Japan inspired by Starbuck’s embracement of Lean manufacturing and Kanban for quality!

PS: I tried to bill my employer, Telerik, for the drinks I consumed in Japan this weekend on an expense report, saying it was “market research”. When my expense report was rejected, they told me that the accounting department is now using a Kanban system to maintain quality and my expense report was flagged.

Yesterday Joel and I did our “Agile Buffet Table” session at GIDS in Bangalore, India.

We talked about XP, Scrum, and Kanban and how you can build your own methodology by mixing and matching the features from each of these agile brands. We had *great* audience interaction, the best I have ever had in India. We wrapped up the session by opening Excel and designing a unique process with the audience. Our exit was also very funny, there was no break between sessions(!), so the next speakers came in and were ready to start when we ended. So I impersonated the next speaker, very agile.

The slides are available here (via slideshare.) In addition we talked about a lot and have recommended the following resources:

In Part I we looked at how I got into Agile and Scrum. In Part II we explored how Scrum failed to be flexible enough to fit into my unique process. In Part III we took a look at how I got introduced to Kanban, without even knowing it. Today we’ll take a quick look at what Kanban is.

Kanban is a Japanese word that loosely translated means “signal card.”Kanban’s underlying thesis is that by using signal cards at various points in the production process to indicate the amount of work completed, you can limit the amount of work in progress (WIP) and thus keep the system very “lean” and agile. Work in Progress (WIP) represents inventory and inventory is expensive to keep.

Kanban was originally developed at Toyota as part of the Lean manufacturing movement to facilitate pull systems in a just in time (JIT) production manufacturing process. Work is pulled through the system in single units by demand, instead of pushed in batches. Think Dell computer’s JIT assembly of your laptop as you order it; Dell is pulling a single unit through its production process on demand as opposed to pushing through a batch of computers and selling them pre-configured.

Over the past few years there have been several blogs and books describing a Kanban process as an agile methodology for software development. There are far more robust explanations of Kanban out there on the Internet, so I will not try to outdo them here, however, let me give a brief overview and then circle back to the system I described in Part III.

As a development methodology, Kanban is an evolutionary process that focuses on the flow of work in progress. Individual items of near equal size are pulled on demand through the system. Kanban focus on the flow of the work, trying to make constant improvements to the flow. This increases the predictability of the system. Evolutionary by nature, Kanban is designed to facilitate continuous learning and improvement to the process (the Japanese call this kaizen ). Kanban teams usually put up a “Kanban Board” where they have the process states as columns and sticky notes representing the queue or work items and where they are in the production cycle. This visualizes the production system and allows you to spot areas for improvement.

The Kanban board is the most important item in the system, it represents the production flow. As an item moves from “design” to “development” to “test” and off the board to production, you can get a holistic view of the process and identify bottlenecks. Kanban has a daily standup meeting, not to focus on “what you have done today” since that is obvious via the Kanban board, but rather to focus on the production process and talk about bottlenecks and how to improve them. For example if you have way too many items queued up in the “tester” queue, you can make changes to the way the work flows through the system (or identify that you need more testers.)

Kanban throws away the concept of a sprint and even estimation to a lesser degree. Stories are larger in length and scope but you have less of them in your system. If you break down tasks into digestible units of comparable size, by looking at the Kanban board, you know how long it typically takes to get tasks done.The goal of Kanban is to keep the work in progress as small as possible, at the exact flow rate that the team can handle.The team will commit to deliver work items at the flow rate, and expedite important work items. As time progresses and the team improves, the flow rates can be adjusted.

Sound familiar? This is the system I stumbled across at my start-up defined in Part III (minus the Kanban board.) If I had a Kanban board I would have had all of the states (analysis and rules complete, in progress, etc) on top and had sticky note for each task (the RegEx work) in the workflow and where it was in the process. Since our tasks typically only took half a day and moved from start to finish off the board in about 48 hours and we had a remote team, it would have made sense to have an electronic board. Nonetheless, our quazi-Kanban system limited work in progress, allowed the developers to pull work out of the queue in a very predictable pattern, and produced quality results. The most important part is that the system was flexible.

Since we started as a Scrum process and evolved to a more lean manufacturing influenced production system, I learned that no single development process (such as Scrum) is a “silver bullet”.I also realized that all of the “features” of Agile are available to you and you can mix and match them-as long as you adhere to the Agile values put forth in the Agile manifesto.More on this later in the last part of this series.

In Part I we looked at how I first got into Agile and Scrum. Last week in Part II, we explored how Scrum failed to be flexible enough to fit into my unique process. Today we will take a look at how I got introduced to Kanban.

The start-up I worked at a few years ago that I described in Part II successfully used Scrum for traditional software development, however, when we were faced with a pretty unique development requirement, Scrum failed us. To refresh your memory from Part II, we had to spider thousands of web sites. Each web site was entered with a specification from a business user and prioritized. The developers worked on the highest priority item in the queue and published the RegEx patterns to a test server where the overnight process picked them up and the results were verified by a tester the next day and put into production. In Agile terms, we had a big backlog, each item in the backlog was about the same “size” and the customer (business users) prioritized the items in the backlog.

As I said in Part II, Scrum did not work, for starters we did not need a cross functional team, our team had about 10 developers on it that did one thing: produce the RegEx patterns. No need for a daily scrum either. In addition, we did not have to time box our development effort into a two week or month long cycle, we delivered daily. We prioritized daily as the new requirements came in and old sites stopped working.

All work was the same so we would assign a state to the work:

Web site identified for spidering

Site’s business analysis and rules complete

Site sitting in the developer queue

In progress

Done-need verify

Testing

Done-verified

We developed a classic “pull” system. The developers pulled a single work item (as opposed to a batch of work) out of a queue (backlog) and when they were done put them into the test queue (which when complete was then scheduled to go into production.)

We also developed different classes of service for each work item. At first 90% of the sites in our queue were listed as “High” priority and then the business asked me if we could have a “Very High” priority status. I said no, since I knew it would eventually be abused like how the high priority status was. We then made the process simple no more than 10 highs in the system at a time (we only have 10 developers for example) and they were expected to be into testing within 24 hours. Mediums would be assumed to be done in 48 hours and low had no guarantee, we’ll get to them when we get to them-we let the business reprioritize (and change status) daily.

After a few months we made another change. Each developer could do on average two sites a day, so our throughput was 100 Regex a week for a team of 10. At first the business would have 200+ sites in the queue and each morning promote 10 mediums to high (or 8 mediums to high if 2 new highs came in as new items.) After constant daily reprioritizing, we decided to limit the number of items in the queue/backlog to only 2 days’ worth of work since our guarantee was 48 hours for mediums and 24 hours for highs. Now new high priority sites were added only as needed and every two days the business would add 40 new sites into the queue. (In reality, the team never hit 100% on the dot, so sometimes we would add only 32 items since 8 were still left over, etc.)

This process worked great, the team in India pulled items out of the queue while the business team in New York was sleeping and completed the items early morning New York time. The testers would verify early in the morning (when India was sleeping) and either put the site back into the development queue or put it into production. Every second day the business team would add approximately 40 more sites into the queue. In the past the business people would do a dump of about 200 or 300 sites at a time. By having so many items in the queue, the team would then have to spend too much time just managing the process and reprioritizing. Sites fell off and got lost. Only by limiting the work in progress and by limiting the queue did we achieve success. In addition, by keeping the queue small we allowed the business to reprioritize and have the developers pull the items through the system on demand. Our daily meetings were more focused on bottlenecks, process, and throughput, not “what am I working on today.” Since we were well oiled, we could predict how long it would take something to flow though the system.

This was about 3 or 4 years ago and I did not know it at the time, but we were using a primitive form of Kanban. I would not even hear of Kanban as an Agile process until about a year or two later. (By then I had sold this business and was working at Telerik.)

Yesterday Joel and I did our “Agile Buffet Table” session in Sydney, Australia at Telerik’s all day developer seminar. We talked about XP, Scrum, and Kanban and how you can build your own methodology by mixing and matching the features from each of these agile brands.

In the last post, we looked at how I got into Agile and Scrum. Today we will take a look at how I started to break the rules.

After reading the Agile books by Ken Schwaber and obtaining my Certified ScrumMaster credential, I doubled down on Scrum at my start-up since it was working so well. As things progressed and our business evolved, I started to bump up against the “rules” of Scrum.

As I mentioned last week in Part I, the guidance was to only use Scrum locally, not with offshore developers several time zones ahead. I was also breaking many other “rules” most notably the sprint length, at that point the length was supposed to be one month, but I was using one week. I also changed the daily scrum to late in the day for the developers and inverted the questions to:

·What did I do today?

·What will I do tomorrow?

·What do I need from you?

We also had a very small team so we dispensed with the formal sprint retrospective and did it continuously. Then the big one hit. A business requirement came down where we had to develop thousands of Regular Expressions (RegEx) for sites that we spidered.Each RegEx would be considered a work item in our backlog. They came with a spec from the business (what to capture) and the end result was a few RegExes as rows in a database.We had to produce massive amounts of RegEx patterns so we hired a ton of “regex developers” or college kids in India looking for extra money.

We managed our backlog pretty easily but I struggled with applying the rules of Scrum to this process. Typically a developer would take the next highest high priority items from the backlog, work on it for a few hours and return it. They would work on two or three of these a day. I tried doing a daily scrum but it was boring for all involved. (Today I worked on RegEx. Tomorrow I will work on more RegEx. I need more Regex!) Also time boxing our iterations to a month did not make sense. We had to “release” or upload the patterns to our sider engine farm daily.

I asked Scrum experts and consulted the blogs and they all said not to change Scrum! They kept on about cross functional teams, a sprint backlog, 30 day sprints, daily scrums, etc. It was then when I decided that I would just apply the values of Agile and some features of Scrum to my process. I was labeled a “Scrum, butter” by Ken Schwaber (he even did this publically many years later at TechEd 2010.) I went back to the Agile manifesto and looked at the original four values:

·Individuals and interactions over processes and tools

·Working software over comprehensive documentation

·Customer collaboration over contract negotiation

·Responding to change over following a plan

I looked long and hard and realized that the current Scrum experts were too rigid.Scrum boxed me in and when I had a business need that required some creativity, I was not able to use Scrum.So I ditched Scrum and what I wound up doing was using an early form of Kanban. (More on this in the next post.)

Telerik, the market-leading provider of end-to-end solutions for application development, automated testing, agile project management, reporting, and content management across all major Microsoft development platforms, is coming to Australia.

We invite you for in-depth sessions with industry experts and Telerik Senior Leadership. All attendees will receive a copy of Telerik JustCode, valued at $199.

Please note these are 4 separate seminars; you need to register for all those you intend on attending.

New to Agile? Having challenges implementing an agile process in your organization? Have you been using Scrum, but need to bend the rules to make it work in your organization? Can’t get the business to “buy-in”? Come and learn about implementing an agile process in your organization. You'll look at the “buffet table” of agile processes and procedures and learn how to properly decide “what to eat.” We’ll start by defining XP, Scrum, Kanban and some other popular methodologies and then learn how to mix and match each process for various scenarios, including the enterprise, ISVs, consulting, and remote teams. Then take a look at agile tools and how they will aid in implementing your development process. You’ll see how Microsoft Team Foundation Server 2010 provides process templates for Agile that facilitate better planning and metrics. Learn how Microsoft’s application lifecycle management (ALM) tools can support your development process. Lastly, we will talk about how to “sell” agile to your business partners and customers. The speakers have a very interactive style so participation is encouraged and there will be plenty of time for Q&A.

As more product teams move to Agile methodologies, the need for automated testing becomes essential to generate the velocity needed to ship fully tested features in short iterations. In this session we will look at the differences between traditional testing and agile testing, explore some tools and strategies that can help make your automation more productive as well as how to get the automation effort started for both new and existing agile projects.

Choosing a CMS can be a daunting task. There are plenty of Content Management Systems to choose from; ranging in price from free to extremely expensive. From this crowded landscape it can be difficult to find a CMS that effectively enables an organization to accomplish their goals. In this session, I will identify 20 things to consider when evaluating a CMS that will help you select the ideal CMS for your project.

PRESENTERS:

Gabe Sumner, Developer Evangelist at Telerik

Martin Kirov, Executive Vice President of the Sitefinity CMS division of Telerik

Tired of dealing with the bloated pages generated by your WebForms application? Wondering what the whole deal is with MVC? Already into MVC but want to get maximum performance and functionality out of your applications? In this presentation we will take a look at how ASP.NET MVC, together with the Telerik MVC Extensions, can have you developing applications with high performance and functionality, while output light-weight and easily readable HTML.

PRESENTER:

Malcolm Sheridan, Microsoft awarded MVP in ASP.NET

Speeding up Development Using 3rd Party Controls

Learn how to cut Silverlight development time significantly using your new Telerik RadControls. As a TechDays attendee, you will receive a complimentary license for Telerik’s RadControls for Silverlight. This TurboTalk will demonstrate how you can speed up application development while adding more functionality to your Silverlight applications with the Telerik tools. See how high-performance data controls like RadGridView and RadChart can take your applications to the next level. See how layout controls like RadDocking and RadTileView can add both richness and increased functionality, helping you maximize screen real estate. And see how RadRichTextBox is unlocking Silverlight’s power to enable editing of HTML, DOCX, and XAML content. Jumpstart your development with the RadControls for Silverlight and get the most out of your new tools by joining this developer-to-developer talk.

In the beginning I used waterfall. There I said it. Looking back at the mid to late 1990s, I can’t believe how I ever got software developed at all! ;)

I was first introduced to Agile methodologies ten years ago. When I was the CTO of Zagat, one of our board members gave me a copy of Kent Beck’s original Extreme Programming Explained. At the time Zagat was doing a modified version of waterfall that was more “agile”, meaning we were doing things quickly and responding to the needs of the business (this was the .COM boom you know!), however, we were not Aglie insofar as we practiced any specific agile methodology. I read over Kent’s book (note to all of you CTOs out there, a board member gives you a book, you read it) and dismissed the concept of pair programming, but embraced several things in the book, including continuous integration and short iterative release cycles. At the time I don’t think it was called “iterations” but I sold it to the CEO as “short iterative chunks” of functionality. I would not make the argument that we were implementing XP, however, we did take some tenants of XP and roll it into our process. We even hired Steve McConnell to come in and help us with that. (That was the best part of the .COM era, we had budget to bring in Steve McConnell!)

After I left Zagat, I started my own business in New York. It was an online service to allow people see how the economy was doing by looking at the ad spend in certain categories (like jobs, autos, and real estate). At my new company we had 1 developer at first, so we started using a blended Waterfall/XP/Sprial/fly by the seat of your pants process since we were in startup mode. After we grew and had a few more developers, my lead developer forwarded me a blog post about Scrum. I read it over and told him that it was cool, but probably just a fad. (He still likes to remind me of this!)

A few years later we augmented our developers with a team in India. We suffered communication gaps and poor quality. (This was BS, or “before skype” in like 2004.) I was desperate to get a productivity boost from the team in India. It seemed that after each of my frequent visits to India, the team was running at like 200% for a few weeks and then leveled off back to the poor productivity. I decided to try out Scrum since the parts of our process that worked were the items we borrowed from XP.

Almost overnight Scrum worked very well for us. The team in India and the team in New York were in complete sync and the business was on board with the rapid release cycles (sprints). Since we were a small company, the entire company could participate in the daily scrum, increasing the communication flow and buy in from the business side. The team in India got addicted to the daily scrum and were in the zone. We were running circles around our competition. Life was good.

Then I read the scrum books. I read the section on “A cost effective alternative to offshore development.” (p136.) The guidance was not to use Scrum with offshore developers! (The argument was the scrum made teams so efficient that you did not need to go offshore.) There was also a section called “Rules.” I realized that I broke just about every rule! I was young and impressionable, so I figured that even though Scrum was working so well, if I followed all of the rules, I would get even better results. So I decided to become a certified scrummaster.

After a lot of trial and error, I realized that it was best to break the rules. More on this in my next post. ;)

New to Agile? Having challenges implementing an agile process in your organization? Have you been using Scrum, but need to bend the rules to make it work in your organization? Can’t get the business to “buy-in”? Come and learn about implementing an agile process in your organization. You'll look at the “buffet table” of agile processes and procedures and learn how to properly decide “what to eat.” We’ll start by defining XP, Scrum, Kanban and some other popular methodologies and then learn how to mix and match each process for various scenarios, including the enterprise, ISVs, consulting, and remote teams. Then take a look at agile tools and how they will aid in implementing your development process. You’ll see how Microsoft Team Foundation Server 2010 provides process templates for Agile that facilitate better planning and metrics. Learn how Microsoft’s application lifecycle management (ALM) tools can support your development process. Lastly, we will talk about how to “sell” agile to your business partners and customers. The speakers have a very interactive style so participation is encouraged and there will be plenty of time for Q&A.

The Agile methodology has been adopted by many organizations around the globe. Unfortunately, many still struggle with the various methodologies (XP, Scrum, Kanban etc), and can’t settle on just one. While some organizations are successful in implementing Agile with the development teams, they tend to forget other vital parts of the process, mainly testing.

A session on how to choose which Agile methodology (or how to mix and match several pieces) to implement in your organization and how to do it.

Are you new to Agile? Have challenges implementing an Agile process in your organization? Have you been using Scrum, but need to bend the rules to make it work in your organization? Are you interested in using Kanban? What about XP? Can’t get the business “buy-in”? Come and learn about implementing an Agile process that suits all your organisational needs.

The “buffet table” of Agile processes & procedures session is aimed at learning how to properly mix & match each process, will cover:

Defining XP, Scrum, Kanban and some other popular methodologies.

How to implement a custom process for the enterprise, ISVs, consulting and remote teams?

How Agile tools aids in implementing your unique process?

How to “sell” Agile to your business partners and customers?

Seminar CoverageTime Slot

Free Registration9:00 am-9:55 am

Speaker Introduction9:55 am-10:00 am

Session on “The Agile Buffet Table”10:00 am-1:00 pm

This session dives into the value of Agile testing, how to use automated Agile testing tools and how your organization will benefit from Agile testing.

As more product teams move to Agile methodologies, the need for automated testing becomes essential to generate the velocity needed to ship fully tested features in short iterations.

The Session will cover:

The differences between traditional testing and Agile testing.

Exploring tools and strategies, that can help make your automation more productive as well as how to get the automation effort started for both new and existing Agile projects?

Stephen Forte is the Chief Strategy Officer of Telerik (A leading vendor of developer and team productivity tools, automated testing and UI components) also a certified scrum master. Involved in several startups, was the Co-founder of Triton Works (acquired by UBM in 2010), CTO and Co-founder of Corzen, Inc. (acquired by Wanted Technologies (TXV: WAN) in 2007). He also speaks regularly at Industry conferences around the world. He has written several books on application and database development including Programming SQL Server 2008 (MS Press). Prior to Corzen, Stephen served as the CTO ofZagat Survey in New York City and also was co-founder of the New York based software consulting firm The Aurora Development Group. He currently is a Microsoft MVP award recipient, INETA speaker and is the Co-moderator & founder of the NYC .NET Developer User Group.

Christopher Eyhorn is the Executive VP of Telerik’s automated testing tools division, where they build the next generation of automated testing tools. Formally Co-founder and CEO of ArtOfTest. He has written automation frameworks and functional testing tools and has worked in a variety roles ranging from developer to CEO within the company. Christopher has worked with a variety of companies ranging in size and Industry. He is a licensed pilot that loves to fly every chance he gets and truly appreciates the importance of hardware and software testing every time he takes off.

WHO SHOULD ATTEND?

Agile Buffet Table:The discussion is advantageous for professionals, using the Microsoft .NET platform as well as Product Managers, Technical Directors, Project Managers, Architects and Sr. Developers.

Agile Testing:Professionals interested in learning how to make their testing efforts more efficient as well as produce more automated tests at the end of each sprint as well as Project Managers, Software Quality Managers, Test/ QA Leads and Sr. Test Engineers.

Last night I spoke at the SofiaDev .NET User Group in Sofia, Bulgaria on Agile Estimation. We covered how my Bulgarian is horrible, all I know is “pull” and “push” (as in doors). After an introduction to the estimation problem, we talked about User Stories, Story Points, Planning Poker, a Product Backlog, Team Velocity, and re-estimation.

The Agile methodology has been adopted at many organizations. Unfortunately, many still struggle with the various methodologies (XP, Scrum, Kanban, etc) and can’t settle on just one. While some organizations do have successes is implementing Agile with the development team, they tend to forget other vital parts of the process, mainly testing. We will present two separate seminars, one on how to choose which agile methodology (or how to mix and match several pieces) to implement in your organization and how to do it. The second seminar dives into the value of Agile testing, how to use automated Agile testing tools, and how your organization will benefit from Agile testing.

New to Agile? Having challenges implementing an agile process in your organization? Have you been using Scrum, but need to bend the rules to make it work in your organization? Can’t get the business to “buy-in”? Come and learn about implementing an agile process in your organization. You'll look at the “buffet table” of agile processes and procedures and learn how to properly decide “what to eat.” We’ll start by defining XP, Scrum, Kanban and some other popular methodologies and then learn how to mix and match each process for various scenarios, including the enterprise, ISVs, consulting, and remote teams. Then take a look at agile tools and how they will aid in implementing your development process. You’ll see how Microsoft Team Foundation Server 2010 provides process templates for Agile that facilitate better planning and metrics. Lastly, we will talk about how to “sell” agile to your business partners and customers. The speakers have a very interactive style so participation is encouraged and there will be plenty of time for Q&A.

Afternoon Seminar: Agile Testing

As more product teams move to Agile methodologies, the need for automated testing becomes essential to generate the velocity needed to ship fully tested features in short iterations. In this session we will look at the differences between traditional testing and agile testing, explore some tools and strategies that can help make your automation more productive as well as how to get the automation effort started for both new and existing agile projects.

Seminar Coverage

Time Slot

Developer Event Registration

9:00-9:55

Speaker Introduction

9:55-10:00

Agile Development Event

10:00-1pm

Break

1pm-2:30pm

Agile Testing Event Registration

2:30-3pm

Speaker Introduction

3-3:10pm

Agile Testing Event

3:15-5pm

Conclusion of Program

5:00pm

WHO SHOULD ATTEND?

Agile Buffet Table: Developers and development managers, especially those using the Microsoft .NET platform.

Agile testing: any agile team member (dev or tester) that is interested in learning how to make their testing efforts more efficient as well as produce more automated tests at the end of each sprint.

FACULTYStephen Forte

Stephen Forte is the Chief Strategy Officer of Telerik, a leading vendor of developer and team productivity tools, automated testing and UI components. Stephen is also a certified scrum master. Involved in several startups, prior he was the co-founder of Triton Works, which was acquired by UBM in 2010 (London: UBM.L), and was the Chief Technology Officer (CTO) and co-founder of Corzen, Inc., which was acquired by Wanted Technologies (TXV: WAN) in 2007. Stephen also speaks regularly at industry conferences around the world. He has written several books on application and database development including Programming SQL Server 2008 (MS Press). Prior to Corzen, Stephen served as the CTO of Zagat Survey in New York City and also was co-founder of the New York based software consulting firm The Aurora Development Group. He currently is a Microsoft MVP award recipient, INETA speaker and is the co-moderator and founder of the NYC .NET Developer User Group. Stephen has an MBA from the City University of New York.

Christopher Eyhorn

Christopher Eyhorn is the Executive VP of Telerik’s automated testing tools division where he is building the next generation of automated testing tools. Formally co-founder and CEO of ArtOfTest, he has written automation frameworks and functional testing tools and has worked in a variety roles ranging from developer to CEO within the company. Christopher has worked with a variety of companies ranging in size and industry. He is a licensed pilot that loves to fly every chance he gets and truly appreciates the importance of hardware and software testing every time he takes off.

Last week I spoke at the first ever Professional Developer’s Summit in Bucharest, Romania. I delivered a keynote titled: “Agile Development for three screens and the cloud.” The summary of the session is that you can use Agile development methodologies to aid your transition to developing on multiple platforms. I went over:

I’m over in Zeist, the Netherlands speaking at the Software Developers Conference, put on by the Software Developer Network of the Netherlands. Back when this event was called CTTP, it was my first international speaking event in 1998. I’ve been speaking at this conference every year since 1998, only missing the event in 2000. I have spoken at three other events produced by SDN over the years besides the SDN/CTTP, so this is my 15th, yes 15th time speaking at this organization’s event in the Netherlands. I have no idea why they keep inviting, me, I usually show up to sessions with beer, go to the red light district instead of my talks, or make fun of Dutch people the entire time I am here.

This year I am speaking on RIA Services and doing an Q&A on Scrum and Agile. Hope to see lots of Dutch there!

DPR201 - Agile Estimation (Tuesday Nov 9th)

Track: Development Practices

We’re agile, so we don’t have to estimate and have no deadlines, right? Wrong! This session will review the problem with estimations in projects today and then give an overview of the concept of agile estimation and the notion of re-estimation. We’ll learn about user stories, story points, team velocity, and how to apply them all to estimation and iterative re-estimation. We will take a look at the cone of uncertainty and how to use it to your advantage. We’ll then take a look at the tools we will use for Agile Estimation, including planning poker, Visual Studio TFS and much more.

And also with Joel (though he is not listed on the session as the other speaker):

DPR301 - Scrum, but (Thursday November 11th)

Track: Development Practices

Having challenges implementing Scrum in your organization? Have you been using Scrum but need to bend the rules to make it work in your organization? Do you practice a little Scrum with a mix of Kanban? Then this session if for you! Come and learn about implementing Scrum, but with a few changes. We'll look at customizing Scrum in your environment and look specifically at how to implement Scrum for the enterprise, ISVs, consulting and remote teams.

A while ago I was asked by the publisher to be a tech editor of A Practical Guide to Distributed Scrum. Since agile luminaries like Ken Schwaber and Scott Ambler were also tech editors, I was honored to be chosen as well. Reviewing this book was a great experience and I have re-read the book since it was published (even thought I was paid to be a tech editor/reviewer, the publisher sent me a free copy when the book was published. Cool!)

You can learn a lot about using Scrum in a distributed environment from reading this book, it is the gold standard. If you have remote employees, off shore developers, or just a lot of offices where the product owner is in one location and the development team in another, this book is for you. The authors walk you through the process of setting up scrum in a distributed environment including planning, user stories, and the daily scrum. They give practical advice on how to deal with the problems specific to distributed teams using scrum, including most importantly communication and coordination. The authors are from IBM and show some of the techniques used at IBM with their remote employees, offices, and contractors.

I have been doing scrum in a distributed environment for almost 5 years now, and still learned quite a bit by reading this book. I encourage you to read it too.

I recently read Kanban by David J Anderson. David is credited with implementing some of the first Kanban agile systems at various companies. In Kanban, he gives a great overview of what Kanban is, how it grew out of the a physical manufacturing process at Toyota, and offers practical advice on how to implement Kanban at your organization. David also shows you how to set up a Kanban Board and provides several ways to model your system and manage the board.

In addition, David walks us through what the Lean movement is and how it relates to agile software development. He makes a very convincing case for tracking work in progress (WIP) and basing your system around that. Kanban attempts to limit WIP for better throughput. David freely admits that there is no actual scientific evidence as of yet that proves smaller WIP increases productivity and quality, however, he offers up his case studies as well as others.

What I found very helpful is that David reviews the popular Scrum agile methodology and pokes some holes in it. He shows some of the weaknesses of time boxing (the “sprint”), estimating, and the daily scrum and offers up alternatives via Kanban. David reminds us that agile is a set of values, not a set of rules. (Some people using Scrum today don’t like any change, they are so invested in Scrum that they forget that Scrum is about change.) Scrum forces you to throw out completely your current system and replace it with Scrum. Kanban allows you to keep your existing process and make changes, changes that revolve around communication, WIP, and flow. Kanban will let your current methodology evolve, not complete revolutionize it.

I used a crude, early version of Kanban a few years ago at my startup in New York. (A blog post will come on this next month.) I also used Scrum pretty extensively over the past few years and realize that neither system is perfect. Kanban is more flexible and Scrum (in my opinion) is easier to get estimates to managers who value “deadlines”. (What managers don’t?) There are strengths and weaknesses of both and David points this out in his book. A few people mix and match and use a “Scrum-ban” system. Personally I have seen the best success with Kanban and doing system maintenance and Scrum for greenfield start-ups with new teams.

If you are practicing any agile methodology or want to improve your current system, read Kanban. It is worth a try, even if you only implement a few ideas from the book.

Last Thursday I did a Scrum session at VSLive on Microsoft’s campus in Redmond, Wa. I lectured for about 30 minutes and then we went for a Q&A, just how I like it. Actually we really had a true conversation, people commenting on each other’s questions and comments, etc. Here is what we talked about:

The Microsoft Developer User Research team regularly does surveys of developers to provide feedback on processes, tools, initiatives etc. At the moment they are looking for Agile project managers and practitioners. Give your opinion! You can sign up to take a survey here.

People usually know Telerik for our individual developer productivity tools. With the release of TeamPulse yesterday, Telerik is entering the Agile ALM space and delivers team productivity tools to the market.

The idea for TeamPulse was hatched a long time ago at Telerik. It started when we realized that we had a lot of agile teams that compete in a very dynamic marketplace. Our teams at Telerik are agile, high performing, and need to rapidly react to new conditions. (I remember when we were building our Silverlight controls, each CTP/beta of Silverlight v 2.0 broke our code so deeply that we had to start over at each beta!)

As we acquired companies and added more product lines and divisions, we needed a better way to manage the projects, requirements, teams, resources, and iterations. Simply put, with close to 200 developers and many products in several categories, we needed an agile application lifecycle management (ALM) solution. We decided to build some tools with our partner Imaginet for internal use. We liked them so much, we decided to release them to the world about a year ago as the Work Item Manager and Project DashBoard. That is when we decided to build and bring TeamPulse to the world.

We wanted to bring a unique product to the market, a product for teams that lived up to the Telerik values of productivity and simplicity. A product that made it easy for agile teams to manage themselves. At its core, TeamPulse is an agile project management tool that focuses on collaboration. The core features of TeamPulse v1.0 are:

As I have written on this blog before, a true high performing team has to be both “high bandwidth” and transparent. TeamPulse helps the teams get there with its stress on ease of use, collaboration, and tracking/analytics. In addition, TeamPulse will help you be “more agile” and give you advice with the unique to the industry Best Practice Analyzer (BPA). The BPA is an engine that will examine your project data and help your team conform to certain agile characteristics. The cool thing is that you can bypass all of the rules that we ship and write and enforce your own!

We are very excited to bring you TeamPulse. I hope you find it as useful as our development teams do.

PS. TeamPulse is written in Microsoft Silverlight 4.0, so you can run it in any environment and out of browser. All you need is a Microsoft backend to host the product, your clients can be Windows or a Mac.

On Thursday, they lumped my “The Daily Scrum” talk on the Visual Studio and .NET track. While the title is The Daily Scrum, I will give some Scrum overviews and then open the floor to Q&A. All levels of participants will benefit from the talk. There will be zero discussion on Visual Studio 2010 and .NET 4.0. Actually, there will be no code at all.

In addition, I will be addressing the recent rift in the agile universe between the “pure” Scrum folks and the “Scrum, butters” which Ken Schwaber labels me. At the end of the talk, I will also address the rise of Kanban, an alternative agile methodology originating at Toyota in Japan. Kanban is quite popular here in Hong Kong where I live and I have seen it work at some very large global organizations as well as startups. Living in Asia over the last year has changed my perspective on agile and Kanban: I have seen how this Japanese invention works and can compliment a flexible agile strategy. I’ll weave this experience to my presentation. You won’t want to miss out.

Want to learn about TFS 2010 by doing nine application lifecycle (ALM) labs? You can download a Virtual Machine from Microsoft that has a full version of Windows and Visual Studio 2010 Team Foundation Server including nine labs. You can download it as Hyber-V, Windows 7 VPC or regular “old school” VPC. The VPC will not expire until Dec 31, 2010, but Microsoft promises to release another one before then.

A few months ago I wrote to you about why teams succeed. I talked about the “high bandwidth” team that stressed communication and collaboration. While I believe that communication and collaboration are the keys to success of any team, I always felt that there was another important component to the equation.

I visited a large retail global customer here in Hong Kong today. They are working on a large application for their product development group using Silverlight 4.0 and have teams in the United States, India, and Hong Kong. We were talking first about their use of Telerik tools and then the conversation moved on to teams and process. They are having success and are using the agile methodology Kanban. When I left, they were proud to show me their Kanban board with all of their user stories, tasks, features, and burn down.

That is when it hit me; the other component of highly successful teams is transparency. I started looking back throughout my career and looked at the high performing teams that had successful projects and the very successful ones were the ones that had the magic combination of high bandwidth and transparency.

I remember ten years ago building the original Zagat.com at the height of the .COM boom. We held “open staff meetings” where our weekly staff meetings were attended by other managers from around the company. Our own version of a Kanban board was posted outside the door of our main room. We were still using Microsoft Project and Gantt charts, each chart for each project was hanging outside of the room as well and updated daily. That level of transparency built trust with the organization and enabled us to work with the business closer.

I use to get pushback from the team about our transparency; the team did not like transparency when they were behind schedule. My argument was that we had to show the good, the bad, and the ugly. Besides, it is a well-known fact that we are motivated to work hard not by money, but by our creativity and the chance to produce something truly awesome. I figured that if we make that process more public and transparent, the employees would be even more motivated. By making our product development cycle public, the team took more pride in what they did since everyone was watching.

In addition, this process solved minor disputes between team members. Once when the VP of Marketing was at our open staff meeting, two developers were arguing over something petty. They forgot that the VP of marketing was there and later told me that they “looked bad” in front of the marketing VP. The next time I made sure that the founder of the company was at our staff meeting. Everyone on the team got the message and the transparency worked.

I was also very transparent with the business information coming into IT. I use to disseminate our monthly sales numbers (which were a closely guarded secret) to the whole department. The CEO asked me to stop since IT were the only people in the company besides the senior management to know this information. I responded with even more transparency and shared with the team our profit and loss information as well. (The CEO was not happy, but to her credit, she did not stop me.)

The Agile movement really helped push the importance of transparency forward. The very intention of the Scrum or Kanban board is to be public; same with the daily scrum meeting. If the business is engaged and attending your meetings, there is going to be more productivity and much less friction. Luminary Kent Beck wrote a white paper on agile tooling and teams where he stressed transparency. Beck says:

“When I started programming the weekly status report was sufficient. Here’s what I did this week, here’s what I’m planning to do next week. Press fast forward twice, though, and the weekly status report becomes as quaint as a debate about the relative merits of assembly language and higher level languages. … transparency is a choice you make to offer trustworthiness to you teammates. A transparent team can more cheaply and effectively coordinate their efforts towards shared goals. Acting transparently sends a signal to others that they can trust you. Trust, when realized, reduces the friction of development as people focus more on what they are accomplishing together and less on avoiding blame.”

Ten years after my experiences at Zagat, it is even easier to be transparent. There are many tools that help with transparency. Kent Beck also states in the white paper:

“One way out of the Reporting Dilemma is to stop explicitly telling people what you are doing. Instead, rely on your tools to infer your intentions from your activities and report that for you.”

Agile teams usually publish burn down charts and team velocity charts to report progress between iterations. In an effort to be both more transparent and more automated, the industry has moved to Agile Dashboards, dashboards that read from your repository and automatically publish your burn down and velocity charts as well as other vital information related to the iteration and build process (including my personal favorite, who broke the build.)

Several vendors offer an agile dashboard, such as i.e. Rally’s Team Status Dashboard, VersionOne, and of course Telerik. Our Agile Dashboard, a free tool, posts all the important details of a project on a dashboard for the whole world to see. This tool is meant to be on a large TV, hanging over the receptionist’s desk when you walk into a company complete the status of the current iteration, burn down charts, and even a photo of who last broke the build.

This decade will be remembered as the era when technology teams fully embraced transparency. As teams start to automate their transparency and look for ways to be more open, the quality of the software they produce will only improve. I look forward to this brave new (open) world.

We used an “Agile presenting” technique where we put the agenda in an “Agenda Backlog” and we reprioritized after every sprint (agenda item) and let the audience decide what we would talk about next. To our surprise the audience voted against two planned sections and we did two new sections on the fly. We talked about:

We got into a discussion on what happens when the team finishes early, do you stop the sprint, or give them more work to do. (Joel and I both go against the agile literature and give the team more work!)

We also took a few micro-breaks to rest our brain to talk about the iPhone v Android, how I buy Joel clothes, and movie quotes from the Matrix (I know Kung Fu) and What about Bob (Baby Steps).

We also recommended a book, one of my favorite management books of all time: Peopleware. For those of you non-techies reading this blog (I don’t know why!) if you manage teams, this book is also for you.

On Wednesday I presented an hour long talk on an introduction to Scrum, titled “To Scrum or not to Scrum” at the PMI’s Project Management Day in Bucharest, Romania. It was a great event and I presented Scrum from a project manager’s point of view. About 15% of the audience is not from the IT field and I also tried to present Scrum in a way that is more generic. (You can download the seminar slides here, they are the same slides I have used all year.)

I asked the audience to turn off their cell phones, but asked them to stand up and take my photo while they did it, so I took their photo at the same time. This is about half the room, sorry to the other half. :)

After the event I hung out with some of the PMI guys and walked down to a local restaurant/beer hall Caru Cu Bere in the historic old town (there was even a statue of Dracula there!) On the walk down I saw a Romania Arc de Triumph.

Agile project management and development methods are being adopted at many development shops. After an introduction to the basics of Agile and Scrum like: project planning and estimation, the Scrum Master, team, product owner and burn down, and of course the daily Scrum, Stephen, a certified scrum master, will show many real world applications of the methodology drawn from his own experience. Negotiating with the business, estimation and team dynamics are all discussed as well as how to use Scrum in small organizations, large enterprise environments and consulting environments. Stephen uses a very interactive style so participation is encouraged and there will be plenty of time for Q&A. This seminar is a jump start for preparing for a scrum master certification.

I will be presenting my half day Agile seminar this May in Sydney, Australia. I hope to see you there. I will also be speaking at the Sydney .NET User Group that evening on Silverlight 4.0 and giving out some Telerik swag.

One of the most popular Agile project management and development methods, Scrum is starting to be adopted at major corporations and on very large projects. After an introduction to the basics of Scrum like: project planning and estimation, the Scrum Master, team, product owner and burn down, and of course the daily Scrum, Stephen (a certified Scrum Master) shows many real world applications of the methodology drawn from his own experience as a Scrum Master.

Negotiating with the business, estimation and team dynamics are all discussed as well as how to use Scrum in small organizations, large enterprise environments and consulting environments. Stephen will also discuss using Scrum with virtual teams and an off-shoring environment. We’ll then take a look at the tools we will use for Agile development, including planning poker, unit testing, and much more. There will be plenty of time for Question and Answer. This seminar is a jump start for a certified scrum master exam.

While delivering the Agile Seminars in Pune, India and Taipei, Taiwan over the last week, the question of the development team came up. What started out as a discussion of Team Velocity, ended with a discussion of “Heroes” or “Rock Stars” on the team.

Too many managers think that you need a team of super human coders to get the job done. I think that while a team should have the most talented, motivated, and hard working members it can find, teams should avoid adding the “rock star developer” at all costs.

At the seminar I told the story of a real life story of a team I managed a number of years back. It was a team of good developers and one rock star. Let’s call our rock star developer John. John coded faster than all our team members, some tasks he could do two or three times faster. His code was usually pretty spot on, decently commented, and well thought out. Shouldn’t the entire team be made up of John clones?

Well while the number of lines of code per day developed by John was high, other things did not add up. At code reviews John would argue with other developers about the direction they took. When those developers were not around, John would check out their code and make small changes.

What really got me to my breaking point was John’s inability to see the big picture. Once someone from the business side came over and asked John to make a small change to the online shop by the end of the day. It was a Friday of a three day weekend and the marketing guy thought that he can push this change out and help our sales over the weekend. This change was not in the product backlog (well this was almost 10 years ago, it was more of a project plan back then) but John said he can sneak it in today. John was assigned other tasks that day, but figured that if he skipped lunch and stayed a little late, he could do both and be the hero.

It did not turn out that way. John bypassed our build and qa and production upload process and somehow managed to push his change to production without telling anyone. He figured that the business people would be happy with IT and life would be good. The problem was that this took him longer than expected (it always does, even for rock stars) and he had to skip is regular tasks.

The rest of the team was at a local bar we hung out at watching the Mets-Yankees game on TV. (I remember it was a rare occasion where the Mets beat the Yankees.) John was noticeably not there and we just thought he went home. Then my cell phone beeps, it was the founder of the company asking me why the online shop is down. I said I had no idea and would look into it immediately. I asked a dependable programmer to come with me and we went to the office to see what was up. Back at the office, the other programmer and I discovered John banging his head against his desk. After some heated words, the other guy and I reverted the site back to the original state. John pleaded and pleaded that he needed just 15 more minutes and that he was a “better coder than me.” While that may have been true, I said that my code always goes through QA. Against his wishes, I sent him home. John would have done better if he called in sick that day, by overpromising, he not only caused a problem with the site that caused two of us to fix, but he did not do his assigned tasks, making him behind in his work.

The next day I get an angry phone call from the VP of Marketing asking why the change was not pushed to production as he was “told by IT” it would be. The VP said that an email campaign was to be sent out telling customers about the change and it would be expensive to cancel it. I told the VP that I don’t care and to cancel it.

Needless to say the next week there were some fireworks at the office. I told John that he was like a cow who produced two buckets of milk while all the other cows produced only one bucket. But he also knocked over other cow’s buckets when he walked by. John thought he was right and I was wrong. That did not go well for anyone.

After the annual raise and bonus season went by and John was not “taken care of” in his mind (he was given the same modest raise and bonus the rest of the team received), he quit and took a job getting paid far more. He asked me what I would say when he used me as a reference. I told him:

“John is an A+ developer. Smart and fast. He is an F- team player. Overall that makes him a C+ developer.”

John never used me as a reference.

Rock stars have no place on a high performing team. Don’t confuse a rock star or “hero” with a very talented developer. A rock star is someone who, while talented, thinks that they are the ultimate guru and that everything should be done their way. Avoid them like the plague!

PS, about 5 years ago John asked me to lunch. It was the first time we spoke in many years. We made our peace and he admitted that he was wrong that day and looked forward to working together one day. I told him that if anyone asks for a recommendation today, I will let them know about our past difficulties and that he has evolved from a “Rock Star” to a great developer with perspective.

In an op-ed piece in this month’s SD Times, I make the argument that software development productivity tools have evolved over the years to become more mainstream. I make the case that while some developers shun tools, in reality they take for granted the tools they are using today that were not available 10 years or so ago, or were not that mature. For example today we use some tools without even thinking such as: SCM, build management, standards enforcement, ORM and UI components. Tools today save a team a tremendous amount of time and are the missing link in the software development process.

You can get the March issue of SD Times on the newsstands today or read my article online here.

I will be presenting a half day seminar on Agile Development, Tools and Teams on Wednesday at the MCCIA in Pune, India. The event is brought to you free by e-Zest, MCCIA, and Telerik.

The Program Details

One of the most popular Agile project management and development methods, Scrum is starting to be adopted at major corporations and on very large projects. After an introduction to the basics of Scrum like: project planning and estimation, the Scrum Master, team, product owner and burn down, and of course the daily Scrum, Stephen (a certified Scrum Master) shows many real world applications of the methodology drawn from his own experience as a Scrum Master. Negotiating with the business, estimation and team dynamics are all discussed as well as how to use Scrum in small organizations, large enterprise environments and consulting environments. Stephen will also discuss using Scrum with virtual teams and an off-shoring environment. We’ll then take a look at the tools we will use for Agile development, including planning poker, unit testing, and much more. There will be plenty of time for Question and Answer. This seminar is a jump start for a certified scrum master exam.

The story of human achievement is almost always one of teamwork. While we celebrate individual accomplishments, like Neil Armstrong stepping foot on the moon, it is always the team that makes or breaks the effort. I have always been interested in why teams succeed; it is easy to figure out why teams fail. A lot of time we think that we need a team of “Ninjas” in order to succeed, or a superstar team leader. In reality we need neither the Ninja team nor rock star team leader. For better or worse, I have been leading teams for a long time and I maybe a decent team leader now, but I was not early in my career-I have made every mistake in the book! Upon reflection of my past successes and failures I recently turned my attention to the question of why do teams succeed?

The problem with answering that question is that each team is different and even if you measure one team over a period of time, chances are that they worked on different projects or with different users, so it is difficult to get reliable observations. To gain some reliable observations you would have to observe one team working on virtually the same project, with virtually the same users, over a short period of time.

The good news is that I did just that. About 10 years ago during the .COM boom, I was the team leader of a team that was working on a website. (Surprise, surprise back then!) We worked on two short iterations (we did not call them that since this was before “Agile”) that were very similar in scope and requirements and worked for the same users. One iteration failed completely (the second one) and one was a smashing success (the first one). What was the key difference between these iterations? Everything was the same, the users and the developers got along, all key members were engaged, all the requirements were clear. What was different?

During the first and more successful project , I was on the “disabled list”. My ankle and leg were hurt while rock climbing and I had to walk around with a silly cane. (My doctor wanted crutches, but I refused.) It hurt to walk, even to stand, so I tended to stay put in one place at a time. As luck would have it, this company was an aspiring .COM, so they had leased a ridiculous amount of office space since they were going to hire 500 more people overnight. (Remember those days?) Since it hurt to walk, I usually just camped out with the business users at a spare desk.

Sometimes I overheard something the users would say that would affect the system and just butt on in that conversation. Sometimes they wanted to bounce things off my head and since I was right next to them, we had a lot of ad hoc meetings. This produced a better quality of communication. Studies have shown that there are thousands of communication "points" delivered with facial expressions and verbal tones/speech patterns. This gets lost in email, documents, etc.

Besides the close proximity to the business users, the development team would be around a lot too. While email was popular back then, I believed (and still do) that in-person communication is better, so I would not reply often to emails (especially vacation requests), forcing my introverted developers to ask me things face to face. This lead to other mini-meetings with the users and developers; business users would also overhead a team member coming to me lobbying to cut or add a feature and butt into that conversation with their perspective.

When the second project started, I was almost healed, so I tended to hang out in the IT department more often. (I also started to walk around with a baseball bat instead of a cane, that that would frighten people who did not know me.) As I said before the second project was a big failure and we later figured out that my leg was the only variable that had changed. For the next project iteration, we made it a rule to have a technology person sitting with the business team. (The guy who suggested this won the first shift with the users.) The collaboration between the business team and the technical team was the deciding factor and I have stressed team collaboration ever since, and my career has been the better for it.

You may be thinking that this is impossible in today’s day and age with distributed teams and rapidly changing requirements. The company I co-founded a few years back, Corzen, employed this strategy, even though we had a distributed team with both remote employees and overseas contractors. At our Corzen headquarters in New York City, we had our seating arrangements in an “open” style where the business team and the technology teams all sat together at desks right on top of each other alongside the sales team. While it at times did suck (like when my girlfriend would call and everyone could overhear our conversation), it paid many dividends. When the salesperson obviously lost a sale because of a lack of a feature that you lobbied against, it is far more powerful to hear the play by play in real time than getting an angry email from him later on.

Corzen had remote employees as well as overseas contractors, and we collaborated and communicated well with them. Of course we could not have them sit with us in the “bullpen” as we called it, but we did involve them on very frequent calls and webinars with our business team. The business team would make all of their documents available on a share or Google documents and over-share information instead of under-share. During the design phases the team would always communicate well and keep that communication going almost daily. New team members were inserted all the time and would come up to speed very rapidly. Of course the technical team held daily scrums using Skype and reported both ways (to the tech team and the business team) what was going on. This process was so successful that it lead to a great deal of success and Corzen was acquired by a larger entity based in another country and it still operates this way.

So if I have to sum it all up and answer the question why do teams succeed, the answer is pretty easy: communication, collaboration, and being “in the flow” of the emerging process. I have always known this, but my experiences described above enabled me to re-discover it. The best teams can finish each other sentences. Successful projects that I worked on had high bandwidth communication and extremely small feedback cycles. Success projects communicate and work "the way humans" should work - more face to face, more verbal. They also didn't rely up documentation to collaborate/communicate need/specification. Users don’t have all the answers, the requirements and features need to be discovered jointly by having a technical team member embedded with the users, or tools that mimic the fluidity of being together. Toyota perfected this process twenty years ago; the agile movement that started ten years ago was a recognition of this, so we have the knowledge of what works and what doesn’t work on projects. Embrace collaboration, communication, and work “the way humans” work (or mimic that fluidity if your team is remote) and you will have successful projects all the time.

Agile project management and development methods are being adopted at many development shops. After an introduction to the basics of Agile and Scrum, including: project planning and estimation, the Scrum Master, team, product owner and burn down, and of course the daily Scrum, certified scrum masters Stephen and Joel show many real-world applications of the methodology drawn from their own experience. Negotiating with the business, estimation, and team dynamics are all discussed as well as how to use Scrum in small organizations, large enterprise environments, and consulting environments. Next we discuss using Scrum with virtual teams and an off-shoring environment. We then take a look at some of the planning tools we will use for Agile Estimation, including planning poker, Microsoft Visual Studio Team Foundation Server 2010, and much more. We dive into some agile developer techniques such as TDD, Continuous Integration, and Dependency Injection, and round out the pre-con with a discussion on Agile developer tools and how they can help (and sometimes hinder) the development process. The speakers have a very interactive style so participation is encouraged and there will be plenty of time for Q&A. This seminar is a jump start for preparing for a scrum master certification.

I will be presenting a half day seminar on Agile Development, Tools and Teams on Wednesday February 24th at the MCCIA in Pune. The event is brought to you free by e-Zest, MCCIA, and Telerik. Seats are limited, to sign up in advance, please email seminar@e-zest.net.

The Program Details

One of the most popular Agile project management and development methods, Scrum is starting to be adopted at major corporations and on very large projects. After an introduction to the basics of Scrum like: project planning and estimation, the Scrum Master, team, product owner and burn down, and of course the daily Scrum, Stephen (a certified Scrum Master) shows many real world applications of the methodology drawn from his own experience as a Scrum Master. Negotiating with the business, estimation and team dynamics are all discussed as well as how to use Scrum in small organizations, large enterprise environments and consulting environments. Stephen will also discuss using Scrum with virtual teams and an off-shoring environment. We’ll then take a look at the tools we will use for Agile development, including planning poker, unit testing, and much more. There will be plenty of time for Question and Answer. This seminar is a jump start for a certified scrum master exam.

Who Should Attend

Developers and development managers, especially those using the Microsoft .NET platform.

Schedule and Agenda

Seminar Coverage

Time Slot

Event Registration

9:00-9:55

Speaker Introduction

9:55-10:00

Introduction to Agile Development and Scrum

10:00-11:00

Agile Estimation

11:00-11:30

High Tea Break

11:30-11:45

Implementing Scrum with remote and offshore teams

11:45-12:15

Agile Tools, Test Driven Development, and Continuous Integration

12:15-12:45

Summary, Question and Answer

12:45-1:00

Conclusion of Program

1:00

The Speaker

Stephen Forte is the Chief Strategy Officer of Telerik, a leading vendor in .NET components. He sits on the board of several start-ups including Triton Works and is also a certified scrum master. Prior he was the Chief Technology Officer (CTO) and co-founder of Corzen, Inc, a New York based provider of online market research data for Wall Street Firms. Corzen was acquired by Wanted Technologies (TXV: WAN) in 2007. Stephen is also the Microsoft Regional Director for the NY Metro region and speaks regularly at industry conferences around the world. He has written several books on application and database development including Programming SQL Server 2008 (MS Press). Prior to Corzen, Stephen served as the CTO of Zagat Survey in New York City and also was co-founder of the New York based software consulting firm The Aurora Development Group. He currently is an MVP, INETA speaker and is the co-moderator and founder of the NYC .NET Developer User Group. Stephen has an MBA from the City University of New York. Stephen currently lives in Hong Kong and will be returning to Mt. Everest again in September 2010.

Another Firestarter event is coming to the NY/NJ area! If you’ve been to any of the previousFirestarterevents, then you’ll know this one will be sure not to disappoint! Firestarter’s are a full day event where we focus on a single technology and take attendees from intro to guru in hours. The goal is for attendees to come away fired up and ready to start using the technologies or methodologies right away.

The Agile Firestarter in NYC that I helped plan and spoke at and back in June 2009 was super popular and a huge success and now it is time to have one in NJ! Are you just starting out with Agile, XP or Scrum and need to get up to speed? Or do you know a thing or two about Agile but want to learn the basics so you can implement it in your organization? Then this Firestarter is for you!

Registration just opened this morning (Nov 25th). There are a limited number of seats available for this event, so register quickly if you want in. Previous Firestarter events have all sold out! So do it before you head off for a turkey stuffed extended weekend! :)

Stephen BohlenCurrently a Senior Software Engineer for FirstPaper, LLC, a start-up in the world of digital media, Stephen brings his varied 15-year-plus experience as a former practicing Architect, CAD Manager, IT Technologist, Software Engineer, CTO, and consultant to the design and delivery of Software Engineering Solutions.Stephen is an active contributor to several Open-Source Software projects including NHibernate, NDbUnit, and others as well having developed a number of Visual Studio productivity add-ins. Active in the local NYC software development community, Stephen speaks publicly, blogs regularly, and is the author of several popular screencast series focused on Agile and ALT.NET concepts and technologies including the widely-praised 15-part Summer of NHibernate video series introducing viewers to the popular open-source O/RM tool and the Autumn of Agile series that takes viewers through the design, planning, and construction of an entire .NET project in an Agile context. He is also a contributor of a number of shorter screencasts available on Dimecasts.NET and elsewhere. Stephen is also a founding/organizing member of the NYC ALT.NET user group which meets monthly to discuss Agile-focused techniques and technologies in the world of Microsoft software development and beyond.

Jess ChadwickJess is an independent software consultant specializing in web technologies. He has over 9 years of development experience ranging from embedded devices in start-ups to enterprise-scale web farms at Fortune 500s. He is an ASPInsider, Microsoft MVP in ASP.NET, technical editor of the recently-released Silverlight 3 Programmers Reference (WROX) and leader of the NJDOTNET Central New Jersey .NET user group.

Sara ChippsSara is a developer specializing in web applications, an irreverent blogger at GirlDeveloper.com, and a writer for Datamation.com. She enjoys participating in and organizing community events such as Code Camps and most recently NJ Tech Drinks and Concept Camp, an opportunity for nerds to go camping together.

Peter LaudatiPeter Laudati, the "JrzyShr Dev Guy," is a Developer Evangelist with Microsoft, based in the New York/New Jersey area. One of his roles is supporting and educating Microsoft customers working with the .NET development platform. Peter supports the community of .NET developers in the NY Metro area by speaking at user group events and Code Camps. Peter is also the co-host of the “Connected Show”, a new podcast covering Microsoft technology with a focus on interoperability. His blog can be found at http://www.peterlaudati.com.

Todd SnyderTodd is a MCSD in .Net and a MCTS in SharePoint & Biztalk. He works in the Infragistics Experience Guidance Group (XDG) as the developer team lead. In his role as the XDG developer team lead Todd is responsible for making sure the samples include with Net Advantage showcase the capabilities of the product and help educate developers on how to tap into those capabilities. Prior to joining Infragistics Todd spent several years working as consultant helping customers build enterprise .Net applications.

Joel and I are doing a BOF session on Tuesday about Agile tools and Teams. (I am not listed on the PDC web site for some reason, but I will be there alongside Joel.)

We will most definitely show the Telerik Dashboard and Work Item Manager as well as chat about tons of other great tools. Most importantly, we want to hear from you at this session. We did it that way at TechEd in LA earlier this year (the #1 ranked interactive session at TechEd 2009) and it worked well. Hope to see you there and have a great discussion.

Agile practices focus on customer value and team interactions. There is significantly growing and important set of tools that work to help Agile teams be more “agile”. In this session, we would like to hear what you have to say about tools for Agile teams? What tools work? What tools don’t work? What tools are missing in the industry? What tools can you not live without? Come join the discussion or simply listen to what your peers have to say.

Are you just starting out with Agile, XP or Scrum and need to get up to speed? Or do you know a thing or two about Agile but want to learn the basics so you can implement it in your organization? Then this Firestarter is for you. We’ll take you from 0 to 60 in 8 hours. Bring a laptop with Visual Studio 2008 Express edition or better for an all day hands on seminar led by some of the NY area’s Agile practitioners.

Next week at TechEd Europe I will be doing two talks on Scrum (with one repeat) and we are trying something new at TechEd this year, so let me know what you think.

The talk on Tuesday, DVM309: Using Scrum to Run Your Projects, is a typical TechEd breakout session in lecture format with Q&A encouraged. I’ll go through slides and examples from my experience as a scrum master (and also share some of my experiences from the certified scrum master class.) This is a good overview of Scrum good for beginners or experienced scrum masters trying to scale out scrum.

On Tuesday and Friday we turn the tables in DVP04-IS: The Tech*Ed Daily Scrum! This is an interactive session where I will be passing around a microphone and it will be 100% Q&A, war stories, and interactive, no slides if I can help it. (Come on, ask a lot of questions, tell a lot of war stories make my week a little easier!) I have done the “Daily Scrum” talk about 10 times this year in several places (New York, TechEd US in Orlando, Egypt, Pakistan, Netherlands, Bulgaria, Serbia, Connecticut .NET User Group, etc) and every time it is different and exciting. I always learn something from the audience as well. Everyone is welcome, you will see how Scrum works in the real world as well as real life implementations. Since it is mostly interactive, it is great for people who want to learn about scrum, as well as experts in Scrum. My only rule is no religious warfare, other than that, anything goes! (Just ask the Serbians, it was also the last session of their conference and we all drank beer as we did the Q&A.)

See you all there… If you can’t make it, I hope they will film it and put it online.