Imagine a typical software development team. There are 2 types of such teams: those that are based around a single project or those around a single system. People tend to want to differentiate between those types only to find out in the end that they are remarkably similar if you zoom out far enough. Since my experience is with the latter I’ll talk about that. If something does not apply to your team on first glance it just might on second glance. The similarities are enough that I think I can generalize and make my point.
What then do I want to talk about? Three attributes most IT projects share are
- the complexity is always greater than anticipated
- projects tend to grow over time
- they are difficult to manage
Nothing new here probably. There are solutions that help getting a grasp on the complexity and make some parts of IT projects not easy but easier. Those things are called ” development processes” and I have a favorite in that department which you will find out soon if you don’t know already.
So imagine that team I was talking about and all the people and the “stuff” that is involved in it. I’ll put some arbitrary numbers to it to clarify the aspects I am talking about.
- 1 team leader (if you are unlucky you have a structure that gives a team different leaders with different roles)
- 5-7 employees spread over a few offices (hopefully in the same building, sometimes however not even in the same country)
- 3-4 freelancers or “consultants” (everybody is a consultant today)
- 3 project managers for the different projects the team is currently working on
- 1-2 main systems / project
- 5-6 subsystems / associated projects
- 3-8 on-going development projects for the system – usually at least 1 more than there are developers
- 6-12 months of roadmap planned out in mostly less detail, just enough to build up pressure
- 80% legacy code written by former team members
- 5 major bugs keeping developers from the work
- 42 minor bugs keeping developers from resting on their laurels if they ever manage to fix the major ones
- operating issues for the running systems
- at least 1 big performance problem that keeps nagging at the minds of the developers day and night
and last but definitely not least:
development processes < ε
The effects on different aspects of the development work are easily guessed:
4 Effects on Projects
- project priorities are unclear & the priorities typically change often
- projects rarely get finished on time and sometimes never at all
- requirements have to be dropped
- more and more unfinished tasks & projects pool into the murky backwater of “later”
4 Effects on Communication
- meetings are taking up a lot of time and yet communication is still never enough
- it is hard to figure out at any one time what everyone is working on
- finding out the state of a project/working package is hard
- some tasks are done more than once while others are forgotten
4 Effects on Quality
- non-functional requirements (typically those are the ones that are supposed to increase quality) get dropped
- technical debt accumulates and the interest to pay for that increases faster than the national debt of Greece as you just do the “quick and easy” solution – “for now”
- there is no time to modernize the legacy code
- time allocated to new projects is misappropriated to finish up development of old projects
4 Effects on Team Members
- the number of context switches for team members increase as projects fight for the attention of the developers
- time spent fixing bugs (old & new) increases
- everybody is more or less working on “their” stuff, so when someone is sick or on vacation (or quits) their work stalls
- more and more conflicts between people pop up as stress increases
I won’t even get started on technical issues like version control, release management, deployment and operating.
Things can work out for years without a process. It is much easier and doesn’t require any knowledge at all to “just get started with the project” instead of defining rules and structures how the team is supposed to work.
I know a project manager who doesn’t think much of development processes. He has about 30 years of experience in the job and has his own methods to get projects finished. His projects work out great because he is simply very good at what he is doing.
However not every project has such a project manager all the time. What development processes – agile or not – give us is a structure beyond each single project. Rules to go by, when we’re not sure how to proceed. A great project manager does the same thing: he gives you rules, structures and helps with decisions. Wouldn’t it be nice to be able to work in the same structured way without having to have a nanny hold your hand all the time?
When the next crisis hits your team (or company) all of a sudden you may have to be more (cost-)efficient. Then the precarious balance on which an unstructured team may have built past successes can quickly turn into a messy “situation” that takes all the fun out of work.
A structured development process does not solve all problems for you. No process is a magic cure-all. A process is about providing you with techniques and tools that sometimes provides you with a solution. At other times it may simply work like an aspirin that contains the pain so you can continue working. Sometimes it is enough to realize the pain is there to be able to do something about it. So even the analysis of your situation may help provide part of the solution.
To adapt itself to a given situation is the most important attribute of any process. A process that fits a team will be accepted much more readily by the team members. That is the reason why I am a fan of agile processes and especially Scrum. You may have a different impression but let me tell you Scrum is great at adapting! As a sidenote: I do believe that it is better to have any process than none so if you have an agile process: great for you! If you have any other process: still great for you!
“What is your biggest issue currently? Where is your team hurting right now?” Usually this is my first question when talking to anyone about processes. If you don’t have a process and are thinking about introducing one then the reason for doing so probably is, that something is not working out. There is usually a very specific need to be adressed and a process should deliver some tool to help tackle that problem.
So what is your biggest issue currently? What aspect of your work is in need of a reload?
Why haven’t you done anything about it, yet?