Project Management and Best Practices in Retrospect-iva
Posted by Mathew Abonyi Sat, 28 Jul 2007 01:18:35 GMT
I don’t hear a lot about project management, even though there’s a lot about how to manage a project. Testing, deployment and source code management get the most attention, and project management seems to get the least. Maybe that’s because it hasn’t been done properly yet and all the solutions out there only address pieces of the overall problem.
So I’m going to try to clarify, for myself mostly, the kind of project management that is needed and why it is so important in development.
Getting It Right
When I say management, I mean a combination of something like Lighthouse and Basecamp, with a serious overhaul of perpsective. An integral part of good development is developing ideas hand-in-hand with the code. Management is all about keeping this communication as agile as the coding process, sticking to priorities, and addressing the right things at the right time.
Is Basecamp sufficient for managing a project? No. DHH even says it is not meant for managing Rails projects; it’s for marketers and managers. It’s only a piece of the puzzle, because it provides no way to easily track code.
Is Trac sufficient for managing a project? No. It is too much like a big todo list and a bug tracker combined. It is very developer-centric—even when the developer is also the designer and manager, there’s no way to make known the other roles. Trac too is only a piece, because it provides no way to easily communicate ideas. A wiki doesn’t cut it.
Are help desks sufficient? No. They are too customer/support-centric. They have no way to easily communicate the ideas of developers and designers.
What about Lighthouse or Unfuddle? For a hosted solution, Lighthouse and Unfuddle combine Trac and Basecamp. That’s going in a decent direction. Anything which integrates different parts of the development process is addressing the need for management. But it’s not enough, because it has no integration with the customer.
What about [insert megolithic answer to everything]? No. It’s too complicated, has too many options and forms, too much information on each page. Something as complicated as Google Analytics, for example, is pushing the boundary of what is acceptable. Complicated applications get in the way of communication and understanding, even if they integrate everything. Simplicity first.
What all of these solutions lack is a focus on the different kinds of users for a project, ways of easily communicating their needs and ways of addressing those needs. Even when the developer, designer, marketer and manager are rolled into the same person, it is important to separate the roles, make them clear and integrate each one’s concerns at the right points.
It’s all about the development process.
The Development Process
I see that there are 9 stages in the development process:
- Management: find out the next need to address
- Specification/Testing: specify how the need is addressed
- Coding: code until the specification passes
- Continuous Integration: combine the efforts of multiple coders
- Refactoring: clean up the code
- Graphic Design (if needed): make the new feature appealing
- Deployment: release the latest revision
- Marketing: advertise the latest feature
- Customer Feedback: find out what is going well and what isn’t
If you see this process as organic, the importance of management becomes much clearer. In fact, I think management is the most important stage, more important than the code itself, for a number of reasons:
- Management is the first step; without management, testing/coding is arbitrary
- Management brings everyone into the development process
- Management gives everyone an overview so they can see the wood for the trees
- Management encourages communication between everyone
- Management naturally focuses on the most important aspects
- Management reinforces and rewards good development
- Management operates organically, reflecting needs and their importance
- Management begins the specification/coding cycle
- Management draws from and feeds into all other stages of development
Disconnecting from these aspects of development is a serious mistake because it denies the organic element of development. Everything needs to converge at some point and management is the most natural way of acknowledging and converging all of a project’s members, roles, ideas, problems and concerns.
Poor management will try to force the development process into a linear pattern. It will approach things as ‘things to do’, ‘features to have’, ‘milestones to reach’, ‘deadlines to meet’, ‘code to test’. Everything will have its place, need to be addressed by a particular person… in short, it’ll look like a Trac installation. The code will feel strained, regimented and will generally be a rather boring thing to deal with. The developer is being strait-jacketed.
On the other hand, a lack of management will result in the process becoming chaotic. The developer will code whatever takes his fancy. Occasionally e-mails or posts containing feedback will find their way into the code, but mostly the code will diverge from the customer’s interests. The organic element has gone mad in this case because the developer is too isolated.
But good management acknowledges the organic aspect of development and lets the code flow. It translates ideas into specifications just as test-first translates specifications into code. Good project management will create and maintain strong channels of communication between developer, designer, marketer, manager and customer. The real needs for the project will appear of their own accord as different ideas converge in one place.
But that sounds much easier than it actually is. There isn’t yet an application out there which integrates all of those roles together, but some are closer than others. I think Retrospectiva could be the one which gets there first.
What is needed for good management
The three major aspects of project management are development, collaboration and integration. There needs to be a way to develop, track that development, and focus it. There needs to be collaboration and communication surrounding that development. There needs to be a process of integration between management and the other stages of development.
Ideally, a project management system will have the following aspects:
- Stories: isolated stories to be resolved (bug, feature, question, idea)
- Dynamic properties: status, milestone, persona, feature, assigned user, assigned group
- Reinforcement: aspects of the application NOT to change (positive feedback, robust code)
- Personae: ability to define personae, like power users, buyers, sellers, novices, etc.
- Milestones: rough organisation of stories and deadlines
- Messages: site-wide (like Basecamp) and for each milestone
- Roles: developer, guest, manager, designer, customer, marketer, administrator
- Groups: optional story development by groups
- Interfaces: different interfaces for each role and/or group
- Cross-referencing: referencing between stories, messages, milestones, source
- Testing integration: update stories with progress on tests (e.g. Tesly)
- Coverage Integration: stories for area of test coverage, whether 100% covered or not
- SCM integration: update stories through commit logs
- Continuous Build Integration: create stories for failed builds
- Error Notification Integration: create stories for application errors
- Customer Integration: create stories for customer feedback (positive & negative)
Most importantly, the interface(s) needs to be extremely clean. Lighthouse goes a long way in making a highly readable, even pleasurable interface. Most of the aspects I list above can exist on their own, meaning the application itself will have many facets, but each very easily understood. Cross-referencing is probably the most important of them all, since it will bring together the various aspects.
The shift in perspective I suggest for project management is to not focus on managing people (like Basecamp) or code (like Trac) or users, but ideas. Those ideas will never disappear from view, unlike tickets on Trac or todo lists on Basecamp. As stories grow and connect with new stories (like associating tickets), everyone will see the evolution and development of features, in which way the project is going, and be able to react better to the movement of the project. In a way, project management also begins to document the project, but more importantly, it shows in black and white how ideas become code and how they evolve. At the centre of the project should be a cloud of ideas which each role can see differently.
Just to give a little hypothetical situation: at the beginning of your project you had a simple user authentication system. Over time, users talked about adding Open ID. Management wanted an authorisation system and an admin interface. Designers wanted a cute widget that pops down with AJAX. Developers wanted to extract it into a plugin. All of these ideas would be associated and appear together in a good management system, showing the time each one was added and completed, the role which initially suggested it, and the group or user responsible for implementing it. All the bugs, notes, support questions, requests and feature stories will clump together and naturally point towards what is needed next, if anything.
This form of project management could very well revolutionise the way development is perceived. Or is it a load of bullshit?
