User Story Sizing and Acceptance Criteria
By · CommentsWhen doing sizing with story points people will get hung up on the details. They want all of the acceptance test requirements understood. The beauty of story points is that they have no units of time associated with them. We are just look at relative complexity compare to other stories in our back log. So if each story is at the same level of understanding it all works out.
It is not necessary to do detailed acceptance criteria before sizing. The acceptance criteria should be very general. Such as what is the expected result and what are critical negative cases. We do not need to deal with the wireframes or UI at this time. This will be done during the iteration planning. Here is an example from the a team backlog:
Confirm - Email - Indicate email not listed
As an agent, I want the system to provide an option, so that I can indicate that the email that the customer wants to confirm is not listed.
Acceptance:
Expected: Agent enters an email that has not been previously used and the system indicates the email can be confirmed.
Negative: Agent enters a email that is in the system and the system indicates the email cannot be confirmed for the customer.
Team Work
By · CommentsAgile relies on self organized teams. But most of us do not really understand what it means to work on such a team. The model I see most often is that the ScrumMaster or the Technical Lead will take control of the team.
I have seen one team where the ScrumMaster actually created all of the tasks for a sprint and assigned members of the team to work on these tasks. In other cases the technical lead controlled what tasks are created and made sure the team know who are working on the tasks.
I know that each team members may have special skills and it makes sense that they are the best choice but in doing this we loose the value of the team. A team functions best when we share knowledge with each other. It is great when you have a team in which members will help each other even if they are not the expert in the field. Also, a team protects itself when the knowledge is distributed among the team.
As team members we should be willing to learn new technologies. Also, team is more efficient because there is no “down” time.
When a team creates the tasks they are going to do in a sprint they assume ownership of those tasks. They have created the tasks and will be more likely to see that they get finished.
Demotivating a team
By · CommentsAgile methodologies support best software practices. One of these practices is that working together as a team is more productive then individual contributors to a project. But it is easy for a team to be demotivated.
We all start out being motivated. We like the work we do and we want to do a good job. So what happens? It is the situation we work in that demotivates. This includes the stress and company culture. This quote is from “Agile Coaching”:
These are factors that demotivate people if they are not present, even though these factors are not motivators when they are present. For instance, fast computers, decent coffee and fair pay won’t be noticed if they are there, but their absence can demotivate employees.
It important to be aware of what may be demotivating a team.
Introducing Agile Change
By · CommentsChange is difficult for all of us. We get comfortable in a routine and like to maintain it. This is especially true at work where we spend a majority of our waking hours.
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 :
- 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. - 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. - 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. - 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. - 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.
Personal Agility - Your development practices
By · CommentsWe often look at Agile adoption from an organization level but what about adoption at a personal level> What does it mean for you as a developer to adopt Agile methodologies.
Let’s start with your own developement practices. What do you value as a developer? How have you improved your development practices over the last year?
Here are some practices that an Agile developer should adopt:
- Test Driven Development.
This is more then just writing unit test, it is having the unit test drive your development. - Code refactoring
Do you leave the code you work on more readable and easier to understand? - Code ownership
Do you take responsibility for what you do?
I am sure you can add to the list. The point is are you constantly trying to improve the way you develop software.
Cool Under Pressure - Learn To Adjust
By · CommentsIt is a given that no project goes as planned. We all get into situations where we want to panic. Many times we see this when adopting Agile methodologies. A practice we put in place seems to back fire. The developers are actually less efficient. What do you do, there is a dead line to meet?
It is times like these that you must keep your cool. Carefully evaluate the situations. Take a step back and look at what may be causing the problem. Experts know that plans are not executed as hoped. They will readjust on the fly but still keep the goal in focus.
The beauty of Scrum is at the end of every sprint you can do a retrospective. This gives you a mechanism to adjust in mid-project.
XP eight hour burn
By · CommentsWe have been told that when developing using Agile we should get into a rhythm as a team. We should be working just 8 hour days. Now to many this seems absurd. No developer can get by just working 8 hours a day, what would my manager think?
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.
Being Passionate
By · CommentsHow often do we go about our jobs and have not real passion about what we do? When an friends asks what you do for a living what do you tell them? Do you say I work for company XYZ or I am a C/C++ programmers (or what ever you current skill is)?
Is there a skill you can teach others because you really believe they would benefit from learning the skill? Do others recognize an underlying passion to make your work place better or the world better around you?
So much about agile is about be passionate first about improving your own skills and the improving the skills of those you work with. Be passionate about improving!
There is much to change
By · CommentsThis morning I had a very interesting discussion about the culture at the company I work for. We as developers have been instructed to use a testing tool that our QA group uses. This is all well and good because the tool is based on JUnit and is XML driven. The problem is that the tool is only supported in the QA testing environments. The tools cannot be used in the regular development environment. So if developers do use the tool for tests it will have to be for QA regression testing and cannot be used in a test driven development (TDD) style.
This is very frustrating because TDD is the proven way to create quality software. Also, developers are going to resist using tools that do not enhance their job and the quality of their software. Who wants to add more time to an already tight schedule to develop test that one cannot use.
I was informed that our culture does not value testing by the developers. Oh, there have been directives that all new code will be unit tested but because good tools have not been provided this type of testing is spotty at best.
To do our job efficiently and produce top quality code we need to have environments that support us not hinder us.
The tide is changing
By · CommentsToday was one of those days when one sees months of effort pay off. The project manager and QA manager are really going to give the team a chance to do genuine agile development over the next 3 months. Our overall deliverable is not until the end of September but we will have a chance to work with QA and actually produce sequential releases for for multiple projects. This should be challenging and fun.