How Project Managers and Technical Leads compliment each other


For new practitioners of Scrum and other agile methodologies, it is tempting to think of the scrum team as operating in some kind of Nirvana where the team works in isolation constantly producing value.

This is never the case. As far as businesses go, the scrum team is still part of the business and needs to be in alignment with the greater goals of the organisation.

To this end, most teams have some kind of project management and technical lead roles.

Understanding the difference between this roles even if you don’t have individuals exclusively assigned to them is critical for smooth relations and alignment of project goals and organisational goals.

What does a Project Manager do?

The PM acts as the interface between the team and the outside world. She has responsibilities to all stakeholders to ensure their interests are served.

To the leadership, she acts as an advocate of the team ensuring that the team’s interests are adequately represented.

While XP, an agile methodology insists that a member of the customer’s team must always be available to act as the Product Owner, this is not always possible in practice. In such cases, the PM helps explore the product owner’s conditions of satisfaction. These include the usual items—scope, schedule, budget, and quality.

In the course of the project, the PM will be expected to provide the development team with all the resources they need to get their work done. This includes physical items such as laptops whiteboards etc and enabling environment such as protecting the team from requests in the middle of the sprint. She will also be expected to provide progress reports during the sprint to the stakeholders as required.

The PM need not be technically savvy but she must have strong collaborative skills.

In a scrum team, the scrum master can take on this role.

What does a Technical Lead to?

The TL is in charge of the technical output of a single team. He is in charge of operational excellence. That is, he ensures the team produces high-quality products with high rates of productivity while meeting target costs and dates.

Typically he is a senior engineer who has the respect of the rest of the team members.

He will actively write code along with the rest of the team while simultaneously reviewing their code to ensure quality and provide pointers as to how the developers can grow. The TL will be the one tasked with leading code reviews.

Where the whole team can not attend, the TL will represent them on estimation meetings. He will be best suited to appropriately break down the client’s requirements into epics and give a rough estimate. It is, however, important that the final commitment comes from the entire development team.

The TL will typically be in charge of the architecture of the application being built. This means that in addition to leading design meetings, he should be able to provide feedback on the ramifications of individual developers commits on the rest of the system.


In teams where the roles are clear, development goes smoothly and the individuals in charge of the roles complement each other avoiding responsibility overlaps and vacuums.

Do you have a clear separation of the roles and duties of PMs and TLs in your own organisation? Talk to me in the comment section below or on my twitter @jchex


Factors in selecting iteration length


Development in Scrum happens with iterations or sprints. An iteration is a time-boxed period within which development is done. During an iteration, the team transforms one or more imprecise requirements statements into coded, tested, and potentially shippable software

Iterations are a core part of Scrum. They allow for the development team to quickly converge towards building what is of most value to the customers.

The iteration length is typically 2 – 4 weeks. This is not a hard figure. Some teams have iterations that are as short as 1 week and others have 8 weeks sprints!

In this entry, we will be discussing some of the factors that lead to variability in iteration length and what you should be considering as you are deciding on your own iteration length.

Length of the project

Projects tend to vary in length. I have worked on projects that lasted only a month and some multi-year.

Longer projects offer the luxury of a window of correction. That is if after the end of an iteration the client discovers what was built is not what they expected, there are a number of other sprints that are available to the team to correct the issue. Shorter term projects lack this kind of luxury.

Thus the length of a project acts as an important factor in choosing sprint duration. The longer the project length, the longer the sprint length you can afford have. In fact, if you already know how many reviews you want to have, you can derive the length as follows:

    Duration of sprint in weeks = Total project length in weeks / number of reviews

For example, if the project is 2 months and you want at least 4 reviews then the duration of the sprint will be

    Duration of sprint in weeks = 8 weeks / 4 = 2 weeks

In addition to allowing for more review periods, longer projects can also more easily afford the “costs of iteration”. The costs of iteration refer to the extra time used to facilitate iterative development. This would include such things as:

  • Iteration planning
  • Retrospectives
  • QA
  • Convergence

This means that for longer term projects, you can afford longer iterations and associated time costs. For very short projects, the costs can also influence the length since you don’t want to spend all your precious development time on this supporting activities.

Clarity on product and team

Some projects are simple even if they are not easy. This means that it is easy to communicate what is required and changes are not likely to come during the development phase. These kinds of projects are very rare to come across, most projects are messy especially at the beginning.

Thankfully Scrum thrives in the kind of complex projects that exist in the real world. It does this by ruthless application of Palchinsky principles.

    First, seek out new ideas and try new things; second, when trying something new, do it on a scale where failure is survivable; third, seek out feedback and learn from your mistakes as you go along.

You see, iterative and incremental development is about generating feedback, learning from it, and then adapting what we are building and how we are building it. Sprints provide teams with the mechanisms for doing this.

Thus the more uncertainty you have in your project, the shorter the sprint should be.

Uncertainty tends to come in two distinct flavours. First one is, what are we building?. This is the product question and relates to meeting the client’s conditions of satisfaction. The second one is, how are we going to build it?. This relates to the team’s development practises. You may, for example, want to run short sprints at first both to quickly show the client what the product will look like and establish the team velocity.

Since for highly uncertain projects the priorities change quickly, shorter iterations ensure that what you are currently working on is what is most important.

Stakeholder availability

At the end of the sprint, the development team needs to do a demo to the stakeholders. Your stakeholders maybe extremely busy or important individuals whose time is hard to secure. In this cases, it may be wise to plan your sprints according to their schedule.

For example, if the executive team meets once every month, it may make sense to schedule your sprints so that a demo day falls on that day. This way the hard work of convening all of them is already done for you.

You, of course, don’t want to vary sprint length from sprint to sprint. Thus you don’t want to unduly sacrifice your process in service of the demo day unless a good synchronisation opportunity exists.

Stress levels

What iteration do you think induces more stress, 2-week or 4-week iteration?

I have asked this question to a good number of my friends, the answer is almost always 2 weeks. They are wrong.

It may not seem like it, but longer iterations tend to induce more stress than shorter ones. This is because longer iterations have well defined, beginning, middle and ending points. Naturally, the team is a bit more laid-back at the beginning and gets more stressed as the deadline approaches.

Shorter iterations smooth out this effect, the team can then settle into a manageable tempo.

See this masterful piece by Tim Urban

How do you select iteration length in your own organisation? Talk to me in the comment section below or on my twitter @ jchex