Better Projects

The Scrum Team and old roles

2009-11-19T07:00:00.000+11:00

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.

Managing Project Cost

2009-11-18T08:00:00.000+11:00

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.

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

2009-11-17T17:40:00.000+11:00

"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.

Quote: "The grim frivolity of unnecessary precision"

2009-11-16T17:09:00.001+11:00

Quote: "The grim frivolity of unnecessary precision"

What a great phrase!

Find out what it means here.

FIST Values

2009-11-12T07:00:00.001+11:00

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!

2009-11-12T00:19:00.000+11:00

"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."

(podcast)

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

Getting to Productive meetings

2009-11-10T09:00:00.008+11:00

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

Pfffftsssshsstt!

2009-11-09T21:54:00.002+11:00

Okay

The Hitler Windows 7 Launch IS funny.

But not as funny as this!

Seriously!?

Windows 7?

2009-11-09T21:37:00.004+11:00

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

Friday

2009-11-05T23:47:00.000+11:00

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

The Future Of Work

View more documents from Jeff Brenman.

Contracting versus Full time

2009-11-04T09:00:00.002+11:00

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.

Read more here.

What _do_ we need from our professional organisations?

2009-11-04T00:06:00.001+11:00

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.

Capability is as important as Customer

2009-11-03T09:00:00.001+11:00

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

The MBA Oath

2009-11-01T09:00:00.014+11:00

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;

THE MBA OATH

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?

How to organise a Children's Party

2009-10-30T09:00:00.003+11:00

This will probably spread like wildfire in the pm/agile blogging community. May as well get on the bandwagon!

Building agile project management capability

2009-10-29T09:00:00.002+11:00

This prezi is by Matt Hodgson who i have been showcasing here a bit recently. I like his presentatoions. What can I say?

This one does a good job of showing a path to agile practices for conservative and bureacratic organsiations..

Management and leadership

2009-10-28T17:16:00.000+11:00

Do projects need leaders more than managers?

Here is a definition of management

Management is the process of achieving organizational goals through engaging in the four major functions of planning, organizing, leading and controlling (Bartol & Martin, 1998 in Management).

Here is a definition of leadership (in the enterprise context.)

The process of influencing others to achieve organizational goals (Bartol & Martin, 1998).

Are they mutually exclusive things? Can you lead without management? Can you manage people without leadership?

To be an effective leader you need to have some semblance of organisation. You need to be able to plan your work, understand the outcomes you are trying to achieve lead and motivate others on the way and clear impediments out of the way.

In enterprise project management you need to be able to manage stakeholders, and manage people through a project’s processes. You need to be organised to manage the complexity that comes with the territory. If you aren’t organised you won’t get the respect and trust you need to lead people.

To be an effective manager of people, either reports or stakeholders, you need to be able to lead. Leadership is not technical expertise, and it isn’t having a vision for the product. Leadership is engendering trust in your decisions and confidence in your ability to get things done. Leadership is part of management.

Management without leadership is poor management. Leadership without management is movement seeking a purpose.

The thing is that leadership and management aren’t binary attributes. It isn’t as if you either have it or you don’t. Both of these skills grow as you study and practice them. Actively seeking feedback and reflection speeds up that growth.

So, yes there are some people who are way off the mark, but most, even many of us have great potential.

I was listening to part of a Noam Chomsky interview the other day and he said something like ‘…corporations aren’t run by bad people, they are run by smart people optimising bad systems.’

Maybe a lack of forethought and a lack of big picture thinking is the problem. This thinking falls into the management role of planning, doesn’t it?

And if you need to break out of your current system? That takes leadership.

Ethical dillemas for Analysts

2009-10-21T21:47:00.001+11:00

1. Here is a question at BATimes (login required) about what you would do if you felt a project was urposely delivering a product that would;

Be functionally worse that the legacy system it replace, and

Potentuially brach accounting or other regulatory rules.

What would you do? Click through and offer an opinion.

2. Amanda Becker provides three real life ethical dillemas at BNet and asks you to say how you would handle it. You get to compare your results to others, and to what really happenned.

Ethics are harder in practice than in theory and the best ways to arm yourself for tough decicions are to practice your ethics in safe scenarios *such as role plays or surveys) and to know your moral compass.

While we are on the topic, have a look at Caveman's flickr page (The source of this post's picture) where he describes the US Office of Giovernment Ethics (and browse the comments while here.

Managing your Steering Committee

2009-10-20T09:00:00.000+11:00

Tim van Gelder writes a post on how boards use information and make decisions.

Two key pieces of information that I took away from the post are that Boards will share better if they think they are solving some kind of factual issue as opposed to making a judgement requiring consensus.

Boards share information better if they use a structured discussion process, rather than just indulging in the usual kind of spontaneous conversation.

The idea here is that Boards need to be actively engaged in managing things. For me and you it is our project steering committees and governance groups. How do we get them more involved in the project?

By making board members participate in certain decisions they 'own' the solution more than if they just front up and rubber stamp a progress report.

Every report on project success or failure includes mention of close customer engagement as a key success factor. Frontline managers are not the customer. The sponsor and steering committees are much better embodiments of the customer, as they are the ones paying for the product your project is delivering. Getting your board members involved is a step in the right direction.

In order to help boards collaborate more, Tim endorses a McKinsey recommendation to augment proposals and recommendations with a 'red report' or the counter argument to the actual recommendation.

This is a common approach used in project management: the infamous 'three options' including or augmented with the "do nothing" option. Depending on the time and relationship you have with your board/sponsor, and the importance of your project what can you do to get them more involved in your next board (or steering committee) meeting?

Picture by mugley CC@ Flickr

UAT is going well

2009-10-18T17:47:00.000+11:00

iTWire reports a dozen common or critical failure modes for an agile implementation, lifted from Agile Australia 2009. It's interesting to see the angle mainstream IT press in Australia has on this theme.

The last point in the article is one close to my heart. Falling back to traditional appproaches when it all gets too hard. As the agile point man at my current engagement, I definitely know that feeling.

On the other hand, we ran our second round of UAT last week and in both it and the first round we only came across one bug of moderate significance. This is a pretty fantastic result, especially from a team who's previous release didn't even run on day one of UAT, and that's not even considering the huge schedule differences.

It seems a process that enables, rather than tries to force particular agendas can really make a difference. Once the product is more mature we might see if we can turn out a white paper on the topic.

"Never give a fool sterile information, because he cannot ignore it."

2009-10-17T09:01:00.000+11:00

"Never give a fool sterile information, because he cannot ignore it."

So says Nasim Taleb when discussing risk management in the financial industry.

The same can be said about our industry. Think about this paraphrased comment; If we all use the same risk management framework, but we price risk wrong, we are headed for a huge problem.

So, when you are assessing likelihood and impact you are assessing the cost of things going wrong. But are you thinking about the work that is required to manage your risk? Do you update your schedule and budget to acknowledge additional effort required to manage these risks?

There are two things going on here: Being transparent and accountable about the cost of managing risk and building resilience into your project.

Co-location of teams

2009-10-15T13:00:00.000+11:00

Adrian at the Scrum Development message group handed out a list of resources for justifying co-location of teams. It covers international and intra-building co-location.

Your instincts tell you that this model is right. Broader bands of communication help get things done.

People working close to each other over-hear conversations and chip in with their experiences and opinions.

Us and Them divides are conquered.

One space per team...

The list is good. Check it out.

Planning and Patterns

2009-10-13T08:45:00.013+11:00

Planning is one way to anticipate the work you'll need to do. Patterns are another.

Plan for when the work is new, unknown and unique. Patterns are for common problems.

Some patterns and plans are also presented as processes. I'll leave the idea of work as a process to you and the comments below.

If you know the work you'll need to do well and intimately ahead of time, it's a pattern. We find patterns all over the place in project management, especially in strongly process oriented organisations. Here are a few examples;

User acceptance testing pattern; You set up a replica of your production environment, write up test cases around the system capabilities, execute the tests an report on the outcomes. All good? Go live.
COTS Product evaluations pattern; Define your needs, investigate options, compare, select.
Scrum pattern; Plan a sprint, execute, demonstrate the outcomes, reflect. Repeat.

At a higher and lower level a pattern can be surrounded by or embedded with more patterns or with planned work.

Scrum for example is a pattern. The details within the sprint need to be planned (hence it kicks off with a planning session.) Some of those details may also be patterns. For example, in my team the QA process is a pattern within the sprint that is repeated several times.

So, if you know the activities you'll need to do, it's a pattern. Patterns save time and bring consistency.

So, as I said above, that leaves plans for the uncertain, untried and unique work. Something implicit in this statement is that plans have to accomodate uncertainty, and allow for details to emerge as you travel with them into the future.

Plans are important because they help you think ahead though the uncertainty and complexity. Plan's don't have to get you to the right answer every time. Their job is mainly to help you anticipate some of that uncertainty.

Projects, at least the ones I have seen, use both patterns and plans to organise the work.

Both planning and patterns require something to make them work; good judgement.

When should you use a plan and when should you follow a pattern? When do you customise a pattern and when do you populate plans with patterns? You need to think about these things, and that part of the organising process is planning.

Picture by Lachlan Hardy, CC @ Flickr

Tinkering with the site design

2009-10-12T22:45:00.001+11:00

Hi people, If you've clicked through to the site from your RSS or emails, you might have seen me tinkering with the site design. Feel very free to tell me what works and what doesn't.

The A word

2009-10-11T09:00:00.004+11:00

This is a short video introducing the idea of 'agile projects.' Light hearted and entertaining.