Open Journalism & the Open Web

I picked question one. I've worked on many dev teams, including scrum-driven ones. Off the top of my head for a software project to be successful people need to be:

1. Adaptable
2. Open to constructive criticism
3. Ready to throw code away if necessary (not too much emotional investment in it)
4. Able to collaborate and support others
5. Honest and transparent about impediments and issues
6. Open to new ideas
7. Ready to commit and follow through once a course of action has been decided
8. Able to think outside the box
9. Able to lead and be led (in a scrum where scrum masters are rotated)

• For software development projects to be successful, what do the people involved need to be?

I was struck by one manager's statement in "The New New Product Development Game" that he encourages his team members to be well-versed in two technological fields and two functional areas. A team made up of such people -- whose bodies of knowledge and skills overlapped with one another -- would be so powerful because it would be flexible and able to collaborate at a high level.

I think members of a software development team must also be comfortable with instability, including changing customer requirements. I noticed that the management of the companies profiled in that article created such instability by giving these employees the freedom to do something important and by placing them in challenging situations.

Members of a team with overlapping areas of expertise would be more prepared to deal with instability and turnover. They may be able to solve problems more effectively because people with similar knowledge bases would approach problems from different perspectives depending on their other specialties.

I would think being able to move up and down the ladder of abstraction would be key, too. For instance, team members should be able to see how a piece of code could be abstracted for other purposes -- to move from the concrete to the abstract. But they should also be able to break down large projects and initial concepts into smaller, discrete tasks.

For software development projects to be successful, what do the people involved need to be?

** Flexible — They can not to be stuck on one principle or idea. They must be constantly aware of the needs of the customer or final user, as noted by the Manifesto for Agile Software Development.

** Self-starters -- Under the scrum principle, you do not have a manager tell you what to do. The manager has a vision or idea and your job is to figure out where to go with it. There is no hand holding here.

** Engaging -- You must be willing to work with others involved in the project. You can't be an introvert here. You must be willing to interact daily to get a sense of where the project is going and how to work together to get it done.

** Passionate -- Someone mentioned this year. This is related to be a self-starter. Since you're not having someone tell you that you MUST do this, then chances are success will only come if you are driven to succeed.

** Willing to invest -- This is more so for the manager or the people who are providing the resources. Wideman explains that the practice of under staffing a project is a recipe for failure. If nothing else, he notes, you need extra folks to be there to take care of contingencies. Actually, a great example of this is being seen in the journalism business: Both USA Today and the Deseret News in Salt Lake City announced that they were focus on providing innovate products online while announcing massive layoffs. Of course, the justification was that the layoffs was a result of a de-emphasis on the print product, but I find it hard to believe that all the folks layoff had nothing to offer in future innovation.

>more assembly line-type process

Software development is still more of an art than a process. Simply because there are so many decisions to make. Decisions are the essence of art.

>the agile team is expected to follow one project all the way to completion.

The word 'completion' can have many definitions, I suppose. Agile teams use Sprints to chunk work into blocks of time (for example, two weeks). After each sprint, people can be re-allocated. However, a stable team is encouraged. Stable teams can produce the same amount of work sprint after sprint which aids in planning.

>team members probably need to like ... each other

Yes. If not, the dislike acts as friction and less work is done.

>It also seems like the individuals need to be "process geeks"

I don't agree. Some process is obviously needed but the exact amount and how the process is defined is fairly flexible.

>it requires the development work to be done according to good standards, to enhance flexibility.

Good standards arise from good team members. The best process in the world means nothing because people can subvert it fairly easily (i.e., lie). However, peer pressure can work every time if you can fire people who don't respond.

For software development projects to succeed, management has to clearly state a goal, select creative, cooperative, flexible types from across departments and then step back and let the team work on the project.

Team members with a passion for what they do and a variety of backgrounds/experiences would tend to be more successful because they’re not easily cornered by failure or frustrated by details. They have patience for the long haul and are able to quickly shift gears when an idea fails to give the group the outcome they need to accomplish the stated goal.

Members should have a track record for meeting deadlines. As free-flowing as the scrum method is described, it comes with a built-in accountability check, where members are constantly benchmarking their progress from day-to-day, week-to-week, month-to-month.

Three common project risks are:

-Wrong people selected. Those who cannot meet deadline, tend to focus on the negative and not accustomed to working with others.
-Lack of focus. No stated goal. Too open-ended, as in “Come up with a way to make us money.”
-Lack of autonomy. Group is constantly having to check in with management or the other way around.

With Agile product development methods, these three problem areas are eliminated. The ultimate problem is convincing management in a more rigid top-down organization to see the value of allowing subordinates the time to problem-solve.

Belatedly adding my reaction -- the people involved clearly need to be organized! One of the things I found most compelling about the scrum method was the daily scrum meeting, where every participant says what they will do that day to advance the project. I think it's a good motivator, first of all. And it gives all participants access to each other, including project leaders, so no one is waiting around. It's like a built-in, communal to-do list.

- Pick a piece of functionality that you'd like to implement

My functionality is not too high-brow, nor does it require a lot of programming gymnastics.

InvestigateThis!

An interactive tool for Chron.com’s homepage that would bring readers to the page, and keep them there for more than 30 seconds.

InvestigateThis! would be featured as a button on the homepage, asking readers to send investigative story ideas quickly to the reporters who could follow up on them.

Once clicked, that button would open up a template for readers to fill out.

Five criteria would be featured:
1. Story idea in 30 words or less.

2. Is this time-sensitive (or when is happening?),

3. What’s at stake? (waste of money/resources, corruptive or unfair process, life or death?)

4. Any records involved? (What should the reporter ask for?)

5. Optional contact number/email for the tipster if a reporter has more questions (not for publication).

Once filled out, the accumulated tips would be forwarded to designated editor in Metro, or to reporters interested either once or twice a day OR they could be sent out once a day to the entire staff.

If an InvestigateThis! tip leads to a story, we would say so at the bottom of the story, encouraging others to keep sending investigative
story ideas to us.

This app is broken down into two parts: the click button and the template the user is led to.

To get this app built and launched:

-Write a detailed proposal/Powerpoint/Prezi complete with stick drawings and flow-chart showing exactly how this would work.

-Field-test the proposal by sending it first to Projects/Investigative editor. Edit proposal, based on her input...or not.

-Do same thing with Newsroom IT Director, Chron.com Editor, Graphics Editor, City Editor.

-Do not send group email. Group emails tend to make management nervous and defensive, especially when they come from the worker bees pitching ideas. They
like to think you came to them first with your great idea.

-Meet with Graphics Editor to work with you on mock art of the app.

-Edit proposal after all of their input.

-Meet with City Editor, Projects/Investigative Editor, Graphics
Editor, Newsroom IT Director, Chron.com Content Editor to a presentation/discussion of edited proposal. Discuss logistics about where this app would appear. Set a deadline for completion of the app.
Find out exactly who will build.

-Meet with web advertising department about the app so they can locate
potential advertisers around the area on the web where InvestigateThis! will appear.

-Start regular meetings with builder of the app (daily/weekly) until
the app is made.

-Test the app. Retool, edit, redesign, where necessary. Re-test.

-Contact advertising to put ads in place.

-Launch app.

-Retool again, after a few days or weeks use, based on reader/user input.