Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've just taken on a new job at a college as (the sole) Web application developer.

The college has a number of disparate but all pretty badly coded legacy systems. Mostly built in PHP they deal with things like attendance, exam results, marking etc.

My first job is to build a system that incorporates a lot of this data, which is currently resting in various databases without any kind of friendly API to pull it out (the existing systems are coded in vanilla PHP with no separation of data and view) with a new platform for recording pastoral information about students and presents it to tutors and senior staff in a useful manner so they can react to issues with students quickly.

In our first meeting, there were 18 people! There was no clear leader or voice that represented the majority. No identifiable client. The meeting swung from detailed implementation ideas on minor features from heads of faculty to arguments about whether we should use Excel spreadsheets or not for data input!

As you can imagine my head was spinning at the end. I actually had a lot of good ideas but I couldn't get them heard. This is a very new role for me, before I was part of a development team in a marketing agency. We had very well defined roles: Project Manager, Client, Designer, Developer.

I'd like to know if any seasoned developers or managers out their can give me some pointers on how I can whip my colleagues up into something that resembles a project team. Is agile the way to go? How would you approach handling all the disparate voices? It's clear that some process needs to be put in place very quickly, I'm just not sure what that is.

share|improve this question
8  
If you're the sole developer, who were the other 17 in the meeting? –  pdr Mar 20 '13 at 16:41
1  
Good question. The principal of the school, Various members of teaching staff (even the PE teacher was there), and a lot of people with acronymical names. –  Matt Harrison Mar 20 '13 at 17:01
1  
@MattHarrison: but what do they have in common with your web application? Are they potential users? Do they maintain those legacy system you mentioned? You should clarify that so you make sure you know whom you will ask for requirements and whom you can ignore. –  Doc Brown Mar 20 '13 at 17:04
1  
@DocBrown I'm sorry perhaps I was a little unclear. They will all be future users of the system. The application will be cross-college and used by over 3000 people. I think what's happened here is people inviting people and the meeting has become a circus. What I will do is stress the need for a smaller stakeholder involvement. –  Matt Harrison Mar 20 '13 at 17:07
5  
@To the anonymous downvoter/closer: this may seem to be too localized at a first glance. But I think the real question is a development question of general interest: "how to start a development project when there are too many potential stakeholders", and those kind of questions are IMHO on-topic here. –  Doc Brown Mar 20 '13 at 17:31

5 Answers 5

up vote 26 down vote accepted

I would not expect any "agile development process" here as a solution to your current problem. First thing for you should be: clear your mission. That means:

  • clarify what your own responsibilities are
  • clarify what the responsibilities of the other stakeholders are
  • identify who is responsible for each of the legacy systems
  • if there is no client (yet) for your web application, find one who is going to use it in the future and ask for permission to incorporate him as a representative user of your system (a person you can discuss the requirements with)
  • if there are different stakeholders with different goals, collect their requirements (for example, by interviewing them one-by-one, not 18 people alltogether in one room). Write the results on a list. Afterwards, start priorizing.
  • write down a roadmap (the big picture) and a small spec for release 0.1 and make your boss as well as the representative client agree to it formally
  • EDIT: see GlenH7`s comment

This can take a while, you will probably don't write much code at this stage of the project. In such a situation, you should do some "requirements engineering" first. But start small, think big. Once you have developed your first release, you will have something to show around, discuss requirements again with the stakeholders etc.

share|improve this answer
    
Brilliant advice. Thank you! May I just clarify; when you say 'clear your responsibilities', do you mean make them clear, or clear them as in get rid of them? Sorry, I'm British so perhaps it's a US English thing. –  Matt Harrison Mar 20 '13 at 17:04
1  
@MattHarrison: hope my edit makes this more clear - though sometimes it may also be a good idea to get rid of some responsibilities ;-) –  Doc Brown Mar 20 '13 at 17:07
4  
Excellent answer. The only item I would add is to identify a lead or executive stakeholder. This person has the final authority in determining feature prioritization and scope. There are differing ways to get there, but someone has final accountability on the project. And yes, feel free to steal this comment to add to your answer if you'd like. :-) –  GlenH7 Mar 20 '13 at 18:24
    
+1 for roadmap. write down what you intend to deliver –  hanzolo Mar 20 '13 at 19:05

Separate the ones who really want this project to work from the herd.

Due to a lot of politics, someone put together this meeting with a list of attendees where the membership was determined by who would get the most upset if I don't invite them. It happens. This goal was fullfilled but as the developer, you found that nothing was decided. No one was assigned what to do. If you're lucky, they managed to schedule the next meeting or god forbid, they set a reoccuring meeting on the 3rd Tuesday of each month.

Next will come the formation of committees, sub-committes, and task forces. This is betteer, but you'll find them all equally worthless.

Finally, you're going to find out who really cares about this project. Who really wants to put in the time to do it right. Hopefully, this person(s) will have a supervisor that will allow them the time to do this and not just make it another item on their already lengthy todo list. Find these people ASAP! Help them manage their boss's expectations and get an agreed amount of commitment.

Get something in front of as many people in the original group who will even bother to return. They may all be smart and/or educated people but they're not going to read a bunch of specs. They'll like some things, hate others and want more. It doesn't hurt to write down suggestions, but try to get that party to follow-up with some skin in the game. Don't promise to do everything. Just address what can be done in the near future.

If you end up having to deal with more than 5 people on a regular basis, it's because some manager made several of their people get involved who don't really want to be there.

share|improve this answer
1  
+1 for highlighting the political aspects of such a situation. –  Doc Brown Mar 20 '13 at 21:18

Come up with a list of ideas which you think would solidify / improve the existing systems based on your observations and their "needs" and ensure you focus on where you can achieve actual visible gains. Include on that list each idea you think would be useful, as well as any standout "reasonable" suggestion from the non-devs.

Build a feature list of things that "should" be included in your development efforts. Give each member "voting" power, maybe in the form of "sticky stars" and find out what the whole actually wants by each member placing stars next to what they think is important. Some people may end up with more stars if they sign the check, have final say, etc.. After that hopefully you, and everyone else, will see what is important to the whole, and hopefully they will agree to the priority, which will then translate into a roadmap

1). Survey the Team - Find out what each member considers important / needed / top priority

2). Get something out there, quickly - Dont try to solve all of the problems all at once, get the "bare minimum" functionality out there and have them approve, then collectively advance it based on feedback of the users.

3). Use their feedback and the feedback of other users to guide the development process

(Build, Assess Feedback, Build, Assess Feedback) Rinse and Repeat.

Also, you might consider putting "effort points" or estimated hours to complete.. that might also aid in prioritization.

share|improve this answer
    
+1, that's the way to drive the car once you got it to movement :-) –  Doc Brown Mar 20 '13 at 21:16
    
+1 for this one, though I'd still make it more explicit that you need to be wary of a "bad system" that actually does what it needs to do. Prioritize in a way that you're not fixing things that aren't broken, focus on where you can achieve actual visible gains. –  Joris Timmermans Mar 21 '13 at 13:33
    
@MadKeithV , agreed.. "Focus on where you can achieve actual visible gains", updated comment to include that statement. –  hanzolo Mar 21 '13 at 16:44

Your first challenge is to identify the need for this project. Hold another meeting with all those folks and ask them to write down the problems that need to be solved. Don't let them talk about the many ways in which this project will be the solution. Force them to truly identify the needs/problems.

One way to do this is to ask them each individually to document those needs on sticky notes -- one idea per sticky. Then run an Affinity Diagram to help them group those disparate ideas into specific needs. Finally, make them vote (Multi-Voting) so that you can see the biggest needs.

Agile reminds us to tackle the feature that has the most customer value first. Start with the biggest need and then keep splitting that item down until you have the first small piece that you can actually do in a short period of time.

share|improve this answer

KISS - Make an itinerary. Thank everyone for coming, review it, do it. Side tracking will slow down if you address it by sharing their concern and ask them to stay AFTER the meeting. Make decisions by vote where there is controversy to keep most happy. Motivation towards participating in any system is directly related to the individuals belief in it's methods.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.