allan kelly

For Agile on the Beach 2016 we had over 240 submissions. Thank you to everyone who submitted, I’m sorry we could have so few of you – 41 sessions if I remember correctly.

I find sending the “Sorry you weren’t accepted” mails the hardest part of organising Agile on the Beach. That is especially true when I know the speaker personally, or I want the topic, or I’ve seen the talk before and think it would be great. But in the end I only have the same voting power as the other five committee members.

And in the end, knowing that the decision on who to accept, and who not to, was not mine alone helps me get through the “Sorries.”

Each year I tell potential speakers: “If you would like feedback on why your session was not accepted please email me, I can’t promise detail feedback, or promise to do it promptly but I’ll do my best.”

After all Agile is about Feedback so why wouldn’t we do this?

Well, its a lot of work – about five hours I think. Because its a lot of work this year it has taken me nearly three months to find the time to do it but I have just sent the last feedback. Sometimes there isn’t much I can tell potential speakers, reviewers can add comments with their score but they don’t have to.

(If you submitted something to Agile on the Beach 2016 and I’ve missed your request, or only know decided you would like feedback then please e-mail me.)

Many of the reasons why sessions didn’t score highly crop up again and again so I thought it would be worth capturing them here in a blog. For anyone thinking of submitting to Agile on the Beach 2017, or another conference, these reasons might be useful.

By the way, I have another blog post about the Agile on the Beach voting process which should be read together with this one – or better still, before this one!

So, the common themes in the feedback I’m giving submitters are:

1. A lot of session were simply out competed: reviewers liked them but they liked other sessions more.
2. Some synopsis were to short, light on detail, little to engage the audience – and certainly the reviewer.
3. Some synopsis were too long, too much detail – indeed I remember some that went on and on. Clearly there is an art to getting something long enough to give detail but not so long the reader gets fed up reading it. (Remember reviewers may have 240 of these to read.)
4. Multiple submissions by one person is a high-risk strategy. If you are Adrian Howard or Seb Rose this is a high reward strategy, both of these speakers have in the past submitted strong proposals and the committee is left agonising about which one, or perhaps two, of the submissions we will have. Seb and Adrian changed the debate. But for most submitters reviewers notice multiple submissions and actively score one higher than the other. Unfortunately if another reviewer makes the opposite choice multiple submissions effectively split the speakers vote. So it is better to limit your number of submissions and play to your strengths.
5. Multiple submissions of the same synopsis with different travel expense expectations or co-speakers really annoyed the reviewers. For example, a couple of people submitted a talk with expenses set to “Worldwide” i.e. a long haul flight, and then submitted the same with “Local” or “Will pay my own long haul.” Reviewers felt these people were trying to game the system and marked them down.
6. Indeed, Worldwide travel, long-haul flights, always presents us with a problem because such speakers are more expensive for us. We can usually find the money for one or two such speakers but thats the limit. This year we provided the option for speakers who were prepared to pay their own long-haul flights and we have a couple of speakers doing this. While I accept this might not be fare it is hard to see how we can be completely fare given our economics.
7. Paid speakers: we don’t pay speaker for Agile on the Beach. We pay travel expenses but not speaking fees. If you are looking for a fee then please don’t submit.
8. Keynotes: we don’t do an open call for keynotes. We select the keynotes and invite them before we even open the call for papers usually.
9. Double sessions need to be twice as good: accepting a double displaces two single sessions which means we need to be convinced. Despite making extra space for doubles this feels like an inevitable problem because it is about timing. It isn’t really fair – some topics genuinely deserve more time, especially if they are interactive. Perhaps the best advice is: only submit a double if you have been the to conference before and committee members are likely to remember you as a good speaker. Giving a double to an unknown speaker is a big risk.
10. This year we had what seemed like a lot of submissions along the lines of “What Hiking taught me about Agile” or “Why paragliding is like software development.” While these are interesting metaphors none of the scored highly. In general I think such metaphors only work if the field is well know. And this year I for one got a bit fed up of reading yet another “Lessons from arctic exploration for Agilistas.”
11. ThoughtWorks: this is one of those “nice to have” problems but still a problem. We have a great relationship with ThoughtWorks – largely thanks to Jim Barritt and James Lewis who put us on the TW map and encourage a lot of TW people to attend. So we get a lot of strong proposals from Thought-Workers – after all TW only hire the best so we don’t get weak proposals from them. In 2015 we could have populated entire tracks with only TW consultants. They would be strong tracks but we don’t think that is good for conference variety. As a result submissions from TW consultants have to compete against each other in addition to competing with everyone else. Sorry guys.

By the way, we don’t do anonymous submissions, we, certainly myself, tend to believe the speaker, their background, name and experience is important. If we have been fortunate (or unfortunate) enough to see someone speak at a conference we take that into account. We also know there are many speakers we like to see return – and one or two who we don’t want to see again!

We have in the past been criticised for not including enough variety in our speakers, specifically: having too many men. Perhaps one reason for doing anonymous submissions would be to guard against this but actually, we don’t see this our problem. Or rather: yes we would like a better gender balance but when we’ve looked at the male/female ratio of other – comparable – conferences we’ve found we our balance is better than most. That is not a reason to rest on our laurels but it does imply its not a problem to us specifically.

One of the arguments that is made for manager-less teams runs something like this:

“Managers were useful when they were information hubs, when they heard company information, policy, direction, etc. and cascaded it down to their staff.

But in a world with e-mail, web, slack and a myriad of information systems there is no need for the role. Information can be directly communicated via modern tools to staff.”

This doesn’t actually hold up when you examine it:

1. Modern tools might allow mass communication but they also allow mass interruption. To communicate everything to everyone increases the information processing load on everyone. True, the information may be public but this has the cost of demanding everyone reads it.
2. Much information does not need communicating to everyone, to communicate it to everyone interrupts everyone.
3. Communicating a common message to everyone means that context is lost; information requires interpretation within local environment.
4. Without a common, shared, understanding of information then each individual can interpret the same information differently within their context. Remember: the meaning of any message is decided by the reader, not the writer.
5. Because modern tools lower the barriers – specifically cost – of communicating to many people more communication happens, but this increases the cost of receiving information because more people read the information and have to interpret it.

I could go on but you get the picture.

Let me suggest, that rather than removing the need for information hubs modern tools actually increase the need for information hubs. Far better for one person to read all the information, interpret it and pass on the useful stuff – within a context and perhaps in a timely but not disrupting fashion – than for everyone to undertake the same work and pay the price.

Such an information hub could be anyone, or at least, anyone who likes reading and communicating. But let me further suggest that this work, the information hub, is an example of management work.

Whether a commissioned manager or someone else does the work is another question.

But let me suggest further, than having someone with slightly elevated authority act in this capacity also makes sense. It makes sense because such a person can be privy to more information – yes I know we shouldn’t have secrets inside the company but they exist, some are even legally mandated.

Because such people have more authority they are also able to seek out – i.e. ask questions – which are missing from information.

In summary:

• Just because modern tools allow us to remove information hubs it may not make sense to.
• If there is going to be an information hub it may well make sense to give this person additional authority to go with their additional responsibility.

In response to one of my posts on management Sergey Timanin ‏tweeted:

“the work [of managers includes] steering the organisation in times of change might be the most invisible to tech people and most under appreciated”

I agree completely with Sergey, many of the changes in and around organizations are invisible to those doing the work. Indeed much, if not most, management work is invisible to those outside the management circle. Does that make it worthless?

Programmers often just want to get on with programming, nothing wrong with that. But sometimes there are changes swirling around, left unmanaged these changes have the potential to sow uncertainty, diminish trust and disrupt work.

In my nature of management post I noted that part of the management role is to interfaced the fuzzy, unknown, unpredicted (unpredictable) world to the very predictable world of machines. This is where Sergey’s observation fits in: the world out that is in a constant state of flux, allow too much of that flux into the work environment and well… you won’t get too much work done!

Managers are sometimes described as “Firewalls”. That is, they shield workers from interruptions and uncertainties that will disrupt their work. This can certainly be true.

But, for every programmer who values their manager as a firewall there is another who believes the manager is unnecessarily filtering – perhaps even controlling or hiding – the information which reaches them and that managers should get out the way and let the information flow direct. These people see managers not as Firewalls but as Gatekeepers who (unnecessarily) restrict the flow of information.

Its easy to see how these two points of view can be simultaneously held by two individual programmers about the same manager in the same company at the same time. One man’s protecting is another man’s hiding, the distinction between Firewall and Gatekeeper is subjective. This is where managers require skills and intuition, both to know what information to hide and what to share and how to communicate with different people with different expectations.

Sergey’s tweet also hints at something another responsibility which is often laid at managers door: that of bringing about change. Particularly being about change in the work environment.

Certainly I would see this as part of a managers role but actually, I would see this as part of everyones role. A good manager should encourage the change ideas of others and help them bring about changes they want to see.

While on occasion a manager may need to discourage – or even prohibit a proposed change – managers should have a role to play in bring about change for the better. However change is usually best when it is bottom-up rather than top-down. I would see a managers role more as fanning the flames of positive change and building momentum more than rolling-out a series of changes decided on in closed rooms.

Traditionally management’s role has been seen as one creating change below in order to satisfy the requests from above: top-down change with the manager as the instrument of delivery. Certainly that is sometimes true. Those who subscribe to view that strategy is planning, that strategy is decided at the top by big brains and passed down the organization would subscribe to that view.

But I don’t.

I believe some strategy is certainly decided at the top and “deployed” or “rolled out” down the organization but, actually, much strategy is bottom-up, it is emergent, it is the result of what happens on the ground, learning at the coal-face, and how this information is interpreted higher up.

Strategy is both emergent and in many cases retrospective. That is to say, strategy is a story we tell afterwards to make sense of what happened and to align future actions. In this case manager’s role is as much about telling stories and passing strategy up the hierarchy as down.

When I started writing my management blog series one reader expressed their hope that I would give advice on how to manage software development. I’m sorry, but this series has contained very little advice on how to manage software development.

There is a good reason for that: It is hard to give specific advice to managers.

You can’t say “If X happens then do Y”, you can’t even say “If you find yourself in situation A and then B happens then do C.” You can say such things in code, and you can say such things about coding. You can say such things about testing, you can often say such things about product management. But you can’t give such rules to managers, and if you did they would cause more harm than good.

There is a branch of philosophy and logic called contingency theory which talks of such situations. When a set of pre-conditions are satisfied then a certain action is “the right” thing to do.

The problem with managing is that it is difficult to give hard and fast rules, management is not contingent. What managers do, and what decisions they make – and don’t make – is very very dependent on context.

If you were to try and codify all the management actions and decisions you would need an incredible amount of detail and an incredible number of rules. Now computers are getting more powerful and the application of artificial intelligence may render some management decisions subject to contingency theory but for most humans such an approach to decision making is not possible.

And to complicate matters, even if you did have a decision making system much of the information managers have is incomplete or fuzzy, indeed, part of their job, their reason for existing, if to manage in when information is uncertain and the world is changing. (These same factors mean attempts at contingent management, like PRINCE2, are fundamentally misconceived.)

Hence intuition and understanding of context are important. Let me repeat a quote I used a couple of weeks back from Professor Henry Mintzberg:

“Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to manage; it depends on the situation.” Mintzberg, Simply Managing

Management is contextual not contingent, there are few, if any, hard rules.

Consequently I think the best advice I can give to managers, and soon to be managers, is:

• Understand your management philosophy. Understand what you believe, understand how you believe the world works. Your philosophy will inform your decision making.
• It is not enough to just understand ones own philosophy, one needs to continually reflect and build on ones own experiences.

Hence I have very little advice for managers. Well, actually… I do… my “failed” book, Xanpan 2, set out to try and decode many of the problems managers face in software development and build a practical guide to software managers. I was, perhaps, too ambitions. Xanpan 2 is available, as it stands it forms a wonderful appendix to Xanpan.

This is an important post. This is the ninth blog post in my mini-series on management, it is the blog post all the others have been building up to, let me recap some key points:

• When creating software there there is coding work, testing work, requirements work and some unavoidable management work
• Removing managers may remove some work (because managers make work for other managers) but there is still a residual amount of management work to do
• Management itself is a skill and requires intuition
• It takes an engineer to manage engineering; people without experience of doing software development are going to struggle
• Management decisions can make a big difference
• All who are called “Manager” are not managers, some are specialists
• There are many non-commissioned managers (NCO managers), those who manage without the title of “Manager”, frequently these people manage with minimal or little management

• Management work may be done by specific people, commissioned or non-commissioned managers, it may also be shared among team members

I’ve deliberately avoided discussion of self-organising or self-managing teams because these subjects deserve posts to themselves. The key point for me is:

• When decisions need to be taken they are best taken close to the point where they are needed
• When decisions are needed those who are staring directly at the decision are often the ones with the most knowledge about what is needed
• Taking decisions at the point the decision is needed also makes for a rapid decision
• It may make sense to get a second opinion, to talk through a decision with another person or in a team, and if the decision effects several people it probably makes sense to consult with them

One way to address these points is to use a self-managing/self-organising team and there are reasons why you might want to do that. But, that is not the only organization structure for satisfying these needs. The underlying principle is:

Devolve authority, pushing authority downwards, decentralise decision making

Whether you devolve to a team as a whole – as in the self-organizing/self-managing model – or to individuals, perhaps to NCOs the aim is to move the decision closer to the work.

Note: I’m avoiding the work empowerment, see my Stop empowering people – End disempowerment! post form last year.

Either way you do it, if you push authority down something else happens:

More people engage in management work

Yes, suddenly coders, testers and analysts who do not think of themselves as managers now need to make management decisions. Even if this is done in the setting of a self-managing/self-organising team management decisions are still being made. Indeed, if the whole team makes the decision they whole team is engaging in a little bit of management.

Everyone in the team starts to take on management attributes.

More importantly, More people need management skills, the whole team need some management skills and the intuition that makes a good manager a good manager.

Think about this for a moment.

Do team members want to go to meetings about management issues?

Do you C++ programmers want to engage in management?

If your Java programmers are now engaging in management where do they learn their management skills?

If your Testers are making on management decisions how do they develop their intuition?

If you accept that management work is a skill set in its own right, and you believe that more people should be involved in managing then you have to ask: how are these people going to learn management skills?

Then there is another side to this…

Talk to any manager about what they actually do, not what they would think they should do, or what they like to be doing but what they actually spend their days doing. You will hear them say things like:

• “I’m constantly fire fighting”
• “I’ve got tons of e-mail to answer”, “My phone is ringing all the time”
• “I never get to do strategy”, “I never get time to think or plan”

One of the characteristics of management work is that it is inherently interrupt driven. (If you don’t believe me go read Henry Mintzberg’s Simply Managing book I mentioned last time.)

So, by involving programmers, testers, analysts, etc. in management we are also opening these people up to interruptions. People will interrupt… well, potentially any team member!

Now if you are a programmer, tester, analysts or what-not please ask yourself: do I want to be interrupted? Am I willing to take the downside of management?

I’ve known plenty of programmers who would definitely answer “No!”

(There is a twist here, Mintzberg also suggests that managers choose to be interrupted. Which could imply that teams could choose not to inflict interruptions on team members but that is not entirely in the team’s gift. What Mintzberg doesn’t say how many of the interruptions would be avoidable? Do managers choose to be managers because they are interrupt driven in nature? – but we digress).

Lean folk will spot that there is a question of variance analysis here: management work has a greater variance than programming or testing and therefore needs to operate on a different cadence. The queues are different. From a lean point of view it makes sense to separate these two types of work because they have different variance and cadence.

Now here is a question.

If management requires skills and intuition (both of which need to be built in a person), and if doing management results in an interrupt driven work pattern then is management better:

a) Centralised in a few people who can be trained in the skills, who develop their intuition and who are tasked to handle interruptions, thereby leaving the majority of the team to focus on technical skills and un-interupted work (hopefully achieving flow)

b) Dispersed with everyone having some management skills (at the cost of technical skills) and some interruptions (at the cost of flow)

c) Other, please specify

For me the answer is (a) but…

If management is centralised it then becomes a question of how centralised? Over centralisation results in the model we see all too often with decisions delayed and taken by people with too little knowledge. The result is depressing and demotivating for those at the code-face.

But if management is organised as a hierarchy of managers then they make work for one another and some decisions end up traversing the hierarchy. So answer (a) is not perfect – this might be another example of dis-economies of scale.

Which brings me back to Non-commissioned managers: I would like to see more people with more management skills embedded closer to the work and working co-operatively within a team. An impure self-organising model if you like.

Any which way, there is no perfect answer. It is about balancing forces.

In my list of management work last week I left what some people will think of as a major omission: strategy and planning.

There is a school of thought that says that managers spend, or at least should spend, a lot of their time engaged in thinking big thoughts, having big discussions, creating company and product strategy. Sure thats why they need those big offices? Where else can they think deep and plan?

This school of thought would acknowledge that not all managers create strategy but since all managers think big thoughts those that don’t spend their time creating strategy are planning. Specifically they are planning how to implement the strategy set by more senior managers who do set strategy.

And since managers spend so much time planning they must also spend a lot of time communicating those plans – communicating downward that is. How else can you roll-out a strategy? How else do you implement a plan?

This school of thought is particularly powerful with people who aspire to be managers, people who want to be managers so they can think big thoughts, so they can step back and play a small part in the running of the world. Those who are fans of Michael Porter’s work on Strategy often subscribe, Porter sees strategy as conscious, inherently a top-down activity.

For those who hold this view is also follows that managers need authority: authority to decide the strategy, authority to tell others the strategy, authority to plan and authority to tell others to implement the plan they just made.

So why did I omit this important, and time consuming, aspect of management work?

I omitted it because this view of management is fantasy. It doesn’t exist.

Managers don’t spend their time planning and even fewer spend their time strategising. Sure many managers say they want to do this but very few ever find time. Thats why they feel compelled to create “offsite days” to plan and create strategy because day to day they are caught up in firefighting.

If you don’t believe me do and read the work of Henry Mintzberg, specifically read his book Managing, or the short version of the same book, Simply Managing. In these books he details his findings from following actual managers around and looking at what they do. He find they do very little planning and strategy.

Which is hardly surprising because in his earlier book Mintzberg demolished the idea of strategic planning: The Rise and Fall of Strategic Planning.

For software developers the story this book tells is oddly familiar, it starts with the idea that a strategic objective can be decided, that having decided the objective people (managers) can rationally decide what needs to be done to achieve the objective. They can then rationally allocate resources. The resources can then move them towards the objective. Sound familiar?

While Mintzberg agrees that organizations can have strategic objectives, and may even put in place plans to achieve them he shows that achieving the objectives is far from a rational planned activity. And, perhaps more important, strategy is not just a forward looking process (“We want to be the world leader in widgets!”) but an iterative process (“How can we increase our widget sales today?”) and backward looking, sense making (“Hay, our widgets are selling well, what did we do?”).

Most management work is far from planning and strategy creation. Most managers spend their days on administration, on working out problems, on applying their knowledge of a problem – a domain, solutions, history – to the problems they face today.

And if managers are spending their time engaged in strategy, planning and deep thinking then it follows that there is a lot less for them to communicate. And since the plans don’t exist there are no plans to deploy and no need for authority to order people implement plans.

Mintzberg also demolishes the idea that manager work hierarchically, that they need authority to do things. He shows how managers work without authority, they cut across hierarchy, and they work with their staff more than they direct their staff. Management is at least as much about persuasion as it is commanding.

Once you start to see managers as co-operative problem solvers they look much more like any other team member. Albeit one with some elevated status.

In fact, I’d go as far as to say: any manager who tries to work purely through authority is a) not going to be popular and b) find it hard to get things done.

Take away strategy formation, planning and roll-out from the work managers do and an awful lot of the power managers supposed have goes too.

In a software development teams an awful lot of this work can be push down to teams and the NCOs that work with the teams. Authority can be distributed to the people who closer to the problems, who need the authority.

Now perhaps it becomes easier to see managers as team members too.

It just so happens that their skills are a little different form other team members, their skills are more in administration, firefighting, working in ambiguous areas with limited knowledge and yes, to some degree organizing.

Continuing my discuss of management, broadly speaking my argument is:

There is management work to do – the same as there is coding, testing and customer understanding. To pretend there isn’t such work to do, that all software development might be reduced to rational engineering is naive.

Much of management work may be administration, we might be able reduce the amount of work, we might be able to delegate it or disperse it but there is still a rump of work to do.

A lot of management work involves decision making, and a lot of those decisions require authority.

So what is this work?

Here are some examples which I think are legitimate, possibly intrinsically, management work:

• Managing the client-supplier relationship: whether you sell your software product directly to customers or not your company will have suppliers (paper-clip vendors maybe) and customers/clients (well I hope you do, a few companies may have none but that is another problem).
• Managing expectations of stakeholders (with BAs, POs, etc.)
• Coaching staff
• Governance of work
• Information hub and firewall: information aggregation, filtering, dissemination
• Organizational structure: creating the environment for success
• Dealing with higher authority: for negotiation, for leveraging (unblocking)
• Finances: even in companies which have gone beyond-budgets there are still finances to “manage”, if anything a beyond-budgets approach will increase the amount of attention paid to finances
• and various administration issues

You do NOT have to have “manager” in your title to deal with these issues, these are examples of management work. You are a “manager” then you are more likely to deal with them – you might even attract such work.

This is not an exhaustive list — how can it be? – feel free to expand the list in the comments section below!

Some of these might be not be agreed by everyone. For example: should managers be information hub?

I’ve spoken to many developers who complain that their managers don’t tell them the full story, they selectively filter information, perhaps to retain their own power. But I’ve spoken to many, probably just as many, developers, who complain that their managers tell them too much, call them to pointless meetings to hear pointless messages.

And there are many who would argue that with modern technology (e-mail, mobile phones, etc.) that the information hub is redundant, after all messages can be communicated nearly instantly to everyone. But this cuts both ways. If message can be communicated instantly at very low cost it may well lead to more pointless messages and information overload.

So before anyone complains that they are not being told enough please check your mailbox, and mail filters, and ensure that you are not receiving too much communication.

Some of these items may be a sign of organizations in transitions from one organization style (maybe called traditional, top-down or hierarchical) to another (maybe called agile, self-organized, or holacracy). Such transitions don’t happen instantly or just because the CEO says “Lets be a holacracy”. And some organizations might simply want a little bit of “agile” in the software development teams in the basement but they don’t want self-organization anywhere else.

In any of these cases there will be management work dealing with the old-world and interfacing it to the new, and quite possibly expanding the new-world.

Some would even suggest that bring about such changes is itself management work and I don’t think I’d disagree.

Few managers will do all of the things I have listed and even fewer should do all these things! These are just a selection of the type of work I would expect to see managers doing.

What all these things have in common is they are nebulous, they deal with unknowns and unknown unknowns, they require working with incomplete information and they require a degree of intuition, some a little some a lot.

If these things weren’t ambiguous and nebulous then they could be formulated as a set of rational decisions, with known inputs and knowable options – as I described last time, lots of management work is about the fuzzy world out there. In so doing much of this work would move from the management space into the engineering space and might even, one day, be automated.

As time goes by we are finding ways to reformulate some of these issues so they can be tackled by engineers. And we are finding ways to reduce the ambiguity – the test driven techniques in Lean Startup are great examples.

Big data is another tool we are using to move decisions from the ambiguous space to the engineering/rational space. But, big data has a soft underbelly.

While this work rests in the ambiguous space then intuition is required to make decisions.

Keen eyed readers will have noted two omissions from the list and the discussion which followed. One I’ve ducked before: Leadership, the question of management leadership deserves a blog all of its own.

The second also deserves a blog all of its own: strategy. Many people have argued that one of the primary roles of management is to provide strategy, I’m not so sure. The full discussion will need to wait another blog.

I shouldn’t do this, it raises my blood pressure, I have better things to do, I have better things to blog about but I can’t help myself….

I made the mistake of opening a mail from a recruitment agent, the title: “Agile Project Manager/Scrum Master”, let me dissect it for you…

“My client based in the West Midlands are looking for an Agile Project Manager/Scrum Master for a long term project opportunity starting in May.”

Agile Project Manager/Scrum Master? – this is a pretty confused role, it is one thing or another, its one thing for a good project manager to act as a facilitator or for a Scrum Master to take on project responsibilities but to start out like this, well is just messed up.

Long term project? – there is no such thing, projects are temporary!

“The successful Agile Project Manager will be responsible for the planning, organising and managing of IT projects within this matrix resource environment. My client is looking for a technical Project Manager with strong experience in leading and managing multiple complex projects in agile environments. To be suitable you MUST have strong process and project management skills with experience in SCRUM.”

Planning, organising and managing of IT projects…? – what happened to self-organizing, empirical control?

And note “projects” not project (as it was before). Multiple project is a bad sign.

Matrix resource environment? – Matrix management, this organization has shot itself in the foot already.

Technical Project Manager? – so this person is a Scrum Master, a Project Manager and Technical, do they also make the tea and wash up?

And why all the SHOUTING? – Scrum is spelt Scrum, as in Rugby, it is not S.C.R.U.M. or SCRUM.

“As the Agile Project Manager/Agile Coach you will have ownership of the full life cycle project process, including the Software development lifecycle.”

Coach too? – as well as a Scrum Master, Project Manager and Technical? I’m not even complaining about the use of Agile and Scrum as if they a synonymous.

Ownership of the full life cycle… including the software development lifecycle, really? – except for the fact that the contract is for 6 months, the company is matrix managed, there are multiple projects and that some bastard hotchpotch process of SCRUM and traditional project management has been mandated.

In other words: you have as much ownership as a homeowner who’s house has just been repossessed by the bank.

Anyone taking this job would have their hands ties behind their back on day one.

“Key requirements:

• Demonstrable experience managing complex Projects in fully Agile environments
• SCRUM Master with previous experience of running Agile project teams
• Excellent presentation skills & competence in project management tools
• Full life cycle delivery experience
• Ensure all SCRUM ceremonies are adhered to throughout project lifecycle
• Collaborate with project teams (both on and offshore), create and maintain project plans and schedules”

Fully Agile environments don’t have projects, Scrum Masters don’t run Agile teams and “maintain project plans and schedules” sounds distinctly Gantt chart-ish.

Saying “all SCRUM ceremonies” sounds like the people doing the asking don’t actually know what the ceremonies are, just they must be “adhered to”. Anyway, Scrum isn’t a full lifecycle model so good luck here!

What is interesting here is what is not said:

• No mention of facilitation, unblocking, coaching
• No mention of technical skills (TDD, ATDD, BDD, refectoring, etc); this is supposed to be a “technical project manager”
• No mention of empirical process control or forecasting
• No mention of value
• No mention of prioritisation
• No mention of the Product Owner/BA/Product Manager

Normally I would be pleased that the recruiter wasn’t asking for a Scrum Master Certification, a Prince 2 certificate, or, heaven forbid, a “Agile Project Manager” qualification but on this occasion I read it more as a sign that the company doing the recruiting don’t actually know what they want.

Similarly, no mention of tools or technologies – Agile in PHP is very different Agile in embedded C, let alone the ERP Agile I’m working on now.

Finally,

“If you are interested to find out more, please reply…”

Should read:

If you are a traditional project manager (who used to code in the dim and distant past) but can’t get work now the world has gone agile, but think you know what agile is (mini-waterfalls) then please give me a ring, you probably know more than the people doing the interviewing anyway.

Bottom line:

1. Unfortunately this is the state of our industry, it is what many organization do and want. But it is far far from what the best teams do.
2. Don’t blame the recruiter, their industry is based on failure, most recruitment agents are failed real estate agents.
3. The organization requesting this role have such a poor understanding of what they need they shouldn’t actually be allowed to hire anyone.