Category Archives: Software Project Management

Posts about software project management in general

The Silence Experiment at #Agile2017

While at #Agile2017 in Orlanda I was able to participate in ‘The Silent Experiment’ being run by Sal Freudenberg, Katherine Kirk , and Chris Corriere, as part of the Audacious Salon. I’d missed this in Edinburgh during it’s unveiling at Lean Agile Scotland, and had read about it in Sal’s ‘Inclusive Collaboration Experiments‘ book, where it’s described as a way to let people better understand the diversity of their colleagues as part of their neurodiversity work. The experiment ran as follows: enter the room and sit quietly at a table so that you form a team of three. Sal set the context for the session and told us when we could open the package and instruction booklet to begin. We had 40 minutes to complete the assembly of the prosthetic hand, decorate the container and take a photo to include in the parcel for the person, who’s to receive the hand. I formed a team with Pia and Lisa Crispin. I found the session exciting and intriguing because we were doing meaningful work. This is something Sal mentioned, that was an integral factor in her early versions of the workshop, whih used Lego. Participants found it less engaging when the work was ‘build a model’, and that the session went better when she switched to hands. I also found it frustrating when I wanted to share ideas, but couldn’t because of the silence. Katherine, happily, kept walking around with a post it that said something like “write down your thoughts and feelings as they occur” so that we didn’t forget them for the debrief later. The frustration was as much about good thoughts as much as about ‘oops, I think I did it wrong’ ones and wasn’t sure how to explain my concern. We did get there in the end, and Lisa kept us going well by pointing out that all pins should be not flush, but recessed into the hand. I found the silence revealing for a number of reasons. First, there wasn’t pressure to keep talking, and we could focus more clearly on the work without the noise from other tables to distract us. Second, we could consider our repsonses to issues as they arose more carefully, and respond differently than we might have otherwise done if we’d all been talking through the building of the hand. Third, while it was hard to share confusion about something, or to ask if others are also confused, it was comforting to trust your partners too as we all eventually worked our way through the produres. When someone had problems, then we’d offer via gestures, another team member a chance to try the step.

The experiment revealed too, that doing meaningful work is an important part of this experiment. For me and others, knowing that the hand we were assembling would change someone’s life meant a lot to what we were doing. That offered a huge amount of empathy and love for the activity. Building a model with Lego just isn’t the same. However, I’ll probably try it this next term using some of the Lego Serious Play sets as my own experiment. This ‘meaningfulness’ then becomes a debrief point.

All of this is by way of showing how we need to have more diversity in our workplaces, and be inclusive so that end the usual monoculture. Come join the crowd at http://inclusive-collaboration.org/ and do what you can to help spread the word.

As Katherine’s poster noted: “insight does not arrive from objects – it comes from ‘insight containers’ called HUMANS” Humans are imperfect, and no one human can know everything, so  we need collaboration in order to gain effective insight. And the best collaboration is that which fosters inclusive diversity.   Save Save Save

Crucial Conversation Card Game

A friend suggested reading Crucial Conversations: Tools for Talking when the Stakes are High and I found the book very useful. It offers strategies to help with those difficult conversations that we all need to do now and then, which are ones we need to do, but which we know will be difficult. I also found it similar to the advice that’s found in How to Talk So Kids Will Listen & Listen So Kids Will Talk, which despite the title, is more than a parenting book. Together the two books cover many useful strategies.

My goal was to set up a workshop so that people could ‘work the materials’ and leave with some useful skills to start them on their way. While I wanted to use this with my computing students so that they could deal with team members better, I also knew that I’d have good audience at Play4Agile 2015, so tried my prototype workshop there.

The workshop went ok. People liked the idea, and offered very useful feedback. This is beauty of unconferences: you can present your ideas, and know that you’ll get feedback you can use.

So, after modifying the materials, and the approach of the workshop, I tried it again today with students. I created a deck of cards with the ‘rules’ and ‘tools’ from Crucial Conversations and had a handout for them to take away too.

crucial_conversation_prototype_cardsI started with letting each table look over a deck of five cards, and discuss them in general for a bit. This meant they could talk in safety of their group. Then after five mintutes or so, I opened it up to the group for people to say which cards resonated with them the most, or other comments about the cards.

This was followed by trios of students with one using a card to guide their discussion with someone in a difficult scenario, while the  third person observed the situation. After 5 minutes they can stop and discuss how it went with the observer, offering their view too. We did this with four chosen scenarios and it all went well. I will definately try this again, and will also see about getting some better designed cards done too.

The card templates  can be printed and glued to playing cards or similar, and the handout offers the background and scenarios you can work through too. If you use them, then please let me know how they work for you.

Simple (non-coding) TDD Game

I did an intro to test driven development (TDD) talk for TechMeetup Aberdeen last night and started with the ‘simple TDD game‘. I modified the game based on comments there, and made a few changes of my own. I used 2×4 Lego bricks as ‘rulers’ to be the ‘testing tool’ as this was easier than finding a large number of actual rulers. I also added the ’round zero’ as suggested to show ‘current state’.

I wanted to try this game as it was the only TDD game I could find that wasn’t also a coding exercise. I wanted a way to introduce TDD to an audience that held a mixture of developers and others. It also let me try the game to see how it might work with a larger group of students by way of introduction to TDD at a later stage.

My modified game ran as follows:

Three one minute rounds with variations:

The ‘dev’ folds the paper where  a fold should be, say 1.5cm, or 3cm in from an edge, or in our case use a 2×4 Lego brick (3cm long), but you could also use paperclips or something else that’s readily available to use as the ‘inspection tool’.

The ‘tester’ measures the fold to see if it meets ‘spec’.

At the beginning of the round, have the team estimate how many accurately folded pieces of paper they can produce in the 1 minute iteration. Keep track of your score on a piece of paper.

Round 0 – Throw it over the wall simulation

There is no talking

Sit back to back, or maybe at different tables in the room if space allows. We were in a lecture theatre so side by side seemed to work ok. The dev should fold as many as possible and hand them to the tester, who should test as many as possible.

(You could discuss ‘queue’ wastage comments too about ‘stack’ waiting to test, and feedback loop on ‘right/wrong’ during retrospective of round.)

Round 1 – Test After Development (TAD) simulation.

In this round, have the dev make the fold and the tester measure the placement of the fold. If it’s right, then good work! However if it’s not exact, then the paper is given back for a refold. At NO time can the dev person utilise the ruler, this is only to be used by the tester.

Once they ‘team’ get the fold right, the unit of work can be counted as complete.

Round 2 – Test Driven Development (TDD) simulation (almost pair programming)

Allow the dev to utilise the ruler, the ruler in this instance simulates the ‘test’ by having the dev use this the fold should be right first time. The tester can help in whichever way seems suitable.

At the beginning of the round, have the team estimate how many accurately folded pieces of paper they can produce in the 1 minute iteration.

Finish, review the scores, discuss the insights from the game and relax.

We did brief retrospectives after each round to see how many people completed successful and what the ratio of folded/correct was for the teams. We didn’t go into comparisons of team practices, but that would be something to consider for a longer session perhaps.

One team inadvertently tried batching the folds as pieces stuck together, which led to a brief discussion of whether this would be a good idea or not. After pointing out that when it worked, this was fine, but that ultimately you’d be letting through untested pieces as you’d only be sampling the output to some extent and feedback would be delayed. Batch size of one is the preferred process for this game.

Some discussion went on about how the game rounds related to programming, and tied into these questions which brought home the main issue of shortening the feedback loop between coding and finding out if there were errors, or bugs.

1) how many of you work with legacy code? (legacy == untested code from Michael Feather’s definition)

2) how do you know your code works?

3) how do you know the new code you just added didn’t break the old code?

4) when will you find out if something broke? (how long is the feedback loop?)

5) what would happen if you speeded up this feedback loop?

The game ran well with the usual fun and noise you get with a good game as people realise the changes they need to make, and cheers at results become known. The one minute rounds went by very quickly and teams that thought they might fold 25 or more pieces found they only managed 10 or so, of which maybe 3 or 4 were ‘to spec’.

In any case this is a game to try again with a larger class. I also want to find a way to do this with only Lego so that I don’t need to keep cutting/tearing up pieces of paper, which become a chore quite quickly. Still, nice game and maybe it’s fine as it is now.

Thanks to Hurricane Four for the game!

The Four Process Phases

I’ve previously written down the system development process for students to use from the high level. This post will break things down into each section of the four sections of cycle (discover, define, develop, and deliver) with some ideas of what should be proposed for each of them.

Discover

Starting with ‘discover’ is where the team meet the client and discuss the percieved issues of the client. The purpose here is to explore the issues raised by the client and the context of the situation in order to establish the parameters of the application. In addition to interviews, probing with Five Whys (training example and TDD example and ‘how to run exercise‘) can be useful here to ensure the problem is being addressed correctly and its full context taken into account. At this stage it is important to not consider solutions, but rather gather ideas, and defer any judgement on possible solutions. In general we are diverging from the original idea and expanding possibilities.

A suitable service design template might be useful at this point. This would help ensure that appropriate partners are brought into the process and that nothing is forgotten along the way. You may also want to use the customer journey canvas from the This is Service Design Thinking book, which is a useful guide to the processes involved and the tools, which can be used for these four stages. The other suitable canvas, which might be useful in some cases is the business model canvas from the Business Model Generation book (where you can download a useful extract too).

Define

In the ‘define’ phase potential solutions are explored. The goal is to expand possible solutions and then to start focusing on viable ones, which can be carried forward to the ‘develop’ phase. This is the phase of brainstorming and ideating possible solutions. A creative problem solving process can overlap between the ‘discover’ and ‘define’ phases to help determine suitable boundaries of the problem, while also generating possible solutions. Many general brainstorming game sessions are detailed in GameStorming and Innovation Games. Chosing which game to use is a matter of determing the type of scenario for the appropriate people involved and the desired goal. Following the session the ideas can be compared using something like Impact Estimation Charts (further example and template), or maybe develop something more out of the CPS process and in particular step 5 suggested by CPS to see which will provide ‘the biggest bang for the buck’.

If the capability is a available, then a facilitated StrategicPlay session using Lego Serious Play may be suitable to help understand the issues of the problem and possible solutions. A StrategicPlay LSP session can help build a shared vision of the problem, or possible solution, as well as to possibly strategize future scenarios, or to understand the context of the problem and the intricacies of behaviours between actors.

During this phase the team should also determine the minimum viable product that is to be developed. You can find MVP discussed with reference to wikipediastartups, and software. This is the simplest, most basic solution which can be released. The goal is to produce something for the end users sooner rather than later, so that feedback from actual usage can be used to tailor a better version. The goal of MVP is to keep adding parts of the product to the customers, instead of all of it at once. Start earning business value sooner, rather than later.

From the ‘define’ idea solution possible interfaces can be rapidly prototyped on paper, or some other simple method used to create a mock up, which can be shown to real users for feedback. Based on trials, the prototype can be refined again and shown to others for more feedback. When enough of the minimum viable product is ready as a prototype, then this is moved onto the next phase. You’ll notice that we started this phase with many possibilities and have narrowed them down via a number of processes to the bare minimum required. We have converged our ideas down based on usable feedback from users.

Develop

In the ‘develop’ phase a working prototype is developed and refined based upon ideas generated in the ‘define’ phase. This should be done using an agile process (wikipedia, scrum & XP) that incorporates incremental week, or two week long, timeboxed iterations based upon the client selecting the most suitable features to build in that increment. In order to keep the quality of the codebase high the team should be using appropriate agile practices such as pair programming based around test/behaviour driven development (TDD/BDD) so that the team only build what is needed. As the completed iterations are shown to the client these should be confirming hypothesis about which features are required, and other issues such as which user interface works better. Successful features should then be pushed onto the ‘deliver’ phase.

When the team is unfamiliar with agile practices, then games such as the Lego XP Game, or the Lego Scrum Game should be used to introduce the ideas. Activities such as CodeRetreats, or CodingDojos should also be used to introduce pair programming and TDD/BDD practices and bring people together too. The book to read for this phase would be something like Agile Estimating and Planning, which covers the basics clearly.

During this phase the process might be diverging out again as ideas explored in ‘define’ are refined and new possibilities explored while building a solution with the client. As the team and the client are also testing hypotheses, other options will also be explored. There might be lots of going back and forth between the ‘define’ and ‘develop’ phases. The key to successfully doing this will be that the team and client base decisions on some notion of ‘biggest bang for buck’, and using a ‘build, measure, learn’, or PDCA cycle, so that validated understanding is being used to make the decisions about what to include and push onto the ‘deliver’ phase. This is all greatly explained in the Lean Startup book, and illustrated in the Toyota Kata blog post using PDCA.

In order to keep the workloads manageable, the team need to institute a sort of ‘work in progress’ kanban system (scrum & kanban book) so that work is focused and delivered quickly. The clients and users only see ideas that are implemented and tested, so it is important not to have too much work ‘in progress’, because that would slow down the feedback cycle. Looking at Henrik Kniberg’s thoughts on Metrics would help here. Using a kanban board to limit the work will make this easier to achieve. There are a number of games that can illustrate these benefits such as the Kanban Pizza Game, or the Frog Factory Kanban Game.

Deliver

The purpose of the ‘deliver’ phase is to make the application go live for the client and their users. During the ‘develop’ phase limited users should have been trialing the application so that lessons could be learned, and from that knowledge final features should be pushed to the release version of the application. A continuous integration system should be used to ensure that all of the code is properly tested for smooth integration and any errors quickly caught and fixed. This is mainly to catch situtaions where multiple developers are pushing code to the version control system and one misses a change that someone else made and a test fails. It provides a useful safety net, which is not too hard to add to the process. The line between the ‘develop’ and ‘deliver’ phases can be permeable and the only difference might be that some features being used are temporary as part of an ‘a/b test’, or some other means to measure what is needed by the users, and thus might disappear if not deemed useful.

Together each of these phases should be a part of each project and while the team might spend more time in the ‘develop’ phase, they should also be sure to spend suitable amounts of time in ‘discovery’ and ‘define’ so that they ensure that they ‘develop’ the right application because they took the time to ask the right questions in the ‘discover’ phase and tested out prototypes in the ‘define’ phase to see if their ideas had merit.

Further resources

Further resources can be found to cover each of these phases. Some will be obviously applicable, while others will be less so, but will provide background suggestions for context. The focus here is on the service design aspects, which I’m assuming are new, and that the agile and other software aspects are familiar enough already.

d’school bootcamp bootleg with the basic process (they use five phases to the four here).

Service design tools has a wealth of material that can be used across the project.

Gamestorming site with games and suggestions, which can help with the ‘define’ phase.

Innovation Games has a lot of games, which can be used in the ‘define’ phase.

Conclusion

So there you have the basis of a process to co-create software bringing together service design and agile approaches. This is still not quite ‘right’ but pulls together most of the details I want to see covered. As with the post on ‘the process’ this is still a starting point, which I’m sure will change over time. Any thoughts and comments greatly appreciated.

The Development Process for Group Work

Discussions with a good friend this last week made me realise that I’d never put my thoughts down on how students should be building their applications before. Thanks friend, your prodding is greatly appreciated. Sure, I’d been thinking about it and determined what was needed from the software development process, but since moving more into the service design and design thinking camp, I’d not coalesced these ideas together. As always with these things, this is just a snapshot of where my thoughts are now. As I get a better understanding of this all myself, I’m sure my ideas will change. In any case, it is useful to document the starting point.

I’ll roll this idea out with the MSc students on group projects over the coming summer and then iterate it for other group work next academic year. These students have already done some of these things in isolation as part of other exercises, but other parts will be new to them. Where possible, I’ll pull in materials from elsewhere and use things they can run on their own. However, some parts will need to be facilited by myself or other suitable staff members. These group projects are always done with an external client across a variety of domains.

The process starts at the top and goes around clockwise with the red labels of ‘discover, define, develop and deliver’. This follows the British Design Council ‘double diamond‘ where discover and develop are divergent phases, and define and deliver are conceived as convegent ones. Putting this into a wheel is based on a DNA Wheel diagram from Sarah Drummond in her Embedding Design presentation.

The process also overlaps with the creative problem solving (CPS) stages used by Basadur, and thus also suggest phases and activities for each of the stages. While that breaks everything into eight phases of the circle, we can see them mapping onto these same four phases without too much trouble.

The orange labels suggest activities for each of the phases. I assume that each group will use all of these in the phase in co-creative work with the client. After fact finding and understanding the issues involved with the client, then they will brainstorm and ideate possible solutions. One or two of these will be rapidly prototyped according to whichever will provide the ‘biggest bang for the buck’, or some other logic about a return on the time/effort invested. The best of these ideas will be carried forward into the next phase where a more detailed prototype will be developed and refined based on user feedback. Accepted and validated ideas from the prototype will be moved into the deployed version that is released.

The blue labels suggest specific activities that will implement the orange activities. You can assume many more of these, and these are here only as typical versions of the activities I expect to use with the students. During the discovery phase this will include empathy maps and personas based on interviews. CPS can be used inbetween the discover nd define phase, while StrategicPlay sessions using Lego Serious Play can be used in the define phase. Needless to say many of the ideas in GameStorming could also be used here too.

The green labels are ways to help learn the blue labelled activities. They are there to provide another aspect of the process.

I see the Plan, Do, Check, Act (PDCA) from Deming, and the Build, Measure, Learn from the Lean Startup cycles sitting between teh ‘define’ and ‘develop’ cycles as ideas flow back and forth between them. Successful, ‘validated’ ideas move onwards to the ‘deliver’ phase.

The next step for me is to flesh this out some more with specific activities for the students in each phase along with more detailed notes and references for them. I’ll put in more references here too, for the rest of you too. In the meantime, please leave any comments about this you may have.

PM Camp Aberdeen, 26 November 2011

The PM Camp Aberdeen event for project managers ran on Saturday, 26 November 2011 at the University of Aberdeen, as noted on the sign up page at http://pmcampaberdeen2011.eventbrite.com/. We had a dozen people in the end. There was a mixture of people like myself, who ran some projects, to several consultants from Logica who ran numerous projects. There were also a number of beginners to the field, who were just getting started and a number in between. Everyone contributed during the day at one point or another, and the questions and discussion seemed to flow well during the day.

Due to the snall number of people we ran with one track for the day, instead of the multiple tracks envisioned. We started with a number of general prepared slide decks on topics of interest to a number of people followed by lunch, provided by Logica, and an afternoon of general open space discussions which carried on the general theme from the morning.

One thread that ran through the whole day was how to integtate agile practices into general project management practices. As everyone was from the software development field, this is perhaps not surprising, and worked well as a point of discussion. Some of the talk went from basic practices, up to the general philosophy of agile.

Other topics during the day were tools for PMs; challenges of PMs; and Wikispeed on using agile for automotive projects.

The day was good and all participants thought that (a) there should be more of these PM Camp events, and that (b) we shouldn’t wait a year, but have them twice a year, so another event will be scheduled for May.

Thanks to Rajeev Hasija for help in organising the event, and bringing the Logica support to the event, and also to Polly Purvis at ScotlandIS for their support of the event. We couldn’t have done this without your help, and it’s greatly appreciated.

Time for a project managers open space event?

See the update from 4 November at the bottom of the post

I’m thinking we need to have a project managers open space day. There seem to be plenty of unconferences for developers and coaches to attend, but I’ve only seen one in Austria that a friend is helping to organise in a few weeks time where project managers can raise and discuss the issues concerning them. I’m thinking, why wait? I’d like to propose such an event for late November, early December at the University of Aberdeen. If this works, which I think it might, then we organise a follow up in the summer based on lessons learned from this first run at the event.

This would be a day for beginners as well as experienced project managers and everyone in between to come and share what they know with fellow practitioners. The new can learn from the old, and the old can see things again through the eyes of the newcomers.

I’m thinking the day should have a mixture of proposed talks that are selected by a small group of willing volunteers for the morning, followed by a round of 3 minute long lightning talks on whatever people wanted to highlight. The lightning talks could be used to ‘recruit’ people for the open space topics that followed later. Using this format participants could volunteer a longer ‘solo’ talk on their topic, and others would have a chance to raise the issues of concern to them too.

Topics that I’m thinking people might want to talk about would be:

* agile versus traditional projects

* beyond budgeting aspects for projects

* organised versus self-organising teams

* planning versus unfolding events

The day could look like this:

gather for coffee and registration 9:30-10

two parallel talks 10-10:30

coffee till 10:45

two parallel talks 10:45-11:15

coffee till 11:30

two parallel talks 11:30-12

lunch 12-13:00

lightning talks 13:00-13:30 for anyone to talk on a topic for 3 minutes

open space proposals 13:30-14:00

14:15-15:00 first rounds of two/three parallel open spaces

coffee till 15:15

15:15-16:00 second round of two/three open spaces

coffee till 16:15

16:15-17:00 third round of two/three open spaces

17:00-17:15 concluding remarks

Maybe this is the right structure for the day, or maybe it needs more open spaces and fewer proposed talks. I’m only throwing this out there for discussion, as one proposal. I’d like some comments on it from others, along with another person who’d like to help pull this together.

Right now I need to know a number of things:

First, tell me if you’re interested in the idea, or think it would be a waste of time.

Second, tell me if you want to help make this happen so that we can take this forward.

Third, if you’re interested, and think you or your company might want to help with sponsorship to make it happen, then definately get in touch.

UPDATE: This idea is now going ahead on Saturday, 26 November 2011 – sign up at http://pmcampaberdeen2011.eventbrite.co.uk/

Agile, evo and kanban games

As part of the MSc summer projects preparation I ran a number of workshops and lectures on agile, evo and kanban related topics. These all went well. Some of them were being run for the second time (agile with Lego and the Evo workshop), so they went smoother, while the kanban game was new. I dropped James Shore’s agile customer game and put the kanban game in its place as it seemed more important to run the kanban exercises instead.

The Lego game went much better this year than last. We stayed alert to students trying to pre-build sections and also ran it much better to time. It was good to see that they quickly picked up the details and learned the value of planning which features they were trying to build each iteration instead of just starting to build without planning. See, agile does have planning.

The evo game is based on Ryan Shriver’sMeasurable Value with Agile‘ article, and still needs some work to integrate it better with Tom Gilb’s worksheets on requirements and such like. The ‘game’ is lurking in there and now that I’ve seen a few other software development games, I think I can see how to make this better for the future.

The kanban game was from Tsutomu Yasui, who presented it at Agile 2009. It went real well by the third variation and has probably helped the students manage their own kanban boards on their projects over the summer. The game shows the benefits of applying limits to your work, so starts with a version where you don’t apply limits to the work in progress and then starts adding them in to show how this helps speed development. This worked quite well and I know that I’ll defiantly run it again in the future.

All of these games were run after a lecture/discussion of the topic so they helped to embed the ideas for the students, who could see more than just diagrams, and words about the topic. The game helped show the ideas in practice. I wish we could do this more often with other classes, as this format of lecture, break and then workshop worked real well. It made for an intense week, but worked real well as a prelude to the students working on their group projects.

Solution to fixed price projects

I  found the solution to pricing agile projects. It has been staring me in the face for ages. You see it mentioned by lots of people: Anderson, Gilb, Cohn, Poppendieck, etc. It’s obvious really when you think about it. However, it took Alan Shalloway, Guy Beaver and James Trott to spell out the answer in their latest book. The short answer is: ROI. As Alan et.al, argue in their new book Lean-Agile Software Development: Achieving Enterprise Agility that, assuming you need to work up a RFP where scope, budget, due date and quality are locked, then you can respond and point out how iterative releases will ensure the project stays focused on business needs and enables a faster return on the investment of the project.

With this in place you break up the project into at least two releases, assuming that this is possible (you’re not building an air traffic control system as Allan et al mention), and determine the most business useful features to put into the first release and then get feedback on that while working on the remaining features of the product. If you can break this product development project down into more releases, then their is more possibility of greater feedback and an even earlier return on the investment. Needless to say, you use the usual agile approaches to improve quality, and handle scope.

Using this approach you can make a compelling proposal. First, you can deliver more functionality sooner. This helps to ensure the project achieves it business goals, by ensuring useful feedback earlier from real users. Second, you can provide a faster return on investment for the project, which releases funds back to the firm sooner. This enables the capital to be put to other uses sooner. Third, you may finish the whole project sooner than their planned date because you’re focusing on the needs of the business, and yes, you committed to deliverying all of the scope in the project, but this should happen faster due to your agile and lean approach to the project. This assumes that the scope mentioned in the RFP is still relevant at the end, and hasn’t been changed too much during the life of the project. In any case, you can assume to be able to delivery the completed project early, which opens up new possibilities for both you and the client. They can start another project, they can add more features, whatever.  As for you, your team can move onto a new project or continue with this one depending upon what the client decides.

Software house starts

The student software factory is up and running. It’s on a volunteer basis with about four or five students meeting twice a week for about two hours each session. Some of them do a bit on the projects outside of this time, but not a great deal as they still have other committments for coursework, and paying jobs to supplement their income. Nonetheless, they are enthusiatic and are providing teams to help work out what’s required to scale this up and remove any impediments when we hopefully offer it as an optional module next year.

The biggest holdup so far is getting software tools in place for students and ensuring that all team members can push/pull code changes from the git repositories that we’re using. When I get some time I must set up basic downloads from local sources for students to use instead of downloading from the original sources. Similarly, they need to have clear instructions for setting up system paths, etc for Windows, Linux and Mac OSs, which students seem to be using.

My aim for getting the project management aspects going, user stories, metrics, etc is to introduce them as we go along, and as they’re needed. I want to keep the students enthused in their work, and to let them take the lead to code up the examples as they go along and put order into their work as needed to keep it going in the right direction.

Pursuing the bigger picture of a running software house, was the tangential idea of having any appropriate students helping out in the summer months. We’ll see if that can be sorted out. While we couldn’t offer the students paying work, we could offer them experience working with real clients on real p projects. This would easily run alongside the current group projects for the conversion MSc students that run in the summer, and the individual advanced MSc projects.

Similarly it would be useful to help mentor students who are running their own one-person software houses, of which there seem to be a growing number, to help them grow and improve their processes. I’m assuming that most of them slide into this by accident, and only pick up new ideas as they cover that part of the process in their coursework, or after they did a placement with a firm. Hence, they could use some mentoring to help them on their continuious improvement. It would also be useful for them to meet their fellow entrepreneurs once a fortnight or so and to discuss common problems, issues, etc. Must get it organised for next term.