These aren't new ideas but they are true. The list below focus' on the things that organizations should be doing to help make their agile teams more productive.
- LET USERS SUBMIT ISSUES! Let users submit issue tickets. They may be bugs, feature requests...whatever. You need to start tracking it. Your users will sense that you place value on their needs and you will have invaluable data for prioritizing new user stories.
- GET USERS TALKING ABOUT YOUR SOFTWARE! Create a discussion forum or bullitin board for users to discuss the software they use. Creating a community around your software will help endear your users to it. Your engineers, product managers and other stakeholders should be encouraged to actively participate. Your team will gain great insight into how users are using the software.
- MAKE A USER AVAILABLE! Developers should have real-live users to contact and ask questions. Most of what slows delivery of new features is a clear understanding of how a user will use them. Many new features end up looking nothing like what a user was asking for. These features sit around and remain unused.
- TESTERS SHOULD BE USER EXPERIENCE EXPERTS! Put user experience experts on your testing team. If you don't have a testing team then become a user experience expert.
- CO-LOCATE THE "WHOLE TEAM"! XP defines the Whole Team as the developers, testers and users. Studies show that communication is a major linch-pin in the success of software development. Anything you can do to improve communication will pay off.
- EAT YOUR DOG-FOOD! Dog-fooding is the process of using your own software internally (eating your own dog food). If you use it then you will fix it!
- RELEASE OFTEN AND EARLY! Your users like to see new features! These days you absolutely MUST give users a sense that your software has a future. Your organization should never consider a project "complete". You must work iteratively and release smaller chuncks of functionality.
- ALLOW DEVELOPERS TO CHOOSE! The big boys know this one! Google does this and so does M$. Take advantage of your engineers' Creative Momentum and let them decide which project to work on. I would suggest that this can be done from iteration to iteration or release to release.
3 comments:
I would question that last point. If a developer can just leave a team whenever they want it seems like it would be difficult for a stable team to form. On the other hand, one might argue that teams which do form this way would be much more stable. The jury's still out for me.
Your not "forcing" developers to switch projects every iteration or every release. You're simply giving them the option to switch. Most developers will switch to a project and stay their for a while.
This works best when engineers across all projects are co-located. You will reap the benefits of both Creative Momentum and cross pollination.
If you see an unhealthy number of engineer switches taking place (meaning it affects the project velocity) you simply set down some ground rules. Examples could be: You can only switch after 3 iterations on a project, switches must be a one for one swap, both teams must approve the switch etc.
Like I said, the jury was still out for me when I wrote that. I think you are right. Relatively stable teams should form because people are going to stay where they are happy and move when they are not.
In a way, it's the most organic way of producing healthy teams. It may take a couple of iterations but the end result would be better.
Post a Comment