Today a new project manager, somebody running one of my work streams, asked to put her risks on my programme risk and issues log. She didn’t really want to but apparently she’d been told to do this by her organisational masters outside the programme. I told her not to. Why? Because I use the log for the programme not the sub-projects. Since I had to explain my thinking to people in the company I thought it warranted a blog entry.
Continue reading
Category Archives: Experience
Build it in a Week
I ran a massed prototyping exercise with my current team. The whole team: development, user experience and design, testing, product management, business analysis, programme/project management and the programme director. It was a concerted effort to get a solution covering everything. The idea was to build wide not deep. The requirements for the end to end workflow was a generic operating model we’d developed previously. Microsoft Sharepoint was the underlying platform so this exercise concentrated on “out-of-the-box” solutions based on Sharepoint.
Expected Benefits
I allocated a week for this so the cost was quite high. On the other hand I expected considerable benefits. I expected “Build it in a Week” to enable us to:
- understand the requirements more
- validate the generic operating model
- validate the emerging information architecture
- identify technical challenges and identify if “tricky” things were in fact simple
- demo an end to end solution (even if clunky and with caveats)
- understand Sharepoint 2010 more, specifically understand what “out-of-the-box” means in 2010
- identify what we can’t do “out-of-the-box” right now
- understand each other more
As programme manager I thought it worth the cost.
Continue reading
Minimum Releasable Feature
There are a variety of terms in use for chunks of functionality that are worth releasing and the requirements that describe them. Desirable characteristics for these features include being minimum, releasable, and valuable. At the moment I am using the phrase Minimum Releasable Feature (MRF) so I thought I’d explain why and some of the alternatives.
Continue reading
Scale and Performance Suggestions for High Usage Websites
I work at the BBC and scale and performance is a big deal. After talking to Mark Gledhill (one of the Senior Software Engineers) and Andy Macinnes (head of ops) I put together some notes on scale and performance. It isn’t rocket science; just good common sense.
The general message is to avoid unnecessary repetition. If you’re a scalability/performance problem then you could explore …
Continue reading
One Page Agile Standard for team of 350
For the last two years I have been rolling out a standard Agile approach to a department of 350. One part of the roll out strategy was to have a published standard. This was to make the goal / end-game obvious even if we didn’t initially mandate everything.
The first version of the standard, published Oct 2006, was a 50 page document. Earlier drafts had been quite short but in reviewing the document people kept asking “What does that mean?” so we’d add another section explaining it. All rather worthy but, aside from the initial reviews before publication, nobody read it. And it diluted the document as a standard, defining what must be done, as opposed to a guideline about how to do it.
We published version 2 today. This version of the standard is one page. I want to give people a simple checklist so they know whether or not they are following the standard.
Continue reading