Quality starts first of all with the backlog. The customer’s highest priority user story is what is developed first. A quality product must first meet the customer’s expectation of what is important.

We will make the assumption that we have chosen the top priority user stories for a  sprint. How do we decide when we have finished the user story and it is ready to presented to the “world”.

There are three major areas of acceptance:

1.       Code quality

2.       Functionality

3.       Presentation (usability)

1. Code quality

a)      Is the design reasonable?

b)      Is the user story testable?

c)       Is the code well written?

d)      Have we followed a consistent data model?

e)      Are we following the best practices?

2. Functionality

a)      Is the code unit tested?

b)      Is the test data available?

c)       Have we worked on creating test fixtures?

d)      Does it meet the data requirements?

e)      Does it meet the logic requirements?

f)       Have we automated our testing?

3. Presentation (usability)

a)      Is the layout correct?

b)      Are all of the UI assets in place?

c)       Are all of the interaction components working properly?

d)      Is the data displayed correctly?

e)      Are the screens being displayed in the correct order?

f)       Is there valid wording all text fields?

Who is responsible for “signing” off on these acceptance criteria:

1.       Product Owner

2.       Quality assurance developer

3.       User interface designer

4.       The team

We all work together as a team to build the unit tests, automation tests and making sure the presentation in correct. The product owner creates high level acceptance tests. The quality assurance developer assures  the story in testable and creates the function test tasks. The software engineers work with the QA developers when creating the unit tests and automation tests. All during the process the team is working together to make sure the user story is acceptable at all levels.

We should not wait until the end of the sprint to have the quality assurance developers begin their testing. Once a section of code has been develop the QA developer should be consulted to make sure software engineers are meeting the requirements. Once a UI component is finished the user interface designer should be consulted to make sure it meets the requirements.

When all of these acceptance criteria are meet the story is done. It is very important the team does not over commit to the number of user stories that can be completed in the sprint.

The goal is a quality product that we are proud of and an our customers are very pleased with.

Let me give you an analogy. Let’s say you by a new delivery van (yes we need to help the economy right now) and you want to start using it in your business. Now you want to make the most of this asset. So you decide that you will drive it at 100 miles hour and that you will not take it into the shop for routine maintenance because you will not be able to make deliveries with it. How long would your new new delivery van last? Is this the best use of your new asset?

Developers cannot be constantly running at peak speeds. Eventually they will wear out. Also, they need to be able to work on skill improvement and have a chance to expand their horizons. Slack time in the schedule is important just for the sake of sanity.

Having a developer working on multiple projects is bound to wear them out. This can be displayed in lack of enthusiasm, increase sick days or just plain bad attitude.

What are the perceived benefits of multitasking:

1. A developer will always have a task to work on.
2. More projects can be staffed.
3. More development hours are recorded against projects.

But are benefits producing a good return on investment? Let’s look at each one of these benefits.

1. A developer will always have a task to work on

Every time one changes tasks especially on another project there is a problem of context switching. First one must take the task they are working on and save the information that is needed to work on it in the future. When starting a new task, previous information about the new task must be gathered and the task started. This may create considerable overhead with large tasks in different projects.

Also, a developer may choose tasks that are “easier” to do and avoid project critical tasks when making a switch. This makes them look more productive because tasks are getting done.

2. More projects can be staffed

It does look like company resources are be used more efficiently because more hours can be allocated. But are these really productive hours?

3. More development hours are recorded against projects.

We can all look busy but are we really productive.

One of the foundations of Scrum is that the team is able to focus on a project for a sprint.  This quote is from Scaling Lean and Agile Development page 142:

Do your job. Focus all your efforts and skills on doing the work that you’ve committed to doing. Don’t worry about anything else. In Scrum, work is not arbitrarily forced on people, and work cannot be added during the iteration. Nor is there any multitasking or distraction, because each team is 100 percent committed to the set of small achievable items chosen for the short iteration. There is no partial allocation on different projects; partial allocation means partial results. Each person’s time is 100 percent allocated to the goals of the iteration for the product. This provides the foundation for the focus and reduction in multitasking that leads to quick delivery and productivity

When a team can focus on a single goal they will be more productive. Assigning team members to multiple projects is a sure way of decreasing productivity.

Agile so many times starts at the developer level. Usually a team lead or manager has read about Agile and wants to use it with their team. That is the way I started, I was a team leader. This works great for a limited period of time util you run into the bureaucracy of the standard software development process. That is the time to start thinking of how to transition the whole company or division.

One concept introduced by Mike is the Enterprise Transition Community (p. 63).

The Enterprise Transition Community exists to create a culture and environment where change can be released by those who are passionate about the success of the organization and where success leads to more passion from more people. The ETC does this not by imposing changes on the organization but by guiding groups who are implementing changes, by removing obstacles to doing Scrum well, and by creating energy and excitement for the change.

In other words you need a team at the appropriate level in management to take up the Agile cause. They are the ones who will guide the agile adoption and remove the obstacles. Read this section in the book, it might help you in your adoption.

It becomes a challenge to Agile practices to an organization or a team because of resistance to change. Here are some ideas on how to introduce change :

1. Sell the team on the problem that needs to be fixed
   Many times we need to convince the team there is a problem. It is important we explain what the problem is and have the team agree that the problem needs to be addressed.
2. Have the team read about Agile
   Introduce the team to reading materials that clearly explain the Agile concepts you want to introduce. These may include blogs, white paper and books.
3. Attend Agile user group meeting
   There are Agile user groups in any metropolitan area. It is good to attend these meeting to get other developers opinion about Agile.
4. Do not be fanatical about Agile
   When you are passionate about Agile methodologies it is easy to be fanatical. This will turn people off because you do not listen to their concerns.
5. Choose one Agile practice to introduce
   To much change at one time overwhelms a team. Introduce one new Agile practice a month. This will make change easier because the team will have time to learn about the practice and apply it.

I read the following from the book The Passionate Programmer:

If you have 70 hours available [in a week] each hour is less precious to you than when you have forty hours available.

Here is another quote:

Bob Martin’s eight-hour burn places a constraint on you and gives you a strategy for dealing with that constraint. You get to work and think, I’ve only got eight hours! Go, go, go! With strict barriers on start and end times, you naturally start to organize your time more effectively. You might start with a set of tasks that need to get done for the day, and you lay them out in prioritized order and start nailing them one at a time.

Activities fill all available time.

Take on this challenge, this next week plan on working just 40 hours and make each one of those hours count.

This is prime example of the individual not thinking as a team member. This individual must realize they are a member of a team whose goal is to produce a successful product. We need to adjust to the needs of the team.

The scope of the requirements were not clearly understood by the product owner. Actually we do not have direct communication with the product owners and are using a proxy. Fortunately there are still drawing on the window which clearly showed the scope of the project.

Then we had miscommunication with the QA test plan. The test plan was never reviewed. and had tests that were outside of the scope of the project.

The project is also behind schedule and requires special exemptions to get into the current release.

I hope you understand that this was not a Agile project. These problems are ones that would have been exposed sprint plans and reviews.

Today I ran accross an excellent book, 97 Things Every Software Architect Should Know, 1st Edition. I highly recommend this book. It is easy reading but one of those books filled with axioms that we need to reminded of all of the time.

The first maxim is “Don’t Put Your Resume Ahead of the Requirements”. How often do we want to use a new technology because it will look good on our resume?

There are 96 more to go. You may disagree with what these experts are saying but they are thought provoking. Take a look at this book.