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
Author Archives: Steven Thomas
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
Glossary definition for “Agile”
I was asked by a corporate Programme Management Office (PMO) to provide a glossary definition for “Agile”. This is the definition I gave them.
Continue reading
Using a Product Led Matrix in Lean-Agile
I’ve worked in a variety of organisational settings including matrixed and non-matrixed. Based on this experience I thought I’d write up a few observations about organisational structures.
Traditionally companies have been organised into functional teams. More recently, partly as a result of Scrum and Lean for Software Engineering, companies are moving to departments containing cross functional product teams. Some organisations have a mix, for example, design might be a functional department but other departments might contain product teams. Other companies try to combine function and product into a explicit matrix structure. This ensures both product and function are represented on the management team.
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
Two Pillars of the Lean Thinking House
The Toyota approach to lean is quite sophisticated and is based on a model called the Lean Thinking House (Larman & Vodde, 2009). The Toyota model includes two pillars:
- Respect for People
- Continuous Improvement
These pillars struck a cord with me. I’m normally more interested in what practices work than in values and principles however these two phrases seemed to nicely summarise my approach to work and are key themes in my career.
References
Larman, C., and Vodde, B. (2009). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley.
Difference between programme, project, portfolio and product management
P3M stands for "programme, portfolio and project management". Product management is a closely related discipline and as most software organisations do product development I’ll include it in the discussion.
P3M Levels:
programme, project, portfolio
and product management
That bit is simple. The tricky bit is agreeing what a project, product, portfolio or programme is. Projects and products are pretty straight forward but definitions vary quite a lot for programme and portfolio. A portfolio for some people is a set of products where for others it is a group of projects. I have, for example, met a portfolio manager who was responsible for some projects and within the same division met a another portfolio manager who was responsible for the product portfolio of the entire division. Programmes are sometimes seen as simply as a complex project or set of projects, or, more interestingly, as an initiative to deliver business benefit.
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
Agile Quality Management
Quality Management, in a project context, is concerned with having the right processes to ensure both quality product and a quality project. This article describes Traditional Quality Management, Agile versus Traditional Quality Management, Agile Product Quality, Agile Project Quality, Agile Product Quality, Agile Quality Assurance and Control, and Agile Quality Improvement.
Continue reading
Agile Project Estimating
Estimates are an essential part of Agile Project Planning. Software estimation has always been problematic and people have proposed many different ways to do estimating. Different methods are on a spectrum from formal to informal and from supposedly objective to seemingly subjective. Different methods also get individuals estimate or groups. And some methods estimate size and derive effort while others estimate effort directly. Estimating in the Agile world has settled a certain approach which might be characterised as expert group estimation of size. this article covers Traditional Project Estimation, Agile versus Traditional Estimating, Estimating User Stories, Estimating Tasks, Contingency, and Agile Ballpark Estimates.
Continue reading