Archive

Author Archive

Iterative planning

April 22, 2014 Leave a comment

I previously wrote about how we combined elements of both Agile and Waterfall practices on a project to allow us to develop in an iterative way whilst remaining within the confines of our client’s Waterfall methodology.  In this post I want to look a bit more at how our iterative development approach was organised.

We planned the development into 3-week cycles.  Two weeks would have been too short to get some of the meatier components completed in a single iteration, and we would have had to break them up artificially.  Four weeks was too long and wouldn’t have given us enough flexibility.  We reviewed it as we went along and we always felt it was the right length.  On the other hand a 2- or 4-week cycle would have fitted better with the natural business cycle – which suited a regular drop in middle of the 4-week financial period.  The 3-week cycle worked well until we reached the go-live date when we needed to release code every 4 weeks and other issues briefly caused us to suspend our regular cycle (by then we had completed the core development anyway).  Three weeks would have worked well with a quarterly delivery cycle once things had settled down again into a regular pattern.

We adopted the agile principle of delivering a build on the deadline, and adjusting the scope to ensure it happened.  Within this, we to ensure that any build we provided was coherent and could process data from end-to-end, even if we couldn’t cover certain cases.  This meant that once we had covered off the minimum requirements, we were always able to deliver into production.

To ensure, outwardly at least, we appeared to be following a waterfall process, the development cycle included all technical specification updates alongside code changes, and all affected unit tests passed (we automated unit tests for new functionality but inherited manual testing for legacy code).

Business Analysts and Designers ran ahead of the development team so that there was a backlog scoped/designed to a sufficient level of detail, on a “just in time” basis so we didn’t waste too much time on low level detail until it looked like it might be in the next iteration or two.  They worked with the development team at the beginning of the cycle to make sure all requirements were fully defined.

The system test team also ran on the same 3-week cycle but two weeks in arrears, giving them up to two weeks to test the last build and then at least a week to prepare/update tests for the next release before it was delivered to them.  As we neared the intended release date we focussed on ensuring that code delivered to production was coherent.

The way each iteration cascaded into the next is more easily shown in a gantt chart:

iterative gantt

System testing prioritised the most important functionality first. This meant that critical bug fixes identified in the initial round of system testing could be fitted in to the next iteration, because at that stage it was being worked on by the developers.  Non-critical bugs identified in testing would be added to the work queue and fixed in the next iteration if possible

Priorities for each iteration were set and revised jointly with the client, especially as the deadline drew nearer.  At each project meeting progress was discussed and changes to priorities noted so the team always had a clear view of what was likely to come next.

Ultimately this worked well; despite constantly shifting sands we completed our initial baseline on time and went live with a system containing all essential code from Day 1.

Categories: Work Tags: ,

A few observations on PRINCE2

December 30, 2013 Comments off

I recently attended a PRINCE2 Foundation and Practitioner course, and have offered some thoughts on my experience of it. Here are a few thoughts on PRINCE2 itself that struck me while I was thinking about my role as a Project Manager, in no particular order:

Not as inflexible as I thought. PRINCE2 has a reputation for rigid adherence to process and for generating lots of documents. Maybe that reputation was earned by earlier flavours of PRINCE2, for the current version allows flexibility and the manual has a section on tailoring. Where I thought my recent practices might not follow the PRINCE2 standard, I discussed them with the instructor who nearly always took the view that it was an acceptable use of tailoring.

Continuous Business Justification. My business users have been consistently poor at this through my career to date. As a rule they produce an initial Business Case produced to obtain funding but rarely revisit it between stages or when there is a significant change, unless more funding is required. They have been especially weak when dealing with change within a stage; some strange decisions are taken about functional changes when a quick benefits analysis would show that money could be better spent elsewhere.

Risks include Opportunities. The Risk Theme also includes the concept of Opportunity, defined as an uncertain event that could have a favourable impact on objectives. I can’t recall ever considering this aspect formally in a project, either as a supplier or on behalf of the client.

Lessons aren’t Learned. Like most people I have dutifully recorded lessons at the end of projects (and also as we go along) but what happens afterwards? In PRINCE2 the start of a project should include consideration of relevant Lessons Learned from previous projects. I haven’t seen this take place other than anecdotally based on the experience of the individuals involved. I’m sure I wouldn’t know how to go about finding applicable lessons within my own organisation, and I haven’t seen any evidence of it within the client organisations I have known well over the years. The other area where we could also do better is to review our own project performance more often, at the completion of key stages. Again, this is something that happens erratically, usually because we’re too busy to do it at the time.

Manage by Exception. A key principle of PRINCE2, to ensure management focus is where it needs to be. A tolerance (in time, money or both) is set for each work package, and as soon as it looks as if it might be exceeded the team leader responsible should raise it as an exception to his manager. This may not affect the overall project tolerance, in which case the manager need not take it further. Although my internal management tends to work on this basis, I can’t say that my client managers have adopted this principle very often, too much man-marking goes on….

One quibble. We don’t usually have a Quality Register (rightly?) As defined in PRINCE2 the Quality Register lists all checks that are planned, and as they take place is updated with the date and outcome of each quality check. Almost all the projects I have worked on over the years have carried out the checks themselves – which are planned properly (scheduled in the Project Plan and described in the Quality Plan), and results are duly recorded – but I don’t recall working on a project that had a central Quality Register. Dare I say it, but I think this is appropriate as I see a register adding little value but a lot of effort to maintain it. When I brought this up on the course it generated quite a bit of discussion. We thought there was probably a benefit in safety-critical projects (aviation, defence) but for normal work having an entry in the plan was sufficient.

A PM wears more than one hat. Is a supplier PM a PRINCE2 Project Manager, or a Team Manager? Of course, the answer is “it depends, …” Often, we might fill both roles simultaneously – as well as being a PM from a supplier perspective we are also the Team Manager from the Client’s perspective at the same time. This significantly alters the view we might take of what is required of us.

Overall, PRINCE2 provides a framework to use to save re-inventing the wheel; as a proven and widely recognised standard it can easily be sold to an organisation. As an experienced PM, I was pleased to find little that was new or that I don’t already do. My experience of the clients I have worked for over the years is that they are less methodical – perhaps that’s why they rely on external consultants so often.

Categories: Work Tags: ,

Course review – PRINCE2 Foundation and Practitioner (QA)

November 28, 2013 2 comments

I recently attended this week-long course run by QA. If you are thinking of attending it or a course like it, I hope that by sharing a few thoughts it may help you decide whether to attend it too. My view of the course is coloured by being an experienced Project Manager, so some of what I say may be less relevant if you are looking to move up into Project Management.

Why go?

My motivation for taking the course was simply to get a “tick in the box”. Many organisations expect it and I wanted to obtain the formal qualification as quickly and painlessly as possible. I had some prior experience of working on projects that were operating within a PRINCE2 framework (on an older version), but I knew I had gaps in my knowledge of the formal process and terminology.

The provider was determined by my employer – however I know that other training companies also offer similar courses and I expect they are not very different.

Course format and content

The course is very focussed on passing the exams, not learning PRINCE2, and should be judged accordingly! It assumes both some Project Management experience and that you have read the pre-learning material. It is split into two parts, covering each accreditation level, which can be taken independently of each other, although in fact all course delegates on my particular course stayed for the full week (as is usual). The first two days cover the Foundation level and the remaining three the Practitioner level, each ending with the official exam.

The format of each part of the week followed the same pattern. We were taken through each of the Themes and Processes in turn to the level of detail necessary to pass the exam, and then tried out a set of practice questions. The Foundation exam focusses more on the Themes, whereas the Practitioner exam looks at both Themes and Processes at the same level of detail. The good news is that the Practitioner exam is “open book”, which means that although there is more ground to cover, you only have to remember where to look for the detail in the official manual. The bad news is that each night (apart from after the Foundation exam on the Tuesday) there is homework to do, in the form of a second set of practice questions reinforcing the material covered during the day.

The middle of the week provided a welcome break when we all shared our own experiences of project management: where we felt our existing practice fell short of the PRINCE2 principles, or where adopting its practices might help us in future. We had some lively discussions.

My one real criticism of the course is that I didn’t like the format of the pre-learning. It was on-line only, so I couldn’t do it on the train, and annoyingly I had to wait for the voice to read out the words on the slides before being able to move on, which is one of my pet hates. I read a book (PRINCE2 Study Guide, by David Hinde) instead, which I had already bought before the official pre-reading came through, and which suited my learning style better – I recommend this book for anyone looking to study by themselves.

So, was it worth going?

If you want to gain the PRINCE2 as quickly as possible then – Yes. It would help if you have prior project management experience, but it isn’t essential.

If you are a relatively inexperienced Project Manager and are looking to study PRINCE2 from scratch as a way to learn project management, this is probably not the best way to do it.

With the benefit of hindsight I could probably have got away with just taking the exams after reading up, but actually I found the course useful as a refresher on good practice in general. The course’s cramming style suited me personally; it would have taken me a lot longer to cover the same ground in my spare time or one evening a week and I would have been more likely to forget some of the content by the time of the exam. I was very tired by the end of the week though!

Categories: Work Tags: , ,

How we did non-Agile Agile

September 13, 2013 Leave a comment

From time to time there is a debate about Waterfall versus Agile development, and why one is superior to the other. In practice the situation where one or other clearly works best does not always occur in the real world, as I found recently while delivering a major project for a large infrastructure company. A regulatory change meant a new database was needed to accept a feed from a new data source, which resulted in significant changes to their existing billing system to allow it to read the new data.

The situation we started in, ordinarily, would have lent itself perfectly to Agile:

  • At the outset, there was a large set of unknown requirements, but the uncertainty was around the detail – the big picture was clear;
  • the priority of requirements was not known at the outset, and varied over time;
  • the deadline (set by the regulator) was immoveable;
  • we needed something in place early to test with externally sourced data;
  • our team size was about right (8-10 for most of the project duration, although it peaked at 15);
  • the core team had been working together for some time so an established team dynamic already existed.

But certain other factors ruled Agile out:

  • lack of business user availability to work alongside the development team;
  • a mandatory client waterfall methodology had to be followed, heavy in documentation;
  • the client was genuinely scared of Agile, and it was officially out of the question. (The client had previously had its fingers burnt by an Agile project that had spent millions and delivered nothing).

As the programme manager put it, we couldn’t do waterfall because we would deliver a year late, and we couldn’t do Agile because it was forbidden.

So what do you do when you can’t use either approach?

We adopted a hybrid approach to gain some of the benefits of agile while remaining within the Waterfall constraints set by the client. Basically, we made it as agile as we could get away with while seeming (to the outside) to be following the approved methodology.

The client process defined certain deliverable documents at key points, before we could proceed to the next stage. The most critical ones were a requirements specification and a design document.

We were able to produce an adequate requirements specification as the high-level requirements were known, even though many of the key business rules were flagged as still being subject to agreement. It helped that many of the requirements were already met by the existing system, making the requirements appear more complete than they really were.

It then became a straightforward task to produce a high-level design document showing how all the requirements were going to be met, defining interfaces etc. Much of this design work would have been needed up front, even on a pure Agile project. It was clearly understood that the requirements (and therefore the design) would change during the course of development, so we would not have any difficulty presenting a substantially different final design document at project close if that turned out to be necessary.

Once the design was signed off, we adopted a different approach to the development phase. A series of short iterative waterfall cycles covered all stages from development to system test. A relentless focus on priorities ensured all essential functionality required from day 1 was completed first. We developed something as quickly as possible that worked, crudely at first, then adding more functionality with each iteration but allowing scope to vary as priorities changed. I will cover how we planned our development iterations in a further post. Finally as we approached the initial planned production release date, we reverted to a more recognisable waterfall cycle for final FAT and UAT.

We then planned further cycles after the deadline to deliver less critical functionality followed in subsequent deliveries every few months, following the same approach taking the next most urgent set of requirements in priority order. Not quite Waterfall, certainly not Agile – how about Nimble?

Categories: Work

The intervention of real life

September 11, 2013 Comments off

A year has passed since my last post.

This was not intentional, but was a reflection of an extremely busy period at work combined with family problems which together used up all my spare time. Both have now come to an end and I have some material in preparation.

Categories: Personal

East of Bloomsbury, Part 5: Regent and Argyle Squares

August 23, 2012 Leave a comment

This is the fifth part of a walking tour following a Pevsner Perambulation in part of Bloomsbury, London; the previous part is here. See the introduction for fuller details; page references are to the Pevsner Buildings of England series volume London 4: North.


Regent Square

Regent Square

We start at Regent Square, entering the gardens in the centre.
The large terrace on the south side (Nos 1-17) is the only one remaining from the original development of the square in around 1829. The last three to the left are set slightly forward and are all that remains of the original houses in Sidmouth St (Nos 51-55).

51-55 Sidmouth St

51-55 Sidmouth St


United Reformed Church, Regent Sq

United Reformed Church, Regent Sq

To the right is the United Reformed Church (originally Presbyterian), which now goes by the trendy name of Lumen. The complex occupies the corner with Wakefield Street. This is a outwardly plain brick modern building of 1965 replacing its bomb-damaged Victorian Gothic predecessor; judging from pictures this was a major wartime loss.


Regent Square, NW corner

Regent Square, NW corner

Turning around to view the opposite (north) side of the square we see postwar redevelopment. To the left and in front of us are former LCC flats of c. 1958, and at the right hand end is the more modern St Peter’s Court. As its name suggests it replaced a redundant church of the same name (originally by the Inwoods of 1820s, with Greek portico similar in style to St Pancras by the same builders and damaged during the war). Notices in the square give an account of some of its history and residents.

Regent Square, NE corner

Regent Square, NE corner


Holy Cross church

Holy Cross church, Cromer St

We leave Regent Square by the NW corner between the LCC flats which brings us through to Cromer Street beside Holy Cross church. This brick towerless building was built in the Early English style in 1887 by Joseph Peacock (see p255) and is hard to photograph in summer! I have never found it open except for services.


Cromer Street, White Heather House

Cromer Street, White Heather House

We turn right on Cromer Street and go along as far as necessary to look at the flats on both sides of the road, which show the development of council housing from the thirties to the fifties. The first few blocks on the left hand (North) side are early St Pancras Borough Council housing dating from either side of the war, White Heather House serving as an example. By contrast the right hand side consists of nine blocks of flats placed at right angles to the street built 1949-51 and refurbished 1996 so they look newer than they are. Four more are on the north side.

Cromer Street, S side

Cromer Street, South side


Tankerton Street

Tankerton Street

We now retrace our steps along Cromer Street to look at some earlier public housing erected by the East End Dwellings Company. The streets on the right are each filled by single developments of flats which although cramped must have been a vast improvement on what they replaced. Tankerton Street, of 1893, is an example (2nd street on the Right).


Tonbridge House, Tonbridge Street

Tonbridge House, Tonbridge Street

We continue to Tonbridge St (opposite Holy Cross church) which we turn into. Tonbridge House on the left hand side is slightly newer (1904) and more spacious, having been built by the LCC. The original sign remains.

Tonbridge House sign

Sign on Tonbridge House, Tonbridge Street


Argyle School

Argyle School, Tonbridge Street

Continuing along Tonbridge Street, Argyle School (see p.263) a little further along on the right hand side, a good example of a Board school slightly hidden from the road by a brick wall.


Argyle Street

Argyle Street

We turn right just before the school and cut through the alleyway into Argyle Street. This is the most complete of a block of a few streets centred around Argyle Square developed in the 1820s, in this case from 1826.

We continue straight on in Argyle Square itself on the left, which has terraces on three sides (many of them now hotels) and a small garden and a basketball court in the centre. This was developed slightly later than the surrounding streets, in the 1840s.

Argyle Square

Argyle Square


Crestfield Street

Crestfield Street

The other streets are more mixed, with original terraces interspersed with newer infill. Crestfield Street and Birkenhead Street both date from 1826 extend the long sides of the square the north (the left as we approach) and St Chad’s Street (from 1827 onwards), forms the continuation of the north side.

Birkenhead Street

Birkenhead Street


St Chad's Street

St Chad’s Street

We continue along St Chad’s Street to the main road at the end, which is Gray’s Inn Road and where the next section of the tour continues.

A further post will continue the tour.

Thoughts from the beach

June 7, 2012 Leave a comment

I recently returned from a break of over two weeks off work, which included a 10 day holiday in Barbados. This came at the right time, following a very intense period on my current project which has been full-on since Christmas. I returned to work refreshed, and relieved to find my deputy summarising events by saying “you’ll find a lot of emails about a lot of things, but basically, the last one says, ‘Thanks.'” Naturally as I return my break has given me some fresh perspective and a few observations.

Time to switch off is important; I didn’t realise how stressed I was until I discovered how relaxed I had become. I think it’s important with a stressful job to have a two-week break because it always takes me a couple of days to forget about work including all the things I forgot to do before I left. Then two or three days before going back to work I start to think about it again. By taking over two weeks it meant I forgot about work altogether for at least ten days – a break of just a week means I hardly turn off. I’m sure I’m not alone in being like this (I know others who say the same). On this occasion, immediately before going away we attended a big social event, which really helped to get work out of my system straight away and I started my holiday proper with a clear mind.

As the holiday drew to an end, and on the overnight flight (I can never sleep on planes), my thoughts naturally started to return to the work facing me on my return. When I’m in the middle of the daily routine I normally find I’m so busy dealing with all the immediate tasks in hand that I never have the chance to look beyond the immediate to the longer term. Too often urgent tasks crowd out the important but less important. I don’t spend enough time thinking strategically – what do I need to do now to make things better in 3-6 months? Never mind anything longer term than that. Being away from work allowed me to think about these things, and act on my return to bring some of it about before the moment was lost.

The other thing a period of leave gives me is a chance to reassess my own work. Again, this doesn’t happen enough at work because I’m too busy. Some things I need to do personally – push back more with some of the random requests I get from management. Also I need to offload some more tasks to others as I’m just too busy in general. Luckily I can do that at the moment as I have some capable people who can take some of these things on – which isn’t always the case.

A couple of side notes: firstly I couldn’t believe how many people took laptops on holiday – it’s the last thing I want!

Secondly I noticed that the waiting staff at the hotel restaurant addressed their manager as “Sir”. At the team meeting following my return I suggested this might be something we should consider copying, but the rest of my team were of a different opinion!

Some other views:

The Case for Vacations – Emily Pines, The Energy Project

The Importance of Vacations, for Stress Relief, Productivity and Health – Elizabeth Scott

The Importance of Taking a Vacation – Mary Abbajay

Take Vacation The Journey, April 2011