Showing posts with label Agile. Show all posts

9 Project Management Commandments to live by

I'm coaching a very successful software company in Auckland on the finer points of Project Management. The 9 commandments that follow represent an accumulation of wisdom that has served me well over the years. Please feel free to share your thoughts on the matter.

Begin with the end in mind

Plan the flight... then fly the plan
Pause for agreement and clarity before implementing
Stay wedded to the outcome, not the path for getting there
The worst time to define success is after it’s over

Manage by result, not activity

An active team is not necessarily a productive team
Focus on Throughput
Limit Work in Progress
Learn to use teams to achieve results... not individuals.

Compromise on scope not quality

Define ‘quality’ upfront (e.g. verification criteria)
Understand technical debt
Learn to recognize an ‘interest’ payment from a ‘capital’ payment. (i.e. treat causes as well as effects)

Escalate early and often (e.g. 2X2X2 Escalation)

2 minutes to explain the issue
2 minutes to describe options
2 minutes to make a decision on what to do next

Continuous Course Correction

Invest in short regular planning exercises.
The act of planning is more valuable than the plan!
Learn to surface impediments/blockers regularly
Planning exercises are for planning the work not doing the work!

Serve your team

Enable your teams with clear decisions, clear priorities and lot’s of encouragement
Double the rate of failure!
Trust your experts

Manage the context

Maintain situational awareness outside of the team
Make yourself aware of ALL the stakeholders
Create an atmosphere that celebrates failure as a learning experience
Communicate little bits of news often!

DWYSYWDWYSYWDI

Credibility is critical to building trust
Do What You Said You Would Do When You Said You Would Do It .

Retire risk early

Tiger cubs are easier to deal with than tigers!
Prioritize first... sequence last.

How can corporations best fight atrophy?

I was listening to a podcast a while back* by Ried Hoffman (who started LinkedIn and Paypal) and something he said got me thinking about corporate atrophy**.

Ried mentioned how easy it was for Paypal to out maneuver the larger banking bodies during the startup phase. They were busy testing the legal definition of a bank with their online offering and the banks were squirming and nearly powerless to respond. In fact some of the banks online counter offerings took in excess of 12 months to deliver... as Ried correctly points out, thats an eon in internet time!

Just how did the banks get to this lethargic state?

And how can they (or any large corporate body for that matter) hope to compete in this rapidly changing business environment.

More to the point, How can corporations best fight this atrophy?

*For Rieds Podcast: http://edcorner.stanford.edu/authorMaterialInfo.html?mid=1650
** Definition of atrophy: http://www.thefreedictionary.com/atrophy

I posted this question in LinkedIn and got quite a few interesting suggestions back:

Mergers & Acquisitions
>>Let others take the big risks and buy them up when they look promising.

Various forms of Internal Entrepreneurialism
>> Google have an interesting internal policy where they allow thier employees to use 20% of their worktime to work on anything they want. They have enjoyed an enormous amount of success from the projects resourced this way.

9 Top Tips for starting an Agile Project

Set-up a planning session with the project sponsor... get them to share the vision... identify the Success Criteria (I.e. the conditions under which the vision will be considered realised)
Use Rob Thomsett's project success sliders to define the degree of flexibility in the different dimensions.
Derive SMART Objectives (Specific, Measurable, Achievable, Realistic and Timely)
Create a Product Breakdown Structure
Turn this into a Product Flow Chart and use this to communicate the project roadmap to both the team and the sponsor.
Use Mike Cohn's planning poker to estimate the relative weighting for each of the main products on the roadmap.
Establish a burndown chart to track 'speed over ground'.
Propose that your project sponsor gives the status reports on the project.
Re-plan the project regularly. Keep checking that the project goal is still the same (i.e. progressive elaboration)

7 SCRUM insights from Jeff Sutherland and Jens Ostergardt

Jeff Sutherland, the inventor of SCRUM and Jens Ostergardt, the 1st SCRUMMASTER, were keynote speakers at the APN in Auckland last night.

Here are a couple of salient points I took from the talk:

Jeff was a fighter pilot in Vietnam (Sydney 1967) and flew over 100 missions! This along with Jeff's subsequent experience in medical sciences seems to form the backdrop to the pre-scrum thinking. Jeff said he came up with a process that is in a constant state of response to impediments.
Jeff appears to be a scientist at heart with an evidence based way of getting his point accross. One of the stats he mentioned was that an average 63% of features change on development projects... I'm still digging for the reference for this... will post it shortly.
When coaching senior management teams Jeff seemd to emphasize the need to "surface impediments". He cited a great example of a Danish company that was level 5 on CMMI with excellent control over processes. This was used as the test bed for determining the productivity differences between SCRUM & Waterfall... needless to say SCRUM kicked ass ;-)
Read the MIT iRobot story. I loved this story as it really brought home the need to establish the learning process with simple rules... The world is the database... simple rules give rise to sophisticated behaviours!!!
Jens gave some valued advice for new ScrumMasters:

Don't get fired,
Resist the urge to 'help' the team
Don't use a SCRUM tool at first! (Help the team find it's feet (low tech) before introducing tools.)

Jeff seems to enjoy applying Root cause analysis for SCRUM issues... Let the data reveal the causes. He gave one of his Polish companies as an example. The company in question had been advised to implement integration testing... this was ignored and later identified as a root cause of the ensuing spate of iteration failures.
Lack of integration testing was identified as a major impediment to getting to DONE!

Hope you enjoyed this installment... If you attended the event too please feel free to add your own take on the talk!

This event was arranged by Edwin Dando from Clarus Consulting in Christchurch. A real win for the New Zealand Agile community I'd say!!

Handling 3rd party vendors on SCRUM projects

A friend of mine recently asked me what the best way was to manage a 3rd party vendor on a SCRUM project. (SCRUM is an Agile Methodology for those of you who don't know)

Here's the advice I gave him:

Get the vendor relationship off to a healthy start:

Make sure there's an open, honest and safe channel for the vendor to communicate with you.
Be as specific as possible with what you require from them. Try and be results focused and not activity focused. Here's a great article by Marc McDonald on the merits of results versus activity management.
Urge vendors to give commitments that you can rely on and not commitments that you may want to hear.
As a rule of thumb question the assumptions behind an estimate and not the estimate itself. This way your vendor is encouraged to use their expertise while protecting their self esteem (improves their perception of safety).
Try and use the language of 'confidence' when considering estimates. For example, "The vendor is very confident in a 5 day delivery" or "The vendor is not very confident in a 5 day delivery due to an issue with XYZ". This way you're less likely to set unrealistic expectations with stakeholders.
Ask your vendors to escalate potential issues early and often... better to handle things early & cheap than late & expensive. (See my previous blog article on this)
Work hard to empower your vendor... especially since their performance has direct impact on your reputation. In other words, your reputation will very likely take a knock if they flounder.
Prioritise the deliverables you're expecting as much as possible. Be clear about Must Haves.
Compromise on Scope not Quality where possible. Don't make them deliver things if it can't be done properly. For example if you're time pressured, negotiate with scope.

Integrating vendor deliverables with your SCRUM project:

Create a user story card for their deliverable and place it in the product backlog.
When the iteration arrives be sure to schedule integration and testing tasks in the sprint backlog to ensure the vendor deliverables are truly DONE by the end of the iteration.
For planning poker, Limit the task estimates to just those your team will need to carry out. I.e. exclude any work your vendor will do as this will distort your view of velocity (... thanks Vasco)
Invite your vendor along to attend the sprint planning meeting for the relevant iteration. A public commitment to the team to meet a deadline is always more powerful than a contract ;-)
Be sure to regularly ask vendors how they are tracking and to confirm their delivery estimates (weekly should be ok).
If there are dependancies on the vendor's work be sure to assess the impact of delays. Communicate the potential impacts to stakeholders early.
The vendor should also attend the sprint review to see how their deliverable has been integrated and to clarify anything should the need arise.
It's also ideal to have your vendors attend the relevant sprint retrospective to get their input.

8 of my favourite Agile RSS Feeds

Thought I would share the list of my favourite RSS feeds on the topic of Agile. They've helped me through some difficult times and continue to be a great resource for guidance and support.

P.s. if you're not familiar with RSS feeds have a look at this tutorial: how-to-getting-started-with-rss

Design upfront or let your architecture emerge?

Our team is looking at rolling out a new technology stack (enterprise wide) called Pega Rules Process Commander (supported by Pega Systems and considered to be top of the Gartner magic quadrant for BPM Suites). This being the beginning of the journey there were a few obvious architectural questions to address. I was particularly concerned about the base class structure knowing from experience that this is the part to get right at the start.

On a mission to get some answers I went along to the annual Pega symposium in Sydney in February. The clear steer I got from the Pega team (including Alan Treffler) was to hold true to an agile philosophy and allow the architecture to emerge. Meaning to build the initial application using as much of the existing generic structure as possible in the first couple of iterations. In the retrospective, determine the gap between where you want the structure to be and where it actually is. Use this knowledge to make conservative specialization decisions for the classes. Essentially this will instill an important re-use enabler discipline within the development team.

This seemed a little counter-intuitive to me especially since the first project was intended to be the first of many rolling this technology out as a core capability for the company. Who knows what the next business problem may look like? The cost of 'getting the class structure wrong at the start seemed far too high to dismiss. Now consider the alternative...

The natural counter approach is to design as much of the class structure upfront (using techniques like detailed business domain modeling)... This smacked heavily of waterfall and seemed to be the safest route... "NO!" I thought "I absolutely won't give in to that kind of fear driven logic!"

Digging a little deeper with some of Pega's other customers and with our sister company in Australia, I started to get a feel for the actual cost of changing our minds about the class structure and it appears this topic is well addressed. However it depends entirely on the development approach your team takes. Pega actively discourages waterfall when using their suite however this doesn't proclude customers getting value out if they're constrained by traditional SDLC views. It just means that the potential for re-use and agility is more likely to remain locked up.

Pega supports alterations to the base class structure and more importantly they actively promote a 'build for change' philosophy for implementers.

In summary, my opinion is that it comes down to a combination of an organization's outlook and risk appetite. If they're a bit more contemporary and understand the dynamics of innovation (i.e. learning frameworks such as SCRUM) then allowing the architecture to emerge is a 'no brainer'. On the other hand if the organization is still struggling with a traditional theory based philosophy (waterfall for example) then 'design upfront' will certainly ease anxiety and get things going.

================= LnkedIn Q & A ==================

I posted this question on LinkedIn and here are a few answers I got back:

From: Paul Williams

Colart,

I think that there's a balance. My most successful projects were front-end designed to a point, then evolved from that. In essence, the core -- backbone, if you will -- of the frameworks were designed cathedral style. The application modules, then, were "evolved", bazzar style.

Occasionally, a requirement of the application would necessitate an adaptation of the framework (or a really useful component would be promoted into the framework), and thus the framework also evolved, but always and only within the spirit of the initial design.

In contrast, the application components were ad-hoc, whatever you please to get the client happy.

From: Olaf Dietzler

I believe that the term "architecture" is actually defining a few basic principles.

- Stability
- Scalability
- Integration and interfaces

The point of having an architect (both for IT and buildings) is to at least provide a framework in which technology can support business changes, both in function and volume without the whole thing coming apart.

An architect doesn't neccessarily need to define up front what colour the walls are going to be or what flooring is beeing put into the building, but he should have provide walls (which can be repainted in different colours) and a level base, so that when the flooring is beeing placed (or replaced) without harming the foundation.

Regards,
Olaf

From: Tony Fairhurst

I find the best approach is to define a business strategy. What are the goals of the business over the next 2,3,4,5 years. Once this had been understood, you can produce a roadmap of how to get there. That doesn't mean you won't deviate from the roadmap, but at least you will know you have and why you have.

The Key for any EA is to build in, Agility, Adaptability, Re-usability into the big picture view. If these principles are adhered to then the evolution of the architecture should be positive.

I suppose on Philosophical perspective you can think of Enterprise Architecture along the same lines as Darwinian Evolution. Put the right building blocks in place upfront, and the entity will have a good chance of survival.

So, design in terms of the core principles and building blocks should take place, however, don't over design as this may constrain you long term, remember, none of us know whats going to happen in the future, and my experience is expect the unexpected!

One of the key issues to consider is the cost of getting it wrong. The higher the cost of having to restructure the whole thing the more effort needs to go into planning up front.
Consider the key message from Agile Development: "build the simplest thing that can do the whole job, and emphasis is on whole' (maybe I don't recollect the exact wording here). Even for something that is considered very evolutionary, the basic architecture needs to be right up front, or you're going to hurt later on.
There is no conceivable reason to discard what is known and make your architecture too simple, or impossible to scale or what ever you know it will have to do.
That said, you can often create your architecture such that it is extremely scalable, but not implement the scaled out version from the start.

To change your architecture (not your implementation details) usually requires a major rewrite of everything. As long as the cost is small enough, do it, but as the project / system grows, the cost of doing this also grows...

What's a great elevator pitch for Agile?

Let's say you got into an elevator with a senior executive and you had 30 seconds to sell Agile to them, what would you say?

B.T.W. This is commonly referred to as an elevator pitch and here's a good intro from Business Week.

Here are some answers I got back from the LinkedIn community:

Carolyn Sanders wrote:

"I actually do get asked this one by execs. This is what I usually say: Agile delivery is about two things: you usually don't know what you want until you see something, so deliver something real as early as you can; and if you're going to fail, fail fast. Agile in general is about being fundamentally honest with each other, about money, about technical delivery and quality, about requirements andtime - that's why it's so scary for some people."

Matt Richards wrote:

"Agile software development practices will give you more control over the cost and feature set of your software than traditional methods. You are also likely to have usable software sooner."

PJ Srivastava wrote:

"Are you at all worried that your project might go over-budget, that it might run behind schedule, that the customer might not like the end result, or that someone will change the project requirements on you in the middle of it? That's where Agile comes in. Its as simple as this: the more complex, the more challenging, and the more uncertain your project, the more you have to inspect it frequently and the better you have to control your process to be successful with it. Agile is simply a more intense, but tried-and-true process for reducing risk and better controlling your results. Give me 10 minutes of your time and I'll explain why some of the most recognized companies in the world are turning to Agile..."

Plan to succeed on projects (Part 2)

Now that you've planned the flight... Fly the plan.

If you've taken the advice given in Part 1 you should be set up to drive your projects by result rather than activity... you'll find your team responds best to this approach...

I posed a question on LinkedIn recently to see what advice the professionals would give a budding PM:

"What are the top 5 tips you would give a PM to improve their luck on projects?"

I chose a couple of these answers as they sum up the basic principles of flying the plan nicely:

Here's the answer offered by Gianluca Bacca:

1) Define the scope of you project as clear and as soon as possible and formalize it … a project doesn’t exists without a Project Charter and a WBS!

2) Be realistic and pragmatic, don’t forget that generally available resources are limited … a request or change coming from a stakeholder, generally, involves a trade-off between different elements of the “triple constraint” (time, cost & quality) … think always in terms of trade off between the elements of the “triple constraint”.

3) Manage ALL your stakeholders with care being proactive: to do this you need to identify ALL of them and constantly communicate with ALL of them

4) Identify all risk of your project and constantly looking for their evolution along the entire lifecycle of your project … don’t forget risk! In Project Management luck and bad luck doesn’t exist (more or less) … there are mainly identified and unidentified risks! Identifying risks you can build your luck by yourself ;)

5) Don’t forget to collect lessons learned after each project … you cannot improve your ability to manage your future projects without lessons learned from your past projects ;)

This is my favourite answer from an old colleague, Gunveer Mahandru:

1. Show leadership (strong vision, direction. take risks, manage them)
2. Develop a backbone (back up what you say, don't wilt and wimp)
3. Work the team dynamic (manage the form/storm/norm/perform phases)
4. Engage stakeholders and keep buy-in (politics with a small 'p')
5. Inject entrepreneurship (excite, motivate, innovate)

Short, sharp and very effective...

Here are a few more useful little project tips:

Derive a burndown chart and use it to generate momentum and track progress.
- use Mike Cohn's estimation technique, planning poker.
- derive the ordered stack and begin plotting this over the time line.
- You may want to include checkpoints (or iterations) in the plan. (Step towards Agile)
- use these checkpoints as opportunities to deliver value (no matter how small) and plot your position on the burndown chart.
- Remove products from the stack when considered 'done'.
- 'Done' = when someone other than the developer (preferably the recipient) says it is... i.e. it meets the predetermined acceptance criteria.

In fact, I'd heartily recommend you watch Mike's YouTube clips on Agile Estimation: Part 1 and Part 2

A short note on lightweight reporting:
Agree a '5 minute emergency channel' with the sponsor... As you become aware of an issue which significantly affects the project, present what you know to the sponsor (no interpretation) along with a few proposed next steps. Aim to present and get a decision within 5 minutes... Even if the next step is to have a longer meeting. This way you keep your sponsor in touch.

Good luck!!

Plan to succeed on projects! (Part 1)

You've heard the old saying: "Plan the flight then fly the plan..." well I'd like to apply this approach to project management in this article and offer an formula that will ensure you're driving the project by result rather than activity.

Here we go:

Step 1) Find a sponsor. Note: If you haven't got a sponsor... get one... don't give in to the temptation to implement your own vision. If you're the sponsor then ideally get someone else to deliver your vision ;-)
Step 2) Talk to the sponsor about their dream... replay your interpretation at every opportunity. Especially the benefits they expect.
Step 3) Once you've gained a bit of rapport start talking about: scope, success criteria, time scales.
Step 4) Go away and think about the objectives and resources you'll need.
Step 5) Propose the set of highlevel project objectives and negotiate for resources.
Step 6) Develop a product breakdown structure... Derive the Product Flow Chart that follows.
Step 7) Market this to the team and sponsor as the delivery roadmap, make sure the roadmap attacks the highest risk/reward items first.
Step 8) In closing, make sure you're set up to drive the project by result not activities!

By this stage, you should have enough to get a green light to proceed. So there you have it... the flight plan.

In part 2 we'll look more closely at flying the plan...

How to generate better luck on large projects.

Today’s topic will include a look at typical project cycles and how to dramatically improve the 'luck' experienced on a project.

This posting focusses mainly on the Start-up and Final Delivery phases of a typical project and answers the question: What can we do during the start-up phase to promote success during the final delivery?

We will approach the answer by first looking at the 'What' and 'Why' before moving on to the 'How' and 'Who'.

So lets get started...

How can we generate better luck on our projects?

Step 1. Make sure you have the end in mind before you start.

Identify the high-level project deliverables along with the main business drivers. (Business Case)

These are powerful navigation tools essential for steering the right course.

Conduct a study of who your Stakeholders are and what benefits they'll want from your project.

Meet with your customers and ask them to help you to help them. Sounds cheesy, but it's a great way to build rapport and calibrate your approach. This will also demonstrate to them that your project is focussed on delivering benefits and not just another sterile solution.

Develop an 'Elevator Pitch' for the project and have this adopted by your management team.

Create a detailed Product Breakdown Structure taking into account the stakeholder input.

This takes care of the ‘WHAT’ and ‘WHY’ for your project. Now let’s look at the ‘HOW’ and the ‘WHO’...

Step 2. Conduct a full inventory check on the resources you and your team have at their disposal:

People, skills, expertise, budget, time, infrastructure, sponsorship support etc.

Consider the timelines for when these resources may actually be needed.

Assess any gaps between the project demand profile and what you can supply in terms of resources.

Work out how to fill the gaps. For example request more funding, skills etc. This is where you show your initiative and resourcefulness.

Step 3. Measure Measure Measure !!!

There's an old saying: "What doesn't get measured doesn't get done."

How will you know when you get there?

Look at the Product Breakdown Structure and work out ways in which to measure the successful delivery.

Carefully decide on the quality criteria for each one.
Try applying the GQM method to get started.

Make sure they are SMART criteria.

There is a strong cause and effect relationship between the decisions made at the start of a project and the ease of success of the output.

In short, effort invested in these techniques at the beginning will amplify the luck experienced at the end.

All the best,

P.s. Feel free to comment on this blog with your own experiences.

Make your mistakes early and cheap!

Take too long to deliver and you've missed that crucial window of opportunity!
Someone else gets to market with a competing product and again you've missed the boat!

This is where we can learn from today's entrepreneurs...

*** Make your mistakes early and cheap ***

(Featuring: Five easy steps to consider when planning your next deliverable ;-)

Last year we had a brand spanking new product to launch for a rather large internet start-up that sought to combine three major technologies; Mobile, IM and VOIP. The sheer volume of assumptions we were relying on made management very nervous. Their (quite natural) response was to consider extending the deadlines and increase quality control. Luckily, we managed to convince them to support our, seemingly counter intuitive, approach...
By thinking like a garage start-up we aimed to capture the essence of the business model in a cheaper and simpler solution. We found we were able to gain faster access to the revenue, drastically reduce the time to deliver and minimize the associated risk exposure. We planned several incremental releases that would respond to the feedback captured on the fly. This enabled us to maximize the revenue streams and easily ramp up the complexity. Working closely with these entrepreneurs gave me the idea for this post:

Here are five easy steps to applying the entrepreneur's lesson to your next project:

Step 1) Analyze the core requirement that your deliverable is addressing.
This is very much about WHAT your deliverable is trying to achieve as oppose to HOW. The answer will give you greater flexibility when generating pilot options.

Step 2) Conceptualize a Pilot version of your deliverable that meets this requirement.
As a rule of thumb, aim to scale the solution down to about 25% of the original budget.

Step 3) Plan to pilot this release to a select set of target users.
Identify and engage your customers early. Prepare them for the release and how they can best help out. Make sure you establish several ways for them to communicate with your team.

Step 4) Set-up your development resources to respond quickly to feedback.
Make sure your own team is setup to capture and manage the changes in the following releases.

Step 5) Start planning a series of releases as required.
Be ambitious with your delivery dates. Constantly re-prioritize the tasks to maintain alignment with the overall requirement. Think Triage! Follow this up with a schedule of release dates and commit to them publicly.