Check the error messages

I was meeting with some local developers the other night and one of the topics that came up was how to move from traditional fixed price projects to agile ones. The developer I was chatting with works for a firm that submits tenders to projects, where the clients all expect, and want fixed prices for the project so that they can submit their budget. His experience in trying to move to agile projects was that these are hard to tender because their costs look too high, and then they end up being undercut on price by competitors.

There has to be a way to do this: make this transition so that clients know you can do the work and do the work as required to meet their requirements. However, I’ve not found much on the topic on the interweb. Have I just missed the memo, or is it hidden somewhere? Surely others have gone down this road too, and written about it?

What I did find was a few links to useful papers and experiences. Start with the two pieces (part 1 and part 2) by Pascal Van Cauwenberghe under the ‘reading and books‘ page. Vikrama Dhiman also has a few points on fixed price projects on his blog, but argues the counterpoint to Pascal, so maybe that issue about ‘bidding low’ is up for debate.

My own feeling is that agile and evo teams should be able to make a compelling offer as part of their tender on projects, much as Goldratt discusses in ‘It’s not Luck‘. This needs to be a way to get the point across to those submitting RFTs that your offer will deliver something more useful than the spec provided, in a shorter time, and thus for less money in the long run. Maybe I need to find a firm that wants to pursue this further and we can work on it together. There must be a better way.

While at the University of Kent in Cantebury last week for the HEA-ICS conference I had a chance to discuss some of the other programmes that offer students places in software houses either as part of their undergraduate programme, or as an extra job for which they need to apply for a place. At Kent and Sheffield this can be done as part of the programme, while at Leeds this is an extra done outside of the curriculum.

About three years ago the University of Kent started their IT Clinic programme based upon the Genesys Solutions programme at the University of Sheffield. Last night I was able to speak to someone at Kent who’s worked with the IT Clinic. He told me about the programme at Sheffield, which I looked up later. Some of the interesting things about both of them are that they are integrated into the curriculum for the undergraduates and the postgraduate students. This means that the students are getting course credits for the work they do, and that the ‘work’ the business brings in is also separated from the ‘processes’ of project management and development, upon which they are assessed. At Kent the IT Clinic is also only one stream of many, which the students can do for their degree, as it is not something that all students will want to pursue.

At Sheffield all students do group projects as part of the ‘Software Hut‘ (link to course site), which explicitly uses extreme programming, TDD and pair programming as part of the process from the very beginning of the term. Once they have done this module, then they can go and do further development and project work in the Genesys Solutions office for credit and gain further experience. The projects for the Software Hut are for external clients, but each client might have four teams competing to build the ‘best’ solution for that client, with the ‘winning’ one chosen by the client being the one implemented in the end. This is an intriguing idea, but I’d have thought it would be a waste of time, as the client doesn’t get any results until much later, and they work with a fake luxury of multiple prototypes that can be tried and tested, which is not the usual way things work.

At Leeds the students can apply to take part in the Leeds Source-IT consultancy project. This is a new venture, which started around February of this year as a way for students to gain more practical experience, while also providing a service to the community. A key issue, which they have noticed is that students can only work about five hours a week on their projects during term time, to allow for their time for coursework. Needless to say, this proves limiting in how much work the team can take on at any one time.

One difference with the Kent solution is that it is as much about software development as it anything else, which can be a project. Therefore the consultants there will do laptop clinics to help students out at the start of term, and they’ll also do other hardware projects, and not just focus on software. On the one hand this can be a useful awareness raising activity, but on the other, it is diverting attention away from learning the tools of the trade in software engineering. Focusing on software will also look better on the cv for the student too, when she or he comes to apply for work after they finish their degree.

Both Kent, and presumably Sheffield too, have staff who look after the programme finding clients for the teams. In Kent, they have hired outside consultants, who worked in the region previously and therefore had good understanding of the local market. At Leeds they have someone who looks after all of the student related programmes in the department to look after this one too.

I think I need to plan a path that gets our programme to such a state as simply and naturally (ie as organically in a natural progression) as possible. Establish the components, glue the components together in a path students can take, and show their value to the department as a whole. This is the next step in this project.

UPDATE: (10 Sept) Forgot to mention Philip Greenspun’s ideas on universities and the economy and how the curricula students encounter with project based learning can help the local economy and prepare students for the working world. While he doesn’t push a software house for students, he does provide industrial relevant projects for students to develop.

As part of sorting out the details of what to put into a mobile computing ‘roadshow’ for secondary pupils, I’ve been trying to find links to materials about the impact of mobiles in the developing world. Some of them will fit into the page and the later acccompanying slideshow rather well, and that’s good. The students will be presented with the wider picture than they normally see and think about, namely their mobile and them, so that they can appreciate how the impact of the mobile is greater outside of the developed world than in our world.

During the pulling together of the materials I keep thinking that it would be interesting to do a project with a team of students here, and a group of students, or workers in another country, so that together we can build something greater than the sum of us. However, while that will not happen today, or perhaps even this year, it would be nice to keep track of these resources that I’ve got so far, so that they are not stuck inside the ‘blog’ of Bloglines.

The W3C had a useful Mobile Web Initiative conference in 2008 and many of the papers and posters provide good background. Kiwanja.net provides a database of articles about the impact of mobile both globally and within specific regions across a variety of projects. The Putting People First blog had a good round of links relating to the ICT4D Africa Gathering meeting in April 2009. The Putting People First blog is always a good place to look for this kind of material actually.

The other week as part of the summer conversion MSc group project preperations I took the Measurable Value case study by Ryan Shriver and turned it into a working example that the students needed to work through. This exercise worked, but could’ve been better. Ryan also gave me permission to make use of his example as I wanted, so I reused his materials where it seemed appropriate. Thanks Ryan!

Shriver works through a clear voluntary organistion example, and provides the answers along the way, as you do with an article. I decided that the students would need to hunt for their answers amongst some worksheets that I would give them. After looking round I found some similar materials  centered around Impact GiveBack, and some relevant news items that I could reduce to workable data. With this in hand we could then work through Shriver’s six steps of Evo.

The other links that had usable background information were: http://online.wsj.com/article/SB121554292423936539.html http://www.newsweek.com/id/62168 (26 Oct 2007 issue) http://www.slate.com/id/2183542/pagenum/all/#p2 and some made up data about goals for volunteer hours and donations that I extrapolated from the data found elsewhere. This meant that the students had something to look through in their hands, and didn’t need to go hunting on the internet to find information. Hmm, that might be interesting to do as part of an ongoing project perhaps, if each team had to do an extended scenario.

Earlier in the day I’d gone through a reduced slideset of  a talk by Tom Gilb in October 2007 to put Evo into context and explain how it approached software engineering and project management. This seemed to go fine, and followed other discussions about waterfall and agile approaches in general. Therefore the general groundwork was laid we were explaining why Evo is required, and how it is used in conjunction with agile projects.

Working through the six steps that Shriver sets out, and approaching the case study the same way that he did, worked well. I could set up the issue and then point the students to the handouts which they discussed in groups around tables. After ten minutes or so, then I gathered up answers on the blackboard and we discussed the solutions provided for that step. Instead of gathering up solutions verbally, a better approach might be to have the teams submit written solutions, which could then be merged at the front of the classroom, so that no group feels there solution was ignored because another group listed it before them.

The only problem encountered was with creating workable impact estimation tables based on Shriver’s spreadsheets. I showed them his examples and how they could be used. A better job next time would be to prepare his examples a bit further, and clarify how the IET relates to the data from our examples, instead of showing completed ones for his example, which was similar, but not quite the same. Providing partially completed ones would mean that they could then fill in the rest per the data they have for the scenario, instead of reading what’s on the ones Shriver used.

All in all, this worked, and I’ll definately use it again next year after I make the suggestions noted above. Having people work through the scenario themselves gives them a feel for the approach, and how it is applied. Having a reading to take away that uses an example similar to the one they worked through themselves is priceless. So far so good, and the projects now seem to be starting off without too much trouble.

s part of the training and workshops I organised for the group projects I’m running this summer I decided to see how some of the ‘games’ would work in conveying agile prinicples to the students. I tried James Shores ‘Offing the Off-site Customer‘ and the ‘Lego XP Game‘ last week. Both went reasonably well I think.

On Monday I gave the students an overview of why they’d not be using the waterfall model for software development, and why we’d go for incremental and iterative development processes instead. In particular I explained why small we’d want to push decisions to as late as possible because of the cone of uncertainty, and therefore a user story on a post-it note would suffice to capture the essence of the need at the start, and you’d end up getting more details in a chat with the person later when you knew more about the product being developed. I also pointed out that waterfall assumes the product is being manufactured, when in fact, as agile assumes, software development is really, as Clark Ching points out nicely in Rolling Rocks Downhill, that it is product development: what is the best way to make this ‘new’ product or service? Software development is an exploration, and therefore change is the normal state of affairs, as nobody can know all of the requirements up front.

On Tuesday we looked at requirements gathering and user stories. This went well. We also used Shore’s game to highlight the relationship between the customer and the developer. In the first run of the game, where the developer and the customer are divided and the analyst conveys the information, some students started writing down descriptions of the diagram that was ‘the product’, and others only laterly, after suggestions, started going back and forth desciribing what was needed.

In the second version, when the developer can speak to the customer and the analyst at the same table, then this went much better and a few students even picked up the idea of developing ‘tools’ to establish right-angles and function as ‘rulers’. Very nice work by them.

On Wednesday we looked at estimating and planning following the ideas of Mike Cohn. This went well, and we followed it up with the Lego XP Game. This was delivered smoothly, and the students soon learned not to mess with the lego outside of the ‘build’ time, as my assistant and I had to destroy artifacts being built in the estimating and planning stages. Our explaination was that ‘oops, the customer didn’t like that version. A shame you wasted your time building something no one asked you for.’

The game follows a clear ‘estimate, plan, build, retrrospective’ phases and with the help of an online stopwatch worked well. In the second, and especially the third iteration of the project, the students knew what they were doing, and focused on the estimating and planning more appropriately.

We had seven teams of four, as we didn’t have enough lego for nine teams of three - the box of lego that would hold four/five? reams of paper was just enough. The more lego you have the more interesting and easier the tasks are to complete for the teams.

Using both games to reinforce the ideas covered in the lecture worked well I think, and I’ll run them again when we cover these topics again. It broke up the day well, so that it wasn’t just lectures and practicals, but also some relevant experience ‘doing’ what is needed so that the students understand ‘why’ the different steps are necessary. Both games were full of noise and excitement and did a good job of representing the ideas and processes of agile methods. If you’ve not tried them, then you should. You’ll find links to others if you google ‘agile games‘, or head to agile fun.

The last week has seen a flurry of activity in the Ruby and Rails world where there is a buzz about geting newbies up and running easily. Some of these are new ones, while others have been around for a little while but as I’ve not come across them before I wanted to make sure I noted them down here for later use.

RailsBridge is a new project underway as a resource for people to learn Rails via a variety of paths and tools. Over time new practicals and tutorials should appear that people can follow to learn Rails and Ruby.

Rails Tutor will provide the courseware for RailsBridge in a number of bitsize chunks that people can work through as needed. It should cater to those who are new to programming, as well as those who have done programming before and are just new to Rails and Ruby.

Ruby Challenge will provide exercises and games in Ruby to make learning fun. This could be the nice ‘extra’ to the whole RailsBridge package. If it works well, then this will be a bit of fun to add to classes for students.

While watching the mail list for RailsBridge I saw a few interesting sites pop up, which I should mention here too.

Ruby Learning (.org) provides a number of on-line classes for people to take, and provides mentors to help people with the work. This looks quite useful for guided learning.

Ruby Learning (.com) provides a class in Ruby that is all there laid out for you, and you can work through it yourself and read the notes at your own pace. In addition to the on-line tutorials, you can also download an e-book that looks like it goes over the same material.

Ruby at About.com also provides a lot of materials and how-to guides for those learning Ruby as well as Rails. This covers obvious resources, plus adds more of its own too, which is nice. They will also be helping out with RailsBridge too.

All in all, it’s a good time to be learning Ruby and Rails.

There is a new 2009 Chaos Report from the Standish Group. It still shows the poor success rate for software projects, and that many are still challenged with budget and delivery issues. Things are not any better since the 2006 Chaos Report either. They are somewhat better than the original 1994 (or at scribd) report at least.

• Successful projects (on time, on budget with requested features): 32% in 2009, 35% in 2006, 16.2% in 1994
• Failed projects (cancelled prior to completion):  24% in 2009, 19% in 2006, 31.1% in 1994.
• ‘Challenged’ projects (over budget, missing features, late deliveries): 44% in 2009, 46% in 2006, 52.7% in 1994

According to the above the situation has actually gotten worse, except that now fewer are ‘challenged’ than in the past. We are not deliverying more successful projects, and the likelyhood has increased that the project will fail.

On the one hand, it is sad that these sorts of results still appear, despite the trends towards more adaptable and flexible project management and software development practices such associted with agile. You’d hope and assume that best practices would spread around the industry and we’d all get better at building software applications. Obviously not, if you think about the UK NHS software project and it’s ongoing mess.

On the other hand, as pointed out by Glen Alleman, we don’t know the basis of the Chaos Reports: how many firms were questioned, how many replied, is this a real sample of all projects, or of just the ones covered in their survey? We don’t know, so we can take the results with a pinch of salt.

As Pavel Brodzinski argues, everyone knows about these reports, so the results don’t make a big impact. Only a few teams, he says, will bother to train themselves to be better.

If you think about it though, that is sad too. People are stuck in a rut and like to stay in their comfort zone.

It does present an opportunity though for those firms which do finish their projects on time, and on budget and with the features requested by the customer. They have new stats to use in their marketing. They should also be able to keep bringing in clients on a regular basis if they can show a proven track record of successful projects.

Update 19 May 2009: Found a reference to a paper given by Jim Johnson of the Standish Group at XP2002 on ROI that had results of Chaos Report 2000, that were just as dire as others. The idea pressed here was to focus on early results, customer involvement and to keep the project small if you want to be successful.

As part of a module on the MSc Software Project Management programme I had my students write an essay comparing a work breakdown structure for the iteration of a project and the approach taken for ‘business value delivery’ described by Ryan Shriver in his Measurable Value with Agile article. This produced some interesting results amongst the students.

I had eight essays to read from students, who all work in the software industry. Some work with traditional software development processes, and others follow more agile and TOC approaches, and everything in between.

Of the eight, three thought it was a good approach, which they thought would work well, three had some criticism of the approach, and could see it being applicable in some places, while two were generally against the ideas put forward.

The gist of the arguments against and ’sometimes’ seemed to be down to two aspects. There were some who had different interpretations of the text, which means that I need to lay out this approach more clearly next time around, so that it’s better understood. Others had a difference in opinion about how the ‘value’ of a solution should be measured. Some felt that you can’t measure the knowledge gained in developing a solution, for example, while others thought that this approach doesn’t take full stock of the margin on some solutions. Again, this looks like I need to lay out the importance of cashflow, and the difference between througput and cost based approaches.

As the course has gone over some of Tom Gilb’s evolutionary project management (evo) ideas before this, I was a little surprised that more weren’t supportive of the ideas. I suspect part of the issue is that I need to take more time laying the ideas out more clearly, which I’ll do when I re-write the course text. Similarly, I’ll also need to lay out Eliyahu Goldratt’s Theory of Constraints more fully. I just finished re-reading them and can now appreciate where they fit into the coursework more clearly. It’s also quite interesting how some parts of TOC overlap with EVO as both are evidence based approaches to solutions with results.

All in all though, I think this exercise will get used again next year, or maybe something similar if Ryan, or someone else comes up with a better ’step-by-step’ guide.

I was speaking to a friend, who’s doing an English degree at Dundee University on Saturday, and she was telling us about how she didn’t have any exams this term and what they were doing instead. For her Vision in Film course they do weekly ‘journals’, which are 500 word essays on some aspect of the weekly topic. Each of these are handed in and a small mark given for the work. At the end of term, the students revise them, and use the appropriate ones to contribute to a larger ‘journal’ that argues an issue of their choice. So the students are doing weekly writing, which is good, and they get lots of feedback on their writing skills, which is good, and they also get to have a say in their coursework, which is good too, and the course organiser has one less exam to mark too, as the students are writing something more like what they’ll do for ‘work’ one day, which is also good.

Something like this could be done for the enterprise computing and security course I teach. The students are just starting their conversion degree, so they need to process and codify their thoughts on the subjects we’re covering in the term. A weekly essay would help them to keep up to date with the materials being covered in the course, and also give them lots of practice for their writing too. They already do a longer essay, which I’ve just marked and found that while some could do this ok, others were lost in the idea of what an essay should do, and how to structure arguments. The weekly feedback would help to overcome this problem, so that their larger essay would be more of a challenge, and rewarding for them.

To provide a focus for their work it might be useful to have each student write their weekly ‘journal’ as part of an ongoing analysis of a firm from the IT perspective. This would add to the notion of a  larger analysis or case study to see how IT and IS is applied in a consistent manner across a firm. Each week they would be looking at the firm from another point of view, with respect to another piece of technology and assessing how well it works, or doesn’t for that firm.

If the longer essay is also kept in place, then this becomes what is submitted instead of an exam. The exam for these students is then limited to the security part of the course perhaps, or maybe something else is done for that, which assesses their work in that part of the course. This will need more thought, but looks like it might be useful at some point.

I’ve had a few requests from former students for help finding work. Sometimes I can point a person to a job, and sometimes I can’t. It’s great when it does work out, but there is no guarantee. This is especially true in the current (April 2009) job market, with a number of companies stopping hiring altogether.

This is not to say that no one will get a job in this climate. People will get jobs, and it’s up to you to be the best prepared you can be, and to ensure that when a job does come along, that you are well-placed to take it up. What follows are some general guidelines on imporving the odds that you’lll get that interview, and to help you prepare for the interview. This is based on what I’ve done, and what others have done. For example, go look at Matt Raible’s bio, and notice his degree. He got in the profession through self-learning, and working on open source. You can also look at what Joel Spolsky says about resumes (cv). I’m sure that there are others too, and of course, you can always go along to the careers service at the Uni too and check their jobs listings.

The preparation

First, you need to prepare yourself and your cv for the job. Write a general, all-purpose cv that has everything you need. Which schools you went to, what jobs you had, and all of that stuff, plus other interests and hobbies, and publications you may have done. This cv becomes the basis for all of the other ones that you’ll produce, so put everything into it, and don’t worry if it’s long.

Second, cut and paste a more tailored version of your cv so that you have, for example a ‘programming’ one, and another that is an ‘analyst’ one. Each of them then puts your past experience in these areas to the fore. You should aim to make these no longer than two pages so that the person reading them knows the general outline of what you’ve done, and has a reason to call you in for an interview. You don’t put everything into these ‘templates’ so that you can tailor each of them per the job you’re applying for, but still keep it short. The goal is to get an interview, so you want to excite the company’s interest with your cv.

Third, you should have a generic cover letter that you use to send with each job application. Each of the cover letters should then be tailored appopriately to highlight the key points of your cv, which match up with the points they raise in their job advert. If you’re applying on spec, then be hightlight how your skills will tie in with their current products, or services. Do NOT just change the name, etc for each of these, but take the time to ensure that it is keyed to their needs and services. You don’t want them to bin it when they notice that it looks like you just used mail-merge to print it out. You want them to give it due care and consideration, so you should do the same.

Fourth, assuming that your hard work so far has paid off, and you got an interview date, then the next hard part starts as you prepare for the questions. I dont’ remember, which interview book I found these in, but I have found its list and philosophy useful. This list of questions boils down to ‘why should we’ and ‘why shouldn’t we’ hire you. Take the time to write out full answers to each of the questions. Tailor each question to the specific job interview you’re going to attend. Yes, this takes a long time, and yes, they do ask these questions. I know that I’ve had them all asked in one interview or another, and boy was I happy that I’d prepared for them. If you  prepare for them, then you can snap back your answer right away instead of hmm, hwww, mull, mull, answer. It shows you care about the job they have to offer, and did your homework.

The key point about answering these questions, and any others, is that you remove any reason why they might not want to hire you. Therefore, have answers, as suggested, which put context into your answers, and help them to say ‘yes’.

The first time you go through this it will take you hours. Don’t worry, it’s all good work, and you should write them down as that forces you to think about them, and process them more, than if if you just ‘think’ about them, or say them out loud. As with the cv and cover letter, you then tailor them again each time you go for an interview. Thus only the first time takes a long time, while subsequent ones will be able to reuse the generic answers.

Lastly, it’s your call about taking up offers of coffee and biscuits during the interview. On the one hand, they do relax you perhaps. On the other, however, you run the risk of spillage, and having your mouth full of food when they ask a question. Just be awake to the possibilities, and dangers.

So with this in hand, where do you look for jobs?

Where to hunt

If you’re after temporary or other academic jobs, then you need to subscribe to jobs.ac.uk for your region, or interests. There are also no end of Scottish specific job sites, and national ones too. Look at as many as you can.

You should also check out the recruitment agencies too, but don’t hold out your hopes there. I know lots of people end up with interviews through them, but it’s hard to actually land a job through them. Some people just avoid them, and similarly, you should also be aware that a number of firms don’t use them on principle too, so they won’t have all of the jobs you may want to apply for.

The other place to look for jobs is to find the sites for companies you want to work for, and apply to them. If you’re staying local, then get the yellow pages (or use yell.co.uk), and go through the appropriate categories to find the companies and send them emails with your tailored cv and cover letter. Yes, this takes time, and yes, it is a slow process, but it should yield some results.

Keep your skills fresh

While looking for work, you need to show that you have relevant skills. This is epecially true if it’s been a while since you graduated, and if you find that all the firms are saying ‘experience required’. So, if no one’s hiring you because of this, then you need to make your own experience. You can do this a number of ways.

One option is to volunteer work for people. Sure, it’s not glamourous, but it might be. Either volunteer to do web sites, or other projects for people you know, or go find a community group that needs some help, and which you’re interested in, and then do something for them. Then add it to your cv, and mention it in your cover letters where appropriate.

Another option that will get you more relevant experience is to find an open source project, which you like and contribute to that. Yes, you will need to start at the bottom doing patches, and then moving up the way. This option means you will get a view of the full sweep of software development as you’ll need to work your way through the use of all of the tools of modern development using source control, tests, and other aspects depending upon the programming language. This will also stand out on your cv.

Yes, both of these options mean that you might be working a ‘normal’ job as well as doing these ‘non-paying’ jobs. It does mean that you do pay the bills, as well as also keep your skills fresh, and relevant. It will also mean that you’re paying a small price for what you ‘want’ to do, instead of resigning yourself to not doing what you want to do.

As you can see all of this will take time to take effect. However, I’m also sure that it will pay off for you. So go tidy up your cv, write out the answers to the interview questions, and start picking the companies you want to apply for. And, also think about which open source projects you really like and want to contribute to.

Good luck, and let me know how you get on.