# Friday, June 3, 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 3, 2011 12:02:42 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [1] Trackback
# Friday, May 13, 2011

Next week I will be headed to Atlanta, Georgia, for my 10th TechEd North America, and my 21st TechEd of my career worldwide. I will be doing three breakout sessions this week, all on the agile methodologies.

There are over 200 sessions at TechEd, however, my Agile Estimation session, so popular last year at TechEd Berlin, will be live streamed, so if you can’t join me in Atlanta, join me on the live stream, it will be fun. Here are all of my sessions.

DPR202 | Agile Estimation (Live Streamed)

Breakout Session | 200 - Intermediate | Development Practices & Architecture

Speaker(s): Stephen Forte

Tuesday, May 17 | 10:15 AM - 11:30 AM | Room: C305


DPR306 | The Agile Buffet

Breakout Session | 300 - Advanced | Development Practices & Architecture

Speaker(s): Joel Semeniuk (This is listed at Joel’s session, but we are doing it together)

Wednesday, May 18 | 10:15 AM - 11:30 AM | Room: B309


DPR203 | Yes, We Kanban!

Breakout Session | 200 - Intermediate | Development Practices & Architecture

Speaker(s): Stephen Forte (This is listed as my session, but Joel is doing it with me)

Thursday, May 19 | 1:00 PM - 2:15 PM | Room: B309

posted on Friday, May 13, 2011 9:17:59 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Thursday, May 12, 2011

Thursday, May 19, 2011
Building N-Tier Applications With Entity Framework 4

You must register at https://www.clicktoattend.com/invitation.aspx?code=155176 in order to be admitted to the building and attend.
The first version of the Entity Framework (EF) did not support entity objects detached from the object context, making it difficult or impossible to use EF in any serious n-tier application. The situation is vastly improved with the release of .NET 4 and the new Entity Framework, which supports a number of strategies that enable and simplify n-tier development. In this demo-packed session, Lenni will show you how to work with EF in disconnected and service-oriented architectures. You’ll see a number of scenarios up close, along with the code that makes it work. We’ll begin with simple cases of attaching disconnected objects to the context, and then move on to richer scenarios involving basic WCF services, and higher-level abstractions with WCF Data Services and WCF RIA Services. You’ll also learn how to create POCOs (plain old CLR objects) and Self-Tracking Entities using the specialized T4 templates now available in Visual Studio 2010. Attend this talk, and learn how to build n-tier applications with Entity Framework 4 today!

Leonard Lobel, Sleek Technologies
Leonard Lobel is the chief technology officer (CTO) and co-founder of Sleek Technologies, Inc., a New York–based development shop with an early adopter philosophy toward new technologies. He is also a principal consultant at Tallan, a Microsoft National Systems Integrator. Programming since 1979, Lenni specializes in Microsoft-based solutions, with experience that spans a variety of business domains, including publishing, financial, wholesale/retail, health care, and e-commerce. Lenni has served as chief architect and lead developer for various organizations, ranging from small shops to high-profile clients. He is also a consultant, trainer, and a frequent speaker at local usergroup meetings, VSLive, SQL PASS, and other industry conferences. Lenni is also lead author in the new MS Press book "Programming Microsoft SQL Server 2008". He can be reached at lenni.lobel@tallan.com.

Thursday, May 19, 2011

Reception 6:00 PM , Program 6:15 PM

Microsoft , 1290 Avenue of the Americas (the AXA building - bet. 51st/52nd Sts.) , 6th floor

B/D/F/V to 47th-50th Sts./Rockefeller Ctr
1 to 50th St./Bway
N/R/W to 49th St./7th Ave.

posted on Thursday, May 12, 2011 8:50:58 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] 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
# Thursday, April 14, 2011

Next week I will be speaking at the 4th Great Indian Developer Summit (GIDS) in Bangalore, India. I have spoken at the last three GIDS and really enjoy the “ninja” speaking style: 50 minute sessions! So my technical sessions will be all code/demo, no slides, only the “please fill out the evaluation” slide at the end. Here are my sessions:

Tuesday April 19th, .NET day:

  • Building RESTful Applications with the Open Data Protocol (no slides!)
  • Agile Estimation (ok, slides for this one)
  • Enhancing Developer Productivity across the Entire Stack (Telerik vendor session, NO SLIDES, no marketing, just code!)

Wednesday April 20th, Web day:

  • Introduction to WCF RIA Services for Silverlight 4 Developers (no slides!)

Friday April 22nd, Seminar day:

  • The Agile Buffet Table (with Joel) Ok, this session will have slides, but last year it was standing room only, we got in trouble with a fire hazard, so get there early.

Visit Telerik, get free goodies, win stuff and come to our party!

GIDS is four years old and Telerik has been at each and every GIDS since its inception. On .NET day (Tuesday), we are handing out some great free goodies at our booth, so make sure you stop by before the keynotes before it gets mobbed. (Last year our Tee shirts were in such demand, the booth got knocked over in a rush!) Also look in your conference bag for some other great goodies.

We have some great prizes, but another reason to come visit our booth is that in partnership with Pluralsight, we are throwing a great party on Tuesday night. (If you went to our party last year, you know what I am talking about!) Swing by our booth for a demo, some goodies, and tickets to our party. Space is limited, so come by early!!!

See you in Bangalore. Bring your umbrella, hopefully the monsoon is not as bad as last year. Winking smile

posted on Thursday, April 14, 2011 8:47:24 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [2] Trackback
# Monday, April 11, 2011

Thursday, April 21, 2011
Learning MVC for the Web Forms Developer

You must register athttps://www.clicktoattend.com/invitation.aspx?code=154501 in order to be admitted to the building and attend.
The biggest problem for developers moving to MVC is not being able to use a lot of the Web Forms knowledge we've already spent so much time learning. This presentation will take the developer from something they already know - Asp.Net Web Forms and move them into MVC utilizing the knowledge they already have for Web Forms. We will review a complete ASP.Net Web Forms application where we do common tasks, and then see how to do the equivalent type of task in MVC. Procedures such as Data Binding, Error Handling, URL routing, AJAX, and more will be covered. No MVC talk would be complete without discussing how to unit test our MVC code as well. This discussion will also cover common controls (grids, etc) available to the developer and how client libraries used to enhance our MVC applications.

Adam Tuliper, Cegedim
Adam has been developing software for over 15 years. He started his work in security and reverse engineering (x86 based - pre .NET) with the direction of going into the software protection and anti-piracy field. This gave him a foundation for learning the internals of other technologies from Win32 systems to CLR systems. Besides development, he has performed security audits and penetration testing for large and small companies alike. Adam currently works as a Software Architect for Cegedim. He has been deeply involved in .Net internals since early beta and currently works extensively with WCF, ASP.Net, SQL Server, MVC, C#, jQuery, and Silverlight.

Thursday, April 21, 2011

Reception 6:00 PM , Program 6:15 PM

Microsoft , 1290 Avenue of the Americas (the AXA building - bet. 51st/52nd Sts.) , 6th floor

B/D/F/V to 47th-50th Sts./Rockefeller Ctr
1 to 50th St./Bway
N/R/W to 49th St./7th Ave.

posted on Monday, April 11, 2011 10:43:43 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Friday, April 1, 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.


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 1, 2011 9:02:49 AM (Eastern Standard Time, UTC-05: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 2:25:15 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback