A software testing plan provides the backbone of the entire software design, development and installation process. Carefully considering all the aspects of a testing plan will help ensure success when starting the software design process, giving a clear direction and path. The testing plan provides information as to how success is defined and how it will be achieved – these are key aspects to making sure the product designed will address the actual needs of the internal or external client.

In an attempt to ride the wave of backronyms like INVEST in your user stories and DEEP product backlogs (though they are now supposedly DEEO ;-)), here's my rule to create task lists for doers.

I am childishly pleased with the backronym, but I'm pretty sure it's not foolproof: can you think of other characteristics that make a good task list? Let me know! Anyhow, here goes…

To use Scrum, you arguably need to apply it wholly. However, some practices are not unique to Scrum: practices all teams can benefit from.

It might also be an eye-opener for people, making them more inclined to turn fully agile. I recently switched from a project doing Scrum to a team with no clear project methodology or framework: the change in the level of communication and willingness to change and improve was striking. I think these three things alone would go a long way to improve the situation.

This is the fourth post in a series about hidden project changes: things that affect scope but are easily overlooked. The topic for this post is third party APIs.

You often have to rely on third parties to finish a project. Having a dependency on third party code is a big commitment though, and you should consider it carefully.

If you have no choice but to use a certain API (perhaps it is a requirement by the customer or the only one available) reviewing it is especially important to provide accurate time estimates and properly analyze associated risks.

In six posts, I have written about agile roadblocks: obstructions for implementing agile processes. The time has come to conclude the series with a summary and a couple of final words.

The theme of the series has been issues you might be facing when migrating to agile development.

Agile principles are easy to understand but can be difficult to master, and the transition to agile can be as complex as the problems it tries to solve.

This is the third post in a series about hidden project changes: things that affect scope but are easily overlooked. The topic for this post is ambiguous requirements.

One of the conditions for a waterfall project to succeed is comprehensive requirement specifications.

You supposedly plan the whole project in the beginning, during the planning phase. Anything that is not clearly stated, without room for interpretation, potentially leads to contract negotiations, which in turn might lead to a damaged relationship with the customer and - in the worst case - the project failing or being canceled altogether.

In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Cross-Functional or Dysfunctional”.

Cross-functionality leads to autonomous teams where complete features can be developed independently. One roadblock to achieve cross-functional teams is organizational silos¹. Another potential problem is the common misconception that individuals need to be cross-functional.

In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Predicting the Unpredictable”.

One reason behind the success of agile methodologies is a new approach to estimating work.

Traditional estimations fail of at least two reasons: they are based on calendar time, and they are done for the complete project directly.

In addition, estimates are sometimes calculated by people other than the ones that will do the actual work. How's that for commitment?

This is the second post in a series about hidden project changes: things that affect scope but are easily overlooked. The topic for this particular post is team configuration. Feel free to read the previous post about shared code base, too.

Let me first explain what I mean by “team configuration”. To me, it does not only include who’s on your team.

This is the first post in a series about hidden project changes: things that affect scope but are easily overlooked. The topic for this post is shared code base.

You are sometimes asked to work in the same codebase as the customer. This is usually the case for resource consulting, but can be true in projects, too.

In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Man Overboard!”. (Also read the previous posts: stray team members, drowned by waterfalls and lost in translation.)

Scrum teams are supposed to consist of highly motivated, cross-functional and self-organizing people. What if someone is not on board? How do you deal with people that are not motivated and don’t want to adopt agile processes and team practices?

You might find yourself in situations where you are asked to use Scrum and have people on your team that are used to working alone, or using other methodologies, and simply don’t want to change.

The project management triangle is an illustration of how a project’s constraints correlate.

It is a useful tool to help stakeholders and customers understand that they can’t get everything (“pick any two”). It can also be the starting-point for discussions about a project’s relative priorities.

In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Lost in Translation”. (Please read the previous posts about stray team members and drowned by waterfalls as well.)

People are eager to migrate to agile processes such as Scrum. There’s a lot of talk about sprints, scrum boards and retrospectives. One thing that is overlooked is understanding why agile works and the rationale behind it.

Many customers prefer fixed price contracts. It makes them feel secure. They know what they will get, when they will get it, and how much it will cost. Or do they?

Pitching contractors against each other on a fixed price may seem like a good idea, but what effects does this have on bids, the project, and – consequently – the final result?

In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Drowned by Waterfalls”. (Read the previous post about stray team members as well.)

Often agile processes slowly make their way into larger organizations. Parts of management may not even be aware of any changes. Others may be too rooted in existing processes and methodologies. They consider any change an annoyance that will eventually go away if you just ignore it.

So, how do you apply an agile development process when drowned by waterfalls?

This is the first post in a series about agile roadblocks: obstructions for implementing agile processes. First up is “Stray Team members”.

To share resources between projects seems to be a more common practice than one would expect. What’s worse is that often it is done seemingly without good cause. Some managers do not understand the impact this has on productivity, and the well being of the individual.