Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: project managment

  • Project Management in One-Man Project

    Recently I came across a very interesting question on Project Management Stack Overflow. The question is how to organize project management in tiny projects, where everything is done by a single person or just a couple of them.

    The interesting thing here is that when we think about the point where organization introduce formal PM role we usually see at least a few dozen people. So how about startups, where just a few people are working in the whole organization?

    Let’s consider one-man project. I leave aside all tasks directly related with software development, so for the sake of this article I don’t care about version control or bug tracking. Which leaves us with a few of basic areas.

    • Scope management

    You actually need to know what you’re going to do. At least on general level. Actually in startups it’s not a good idea to have detailed plans of development since, well, what you start with is wrong and you’re going to change the course along the way. However if you don’t know, even roughly, where you’re going and you can hardly tell what is your goal then you might look for another project or another job instead because you’re not succeeding. So yes, a bit of scope management is crucial – you have to know that you’re building a tower and not, say, space ship.

    • Task management

    You already know where you generally are going. Good. Now you have to figure out the next step. Or the next feature you’re going to build. Then you build it. And you repeat the process. I mean from the point when you figure out the next step, not from setting the general direction. Of course you don’t have to be so short-sighted to plan only a feature ahead but you do need to break the scope down to smaller tasks and start building your tower brick after brick. And of course you need to know which brick goes first and which goes next.

    • Product management

    This is kind of tricky. Actually if you know the scope and you dealing well with tasks you pretty much have this one covered. Given that you’re building the right thing that is. Product management in such small project is all about making sure that you’re building the right thing. It’s not on brick level but you need something more than just a picture of tower pinned over your desk. You actually have to know that you want to keep bad people in hostage there so you need cells, torture chambers and such. Then you need to figure out how these things should work so clients… I mean hostages are served… I mean tortured well.

    • Communication with users and/or clients

    Finally, you need to verify whether your dream about best of the breed torture tower is something people actually want. You need to regularly confront your ideas with clients or users or both (depending on your target group) to make a sanity check: are we still going into the right direction. Yes, you need to talk with those tortured poor souls to learn whether they’re happy with the service. You might also check your butchers – they do use your product as well. If the tower isn’t ready, go find potential customers and potential users and get their feedback. Since you’re running one-man project you don’t have clearly defined requirements so this part is even more important than in typical projects.

    Now, I’m well aware these areas aren’t strictly connected with project management as some corporate PMs out there know. In big teams PM can be isolated from product management and from end users, scope can be thrown at the project team in huge specification before the project starts, but well, we don’t discuss big teams working on boring BDUF project here, do we?

    By the way PMSE (Project Management Stack Exchange) site is awesome not only in terms of inspiring blog posts. You will find there a lot of great stuff so what are you waiting for? Go check the site.

  • Internal Audit: Lessons Learned

    Last week we had an internal audit in our team. If you automatically think “ISO 9001” when you hear “internal audit” let me just state it had nothing to do with ISO. We have a few so called quality requirements in the company and every team should follow them but these aren’t anything like ISO procedures.

    The reason why I was interested how the audit would go is we work pretty differently than the rest of the organization so quality requirements aren’t really adjusted to our specifics. I was also curious how our non-standard process would look like in comparison to other teams.

    I caught a few things which are worth sharing.

    Small Features versus Big Features

    Our currency for functionality is MMF (Minimal Marketable Feature). MMF itself probably doesn’t tell you much and I know different teams use different sizes for MMFs. In our case average MMF can be coded by a single developer in about a week, so they are pretty small.

    On the other hand in other projects typical currency for functionality is requirement which is significantly bigger and, as such, less detailed. I’d say that on average it is few times bigger than MMF.

    Where’s the difference? I mean, besides the size itself. One very visible difference is we do significantly less paperwork. With features small enough that they can be easily analyzed and decomposed by product owner, developer and tester we don’t need to write low-level design documents or test cases or user stories. We can spend more time doing the real work instead of creating a pile of documents which tend to become outdated as soon as you hit the save button.

    Frequent Deployment versus Not-So-Frequent Deployment

    I guess there aren’t many teams which still treat deployment as one-time effort done at the end of project. But still, frequent deployment is a painful thing, especially when developers work in different team than QA engineers and QA engineers work in different team than release managers. An average project isn’t deployed biweekly. Not even close.

    On the contrary we deploy, on average, once every 9 days and I mean calendar days here. Of course it didn’t look like that from the very beginning and it cost us a bit to get there. I would say it took us about half a year to gain this pace.

    Where’s the difference? I could tell you about time-to-market, but it really depends on project whether you need time-to-market counted in days or months. The cool thing is somewhere else. With such a short cycle time we don’t have a temptation to incur technical debt. We don’t leave unfixed bugs. We just don’t. After all we might have been discussing about a single low priority bug, not a few dozens of them so the fixing cost would be so low that we don’t even start the discussion in the first place. Even if we hit a dead-end redoing the whole darn feature doesn’t take us a couple of months – it’s just a few days so it’s much easier to accept it.

    Everyone on the Same Page versus Formalized Process

    We’re small team and we’re co-located so we have fairly few communication issues. The process we follow is very simple and, what is even more important, crafted by our team. We all are at the same page.

    Most of the teams in the company follow more formalized process. There are different functional teams which are meant to cooperate, there are specific documents expected from each other by people working on projects etc. On the top of that there’s some office politics too and formalized process is used as a weapon.

    Where’s the difference? This one was pretty much a surprise for me, but it looks like our process appears as mature and effective even though it isn’t even recorded in any form. We just know what everyone should do. Whenever some obstacle appears on the way people naturally try to help each other as they see and understand what’s happening. And yes, I’m over the top just because no one forced me to write the process description down. On the other hand formalized process is often artificial for other teams who have to follow it and they sometimes focus on being compliant to the process (or fighting with it) instead of building software.

    What Does It Mean For You?

    I’m not trying to say here you should now automatically cut every feature you work on in half (at least), deploy three times more frequently than you do now and throw every procedure out. It would probably end with chaos, which your managers might have not appreciated.

    I’m not trying to say it was easy to get where we are now. It took great people, some experience, a lot of experimenting and enough time to get better at what we started doing. A year ago I would have hard time trying to point how our approach might be better than what you could find in the rest of the company.

    And I’m not trying to say you should read these advices in “this over that” manner known from Agile Manifesto. It’s not only our team which is pretty different than average team in the company but a product is also far from standard projects we build in organization so I compare pretty different environments. I wouldn’t even say that every single team in the company would benefit from implementing our approach, although a few of them definitely would.

    These are just things I learned while talking with Ola who audited our team (and many other teams in the company). For me these lessons weren’t obvious. I mean connection between frequent deployment and short time-to-market is pretty clear for anyone who understands what “deployment” and “time-to-market” means, but I’ve never really considered that very short production cycle may help to avoid technical debt too.

    And if you’re interested what the audit result was, I’d say it was pretty good. I mean, everyone likes to listen to some compliments from time to time, so we may want to ask for another audit soon.