The Chart is not the Voyage

Or more conventionally – The map is not the terrain.

img_0323

This is an old quote attributed to Alfred Korzybski which is highly appropriate to my current client, as we make Charts of the oceans. They will be the first to agree that a chart is not the topography.

Charts can and frequently go out of date and so frequent updates of changes have to be notified to mariners promptly.  In response to the Titanic disaster there was an international convention for the Safety of Life at Sea and now all larger ships are legally required to carry the latest charts and to keep them up to date in response to warnings. But even with an up to date chart no mariner would blindly assume it covered all hazards or was completely correct at any given point in time. Sands shift, sea beds may have objects that drift, some hazards may seem too small to note at some scales, some Hazards are temporary, etc.

The expression though is a warning to planners and navigators that the information they are using to plan is a simplified and likely an out-of-date illustration of the terrain.  Navigational charts will often come with additional advice on approaching ports or other hazards but none can confidently claim to cover everything accurately.

Have you ever used a Sat Nav and found it taking you a convoluted and often much slower route because the pathfinding thinks a particular route  looks shorter but is actually a narrow country lane that has limited passing places, I’m sure we’ve all see photos of trucks stuck in a narrow road as a result of following a map (or Sat Nav) without really understanding the terrain.

46718056-F48F-8D7D-A085FF4E59003351

Planning

When planning a project you gather information to help you make the plan but here is the challenge of all planners:

  • If you try to cover every detail, every eventuality and every hazard it would likely take you as long as if you acted out the plan, probably longer as you would be mapping potential avenues that are never followed.
  • If you over simplify the plan you may omit key information and as in the case of the Sat Nav missing something crucial like a bridge being closed could throw the plan entirely. Making it difficult to stick to a plan.
  • If you plan from an illustration it is difficult to truly anticipate how long the actual journey will take.

Accurately planning for a team, large or small requires that you understand in detail both the journey and the team.

So how is it possible to get a team to successfully follow a detailed project plan?

Is it possible to successfully follow a detailed plan?

In a rather defeatist way, my answer is that it is not possible, or at least not consistently.

In waterfall projects, the normal solution is often to add huge amounts of contingency, if I think it is a 6 month project, call it 12 months etc. Have milestones to regroup and get back on track, but contingency when not needed is waste and in waterfall contingency is generally consumed. But contingency is in essence a form of planning based on an assumption that our plan is flawed – which it likely is, but this is hardly efficient.

We may also throw more staff at a plan or change scope or move dates the usual reactive crisis management that occurs when a Waterfall project is running late, but all of these are the result of a flawed plan, and in my experience the longer the plan duration the more inaccurate it becomes.

So if it is not possible to successfully plan a complex project why bother?

Essentially what I am saying is that Eisenhower hit the nail on the head when he said

“Plans are useless, But planning is indispensable”

Eisenhower

inspiration-voyage

Planning is Indispensable

In Agile terms, my advice is to set a clear Vision, we absolutely must know where we want to go, and then simplify the plan into high-level objectives, and then prioritize them.   Flesh out the detail of the highest priority item, and begin to explore more detail on the next highest priority and so on.  Have a plan that has the minimal detail and expand it as you go and be prepared to adjust.  Agile projects have the wonderful tendency to separate the wheat from the chaff and you will get a much leaner solution, lower priority features are deferred until later and often dropped altogether.

If we return to a voyage analogy if I were planning a voyage that involved multiple stops, I’d want to know the final destination and the major ports on the way perhaps an idea of key navigational way points, I would eventually want a detailed chart for each stage of my journey but I don’t need to study them yet (the charts may change or perhaps I will need to add a stop or skip one), the detail only matters when I reach that point. Right now all I need are detailed charts for the current stage, so long as I can plan that part of the journey  I can proceed.

How long will the project take?

“But I’m a Project Manager and I need to know how long the project will take.”

If you have been nodding along with me as you read this you will be in agreement that the notion of accurately planning a complex project is a flawed concept, and that your previous attempts to predict project duration inevitably result in inflated estimates to cover contingency and you are not competitive. So the question becomes one of “do you really need to know how long this will take?” Or “why do you need to know how long it will take?”

Generally this falls into a number of categories:

1 Dependency:

If you are planning a launch date and it must coincide with another particular event then this may seem to be a reasonable request, but the question isn’t really one of how long the project will take, but one of how much can be completed by that date? Can it be delivered in phases? What is the MVP?  How fixed is the date? Could it slip? Could it be deferred? What are the consequences if we are late?

The best advice would be to defer fixing the date as long as possible if content (MVP) is critical,  or to ask yourself if you are willing to adjust scope, and or cost to meet the date? It is rare to find a project where 100% of the requested features are truly mandatory on a particular date and when that is the case it is unwise to have a fixed delivery date.

2 Return on investment

More often the usual reasons for wanting a plan are because of cost constraints or price/profit related issues, neither of which are helped by an inaccurate plan. What they mean is “How can I predict whether this project will be profitable?” or “I’d like an estimate for how much is this project going to cost me?”

Both of these are perfectly reasonable requests but neither require a date to be plucked from the air and written on the back of a contract for the soul of the Product Owner.

In all cases where Scope, Time or Cost are a limiting factor Agile planning and Agile delivery should mean that you get the highest Business Value items for the lowest cost, and that you will know at the earliest possible moment when there are issues that may impact on the success of the project.  The aim is to deliver value at the earliest opportunity, in theory this is the most efficient and therefore most profitable/lowest cost solution for the given parameters. And if the project fails it will fail quickly for the lowest cost.

Agile doesn’t guarantee success or profitability, but when applied well it maximizes the value of successful projects, and perhaps more crucially in commercially driven projects it enables mitigation of failures at the earliest opportunity.

But you will have spotted that doesn’t answer the question: An estimate is a different matter entirely – see Estimates – Planning and estimation are frequently confused and they really shouldn’t be, but that is another topic.

3 Resource allocation

There may be other projects and you may want to predict when the team will become available, but assuming you are working on the highest priority project then your team is being utilized in the most appropriate way. Programme planning, like project planning is better done at a high level for the future and only becoming more specific as the task draws closer. If there is a dependency then see above, otherwise trust that the project/product will be completed as quickly as possible and the team can move on to the next task at the earliest opportunity.

Summary

There is nothing wrong with planning, planning is vitally important, the mistake is relying on a flawed plan, rigidly sticking to it in the face of reality.

Plan with the expectation that your plan will change.

img_0056

The Mythical Mature Team

On a regular basis I see comments in forums about how in a mature agile team a Scrum Master is not needed, or how the goal of a Scrum Master is to make themselves redundant.

On some level I agree with both comments, but the thing I am curious about is just what proportion of teams are actually mature?

My experience is anecdotal and is obviously reflective of where I have worked and who I have interacted with, but I have worked on Agile projects at 5 major companies, 3 of whom are top 100 companies and 2 major government departments, these are not obscure backstreet companies these are mainstream and in some cases pioneering tech companies. But if you measure Agile maturity on a scale of 1-5 the best would rate a 2/5. They are certainly improving, they are maturing and I am proud to have been part of that process, but they are all a long way from this fabled maturity.

So you might think that the rest of the industry is better and I have just been unlucky – or maybe I am hired because they need a coach to mature.  But again my experience disagrees with this, I do a lot of recruitment: in the last 12 months I have hired 14 developers/testers, and significant numbers at previous clients. I always ask about Scrum to get a feel for their experience and their attitude towards Agile delivery. I must have interviewed hundreds of candidates, and a significant number put that they are certified ScrumMasters on their CV.  But overwhelmingly those that claim to come from companies where they are ‘Agile’ or use ‘Scrum’ – demonstrate what I would describe as immature Agile adoption, sometimes just paying lip service to the concept.

So many, and I mean many! Seem to think that a daily Stand-up means they are Agile, I have had some describe how they are very Agile and follow Scrum closely but go on to describe how the plan is made in advance, a lead engineer estimates and the dev manager individually tasks on a daily basis and that testing occurs in the following Sprint to development and bugfixes are dealt with the sprint after.  I ask about retrospectives and I’d say that maybe 1 in 20 come from teams that hold any retrospectives and those that do describe quite varied experiences.

So for me that mature team remains a myth, something to aspire to.  However, I do notice that over time my role as a an Agile Coach changes drastically, early on a lot of time is spent embedding Scrum Processes, getting the team used to a different way of working, encouraging XP practices, building confidence in the team and showing the value of retrospectives and Agile delivery.  As the team evolves less time is spent on these, as a project progresses there are less impediments, but retrospectives become harder: the low hanging fruit has been dealt with and further improvements require greater insight and more skill to draw them out.  This is not a bad thing and gives time to start pushing out to the rest of the organisation, or taking on a second or third team.

So do you become redundant?  I don’t see it, there will always be some impediments and yes a mature team may learn to solve them by themselves but that is hardly the point, the goal is to allow the dev teams to concentrate on what brings value, and a Scrum Master can deal with many of these problems more efficiently and without distracting the frankly more valuable dev resource.

Also simply by their presence a Scrum Master acts as a counter balance to the Product Owner and the pressure to circumvent the framework.  There seems to be a notion that a mature team is a team of highly skilled software developers and testers that are also interested and eager to enforce Agile principles, and again this is something I don’t see, even the mature teams and experienced agile development teams are not enthusiastic about it in the same way a Scrum Master would be. They understand the value and the importance of Agile, they are wholeheartedly behind it, but that is quite different from the enthusiasm and drive a Scrum Master usually has.

If given the option of completing a task or attending a meeting, many developers would drop the scrum framework in a flash (“just this once”)  or extend a sprint to complete a story (“just this once”). It is also hard to see fault in yourself, and sometimes it takes an observer to reflect your behaviours back at you in a way to enable you to improve.

Metrics can be useful but they can take time and effort to produce effectively, and yes a developer or product owner could do it, but again this is something that a Scrum Master is likely better at and again the developers’ time is more valuable writing code.

Finally, new projects/product increments start and this creates a flurry of impediments, there will be turnover in the team and new staff will need to be hired and integrated into the team, a team may expand or another team needed and all of this runs far smoother with a Scrum Master. When you scale to having multiple teams working together the need for a Scrum Master becomes even greater.

In my opinion, for a new team on a new project a Scrum Master will be very, very busy, but over time as the teams settle and mature I see no reason why a Scrum Master couldn’t support 2 or 3 or in some cases even 4 development teams – assuming they are all located in the same room.

But the prospect of a team or teams without a Scrum Master at all causes me concern as it exposes them to internal and external pressure to compromise Agile principles. And unless there is an enthusiastic team member you are in danger of regressing and whilst you can certainly manage without a Scrum Master, our goal is not to ‘manage’ or ‘get by’ it is to be high performing and efficient.  If the team(s) gets more value from having a Scrum Master than they cost it should not be a difficult choice.

And if you truly want to be Agile, having an expert around to help and to coach would be high on my list of factors that can determine success or failure of a project.

I personally see huge value in having Scrum Masters and Agile Coaches, maybe not 1:1 with teams, but I question your commitment to Agile if you feel you don’t need them at all.

We all still have more to learn, and there are countless opportunities to improve.

Project Management Mistakes

I found an interesting link discussing common Project Management problems and suggested solutions, and I found myself questioning the advice given…

http://www.cio.com/article/2391872/project-management/12-common-project-management-mistakes–and-how-to-avoid-them.html

So many projects, so much mismanagement. That’s the refrain of many IT executives. Indeed, even with project management software, IT projects often wind up taking longer (much longer) than planned and costing more than budgeted.

I have previously covered the issue of how many failed projects there actually are, the proportions are really quite frightening: Most projects will fail by conventional measures, they will go over budget, be late or the scope will change, even with ‘good’ planning and contingency. So an assessment of “why?” is a great idea, but many companies are still stuck in a rut of doing the same thing and expecting different results.

The Survey in the link above and the proposed solutions is nice to see, but to me it felt as if the respondents were trying to solve problems by doing the same things that have failed previously – only suggesting that if they had done it ‘better’ it would be different, rather than considering that maybe the process that was at fault?  I wondered how applying an Agile perspective might offer different solutions to try.

I do not intend to be (too) critical of the original responses, they were clearly made by experts in their field and may very well be the right answer, but I have taken each issue – all of which are common project management issues, and I have applied an Agile head when offering a solution.

I don’t claim my solutions are right or better, but they may offer a slightly different perspective on persistent problems. And reflect how I would advise the problems should be resolved.

 

Project Management Mistake No. 1: Not Assigning the Right Person to Manage the Project.

Typically during resource allocation, most of the effort is focused on finding the right resources rather than finding the right project manager. Indeed, too often project managers get picked based on availability, not necessarily on skill set. However, an inadequately trained and/or inexperienced project manager can doom a project.

Traditional PM Solution:

Choose a project manager whose skill set(s) match the project requirements.

Agile solution:

1) Ask whether the project even needs a Project Manager, it may be that the content and scope could be ‘owned’ by a single ‘Product Owner’  When it comes to a project that involves integrating many independent components from different sources and there isn’t a clear hierarchy or dependency then a Project Manager may make sense, but where the project is delivery of a product increment, or there is a clear hierarchy and dependencies it is not clear to me what value if any that a PM adds, it becomes an extra layer of bureaucracy but no added value.

2) However the traditional answer applies in an Agile environment. Finding a Product Owner that has the right knowledge and skill set is vital, as is empower them appropriately. Finally have them focused entirely on this one and only product. Multi-tasking will generally lead to problems with one or both projects.

Project Management Mistake No. 2: Failing to Get Everyone on the Team Behind the Project.

Too often, projects are doomed to fail because they didn’t get enough support from the departments and people affected by and involved in the project. Either managers: 1) Didn’t make clear what everyone’s role was. 2) Didn’t describe the personal payoff everyone would get when the project was completed successfully. 3) Didn’t tell how each person’s contributions to the project would be evaluated. And/or 4) Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine.

Traditional PM Solution:

The project manager should start by calling the team together (being certain to include off-site staff via the best technology available) and delivering a presentation about the project and its significance in a way that gets everybody fired up.

Agile solution:

1) The Product owner should share the vision with the team, show how their part fits in with the big picture. The vision is crucial and should be clear to everyone. (just as above)

2) Where possible have team members dedicated to the project, this immediately builds ownership and commitment, have them co-located with colleagues and build a team. Motivation to team mates is more effective, more consistent and has greater longevity than that which can be created to a project.

3) Have the team involved in setting goals and expectations; the more involved they are the more they will buy-in to the project. Give them ownership of the design and the level of quality, a self-set target is more meaningful than an imposed one.

4) Discussing Personal payoff is not helpful, we are trying to build a team, in software projects like any cognitive task both carrot and stick are counter product and can be demonstrated to reduce productivity. It is far better to build a good team and share a vision, a well-motivated team does not need a sense of payoff, successful delivery of a product is motivation enough. A shared purpose and shared success.

5) Again a sense of urgency is not a helpful tool for motivating software teams, ‘Urgency’ should be reflected in prioritization not pressure or deadlines. An appropriately motivated team should work at a sustainable pace.  Let’s talk in terms of priority: Urgency is a reflection of poor management and poor planning, projecting that failure on to the team is in my opinion a sign of failure of management.

One final note – “Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine”   I find this to be a very bizarre comment, in my opinion “Business as Usual” is fine, in fact business as usual is great. If I have a team that works at a sustainable and predictable pace that is the holy grail for a project manager, or it should be. A known quantity, and one that can run and run and run like the Duracell bunny is what any project manager should desire.

Why would anyone thing that driving a team into the ground to meet an urgent deadline, followed by a crash of exhaustion, staff potentially off with stress, or quitting, or any of the other consequences of deliberately overworking and pressuring staff is actually a good thing?

Whilst meeting an unrealistic deadline set by someone outside of the team may well be the priority of a PM, it is naïve to assume you can move teams from one project to the next without a break always expecting them to work with a sense of urgency.  It would be far better to think of the team as a machine that takes a while to get up to speed, whilst you may be able to stress the engine and push it to the limit, to do so regularly or for prolonged periods will cause damage. Whereas a good engine run at a sustainable pace can run for far longer.

Ultimately, It comes down to a question of respect. If you treat your team right, they will work well for far longer and be far more productive in the long-term.

 

Project Management Mistake No. 3: Not Getting Executive Buy-in.

Traditional PM Solution:

Somebody at the higher levels of the organization needs to own the project from start to finish and be personally vested in its success, When a project has no clear head, things tend to fall apart.

Agile solution:

1) A single Product owner should be empowered, and personally vested in the success and assigned exclusively for the duration. If the Product Owner cannot be sufficiently empowered to achieve success, then your organization has more serious issues.

2) Not all projects need a senior sponsor, but they do need support appropriate to the project.

3) Senior sponsorship for the way you work is vital – By which I mean Framework – in this case Agile. The organisation needs to be behind the delivery method. If the project is necessary then the project leader needs to have the backing of the company to get it done. Any block to agile delivery needs to be aggressively unblocked and sometimes this required uncomfortable change in attitudes, and that will require senior sponsorship.

 

Project Management Mistake No. 4: Putting Too Many Projects into Production at Once.

Most managers think that they can get more done by starting all projects at once, but in reality, it’s counterproductive. Multitasking slows people down, hurts quality and, worst of all, the delays caused by multitasking cascade and multiply through the organization as people further down the line wait for others to finish prerequisite tasks.

Traditional PM Solution:

To stop these productivity losses, a good first step is to reduce work in progress (WIP) by 25-50 percent. This reduces the back and forth and makes managers and experts more responsive in dealing with issues and questions. Though counter-intuitive, reducing the number of open projects by 25-50 percent can double task completion rates.

Agile solution:

The same as above: reduce WIP, far too often we resort to claiming credit for starting work, or for claiming it is in progress.  The only metric that matters is completed work.  If limiting the number of projects on the go, results in more projects being completed then what are you waiting for?

I’d like to write more on this topic, I feel this is so crucial to success, the number of times teams are held up because of competing demands on networks teams, DBAs or deployment pipelines or any number of other critical resources. The impact of these are often unmeasured, but simply reducing the number of concurrent projects relieves the context switching and demand on these resources. Which is an immediate easy win.

But more that if you can deliver 4 projects in 12 months, why not deliver 2 of them in 6 months, and then 2 in the following 6 months.  That is two projects delivered 6 months early without any additional work and without delaying anything, you may even find they get done quicker.

Project Management Mistake No. 5: Lack of (Regular) Communication/Meetings.

Communication is the most important factor of successful project management. Without regularly and clearly communicating, the project will fall apart.

Traditional PM Solution:

Pick a day and time to meet each week (either virtually or in person) that works for the team (not just the project manager) — and stick with it. Having specific days and times scheduled, in advance, helps to keep everyone on the same page and keeps the project flowing.

Agile solution:

Meet daily, co-locate the team to reduce further any delay in communication.  Use information radiators (Whiteboards to the rest of us) to prominently display  useful and pertinent information.  If the information is useful you need it now, if you can wait a week for it, it probably isn’t that important.

Communication in Agile is crucial, anything that can be done to reduce the barriers to communication should be considered a priority, getting team members and those peripheral to the team communicating effectively is vital. Co-locate where possible, a daily stand-up is a scheduled opportunity to get together and share, but for anything critical even a daily meet up is not quick enough. But communication should be useful, timely and concise.

Project Management Mistake No. 6: Not Being Specific Enough with the Scope/Allowing the Scope to Frequently Change.

Any project that doesn’t have an ultra-clear goal is doomed, scope change is one of the most dangerous things that can happen to your project. If not handled properly it can lead to cost and time overrun. Even something small, like changing the color of a logo or adding a page to a website might cause unexpected delays.

Traditional PM Solution:

Define the scope of your project from the outset and monitor the project regularly to make sure you and your team are keeping within the scope. And to avoid delays and deviation from the original scope, track change requests separately from the original project scope, and provide estimates on how it will affect the schedule and get explicit customer/stakeholder approval for each change.

Agile solution:

“Even something small like changing the color of a logo might cause unexpected delays”   Wow!  And the solution is to “Avoid delays and deviation from original scope”  Wow!

I am utterly stunned by this problem and the response.  First everyone involved in a project does or should understand that Change causes delays, any client that expects to be able to change a Logo or add a page without a consequential delay, is extraordinarily naïve or is being misled.  Very simply work takes time, sometimes even removing work takes time.  A product Owner or PM should be able to candidly discuss this with the client, if the client is asking for change they should be made aware of the impact and that information should help shape their decision.  If you cannot have this conversation then there is insufficient trust between you and the client, and rigorously enforcing terms of the original contract is not going to promote trust.

In my opinion the response is shocking, just who is the Client here?  If the client has changed their Logo, then who would consider it sensible to plough on with a solution that is wrong? Refusing to accept change is not working for your customer, it is self-serving and ultimately futile.  This stubborn refusal to accept change is the primary reason Agile has been the huge success it has, because the customer is respected.  In Waterfall the goal is to conform to a contract, in Agile the goal is to give the customer what they want. The difference between the two is a happy customer and an irritated customer seeking a new supplier.

Example: If we consider an extension to a house, upfront I may have architectural drawings, and building plans, and I may get a builders quote based on those plans.  But as the build progresses I decide that I’d like to change the position of a window or I change my mind about the type of tiles, or kitchen units. As the customer that is my prerogative.

Situation A:  Builder says, “No! that is not what we agreed, you must stick with the plan and keep the materials you specified.  If you want to change this, you must wait until we are done, then rip out the work and redo it later.”

Situation B: Builder says, “Yes! But it is not what our estimate was based on, changing the plan and materials may increase the cost, and may take a little longer. So long as you are comfortable with the impact we are able to accommodate your requests.”

And Just for fun – and this generally doesn’t work so well for building work where planning permission is needed upfront but still…

Situation C: Builder says, “Let’s build the initial framework and you can defer making the decisions about the layout and internal fixtures until later, when you are better able to envision the situation.

Project Management Mistake No. 7: Providing Aggressive/Overly Optimistic Timelines.

The intentions are noble, as project managers are often trying to keep their clients happy. But missing deadline after deadline will only lead to distrust and aggravation on the part of your client.

Traditional PM Solution:

Good project management software will allow you to manage many work items and the bandwidth of available resources. However, it’s still important to add a buffer providing some extra time and money to your project, especially in the world of technology.

Agile Solution:

The proposal of Better software, and more micromanagement and adding contingency to counter optimistic timelines, is the opposite of good agile practices.    Once again I completely disagree with the proposed solution.

Solution 1) If the timelines are unrealistic this should be addressed, the team (dev or management team, or customers) should assess why they are coming up with unrealistic estimates, and modify behaviour accordingly.  Discuss why a timeline is needed, and plan accordingly.  If we must meet a specific date then we plan the solution accordingly, if we must keep to a certain budget, we can plan the solution accordingly, but an estimate is not the same as a deadline. See blog post…

Solution 2) Rather than adding buffers and contingency, how about prioritizing content and being flexible with the scope to meet a timeline if the timeline is critical, or being flexible with the time.  It is a controversial comment but I find the routine practice of PMs padding estimates or surreptitiously adding contingency is counterproductive, it causes mistrust, and is ultimately futile as management will react by demanding earlier delivery believing that estimates are padded.  I’d much prefer to be open an honest, and build trust, I keep management informed of progress and allow them to make decisions on true and upto date information.

Solution 3) Fancy software doesn’t help. The more you micromanage the less productive the team becomes.  For a former software developer and general technophile, when it comes to project management I’d actually prefer to have no software tool at all.  A Kanban board and a backlog of stories on Index cards is actually very powerful, software has value in some circumstances but most of the time the simple approach is sufficient and clear to everyone involved.

Project Management Mistake No. 8:

Not Being Flexible. While you may think of your project plan as your bible, telling you what needs to be done, by whom, and when to do it to get to your goal. Don’t hesitate to listen to new information and suggestions that come up along the way.

Traditional PM Solution:

It’s good at various intervals to step back and take a fresh look at the overall project, review how things have gone so far, and how you can improve your future work based on what’s already changed along the way. That doesn’t mean you should or need to constantly make changes,  just be open to suggestions if they help the project.

Agile response:

Schedule regular retrospectives, make the act of trying to improve a regular part of your job. Actively look for ways to improve, a passive ‘being open to change’ is not enough. We need to seek to improve and have a willingness to continually find even small ways to grow. Many small improvements can lead to significant benefits.

Project Management Mistake No. 9: Not Having a System in Place for Approving and Tracking Changes.

Often, success or failure of a project hinges on the changes that occur after it begins. However, all too often, there is no system in place for approving and tracking changes.

Traditional PM Solution:

Having a clear process that must be followed is the best way to ensure the pertinent details: how much it will cost, why it is necessary, the impact on the overall project etc., are known before the change is approved. It’s also extremely effective for auditing performance during and after project completion.”

Agile solution:

Change is a part of software development, no amount of planning can ever reveal everything, there will be change, so plan for it from the outset.  Prioritise work rather than plan in detail, allow for priorities to change and expect them to change. Allow for new work to emerge, and consider and plan for the possibility of failure.   As with the traditional PM approach, why; cost and impact need to be considered, but these are a factor of priority. Any heavy weight review process is unnecessary.

Failure is deemed bad in all circumstances, but that is not the case, to fail early may actually save significant costs compared to failing later. This should he heralded a success, but too often all failure is considered bad. Failure can lead to successes later. Not learning from failure or continuing along a failing path is the real waste. But too often any failure is not tolerated and this can be very damaging.

Project Management Mistake No. 10: Micromanaging Projects.

Don’t babysit, It’s very common for budding project managers to treat their job like an enforcer, policing the project team for progress and updates.

Traditional PM Solution:

Instead of babysitting the project team, let it be known from the start [i.e., the kick-off meeting] that there will be regularly scheduled updates for the duration of the project. This lets your team know that status updates and progress are expected from them weekly and will encourage them to vocalize any issues or delays in advance.

Agile Solution:

Don’t allow the Project Manager or Product Owner to micro-manage, it is the job of the Scrum Master to coach the team to manage themselves and then the SM is to run protection – keeping the wolves at bay. PMs micromanaging is rarely beneficial and is generally damaging. The saying goes that you should hire the right people to do the job, and once you have hired them, trust them to do the job right.  If you have hired the wrong person no amount of micromanaging will help, and if you have the hired the right person micromanaging will only hurt.

Project Management Mistake No. 11: Expecting Software to Solve All Your Project Management Issues.

I’ve seen people throw software at problems all too often, and though projects become enumerated and more visible, the underlying process is still broken,” “What you end up with in that case is a potentially costly piece of software only serving as a checklist of projects in motion without any thought given to advancing each project/milestone effectively.

Traditional PM Solution:

Choose project management software wisely — something all members of the team will be comfortable using. Then make sure to train users properly and set up a system for tracking projects. Above all, don’t let human capital be “overshadowed by the allure of software solutions’!”

Agile Solution:

Fancy software doesn’t help. The more you micromanage the less productive the team becomes.  When it comes to software project management I’d actually prefer to have no software tool at all.  A Kanban board and a backlog of stories on Index cards is actually very powerful, software has value in some circumstances but most of the time the simple approach is sufficient and clear to everyone involved.  Naturally many projects involve more than a single stream of software and in that case a software tool may be useful, so long as it doesn’t interfere with the software development streams.

If we limit scope to be a software development stream, then simple metrics on backlog, cumulative flow and perhaps velocity should be more than enough to check progress towards milestones. But in this case the Product Owner is the best source for the health of a software project.

 

Project Management Mistake No. 12: Not Having a Metric for Defining Success.

Traditional PM Solution:

The very first thing a project manager should do is ensure he understands what the end users will consider a successful completion to the project,” Understanding what will make a project successful…ensures that when the project is completed [all] parties walk away satisfied.

Agile Solution:

Very similar, a clear Vision for the project is key, but a vision is not a set of requirements it is a concept.  Ensure that the Product Owner and the team understand the vision and any intermediate milestones.  But the goal is satisfaction of the customer,  that is the only metric that matters. Ongoing conversation to ensure they are satisfied with the progress is essential, regular reviews and conversations to ensure your solution is meeting their needs.  This is not an exercise in checking off items on a contract, it is about delivering the right solution to the customer.

 

Summary

It surprised me how different an agile approach is, I had expected far more overlap, after all Project Management is as old as the hills. Some solutions are common to both approaches but even then the approach whilst similar seemed to have a different goal.

But what struck me most was how Traditional solutions fell back to a desire for more control: control the scope, control the team, and control the customer. Whereas Agile was about building a team, responding to the customer and guiding not controlling the delivery. The perception of control is such a fallacy when dealing with a customers evolving needs and the unknowns of software development.

 

A quick Star Wars quote to finish:

“The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.”

Could it be as simple as that? As a Project Manager it seems that the more control you try to exert, the less real control you have on the delivery, but by accepting a little Agility:- whilst it may seem to be relinquishing control you are actually far better able to steer the project.

Vision without action is a daydream. Action without vision is a nightmare

Waterfall vs Agile?

Sounds a bit daft to even be having the debate, surely by now there is no one left that still thinks waterfall is the better choice for delivery of complex software projects, unfortunately that is very far from the truth, there seem to be many that still prefer waterfall and recently I even heard it talked of in terms of the good old days.  So I delved a little deeper.

In this instance the source was a statement by someone who’s opinion was given weight. The comment was:

I could deliver ‘project x’ using waterfall if you gave me dedicated resources and we could lock ourselves away for 6-months.  

In waterfall the costs of planning are high, the costs of analysis is high, and the cost of change is very high. But by it’s nature waterfall has a clear scope(vision).   The result is that everyone is clear on the priority, the project is protected, no change and no disruption, the scope doesn’t change. Because everyone understands the cost of interruption.

In Agile the upfront cost of planning is low, the upfront cost of analysis is low and the cost of change is relatively low. The result in some cases is that ‘unnecessary’ direction change can be frequent, the project is unprotected because it can adjust, disruption can be frequent, and so the scope regularly changes for sometimes trivial reasons or low priority distractions.

In short we are not comparing apples with apples.  We are comparing focused vision-led waterfall, with an unfocused ad-hoc agile.

In the example above the team had a fairly vague goal to deliver ‘x’ but also support ‘project y’ and deliver small increments of ‘project z’, ‘project w’ and maybe even an update to ‘project v’ too. And that plan was likely to change next week when something else came along. Because of this ‘project x’ was taking far longer than anticipated. so this notion that delivery using waterfall would be quicker has arisen.

But, the problem for me is that it was not the ‘waterfall’ part of the plan that would ensure success, it was the dedicated resources and clear vision that were the crucial aspects.  Give me a clear vision and those same dedicated resources and I can be pretty sure that I would deliver what the customer wants, sooner, cheaper and more reliably using Scrum than someone else could using waterfall.

Agile is the victim of it’s own agility, it is like the free gift no one values.  Because there is less pain in changing direction in agile projects, and because the team can adjust and adapt, that doesn’t make it free and it doesn’t mean it isn’t disruptive.

Agile enables you to have flexibility in planning, it allows deferring decisions, it allows planning only small amounts, and allows changes in direction and content.  But just because you can do these things doesn’t mean you always should.

A single vision with dedicated resources is a powerful combination, Agile is a powerful tool, but as they say with great power comes great responsibility.

Agile enables you to vary the scope of your vision, to respond to change, it is not a licence to operate without a vision.

As the Japanese proverb goes:

Vision without action is a daydream.  Action without vision is a nightmare.

Who is interviewing who?

How I’d like to do it.

My advice would be to concentrate first and foremost on creating a place where people would want to work, then marketing your organisation to the candidate, they should really want to work for your company, that way you start with a better candidate pool, immediately giving you a better chance of finding the best employees.

Then – even if it feels impersonal, a series of consistent structured tests (IQ and Psychometric) and then formal structured interview questions where the results and responses are noted and then referred onto an independent panel for a decision on hiring. Forget the gut-feel, forget the technical questions, forget hostile interview techniques, they really don’t work. Throughout all this ensure the candidates are treated well and made to feel important.

Sounds like hard work, it sounds like it undermines the hiring manager, it sounds incredibly time-consuming and bureaucratic, perhaps even expensive. But if your goal is to consistently hire good quality candidates it is going to be hard work and you will have to accept that there are some things that cannot be effectively and consistently assessed in an interview situation.

My final thought is that if you have got your hiring right, it is very likely that the most capable, most experienced and most reliable person for a role is the one currently in it. Don’t lose them.  Look after good employees they are your company’s most valuable asset.  Treat them well and do whatever it takes to keep them.

recruitment tips

And next time you are in an interview situation, ask yourself who is interviewing who?

Typical interview styles

The interview itself.

What I have observed is that interviewing is generally composed of one or more of a very small number of techniques:

  1.  Free-form, gut-feel unstructured or semi-structured chat and questions between candidate and hiring manager.

  2.  More formal pre-defined questions structured and consistently asked to all candidates.

  3.  Some variety of standardised test, essentially IQ based.

  4.  Questions posed by a technical expert with a desire to highlight his superiority rather than assess your capability.

  5.  A technical test or series of technical questions intended to be pragmatic and fair.

  6.  Aggressive panel questioning

  7.  Psychometric testing: verbal/numeric/diagrammatic reasoning or personality tests.

  8.  Presentation by interviewer on why the candidate should work for you.

There are studies and statistics that rank the effectiveness of the different techniques for selecting good candidates, I won’t pour them out here – I am not an expert and I’d just embarrass myself. But in my experience 1 is the most common, often combined with 4 or 5. But logic states that 4 is a waste of time and puts off candidates, and studies show that 1 and 5 are actually very, very poor indicators of ability and capability for the role and do not result in long-term success.

So what works? 

2, 3 and 7 are by far a better method of assessing candidates, followed by an independent panel-decision based on the documented evidence taken from the interviews – the interviewer should not be allowed to make the decision independently as they display bias (subconscious or otherwise).

But 2, 3 and 7 are hard, it requires yet more work on what is already a tough and time-consuming process, so very rarely gets done.

The reciprocal nature of an interview (8) is so often overlooked, if you want the best people and you want to get the best out of them, then not only do you need to decide if they are right for you, you need to convince them that your business/team is right for them. You should be putting as much effort in to impressing candidates as they put into impressing you. You are competing for them in a buoyant market.

recruitment2

Doing it right.

As an interviewer, my best experience has been for a company that did a combination of 2, 3, 7 and 5. We put a lot of effort into interviewing, but the majority of people still failed the combination of tests, especially the technical test. The test felt ‘easy’ to us and some candidates did well, but the results didn’t match the apparent skills of candidates, in hindsight I think it confused the process. The problem is that technical tests are not effective at assessing ability during an interview, there are simply so many other factors at play.

Relying on structured questions, IQ tests and psychometric tests may feel clinical and impersonal, but very likely the best way to find the right candidate. But ego plays a role and when hiring for a team, we are only human and so many hiring managers want to rely on their own instinct, even if evidence demonstrates this is unreliable, so it is hardly a surprise that many hiring managers favour their instinct over a structured process.

What makes a good interview?

My experience of recruitment is largely anecdotal, I am not a professional interviewer or HR expert. My limited experience of interviewing has been as a candidate, a hiring manager, or sometimes even as a subject expert. I’d estimate that over my career my experience is approximately 8:1 in favour of being an interviewer over being an interviewee, but I have been on both sides of the table often enough to know how it feels from either perspective. 

Over the last 5 or so years the amount of effort I have put into recruitment has been considerable, especially considering it is not really meant to be a significant part of my role. I’d estimate that I have hired an average of one person ever 2 months or so.   I even like to think I am pretty good at it,  although as you will see I am probably mistaken in that opinion.

What is striking though is how much time this takes, very anecdotally I’d estimate that depending on the quality of the CVs that I receive, on average only 5% will make it through the screening and interviewing to getting an offer(probably less). But the 95% that get rejected still consume a lot of time, and of the 5% selected we don’t always get it right, and I’m pretty sure quite a few good candidates get missed. The process is far from ideal.

recruitment

But what makes for a good interview?

As a candidate I have had interviews lasting less than 15 minutes (where I was offered) and interviews spanning 3 days, for a graduate recruitment programme, and just about everything in between. I have had good experiences and bad.

Some, in fact most interviewers seem to forget that the candidate is also interviewing them, and that the candidate is deciding if they want to work with you in the same way you are assessing them – it is not a one way decision by any stretch. Such is the lack of understanding and sheer arrogance of some that I have been asked extremely obscure technical questions that provide no clear value, I have been challenged(insulted) to gauge my response, I have had panel of interviewers quick-firing questions and had interviewers who were clearly reading my CV for the first time during the interview.  Why would any good candidate have any desire to work for you after an interview like that?

I haven’t kept accurate records, and I appreciate this is anecdotal but I’d estimate I have turned down close to three job offers for every one I have accepted over my career. Now I am well aware that I am fortunate to have in-demand skills at a time when the market is booming, I have also had a lot of rejection.  Similarly, as a hiring manager I’ve had too many candidates turn down offers, or more frustrating get a better offer before we could complete the hiring process.

The hiring process is so expensive and so important I am surprised at how often it is treated in a cavalier manner.   Why oh why would you be so arrogant to treat candidates with anything less than the respect you would expect them to show you?

What is the Minimum Viable Product?

A question came up this week following a discussion on story writing that I think bears further discussion.

What really is the Minimum Viable Product? 

To explain my thoughts I will use the building of a Skyscraper as an analogy.

The project vision is to build the UK’s tallest building. To achieve that it must be over 1000ft tall and 88 floors.

What is the MVP?  There are many possible answers to this, but the first two responses that spring to mind are:

1                 My MVP is over 1000ft tall and 88 floors, without that it simply fails to meet my vision.

But let’s say I underestimated the costs and after 65 floors I run out of money, I have been agile and each of the floors was a complete deliverable, the building is perfectly functional at 65 floors, in fact it was probably functional at 1 floor.   So surely at any point it was an MVP?

construction

2                 My absolute worst case scenario MVP a single floor

This is where things get confusing.    No serious customer would consider a 1 floor building with massive land costs and hugely expensive foundations ‘Viable’  the project would never be signed off.  As such this is not viable.  However, I’d still suggest aiming for the ability to deliver in phases, e.g. a delivery after each floor.

In this situation I’d say an MVP is the minimum that a customer would accept. And that is a conversation, would he agree to a MVP of 88 floors but a first phase goal of 20 floors, with the ability to expand later? As you can imagine the MVP is likely to change according to the circumstances. Our goal is to delight the customer but our plan is to build the product in such a way that if at any point he is satisfied or better yet delighted, we can ‘deliver’ immediately.

skyline

My point – hopefully not lost in the mix is that an MVP is about thinking about the minimum that a customer would find useful – usually this is closely related to the original vision. In the case of this building – what if the last 10 floors were empty unfinished shells? or similarly we leave the project in a state where it is valuable as is and the Vision can be achieved in a future project  – The building still will meet the vision and those floors could be finished later?

Having an MVP in mind is useful, it may help with some decisions, but every project is different and MVP will likely evolve with the project. A good Product Owner or BA will be able to work out what is the true MVP and why. The PO can focus on the customers evolving needs so that the customer gets the best ROI at each stage, but most of all they will be aware of what would be the solution that would delight the customer.

An MVP is a tool like any other, in most cases it is a fall back position, not the goal.

Live to work, not work to live.

It is often said that happiness is about finding balance in your life, sometimes this means making time for the different aspects of your life, work, hobbies, family and so on, but what if balance is achieved by taking pleasure in all these endeavours? Not simply making time for each but making sure each is fulfilling in its own way.

Too many people seem to suggest that they dislike work, or that it is a chore to be endured for the pay cheque. I find this an odd perspective. Why would you spend 40 hours a week, every week, doing something you endure? Chances are you spend more time at work than anything else. 

I am very lucky, I have a job I love, although I also love my bed and find getting out of bed on a morning difficult sometimes. But once I am up I am itching to get to work, I have ideas and plans and normally can’t wait to get started, at the end of the day there is usually more I want to achieve and it is only self-discipline that makes me come home at the end of the day, I set myself a time box on my working day to avoid taking on too much or allowing work to take over, I try hard to only rarely exceed it, this is a personal choice and I’m aware is not common but works for me and is something I encourage in teams I coach. 

I have covered this before but being clear on what you can achieve in a working week is vital. To quote Dickens.

“Annual income twenty pounds, annual expenditure nineteen pounds nineteen shillings and six pence, result happiness. Annual income twenty pounds, annual expenditure twenty pounds ought and six, result misery.” Charles Dickens.

My philosophy is similar – if your workload can be achieved in the time available the result is happiness, if your workload exceeds the time available the result is stress and unhappiness.

If you work extra hours to get the extra work done, the result is that next week the work will grow more and then more, until at some point you will collapse or be forced to set a limit, so set the limit now where you are able to do so objectively.
When it comes to job satisfaction it is fair to say that my job is not saving the world, I am not doing something overtly exciting or grandly creative, the teams I work with are about streamlining business processes to increase automation, reduce errors and reduce staff to save the government money, as a 7 year old I was hardly saying “when I grow up I want to save the government money”. But nevertheless I love my job, I work with some really nice people and we are working hard to do a good job. I take pleasure from achieving goals, and especially seeing teams and individuals develop, I take particular pride when my advice or coaching bears fruit.

Life is shaped by experience and I have found that no matter what the work there can be pleasure in it. In the past, I have been a debt collector, I owned and ran a small retail bookshop, But I have spent most of my career in software development, some interesting projects some much less so, but it has been only rare occasions that I haven’t enjoyed work. My first post-university job was with Bell Labs working on GSM, the established guys got to work on the roll-out of GPRS, but the new guys got the ‘dull job’ we had to fix bugs on an old C++ Unix system, but it wasn’t dull at all, we had a largely absent boss so we mostly organised ourselves, every bug was a puzzle, a challenge and a learning experience (I hope that doesn’t sound too pretentious because it really was enjoyable) we had a small team that were great fun, we would lunch together most days, we had a pretty poor softball team that played in a league and lost most of the time, and we often socialised together, because work isn’t just about the work it is about the people. 

My worst experience was also at Bell Labs, the team had an ambitious boss, he wanted a juicy high profile project and so he turned down anything that didn’t fit this requirement and so the team went through an idle period where we quite literally had nothing to do, it was sole destroying, we would come to work for our required hours but there was nothing to do, we read, and looking for training, we talked and we played silly office games, we formed a league for Ball-in-the-box a game where we threw a mini American football the length of an office to bounce into a photocopy paper box, after many hours playing we became quite adept. But what we were not allowed to do was work on something, we had to be ready for the next plum project.  Thankfully a senior manager saw what was going on, and transferred the team to UMTS (3G) this was a lifesaver the morale was getting pretty low.  I find it odd that my worst experience was where I was paid to do nothing but chat have fun and play games, for me at least I get pleasure from being busy and doing something I see as productive and valuable. 

Perhaps the most influential aspect in anyone’s life is their parents, I was a “vicar’s kid” or “son of a preacher man” etc etc, my father was a minister of religion and I was the 3rd of 4 children, the only boy, as a result I have developed a pretty strong rebellious streak, but what surprises me looking back is how much my father’s work has influenced me, as the leader of a church he was an archetypal servant leader, a church is a voluntary organisation, the minister is employed only with the support of the church and he has very little power, his job is to lead and to serve. It is extremely challenging and often unrewarding. 

So now like him I am the servant leader, only in business, I see myself as having two roles one to serve the team and one to lead them to achieve, and what I have learned is that it is important to create an environment where your team can enjoy work, this is a paradox for many as the assumption seems to be that if you are having fun you are not being productive, my experience is the opposite – not being productive is no fun at all.  

Make work an enjoyable place to be and people will work harder, make them feel invested in the organisation and they will work harder still, create a team spirit and collective sense of purpose and they will amaze you.

Trust is often lacking and this is a real sticking point for many managers and businesses, but my opinion and experience is that the normal situation is that people have an inherent desire to work hard and achieve and give the opportunity they will, what often prevents this are people or processes that restrict or control, managing should be about setting goals and guidelines, creating a framework to achieve not a culture of control.

My number one piece of advice for a ‘task’ manager is to give a team a clear goal and stand back, you will be amazed. 

Your only three jobs as a leader are to remind the team of the goal, to remove any obstacle in their way and most importantly  to Trust them. 
As an aside for business leaders I’d also suggest if you want to build and retain an effective happy and productive workforce, to indulge them (sensibly) make them feel valued, give them the best tools – generally whatever they ask for, the cost is likely a fraction of their salary and tiny compared to recruiting and training a replacement if they are lured away, give perks – for example issue everyone an iPad and a pluralsite subscription, this costs very little(and is tax deductible) in comparison to an average salary (far less than 1%) but I’d bet your team would feel valued and would broadcast what a great employer you are, and chances are they might even do some training too. Provide coffee and snacks, encourage social activities, make time for the team, if people feel it is a great place to work recruitment becomes easier and they WILL work harder. And lastly pay more, especially to those that have proven themselves, being generous early saves a fortune later, if you are not paying your best people well above average it is inviting them to leave.

To be the best, hire the best… for you.

I have recently been reflecting on the impact of our choices when hiring new staff. Over the last few years hiring has been a major activity for me, and so I am particularly interested in what the impact of these hiring decisions has on the team and the organisation.

I have a number of experiences that I feel are relevant and two particular opinions I have recently heard that I would like to discuss.

The first was from a blog post: http://zachholman.com/posts/0x-engineers/   in this the author is critical of everyone chasing after the type ‘A’ engineer, it makes an interesting read and refers to a popular belief that the good software engineers are worth 10x as much as the ‘average’ engineer.  I don’t intend to get into the basis or accuracy of the claims, but I am satisfied that it is a generally well accepted opinion that there is a significant difference in ability, and value of output between those deemed average and the top end of the scale, I have heard figures ranging from 10x as valuable to 1000x as valuable from quite well respected authors.

But ultimately the author compares software engineers to restaurants and concludes that most of the time he would be content with an average restaurant as we can’t always all eat in the best restaurants.  This is the point where I try hard not to be dismissive. The analogy is suggesting that most of us are content with ‘Good’ food and don’t need ‘Great food’ but the reality is that we are not only comparing quality, we are comparing relative quantity AND quantity, if we use his 10x value estimate then what we are comparing is a 1/10th of a ‘Good’ meal to a whole ‘Great meal’  We’d need to eat (and pay for) 10 ‘Good’ meals to get the same quantity/quality (value) of food.

He does have some good points about a good team being better than a star player and I’ll come back to that but I for one am not content with a tenth of a meal.

By contrast I looked at Work Rules! by Laszlo Bock (SVP People Operations at Google)

Lessons from WORK RULES! include:

* Take away managers’ power over employees
* Only hire people who are smarter than you are, no matter how long it takes to find them
* Pay unfairly (it’s more fair!)
* Default to open: be transparent, and welcome feedback
* If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

Laszlo advocates hiring only the best, by hiring the best you get the best output, you certainly have to pay more but you don’t have to pay 10x the salary to get a 10x software engineer, it makes financial and practical sense, a small team of high achievers must be amazing and they clearly are for Google. But…

Here is where the real word kicks in.  Most of us don’t work for Google or Apple, we will not attract the best of the best, most organisations are unable to employ an entire team of 10x engineers, many of us are lucky to hire a few high achievers, when location, salary, benefits, and image are factored in, we can be selective and choose the best of what is available to us, but a good engineer is hard to find.

So I am saying that I don’t want a team where the primary qualification is a pulse, and I am highly unlikely to be able to hire (and retain) an organisation full of 10x engineers.  My world is the grey area somewhere between.

This brings me to what has been an inevitable consequence of the real world – a mixed team.  I didn’t like the restaurant analogy so I will go with cars.

cars

Lets say I have a team of five developers, as a very general rule a team will travel at the pace of the slowest member, and whilst you may be able to improve the speed of the slowest a little, the high performers are stuck at the slowest speed and may well be getting bored and frustrated.  It is no good one or two members zooming-off, knowledge doesn’t get shared resentment grows and very quickly you are at a standstill with a dysfunctional team. An effective team moves at one pace – the pace of the team, and as the original blogger wrote, a team that works well together can actually be far more effective than a single star player.

And this is where things get more messy, as either a Scrum Master or a Department Manager the goal is the long-term development of the team, I value all the team and I’d like to see everyone have the opportunity to develop and get better, a single star-player held back is bad, I don’t want to see that, but equally I am aware that an effective team can be amazing, and then again a dysfunctional team is a disaster. I want to grow and build a team that are greater than the sum of their parts not a group of individuals moving at the pace of the slowest.

So I find myself both agreeing and disagreeing with Laszlo, yes I want a group of the best engineers, but that isn’t going to happen, I don’t live in silicon valley and I don’t have that budget, and even if I did then I’d still prefer a great team of engineers. I believe that a team working well together can achieve far more and far better software than even ’10x’ individuals.

I aim to get that by hiring for the team. I will still aim to hire a team where they are smarter than me if I can but my primary goal is to find someone good that will enhance the existing team, that means I value the ability to communicate over their technical depth, I value their willingness to learn and to question over their certainty of their own knowledge, I value a desire to give customers what they want over a desire for a perfectly engineered solution. I suppose I am saying I value the team over individuals – even star players.

But I have a dark side too, anyone that is holding the team back needs to go, whether they are disruptive or not pulling their weight or simply because they don’t mix well with the others. I think we should be aggressive in hiring the best people for the team but equally aggressive in removing obstacles whatever form they take even if it means changing the make-up of the team.

I don’t want to close before addressing the other items on Laszlo’s list.  I want to voice my agreement over the other points,

* Take away managers’ power over employees

It really makes no sense to hire smart people and then tell them what to do, we hire smart people because they know more than us in their area of expertise – Let them use it!

* Only hire people who are smarter than you are, no matter how long it takes to find them

I agree with the caveat mentioned above, we don’t all have that luxury and for the most part it depends heavily on the next point.

* Pay unfairly (it’s more fair!)

Double what you are willing to pay and be selective. But don’t stop there! Retention is as important as recruitment, don’t lose someone good by being stingy, if you discover you have hired a star, give them a pay raise immediately, I can guarantee that when they go it will be for only 5%-10% more than you currently pay – don’t let that happen and offering to ‘match’ after they have one foot out of the door is far far too late. Let them know you value them now and make it hard for a competitor to lure them away.  Don’t worry if it upsets other people, if they know that reward is based on ability and performance they will respect it even if they don’t like it.

* Default to open: be transparent, and welcome feedback

I am a huge believer in transparency in development, so many projects fail because problems were hidden ignored or deferred or where customers were excluded until it was too late and too costly to change. Be honest and open and learn to see that finding a problem early is a good thing, even if you’d prefer not to hear it.

 * If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

This goes with the first point but let the team lead the way, they likely do know best, and make work a place they want to be, if a team of engineers is happy and enthusiastic you will see an amazing improvement. And trust them.

Trust the team

I shall add that as my own piece of advice for success with software development.  Trust the team, trust their judgement, trust their opinions, trust their concerns and trust that they will do the right thing. In my experience a good team will reward that trust ten-fold.

In my opinion if you cannot Trust your development team it is a failure of management as you have hired the wrong people.