# Sunday, December 02, 2012

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.

IMG_20121127_151312

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.

IMG_20121128_150703

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). Smile We will see if he buys a pair of jeans this weekend.

IMG_20121130_135744

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.

IMG_20121201_101751

Week 5 is also a busy week, stay tuned for more progress.

posted on Sunday, December 02, 2012 5:46:14 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Thursday, November 15, 2012

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. Smile Details are below, register today, space is limited (only about 30 seats left)!

EventBrite Link to register: http://agiletour2012hongkong.eventbrite.com

AGILE TOUR 2012 COMING TO HONG KONG DECEMBER 1, 2012

Welcome all,

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 teams
Speaker : Emerson Mills
Abstract:

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.

  1. Why did we even use them?!
  2. Distribute teams not people
  3. Giving teams ownership of features and not tasks
  4. Sharing a product development culture

Title: Inject start up spirit
Speaker: Wang XiaoMing
Abstract:

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.

  1. A real project, double velocity
  2. The pain of founders
  3. Inject start up spirit
  4. Lightweight Agile.

Title: Test Driven Development
Speaker: Ian Lucas
Abstract:

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.

  1. TDD in context
  2. Defining Success criteria upfront (i.e. Test Cases as requirements specifications)
  3. Practical examples of TDD with XQuery and XQunit

Title: Agile ate my Project Plan!
Speaker: Michael Mallete
Abstract:

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 techniques
We will then counter that with the assumptions behind Agile estimation and planning
We will show the different features of traditional estimation and planning
We will then show the different features of Agile estimation and planning
We 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: TBD
Abstract:

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!

Intended Audience

  • IT professionals already experienced in Agile or thinking about moving to Agile (Developers, Testers, Business Analysts, Project managers, Scrum Masters, Product Managers / Owners etc.)

  • Managers responsible for Agile Development or in future likely involved in Agile

  • Anyone interested in Agile

How to register

Through EvenBrite. Register Early to avoid disappointment.

Regular: 75 HK$

Price on day self – provided there are still seats: 100 HK$

EventBrite Link: http://agiletour2012hongkong.eventbrite.com

Date
Saturday, December 1, 2012, 9am – 5pm, with lunch break from 12-1:30.
There will be time to meet speakers after 5pm.

Location

Cocoon, Causeway Bay, close to MTR and various lunch locations with local or international food.

http://www.hkcocoon.org/en/index.aspx

Transportation

  • Tin Hau MTR Exit A2 (10 mins walk)
  • Fortress Hill MTR Exit A (7 mins walk)
  • From Hong Kong Island, take Route 5X or 5 Bus straight to the final station
  • From Kowloon, take Route 118 Bus, get off the bus at Gordon Road station (3 mins walk)
  • From Airport, take Route A11 Bus, get off the bus at Gordon Road station (3 mins walk)

Supporting Organizations

posted on Thursday, November 15, 2012 8:53:13 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Wednesday, September 05, 2012

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.

image

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.

posted on Wednesday, September 05, 2012 7:21:32 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Tuesday, July 24, 2012

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.

image

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. Smile) 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.

image

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.

image

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.

posted on Tuesday, July 24, 2012 4:34:15 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Monday, July 23, 2012

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. Smile 

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.

image

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.

posted on Monday, July 23, 2012 6:41:46 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [3] Trackback
# Friday, December 23, 2011

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.

posted on Friday, December 23, 2011 9:10:17 PM (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback
# Monday, December 05, 2011

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.

posted on Monday, December 05, 2011 7:10:15 PM (Eastern Standard Time, UTC-05:00)  #    Comments [1] Trackback
# Tuesday, November 22, 2011

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.

I hope to see you at the Hong Kong Convention Center, but if not, my slides are posted below.

posted on Tuesday, November 22, 2011 5:23:53 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Tuesday, November 01, 2011

Today I will be speaking at the 1st World CIO Forum held in booming city of Shenzhen, China sponsored by the International Federation for Information Processing.

image

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.

posted on Tuesday, November 01, 2011 10:52:19 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Monday, October 31, 2011

This week I will be attending and speaking at the 1st World CIO Forum held in booming city of Shenzhen, China sponsored by the International Federation for Information Processing.

image

The theme of the World CIO Forum is: Globalization and IT Innovation. Topics include: cloud computing (of course!), mobile innovation, green IT, CIO Leadership, “manufacturing 2.0” (my track), and e-government.

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.”

posted on Monday, October 31, 2011 10:11:32 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Tuesday, October 18, 2011

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.

posted on Tuesday, October 18, 2011 2:36:57 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [2] Trackback
# Monday, August 22, 2011

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 Tracks
At 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
PMI Professional Development Units Provided!

Are you keeping your PMI Certification current and looking to aquire Continuing Certification Requirements credits (http://www.pmi.org/Certification/Maintain-Your-Credential.aspx)?  This event offers six PDU's from PMI for attending!

Sessions and Speakers
This event features a great mix of national, regional, and local-area speakers with wide and deep Agile experiences to share!
Sessions include:

  • What is Agile and Why Should I Care? (Steve Bohlen)
  • The Testing Pyramid (Nancy Chacko)
  • Intro to Kanban (Jon Mills)
  • Selling Agile Into Your Organization (John Petersen)
  • Agile Teams - From Good To Great (David Bulkin)
  • Making Distributed Teams Work - Effectively, Even (Jim Holmes)
  • Help! There's a waterfall in my Sprint (Jim Schiel)
  • 5 Dysfunctions of Agile Teams (Bob Hartman)
  • Agile Project Owners - What Ails Them (Anupam Kundu)
  • Risk Adjusted Release Planning (Bob Hartman)
  • Introduction to Test Driven Development (James Bender)
  • Beyond Metrics (Andre Dhondt)
  • Enterprise Agility (Philip Japikse)
For a complete schedule for each track, see http://dayofagile.org/agenda
Registration Details

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.com
Register 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.

posted on Monday, August 22, 2011 8:43:18 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Monday, August 08, 2011

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.)

IMG_20110806_123850I 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.”

IMG_20110806_123858

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. Winking smile

posted on Monday, August 08, 2011 3:33:04 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [1] Trackback
# Friday, June 03, 2011

They Keynote on Kanban I did at both the PMI day and ITCamp in Romania as well as the TechEd North America breakout session is available on slideshare. Enjoy!

posted on Friday, June 03, 2011 12:02:42 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [1] Trackback
# Friday, April 22, 2011

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. Winking smile

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

Also had some books to take a look at, they came up at various points in the discussion, check out any one of them:

posted on Friday, April 22, 2011 10:54:04 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [2] Trackback
# Friday, April 01, 2011

See also:

·         Part I: How I started to use Scrum

·         Part II: Scrum, but

·         Part III:  Moving away from Scrum

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.

clip_image001

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.

posted on Friday, April 01, 2011 10:02:49 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Friday, March 25, 2011

See also:

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.)

Next, we’ll take a high level look at Kanban.

posted on Friday, March 25, 2011 3:25:15 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Wednesday, March 16, 2011

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.

The slides are below (via slideshare).

posted on Wednesday, March 16, 2011 1:45:05 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Monday, March 14, 2011

See also:

·         Part I:  How I started to use Scrum

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.)

posted on Monday, March 14, 2011 1:15:28 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Wednesday, March 09, 2011

clip_image001

 

Telerik Australia event: Focus on Developer Productivity

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.

 

The Agile Buffet Table: Implementing your own Agile Process  with Microsoft ALM Tools

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.

PRESENTERS:

Stephen Forte, Chief Strategy Officer of Telerik

Tuesday, March 15, 2011 9:00 AM - 12:00 PM (GMT+1000)

REGISTER NOW

(by invite only event, use password: Telerik&&ALM2)

Location:

Citigate Central Sydney

169-179 Thomas Street

Haymarket, NSW

Sydney, 2000

  Joel Semeniuk, Founder of Imaginet Resources,

                 Microsoft Regional Director

All attendees will receive a copy of Telerik JustCode, valued at $199.


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.

PRESENTER:

Christopher Eyhorn, Executive VP of Telerik’s automated testing tools division

Tuesday, March 15, 2011 2:00 PM - 5:00 PM (GMT+1000)

REGISTER NOW

(by invite only event, use password:TestingTelerik)

Location:

Citigate Central Sydney

169-179 Thomas Street

Haymarket, NSW

Sydney, 2000

All attendees will receive a copy of Telerik JustCode, valued at $199.


20 Things to Consider When Selecting a CMS

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

Tuesday, March 15, 2011 9:00 AM - 12:00 PM (GMT+1000)

REGISTER NOW

(by invite only event, use password:TelerikAustralia)

Location:

Citigate Central Sydney

169-179 Thomas Street

Haymarket, NSW

Sydney, 2000

All attendees will receive a copy of Telerik JustCode, valued at $199.


Streamline Development with ASP.NET MVC Extensions

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.

PRESENTER:

Jordan Knight, Solution Architect | Microsoft MVP - Silverlight

Tuesday, March 15, 2011 2:00 PM - 5:00 PM (GMT+1000)

REGISTER NOW

(by invite only event, use password: DevelopersRock)

Location:

Citigate Central Sydney

169-179 Thomas Street

Haymarket, NSW

Sydney, 2000

All attendees will receive a copy of Telerik JustCode, valued at $199.

posted on Wednesday, March 09, 2011 3:52:17 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Tuesday, March 08, 2011

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. ;)

posted on Tuesday, March 08, 2011 5:47:34 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Friday, March 04, 2011

I’ll be speaking in Sydney on Tuesday March 15th on building your own Agile methodology.  As usual, Joel will be joining me.

The Agile Buffet Table: Implementing your own Agile Process  with Microsoft ALM Tools

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.

Register now and get a free copy of JustCode ($199 value!)

Tuesday, March 15, 2011 9:00 AM - 12:00 PM (GMT+1000)

REGISTER NOW (by invite only event, use password: Telerik&&ALM2)

Location:

Citigate Central Sydney

169-179 Thomas Street

Haymarket, NSW

Sydney, 2000

posted on Friday, March 04, 2011 1:39:42 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Wednesday, January 12, 2011

Making Agile Development work in your organization

Telerik & e-Zest Solutions Ltd. invites you for Two Free Seminars:

Agile Development

INTRODUCTION

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.

Implementing your own Agile Process Seminar at Pune, India

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 Coverage
Time Slot

Free Registration
9:00 am-9:55 am

Speaker Introduction
9:55 am-10:00 am

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

Agile Testing Seminar at Pune, India

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?

Seminar Coverage
Time Slot

Free Registration
2:30 pm-2.50 pm

Speaker Introduction
2.50 pm-3.00 pm

Session on “Agile Testing”
3:00 pm–5:00 pm

Conclusion of Program
5:00 pm

SPEAKERS

Stephen Forte

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

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.

Date & Time:

Tuesday, January 18th 2011
Agile Buffet Table, from 9:00 am – 1:00 pm
Agile Testing, from 2:30 pm – 5:00 pm

Venue:

Sumant Moolgaokar Auditorium, Ground floor,
MCCIA Trade Tower, ICC Complex, 403,
Near Senapati Bapat Road, Pune

Pre-registration: Mandatory

Kindly confirm your participation immediately by sending us your contact
details on seminar@e-zest.net

e-Zest Help line number: 020–25459802/03/04

e-Zest Solutions Ltd. (www.e-zest.net) is a CMMI Level 3 & ISO 9001:2008 certified, Product Engineering and Enterprise Solutions provider, focused on solutions and services based on Microsoft .NET (3.0/3.5/4.0), Sun Java EE (5.0) & LAMP. e-Zest is also Telerik Sales & Training India partner, a Microsoft Gold Certified Partner and Sun Associate Partner.

Telerik (www.telerik.com), is a leading vendor of ASP.NET AJAX, ASP.NET MVC, Silverlight, WinForms & WPF controls & components, as well as .NET Reporting, .NET ORM , .NET CMS, TFS, Code Analysis & Web Application Testing Tools. Building on its expertise in interface development & Microsoft technologies.

posted on Wednesday, January 12, 2011 1:34:00 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Friday, January 07, 2011

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.

Slides are here:

posted on Friday, January 07, 2011 9:54:57 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Wednesday, December 15, 2010

Telerik and e-Zest will be sponsoring two Agile seminars on January 18th at the MCCIA in Pune, India. Hope to see you there!

Seminars on
Agile Development and Testing
Tuesday January 18th 2011 @ MCCIA, Pune

e-Zest logo CMMI 


INTRODUCTION

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.

Morning Seminar: The Agile Buffet Table: Implementing your own Agile process

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.

FACULTY
Stephen 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.

posted on Wednesday, December 15, 2010 8:51:21 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Monday, December 13, 2010

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:

  • What Agile is, the Agile Manifesto
  • Scrum 101
    • Why I wear a Rugby Jersey when I speak about Scrum
  • Agile Estimation
  • The Cone of Uncertainty
    • A drinking game around the cone of uncertainty
  • Developing with remote teams
  • That Rugby has a position named after the US English slang for a prostitute: hooker
  • Agile uses at Telerik
  • How my friends use Wikipedia against me Winking smile

Slides are here:

posted on Monday, December 13, 2010 6:22:02 AM (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback
# Monday, October 25, 2010

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!

posted on Monday, October 25, 2010 9:55:34 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Tuesday, October 12, 2010

I will be speaking this year at TechEd Europe in Berlin, Germany from November 8th to November 12th. I’ll be doing two talks:

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.

See ya there!

posted on Tuesday, October 12, 2010 11:29:53 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Wednesday, August 25, 2010

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

8-25-2010 6-20-37 PM

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.

posted on Wednesday, August 25, 2010 6:50:07 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [1] Trackback
# Tuesday, August 24, 2010

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.

image

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.

posted on Tuesday, August 24, 2010 3:35:54 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Monday, August 09, 2010

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 Agile Manifesto and how it is just four items
    • The Agile Manifest is about values, not rules
    • The values of the Agile movement: communication, delivering business value, collaboration, embracing change
    • How some agile practitioners are not really agile, they forgot the core values and are too rigid
  • Other agile methodologies like XP and Kanban
  • Where scrum came from: Japan and Harvard Business Review (1986)
  • The Scrum 101 stuff: the daily scrum, iterations, the team, backlogs
  • The world’s greatest project management tool: Microsoft Excel
  • A little on velocity and agile estimation
  • A lot on testing, where to put testers
    • One guy had his testers outside of the sprint-and it worked for him
    • One guy thought about staggering the testers one week behind the dev sprint (we had mixed reviews on that)
  • It is ok to change Scrum!
    • How the inventor of Scrum wants my head for that bullet ;)
    • The best approach is a “buffet table
  • Lean processes at Toyoda and how it relates to software development (a la  Kanban)

Glad that we had a conversation rather than a straight lecture.

posted on Monday, August 09, 2010 8:41:18 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Friday, July 30, 2010

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.

posted on Friday, July 30, 2010 3:17:58 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Wednesday, July 28, 2010

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!

image

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.

posted on Wednesday, July 28, 2010 6:25:33 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [2] Trackback
# Monday, July 26, 2010

Next week, I will be speaking at VS Live! at Microsoft’s campus in Redmond, Washington. I will be doing two talks.

Wednesday, on the data track, I will be following Chris Selles’ Entity Framework and OData and Database Projects and Jon Flanders’ Building RESTful Services Using Windows Communication Foundation talks with my own: Building RESTful Applications with the Open Data Protocol, so I will skip the “What is REST” slides up front and just start coding. ;)

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.

image

posted on Monday, July 26, 2010 9:53:51 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Monday, July 12, 2010

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.

Check out this  blog for more details.

posted on Monday, July 12, 2010 10:19:57 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Monday, June 28, 2010

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.

clip_image001

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.

clip_image002

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.

posted on Monday, June 28, 2010 1:44:44 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Monday, June 07, 2010

Yesterday Joel and I did the day long Agile precon at TechEd in New Orleans, LA. We had a great crowd and were able to keep them engaged for 8 hours. You can download the materials here.

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:

  • Agile theory and agile methodologies (XP, Scrum, FDD, DSDM, *DD, Kanban, etc)
  • Intro to Scrum
  • Agile Estimation
  • Challenges to Implementing Agile in General
  • Challenges to Implementing Agile: In the Enterprise
  • Challenges to Implementing Agile: Remote Teams
  • Tools
  • QA and Documentation

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.

Hope to do this seminar again soon!

posted on Monday, June 07, 2010 12:04:51 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [1] Trackback
# Thursday, May 27, 2010

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. :)

IMG_20100526_102552

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.

IMG_20100526_200314

Looking forward to my next visit!

posted on Thursday, May 27, 2010 2:49:05 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Wednesday, May 05, 2010

I’ll be doing my (in)famous Scrum seminar in Bucharest, Romania on May 26th at Project Management Day, hosted by PMI and Microsoft. My talk is titled “To Scrum or not to Scrum.”

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.

See you there.

posted on Wednesday, May 05, 2010 3:40:26 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Friday, March 12, 2010

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.

Half-day Agile Seminar
Wednesday 19th May 2010
9:00am - 12:00pm
SSW Office, Sydney
Suite 10, 81-91 Military Road, Neutral Bay
Cost: No Charge

 SharePoint

Agile Development, Tools and Teams

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.

Agenda

  • Introduction to Agile Development and Scrum
  • Agile Estimation
  • Implementing Scrum with remote and offshore teams
  • Agile Tools, Test Driven Development, and Continuous Integration
Technorati Tags:

Bookmark and Share
posted on Friday, March 12, 2010 4:21:06 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Friday, March 05, 2010

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.

Technorati Tags:

Bookmark and Share
posted on Friday, March 05, 2010 11:12:01 PM (Eastern Standard Time, UTC-05:00)  #    Comments [5] Trackback
# Wednesday, March 03, 2010

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.

Technorati Tags:

Bookmark and Share
posted on Wednesday, March 03, 2010 3:09:36 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Friday, February 26, 2010

We had a great Agile seminar yesterday in Pune, India. You can download the seminar slides here.

A special thanks to Telerik, the Mahratta Chamber of Commerce, Industries and Agriculture and the team from e-Zest for planning such a successful event. Usually as the speaker I get all the glory, so here is the photo of me with the folks who made it happen, they deserve the glory:

image

Technorati Tags: ,

Bookmark and Share
posted on Friday, February 26, 2010 3:37:27 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Sunday, February 21, 2010

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. 

To register: please email seminar@e-zest.net.

posted on Sunday, February 21, 2010 11:59:02 AM (Eastern Standard Time, UTC-05:00)  #    Comments [1] Trackback
# Monday, February 15, 2010

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.

 

Technorati Tags:

Bookmark and Share

posted on Monday, February 15, 2010 2:46:36 PM (Eastern Standard Time, UTC-05:00)  #    Comments [4] Trackback
# Saturday, February 06, 2010

Check out my pre-con at TechEd North America, Joel and I will be speaking on Agile. Register here. :)

PRC07 The Agile Methodology Demystified: Implementing Agile in Your Organization

Track: Development Practices

Speaker(s): Joel Semeniuk, Stephen Forte

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.

 

Technorati Tags:

Bookmark and Share
posted on Saturday, February 06, 2010 3:56:32 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Thursday, January 21, 2010

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. 

Final Details

DATE

Wednesday February 24th, 2010

TIMING

9.00 am to 1.00 pm (registration from 9.00 a.m. to 9.45 a.m.)

VENUE

Shekhar Natu Hall, MCCIA, 403-A,Senapati Bapat Road, Pune 411 016

FEE

Free

 

Technorati Tags: ,
posted on Thursday, January 21, 2010 1:59:34 AM (Eastern Standard Time, UTC-05:00)  #    Comments [1] Trackback
# Tuesday, November 24, 2009

NJAgileFirestarter

Another Firestarter event is coming to the NY/NJ area!  If you’ve been to any of the previous Firestarter events, 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!

REGISTER HERE!!!

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

When

Saturday, December 12, 2009 from 8:30 AM - 5:00 PM (ET)

Microsoft Office - Iselin, NJ
Microsoft Office - Iselin, NJ

Where

Microsoft Office (Iselin)
194 Wood Avenue South (Prudential Building)
Sixth Floor
Iselin, NJ 08830

The Agenda:

  • Introduction to Agile
    A high-level introduction to Agile concepts and values from the software developer's perspective.
  • SOLID:  OO Principles
    This presentation will examine the five key design principals used on agile project and how to use them to build out an adaptive system over several cycles.
  • Test-Driven Design & Development
    An introduction to Unit Testing and Test-Driven Development, showing how this approach helps keep your code adaptable to change
  • Agile Estimation & SCRUM
    An overview of the concept of agile estimation and the notion of re-estimation
  • Domain Driven Design
    An introduction to the core principles for applying a Domain Driven Design approach and how it fits into the agile development life cycle.
  • Continuous Integration
    This session shows how to centralize your quality assurance efforts and help keep developer productivity high (and defect count low!)

The Presenters:

  • Stephen Bohlen
    Currently 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 Chadwick
    Jess 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 Chipps
    Sara 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 Laudati
    Peter 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 Snyder
    Todd 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.
Technorati Tags:

  Technorati Code: YJQU3Z2SWF46

posted on Tuesday, November 24, 2009 5:39:35 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Monday, November 16, 2009

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.

Tooling on Agile Teams

Joel Semeniuk in 309 on Tuesday at 3:00 PM

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.

See you there!

image

posted on Monday, November 16, 2009 1:54:14 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Monday, July 06, 2009

Last week I did the Agile Estimation session at the NYC Agile Firestarter. Thanks to Alex Hung for taking the video and posting it!

Some back story: all the presenters were trying to out do each other in making up words. :)

Agile Estimation from Alex Hung on Vimeo.

posted on Monday, July 06, 2009 9:05:04 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Wednesday, June 03, 2009

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.

When: Saturday June 27th

Where:

Kaye Scholer LLP
425 Park Avenue
New York, NY 10022

Time: Registration and welcome 8:30am

Cost: $8 (to cover the pizza and materials)

To Register: http://agilefirestarter2009.eventbrite.com

Agenda:

• Registration and Welcome

• Intro to Agile (Steve Bohlen)

• Agile Estimation (Steve Forte)

• Test Driven Development (Steve Bohlen)

• Pizza!

• Continuous Integration (Alex Hung)

• Refactoring (Mark Pollack)

• Dependency Injection (Mark Pollack)

• Retrospective Erik Stepp

• Wrap up

Register today, space is limited! More info is here: http://www.agilefirestarter.net

posted on Wednesday, June 03, 2009 5:28:22 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Thursday, November 06, 2008

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.

posted on Thursday, November 06, 2008 8:20:19 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback