Collaboration – a team of Project Managers?

What happens to an Agile Transformation when new people are recruited into the company in senior positions? Well, obviously it depends on the people and the positions they occupy, but it can be quite disruptive. Here’s an example:

One company I know of has committed to changing their working culture and are adopting DSDM as their Agile method of choice. But in order to change, new people were brought in. Among them, a new Head of IT, and a Portfolio Manager. Neither were experienced in Agile methods or techniques and neither were familiar with the ethos, values and principles of Agile either. One of the first changes seen was that the project managers were moved from their desks scattered around the building (although mainly on one floor) to one room around the Portfolio Manager himself. So who benefited from that?

If we consider the project manager’s role, which is mainly outward-facing, it shouldn’t have been too big a problem, since the Team Leader (equivalent to a Scrum Master) would still be sitting with the team. But not all teams were big enough to warrant a Team Leader, but a Project Manager was still assigned, and playing both the PM and Team Leader roles. For them, it was a bigger problem.

Seating the PM with his/her team means that any impediments the team encounter, any difficulties they experience can be immediately understood and dealt with. The PM can stay abreast of changing circumstances and understand what’s really going on inside the team, to the benefit of the team and therefore the organisation as a whole. 

Seating the PMs together with the Portfolio Manager means the PM can provide information to the Portfolio Manager more quickly, but now has less interaction with his/her team and so has less to communicate. This situation benefits only the Portfolio Manager, and even then not very much, because the quality and detail of any communication is reduced. But what message does this send to the team members? That you don’t need your manager close to you? That he/she is somehow ‘special’? That he/she is more important or part of a different team?

None of those messages is very positive or helpful. Since the Project Managers do not collaborate on a daily basis – they work on different things – there is little point seating them together. Seat them where they can support their teams.

Posted in Uncategorized | Leave a comment

Agile – one size fits all?

Almost every day I read about doing agile ‘properly’. Some people are asking what is the right way to do something, others (including me, it has to be said) are giving their views on what works for them. For someone new to agile – perhaps considering adopting it in their workplace – it is potentially very off-putting, as it may give the impression that we agilists actually can’t agree on what’s right and what isn’t; that agile is actually just a bunch of techy geeks making it up as they go along in ill-disciplined fashion. But that’s not true.

Continue reading

Posted in Agile | Tagged , , , | Leave a comment

Principles of Agile Governance

I first wrote about governance of Agile projects three years ago, when I was developing a governance approach at a DSDM development site. That work, and the work I have done elsewhere since, have further convinced me of the basic ‘correctness’ of that theory. I presented that theory at the Agile Business Conference that same year to a very interested audience.

Fast-forward to the present day and I was recently invited to attend a meeting of the APM Special Interest Group (SIG) on Agile Governance. The APM are working on a Guide on this topic and are keen to elicit opinion and insight from far and wide. When the meeting broke up into break-out groups, I attended the one focussing on the Principles – the one where I thought I could be most helpful. The principles I put forward are what I believe to be some of the guiding principles by which an Agile governance authority – however that is manifested in your organisation (perhaps the PMO, perhaps a separate body) – ought to run the portfolio of projects. They are, in no particular order :

  • People and accountability. Good governance comes from having the right people accountable for delivery, and the quality of the solution delivered. I have blogged before about the need to have the companies Security Officer (or equivalent) responsible for application security and to be accountable for the security of any application development being implemented. Similarly, Marketing should be accountable for the look-and-feel of a web-site development. And the Governance Authority should be people who have no vested interest in the outcome of the project – but they are accountable only for ensuring that it is conducted properly. If, for example, the person responsible for managing the governance process is accountable to the Head of delivery, governance will achieve only what is in the best interests of the Head of delivery. If he/she is paid to deliver more projects, then more projects will go live, even bad ones.
  • Ensure projects are adequately resourced. No project should start unless it has the resources (people, knowledge, skills, tools, equipment, etc) to ensure at least a realistic chance of success. There are no guarantees in life, but every project needs to be given every chance to succeed, and starting a project with only half the people it needs – or with poor equipment, a lack of meeting space, or anything else a successful project needs – is the road to failure.
  • Scale the governance to the project/programme. Avoid unnecessary bureaucracy, but ensure the project is under control. Good agile governance should promote agility by encouraging good agile practice. But such practices and the controls around them need to be adapted to the needs of a project and the people working on it. For example, the governance of a year-long project developing an entirely new product line and all the attending infrastructure needs to be governed differently to one involving a two-month long enhancement to a web site.
  • Review viability frequently. Consider whether all the elements that contribute to success are still in place all the way through a project. One way to do this is to review at every iteration boundary (or every Steering Group meeting) whether the project is still on track to meet the business case, achieve it’s vision, and deliver the planned scope on time and within budget. Consider whether the direction or solution design changed significantly. What happens, for example, if one key person leaves, and takes a few of his friends with him? Is the project still viable? Probably not, and that needs to be recognised and addressed. The job of Governance is to highlight the issue and assist the project team to resolve it.
  • Transparency. Ensure all pertinent information is widely available – on walls, dashboards, etc. It should be the responsibility of governance to ensure a project team are not hiding any bad news. All stakeholders should be aware of the true status of the project, which leads onto…
  • Fact-based reporting. Measure real progress, through delivery of valuable solution components at regular intervals. “We are 80% finished” means nothing unless that 80% can be (or has been) tested and, if necessary, implemented. Don’t measure progress by the subjective reports by PMs, so typical of most organisations – they are not always reliable.
  • Do ‘just enough’ planning throughout. This can be considered more a project management principle than a governance one, but it is also the job of governance to encourage speed to market, and early benefits realisation.
  • Ensure adequate contingency is available. Whether in time, cost or scope, different projects need to fix different elements of that triangle. Governance should check that sufficient contingency exists on an appropriate axis/axes.

I don’t know whether any of the above will find their way into the APM Guide, but I may soon be able to refine these further and put them into practice myself once again. Watch this space.

Posted in Agile | Tagged , | 1 Comment

The core of Agile

Peel away the layers of agile practices, dig down through the principles and values of the Agile Manifesto, and what is at the very core of Agile is one simple objective and two activities.

The objective is Risk Mitigation. Think about it – all the practices that distinguish Agile approaches – daily stand-ups, user stories, test-driven development, pair-programming etc – were adopted in order to reduce the risk of project failure inherent in predictive or plan-driven methods.

The two basic activities we employ in this risk mitigation exercise are Collaboration and Learning. These are the two main factors that make Agile what it is and make it work. Keep these two things always in your mind. In every task, think to yourself “who should be involved in this activity (and how) in order to make it most effective”, and “what do we need to learn most, and how do we discover the answers as quickly and cheaply as possible”.

All of the principles and practices in agile boil down to those fundamentals. Is it really so simple?

Collaboration

Consider cross-functional teams, co-location, stand-ups, user stories, facilitated workshops… All are examples of practices and disciplines designed to amplify collaboration. Because two heads are better than one. Because the wisdom of crowds is better than any individuals. Because it is more effective and efficient to get people in a room together to decide something than it is to share emails for weeks on end. Because there is no more effective form of communication than face-to-face.

Learning

Iteration, architecture modelling, story mapping, show-and-tells, prototyping, pair-programming… all examples of agile practices designed to amplify learning. Learning is important because we recognise that not only do we not get the requirements set exactly right the first time and realise it will change, we also don’t know whether the solution we create will exactly meet the users real needs. So we need to learn about those things as quickly as possible. And continue to do so until the project’s objective is met and the customer is delighted.

This may be an over-simplification of a complex subject, but when the conditions for running ‘pure Agile’ simply aren’t all there, it pays to come back to the essence of what Agile is and why it works.

Posted in Uncategorized | Leave a comment

Role Playing games as Agile educators

One day some years ago, I spent a couple of hours in the car while my son – then aged about 13 – told me all about what he’d been doing recently. What was occupying most of his time was World of Warcraft and he was now online playing this most iconic (apparently) of MMORPGs. I sighed in frustration. Gone were the days when he used to spend his afternoons and evenings playing football or cricket with his mates; now it was online games with virtual friends. This wasn’t doing him any good at all. Or so I thought.

But as I listened to him tell me about how the game worked, and the people he was playing with, I realised that there was a lot more to this than time-wasting. And when he asked if he could play when we got back to my place, I agreed, wanting to see more.

Firstly he used my desktop PC to log into his Warcraft account, but then had his laptop beside him, logged into a voice-chat application using my headset and microphone to talk with other players. I learned that:

  • His ‘raiding team’ had people playing defined roles (Tank, Healer, DPS) based on the characters they adopted and their inherent skills
  • They had a team leader, who ….
  • They met online specific times
  • They set specific goals and objectives each time they played
  • They collaborated to achieve an objective, sometimes sacrificing themselves for the good of the group
  • They communicated constantly during the game.
  • The reflected on their successes and failures after every mission.

Does this sound familiar? Does this sound a little like an effective Agile development team holding stand-ups and  retrospectives? My son, I realised, was doing more than just game playing as entertainment, he was actually learning skills at a young age that some employers tend to take for granted – clear and concise communication, how to collaborate in a group, true teamwork, negotiation,  leadership, empowerment and delegation. It can take some people years to learn these skills in the workplace, but the dynamic nature of Warcraft and the way the teams are structured meant that he exhibited the sort of behaviours that we train and coach into our agile teams. He even learned that no two guilds are the same, and he needed to find one that met his objectives too.

 

Posted in Uncategorized | Tagged , , , , , | Leave a comment

Two Agile worlds

There is a recurring theme that has been around the agile community for a while now. One so pervading the industry that I have spent quite some time reflecting on it.

Have you noticed that people are questioning the very nature of Agile itself? What IS Agile, people are asking. Is it a set of practices? If so, which ones? Some basic values and principles? Then how do we live them in our workplace, it seems too hard. What do you mean there’s no place for a project manager in Agile? We have loads of them! Speak to people at a conference or two, or even just read through the Agile LinkedIn groups forums and there are lots of examples of this type of question.

These questions (and others) are symptoms of the difficulty some people are having trying to apply ‘agile’ in their own environment. Let’s face it, an internet startup like Groupon or Twitter or Snapchat has a completely different environment to a multi-national Investment bank, a local government department or a defence contractor. A small company trying to figure out what its fledgling product will look like when it’s launched will have a different set of constraints to a company with an old and complex multi-platform architecture with development teams spread across three cities in two countries, a limited budget and a larger portfolio of planned projects than they have people to deliver them.

There are those who believe that Agile means Scrum. And/or XP. It means a small cross-functional team co-located, and delivering in short iterations to get a minimum viable product (MVP) to market as quickly as possible. And then delivering updates as quickly as possible based on feedback from real customers. The Lean Startup model. And these people are passionate about Agile. They live and breathe collaborative estimating and planning, test-driven development, continuous integration and one-click automated deployment. They have no need for project managers with their Big Design Up Front and detailed plans, nor system architects, or sponsors. And don’t even mention governance or… (deep breath) the project management office (PMO). For them Agile is lightweight, non-prescriptive, and fast-paced. It is lean (with a small L).

And there are those for whom this is anathema. Or a distant fantasy – a utopia beyond their wildest dreams. For they believe that their projects just cannot be run in this ill-disciplined manner. That projects need management, and planning, that a portfolio of projects needs governance. That there is a place for Business Analysts and platform-specialist developers, technical co-ordinators, change management teams, and yes the PMO as well. That implementations to Production (of multiple projects) happen maybe once a month (or longer), because there is complexity in parallel development. In this environment the involvement of external suppliers and lengthy contracts are the norm, tools for test-driven development won’t work with the platform and not everything is under source control. The approach to software delivery here is geared around projects – structured, planned endeavours with specific goals and usually a defined end-date.

As you can see, these two worlds (in the extreme examples I illustrate) are very different. Neither is right, neither is wrong. They just are. I call these worlds the Product World and the Project World respectively.

Our beliefs about what is right and proper are generated by our own experiences, knowledge and skills. Those who have experience only of the Product World have a fundamentally different view of what Agile is, and is supposed to be, than those whose only experience is of the Project World.

So we need, I believe, to recognise that these two worlds are very different, and that the same approach to Agile cannot work across both – there is no single transformation recipe, no one ‘best practice’ or method. That each organisation needs a deep understanding of the values and principles behind Agile, and work out the best way to live them in their own organisation. That what is right for one company is not necessarily right for another. And that we should all stop telling each other what is the ‘right’ way, and do more to discuss and learn about other ways in other environments. Sure there are things that we can all learn from other people in different environments, but we can’t assume that they will work the same elsewhere.

Agile is so much more than just a set of practices, and it is not a recipe book. Agile is a philosophy; a way of thinking. And all we can do is be as Agile as we can be, given the constraints under which we are working.

Posted in Agile | Tagged , , , , | 1 Comment

Hansei and “being negative”

The success of a change program is dependent on many things. One of them is how the organisation deals with change. And how they learn what needs changing and whether the change was effective once introduced.

I was reminded of this while reading The Toyota Way, (J K Liker, 2004). Chapter 20 discusses Principle 14 of the Toyota Way – “become a learning organisation through relentless reflection and continuous improvement.”
It explains Hansei and Kaizen as concepts and practical tools. Kaizen has found it’s way into the Lean software development community, but this was the first time I came across the word Hansei. It means deep reflection and is the root of Kaizen.
As the author explains, Toyota found it difficult introducing Hansei into their American plants because of the cultural differences. In Japan, when a mistake is pointed out, whoever made the mistake is usually the one pointing it out, or at least accepting it, then reflecting deeply on why he made the mistake and what he can do to improve so that he doesn’t make the mistake again. It is seen as a positive thing; as an opportunity. In the West, having a mistake pointed out is taken as a sign of weakness and is seen as a negative.

Some time ago, I made my colleagues aware that a particular process was lengthy, bureaucratic, wasteful and expensive. A short time later, the CIO asked me for a chat and asked me why I was “being negative”. I was confused, and explained that, to my mind, I wasn’t being negative, I was looking for the negatives as opportunities to improve – a positive thing, I thought. But my comments were perceived as making waves, disrupting the status quo.
How, I thought, could you identify where change was needed unless you looked for the negatives?! Seeing the negatives and trying to improve them is not the same as being negative. Being negative is thinking we can’t – or won’t – improve.

The concept of Hansei is lacking in western organisations. The agile retrospective comes close, but the sort of deep and careful reflection that is Hansei requires a change of mindset similar to that required to really understand the nature of Agile itself.

Posted in Agile | Tagged , , , | Leave a comment