Failing Fast is a Good Thing

One of the benefits of switching to agile project management methodologies is the opportunity to fail fast. As a point of comparison, think about how waterfall projects work. The business requirements are assembled into a software specification. The software development team reviews the specification, creates the design and builds the software product. (I know this is an oversimplification) Some months later the software development team proudly shows the customer the software application in all its glory.

History has shown that this moment is often a moment that is less happy than expected. Some part of the software specification was not delivered as the customer wanted, or it was delivered as the customer wanted, but it’s really the wrong thing. Bottom-line, the software project or a part of the software project failed late. Ouch… It’s going to be expensive to fix…

Agile methodologies by the way they work encourage failures very early in the project. With agile project management methodologies, there are frequent software product demonstrations to the product owner. Typically at the end of each sprint / iteration the software development team demonstrates the software build to the customer. Here’s the chance to let the product owner catch parts of the software project that are off course and make corrections as needed. It is much easier and cheaper to make a change on three weeks worth of software development after a sprint than six months worth of software development at the end of a waterfall project.

Show your software to the product owner, let them find problems and fix them. It’s better to have a software project fail fast resulting in small changes than fail late and have a big mess.

Failing Fast is a Good Thing

User Story Format Thoughts

Recently I posted about a common user story format. I’m starting to see more and more discussion about this user story format and how some feel that it is too constrained. One proposal was to swap the value and actor sections. I’m trying to figure out an example of how to write this, hence my problem with this format. It does not seem natural and I really don’t see the value.

One of the great concepts of Agile is to inspect and adapt. While right now I don’t see value in changing the standard user story format, it does not mean that there won’t be a day when someone proposes a better way or writing user stories. When that day comes, I’ll inspect the new format and perhaps adapt.

User Story Format Thoughts

Communicating Agile

Here’s a surefire way to fail with your Agile implementation. Ignore the other parts of the business that are used to dealing with schedule driven projects. It’s not enough to get the project team onboard with Agile, you need to spread the word and sell Agility to as many people as you can.

Go on “Agile Tours” and give multiple presentations about your Agile Team and how you are working to reduce waste and speed the delivery of working code. Of course short presentation won’t be enough to cover Agile Methodologies in much detail, but do talk about the benefits of customer interaction, process inspection, use stories, communication, UAT and so on.

Take the time to build the trust that what you are doing is correct and is the right thing for the business. Plus in today’s economy you are focusing valuable resources on the highest priority items and will deliver results sooner, who won't want to hear about that?

Communicating Agile

Agile Thinking – Enhance Personal Productivity

It’s a tough world right now, most organizations are being asked to get more done with less. In an earlier post I talked about MoSCoW ratings as a way to prioritize user stories. MoSCoW ratings can be used to prioritize many things. Prioritizing tasks with MoSCoW ratings in a to-do is list is just one way of using Agile thinking to boost personal productivity.

When I am overwhelmed I use MoSCoW to prioritize personal tasks.

M - MUST do this task. In this context MUST is similar to Steven Covey’s Important / Urgent Quadrant. Schedule time to handle this task now.

S - SHOULD do this task. The world won’t end if it is not done today. But it’s a task that if it does not get done could lead to problems. This task should remain in your personal task backlog (to do list).

C - COULD do this task. This task is neither urgent nor important now. This task could remain in your personal task backlog (to do list) or be delegated.

W - WON'T do this task. Doing this task won’t move the project forward or provide any value. Delete this task.

We can’t add more hours in the day but we can spend the time we do have on the right things By looking applying MoSCoW ratings to tasks and responsibilities, you can make sure you are focused on the right priorities and remove waste by not spending time on needless tasks.

Agile Thinking – Enhance Personal Productivity

User Acceptance Tests - Test for Success and Build Confidence in Your Agile Team

Getting users stories from your product owner is one of many ways software requirements are conveyed to the agile team. However there is one key companion to the user story, the user acceptance test. The user acceptance test closes the cycle by providing the criteria the product owner will use the test the user story. The agile team can use both the user story and user acceptance test together to ensure they understand requirements from the product owner.

Just as when writing user stories, sometimes the product owners need help with writing user acceptance tests. It’s common to have a QA engineer assist in the process of writing user acceptance tests. I recommend using a QA engineer to make sure the software tests are clear of ambiguity.

At the end of the sprint, the agile team demonstrates the completed user stories to the product owner and validates success by executing the user acceptance tests. This software product demonstration confirms to the product owner that the software meets the requirements specified via user stories.

Running a software product demonstration and passing all the user acceptance tests is a big confidence builder for the team and the product owner.

User Story + User Acceptance Test = Clearer understanding of what the product owner wants and how the agile team can test for success.

User Acceptance Tests - Test for Success and Build Confidence in Your Agile Team