The PMO has the power to support your organisation’s revolution – Part 1 of 2

Intro

The theme of my blogs are based on organisations recognising uncertainty, and finding better ways to respond. I mentioned in my last post that the Project Management Office (PMO) is critical in supporting their organisation to survive and thrive in an uncertain competitive environment.

Here I’ll describe how the PMO can support and facilitate your organisation’s revolution to move beyond competitive myopia, internal ineffectiveness and towards becoming a learning enterprise that’s resilient and highly competitive.

I’ve split this into two posts. The first will identify some common dysfunctions, being agile, and introduce a roadmap for the PMO to support their organisation’s transformation. The second post will focus on being lean, discusses how the PMO plays a central role, and whom they interact with.

Common Dysfunctions

Let’s start by considering these job requirements in this recent Agile PMO job ad. It’s not all bad, but parts of the description are indicative of some PMO teams helping to perpetuate the dysfunctional practices of organisations not effectively recognising and handling uncertainty.

Taking ‘inspiration’ from the job advert, let’s examine some of those dysfunctions. Below in the red hexis (with dashed borders) I’ve identified what I believe are common dysfunctions. In the yellow hexis (with solid borders) I’ve captured some of the negative consequences.

No doubt some hexis could be rearranged and others created. Hopefully you get the gist that often the PMO supports organisational practices and mindset that cater well for certainty. There’s emphasis on consistency (not flexibility), best practice (not emergent practices) and compliance (not responding to change).

Those red hexis may be appropriate for mature business models (their cash cows), but the competitive market is changing too fast for your organisation to rely on those. To continue your organisation’s mission and vision, it must shift towards identifying and handling uncertainty.

This means organisations need practices that address the problems identified in the yellow hexis, and I believe the PMO are well placed to support that revolution.

To achieve this the PMO should support product management, sales and the executive committee to prioritise a portfolio of products and initiatives. This is achieved through Lean and Agile ways of working. In this post I’m focusing on agility; the second post will focus on lean ways of working.

Being Agile

Here I’ve attempted to express the Agile Manifesto values for the PMO, which will help to tackle the common dysfunctions.

  • Individuals and interactions over processes and consistency
  • Support learning outcomes over comprehensive governance
  • Facilitate value-stream coordination over siloed negotiation
  • Responding to change over following a plan

As with the original agile manifesto, while there is value in the items on the right, the PMO should value the items on the left more.

It’s also important the PMO supports their organisation in planning and reporting on the constraints appropriate for each initiative. The traditional Project Iron Triangle controls for cost, schedule and scope; these tend to be the traditional constraints an organisation observes, and which the PMO monitor and report on.

To support agile initiatives these remain important constraints. However value and quality are also important. With the cost, schedule and scope constraints they form the Agile Iron Triangle.

Focusing on value helps us understand that not all of the scope is needed to release a product early and get early feedback; this ties into supporting conditional incremental budgeting. Focusing on quality ensures the product is reliable and adaptable for an uncertain future.

The challenge for the PMO is that unlike cost, schedule and scope, value and quality are subjective. They need to agree with their organisation a way to measure those subjective measures.

Roadmap for your revolution

Here’s a sneak peak of a flexible roadmap for the PMO to support your organisation’s revolution. Follow my posts to learn more, and I welcome feedback to improve and publicise it.

Conclusion

I’ve put forward the case that PMO is critical in supporting your organisation in recognising uncertainty and finding better ways to respond. I believe the PMO should support the approach your organisation takes to survive and thrive in an uncertain competitive environment. This means their practices and mindset needs to realigned to agile ways of working.

That means the PMO should help their organisation gain an ability to rapidly test assumptions with a degree of dispassion and objectivity.

In the next post I’ll introduce how lean ways of working will enable the PMO to support your organisation’s revolution.

Let me know what you think, and contact me if you’d like to learn how I’ve helped clients on this journey.

 

Why agile portfolio managers should act like rice farmers

One of the themes in Malcolm Gladwell’s Outliers is how differences between Asian and Western cultural practices may have a hidden influence on the different attitudes to success and determination.

Gladwell describes how the painstaking persistence of rice cultivation in China differs from Western grain cultivation. In the latter, land is often left fallow for long periods to allow the soil to regain nutrients. He suggests the resulting difference in farm labour has influenced the different attitude to work and play between the two societies.

Although I found this intriguing, I couldn’t help draw parallels between the practice of rice cultivation and the management of an agile product portfolio.

To explain why, I’ll start with some of the points Gladwell made about rice cultivation.

  • The rice farmer planted two or three crops a year. The land is fallow only briefly
  • A rice farmer might plant a dozen or more different varieties at one time, adjusting the mix from season to season in order to manage the risk of a crop failure
  • Sometimes each rice shoot would be individually groomed with a bamboo comb to clear away insects
  • Farmers have to check and recheck water levels and make sure the water doesn’t get too hot in the summer sun
  • A rice farmer would have hundreds of different varieties of rice from which to choose, each one of which offers a slightly different trade-off, say:
  1. between yield and how quickly it grows,
  2. or how well it does in times of drought,
  3. or how it will fare in poor soil

Here are the parallels I see for effective agile product portfolio management.

Like the rice farmer, the portfolio manager must continuously seed the market with new product iterations. However there are times when the market isn’t ready, such as during an off-season.

For example, to attract repeat purchases a TV manufacturer should maintain the rollout of new technologies. However demand is likely to reduce soon after a large international sports event.

Similar to the hundreds of different rice varieties, online platforms should have different varieties of product balances, which can allow them to adjust for different trade-offs.

For example fine tuning the prevalence of adverts against retention of users

Like maintaining rice variety to mitigate against crop failure, creating a product range gives an organisation insurance, even if some of the products are a burden under certain conditions.

For example Procter & Gamble market different laundry detergents designed for different levels of affordability, which respond to different degrees of consumer confidence.

Like those individually loved shoots of rice, some products, or product features, needs very attentive ‘grooming’.

For example consider Telsa Motor’s careful public relations management following crashes involving new autopilot technology.

Like the rice farmers who constantly check their water levels, the portfolio manager must maintain close awareness of the factors which nurture their products

For example, vigilance over the number of active users on a social media platform is necessary since this is a key metric to attract advertisers.

Perhaps you can think of other parallels?

The practices of the rice farmers are a consequence of their agile mindset, where they are:

  • Iterating with a continuous ROI
  • Building in flexibility for unforeseen circumstances
  • Maintaining close vigilance of leading indicators (e.g. water levels)

These should also be the practices and the mindset of an effective agile product portfolio manager.

Thinking along the lines of Steve Blank, who launched the Lean Startup movement, I would say we don’t really know our market, product or customers. Therefore we should act like a rice farmer.

In Tim Hartford’s Adapt he writes that in order to survive and thrive in an uncertain future, we must continuously create variation, build in survivability so failure isn’t a catastrophe, and use feedback to select what works. Again, just like a rice farmer.

Nassim Taleb coined the concept of Antifragility. Rather than become resilient to uncertainty, a portfolio manager must seek uncertainty and complex situations. That way through many small failures, they are constantly getting stronger by hedging and fine-tuning their response to the evolving market. An effective agile product portfolio manager should embody the notion of antifragility.

Here are two future posts to continue this theme. Leaders and PMO people, I hope you’re sitting up!

  • The sometimes maligned PMO is absolutely critical in orchestrating this agile approach.
  • The importance of self-organising teams. As a teaser I’d offer that the speed and volume of feedback required to make portfolio management effective means that a traditional hierarchical, command-and-control structure will always function sub-optimally.

Both emphasise the importance of the agile mindset throughout the organisation. I believe the competitive market is moving too fast, and uncertainty is too great, to operate in any other way.

Switching from Scrum to Kanban – A story of collaborating with the leadership team

This is a real-life story. It’s a story about addressing the concerns of senior managers who are wary of their delivery teams making their own independent decisions. It’s a common tale that many delivery teams face, and one where, as servant-leaders, scrum master and agile coaches need to support their teams in navigating.

This story is set in late 2015 amongst four delivery teams in one of the UK’s most established broadsheet newspapers organisations. To meet the end-of-year deadline, the teams had been working their socks-off to build a new publishing platform and migrate to a new front-end service for the newspaper’s readers.

Since much of the platform had been released and was being used for the first time, the teams were rapidly moving from build-and-deliver release cycles to a more responsive support operation.

Previously when the teams were building and releasing, their iterations were synchronised into two-weekly sprints. However, when an increasing number of journalists were using the platform in unexpected ways, teams needed to respond to urgent support requests more frequently than the two-week sprint cycle would allow.

This meant the two week sprint planning sessions became a bit of a farce because the backlog the teams were selecting from didn’t reflect the uncertainty of supporting a new platform. Multiples times a day the teams were breaking the sprint backlog forecast to deal with rapidly emerging issues.

Being the people actually doing the work, as oppose to the more distant leadership team, most of the teams recognised they should probably switch their work practices from Scrum to Kanban. They wanted to see if the Kanban approach would cater for different urgencies and uncertainties of work.

Note this isn’t a story about the Kanban process, or the pros and cons compared to Scrum; that is covered well enough elsewhere. It’s story about how the relationship between delivery teams and the leadership team, the autonomy the latter should allow the former, and what a servant-leader needs to do to protect the team.

Now back to the story….

During one of the teams’ retrospectives, one team decided now was the time to switch. This was not prompted by the team’s scrum master, and was not discussed with the leadership team. It was an independent team decision.

As well as discussing the way the team would make the switch, the team had to handle the fact that Kanban did not conform to the leadership team’s expectations. The CIO and his Head of Delivery were concerned it would negatively impact delivery and on how the team reported.

With the support of the scrum master the team did several things to relieve the concerns of the leadership team:

  • Since the scrum master spent more time with the Head of Delivery the scrum master was able to help the delivery team recognise and empathise with the concerns of the leadership team.
  • One such concern was a fear that the team would not report and deliver on a fortnightly basis what they planned and worked on. Therefore, via the scrum master, the team had to explain that the nature of their work was changing to a more reactive sense-and-respond operation; less work would be predict-and-control.
  • They explained that the scrum master would still complete the team’s weekly reports and track issues using the recognised red-amber-green status mechanism.
  • The team informed the leadership team that it was only a trial, not an irreversible commitment.
  • And since it was a trial, the scrum master discussed with the leadership team the fact that they needed to give the delivery team the time to learn from mistakes.
  • Finally, since the leadership team had endorsed agile ways of working, the scrum master helped them understand that the switch to Kanban was in keeping with two of the Agile Manifesto values:
    1. Individuals and interactions over processes and tools
    2. Responding to change over following a plan

So those were the discussions the team had with the leadership team. What actions did they actually take?

Acknowledging where the leadership team was coming from, recognising the need to change the processes incrementally, and knowing that quality must be maintained, the team decided on these actions:

  • The team still chose to use story points and their velocity to forecast what could be delivered every fortnight. Since a lot of the work was unpredictable, only a portion of the velocity was available for this forecasted work.
  • The team still had a fixed cadence for some ceremonies such as release management, retrospectives and reporting
  • Ad hoc individual story planning and story reviews were introduced. Thus creating a more responsive flow of work.
  • The team ran workshops to discuss and agree on the first set of Kanban columns and WIP limits. Therefore they began to anticipate where the flow of work should be constrained.
  • Since it was too early to figure out what they’d be, exit criteria would be introduced later.

How does the story end?

Here’s what happened after a couple of iterations

  • The team wasn’t loading work into the sprint backlog which they knew they couldn’t deliver. This gave the business a more realistic picture of the team’s capacity and encouraged the business to recognise the switch to a support operation. Although they found it hard, the business understood less new features could be delivered.
  • Since the team was continuing to story point work, and measure their velocity, artefacts such as the product burn-up chart was still a very useful discussion tool.
  • The team was still able to report on their fortnightly delivery forecast. The leadership team understood the team’s changes did not affect the quality of work and it was not detrimental to the rate of delivery

So, this story has a happy ending.

The team successfully found a way to understand and address the concerns of senior managers. Those managers understood the value of giving team autonomy over their own processes. And, with scrum master guidance, the team independently found a way of working which was more appropriate to their new responsibilities to look after the platform’s users.

What’s your story? Do you have similar challenges in your teams and departments?


This article is also posted on Dean Latchana’s LinkedIn account.

Situational Analysis to Stay Ahead of the Game

For posterity, I’m capturing the details here of the Situational Analysis to Stay Ahead of the Game workshop.

It was run as part of the London Agile Delivery & Coaching Network meetup group.

The workshop was run on 13th July 2016. It was organised and run by me (Dean Latchana) and Tom Broughton.


Workshop description

Situational Analysis to Stay Ahead of the Game

Until recently, most companies we work for had a clear idea of who their rivals were and how to compete. But in recent years the digital revolution, political upheaval and globalisation has blurred strategic clarity; their environment has become far more complex.

Companies and teams are often faced with concerns regarding their productivity and effectiveness in the marketplace. Often their solution is to work faster at doing the same or cutting costs whilst trying to maintain the status quo.  For many this strategy won’t stop their decline into irrelevance. Such organisations need to overcome their myopia, look to the horizon and regain their situation awareness.

With situational awareness we can help our organisations distinguish between known and unknown areas of business operations and the market dynamics in which they operate. Situation awareness will help us understand where to apply practices appropriate for exploration & experimentation versus execution & delivery.

This event is an introduction to ways that’ll help you and your organisation regain better situational awareness, and identify where complexity exists. For each situation we will explore appropriate working practices, such as agile service design, budgeting and business model generation.

We’ll be using the Cynefin framework’s decision model, introducing how to analyse how your vision is positioned in the market and how effective your capabilities are to realise it.

This introduction is an evolution of the material and thinking already presented at many organisations operating in rapidly changing environments, such as Telegraph Media Group, Financial Times, UK Government Cabinet Office department and at several events & conferences.


Photos from the workshop


IMG_20160713_193046

IMG_20160713_193029

Dean Latchana’ Agile Tour London 2016 interview responses

I’m honoured and excited to be talking at Agile Tour London 2016 (21st October), where I’ll be talking about Teal Organisation and how they’re handling complexity.

As part of the lead up to the event, they’ve asked the speakers to answer some interview questions. Here’s my response.

Firstly, if you’d like to come along to this great event, there’s still time to register.

Tell us a little bit about your agile journey (where did it all begin? where are you now? what/who are your inspirations etc)?

My agile journey started when I was working at the BBC in the late ‘00s, when I was introduced to DSDM. Although my experience of DSDM isn’t strong, it made a lot of sense to me. Taking an iterative and incremental approach to product design, and (on a more philosophical level) our own beliefs, seemed like the obvious default approach. Yet many organisations don’t hold agile and lean values at the heart of their mindset, and I fear for their existence.

In the intervening years, and after working at several organisations where their incumbent dominance is threatened, I’m beginning to fear that the majority will never acquire a truly agile mindset. Many are in an existential crisis.

Organisations exist in complex world where they need to be alert and nimble to change; they need to become federated, where each self-governing unit has huge autonomy to sense and respond to their own values and competitive environment. Yet many organisations believe they exist in a simpler world where they can centrally predict and control all internal and external outcomes; this is futile and will lead to their eventual demise.

Now in my agile journey, I’m wanting to enable organisations to acquire an agile mindset where they develop an acute degree of situational awareness, where they foster the ability to experiment quickly to test their assumptions and convictions, and where organisations safely probe threats and develop an adaptive immune system that’s inquisitive and rapidly learns. Boy, are we a long way off from that!

People that inspire me are Simon Wardley (everyone, learn about Wardley Mapping!), Steve Blank (author of Drive), Steve Blank (started the Lean Startup movement) and Dave Snowden (creator of the Cynefin complexity framework).

You are speaking about at Agile Tour London the title of the session is TEAL ORGANISATIONS: THE NEXT PARADIGM SHIFT IN RECOGNISING AND HANDLING COMPLEXITY, what are the origins of the talk?

The origins of my Teal talk is from a confluence of ideas I’ve developed in the past few years. I’ve realised that no one, regardless of how confident, experienced or knowledgeable they are, can predict the dynamic forces within their organisation and within the market the organisation operates in.

Teal’s approaches, I believe, can create organisations where the leader becomes less relevant. They become the steward of the organisation; an organisation that is self-managing, emancipates its staff (not simply empowers), and allows the organisation’s products and service to morph and grow like a living organism swimming in a swirling current of nutrients, threats and friendlies.

Which organisations are now currently Teal?

Here’s a couple of examples.

Buurtzorg is a Dutch homecare organisation that’s renowned for creating fully autonomous nursing units. Like a good agile coach, they create a support system which means their patients can care for themselves, and the nurses safely depart. In a few years Buurtzorg have grown from nothing to dominating the homecare sector in the Netherlands.

In the UK Timpson, the shoe repair and key-cutting retailer, have many Teal-like qualities. Timpson is a profitable organisation that’s embraced upside-down management. Staff are actively encouraged to use their initiative and try new ideas. No head office staff are allowed to issue orders. They delegate authority but NOT responsibility.

Which sessions are you looking forward to seeing while you’re at Agile Tour London?

  • Your company will never be agile – David Tanzer
  • Toyota Kata Puzzle experience – Håkan Forss
  • Growth Hacking for Product Managers – Andrea Darabos

    What else is on your radar for this year; any conferences, events, books etc.?

    • Trying to get some training in Wardley Mapping
    • I’d like to read The Radical Incrementalist (Kelvin Campbell, Rob Cowan), and Beyond Budgeting (Jeremy Hope, Robin Fraser) and Antifragile (Nassim Taleb)

21 June 2016 – London Agile Delivery & Coaching meet-up – Agile coaching, change control and discretionary behaviour

Sandra and I were at the London Agile Delivery & Coaching Network on Tuesday.

Here’s some of the areas we covered.

  • The difference between the role of a scrum master and an agile coach. Key differentiator being agile coaching is driven by leading and coaching through the values and principles and the application of the right agile method for the organisational context.
  • The benefits of visualisation of team boards. Physical and electronic. The power of physical product backlogs, cardwall or a burnup chart as it drives richer focused conversations and provided greater insight to understanding the state of a project or sprint. Experiences of organisations with “clean” wall environment and ways of dealing with these policies.
  • Sandra’s experience at Western Australia’s energy company. Dealing with resistance at middle management level and their reluctance for team autonomy. Strategies in dealing with such issues lead to measuring and reporting inefficiencies in the change control process and in the subjective measures of the delivery team’s frustration and motivation. Change is slow but the key learning is demonstrated through measured facts and the cost of inefficiencies.
  • Dean’s experience of SAFe’s PI Planning at the Telegraph Media Group.
pi-planning-board
One team’s output from PI Planning. It shows the sprints for the quarter, estimated availability per sprint, and what the team believes could be delivered in each sprint.
  • Weighted Shortest Job First technique for prioritising backlog. Including learning and team bonding as a weighting factor.
  • Why DevOps not just about process and tools, but perhaps more profoundly about people’s understanding, empathy and collaboration beyond their typical team boundaries
  • Why striving for happiness maybe dangerous, and why qualities such as equanimity maybe a healthier characteristic. Listen to Boss Level’s podcast: Kathrine Kirk and when happiness fails you
  • Motivation and discretionary behaviour at work. Employees can be either motivated and willing to perform and produce more than contractually obliged, or conversely employees game the system so they get away with doing as little as possible without getting fired.

    Illustration demonstrating the range of an employee's discretionary behaviour.
    Illustration demonstrating the range of an employee’s discretionary behaviour.

London Agile Delivery & Coaching meetups is different to the typical Agile meetup because they’re intentionally kept to a small number of people. This allows folks to have an open and more in-depth set of discussions, and perhaps have a more frank and honest debate. It’s an open forum with no upfront agenda.

Look out for the next London Agile Delivery & Coaching Network meetup.

Cheers,

Sandra Dalli and Dean Latchana

24 May 2016 – London Agile Coaching meet-up – Scrum Master interview questions, Commodore Pet and Larry Weed’s classic 1971 lecture

Baldev and I were at the London Agile Coaching Network on Tuesday.

Here’s some of the areas we covered.

  • We discussed ways to respond to this interview question “How do you deal with a developer who is resistant to testing, who has finished their assigned sprint backlog”
  • We also discuss this interview question “What would you say to the Head of Software Engineering who wants to attend all the scrum ceremonies”
  • Dean spoke briefly about the UK Government’s Digital Marketplace, where individuals and organisation with digital specialisms can be matched with work and outcomes needed by the gov’t.
  • Dean tested and got some valuable feedback on his Teal organisations, and Buurtzorg nursing home care presentation. Dean plans to present this at Government Digital Services. Teal characterises organisations that are gaining the benefits of individual and team self-management, wholeness, and a deeper sense of purpose.

  • Baldev spoke about some of his rich and varied career history where he programmed one of the earliest digital medical records on a Commodore Pet.
Commodore Pet
Commodore Pet
  • This prompted us to talk about Larry Weed’s classic 1971 lecture, where he berated doctors in the United States for not keeping up-to-date and easily accessible patient medical records. In the lecture Dr Larry Weed discusses problem-orientated medical record keeping and clinical decision-making – perhaps something we can draw analogies from.
Larry Weed
Larry Weed at the 1971 Internal Medicine Grand Rounds

London Agile Coaching Network meetups is different to the typical Agile meetup because they’re intentionally kept to a small number of people. This allows folks to have an open and more in-depth set of discussions, and perhaps have a more frank and honest debate. It’s an open forum with no upfront agenda.

Look out for the next London Agile Coaching Network meetup.

Baldev Dhadda and Dean Latchana

19 April 2016 – London Agile Coaching meet-up – Teal organisations, SAFe framework and agile podcasts

Joakim Sahlberg, Raghav and I were at the London Agile Coaching Network meetup on Tuesday night . We had a wide-reaching set of discussions.

Here’s some of the areas we covered.

London Agile Coaching Network meetups is different to the typical Agile meetup because they’re intentionally kept to a small number of people. This allows folks to have an open and more in-depth set of discussions, and perhaps have a more frank and honest debate. It’s an open forum with no upfront agenda.

Look out for the next London Agile Coaching Network meetup.

8 March 2016 – London Agile Coaching meet-up – Phoenix Project, BDD and Speccing Sessions

Back on the 8th March 2016, Greg and Veronika came along to the London Agile Coaching meetup. Amongst many things we spoke about The Phoenix Project book, about how BDD isn’t just about testing, and BDD speccing sessions.

Here’s my write-up of the meetup, which I shared with them.

The Phoenix Project book

This is one of the best books I’ve read about a corporate transformation rescue mission. Through a storytelling form it talks about the Theory of Constraints, getting disparate confrontational teams to cooperate, key-person dependencies, pulling all-nighters, and dealing with stress.

At times it’s almost philosophical.

Behaviour Driven Development is more than just testing

Something that Gojko Adzic, the author of Specification by Example, advocates is that BDD isn’t about testing per se.

It’s more about getting a shared understanding of the business problem/opportunity throughout the value chain (i.e. end-user, stakeholder, product, marketing/sales delivery team, operations), and arriving at a consensus in a style that business people understand and in a form with which solutions can be built and maintained.

By exploring the business case together teams form a common understanding, expectation and vocabulary that carries across the business area.

BDD Speccing sessions

One technique for developing the common understanding I described above is to intentionally encouraging divergent opinions. This is something a department in the Financial Times do very well. They use an emergent diverge/converge facilitation technique where a large group of people are briefly introduced to a user story, and then break out into teams (they diverge) to develop the scenarios independently.

After about 40 minutes they then regroup to talk through their thinking. Different opinions and perspectives are valued and discussed. With the guidance of Product, a common consensus is formed (they converge), scenarios and acceptance criteria are documented, which then goes towards building and maintaining the behaviours of the business systems they’re changing.

Quoting Dan North “If we could develop a consistent vocabulary for analysts, testers, developers, and the business, then we would be well on the way to eliminating some of the ambiguity and miscommunication that occur when technical people talk to business people.”

I’ve facilitated such speccing session before. Here’s a few seconds from one I facilitated: https://goo.gl/photos/a947QpEkA7EdXCV6A

About the London Agile Coaching Network

London Agile Coaching Network meetups is different to the typical Agile meetup because they’re intentionally kept to a small number of people. This allows folks to have an open and more in-depth set of discussions, and perhaps have a more frank and honest debate. It’s an open forum with no upfront agenda.

Look out for the next London Agile Coaching Network meetup.

CV / Résumé for Dean Latchana as Senior Project Manager and Scrum Master

Dean Latchana is a Certified Scrum Master based in London. He’s currently employed at MTV Network Europe as a Development Project Manager and has five years experience as a Technical Lead at the BBC.

Professional Summary

An experienced Project Manager / Certified Scrum Master with a track record of leading digital projects. Strengths include: demonstrating to management the benefits of Agile methodologies, thereby enabling them to monitor progress of deliverables, identify project issues and efficiencies; analysing strategic roadmaps to identify opportunities and risks, and ensure business needs are realised and supported; utilising Agile methodologies to lead technical and design teams through the product and software development lifecycle; and utilising business processes for organisational change and governance.

  • Project Management
  • Leading SAFe
  • Agile / Scrum / Kanban Project Management
  • Team Leadership
  • Strategic Planning
  • International Business
  • Product Lifecycle Management
  • Product Launch
  • Process Improvement
  • Risk Mitigation
  • Behaviour Driven Development
  • Software / Web Development Team Leadership

Case Studies

See all case studies

Telegraph

At the Telegraph many delivery teams had different awareness of agile practices. I needed to determine areas where agile practices needed improving, and support them in their transition. Actions included facilitating and improving scrum ceremonies; running team health-checks; improving the delivery lifecycle such as identifying cross-team bottlenecks; mentoring individuals; adoption of SAFe in the department. As a result teams had the freedom to improve, thus enabling them to meet tough delivery objectives. Leadership team recognised and supported the benefits of further agile adoption.

Financial Times

The Financial Times was creating a content API service. Coordination and understanding between product leadership and delivery teams had room for improvement, resulting in some delays and frustration. As Scrum Master, facilitated and drove the adoption of Behaviour Driven Development (BDD). Actions included running business specification workshops; separating ‘specification by example’ from technical planning; adjusting Kanban processes and running retrospectives. Succeeded in reducing ambiguity & miscommunication, and released the correct functionality in a controlled development cycle.

BBC

BBC was behind schedule on delivering a CMS to enable journalists to author new content for a new online product. As Senior Project Manager, brought project back on track. Liaised with stakeholders to evaluate project status and set new priorities; co-created technical delivery plan and training programme; introduced Scrum methodology and Jira task tracking tool to oversee system build; and played key role in system deployment. Succeeded in completing project within 3 months, allowing journalists to publish new content and further product development.

AKQA

AKQA is a key partner for Nike, which had a global marketing platform and wanted to use a CMS to manage products and their global marketing. As Senior Project Manager, modified existing CMS to meet global requirements for Nike teams, campaigns and products. Reviewed and re-vamped internal requirement gathering processes; developed project plan and solution; utilised Scrum throughout project to optimise delivery; and played role in supporting release teams during global product release. Succeeded in modifying CMS, which improved product launch efficiency.

MTV

MTV Networks wanted to roll out Agile methodologies to better prioritise development and rebuild trust between stakeholders and delivery team. As Project Manager, established methodologies and project portfolio. Reviewed operations, defined requirements and created plan to prioritise and mitigate issues; trained delivery team on Scrum process; established technical and business processes; and led execution of and support for various projects. Succeeded in introducing agile approach, which improved project efficiency and strengthened trust between technical teams and stakeholders.

Career History

Telegraph Media Group – Scrum Master (contract)

February 2015 to present

Financial Times – Scrum Master (contract)

April 2013 to January 2015

  • Utilised agile methodologies, led a number of business initiatives across a wide spectrum of the organisation, including
    • Coordination of key disciplines to improve the main CMS, including front-end FT.com improvements
    • Creation of a revenue-generating content API service
    • Implementation of FT Technology’s strategy to create a rapid speed-to-market, self-service delivery platform for all internal developers
  • Managed more than six teams, encompassing developers, integration engineers, business analysts, product owners, technical architects and third party suppliers across many global territories.
  • Reported to the Programme Leads and Head of Delivery
  • Succeed in increasing visibility of project issues, reduced rework & costs. Promoted common understanding and direction through the adoptions of techniques such as BDD, DevOps, Kanban, Scrum and an MVP approach to product development.

BBC – Senior Project Manager (contract)

March 2012 to April 2013

  • Hired to lead the design, development and delivery of several projects to fulfil key product areas for the organisation’s Knowledge & Learning online division.
  • Contributed to conceiving, shaping and delivering several popular BBC online services.
  • Led a team of 5 Developers, 2 Business Analysts, 1 Product Manager and 2 Designers, along with indirectly managing the 3-member CPS configuration team. Reported to Delivery Manager.
  • Directed the development and rollout of a content production system for journalistic output.
  • Led the prototype design and development of a key part of the department’s product ambitions. Team encompassed 2 Developers, 5 Designers, 1 Business Analyst, 1 Product Owner and 1 Technical Architect.
  • Steered users to key BBC product areas by heading the integration of BBC News with BBC Knowledge and Learning online services.

 

AKQA – Senior Project Manager (contract)

September 2011 to March 2012

AKQA is a digital marketing WPP-owned company specialising in creating digital services, products, communications and experiences.

  • Led a cross-disciplined technical team to ensure resources, skills and solutions met Nike’s business ambitions.
  • KPIs focused on: project delivery completion and efficiency, in addition to customer and stakeholder satisfaction.
  • Led a team of 3 Software Engineers, 5 Developers, a Technical Lead, an Information Architect, 2 User Experience Designers and 2 Testers; collaborated with multi-national clients and 3rd-party technical teams to build solutions.
  • Controlled a £1.2m budget and reported to the Program Manager.
  • Orchestrated and managed a programme of work that included supporting new and existing campaigns and product launches, including the Nike FuelBand global launch.
  • Integrated the delivery team with several global development teams (San Fran, Portland, Guadalajara, India, UK) while liaising with client stakeholders and a 3rd-party digital agency.

BBC – Technical Project Manager (contract)

December 2010 to September 2011

  • Hired to take responsibility for a key component of the organisation’s user participation strategy, which included managing technical delivery as well as conceptualisation, definition, development, release and maintenance of the Things to Do product.
  • Managed a 7-member team of 3rd-party Web Developers and Software Engineers, along with a 3rd-party Visual Designer and a Tester.
  • KPIs focused on: project delivery and stakeholder satisfaction.
  • Worked on tendering external agencies as Scrum Master and reported to the Head of Delivery.
  • Determined why the Things to Do project was failing by conducting gap analysis, reviewing data, analysing priorities, filling product requirements, developing new project plan and performing bi-weekly project analysis. Brought project back on track and delivered new product.

MTV Networks – Agile Development Project Manager (permanent)

April 2010 to December 2010

  • Managed a portfolio of projects across several international territories.
  • Ensured that projects were correctly prioritised and resourced as well as met strategic demands; projects included the development and launch of MTV UK’s mobile payment video-on-demand service.
  • Managed a team that included 5 Developers and 4 Designers, in addition to a core group of Subject Matter Experts.
  • KPIs focused on: improving project prioritisation and optimisation, Scrum implementation results and stakeholder satisfaction.
  • Realised major improvements to project effectiveness, delivery and understanding through introducing Scrum methodologies to the digital media and management teams.

Earlier Career

  • June 2007 to April 2010: BBC – Technical Project Manager and Certified Scrum Master (permanent)
  • July 2001 to June 2007: BBC – Senior Web Developer (permanent)
  • January 2000 to July 2001: Xceed Inc – Web Developer (permanent)

Key Qualifications and Training

  • Leading SAFe (Scaling Agile Framework): agile8
  • Behaviour Driven Development workshop lead by Gojko Adzic (author of Specification by Example)
  • Certified Scrum Master: Agile Bear
  • BBC Leadership Training Programme: Ashridge Business School
  • Introduction to Product Management: BBC Academy
  • Coaching in Team Building, Negotiation and Effective Communication
  • Identifying and Confirming User Requirements: The Learning Tree
  • BSc in Biology: University of Sussex

Recommendations

Dean is a dedicated and meticulous Technical Lead with great agile experience, applied with confidence and rigour.

Dean joined the project as Scrum Master at a tricky time during the build but he quickly got a handle on the technical priorities and complexities of the project and worked very hard to ensure the team organised themselves to deliver clean code throughout.

The BBC’s loss it MTV’s gain!

James Webb, BBC Senior Product Owner, 2010

Further recommendations: uk.linkedin.com/in/deanlatchana