My role as a developer is stretching more into the project management world as well as the coding world.
We have a small team. Every piece of what we do needs to be operating in the most efficient and effective way possible. This ranges from clean code, good architecture, thoughtful design, clear project goals, developer motivation, collaboration with owners/experts/managers/etc.
I know there is a lot of talk about Agile, Kanban, Extreme Programming, and more. My perspective is that there is never a one-size-fits-all solution, but the "frameworks" that are out there can be helpful in developing a solution for your company.
The following is a write-up I did to help communicate project management techniques within my workplace...
The following is also available in a prettier Google Doc version.
Software projects involve more than simply writing code. Here are some areas where we could use improvement.
Every person involved in a project comes from a different perspective. This is important and there is value in those differences, but we do need a means of bridging the gap between different domains. The place to start is to not let the simple things obscure the discussion.
My thoughts: This will always be an area needing improvement. By using visuals and written documents, I hope to facilitate a “common language” amongst all parties involved in a project. This will take time initially, but the value will be great.
Project management has been a struggle in software development for many years. Over time, some techniques have developed, but fundamentally it comes down to each individual being aware of all the factors involved and a willingness to boldly confront issues as early as possible.
We are not a big software company, but some concepts can be used in any size team. Agile, Extreme Programming (XP), and Kanban are some topics that often come up in software books and blogs.
The Agile Manifesto sounds like nerdy programmers taking their jobs too seriously, but something can be gained from what it offers. Here is the abbreviated manifesto...
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
My Thoughts: There is no golden rule to managing projects. Every organization must find its own way, but can learn from the failures and successes of others.
Architecture, Design and Programming
In areas of development, the rules of Extreme Programming are a good starting point. There are five categories... planning, managing, design, coding, testing.
User stories define what the final product needs to do. Some might call this a Functional Specification, and there is a great 4-part article on why and how to write easy-to-read specs...
Plan to make many small releases on a regular interval.
My Thoughts: It is not as difficult, tedious, or annoying as it sounds. It is a critical piece that provides direction and scope for a project. It doesn’t have to be big and wordy document. But it needs to exist in some form, and has to be something that serves the purpose of keeping projects on focused and on track.
Maintain a sustainable pace.
A stand up meeting each day keeps the team communicating and focused.
Move people around - “Moving people around the code base in combination with pair programming does your cross training for you. Instead of one person who knows everything about a given section of code, everyone on the team knows much of the code in each section.”
My Thoughts: On a small team, everyone needs to be aware of what is going on in areas of the system. We have to be able to fill in and cover each other’s backs when necessary. Cross training and peer programming are even more important.
Simplicity is Key - “a simple design always takes less time than a complex one.”
Choose a System Metaphor - “The most important quality is being able to explain the system design to new people without resorting to dumping huge documents on them. A design should have a structure that helps new people begin contributing quickly.”
Refactor whenever and wherever possible
Refactoring = “A disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”
Catalog of commong refactoring techniques by Martin Fowler
Refactoring Book - by Martin Fowler
“Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity.” …
please read Refactor Mercilessly
Customer is always available -
“All phases of a programming project require communication with the customer, preferably face to face, on site.”
“Experts in any field have a tendency to argue. This is natural. Solve this problem by requiring all the customers to be available for occasional group meetings to hash out differences of opinion.”
Pair Programming increases software quality without impacting time to deliver.
Integrate Often - “Developers should be integrating and committing code into the code repository every few hours, when ever possible. In any case never hold onto changes for more than a day.”
Testing can help find bugs, and, even more importantly, prevent bugs from being introduced with future changes. Testing takes time to create and make a habit of, but it will “offer a pay back far greater than the cost of creation.”
My Thoughts: By constantly seeking to improve each area of Planning, Managing, Designing, Coding and Testing we will find our way to more successful development projects. Every area is important. Simplicity and clean code will speed development and improve our effectiveness.