According to Wikipedia leadership has been described as the “process of social influence in which one person can enlist the aid and support of others in the accomplishment of a common task”. A definition more inclusive of followers comes from Alan Keith of Genentech who said “leadership is ultimately about creating a way for people to contribute to making something extraordinary happen.”

Leadership is about influencing people in order to reach goals. It is also about coaching and motivating people so that they can give their best and reach a goal as a team. Leadership can be described many ways, but one thing is sure. Leadership skills are in the core of project management skills. Project management is leading people.

Leadership skills become important when project team faces conflicts or changes, or when difficult decisions must be made. In order to lead a team a project manager must gain respect and appreciation. Without authority project managers does not have much chances to survive in a difficult or pressurized situation. Authority and respect must be earned, and one’s preferred leadership style plays here an important role.

People have different leadership styles, and different leadership styles work in different situations. Although project manager should select the best matching leadership style to a certain situation, his/her personality contains certain dominating leadership styles. Check the table below and think what is your preferred leadership style? With which behaviors you are doing well and with which behaviors you need to develop? Leadership style includes behavior, communication, attitudes, decision making processes, delegating, etc.

The following table is used in IPMA C certification.

Looks scary? Don’t worry, nobody is perfect. We all can find ourselves in both sides, although everybody’s wish is to stay more on the right side. It is important for a project manager to recognize own preferred leadership style and weaknesses, and by that start improving.

I have seen similar mistakes repeating in many projects, and one of those is the lack of continuous integration and testing. A while ago I discussed about the problem of late integration and tests, and actually these following practices help removing the problem. So, if you think you are having quality problems in your project, consider utilizing these practices.

Test Driven Requirements

Tet Driven Requirements is a practice that calls for the customer to provide requirements in an unambiguous format, such as acceptance tests. This not a one-time practice, but repeated in the beginning of each iteration or sprint. The benefit of Test Driven Requirements is that it drives the system architecture to right direction. Unlike waterfall processes it also helps focusing on the most important in the iteration or sprint, because developers build only what is required.

In order to get Test Driven Requirements happen you need customer representative in your project team, and naturally he/she must be willing and competent enough to develop Test Driven Requirements.

Test Driven Development

Test Driven Development is much like the previous practice, but the focus in this case is in creation of automated developer tests. The basic idea is to first write a test case  for a requirement and then implement the requirement. In XP a test case is understood as a requirements, but many people are still used to differentiate requirements and test cases.

Tehe benefit of Test Driven Development is that it produces loosely-coupled designs which are easy to maintain, reduces defect counts and enables building only what is needed.

It is not easy to get your team practicing Test Driven Development if they have never done it before. You are quickly faced with high resistance because so many developers are strongly used to go straight into coding phase. It is best to have an experienced Test Driven Development mentor or consultant to help applying Test Driven Development. If you succeed, you definitely see the results. Test Driven Development is something I always emphasize because I have seen it pays back.

Continuous Refactoring

Refactoring could be understood like “cleaning up” the code but not totally redesigning. Refactoring changes the structure of the code and aims in better design. Continuous refactoring during iterations or sprints leads to incremental improvements of the products, which again leads to higher quality. Without continuous refactoring the design can degrade over time, which usually leads to difficulties in code maintenance and fixes.

Refactoring should be done in every iteration of sprint before checking in to version control. Project manager should arrange time for continuous refactoring by emphasizing the meaning and importance of refactoring from quality perspective.

Automated Unit Regression Tests

Unit tests are pieces of code that validate implementation, and in most cases unit tests are automated. Unit tests are done by developers, and a set of unit tests form so called unit level regression test suite. This regression test suite is automatically or manually executed right after an automated or manual build process has completed.

One of the biggest benefits of Automated Unit Regression Tests is that bugs are found very early during development. Another great benefit of (any) regression test suite is that team can verify that latest changes did not break existing functionality. Certainly I have to point out that no test suite is able to verify 100%, so by building, maintaining and executing Unit Regression Test suite team can lower the risk of serious defects in the end of a project.

It is important to notice that building an Automated Unit Regression Test suite takes time and requires discipline. Project manager should emphasize the importance of unit tests and encourage team members to keep on building the test suite.

Automated Acceptance Tests

Automate Acceptance Tests are written in the beginning of the iretation or sprint. These tests basically answer the question “What will this requirement look like when it has been implemented?”. Execution of the test case typically fails several times during development, but when it passes, in theory no more development is needed.

Just like the automated unit tests, also Automated Acceptance tests are gathered into a regression test suite. They provide similar benefits, such as early defect detection and higher quality. The difference is that Automated Acceptance tests are built on different level where focus is different from unit level tests.

One of the persuasion tactics Robert B. Cialdini describes is “rejection-the-retreat“, which shortly means “ask extremely much and finally receive what you really need”. Although most of the persuasion tactics are used in marketing and sales, can some of them be applied also in project management. I believe “rejection-then-retreat” tactic fits perfectly well in the toolbox of a project manager.

Estimate what you need and then ask a lot more

I used to plan my projects in optimum way, and after several missed deadlines and milestones I had to figure out a better tactic. I started using a risk buffer. I multiplied all my time estimates by two and later by three, but soon I realized it does not make sense because also the non-risky tasks are multiplied. Next I tried to multiply only the risky ones, but my plan became a chaos..

Few years ago I had a subcontractor who by accident told me that they multiply all their optimal time schedules by seven. At that moment I understood why they had been so expensive. Also I realized that it was risky for them to work with us..

So, why am I talking about time estimates in relation to “rejection-then-retreat”? There are similarities. With a project plan (talking only about time schedule) I ask resources from line management. I know big up-front plans and milestones do not exist in agile projects, but in traditional “old fashioned” industries such as factory automation this kind of plans and milestones are an every day life. So when I go and ask for resources from lines management, I must show my plan with time and resource estimates.

If I show my optimal plan, I most probably get 80% of the resources I need, but sometimes even 100%. Unfortunately software projects are impossible to predict and plan 100%, so most probably my optimal plan fails. Therefore I need to ask more than I need in order to get what I actually need, and by adding this buffer to my project plan I can do this. Does this make sense? Well, If your project is successful after resourcing like this, then I would say yes. Now the trick is to ask a lot more than needed in order to get what is actually needed. All right, but what is the theory behind this?

Let’s see what Mr. Cialdini says.

Suppose you want me to agree to a certain request. One way to increase the chances that I will comply is first to make a larger request of me, one that I will most likely turn down. Then, after I have refused, you make the smaller request that you were really interested in all along. Provided that you structured your request skillfully, I should view your second request as a concession to me and should feel inclined to respond with a concession of my own – compliance with your second request.

A true story of rejection from Calvin and Hobbes

Calvin: Mom, can I set fire to my bed mattress?

Mom: No, Calvin.

Calvin: Can I ride my tricycle on the roof?

Mom: No, Calvin.

Calvin: Then can I have a cookie?

Mom: No, Calvin.

Calvin: She’s on to me.

Shortly said, plan and estimate your resource needs first. Add some risk buffer as you know optimal plans never work. Then multiply your plan by five or what ever figure you see the best. Next walk to you manager’s room and proudly present your plan and resource needs. You most probably will drive him/her nuts, and your request will most probably get rejected. Then make your concession and come up with smaller request that is closer to your real needs. Now you should get what you need. Walk away and be happy.

This is 50% serious, 50% joke. You know what I mean.

Imagine a 1-2 years long project with huge up-front specification phase, loooong development phase, and finally a busy integration and system test phase. All this is planned on MS Project chart, requirements are frozen, hundreds of pages long specs have been written and signed off long time ago, and so on. This is a classic project managed with waterfall model.

Management and project leader have agreed that development team creates a system defined in the specs, and all stakeholders are waiting for the delivery. People change their thoughts of things by sending email. Sometimes they talk about the project in front of coffee machine, but most of the discussion is done in emails. Time goes on, and one day project manager realizes that he/she is in trouble. Time has come. System must be integrated and tested before delivery.

“Houston, we have a problem“.

Why late integration and test can cause a big trouble?

Once a colleague told me “in my next project I will make sure ALL requirements are found, and after that I will drop them one by one to a huge MS project plan in order to make sure nothing goes wrong and nothing gets forgotten in my project“. I replied, “you know what? It won’t work. You won’t succeed. Just welcome change and use adaptive planning“. He didn’t understand, and kept on repeating his idea..

Shortly said, the problems have been there but nobody has noticed them. Integration activities finally force the team to face the problems that should have been fixed long time before. For example during integration huge amounts of interface problems show up, and much refactoring and recoding is needed. There are fundamental misunderstandings, wrong assumptions, communication gaps, blaming and a chaos. Project runs in crisis mode and steering group takes the lead. What’s the problem?

The problem is that applying waterfall model to software project, which is always new product development, does not work. Software projects are inventive, and because of that predictive planning is not possible. In big software projects things change, and therefore creating big up-front specs and plans fail. Such predictive planning doesn’t welcome change, and it is rather unrealistic and risky.

When predictive planning and waterfall model is used, integration and test is usually planned in the end of the project. Software developers need feedback from testing in order to clarify requirements and develop code that fulfills the requirements. If integration and testing is done after months of coding, it is obvious that problems show up, and usually there is no time to fix the problems. For some reason waterfall based plans typically include delivery right after system tests.

How the problem could be fixed?

Iterative and agile processes apply adaptive and continuous planning. After initial planning and staging phase team starts 2-4 weeks long sprints that include continuous integration and tests. In fact XP process requires daily builds and automated regression tests, which is very much different from waterfall approach.

By combining agile or iterative process and risk-driven project planning we can pretty well avoid the problem of late integration and test.

How do you see this? Do you different experiences or thoughts about the problem of late integration and test?

Photo: certified_su

Risk-driven project planning – Mitigating risks first

In risk-driven project planning we focus on working the most risky items first. In sprint planning or iteration planning sessions team identifies the most risky requirements or the most difficult architectural solutions, and prioritizes them by voting. Highest priority tasks are dropped into sprint one, next ones to sprint two, etc. After the planning session project manager should have a release plan with highest risk items in the first sprints.

The idea behind risk-driven planning is to make sure the most difficult or highest risk requirements get done as soon as possible. There can be many reasons to use risk-driven approach in project management, but one example could be launching a new weather forecasting system with recently developed algorithm. In order to capture market share and attention development team focuses on implementing and testing the risky algorithm first instead of fancy and intuitive user interface.

Client-driven project planning – Highest business value first

In client-driven project planning we let client sit behind the steering wheel. In practice the client prioritizes requirements and decides the order in which they get implemented. Whatever the reasons are, client gets what they perceive as the highest business value, as soon as possible. In software development projects requirements tend to change, so in agile and iterative projects client-driven project planning gives client several chances to redefine their priorities.

The idea behind client-driven planning is to make sure the highest priority requirements from client’s perspective get done as soon as possible. Again there can be many reasons to use client-driven approach, but for example in case of the weather forecasting system customer knows that market is especially interested in fancy and intuitive user interface, it makes sense to implement requirements in the order client wants.

Best solution is to use both risk-driven and client-driven project planning

Although compromises do not always work, I believe a combination of risk-driven and client-driven project planning is the best solution in most cases. In pure risk-driven approach meaningful market requirements might not be noticed because development team does not understand client’s market. Also in pure client-driven approach it is possible to miss important requirements from architectural or design point of view. Therefore I recommend having both team and client representative in project, sprint or iteration planning meetings in order to plan together with risk-driven and client-driven approaches in mind.

Photo: perhapstoopink

I have no definite answer to my question above, but I believe the reason is that in many technology companies management compares software development to assembly lines or factory work. Imagine you have a car factory and your job is to plan of project of creating 500 new cars. You have a long list of various activities needed in order to build a car. Those activities include assembling components that have been developed and tested many times before. All you need to do is to pick up the needed activities, put them on time line and calculate how much time is needed to complete the job. Mass manufacturing is predictable manufacturing.

Software development is far from that example. Even though there are components also in software development, but unlike car factories software projects always include new design and coding or tailoring of old software. Therefore software development is always new product development, and because of that software development projects are very difficult to estimate. Software projects are inventive projects that are difficult to predict.

In predictable manufacturing it is possible to first complete specifications and then build the product. In new product development it is rarely possible to create unchanging and detailed specifications. In predictable manufacturing one can estimate effort and cost near the start, while in new product development estimations can be done step by step as empirical data emerges.In predictable manufacturing it is possible to identify, define and order the needed activities, but in new product development also this must be done in steps as feedback is gathered from build cycles.

In addition to the nature of software development, we must take into account the added complexity from third party components that can sometimes be even more buggy that our own product.

Based on above, I believe many companies keep on leading their software projects with “waterfall style”. Instead of realizing this mismatch and changing their development process they keep on requiring big up-front specs, and detailed plans and estimates. Even usage of project charter can feed this mismatch, although it absolutely should not.

We should understand that building software always includes high change rates, and therefore applying “waterfall style” predictable manufacturing process is not beneficial. One solution I recommend is agile project management.

Photo Jazi

1# Stakeholders are like shareholders

2# PMP exam – 10 frequently asked questions

3# Team building tips for project managers

4# The value of lessons learned

5# When should you implement Scrum or agile?

6# Interview with Chuck Pearson

7# Podcast: Schedule killers – Bad multitasking

8# A brief introduction to PRINCE2

9# Do something S.P.E.C.I.A.L.!

10# The big picture of enterprise agility

Bonus link: Ssssh… Agile is all about micromanaging

Photo: Tennessee Wanderer

• daily stand-up meetings
• frequent communication
• self-organizing teams
• short iterations
• etc.

There are many ways to describe agile project management, but what it actually is? What agile project manager does in practice? Jim Highsmith (founder of Agile Alliance) has summarized nice principles for agile project manager.

1. Deliver something useful to the client
2. cultivate committed stakeholders
3. Employ a leadership-collaboration style
4. Build competent, collaborative teams
5. Enable team decision making
6. Use short timeboxed iterations to quickly deliver features
7. Encourage adaptability
8. Champion technical excellence
9. Focus on delivery activities, not process-compliance activities

Mr. Highsmith’s Nine principles for agile project manager pretty well describe what an agile project manager does in practice, but let’s take a closer look on each principle.

Deliver something useful to the client

As an agile project manager, your job is to provide value to customer. In order to do that, you need to understand what customer values. Some folks simplify this by stating “focus on coding, forget documentation”. Although in most cases customer values a functioning software, some customer actually value documentation. Focus on providing what customer values. If it is a functioning software, lead your team to create such instead of focusing on planning and documentation, for example.

Cultivate committed stakeholders

Are you frustrated with “lazy” stakeholders who only seem to focus on sending emails? If yes, cultivate them. Your job is to cultivate or activate stakeholders. Take them with you when planning your sprint, assign them tasks, require, ask and demand. Keep them alive and kicking! In most cases you just need to stand up, walk to the person, show what you need from him/her, set a deadline together, and follow up his/her progress.

Employ a leadership-collaboration style

Agile project managers don’t give orders. Instead they facilitate, coach, provide resources, maintain vision, promote agile principles, remove obstacles, keep skeptics away, etc. If you have never acted as an agile project manager, you might need some time and few projects to learn to your new role. Collaborative leadership differs much from traditional “leader-employee” style.

Build competent, collaborative teams

Agile project teams are self-organizing, and self-organizing teams require more from team members than a traditional “leader says what to do”-team. You need competent, active, adaptive and committed team members, and one of the best ways to get such a team is to continuously build the competence and collaboration of team members. There are many ways to do this. Anyhow, your goal is to have a team of very competent people who actively collaborate with each other and possible external stakeholders.

Enable team decision making

It might be surprising for many, but agile project managers don’t actually set rules and responsibilities and give orders. Instead the self-organizing team itself makes decisions within the boundaries set by the project manager. As a project manager your ob is to facilitate, coach, motivate and remove obstacles. Anyhow, I must say point out that this kind of set up does not usually exist, because of many reasons. One good reason is that many times project manager understands the agile world, but line management and team does not. In that kind of situation it is very difficult to create team based decision making, so some kind of “middle-level” solution could work better.

Use short timeboxed iterations to quickly deliver features

Scrum sprints are usually timeboxed to 2 weeks or 4 weeks, and in the end of a sprint product is delivered. Sprint length doesn’t always need to be the same, but the important point is to keep sprints or iterations truly timeboxed. This means no time schedule slippage. If team cannot get everything done, sprint or iteration scope can be changed, but time schedule not. Timeboxed approach forces to faster and more effective working, which again leads to shorter projects.

Encourage adaptability

Software development is always new product development (I’ll explain in later articles). Software development team sails in the sea of constant changes, while project manager stands behind the steering helm (or steering wheel). Software projects evolve, so don’t even try to fight against the nature of software projects. Instead encourage adaptability, which in practice means reactive planning, adapting to new and changing requirements, quick decision making, etc. Talk about the nature of software projects, and encourage people to adapt with changing environment.

Champion technical excellence

In most projects you need gurus who master certain technical skills, frameworks, tools, etc. Encourage people to use part of their time with learning, testing new techniques, collaborating and sharing their knowledge, planning their career as technical experts, etc. If you manage to create a positive and continues spiral of learning, you are sailing good waters.

Focus on delivery activities, not process-compliance activities

Have you seen MS Project charts that clearly follow company processes? If yes, have you ever seen MS Project charts that clearly follow company processes AND are always up to date? I have not. Therefore I strongly recommend focusing on delivery activities instead of maintaining your MS Project plan and trying to lead your team by giving tasks or work orders. Together with your team, sit down twice a week to brainstorm activities that are needed in order to deliver the product. Maintain those activities in your Scrum backlog and follow the progress daily. Ask your team, “is this all we need to do in order to deliver by the end of the sprint, or are there other activities that we haven’t recognized yet?“.

“No, we don’t anymore run our projects with waterfall process. Actually we apply iterative methods, such as RUP (Rational Unified Process) and Evo (Evolutionary Process). In this current project we have been analyzing our requirements for the last few weeks, and as soon as our requirements are frozen, we’ll start our first iteration. Our system test phase is scheduled in six months, so we gotta hurry up..”.

What is wrong with that typical scenario? I have heard it many times, and I can quickly tell you what is wrong with it, but let’s think about it a little more.

Waterfall process was the first step towards structured projects

The problem with the scenario above is that the person talks about applying iterative processes in project management, but in practice the project is managed in waterfall fashion. You can clearly notice the phases, such as requirements analysis, development and system tests. The person clearly knows something about iterative processes, but still keeps on leading his project with waterfall style.

Waterfall process is a sequential process. In its most simple example, waterfall process includes a number of separated phases connected from beginning to the end. Those separated phases are

1. Requirements gathering and analysis
2. Software architecture and design creation
3. Implementation (programming)
4. Integrating and testing, and finally delivery

Basically the product should be ready after step four has been completed. Anyhow, it usually does not really work like that. Waterfall process was invented during the ad-hoc style hacking of 1960’s. It was the first step towards structured software development. I bet introducing waterfall process actually caused more harm than good, because running big projects with waterfall process increases risks and lowers productivity.

The interesting dilemma is that waterfall process is probably used because it is easy to manage, while it is unsuitable for complex projects. You probably did not know that the founder of waterfall process (Winston Royce) has said that waterfall process was only applicable for the most straightforward projects. Software development projects do not belong to that category.

Have you noticed that in waterfall projects difficulties tend to gather to the end of the project? It is the nature of waterfall process to push risky elements toward the end of a project, while iterative methods aim in resolving the hardest and riskiest elements early. Probably one the most annoying thing with waterfall process is the large steps with overwhelming degrees of complexity.

Iterative projects should not be executed waterfall style

Although it is clear that iterative processes provide better results in software development, many managers and organizations still require project to develop software in waterfall style. May be the reason is that these managers studied their diplomas during 1970’s, and they have missed the iterative train long time ago. It is totally understandable.

While waterfall projects contain higher risks, iterative projects contain lower risks. This is due to many reasons, but one reason is that risk-driven iterative projects discover and mitigate risks very early. In iterative projects tasks are continuously prioritized, and because of that the riskiest problems are addressed first.

Iterative processes can be managed with waterfall style, but that does not really make sense. Therefore projects managers leading iterative projects should make sure they really understand how iterative processes work. Leading an iterative project is usually a bit more difficult than leading a waterfall project, even though waterfall projects tend to have serious problems. If you are not familiar with iterative processes, check these books in order to learn more.

• Mary Poppendiek – Lean Software Development
• Mary Poppendiek – Implementing Lean Software Development: From Concept to Cash
• Alistair Cockburn – Agile Software Development

By the way, whenever someone in your project talks about signing off a requirements specification, or freezing the requirements in order to avoid changes, you know it is time to suggest the person the books listed above.