Geeks With Blogs
Scott Miller Appsguild - Software craftsmanship, project management, and the biz of software
Last posting I told the story of the scope actually decreasing because of user feedback. The users decided that they could live with Iteration/Release 1 (of working software) and essentially canceled Iteration/Release 2 so that we could work on some other projects that they considered a higher priority than the added functionality of what we would deliver in Iteration/Release 2. This was considered a huge evolutionary step forward in the software development process, because usually a software team would get requirements and disappear for six months, delivering the total package at the end of that time.

Score one for the team...

As the Agile Manifesto says:
Business people and developers must work together daily throughout the project. Hmmm...ok...

So what is the best way to include users? Here are some possibilities:

We could use the XP example of making a business customer/user/rep/whatever move in with the team. In my experience, requiring this person to move in with you usually results in a business customer/user/rep/whatever being assigned or chosen based on his/her uselessness to his/her own department (Dilbert Principle in reverse). The department will not commit a critical person who delivers daily value to the department to the project full time! A person will be chosen who is a (useless and expendable) manager/newbie/lazy non-worker. In other words, someone who is not a very good customer or user representative anyway.

Now, I have only seen this work on one project, a very high profile project, where the department had a life-or-death vested interest in the project. I was given a real super user. Unfortunately, at the end of the project the person couldn't go back to his team. He was used to working in collaboration. He was marked as "part of IT now", and eventually he left the organization.

You could move into the business unit. I have actually done this in the past. IT was seen as the "ivory tower" where edicts came down from on high. No one worked with IT. It is impressive when you (or the team) move into the business unit. But this presents several problems, including just the opposite of above - it is difficult to go back, and IT will begin to treat you like part of the business (somehow you "defected"). That is why some business units that can't get IT to respond to their requests add IT people and end up co-opting IT.

In my experience, the far better use is to include users, but let them continue to do their jobs. They will stay pertinent to their business unit, but still help you. And you will most likely get a higher quality of user. Include them in the stand-up meetings. You can get two or three days a week of user interaction. Is this strictly adhering to the agile manifesto? No, but in most organizations it is such a paradigm shift that users are included at all that you will get much more "bang for the buck" that it more than makes up for it.

Posted on Friday, September 28, 2007 6:38 PM | Back to top


Comments on this post: Lean/Agile idea of the day - what kind of users do you want on the project?

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Scott Miller | Powered by: GeeksWithBlogs.net