Leadership and project management in a typical agile team

In my last article I claimed that you can have an agile project manager who ran agile projects.  But the projects I described did not involve “typical” agile teams.

So now I want to show that a project manager can work well with a typical agile team.

Read More »

True confessions. I was an agile project manager

I was once an agile project manager.  In fact I did it more than once.

If that is not shocking enough then maybe I should also confess that I have coached, trained and enabled others to be agile project managers.

In this article I will share my experience of being an agile PM without a real product owner or team facilitator (scrum master, kanban commander, iteration manager etc).  I think it worked out well, but I will let you be the judge.

Read More »

Which is more important: clear requirements at the start or good collaboration?

I have been struggling with how to improve our development team output lately. 

We have managed to get 20% to 40% faster with better quality over the last couple of quarters so I am pretty happy with that.  We have  flip-flopper (er experimented) with better requirements and modeling before a sprint or lighter up-front requirements with more time for collaboration and “OODA Cycles” within a sprint.

I asked the team what which we should do more of next, now that we have experience with different approaches that work for us.

This is what one of our scrum masters came back with:

Can I pick a 3rd choice, clarity in scope (which ties to requirements) before the start of the sprint.

It would be best if we would be able to understand the scope, clarify what needs to be delivered, and narrow down the scope should the scope be too huge as we have a dateline to hit.

Once the scope is clear and understood by the team, requirements would the fall into place, and the team can move forward quickly. However, collaboration during the sprint is still needed because there may be things that we somehow had not foreseen, and thus this would require the team and PO to work together to resolve certain issues.

I thought about my previous projects and realised that this is actually the essence of agile for me:

  1. Lock down a short period of time, clarify the scope you think you can probably do in that time and then let things fall into place. 
  2. Then realise that unexpectedly good and bad things will happen and rely on the collaboration of the team to get you the best outcome possible from there (rather than more advanced planning, more hours, better tools or other hoped for factors).

So I defer to my learned colleague on the subject of project management. I will get back to blogging on the dark arts of office politics for my next article.

The dark art of politics – do you need values or a brand to win battles?

Some people believe that if you are evil then you have no values and that you will be good at office politics, but that if you are good then you will have strong values and be really bad at office politics.

I believe that regardless of whether you are good or evil, you will be really stressed if you do not know your values and you will be really bad at office politics if you do not understand and manage your personal brand.

Read More »

The dark art of office politics for IT leaders (part one – why is it stressful?)

Apparently office politics is a horrible thing that other people do.

But many of the emerging IT leaders I speak to get told they need to be better at “soft skills” and “influencing at a senior level”.  What this often means is get good a politics.

Sadly a lot of office politics seems to involve people playing games to get their own way at the expense of everyone else. This skill can be learned and might seem useful, but it is not what I am going to talk about here.  I am going to talk about “how do the good guys get the right outcomes when people have competing interests or needs and some people seem like knob-heads”.

Read More »

Going live on agile projects – where is Machiavelli when you need him?

Niccolò Machiavelli is famous for saying things like:

“At this point one may note that men must be either pampered or annihilated. They avenge light offenses; they cannot avenge severe ones; hence, the harm one does to a man must be such as to obviate any fear of revenge”

I will let you be the judge of whether that is good advice for project managers, but he is certainly a source of inspiration if you want to set up your own crime gang or evil crew of super-heroes.

However, I do think some of the things that Machiavelli commented on are useful in modern projects.

One of his lesser know observations was on the difference between “Dukes and Courtiers”.

  • Each Prince, Machiavelli noted, is likely to have a bunch of Dukes and Courtiers reporting to him and these two roles are distinctly different.
  • Dukes run their own mini-fiefdom on behalf of the prince.  They make many day-to-day decisions and are in most ways mini-princes. In fact the duke will do well if he (or she I guess these days) sends in lots of taxes to the prince and generally maintains good order (and its probably best not to rebel or attack the Prince).
  • Courtiers hang out in the palace and join committees and according to the movies I have seen, they chat girls up and indulge in lots of politics. But they also provide direct advice to the prince and also work with him to run the complex day to day matters of the kingdom or principality. As far as I can tell they should be (less evil) versions or the characters in the TV series “The Tudors”.

So Machiavelli is probably a good source of inspiration for period pieces, but how does it apply to going live with an agile project?

Read More »

A prophets of doom workshop

In the past I have used some pretty dodgy approaches to defining risks in a project, from formal approaches like fault tree analysis through to informal approaches like “the evil genius” and “an international standard for being scared“.

So this article is not really a new one.  It is more a combination of evil geniuses and international standards for being scared.  But I think this workshop should work well when starting any project and particularly small projects with a simple project charter.

Read More »