I’m back to basics at my new job. We haven’t really needed to oversee our project with process, not really, until recently. Things are ramping up. We’re launching an amazing product and there are several opportunities on the heels of it. Some of them may actually involve generating revenue. We are a start up in every sense of the world: pre money, pre market.
Our new Process
I’ve used Scrum for the last few years, and with much success. To capture and track work details, I’ve used Rally and, most recently, Mingle. Both products are best of breed. I’ve tried lots of others, none measure up.
Agile Software Tools
Here’s the easy way to choose which one to use: a) If you are new to, or have less than a year or more of solid, successful agile experience and/or your team is of varying degrees of agile expertise, choose Rally. Rally provides solid guidance and the tool fits the process very well. By using the tool and following the extensive guidance provided, you’ll get better at your own agile process and learn more easily and quickly. I would then also recommend some training from Rally, they are very, very good and very down to earth.
b) If you have been an agile nut for two or more years ad you KNOW how to run an agile shop. Now, dont lie for my sake, you’re not telling me, your telling yourself. If you really have a solid grasp of the principle concepts behind agile development process and methodology, Mingle is superior simply for its flexibility. You can set it up how you prefer and the interface is very clever.
The Rusty Factor
So, which do you use, Rusty? Neither! I brought these tools to the table at my new company and got everyone to commit to using them. They never did, but they committed. Yesterday, Bill and I planned the remaining work we knew had to be done this month. Even in an agile shop, deadlines can be set in stone, right? We have a date to meet where there just isn’t any wiggle room. He and I story carded on 4×6 note cards and then went across the street to the cafe to estimate. An hour later, we had a very confident estimate for how much work we had remaining. We brought this back and then leveled with the boss. During this short meeting, I explained that someone had to enter the details into Mingle (the tool that won the dice toss). Christian explained that he would rather call and ask where we stand than log into some tool, like it or not. Actually, kind of like it. When I explained that the tool gave us reporting and history and documentation, he said, "so what, who cares?"
Forgetting to Think before we Believe
Up until that minute, I felt that being able to report velocity and back test estimates and track defects against features was important. Is it? Really? Not really. Its important to get the job done, do the right job and work as efficiently as possible. Its important to pull your weight and grow so that you can earn increases in comp. However, reports, burndown charts, etc. are mechanisms for managers to herd cattle. They need to know which cattle have strayed and need a zap on the ass. They need to know when the herd could be herding faster and when they can whip and when they should not. However, a good teem needs none of this. A good team is empowered and motivated by self interest that aligns with company strategy. A good employee is one that wants to succeed as a business as much as the owner does. So don’t believe the masses that you need reports and projections of velocity based on historical tracking. Believe you need great people and nothing less.
So I am using 4×6 note cards on a cork board to plan and track projects. How refreshing.
I recall once that a certain someone built an Enterprise Framework for an organization I worked for and that, during his presentation of our new framework to the rest of the team who would have the honor of using it, he reported that there were over xxx thousands lines of source code. (it may have been over 1 million, I don’t recall the exact number, just that it were an awful lot). It was later coined the "h_________ proprietary code initiative" as it was the HPCi.Enterprise framework.
A few years ago, I had as a goal building bullet-proof and re-purposable code. I sought to think of everything, provide every possible feature, solve every conceivable application of my utility and otherwise make people thankful for and impressed by my thoughtfulness and clairvoyance.
Over the last few years I’ve learned about lean. I learned about KISS. I learned that you should do the simplest thing possible to solve the immediate problem after you write automated unit tests that assert the correct outcome from exercising your logic, and move on! This is easier to state than to practice (unless you write tests religiously, which I strongly recommend).
Today I created a simple rounded corner control that opens and closes the necessary html elements and references the needed images to surround child content with a nice container. I dug up some old source code to remind me how to render child controls inside a webcontrol.
My old rounded corner control was over 1550 lines of C# code. I am just as guilty and our historical benefactor for over-engineering.
The one I wrote today was less than 45 lines. I could write 20 special case controls and still check in well under weight from that old piece of majesty. Stop the madness, write the code you need, not the code someone might someday wish for.
I was looking for a reference for Mike Cohn’s recommendation to estimate stories in points and tasks in hours and ran across a really good point.
When a non-tech supervisor looks at an iteration or release plan and questions why, if points are worth ½ day and there are 4 developers, why a 2 week iteration does not have 80 points of work accounted for. How can you explain using 4.5 per day team velocity (or whatever it happens to be) when your stories were estimated using a 2 per developer per day?
“Consider traffic: What does 100-percent-utilization of roads gives us? zero throughput (gridlock)! Why do we think it is different for a development team with competing demands, interruptions, meetings, etc?”
Good point! I have always felt uncomfortable explaining that point to a supervisor. They consistently give you a cock-eyed stare as you explain that your velocity is based on the performance of the previous iteration and that it is not possible to actually complete 2 points per developer per day unless life itself is placed in suspension. Usually a, “ooooh kay,” is the best we expect from that conversation. This is a nice descriptive analogy for what the goal of scrum really is. It’s providing an orchestration system where individuals are not left waiting for a traffic light to change yet they are able to navigate their own path to the well defined goal
People often use "building a house" as a metaphor for software engineering. Ironically, they use it from both sides of several arguments. For example: a Waterfall proponent may suggest that you don’t start swinging your hammer until you have the architectural blueprints drawn up and the construction schedule reconciled with contractors and suppliers. An Agilist would counter that you don’t have pick out the curtains before you begin pouring the foundation. Both are right (at least this specific argument). Its not good practice to dive into a software project without a plan but you don’t have to plan three years out, just far enough to set expectations for delivery.
Visualizing your Goal
Far more important that your plan is your vision. Plans should change when new information is discovered along the way. However, vision should be pretty much consistent through changes in climate and circumstance.
With software, your vision is what the end user does with the system. It is the user experience, from their perspective, for how they use the new or enhanced features. If its a small project, that’s usually easy. When its a major feature enhancement, this can be more difficult. By removing the UI from your description, you can usually be more accurate (through changing requirements) and keep the details simple.
For example:
Let’s say you are building an online flight search tool. Your description of the completed work should be: user can search for flights from origin to destination within a certain date range and optional time range. That’s pretty high level. No talk of drop down menus, page navigation, font color, etc. If you start there, you can then narrow the focus during design.
This should be done before you begin swinging your hammer. Agile doesn’t mean sprinting headlong into uncertainty. Its important to understandwhat means "done"before you begin.
Tests as your Benchmark
So let’s say you begin your project and you stop to define what it is that you are trying to build. You establish you high level description of a successful outcome. Now what?
Break it down into tests! If you are given a broad-scoped feature request, a logical thing to do is decompose that into smaller tasks necessary to accomplish the goal. Do the same thing from vision to tests. In the above example, you can elaborate that a user must select a date range. The second date must be equal to or later than the first. Time is not required. Same rule for second time selection, however. An origin and a destination are required. The rest of the details, you may have to discuss with the business owner to get consensus.
Once you have this list, write them in a format that can easily be implemented as input / output tests. This should be done during design elaboration of the feature. As you are designing how the program will implement the feature, you should be detailing how you will validate that it works.
This list should be converted to unit tests as much as possible. Those items that cannot should be written as automated UI tests. This should be done before you begin coding. If you have a QA department, great, they should write the UI tests and help develop the unit tests (at least in human language). If you don’t, that ain’t no free pass. Taking the time to validate your outcome before you begin will save you a tremendous amount of time and guarantee that you won’t cut corners as release time approaches. You’ll find that you are "done" sooner and that you are more "done" than if you hadn’t taken this step.
Less Time Chasing Rabbits
Another benefit of this practice is that you can produce executable documentation for your feature. Yes, it lives with the code and continues to validate the business rules you worked so hard to support. Just as importantly, you will have something to share before you have a screen to show. Anyone involved in the project can review those rules and find an opportunity to add additional detail or call out a conflict. If you have just begun to build your object layer and someone informs you that login is required to access the feature, you don’t have to toss a bunch of code around to support that. You learn earlier what needs to change and you can implement that change more easily and for a much lower cost.
How do I Test That?
The basic message to take away is that a "test" is your best way to define done. Having a test to start with will help you reach done faster. It will help you be more done and spend less time responding to "issues" found in your code. A solid, consistent practice for testing first will allow you to satisfy both sides of the "build a house" argument and reach a happy compromise between code slinging and sandbagging.
I’ve investigated Ruby several times. I’ve gone through the online Ruby tutorials and installed Instant Ruby (no longer supported, replaced with Bitnami RubyStack). My first real ruby experiment was to try to create an object-based text file parser to open a text file, look for a reg ex pattern, replace it, then save the file. Sounds simple enough? I was able to get 80% of the way there with very little code. In fact, I did this in iRuby (interactive commanline where you define classes as you go). This was compelling because I can’t imagine doing this in c# without a compiler… Oh yeah, its compiled, need compiler. However, I reached an abstacle as I tried to interact with the filesystem and wasn’t satisfied with the accessibility of documentation while I Googled for solutions. I finally completed my task in c# using TestDriven.net as my execution interface. TestDriven.net, by the way, wins tool plug-in of the decade award for all the benefits its brought me.
As the World Turns (Ruby)
I quickly returned to the warm bossom of my Visual Studio IDE and the C# language. However, the Ruby on Rails 15 Minute Intro kept on haunting me, asking me whether I really needed stored procedures, parameter lengths, data readers, streams, request objects, page lifecycle, etc. It’s not that these things don’t have their place but I couldn’t help but feel as though the cutting and pasting I was doing to create data access and user controls wasn’t somehow repetative. DRY?
Rails for Microsoft Junkies
So I love C# but I wanted to experiment with rails. Monorail, y’all!
I started there. The first thing I discovered was how easy simple things were. That sounds pretty trivial but sometimes I am astounded by how much crap I have to add to get data to a page in Asp.Net without violating every principle of good software design ever captured in a UML diagram. Data in the presentation tier just makes me feel dirty, I can’t sleep at night, I can’t eat. I just won’t do it. Even DataTables eak me out. Strongly-typed datasets? Who thought it was a good idea to take something dynamic and unstructured and compile the ugly thing? Intellisense, I know. I am addicted to it, too.
Of course, monorail is a gateway drug. I used monorail with Active Record to create a simple website. When I defined my business classes and used them exclusively to bring data to the view, I was excited. Then I genereated the schema for the first time. It was a dirty chunk of code in global.asax but it generated a database that was compeltely prepped for persisting every class I’d defined with no more than simple attributes. WOW!
Of course, I am a control freak and didn’t like the 1 to 1 requirement of Active Record so I learned about NHibernate. Many months later, and a significant amount of trial and error, not to mention a significant repository infrastruture, plus tremendous development and advancement by Mr. Rick Caldwell, and we now have abandoned our previous belief that all data accessmust use stored procedures and that ORM was for lazy programmers. It rocks. I LOVE database modeling. It is downright orgasmic to design your class structure according to your domain model and then generate a database schema that perfectly matches the normalized data model that you would have coded if you were required to do that by hand. Watching the sql in Log4Net is also quite entertaining and rewarding. Being able to focus entirely on the business domain and not worry very much about data access is just efficient.
Back on the Rails
For a period of time, rails was shelved in favor of asp.net using NHibernate. Recently I spoke with Mark Jones (blog link forthcoming) and he helped reinforce my belief that there is something very exciting happening on the Ruby side of the world.
He was excited about the Monorail possibilities and inspired me to explore the framework further. I dug into the ajax helpers and compared ashx handlers with controller actions and found it truly a pleasurable way to create a website. It almost forces you into good design. MVC frameworks encourage you to separate concerns. A little good practice and inversion of control is as simple as a one line code change (load from config rather than in code).
…and back to Ruby
I have been excited about a ruby port to dotnet so there must be something in that Ruby community that fosters creativity and innovation.
I am installing the RubyStack now and will begin my now far more enlightened adventure through the language. I now understand that you don’t need to compile ruby, you execute the ruby.exe commandline runtime. It will launch whatever components you need for your app. I can’t tell you how long I’ve been confused as to how exactly to execute my ruby app without visual studio. Where is F5?
I haven’t posted for a while. I’ve been busy with non-work. That’s the kind of work that takes exhorbinant amounts of time but doesn’t actually move you forward. Its much like pushing on a tree. It’ll make you sweat but the tree won’t move. I believe there was value in some of what I have been doing (sell the concepts) but I did, in the end, regret having taken the valuable time required to prepare the materials requested only to be told I’d not met expectations for commitments that I had to compromise to produce the required deliverables of the non-work. Basically, I wish I’d have found a way to communicate the strategy and need without having to produce a documented report. That report was tossed aside and filed with the last one.
Most who know me know that I am a obsessed agilist. I left a very waterfall organization, in fact, a very disfunctional corporate mess, to join a small, motivated company. At this small company, we are growing carefully into an efficient, small, productive team. We’ve been stabalizing and consolidating existing software and processes so that we can focus on our new and very powerful forward looking projects. We’ve built a core team that is second to none and just scored a third eager developer who promises to add significant energy and growth to our culture. Building a team is probably the most critical piece of a success proposition so I am entirely confident that we will blow the doors off the competition. Unfortunately, I am not presently clear on the best way to communicate the cultural and process requirements of a small, productive software development team. I failed to effectively secure support for what is necessary to reduce overhead and increase velocity and now I have to pull back on the reins in order to satisfy upline support for an agile process.
The simple way to state this is that I have been conceding to demands to follow a traditional business process. My hope was to satify the immediate need so that I could then enjoy the breathing room necessary to tighten the process. Instea, dealines slipped, process dissolved and the documents I begrudginly authored were tossed aside. Now I am on probation for failure to deliver though that is a direct result of having to abandon project direction to accomodate something I am opposed to: heavy documentation. I had changed my screen saver to an image engraved with the phrase, “balance advocacy with enquiry.” The reason is that I felt immensely frustrated at being asked to behave in a manner consistent with failure both in my own experience (having done that) and in company history. I needed to put myself in another’s shoes to try to understand why I was not being consulted for direction rather than being directed and, well, scolded. While I don’t like being treated like a subordinate, I am subordinate, professionally, and that is the hand I have to deal with. Thus, a swallow of Enquiry with each sip of Advocacy.
Where I am left is feeling as though I may have been better with more advocacy. However, I did learn that it is communication and edication that I must deliver. I am accommodating the request to deliver a message of urgency to my team. However, I will not consider over-allocating my team to the point of burn out. A sustainable pace is a requirement of my employment and I will find a way to communicate how this works into the overall picture of a highly efficient and productive team.
First, I must protect my people with clear pictures of resource allocation (story cards placed in priority order on resource scheduling tempaltes). Next, I must manage the outside interuptions to project health (crisis). I feel as though a well organized story-centric iteration schedule presented on paper is a very difficult thing to argue with. I am still at libery to accommodate any requirement thrown at me though I can then demonstrate the impact by moviing a story on the board. This has been a very powerful mechanism for me in the past. If I have to produce one more 80 page document that gets tossed into a filing cabinet, I am going to light it on fire.
The lesson I have learned is that advocacy is important. I was often called the Agile Evangelist at my previous position. My team produced. My product performed. Our goals were met again and again. I have been on failing teams repeatedly and been through project failures more times than I’d even like to recall. It is only after I abandoned, with ferver, the behavior that was not effective that I began to turn the corner. I didn’t count on resistance in my new role. I was hired for my experience and knowledge. That was foolish of me. That would be like pushing on a tree and expecting it to fall. Consultants have it made. They are paid to give their opinion and their opinion is considered to be worth the line item on the invoice. If it doesn’t work, there is someone to blame. With me, I am providing my consult and my expert opinion. But, as an employee, I am there to support my superior in their vision and I am not on an hourly bill rate. I have a great team and an unmatched industry outlook. All I have to do now is get the vision from my head into a format that can be consumed by a non-agilist…. History repeats itself.
It will be a challenge to remember that advocacy of a principle is not war. I feel very much like a football player preparing for the turnover. This isn’t competition, but it is a challenge.
I have a favorite metaphor: Opportunity knocks and your say, “go away! I am too busy trying to get ahead to open that door.” So opportunity obediently goes away.
A while back, I was looking for a simple support ticketing system that integrated with pop email, was easy to install, and …well, worked. I found a few free tools that had relatively inactive communities and a couple commercial products. I wasn’t really ready to lay out for a commercial product. Frankly, I could build what I needed in a couple of days and then I have that beautiful solution meets need arrangement. However, I am not one of those not invented here snobs.
Randy suggested: kayako support suite. It looks great. At $300/yr, its reasonably priced. However, it’s more than I needed at the time (or right now) and I wasn’t ready for another recurring expense.
Spiceworks
I found something wonderful, however. Spiceworks is a free support ticketing and helpdesk tool. Yah, free. It’s also installed locally, which I like. Installation is seamless. It uses its own webserver and is built in Ruby (cool factor). The first version had pretty crappy performance but they fixed that in the recent update.
One problem I ran into is that our support email address is terribly spammed. These show up as support requests in our help desk system. Closing these not only is messy but I do not want to send a reply to these senders. Its a problem that would be solved with a simple “delete” button but Spiceworks decided that “delete” should not be allowed. What I found was that the database is in a file, uses SQLLite and is very easy to work with using SQLLiteAdmin.
Removing Spam from Spiceworks
I’m having trouble getting my videos processed on YouTube. I’m using CamStudio and its not working very well. I may seek another recorder. Ideas, anyone?
I’m truly struggling to find an Agile Community in Atlanta. Quite some time ago (2005), I discovered the [tags]Agile Atlanta[/tags] User Group and attended a meeting. Stacia Broderick presented Scrum to the group. It really was a great meeting but I haven’t attended one since. I check the website frequently but it is rarely updated. They have had a few meetings and at one time gathered some folks to inject some leadership into the group but it hasn’t really seemed to gain any momentum. I certainly don’t fault anyone for this as I experienced the challenge of starting the C# User Group many years ago. There were meetings when only 3 of us showed up. Then there were times when the room was packed and we had no presenter (so we just winged it). …but I hope to see something spark soon.
I am participating in a few user groups at the moment. My schedule is pretty stretched so I can’t take on another responsibility at the moment. However, if nothing has happened by, say October, I may try to build an Agile Software Development Community in Atlanta. I’d love to hear some feedback and get some contact information for people who would be interested. Leave me a comment here or email me at rusty -at- pwg -dot- com or rustyzarse -at - gmail -dot- com.
I am personally a Scrum practitioner but I have read up on Crystal Clear and Feature Driven Development as well. I use Rally Agile Project Management Software in my daily development. We use Test Driven Development (TDD), Pair-Programming, the daily scrum, Continuous Integration, Reflective Review and Time-boxed, Story-centric iterative release planning. However, we are learning like everyone else and adjusting constantly. I would love to find like-minded agile enthusiasts to collaborate with so we can grow the Atlanta Agile Community!