Monthly Archives: October 2010

Consultant’s Rules?

Leave a reply

Wow, it was a shock to read Gerald Weinberg’s “A Code of Work Rules for Consultants” blog.

While reading the lead-in to his list, I kept finding myself saying “really?” and “ugh!” I enjoy being blissfully ignorant and sheltered, I guess. Here is Gerry’s list:

  1. I will not work for an organization whose goals are not consonant with my beliefs.
  2. I will not work on projects whose goals I do not understand, or cannot agree with.
  3. Before becoming part of a project, I must first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.
  4. I will not work under measurement schemes that pit one person’s performance against another’s. Rather, I will co-operate totally to help others in the project achieve their full potential, as I expect them to help me do.
  5. I will not accept work without understanding what is to be done, and why. Nor will I pass work to others without their similar understanding.
  6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by security considerations). Furthermore, I will always stand ready to review the work of others in exchange for them returning the service to me.
  7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my client and their project.

It’s almost a shame that Gerry had to post this list — in that it reflects a state of affairs that he and others have observed (I trust). I naively assume everyone innately follows Gerry’s rules — as I think I have done my entire 35 years of working (including starting out having a paper route in middle school and washing dishes at 15).

Knowing better, however, that your picture of reality is just that, I always advise that folks (employees and consultants, alike) need to be financially sound/independent. If you live paycheck-to-paycheck, it is harder to buck the system than if you have a 6-month or greater cushion of savings.

TIP: Just start out with small goals, putting savings aside until you have one month of living expenses. Before you know it, you will have two months, six months, a year or more! It is truly liberating to have that cushion! Naturally, incur as little debt as possible so you are not haunted by that “anchor.”

So, to Gerry’s initial list, I humbly suggest he add the following:

“8. Be financially sound so that you can stay true to your principles and not be chained to a paycheck.”

Be an Agile Survey Monkey

1 Reply

There’s seemingly quite a bit of a dust-up over assorted agile surveys:

  • Scott Ambler’s 2010 Scrum Certification Survey.
  • VersionOne’s “State of Agile” survey.

I did Scott’s simple survey last week. I did the VersionOne not-so-simple survey the other day.

After someone dissed Scott’s efforts and praised the VersionOne effort, I replied:

I could poke serious holes in the “State of Agile” survey. I mentioned a flaw or two back to VersionOne (i.e., I replied to the email with the link).

But I won’t. It isn’t worth my time.

Surveys are extremely hard to design. I submit that the VersionOne survey has a flawed model of development projects underlying the questions—not that it stopped me from supplying answers. And when you toss it out to self-selection, it gets even weirder to draw major conclusions. And to get subjective info on being more productive with agile, etc., is anything but accurate.

If people make decisions based solely on someone’s survey (or certification or education), it’s a free country.

Good luck with that.

I would never be so foolish.

Scrum Dust Up

Leave a reply

This post is in response to this:

Kripanidhi said the following on 10/25/10 9:34 AM:

Scott,

It may have been a very interesting and useful idea to have included one more question in your survey:

“How many Certified Scrum …..Masters, Teachers, etc know how to code or have ever written a piece of software that was paid for ? ”

I could easily speculate that figure at less than 50%. Can guys who have never hacked in their lifetime, call themselves Agile ? and worse still teach others how to hack and Scrum ?

Food for Thought

I view Scrum more like a form of Project Management. Nothing more. Nothing less. But I might be mistaken. I am not certified. At least not in that way.

Anyway, given that as my starting point… I am not sure if teaching how to do a particular style of Project Management (e.g., CSM) requires knowing how to do the work that will result in the end goal. AFAIK, Scrum can be applied to many things beyond software. Even for software, does a good PM have to know how to do great graphic design, or be a brilliant UX person, or be the most awesome coder/hacker? Maybe folks drawn to CSM actually realize they can do more for the project than simply do mediocre coding.

Now, would knowledge of the “how” help a manager be a better manager? Probably. But isn’t a truly good Project Manager (Scrum or otherwise) cognizant of the need to trust (but verify) their folks to do the right things? Sure, sometimes it is helpful to question an estimate, or critique a design approach, or help shape the product roadmap, or ask probing questions… But does that require intimate knowledge solely on the part of the CSM? Or does it require a good team effort? To turn the argument on its head: is taking the best coder out of the loop to be the CSM a good idea?

Despite my personal preference for (and being) generalizing specialists, I do not think it is a fair pass/fail “litmus” test to say a CSM has to be a hacker/coder/doer of everything.

Personally, I don’t think we have to challenge the CSM individual’s hacking skills. After all, do hackers inherently make better managers? Rather, we should challenge the terminology that bestows the ludicrous moniker of “Master” after a few days of classroom training. Of course, as a counterpoint, the concepts behind Scrum are simple enough to be mastered in a couple of days — that’s the beauty of a simple technique. But the skill of being a Project Manager can take a lifetime to master, Scrum or otherwise, IMHO.

I think what is worse is the blind-faith that someone who has been certified as a CSM is qualified to run an agile project. Or the illusion that everything else we do can suck, but as long as we have Scrum, we’ll succeed.

The beauty of a free market: this CSM brouhaha will sort itself out. Companies will learn one way or the other that there is no magic bullet to hiring (despite the world’s stupidest job postings for CSM folks), nor is there a silver bullet to getting projects completed successfully.

Using Basecamp in an Agile Manner

Leave a reply

Software Development Life Cycle

In software development, we want to make our process as visible as possible to all participants and stakeholders. To that end, behold a simple process that uses a handful of Basecamp To-Do Lists as markers for how a feature or bug is working its way through this process.

At any point in time, you can look at the “To-Do” list page for a status on your favorite new feature, task, or bug. And, if you have a chunk of features piled up in an “Iteration 1” list, you can see the number of items being worked through to completion. (There are even third-party apps that allow you to do burndown charts if they appeal to you.)

Using Basecamp's To-Do List in a simple manner

Requirements/Bugs

The business has a desired priority for features as expressed by the order of items in the “staging” lists, and especially the On-Deck list (to borrow a baseball metaphor for “What’s next”). For major new features, the business and the developers will work out a rough Release Plan. But for simple enhancements and bugs, the business can simply add desired items to the lists.

Development

The Developer will pick a new task off of the top of the On-Deck list. There will usually be a conversation around the issue to ensure proper understanding (unless it is self-explanatory). Ideally, we get the business/testers helping to write User Acceptance Tests in the BDD form of Given… When… Then… The Developer moves this feature into the “In Progress” list. If desired/possible, the user could add a date estimate for the task.

The Developer will create tests, be they Cucumber, RSpec, or UnitTest, or all 3 types. If possible, the Testers can help write the up-front acceptance tests, so that they are intimate with the feature/bug. The Developer writes code until the tests pass.

Once the issue is complete, and the tests are passing (and you didn’t break any other tests), the Developer: commits the code, updates the TEST server, and does a smoke test to ensure things still work as expected. The Developer then moves the task to the “To Be QA’d” list, where the Testers will now verify the issue is indeed complete and correct on TEST. Close collaboration between Tester and Developer is warranted here, as the nature of the fix and any developer tests can be explained so that testing can be as effective as possible. Plus we want to maximize use of automated tests, and minimize any unnecessary manual tests (as they are time consuming and expensive) given the nature of the code changes.

Testing

If the QA passes, the Tester moves the task to the “To Be Released” list. Depending on the nature of the feature, the Business can also help to “test” and ensure things work as expected. If the test fails, then the task is moved back to the On-Deck list and the details added to the issue as comments (if simple) and image uploads (add image link to the comments), or to the issue tracker if it is more complex (even though it is technically not an issue against the released product).

Release

The Developer will schedule the move for “To Be Released” tasks to the PRODuction box. This may require coordination with the client’s IT team if they have internal controls. Following release, the application is smoke tested to be sure the basics are still functioning. If any problems arise, the server can be rolled back, or fixed ASAP, based on the nature of the error.

Once the items are released to PROD, you can indicate that they are “complete.” If the issues came from a list that you want to keep for posterity, simply drag the completed task to the original list (“Iteration 1” for example). Now you can see the items in that list that have been released (i.e., completed).

Summary

I’ve used Jira and much more elaborate SDLC schemes in the past. But a recent Rails project with just a few folks on the team, found us trying out Basecamp. By creating various lists, we can mimic the Kanban-style wall board that Greenhooper provides within Jira. Because the lists allow simple ordering to show priority, and you can drag-and-drop between lists, and you can track your time, I think we have a very lightweight, winning combination.

This process is equally at home doing one feature all the way through, or an entire iteration’s worth of features in a bigger chunk. (Basically dependent on the cost of testing and the appetite of the end-user for changes.)

SDLC process[/caption]

Tale of the Demanding Consultant

Leave a reply

So, I just heard that a consultant canceled a gig at a company because — get this — the company did not move off of a big VCS system prior to his Scrum (etc.) engagement. (In the words of one friend, it sounds a bit like a temper tantrum or elitism.)

In my opinion, any consultant worth their salt would simply deal with it… the choice of VCS is *not* an issue. Neither is the choice of “Use Cases” or “User Stories.”

If you think these sorts of things are a big deal,

  1. go directly to jail,
  2. do not pass go,
  3. do not collect $200.

meh!

Consider this a “Bad Smell” should you face such a pre-engagement demand!