Search This Blog

30 November 2009

Brittle code and brittle organisations.

Brittle code
The idea of brittle code is that as compromises are made due to competence or deadlines shortcuts and workarounds gradually build up. This leaves you with code debt, which is a sort of maintenance debt.

You’ll have to deal with the cost of fixing these shortcomings one day, but because the project’s delivery date is important, or because the skills of the team are what they are, the issue can’t be dealt with perfectly today.

When you think about it – no enterprise system should go live without some tech debt. In the commercial world there should always be some compromise between time, scope and quality. That’s planned or thought through and accepted technical debt. And it should be known and it’s potential cost understood.

Brittleness is not the same a technical debt. Brittleness is the cost of change, and is a subset of technical debt. It’s a result of poor planning or lack of skill.

Brittleness is manifested in the scenario where each time you fix something, something else breaks. The programmer refrain is ‘cohesion and coupling’ which is a nice jargony way of saying you want to make the parts as independent as possible without spending too much time building them. It manifests as cost today versus cost tomorrow.

Brittle organisations
Organisations are also complex entities. Again, compromises are made to deal with today’s local issues over a holistic approach to organisational design. Projects teams deal with organisational complexity as much as, and in many similar ways to the way software teams deal with code complexity.

The CMMi model is one way to tackle this problem. There are other ways also, including implementing agile project practices. An agile implementation appears to have a ripple effect much like the scenario where you clean a patch on a dirty floor.

“Oh no, the rest of the floor looks dirty, we’ll have to clean the whole thing.”

Agile practices and CMMi are not the only ways to address these issues. Common sense and pragmatism go a long way also.

The point I am trying to get to is that you, as a project leader, need to understand these dynamics. Are you implementing a solution with hidden organisational debt? Are you aware of the longer term consequences of your decisions? Have your optimisations been local or holistic? Are you conscious of the costs and benefits of the changes you are implementing beyond your project’s stated goals?

And are you sharing that knowledge with your customers?

27 November 2009

I hate 90% done

Always have.

I learned to hate it when I use to see people report their work was 90% done for weeks (even months) in a row, but I knew they were really wasting time on unimportant or at least less important things.

I have always had a streak of protestant in me that means I want to see value deliverred, religiously, to my clients.

So how can you avoid he 90% done syndrome?
  1. Make sure your deliverables are clearly understood
  2. Understand the tasks in front of the delievrable
  3. Make sure the required resources are all lined up and ready to go ahead of time
  4. Understand what done means to you and your client/boss/team
  5. Make sure the deliverable is scaled to the time period you are working to
If all else fails, report 80% done :)

(You might like this story of a 90% done project.)

Photo by Christopher Chan shared via CC at Flickr

26 November 2009

Social media, Twitter, Facebook and so on

"Surfing the net at work for pleasure actually increases our concentration levels and helps make a more productive workforce, according to a new University of Melbourne study."

See the original article here, and an HBR elaboration on why social media is good for your work productivity here.

I have stated that I don't think social media helps people do their job.  Earlier this year I was at a dinner with Matthew Hodgson where he told the table about how social media users were more productive at work.  I didn't believe him and argued against it (not particularly well, mind you.)

One of my contradictions is the fact that I publish this blog and am thus a user of social media.  And I read other blogs and correspond with other project people online.  I believe it has increased my knowledge substantially.

I suppose I did not count this channel (or mail groups, or online discussion forums) as social media.  After all they have been around for a few years now and are fairly mainstream tools.

However, Twitter, Facebook and the other newspapaer headline grabbers have me wondering about value.  I've used both Twitter and Facebook but see them more as channels that I can't keep up with, an maybe more relevant to non-professional interactions.  Too much volume, not enough content, too hard to keep with.

In order to keep up I need to defer other work tasks.

Of course better tools would help, but I work in a conservative corporate environment where tools are generally locked down (and several social media channels are locked out.)  So I am unable to test some of the more advanced social media tools.  I am also busy and will find it hard to learn new tools and practices in my almost non-existant spare time.

This Melbourne University article does make me pause and reflect on my biases though.  Maybe I do need to change.

And of course I do use social media, and it has helped me get better at my job.

25 November 2009

What to do about the resisters to change?

Here's an idea that was suggested to me today; People who resist change will still change.  They just change slower than others.


The idea is that resisters are really trying to hold the status quo.  If your early adopters and the middle packs move on to the new way of thinking and doing business the status quo eventually changes.

After a while your change resisters have adopted the new status quo.

Of course by this time, you are invested into the next (or the subsequent) change initiative.

The picture above respresents this idea and is from an article on feedback loops, which is retelling a story from the 70's.  Check it out.

22 November 2009

Fowler’s tech debt quadrants.

Mr Fowler refelcts on tch debt and comes up with a four quadrant moel to eaborate his thinking.

The two dimensions are prudence and intent. Which means is it based on good judgement, and did you mean to do it. The four quadrents are thus;
  • Q1 Reckless and intentional - maybe appropriate for short term band-aids that need to be implemented yesterday, or possibly your last day at work (but not on my team!)
  • Q2 - Reckless and unintentional - where a lack of skills is quietly (or not so quietly) creeping up on the developers.
  • Prudent and delibeate – decisive decisions to defer a best practice implementation in favour of a shorter term win – such as a release date.
  • Prudent and inadvertent – the situation when you look back after a project and see a better way to have done things.
What does this model give us for management and planning decisions on projects? It's a way of describing why things take time and why not just any team can be assigned to a software project.  You need the right mix of skills, both in design and execution.

In some ways this model reminds me of the Johari Window from the 1950's.

The difference here is the Johari window's perspectve is based on the perceptions of others.

Planning versus Experience

Here is a thought; Suppose the more experience you have with a particular knowledge domain, the less you need to plan the work?

I picked this planning versus experience concept up from a Jim Coplien piece on InfoQ a few months ago. The idea was basically this; If you have 20 years experience doing roughly the same work you should acknowledge that the 20 years means you have a lot of your plan pre thought through before you even turn up.

In the piece I was watching (it was a video) the argument was being used to discuss the degreeof planning for "Agile" projects.  How much is too much planning and how much is not enough? The answer lies in the experience of the team.
  • Have they worked in this domain before?
  • Have they worked together before?
  • How much and how well?
  • etc
So if I follow this logic I start to see that highly experienced teams and people need to spend less time on planning.  In fact, if the are investing months into pre-project planning they are perhaps wasting money.

At the inexperienced end of the spectrum the idea is almost reversed, but not quite.  Yes you do need to spend more time planning, but not too much because, frankly, your inexperience means you'll make heaps of planning errors.  Instead go for short milestones and correct along the way.  Of course an inexperienced team does need to plan, and one of the things it should plan to do is get mentoring or coaching from someone with the appropriate knowledge and skills.

And in the middle of the experience spectrum the trap is analysis paralysis where the knowledge planning brings keeps teasing you to go just a little bit further.  In this space you'd be better off starting with a clear focus on the next deliverable and reviewing the plan as you go.


19 November 2009

The Scrum Team and old roles

As you know, in the scrum world there are only three roles; Product Owner, Scrum Master and Team. From observing the conversation on the internet, discussions with colleagues and observation, many teams also find a place for testers and QA people.

Business analysts seem to fall outside of the “team” into proxy Product Owner roles, or into Product Owner assistants. System analysts seem to be migrated into the team as QA or dogs bodies.

Project managers appear become product owners, team coaches or shields from organizational politics.

There are two things in this context I am reflecting on right now: My role and its changing nature, and the flat structure and generalist nature of the team.

My role began as traditional project manager, shifted gear to be about shielding the team from organizational politics (aka remove impediments) then to coaching on team processes and practices (No we can’t abandon the sprint retrospective!) and now is sliding towards requirements management.

This shift seems to be one that others have trodden before. What’s interesting is that it brings me back to where I would naturally play as a project manager; let the team do their development thing and focus on managing requirements (and the stakeholders who advocate them.)

Scrum and Mike Cohn’s planning and estimating techniques give some improved practices around team management and reporting, but I suspect that the benefit is in the order of continuous improvement rather than step change productivity.

Where I have seen the biggest improvement to team performance is in requirements management.

Firstly I love the simple elegance of prioritizing requirements with a ranked list. I can’t think of a better way of sorting and prioritizing requirements. And if you have several products in development at once (i.e. a system of systems) then your solution is a bunch of ranked lists of requirements (WBS/PBS anyone?)

Secondly, permission to release a less than optimized solution goes a long way to getting the requirements/scope problem wrangled. When you shift people’s ideas away from the best potential solution to the best path to that solution, things get done better and faster.

The other thing that is on my mind is the egalitarian ideal of the scrum team.

Here is the problem: Despite all the online noise, we are still at the pointy end of a change in the way we do business. And most people are still getting paid according to their old specializations. The HR department is potentially years behind this shift in the way we do business.

Take a look at the spread of pay for project roles here in Australia. It’s not even, and there are some solid differences between outliers.

Take for example the $76k a test analyst may be getting paid compared to the $91k a systems analyst may be paid for essentially the same work.

I know the answer; take it to HR and manage it as an impediment, but it sits in a pile of other organizational impediments and, because the team members are committed and motivated, the py imbalance tends not to stay on the top of the list.

It’s a bit of a problem, don’t you think?

Picture by to ang, with love , CC @ Flickr.

18 November 2009

Managing Project Cost

At "AskAboutProjects" a user asked whether it's still Project Management when you aren't managing the budget. Mainly he answers floated around the point taht yes, it is. A few examples were mentioned inlcuding projects with a flat resource profile.

Here's the thing; Just because there isn;t anything to do on the budgets doesn;t mean that you are not managing cost. If your team burn through $20k per month, you have a pretty direct influence on the budget by the way you manage the project.

Will it go for 6 months or two years?

Of course cost is one half of the value equation, but it isn't as simple as a financial estimate or report.

17 November 2009

No matter how it might look, people are trying to be helpful to the best of their ability.

"No matter how it might look, people are trying to be helpful to the best of their ability."

Brett Schubert writes a great post based on his experience as a customer of an agile team.  It's not all flowers and early releases.

16 November 2009

Quote: "The grim frivolity of unnecessary precision"

Quote: "The grim frivolity of unnecessary precision"

What a great phrase!

Find out what it means here.

12 November 2009

FIST Values

Dan Ward wrote a thesis on values and how they contribute to project success.  His thesis is that success is correlated with a set of values he tags with the acronym F.I.S.T: Fast, Inexpensive, Simple and Tiny.

Dan works in defense where many projects span decades and yeild little value for taxpayers (beyond jobs in regional areas, maybe.)  His work argues against an embedded bias towards expensive, large complex projects with massive scope.

(You can read his thesis yourself, here.)

Ask yourself this: If you were your project's sponsor and you were given a choice across these values, which options would you chose?

Near enough really is good enough!

"What if 'near enough is good enough' really is true! What if it's not an attitude of laziness, but a discerning and intelligent response to a world of spin and over-production."


And an article to to with it; The good enough revolution (At Wired.)

10 November 2009

Getting to Productive meetings

This topic is perennial... Here are some opinions.  Mr Google has 50 million others.

Meetings fulfil two purposes; solving problems and gaining consensus. When you hold a meeting pick and focus on one of these purposes only.
  • Stand up
  • Start on time
  • Book only the time you’ll need
  • Know how it’s going to end
  • Send an agenda and stick to it
  • Tell everyone what preparation is required
  • Write down what is agreed and share it out afterwards

Stand up
When you stand up you get multiple benefits. They include;
  • People standing up think better that people who are sitting still. Being active helps the brain function. Standing beats sitting. Move around if you can, also.
  • Standing also increases interaction. People get up and write on whiteboards, and are more likely to talk to each other rather than exclusively to a facilitator, thus building a better flow of communication.
  • Lastly, if you stand up in meetings, when you are done, you will walk out. How often have you been in meetings when the content is over but people sit there through to the end of the hour?

Start on time
  • I am almost always late for meetings. On the other hand I am almost always an optional attendee without a need to actually be there.
  • Respect the people who care enough to turn up on time and start on time. This will set up a feedback loop that causes people who want their stake to be considered at a meeting to be there.
  • This isn’t a black and white issue as culture plays a part in time orientation. For example in some companies you stay with the person you are with until they are happy with the outcome of the meeting. But it pretty much looks like a time boxed approach to problems (and meetings) is the best way to go, so maybe give up your bad habits in favour of being on time.

Book only the time you’ll need
  • If you have one question and need to bring five people together to get consensus, how long do you think you’ll need? If it can be done in 15 minutes, book 15 minutes. If t will take 3 hours, book 3 hours. 
  • Don’t book an hour by default. This way lies the path of waste and days of back to back meetings.

Know how it’s going to end
  • I constantly come back to the refrain “Start with the end in mind.” In this context there are many different ends that a meeting can come to.
    • If this is a “decision meeting” you can forecast what the end will be by briefing or polling people prior to the meeting. 
    • If it is a “problem solving meeting” you should have an idea of what the likely outcomes will be via investigation and pre-meeting discussions.
  • I tend to publish a statement of the “Expected outcomes” when I book a meeting. That way everyone knows what I am thinking in advance and has the opportunity to explore my suggestion or other ideas.
Send an agenda and stick to it - mostly

  • Agendas do change and that’s okay, but know the purpose of the meeting and control its scope.
  • You work on projects, right? So you know about the scope control problem. As we have discussed earlier, one of the best ways to manage the scope is by time-boxing the meeting.
A military officer who was about to retire once said: ‘The most important thing I did in my career was to teach young leaders that whenever they saw a threat, their first job was to determine the timebox for their response. Their second job was to hold off making a decision until the end of the timebox, so that they could make it based on the best possible data.’ – Mary Poppendick
  • Use a parking lot for off topic conversations and address them at the end of the meeting if there is time, or let people take their issues with them to follow up in their own time.

Tell everyone what preparation is required and let everyone know the agenda
  • Explaining to people what preparation is required helps get people ready for the meeting, 
  • But you’ll have to remember that several people won’t have time to do their homework. Be ready to give them a 2 minute prĂ©cis of any background issues at the meeting.
  • And for the millionth time, the agenda should be prioritised by importance. Let the unimportant things fall of the back of the meeting. Try to timebox the agenda items also.

Write down what is agreed and share it out afterwards, on the same day.
  • I remembered something different to you and we need to identify this problem as soon as possible. That means you need to send out notes on the meeting the same day.
  • Same day = same day. While people’s minds are still close to the topic.
  • Be specific about what was agreed, including deadlines for actions. If deadlines were not defined in the meeting give people 3 days.  If these things are important to you, follow them up with a call or personal message.
  • And do me a favour. PLEASE don’t attach a word doc to an email. Include your notes in the email body or hyperlink to it.

There are a billion web articles on how to run an effective meeting. This has been once of them.

Picture by ►Voj► CC via Flickr

9 November 2009



The Hitler Windows 7 Launch IS funny.

But not as funny as this!


Windows 7?

Like, whatever dudes.  But if your OS really matters to you, try this for size:

"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it."
And while we are at it; Hitler gets Windows 7

5 November 2009


This Friday is a busy day for me. In the meantime, take a look at this.

4 November 2009

Contracting versus Full time

Alister Scott provides a simple little calcultion showing comparable full time and contract rates.  He compares an $80kpa full timer to a $60ph contractor and finds they earn about the same.

If you are interested in exploring contracting this explanation may help you understand that the benefits of contracting are not all financial, and that the differences in what contractors get paid is not as large as some people assume.

What _do_ we need from our professional organisations?

Matt Hodgson worries about about the BA community repeating the mistakes of the project management community by taking a narrow definition of the role and formalising it.  Embedding itself in a position from which it will be challenged to evolve.

His questions wrap around the ideas of community, discipline and roles.

If you are interested in the ongoing formalisation of the BA (and PM) roles and are wondering/worried about the directions they are headed, read his post and offer your comments.

3 November 2009

Capability is as important as Customer

There’s a lot of talk about outside in thinking and design , and about transformation driven by customer problems. And this talk tends to disparage the approach of “look[ing] around at their capabilities and try[ing] to figure out how to fit them onto the market.”

This strikes me as the pendulum swinging too far the other way.

Yes, a sales driven approach to doing business is insufficient. But no, exclusively adopting a customer centric approach to business growth is equally silly.

Back in Marketing for Projects 101 we talked about marketing being a process of creating value for both the producer and the customer. Think about a simple, two circle Venn Diagram with the circles overlapping.

A market driven approach means building value for both the organisation and the customer. And this means that you need to understand both your customer’s needs and problems, and your own capabilities.

A simple example highlighting the capabilities point is Amazon.

  • Book publisher? Yep.
  • Cloud service provider? Yep.
Did you see that second one coming a few years back?

If Amazon had just focused on their customers (let’s say book buyers) how would they have spotted the great cloud utility opportunity in front of them?

The same goes for project teams and sponsoring organisations. Understand your customer’s needs and problems, but also understand the team and sponsoring organisation’s capabilities.

Know yourself.

Photo shared via cc at Flickr by  sylvar

1 November 2009

The MBA Oath

You may have heard of a Harvard University initiative to get MBAs to sign up to an oath on responsible value creation.  I found it via Mike Clayton's blog.

Here it is;


As a manager, my purpose is to serve the greater good by bringing people and resources together to create value that no single individual can create alone. Therefore I will seek a course that enhances the value my enterprise can create for society over the long term. I recognize my decisions can have far-reaching consequences that affect the well-being of individuals inside and outside my enterprise, today and in the future. As I reconcile the interests of different constituencies, I will face choices that are not easy for me and others.

Therefore I promise:

I will act with utmost integrity and pursue my work in an ethical manner.

I will safeguard the interests of my shareholders, co-workers, customers and the society in which we operate.

I will manage my enterprise in good faith, guarding against decisions and behavior that advance my own narrow ambitions but harm the enterprise and the societies it serves.

I will understand and uphold, both in letter and in spirit, the laws and contracts governing my own conduct and that of my enterprise.

I will take responsibility for my actions, and I will represent the performance and risks of my enterprise accurately and honestly.

I will develop both myself and other managers under my supervision so that the profession continues to grow and contribute to the well-being of society.

I will strive to create sustainable economic, social, and environmental prosperity worldwide.

I will be accountable to my peers and they will be accountable to me for living by this oath.

This oath I make freely, and upon my honor.

So, what do you think?

I think it's a nice initiative, but you shouldn't be betting your house on a shift in ethical behaviour by the people who sign on.

As a sceptic, I presume this initiative is more PR than anything else.

On the one hand, this voluntary oath is likely to attract people who are going to act relatively ethically anyway.  On the other hand, how's the hippocratic oath doing these days?  Is it working for you?

On the third hand it does make people at least think about the issues they are going to face when dealing with real business challenges.  And we do know that mentally rehersing something can at least partialy prepare you for the real deal of ethical dilemmas.

Back to Mike Clayton.  He's made a call out for project managers to draft their own oahs and publically call them out. I'm pretty comfortable with my values and so I think I'll stand by my actions rather than sign on to a list.

But what about you?

I am particulary interested in hearing how you'd prioritise conflicts between "shareholders, co-workers, customers and the society in which we operate."

Who wins in a tussle between shareholders, customers anc the community?