Who's driving the bus?

Monday, April 28, 2008 12:24:53 PM (Mountain Daylight Time, UTC-06:00)

imageHere at DTS, we're very focused on consulting-type software development.  As such, we have very direct access to our end users and customers.  Our work is "clearly" defined and prioritized by our customers and we receive direct customer feedback every two weeks.  We do not have a dispersed customer base, it's usually a single organization.  However, last week I had lunch with a friend who does more "shrink-wrap" development.  His customers and end-users never define or prioritize their needs.  In fact, unless it's by pure happenstance, the developers never meet or know their customers.  The functionality and feature set for the software is defined by an internal customer proxy who has his "finger on the pulse of the customer".

Now a disclaimer:  I've never worked on a shrink-wrap team, I've always been on consulting development teams.  Given that little disclaimer, I don't understand how a customer proxy can really define what an entire unseen, unknown customer base really needs.  I know that some organizations do prototype or "focus-group" type testing to gauge what their customers want.  But my friend's team develops on a gut instinct of what their customer base needs. I'm not sure this ever can truly deliver quality and value to a wider audience.  I think it leads to Microsoft Word-type deals, with tons of functionality that only a few people actually use.  Don't get me wrong, I think a lot of good things come out of gut instincts.  I think there is a lot of value to anticipating user needs.  It's part of innovation. 

The other point my friend made was that in the shrink-wrap world of DVD-based delivery systems, organizations are hard pressed to keep up with the rapidly changing demands of large customer bases.  Their release schedules and update maintenance schedules must be horrendous.  They can't respond rapidly to changing or evolving customer needs.  The best they can do is provide patches and updates via the web.  New functionality is released on the next release...on DVD...every 9 to 12 months.

I do see a solution to this problem and I think the folks at Rally really embrace the ever evolving needs of their dispersed customer base.  It's how they gather and prioritize their customer's needs that impresses me the most.  Rally has a community website where users can enter feature requests.  The other users in the community can vote on the usefulness of the feature requested and provide additional feedback and comments on the feature request.  Based on these entries and their associated popularity, Rally is able to understand their user needs and prioritize them.  Many of the features requested by their user community show up in very frequent releases of their web-based solution. No DVD's or anything.  Just a quick release and instant functionality to their customers.  Speaking from personal experience, I've seen functionality we've asked for implemented within a single 7-week release from when we requested the feature.

To me, this is as close as you can get to your customers if you're doing "shrink wrap" software development.  For those of you out there doing shrink-wrap development in an agile manner, how do you engage your customer base to deliver high value, quality software?  I'm very curious how customer proxies work in agile organizations?  How do you define and prioritize your customer needs if you never get to interact with your customers?  When I think of these types of questions, it makes me very happy to be on a consulting development team.  Sometimes I think I take the close relationships we have with our customers for granted.  After this conversation with my friend, I think I'll value the collaborative nature of our relationship with our customers a whole lot more.

Against the wind

Thursday, April 24, 2008 1:56:58 PM (Mountain Daylight Time, UTC-06:00)

image OK, don't be too concerned, I'm not going to break into some bad Bob Seger karaoke.  Here's the deal:  Today over lunch I planned on doing a quick 20 mile bike ride to refactor my wetware.  Based on my usual average speeds over flat terrain, I figured on about a 1 hour ride.  Before I headed out, I checked the weather and the wind speed was about 2 mph (not much at all).  So, out I go and I'm cranking all the way out toward the foothills of the Rocky Mountains.  I get to my turnaround point and I'm right on my usual average velocity.  I'm thinking, I'm getting back to the office right on time.  So, about a mile in on the return leg, the wind decides it's time to blow.  And it really starts blowing a strong headwind.  I can't get over 14 mph!  I get back to the office and it took me 75 minutes instead of 60!

So, what does this have to do with anything (except that now you know that I ride my bike at lunch)?  While I was riding back, I thought, this is a lot like a big software development project.  A lot of development teams start out thinking "This is a 20-mile ride, I usually do it in 60 minutes".  They try to figure out all the dependencies (i.e., the terrain, the wind speed), and feel really confident that they'll get the job done in time.  Then they start building the software.  The wind is at their back...they're cranking through the work.  Then, one day, the wind starts blowing.  This project has complexities we didn't think of.  We didn't know it was going to be this difficult.  But we still need to finish the job (we still need to get back to the office).  We can't work or pedal any faster.  We know we're going to be late.  What do we do?  The project goes into panic mode.  Do we sacrifice quality to get it done?  Do we sacrifice schedule?  Do we go over budget?  The reality is, most traditional development teams do all three at one point or another.

In agile, we don't let the wind worry us.  Agile embraces changing conditions.  An agile team simply says, OK, it's windy.  How do we work in the wind?  How do we work with the wind?  Do we have to make it back to the office?  In other words, agile teams can easily adapt to new conditions, new requests, new requirements, unknown complexities. And because we use prioritized backlogs with our customers, we don't have to sacrifice quality (or value), schedule, or budget.

A Tale of Two Teams Flash Video

Thursday, April 24, 2008 12:02:54 AM (Mountain Daylight Time, UTC-06:00)

I've been messing around a bit with Flash tonight building 3D cubes, globes, and carousels for site navigation and data presentation with Papervision 3D (very cool stuff and open source...read as FREE...check it out if you've never heard of it before). I'll be posting more stuff about Papervision as I get into it a little deeper.  I also wanted to stick something on the blog to test out this little Flash video and viewer I did for DTS Agile using Camtasia Studio just to see if DasBlog could handle it.  It's called A Tale of Two Teams and is a presentation I put together about a waterfall team and an agile team.  The video is also available on our main site www.dtsagile.comUPDATE: Seems like some aggregators can't read the Flash video.  If you can't see the video, please visit http://www.chrisspagnuolo.com/ATaleOfTwoTeamsFlashVideo.aspx.  Here it is, hope you like it:
 

Geospatial Developer Survey

Monday, April 21, 2008 8:50:25 PM (Mountain Daylight Time, UTC-06:00)

My partner in crime, Dave Bouwman, is currently running a survey called "What Do You Do? Geospatial Developer Survey" through May 9, 2008.  I took a look at some of the preliminary results this evening and found some very interesting responses (some good...some not so good).  Here the blurb on who should take this survey from Dave's blog:

Who should take the survey?

Anyone who writes any code that is geospatial in nature. From the Google Maps Mashup dudes, to those running some geoprocessing tasks with python. If you write code that has anything to do with a map, you're the perfect person to take the survey. Be sure to pass this url around to everyone you work with who is a geospatial developer - the more data points we get, the better. Who knows - we may even be able to influence the content at some conferences...

So, if you haven't had a chance to take this yet, it's worth the few minutes it'll take to complete it.  Here's the link (for copy pasting to all your developer buddies):

http://www.surveymonkey.com/s.aspx?sm=cugzupf5rAG_2bIu5WJ_2f7rxQ_3d_3d

DTS Agile becomes Rally Enablement Partner

Thursday, April 17, 2008 3:32:21 PM (Mountain Daylight Time, UTC-06:00)

image News flash from Ft. Collins, CO:  DTS Agile is the newest Rally Enablement PartnerRally Software Development has established corporate relationships with industry-leading companies to help their customers acquire the Agile development skills and solutions that meet their unique needs. Rally's Enablement Partners provide a comprehensive network of expert resources that offer a wide range of business, process, and technology services related to planning, building and delivering software that provides immediate business value.

As a Rally Enablement Partner, DTS Agile delivers solutions and product development services as well as industry leading Agile coaching and training that help Rally's customers acquire the skills to reliably deliver software in rapid iterations. From outsourced Agile product development to embedding experienced mentors on your team, the experts at DTS Agile  help you plan, build and deliver software that provides immediate business value.

My Dad was a ScrumMaster

Thursday, April 17, 2008 9:49:56 AM (Mountain Daylight Time, UTC-06:00)

PanAm In light of the recent news about American Airline's maintenance problems, I sat down and talked with my Dad about aircraft maintenance.  You see, my Dad was a maintenance Crew Chief for Pan American Airlines for nearly 30 years and I wanted to understand how things got so bad for American.  My Dad explained the inner workings of Pan Am's maintenance program to me.  The program dated back to late 1960's and early 1970's and was remarkably agile-sounding.  Here's the program in a nutshell.

Aircraft are regularly called in for routine servicing.  The servicing was usually scheduled for about 3 days.  A QA specialist (or several QA specialists) examined the aircraft and used a set of cards to write up work orders for each item that required servicing.  The QA specialist then sorted the cards by theme (interior, engines, avionics, etc.), estimated how many items could be completed in 3 days based on historical data, and slotted them on a task board.  The crew chief for each "theme" area would pick up the cards for his team.  The crew chief and his team would triage the work items and prioritize them.  Then, the team members would select the work items they would work on and provided the crew chief with time estimates to complete each of the tasks they selected.  This allowed the mechanics doing the work to actually estimate the duration of their tasks.  The team would then commit to completing the tasks within the 3 day service period.  Each day, they'd check in with each other to make sure things were on track.  During the service period, the crew chief worked on some maintenance tasks, but he also made sure that everyone on his team had what they needed to get their job done.  At the completion of the service period, the QA specialist would come back and inspect each maintenance item and either accept or reject them (and FAA inspectors checked things as well). Team members were also encouraged to think about how they did their job and suggested new or better ways to do things (in fact, they received monetary incentives for coming up with innovative ideas).

Now, I don't know about you, but this sounds very much like Scrum to me.  If you think about it, we have a highly complex piece of equipment with multiple integrated systems.  We have a mission critical maintenance program.  We have high priority items that need to be completed...you know, done done...to keep the aircraft safe and airworthy (and others that are lower piority like a reading lamp that isn't working).  You can't mess up here.  So how do you do it effectively and efficiently: Scrum.  Here's how I see it:

We have a time boxed iteration (the 3-day service period).  We have a product owner (the QA specialist), a ScrumMaster (the Crew Chief) and a team (the mechanics).  We have a prioritized backlog (the task board and task cards) and team members selecting their tasks, providing task estimates, and committing to a team goal of having the aircraft ready to roll in 3 days.  We have a daily stand up (checking in to make sure they're on track).  We have a servant leader ensuring his team has what it needs to meet their goal and we have a product owner review at the end of an iteration.  And most importantly, we have retrospection and continuous improvement.  Seems like Scrum to me. 

So, maybe Scrum is just a repackaging of things we already knew that worked well.  It's just being applied to software development now instead of aircraft.  Toyota picked up on much of this and Taichi Ohno implemented lean manufacturing there in the early 90's with a lot of similar tactics.  Maybe we shouldn't be too proud of ourselves for discovering something new...we really just rediscovered something old that worked and there's nothing wrong with that.  So, let's file this one under "Nothing New Under the Sun".  Or better yet, let's file it under "My Dad Was a ScrumMaster", he just didn't know it.

GeoScrum expanding focus

Monday, April 14, 2008 8:19:56 AM (Mountain Daylight Time, UTC-06:00)

Maybe it's something in the air here in Ft. Collins this spring, but I'm feeling the need to change things up a bit.  Recently, my responsibilities at DTS have increasingly begun to include a wider variety of functions. So, in the months ahead, I will start expanding the focus of GeoScrum beyond discussions about agile practices.  I will begin including topics on the business of software development, marketing, viral marketing, working with distributed teams, and some general presentation goodness.   I will also start including more technical content, especially with regard to GIS development, Flash, Flex, Air, and  possibly Silverlight.  And of course, I'll still be writing plenty about agile and scrum, so stay tuned.  I hope all of you who currently read this blog will enjoy the expanded content.   Cheers!

Agilistas now over 700 strong!

Friday, April 11, 2008 9:03:30 AM (Mountain Daylight Time, UTC-06:00)

Wow, in just 10 days, we added more than 100 new members to the Agilistas group to bring the total membership to over 700 people now!  It's been amazing seeing how may people have joined up.  If you're not an Agilistas member and would like to join here are some links for you.

To join Agilistas on LinkedIn: http://www.linkedin.com/e/gis/43421/24A5E7397137

To join the Agilistas website, which includes a community blog, a news & events section, file sharing and discussion boards, follow the instructions below:

For those of you who do not have an Agile Commons account,  you can join Agilistas by going to http://agilecommons.org/join/agilistas

For those of you who do have an Agile Commons account, you can request membership by going to http://agilecommons.org/groups/1549f5474f/members/request.  This link is displayed on the Agilistas homepage in the “Become an Agilistas Member” panel (which is only visible to members of Agile Commons).

Cheers!

Enter the Dojo

Thursday, April 10, 2008 12:04:31 PM (Mountain Daylight Time, UTC-06:00)

Ah young grasshopper, you have much to learn.  And we're learning everyday at DTS.  If you're interested in the kinds of GIS development we've been playing around with lately, you can check out our new site, the DTS Dojo.  We've put up a bunch of web GIS technology demos that we've developed, including a very cool Virtual Earth demo of some work we just did for National Geographic.  We'll be adding more samples soon, but check it out, there's lot's of good stuff up there already including ArcGIS Server, Virtual Earth and REST API demos.  And if you see something that you want to know more about, feel free to contact us anytime.

The_Dojo

How well do you know your world?

Wednesday, April 09, 2008 9:19:46 AM (Mountain Daylight Time, UTC-06:00)

OK, so I write a lot of stuff about agile and Scrum, but my site is called GeoScrum.  Once in a while I should post something about GIS or geography right?  Well, here it is.  Think you're really good with Google Maps, Google Earth or Virtual Earth mashups? Test your geographic knowledge to see how well you really know your world with this little map app.  (If you can't reach this map directly from the post, you can also check it out at my site www.chrisspagnuolo.com or at http://www.cafetravel.info/geography/?c637=0b66.  If you really rocked, let us know your high score in the comments area of this post.

UPDATE: So, a few people wanted to know my high score. Here it is:

 

 


brought to you by TravelPod, the World's First Travel Blog ( A TripAdvisor Media Network partner ) 

DTS Agile on Agile University Faculty

Tuesday, April 08, 2008 1:47:33 PM (Mountain Daylight Time, UTC-06:00)

imageData Transfer Solutions is pleased to announce that Chris Spagnuolo, Dave Bouwman, Lakshmi Rameseshan and Randy Goss are now members of the faculty at Agile University.  You check out Agile University and our faculty profiles here.  As part of DTS Agile, our trainers will be offering real world agile training and consulting delivered by real world software developers.   Registration is now open for three sections of our Agile Process Kick-Start class through Agile University.  Here's a brief description of the course:

What are agile practices and how can they work for you? This course is designed to answer those questions and more. Speaking from our real world experiences implementing agile practices in several organizations, we'll show you what agile looks like and how it works from a practitioners viewpoint. We'll specifically focus on the use of Scrum to iteratively and incrementally deliver high quality, valuable, working software to your customers quickly.

Learn more about DTS Agile and Agile University here.

Project reporting

Monday, April 07, 2008 11:27:34 AM (Mountain Daylight Time, UTC-06:00)

Many organizations require a fair bit of weekly or monthly project status reports in order to provide invoices to clients and executive level visibility into project status.  Recently, I've been working through the issue of project reporting on our agile projects at the request of our COO.  He has implemented a policy requesting weekly project status reports that require reporting on the iron triangle of scope, schedule and budget.  It's not an overly complicated report and it doesn't take much time to assemble.  However, I'm not entirely sure that it provides useful information for our customers and our executives.  It's very easy to gloss over the facts in a line item report with very generalized reports for milestones, schedules, and forecasts reported only by a project manager.  Currently, my scope status section of the report looks something like this:

Milestone Schedule Current Forecast Status
Iteration 1: Foo Functionality 3/24-4/4 Complete
Iteration 2: Goo Functionality 4/7-4/18 On target In progress

I'm not sure I see much useful data here.  What I think is so valuable about Scrum and tracking our progress in Rally is that we have actual metrics being reported every day directly by our development team.  We have iteration and release burndown charts that show our progress on a daily basis from real reported metrics.  We have a prioritized project backlog that shows what's been completed and what we have left to do.  Our user stories in the backlog all have story points associated with them, and based on our team velocity, we can estimate how long it will take to complete the entire backlog or any portion of it.  Within our iteration backlogs, we have fine grained tasks with estimated and actual hours for each task.  In addition, we can add hourly rates to each developer, and based on the actuals reported through Rally, we can derive our budget status, which is especially important if we are working on a fixed-price contract.

I think that the metrics provided by using Scrum and Rally together provides far more information and visibility into the state of a project than a simple line item status report.  And, because the metrics are based on actuals being provided in near-real time by project team members, executives and customers can "peek" into the project at any given moment and know exactly what the situation is.  They don't need to wait for the weekly or monthly status reports.  Rally is especially helpful in this case because it provides project, program, and workspace dashboard widgets which can provide burndown charts for all currently active projects.  With agile project reporting, there is nowhere to hide poor performance with generic terms that don't deliver much information.  Everything is visible and accessible to everyone. 

Mastering the iteration

Friday, April 04, 2008 8:31:48 AM (Mountain Daylight Time, UTC-06:00)

StickyMinds.com has a new whitepaper out called Mastering the Iteration.  Here's the skinny on the whitepaper:

The heartbeat of Agile software development is the iteration – the ability to create working, tested, value-delivered code in a short time box. Mastering this skill takes guidance and practice. In this paper, Dean Leffingwell describes the iteration pattern and the activities that a team engages in to meet this key challenge.


Download this white paper to learn about:
•  Iteration basics - the heartbeat of software Agility
•  The iteration planning process
•  Executing an iteration
•  Tracking iteration progress and adjusting

To download the whitepaper, click here.

Who needs a resume anymore?

Thursday, April 03, 2008 4:28:51 PM (Mountain Daylight Time, UTC-06:00)

visualcv_button copy

While I was checking out one on of my favorite blogs/websites (Guy Kawasaki's How to Change the World) I noticed  a button on his site that linked to Guy's Visual CV.  It was way cool.  Visual CV is a new online Visual Resume site.  Not only can you include the usual resume fodder, but you can add portfolios, videos, writing samples, audio clips, code samples, links to your websites...you name it..for FREE.  So, if you're out looking for a job, or even considering applying to be a Bad Ass Web Developer for Data Transfer Solutions, consider using this instead sending a paper resume.  As a hiring manager, I'd much rather get rich content like this than a lame Word resume.  And if you're not looking for a job, it's a great way to promote yourself to your customers and clients.

And yes, we're still hiring a Web Developer here in Ft. Collins, so if you're interested, here's our job ad one more time:

Do you have mad ASP.NET, Ajax, Javascript, and CSS skills? Are you a web development guru? If you are, this might be your workstation. Data Transfer Solutions is hiring and we need someone who can do some serious web development. We’re an agile development shop and we’re looking for a web developer that will fit well with our existing Ft. Collins, CO team. Experience with agile development practices and geographic information systems are a plus but are not a prerequisite. If you’re a web developer and you’re looking for a new place to sit, send a resume, or better yet send a link to your Visual CV to ftcjobs@edats.com .

Team Velocity: More than the sum of it's parts?

Wednesday, April 02, 2008 9:39:30 AM (Mountain Daylight Time, UTC-06:00)

With our move to our new company came a new way of working for our team.  We used to be a tight knot team, all working the same long-term 3+ year enterprise project.  Now we're working on equally engaging projects, but they are shorter term.  Our "team" has been split into smaller teams of 3, 2 and even 1 person per project.  We've also been working on distributed teams with our other offices around the country as well.  As such, our velocities are for individuals, small teams and disjointed teams.  It looks like this will be the modus operandi for the foreseeable future as well: Mix-n-match teams to put the right people on the right jobs for our clients.  So, the question that has been occurring to me lately is, how do I get reliable velocities to adequately estimate bids for future work with our mix-n-match teams? 

One idea I'm toying with is trying to gauge the velocity of individual team members using Rally.  For example, I can calculate Dave's velocity as 12 points per sprint, Mike does 10 points per sprint, and Jeff does 11 points per sprint.  If we have a project that requires Dave, Mike and Jeff together, are their velocities additive?  Can I assume that this team would have a combined velocity of 33 points per sprint?  This begs the question, is the whole greater than the sum of it's parts? 

In the next few months, we're going to test this theory.  First we'll get a good handle on individual velocities. Then, we'll start tracking the mix-n-matched teams to see if individual velocities are additive or something else (better or worse).  This approach is going to require that we establish a common basis for estimating.  We'll have to come up with a baseline for our story points that everyone can agree upon.  I'm not entirely convinced this is possible, but I think it is worth investigating.  If you've dealt with a situation like before, I'd love to hear your thoughts on how to tackle a complex issue like this one.

Free Management Briefing from SolutionsIQ in Seattle

Tuesday, April 01, 2008 12:29:36 PM (Mountain Daylight Time, UTC-06:00)

Moving to Agile: An Executive Manager's Perspective

During this two-hour management briefing, Tom Haug, VP of Software Engineering for Electronic Evidence Discovery (EED), will share an executive management perspective on adopting Agile. Tom will discuss how to overcome some of the unexpected challenges companies face when moving from a traditional development process to Agile. Joining him will be Michael Tardiff, SolutionsIQ Agile Team Lead and Coach, and Paul Dupuy, SolutionsIQ Agile Generalist. Together they will provide a coaches' perspective, sharing many of the specific techniques they have employed with EED to enhance the team's use of Scrum and XP practices, while improving the organization's velocity by assuming direct roles as ScrumMaster and development lead on the project.

Event Details:

Date: Thursday, April 17, 2008, 5:00 p.m. to 7:30 p.m.

Location: Bellevue Arts Museum, 510 Bellevue Way NE, Bellevue, Washington (View Map)

Cost: Free

Speakers: Tom Haug, EED Vice President of Software Engineering; Paul Dupuy, SolutionsIQ Agile Generalist; Michael Tardiff, SolutionsIQ Agile Team Lead and Coach

For more information: Management Briefing Overview