5 Reasons to Manage Your Solo Project’s ALM Process

So I’ve been developing software on the Microsoft stack for just over 10 years, and training and consulting on managing software development with VS-ALM (a.k.a. TFS, a.k.a. Team System) for just over 4 of those years. But in all time training and consulting, I was working with teams – from small 5 person start ups, to enterprises with hundreds of users, all using Team Foundation Server (a.k.a. on-premises TFS) to develop their methodology and align their tooling with their products.

Never individuals, though.

Over the years, though,  I’ve had the opportunity to fly solo on several software projects, some short lived, some longer, as have other ALM consultants that I know. One thing we all seem to have in common is that, while as ALM experts, we have all of the skills and knowhow to apply our own trade to the software we develop, we seldom – if ever – do so.

The Cobbler’s Children Go Barefoot…

… as the saying goes. It seems that this proverb applies to our profession as much as it does to others. You’ve seen the doctor who smokes, the out-of-shape coach, the technician or plumber whose own wiring or plumbing is faulty, respectively. Perhaps it’s the same. Perhaps its just that proper ALM is more visibly useful when multiple hands are involved and they must all communicate and interact properly with each other, than when one person holds all roles.

Solo projects seem to need no management, I believe they only seem to.

Here’s why:

1. If You Don’t Use Source Code Version Control, You’re an Idiot!

I apologize for the vehemence. Let me rephrase this. If you don’t use some kind of source code version control, you’re an inexcusably dense idiot who deserves what he or she gets when you lose your source code!!!

I guess I couldn’t rephrase it without the vehemence. Lesson learned.

Beyond the fact that having some kind of backup, preferably online, means that even if you lose your laptop, or accidentally delete your source files, you still have a copy of your code, version control means that if you make a mistake, you can still rollback to that point in time and fix whatever you did wrong. Having a historical log of the changes you made to the software can also serve as release notes of sort, and a rudimentary list of the features and bug fixes you have, and even help establish some kind of time line.

Really though, version control is about security for the code – protection against loss and against mistakes. you should use it as frequently as possible.

Note that you do not need to shell out huge amounts of money to be able to use version control. In fact, as in life, so with version management, the best things are free!

I prefer using Git. You can use it locally with any operating system (Windows, Linux, Mac OS), and there are multiple online tools that work and synchronize with Git, all free: GitHub, CodePlex, and (my personal favorite) Visual Studio Online. There are, of course, other version control systems, both distributed and centralized (Mercurial is another DVCS, Subversion is a great free centralized one).

Heck, even use DropBox or some other online-syncing file-storage, just beware that it won’t protect you from deleting your code, nor will it let you rollback – but at least you’

2. Defining (just enough) Work Upfront = Less Code Writing and Rewriting

Much like TDD tends to limit the amount of production-code you write, so does defining your work. In fact what is TDD, if not the definition of a small amount of work that needs to be done to the system, along with a definition of how to know when you’re done? The same holds true for defining a development task, a user story (a.k.a. a product backlog item, or PBI) or a feature; each is an elaboration of the higher level: Feature to user story, to task, to test. When you know what needs to be done, and you know when you’re done, you know exactly what the remaining work is. That saves time.

And let’s be clear. Just enough is key here. Too little, and you’ll rewrite anything that you haven’t properly thought out and planned. Too much, of course, and changes to the reality surrounding the project and your perception of reality will bring rewrite to your plans.

3. Project Planning Makes it Possible to Plan Releases

Unless you are truly working on a hobby for yourself, you still need to be able to answer at least these two questions:

1. When will it be done?
2. What will be done by a certain date?

Without estimating the work you have to do, more so if you don’t even know how much work you have, you simply will not be able to give more than a POOMA estimate.

Note that unless you live alone, you might still need to answer these questions, if only so your partner, roommate or parent will know when you will finally clear the garage (or dinner table) from your junk.

4. Automation Reduces Human Error as well as Manual Labor

Even if you are a solo programmer, two things remain invariably true for you:

1. You’re only human.
2. You’re only one human.

Being only human means that as talented as you may be, you are still prone to repetition based errors. You’ll forget to update the version number, or forget to set the build configuration to Release, or forget to run the tests, or any number of things. When I train new developers, especially in those early days when they feel that the fact that they’re constantly making errors, and more experienced developers must be demigods or some such, in an attempt to reassure them (and lighten the atmosphere), I tell them this:

• There are only two kinds of developers: experienced, and inexperienced developers.
• Inexperienced developers make only two kinds of mistakes: Mistakes born of inexperience, and mistakes born of stupidity.
• Experienced developers make mistakes only born of stupidity

Aside from the fact that this is inherently true (an experienced person, by definition, cannot make a mistake born of inexperience), it is important to note – experienced developers make mistakes!

Computers do not. Ever.

Another saying that I’m fond of repeating, the former statement being a key reason to do so, especially when consulting and or training clients on the use of ALM tools, is to never let a human do a machine’s work (and vice versa). Anything a machine can do, we shouldn’t.

Finally, there’s the fact that any time spent on doing what someone, or more importantly, something (i.e. your computer) could do, is time not spent on things only you can do (i.e. developing the product – which you’d probably prefer to do anyway). Ask yourself this – while you’re manually doing repetitive work – who is coding? Nobody.

This holds true for building, for testing, for releasing and deploying, and basically for anything that you can (and know how to) automate.

In all but the simplest and most straightforward scenarios (usually short-term, one-shot projects), you should find ways to delegate work to a machine.

5. Defining the Work Makes Change Management Easier

It’s all great when you’re hacking away at that pet-project of yours and you’re in the zone, but a week later, a month or even three later, once you start delivering a second or third release of your software, keeping track of what was done, when – not to mention writing release notes, becomes extremely difficult, if you don’t know what your changes are or were. In fact, if you use an ALM tool for tracking features, changes and defects, and associate them with automated builds, you can generate a release notes document automatically with every build, and not have to deal with it yourself.

The other kind of change, is change of management. Today this may be your solo project. Tomorrow, who knows? You may take on a partner, give someone else the code to maintain, or decide to open the source. If the only definition of the work is whatever lies inside that wonderful brain of yours, hand-off will be a bear. Trust me. I’ve had to waste two weeks once receiving a project, and I still don’t know everything about it. Finding out stuff on my own is not the best use of my time. Having a nice set of features, tasks and bugs (past and open both) shortens the time, and makes discovery pains all but gone.

Conclusion

In summary, I’d like to state my opinion that in most (again, all but the simplest and most straightforward one-shot) software projects, proper ALM is as useful and important when flying solo as when developing with a team. Lack of communication issues (though see point #5) are balanced by the increase of work of having to do it all by yourself.

Just do it right the first time. You’ll thank me for it.

Best Regards,
Assaf Stone
Occasional Solo Developer

Technorati Tags: ALM,Software,Development,Testing,Building,Code,VCS,Git,Solo

One Team’s First Sprint Planning Session

This post is a bit different than my usual ones. Instead of orating off of my soapbox, I’d like to share a moment of agile bliss that I had today. One of the teams I work with at my customer’s company conducted their first “truly agile” sprint planning session. This post is a recount of the experience.

What Came Before

About a month ago, I began working on agile methodology training for a few teams at my client. The focus of the training was team work-process, mostly using Scrum as a template for how we will do things, with a few Kanban inspired overrides. In my first few sessions, I focused on what a user story is, what a task is, and the concept of focusing the team’s energy on completing user stories as fast as possible.

What I taught them boiled down to a few key take-away points:

• A user story is an independent increment in functionality that is valuable to a stakeholder, that can be completed by the team in one sprint
• A task is one developer’s day of work, on one component of the system that is affected by its user story, or work that needs to be done to meet the team’s quality standards.
• Each team member pulls an unassigned task from the most important, unfinished user story

Initially there were arguments on all points: “Our stories are too big for one sprint”, “What if a task takes more or less than a day?”, “It’s easier to assign a story to a developer”. I had to convince them that these basic ideas are important and valuable, or at least to give them a try.

The Man’s Too Big…

What we did was take one “too big” user story, and look for some way to break them down in to thinner vertical slices. We ended up with stories that use naïve implementations, or serve a smaller set of clients, or handle a smaller set of scenarios, with further stories that cover the difference in robustness, clients and scenarios.

With regard to the tasks, I suggested that we simply split tasks that feel too big, or join tasks that feel to small, and not to worry about their actual length. We’ll measure the averages and variance after the end of the sprint, and look for better ways to be more predictable as needed. It was more of a let’s simply try it solution.

The Man’s Too Strong!

The longest argument was over whether the first story warranted having multiple developers swarm on the tasks until the story is complete. One developer felt most strongly that it’s a waste of time to have multiple people learn the story, since we’re certain to complete it in time either way. Another developer didn’t want to be pegged in just the server (or client) coding tasks of each story, and felt that owning a whole story gave her more satisfaction. She also expressed concern over the pain of complex merges. Incidentally, it was mostly the QA engineers that immediately accepted the value of working on one story’s tasks in parallel.

Here are the points I made to alleviate their concerns:

• Having multiple developers learn a story is a great benefit, as it will allow flexibility in task assignment now, and further down the line in future sprints that may have related stories
• Having more people understand the story will eliminate bottlenecks (and increases the team’s bus factor – a good thing)
• Regarding the perceived focusing on one component, some other team member chimed in, suggesting that nothing would stop her from taking a client-side task in one story, and a server-related one in the next. I was really happy that other members joined the discussion; it was no longer a teacher-class relationship, but a team of peers
• I also reminded the team, that since we define a task as the work on one component for a day, and since we focus on completing one story before moving to the next, we are actually reducing the chance of two developers having to manipulate the same object at the same time – which of course reduces the merge conflicts! Further effort can be made to remove the rest of the edge cases almost entirely
• I further mentioned that there will be at least two members working on each story in any case: one coder, one tester.

Planning the Sprint

The rest went by rather smoothly. The team calculated how many expected work days they have in the sprint. I suggested that we simply add them up, rather than trying to split along the lines of coder / tester days & tasks.

I noticed that the backlog had some free-floating tasks, i.e. not related to any user story. I asked the team about those, stating that unless there is some value to a stakeholder, the task may be a waste of time. The team told me that it was technical debt. After some discussion, we agreed to deduct the tasks from the available work days, rather than creating fake user stories – we have to own up to the fact that we are paying back a debt to the system, not adding value to it.

The team-leader-turned-part-time-product-owner gave a rough stack ranking (there were several items high on the list with the same rank). I suggested that if he doesn’t care which of the same-rank stories we complete first, I’ll set an internal rank by the order that they appeared in the spreadsheet. He accepted.

Next we started explaining and breaking the stories. Traditionally, the PO explains the stories in the planning session’s first half, and the team breaks them down in the second. Since the PO in this case is a team member, and fully savvy of the product and solution, I suggested that we simply run down the list until we have as many tasks as we have work days (see how that works out?).

The first story was easy. We created 4 coding tasks and 2 quality related tasks.

Break it Down!

The second story was a whopper. We knew it would take most of the sprint. One developer suggested that we split the story by data source – one part retrieving one source’s data, the other part retrieving the second source. the team leader shook his head. “The customer needs both”, he said. There is no value in supplying just one. We’ll split it some other way, if we have to”.

You couldn’t erase the smile from my face with truckload of erasers. I knew for sure that he got the idea of what a user story is!

With the second, larger, story, the team leader frowned and looked at the task list. “This doesn’t feel right” he said. When asked what the problem was, he said that one task is too big – it will take longer than a day. The team then split it in two parts, and added a third task.

And we were done estimating and committing. Just like that.

All in all, we spent about an hour of planning, 2-3 minutes of which were spent “estimating”, which is to say deciding how to split that “too big” task.

An Agile Manager in a Brave New World

At the end of the meeting, the team leader expressed his regrets that we don’t have a full-time technical-product-manager (TPM) which is the closest role they have to a Product Owner. The group manager, who was present for the Sprint Planning picked up the impediment and answered “Let’s take it offline; I’ll try to get one to join the team ASAP”.

Yes sir! The manager became the Scrum Master’s Scrum Master, as per my suggestion in my previous post.

Here’s What We Didn’t Do

There are several things the team didn’t do:

• Defining proper user stories – I didn’t bother following the ceremony of form with the stories, declaring the reasoning and the interested party. I ignored this because I wanted to avoid too much change-shock at once. Next sprint we’ll focus on that. For now, I felt that understanding the concept of value was more – well – valuable
• Estimate the effort involved in the stories. Personally? I hate estimations. I think they’re useless, most of the time. I noticed that most of the time spent in a sprint planning session is wasted on planning poker, story points and ideal hours, and in the end – they don’t help the project’s predictability in any noticeable way. Instead, we’ll measure, and seek a low-variance way to split the tasks. That will be better. and cheaper

In the End

All in all, it was a great first “agile day” for the team. It was fast, to the point, and everybody participated in every part of the session. Tomorrow I will work with them on building their Scrum-board, and walk them through their first “real” daily meeting. I can’t wait!

So, what do you think? Want to hear more such experiences? Is there anything I did that you like? Something I could have done better? Please drop a comment. Don’t be a stranger!

P.S. A special thank you goes to Mark Knopfler, lead vocals and guitar legend from the Dire Straits, for inspiring the titles of two sections, in his wonderful song.

Technorati Tags: Agile,Scrum,Sprint Planning,Estimation,User Story,Task,How To,Team

How to Break a User Story into Tasks

One of the vaguest aspects of Scrum is breaking stories into tasks, which is done in (the second half of) the Sprint Planning. Most of the questions I get when training or coaching boil down to one question: “How do I break a user story into tasks”?

Defining The Problem

My favorite definition for a user story is that it is a thin, vertical slice of functionality, describing a small increment in value to the user (or customer).

A task, on the other hand is a step taken by the development team, required to fulfill the requirements of the user story. I further like to define, as a rule of thumb, that a task should take half a day to 2 days to complete.

The question therefore should be what are the steps the team needs to take for the story to be considered complete?

Look at Your Architecture

Explicitly or implicitly, your project has an architecture. It might be anything from a master piece drawn out in painstaking elaboration by a the architecture team, to a high-level conceptual architecture diagram. You should look at the components in your system, and ask your self which components do you need to modify (or add) for the story.

For example, Let’s say that we have a product that is a social networking web site of some sorts. given a story such as In order to broaden my network, as a user, I want to be able to import contacts from Gmail. Looking at a typical architecture for such a product, my tasks could be something like:

• Add a new Import Contacts page
• Add a service to get contacts from Gmail
• Modify the contact class to accommodate Gmail specific data (let’s assume such exists)
• Modify the contacts data schema

Assuming these tasks are right-sized (4-16 hours), that’s it. If one of these tasks is bigger, break it down. If a task is smaller, merge it with a related one (if such exists. If not, don’t sweat it. My 4-16 rule is just a guideline). We now have all the tasks for us to complete the coding of the story.

Look at the Definition of Done

Of course, just coding your story isn’t sufficient for the story to be truly done. In Scrum, “done” means ready to ship, or as I like to define it: the story is as it will be received by the customer / user. Agile teams have a list of requirements that should  be true for any story they complete. You should look at your Definition of Done (DoD) to see what tasks remain.

For example, let’s say your DoD includes the following:

• Code Complete
• Automated UAT (User Acceptance Tests)
• Documentation is updated
• Added to shipping package (e.g. InstallShield)

In this case, you should add tasks that help you achieve the story’s DoD. For the above example you might do the following:

• Write UATs for the story
• Document the Contacts Import feature

Assuming you didn’t have to add any new assemblies (i.e. libraries, packages, DLLs, executables, etc.), to your installation, you probably wouldn’t have any need to modify your packaging tool. No need to add a task for that.

That’s It!

You now have 6 tasks for the story:

• Add a new Import Contacts page
• Add a service to get contacts from Gmail
• Modify the contact class to accommodate Gmail specific data (let’s assume such exists)
• Modify the contacts data schema

• Write UATs for the story
• Document the Contacts Import feature

You can now estimate how much time each one will take, and are ready to move on, and break down the next story.

Technorati Tags: Agile,Scrum,Tasks,Sprint Planning,User Story,Definition of Done