Title:search

Sure and Safe? AgilePM and SAFe

AgilePM is a project management framework for agile projects launched to enable project managers to adopt a mature, scalable, corporate-strength agile approach within their organisations.  SAFe (Scaled Agile Framework) is presented as an “interactive knowledge base for implementing agile practices at enterprise level”. 

 

For me, the critical next question for agile projects is about getting top management involvement for projects of high strategic importance; i.e. projects that have significant impact on the future of the organisation. In my experience, strategic decisions in agile projects are being made day-to-day with regard to technologies and customers, whilst unfortunately top managers stand outside the process.


Teams are “empowered”, allegedly (because often without budgetary power), but this does not mean that top managers should be absent. In my opinion, in a highly strategic project they should be available when the situation demands, which may even be in the middle of a ‘timebox’ (i.e. in principle, a ‘sprint‘ does not allow this.)


The philosophy expressed in the '41 things you need to know" is ‘centralized strategy’ with ‘local execution’. But, how does top management participate in ‘local execution’? Think of the way that a Jobs, Gates, Dyson, Bezos or Chanel participates in strategic projects. Give them room and space, but serve, hearten or embolden the team when needed. (Don’t stifle them, but give them oxygen.)


Scrum outlines a ‘Product Owner’ role and I expect SAFe to outline the ‘Product Manager’ role. However, these are often delegated way below the top management level of decision. Given the importance of decisions that will be made during the often turbulent life cycle of an agile project, governance for a ‘strategic’ project must be in the executive suite. How many ‘Product Managers' sit on the board of directors?


I can see the ingredients for top management presence through the ‘Visionary role’ and the guidelines for using the business case in APMG's AgilePM/DSDM,and in the detail of Robert Cooper’s ‘Stage Gates’ (gates with teeth), in design and product development such as Ulrich and Eppinger’s strategic engineering approach via the ‘contract book’, and in ‘design thinking’ in general, and in the IIBA's BABOK. I cannot see it explicitly in Lean for production, but in Eric Ries's Lean Start-Up, via the 'pivots' and 'actionable metrics'. I can also see it as part of stakeholder management in PMI's PMBOK and in APMG's PRINCE2’s exception reporting structure, and in the ‘Sponsor’ role acting as ‘executive champion’, present in all of the afore-mentioned approaches.


For me AgilePM is one way to wrap all of this stuff together and to integrate top management in critical decision making on agile projects of high strategic significance.  

 

If you look at the annual “Agile Tends & Benchmark Report” produced by SwissQ, a consultancy specialising in information technologies and testing practices, on page 4, you can find a maturity curve which shows Scrum approaching post-maturity and DSDM in the introduction phase of the life cycle.

 

Page 5 reveals that in the survey: “54% of all agile projects fail because of difficulties reconciling the business philosophy with agile values”.  “Scrum projects remain islands that are largely self-organized” and only “17.9% use ‘definition of ready’ opposed to 62.1% using ‘definition of done’”.

 

42.2% of statistics are invented of course.  Nevertheless, for me the significance is in the roles. Test consultants recommend an ‘embedded tester’, which is entrenched in DSDM.   Scrum insists repeatedly upon the independence of the team from management interference and the role of the Product Owner being to “serve the customer”.    (Yep: important to know what the words ‘serve’ and ‘customer’ should mean  ;-)

 

SAFe describes the role of Product Manager in a way which implies top-down management.   The Product Manager “communicates the vision” to the team and “maintains the product roadmap”.  In essence this role is “typically an active member of the extended Portfolio Management Team, where they participate in decision-making about the key economic drivers for future releases”.

 

In DSDM, the Business Visionary “defines the business vision”, promotes translation of the vision into working practice, monitors progress in line with the business vision, communicates and promotes the vision to all interested parties, etc.  This is potentially a much more pro-active and high-level role. 

 

For me, these are key points:  A ‘strategic’ project can give reason to ‘pivot’ the business vision.  A strategic agile project may requir frequent re-focusing of the vision during the project.  Vision clarification entails active dialogue, trust and understanding between the development team (technology) and the business (market).  “Defines the business vision” should allow participation and encourage ownership. 

 

All partners in this crafting and shaping of the business vision must learn to understand the language, not only of the technology (agile and whatever), but of the business. 





How to present project management to school students

This is the kind of thing I would prepare if asked to present project management to school students. And I would probably adopt a flipchart style. (This would save having to present a monotonous deck of slides.) I would do something really simple.

First the students would want to hear something about the kind of projects that are done and why they are important all over the world. Students like to hear about the exciting real world and there's nothing more 'real' than a good project! Then I'd explain that projects always bring something new, to the world or to an industry, and they need to be well managed, especially when they are complex and difficult (and they usually are). 

Much can go right or wrong, and you can easily rub some people up the wrong way because you are usually replacing one set of things by something else. This means managing the stakeholders' expectations - including customers, but also project participants and team members, other people in the company, investors, the public, etc.

I would explain that projects are always about managing people and their reactions, that is the benefits, as well as the very important triple constraint. I would explain the triple constraint, by saying that delivering quality is about quantifying the expectations of the stakeholders and agreeing on the priorities. I would say that the project has to be organised so that we know what work has to be done to meet expectations and even to give people some nice surprises so that they will want to work with us again in the future.

And I'd say a few words about the work breakdown structure and how you need people to be responsible for all of the different parcels of work that are defined to make sure you meet the objectives. In the triple constraint I would say that sometimes the technical requirments are very well defined, the budget quite fixed and managing the project is mostly about managing time. I would give some examples - e.g. building a metro system or a new airport.

And I would mention the critical path method. I would say that sometimes the date is very fixed and the project content is quite well known, like with the Olympic Games. In these cases, the project is mostly about managing costs and resources: methods such as the critical chain, and performance management (measuring the value of work done) could be mentioned.

I would say that very often in modern business projects the budget is fixed and the time very tight as well, as in launching a new product ahead of the competition. With these projects scope needs to be managed carefully and the project designed so that the most important things are delivered in early versions, according to the critical purpose of the project, which has to be agreed and worked upon with the stakeholders.

I would select one of these projects and talk about it a bit more, making it look and sound and feel very interesting, explaining why it is important, and talking about what can go right and wrong, and why it is a challenge for the companies concerned. I would say a word about how the project manager's job depends upon their ability to operate in a complex organisational context, with the support of a sponsor and listening to the voices of customers and experts.

Then I would say that in general projects are fascinating, interesting, engaging and a good career choice because all over the world, in every industry and in every company and in every department of every company you have new things going on that need good managers.

You don't need to understand all of the technical details, but you have to be able to get people to work together and remember to ask the stupid questions that inspire people to think: like, "What will it have to do to be useful?", "What do I need in order to get started?" and "How will I know when I have succeeded? How can I measure that?" I'd say that it isn't usually very easy to manage a project, because all projects go through a storming phase when people don't agree, and everyone starts to think that everyone else on the project is an idiot. And the students will know this! But, I would explain that the work breakdown structure helps to define all the work leads the project through this stage.

As a conclusion, I would claim that project managers are the people who are needed to turn the problems and challenges of this world into solutions.





Check with non-experts, not just experts

We like to put our trust in experts.  And we’d rather not deal with those who are not professionals. 

And the experts like to be trusted; to get on with their job without being interrupted or hindered. 

Similarly, when specialists ourselves we prefer to avoid interference and intrusive control.  And if we feel that we do not have the expertise, we choose not to get involved.
 
Thus, we can get into situations where we trust too much in expertise, though it is impossible for anyone to know everything; and trust too little in those that may not be specialist, but nevertheless may be highly motivated and have much to contribute.
 
The result is that we end up with products, treatments, remedies, answers that later turn out badly, to our great chagrin and feeling of betrayal. But in reality we have ourselves to blame, and our own lack of diligence, for our regrets. 
 
Likewise we overlook people who know something of vital importance, but who are not recognized as experts. We should speak to the journeyman not just to the star, to the artisan not just to the artist, to the baggage handler not just the logistics expert, the skilled employee not just the managing director, the fisherman not just the fisheries official, the employee not just the managing director, the patient not just the consultant, the commoner as well as the king.
 
We ignore the customers and the people that really do stuff, because what would they know? We design systems without speaking to users, develop architecture without considering ordinary people.
 
It’s a pattern of behaviour and, as the saying goes, if we carry on repeating what we’ve always done, we’ll get the results we’ve always had.  It’s time to gather information beyond the most obvious sources, and maybe we’ll put an end to a few tragedies and not a few fiascos.




rss


sitemap xml