Development as a service?

Facebooktwitterredditpinterestlinkedintumblrmail

gearIf you are working in software development, then you have probably heard the terms “Continues delivery” and “DevOps”. These are not just new buzz-words, they are already being used in varies software companies, including some of the really big players on the market.

These new methods aims for releases of software on a daily and sometimes even hourly basis. This is done to ensure that the product is pushed to the market as fast and possible, and then to get the feedback from the end user and make adjustment to the product accordingly.

This way of developing software moves the actual development to be more like a service rather than a project, and in most know cases, this approach to software development is for companies developing for the end consumer market (e.g. Facebook, Google etc.), but more and more “non end user IT companies” are looking into this method.

This way of developing software raises all sorts of new questions for our way to approach software development as projects, which has a budget, a deadline and a clear scope and so forth. If you don’t have a finale specification for your product and thereby not knowing when exactly you are done? How then will you do estimates, manage budget, set timetables, measure progress and all these other mechanisms that ensures that your project don’t go of track?

The answer for this comes in varies forms, but the one thing that you need to embrace is that you will have to see the development as a service organization and not as a project. So basicly you will have to figure out how important the software product is to your organization or client, and how many resources you will throw at it. If the software product is your core business, then it might be worth to put as much focus on the development team as possible, but if the software is not your main product but only a support to the business, then you might wanna go the old fashion way at set a max amount of money that you are willing to spent.

Change management in agile projects

Facebooktwitterredditpinterestlinkedintumblrmail

change-managementEvery now and again I get the question – How will you manage changes in the project, if it is agile? Most of the time I would like to be able to answer ”I don’t, agile means constant changes, and I’ll manage the changes by doing the project in an agile manner”. However life as a project manager isn’t always that easy.

In almost every project of a foreseeable size, you will eventually get to the point where the Steering Committee or your project owner want to know who decided to do a specific thing in the project you are managing. If you do things agile and don’t keep track of your changes, then you probably can’t answer that question – ”Who decided to use a top menu and not the left side menu that we planned to use right from the start”? Try and answer that question after 4 months of agile development with absolutely no change logs.

So how can you handle changes – Well, there are a couple of different ways, but they all involve using a log. If your project is done agile, then chances are that you are using user stories (if not, then you should try it out, it is awesome). If you are using user stories you can add a log to each user story, and simply keep track of what has been decide by whom, when it was decided and why. Then later on you can access that user story in order to answer why the menu was changed.
A word of caution, some SCRUM tools makes it had to access the items that has been completed and approved during your project. Always make sure that you can access old user stories and sprint logs in the SCRUM tool that you use.

A second way to handle this is by doing a good old fashion change log, however you should not do any long description in change management documents, or else you will drown in paperwork. In stead use a simple spreadsheet with at least the following columns:

  • ID number
  • Date for deciding to do the change
  • User story identification number
  • User story title
  • Description of what has been changed and why.
  • Who decided this.
  • What impact is expect to the project if any.

The third way, and that is for the spoiled project managers, is to have your product owner do the change management for you, but basically he or she will probably do it in the same fashion as described above, or else that person will be the one who will be drowning in paperwork.

Estimation and impact on the project
When doing changes to a project, even if it is agile, you should always make sure that the tasks are re-estimated and you need to know exactly what impact the change will have on your project – What seems like a simple twist in a steering committee meeting may have a big impact on the project when you present it to your developers. Therefor, you should never allow a change to be decided/approved/committed before you’ve got a complete overview of the impact AND are able to explain this to the rest of the project group.