If you just do what’s on the list of things to do, I think you can accomplish decent things, but nothing great.
I don’t dare saying this is a general truth for everybody creating something new, so let’s focus on software development.
There are many management models, and many of them boils down to something like “do the things on this prioritized list”, and the list might be items in a detailed project plan, a Backlog, test cases or sticky notes.
As an attack, and a defense, of these systems I’m saying:

to accomplish something great you got to do a lot more than what is on the list

The reason for this is that you cannot in advance know about all important things and possibilities that are associated with what your team is trying to accomplish.
Great software has even more than the right capabilities, impeccable reliability, super-performance and perfect usability.
There are no Gods in software development that can specify the details in advance.
And if there was an almighty capable of doing this, it would take too much time to read and understand all items on the list.

If the input for the software is taken from the actual demands of the customers, you can give them what they want, but not necessarily what they need, and probably not something that will be very valuable for many customers. And the item on the list will probably focus on functionality, without all implicit details around quality characteristics that can sum up to a great product.

So the solution is to take height for this, for example by
* not performing (detailed) time estimation and planning
* allocate time for “creative slack”
* pad all estimates with an appropriate percentage
* add extra time for polishing (that must be spread out from start to finish)
* rotate free, unscheduled roles
* encourage everybody to pursue interesting things that emerge
* perform one unscheduled “good” thing for every other item on the list
* schedule vague items that can mean almost anything
* but most importantly: have skilled people doing their best to create valuable software

Imagine that you run a software consultant shop where you take on projects for customers. The projects cover such areas as new software development; implementations of IT systems; and web site development.

Let’s say that you are about to create a offer for a new project to a customer.

Do you dare to specify the proper amount of hours dedicated to software testing? Or do you feel ashamed of having to test the software before letting the customer lay its hand on it?
Do you just add a couple of hours as a separate post so that it doesn’t look bad if someone asks about “any software testing planned”?
Do you include all the software testing hours needed in the total estimate? Or included in the total per function?

I think that we should treat software testing as any other task that are needed in order to develop functionality so that the hours that are specified per function/requirement/area covers all necessary actions and tasks in order to deliver ready functionality.
If you include such tasks as Design, Interaction Design, Specification, Requirement Analysis, Architecture, Coding, etc, you should also include Software Testing amongst these tasks. And you should be proud of doing Software Testing!

By including software testing in your time estimates, you give yourself a competitive advantage. When your customer selects between several offers and sees that you have included software testing and some of the competitors haven’t, it is a signal to the customer that makes them wonder why the others haven’t got any software testing (or why they haven’t specified any). Your offer might come out as a more expensive one, but since you have specified the difference it becomes obvious that they cannot just compare the price tag.

What are your thoughts on this?

This was originally meant as an answer to the (ironic) thread http://thetesteye.com/blog/2009/06/long-live-the-waterfall/ where a new thread was forked when Ola Janson launched a couple of questions regarding agile development. My answers and thoughts on those questions are listed here.

In one reply to Ola, Rikard says that he has “…never worked in a truly Agile project…” but what is a “truly Agile” project really?

I have worked in both agile (quick and well-coordinated in movement) and Agile (http://www.agilemanifesto.org/) projects.
Here are my thoughts and observations.

• Being agile as a team could apply to any jelled team with a developed group dynamic which manages to quickly respond to problems that might arise. It could also be applicable for any team that has ability to minimise the cost of change instead of trying to avoid the change. I have been in such teams.
• Being Agile as a team is when the team agrees upon the Agile Manifesto (Note: remember that the Agile Manifesto is a set of values and not a set of laws). I have been in such teams.
• XP, Scrum, DSDM, Lean, Kanban, etc are process tools in that they help you work more effectively by, to a certain extent, telling you what to do. These process tools must live up to the Agile Manifesto and are described practises for how to work in an Agile fashion more or less structured; each method has its benefits and drawbacks and none of them are comprehensive. That is why you often see combinations of different “Agile” processes e.g., XP (developing method) and Scrum (team management method) and Continuous Integration (incremental build method).
• You can work in an agile team and still utilize Agile methods such as Scrum or XP; but you could also use other non-Agile methods and still be agile.
• You can work in an Agile team and don’t utilize any of the big recognized “Agile” methods.
• Being a tester in an agile team (or project) is gold.
• Being a tester in an Agile team (or project) can be a smooth experience but it could also be painful. My experience is that if you as a tester are not engaged or involved in the team you will have difficulties. E.g., since documentation is not prioritised you need to know more about the software continuously and therefore there will be problems if you are not engaged in the day-to-day development of the project. And many times the team has been forced into working according to a specific Agile method that does not seem to be suitable for the context of project; and it might be very well suited for programmers but not at all suitable for the testing tasks.

The key thing with the agile movement, as I see it, is that the methods on how to develop software have evolved from the project context and, perhaps most importantly, being defined by the team members themselves. Therefore I believe that those projects have had a successful outcome, at least from the team-perspective. Many times it has correlated with business success.

The Agile movement on the other hand, which originally has sprung from the agile movement, has become more and more strict and promoting “best practises” on how to work Agile. This has become the new cash cow for many consultant firms and they of course promote and teach the “real way” of doing things. But I guess that many founders of the Agile Manifesto really think that it should be more agile than Agile…
So nowadays there are, and will be more and more, voices raised which question the new face of agile/Agile and instead promote the “original” thoughts; or at least the thoughts that they believed in then and still do.

My conclusion is: Find out what matters for you; your team; and project. Define a process that will work for you.

Read more about Agile vs. agile:

• Agile Versus agile Development - http://www.agilejournal.com/articles/columns/from-the-editor-mainmenu-45/18-agile-versus-agile-development
• Defining Agile Methodology - http://www.satisfice.com/blog/archives/45

Find out if your team is agile (or is it Agile?)

• Back-of-a-Napkin Agile Assessment - http://testobsessed.com/2008/11/28/back-of-a-napkin-agile-assessment/

Examples of reactions on current Agile methods:

• Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism - http://arxta.net/
• Cargo Cult Agile – http://www.exotribe.com/node/16
• WAgile - http://www.parlezuml.com/blog/?postid=708
• Who Stole Agile? - http://www.satisfice.com/blog/archives/51

Group dynamics

• Read about “Jelled team” (and other interesting topics) in Peopleware - http://www.dorsethouse.com/books/pw.html

A cheer to those of you who were able to attend this conferance: http://www.waterfall2006.com/

My favorites:

http://www.waterfall2006.com/crispin.html

http://www.waterfall2006.com/jeffries.html

Thank god everyone is not a believer of the hype around the Agile Movement. Process is king!

Lets say that you have a bug system; and for each bug you have the two fields “State” and “Resolution” where the following values are valid:
State: New, Assigned, Resolved, Closed.
Resolution: Fixed, Invalid, Won’t fix, Duplicate, Not Repro.

Further, you have a field where a product version number should be entered; i.e., the earliest version number of the product where the bug can be reproduced in.

Now, lets say that you report a serious crash bug that is reproduced in the latest build of the product e.g., version 1.1.2. (Oh, I forgot to mention that you work as a software tester at a software company and this happens during development of the upcoming release of your product.)
Two weeks later the bug is resolved by the assigned developer; the State and Resolution is set to “Resolved – Not Repro” and the following comment is added by the developer in the bug:
“I cannot reproduce this anymore (code is same as in build 1.1.4). This might have been fixed when other bugs in the same area were fixed. Resolving as Not Repro…”

So what do you think?

Do you think that this bug should have been resolved as Not Repro?
If not, what resolution would you have chosen?
Would it make any difference if the resolution “Works for me” had been a valid resolution instead of “Not Repro” (as in Bugzilla)?
Any other thoughts on this?

With subproject I mean when larger project have a need to split the project into minor parts. The essence of a chicken race is “Each player prefers not to yield to the other, the outcome where neither player yields is the worst possible one for both players.”

The goal for the larger project should be to release in time, with expected quality and so on. The goal for each subproject is usually to do their part and then integrate with the rest. The big problem is when something goes wrong or when one of the subprojects are delayed. In an unhealthy situation the subproject will not tell anyone. They will do all in their power to wait until someone else speaks out that they have been delayed or have problems of some sort. At the project meeting where all subproject managers are asked about delays, quality etc they will hold up a illusion of success. This can go on for a long time. Everyone is waiting for the first one to speak out, letting the rest get some extra breathing room and perhaps some extra time. The whole situation has turned into a chicken race.

The subproject managers will go about each other trying to see if someone is infact late and perhaps bring it to the surface. It is very apparent that everyone might be working towards their subgoals, but very much against the major goal. Naturally this is not always the case, but I have seen it happen many times. It is probably most common when there are many subcontractors and when the company culture promotes this behavior.

My only advice is stay to the truth, as you see it. If you are delayed do tell the others so that they can plan accordingly. In many cases you can change from making the short term decisions which might be costly, to more long term decisions that will be better for everyone. Keeping an openness amonst the subproject managers and über project managers will enable you to move more swiftly. Still, in some cases you might get kicked out as a subcontractor if you are delayed, in those cases you had better have a good plan B.

”Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team’s established development process and policies.”, see http://trac.edgewall.org/

This is a very nice light-weight tool. Some of the features:

• Got a wiki
• Possible to connect to SVN to see changes
• Easy to link check-ins with tasks, bugs, etc
• Setup milestones for planning
• See timeline for project management

I can highly recommend this tool if you want to do project management to some level while at the same time utilizing the benefits from SVN.