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

How to Manage a Self-Managing Team?

As we all know, there’s no shortage in confusing and counter-intuitive ideas and practices in the Agile world, but the idea of a self-managing team has to be one of the best. Indeed, the idea that a manager can manage a self-managing team sounds oxymoronic at best, and at worst – plain moronic. In this post I will try to clear the air and explain what it means for a team to be self-managing, and what is the role of a manager of such a team.

By the way, this post is the fourth in my series of Demystifying Agile. If you like this one, you may want to read the others.

What Does It Mean to Self-Manage?

A self managing team, or as it is sometimes also called, a self-organizing team, is, above all, a mature team. It doesn’t even have follow the percepts of any agile methodology per se, but in fact most do. Probably something to do with maturity.

The first thing such a team does is to take charge of how they do their work, which is to say, they define the tasks they will have to complete in order to deliver the solution (requirement / user story / feature).

They will also be in charge of estimating the cost of their work, decide what work they can complete until the next milestone (or iteration, or sprint), and commit to it.

They will take control over their development process and the responsibility of improving it in order to develop a better product, while reducing the cost, as much as they can.

They will (to some extent) be in charge of identifying anything that may impede their progress, any issue that may stop them from completing a task or meeting a deadline, and either resolve what they can, or report to their superiors what is beyond them to solve.

Depending on whether or not the Product Owner is considered part of the team, they will define what needs to be done: user stories and priorities.

In short, one must merely point them at a goal, and they will do everything needed to achieve it!

So What Do I need a Manager for?

As a manager, you may worry that you have become obsolete. Indeed, all but one manager I’ve worked with, has expressed some form of anxiety over this change and subconsciously hindered my efforts to help the team become self-managing. Incidentally, that one manager simply asked me to tell him what his new role would be in this new agile world. All I had to do was convince him that it will work (if you’re reading this, and you know who you are – thanks for making my job enjoyable!)

At any rate, you are not obsolete – in fact, you are needed more than ever; Your team(s) need you to do those things that nobody else can do:

First off, there’s the whole matter of human resources and financing (some might say it is the same). No agile methodology that I know of, suggests that the team is responsible for the following:

• Hiring new employees
• Negotiating compensation and benefits
• Purchasing equipment, software and other tools
• Authorizing personal absences (see below however)
• Anything else that is not directly related to the team’s work
• Yes - Firing a team member that cannot or will not do his job properly

Regarding the matter of personal absences, a mature team could handle the matter of absences by themselves, accounting for planned absences when planning the iteration, and dealing with the consequences when they are unforeseen. The absences would still be accounted and authorized within what was agreed in the compensation package, but the manager might be relieved of having to deal with the day-to-day issues.

What else? In a traditional hierarchy, a manager is in charge of team leaders, who in turn are in charge of the team. In an agile world, the team leader is often replaced by the Scrum Master (or Agile Coach), who serves the team by removing impediments from its path.

An agile manager could serve as the Scrum Master of Scrum Masters. A scrum master who encounters an impediment that he cannot resolve, needs someone to turn to. Enter the Agile Manager, the servant leader for the teams. With the backing of his position the manager can do more to resolve the issues than the scrum masters might do on their own.

All This Sounds Great, But How Do I Get There?

All of this may sound great in theory, but you know your team; they are simply not ready for all this responsibility. So you may wish to “thank” me for wasting your time, right?

Wrong.

Look back at the list of things that the self managing team does. Now back at your tasks. Now back at the team’s. Looks familiar? They are – or were – your tasks. Now look at it again. It’s their tasks, only you were handling their work for them!

Work with the team, relinquish these tasks, one by one, suggest that they take over them. This can (should) be part of their Kaizen, their continuous improvement.

Sooner or later – sooner, actually – you will find yourself the proud agile manager of self managing teams!

Now you will finally have the time to do all of those things that you never had the time to do.

Summary

The Agile Manager is the financer and builder of the self-managing teams he is in charge of. The agile manager is also the scrum master of scrum masters and solves the issues that they cannot resolve on their own.

The path to self management is not a short one, but not a very difficult one. You can get there, one step at a time.

Try it, I believe that you will find it rewarding and liberating.

If you have any experience managing self managing teams, why don’t you leave a comment with a pearl of wisdom of your own? Be a sport.

Technorati Tags: Agile,Scrum,Team,Self Management,How To