# 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
# Monday, March 07, 2011

Thursday, March 17, 2011
Line of Business Apps Made Easy with Microsoft LightSwitch

Subject:
You must register athttps://www.clicktoattend.com/invitation.aspx?code=154306 in order to be admitted to the building and attend.
LightSwitch is the next generation Microsoft tool for rapidly building business applications. In this session you will learn about the basics of building and end to end LightSwitch application as well as customizing the user interface. LightSwitch ships with only a basic set user interface controls - but many of your business applications require a level of sophistication and interaction that LightSwitch does not provide. You'll will learn how to integrate custom controls into the LightSwitch shell, how to build add-ins for a richer UI experience, and how to integrate a custom shell experience.

Speaker:
Jason Beres, Infragistics
As the Vice President of Product Management, Community, and Evangelism, Jason spearheads customer-driven, innovative features and functionality throughout all of Infragistics' products. Mr. Beres is a Microsoft .NET MVP, on the INETA Speakers Bureau, and the author of multiple books on various .NET technologies, the latest being Silverlight 4 Professional from Wrox Press.

Date:
Thursday, March 17, 2011

Time:
Reception 6:00 PM , Program 6:15 PM

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

Directions:
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, March 07, 2011 12:18:43 AM (Eastern Standard Time, UTC-05:00)  #    Comments [1] 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