Tag / organisational change

by Frederik

Agile Transformation is a strategy, not a goal.

I came across an interesting article on InfoQ, it’s titled “Transforming from Projects to Products“. If you want deeper understanding on topics, InfoQ offers descent and great articles. So I’d like you (someone in any position who plans or is part of an “agile transformation” to read this).

Excerpts of the article:

The general understanding and perception of “Agile” or “agile”

” ‘Agile’ as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed – very successfully – which is likely why you are reading this.  I say this to discourage the notion that ‘Agile’ is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.”

In fact, each company or organisations should be concerned to become more agile (as defined in the dictionary), this is a matter of sound principles and ‘common sense‘ (for example: eliminate waste and become more effective in what you do – certainly in software development / product delivery there are many ways to achieve this).

If an agile transformation is not an end-goal, what is the goal?

Organisations shouldn’t embark on a mission to become agile, without understanding what it takes in terms of cultural and organisational changes – and most importantly: figure out what they want to achieve – why do you need a change?

Questions to be asked:

  • Are your customers dissatisfied?
  • Are your products missing the mark?
  • Do you (or your clients) feel you are not getting value for money?
  • Are you slow to market?
  • If you are creating software products for internal teams are they not having the impact you expected?
  • Are people circumventing your tools?
  • Is your ROI on software development too low?
  • Are you losing key development staff?
  • Is there a lack of transparency in the software development process?

As you notice these questions which concern the whole organisation. Any initiative for improvement should be looked at globally – at an organisational (systems) level – in order to avoid local optimisations.

  • What are the major areas of improvement?
  • Transform from projects to products, including:
    • Stop managing, and start leading
    • Shift from “output” (deliverables), to focus on “outcomes”
  • Embrace the idea there is (and will be) uncertainty, instead of fighting it.

“Agile Product Leadership is about accepting the plan is likely wrong or at the very least unclear and the scope is unknown, and so adapting to change and building the right things to fulfil our customers’ needs.”

  • Reward people based on contribution to a common goal, instead of individual performance

Changing from:
“What will I do today?” to “What can I do to help the team towards our goal today?”
can make a huge difference to behaviour.

Common understanding why we want to change as an organisation

“Your business should be saying:

  • Where do we need to improve?
  • and how will we measure success?

Agile transformation may be a means of reaching that goal.

“If you choose an Agile Transformation you will measure success by delivering what customers need, by creating happy and satisfied customers not adherence to a plan. You will measure teams success by those that are willing to learn and grow.  By empowering teams to make decisions for themselves you can create an environment of continuous improvement.”

Read the full article at InfoQ.

and recall:

Image source: https://quickscrum.com/Images/article_detail/Whyagiletransformationisdifficult-1.png
by Frederik

Managing Agile Teams with Project Managers

Managing Agile Teams with Project Managers.

My thoughts regarding this article on InfoQ:

Indeed – Scrum by the book indicates there’s no project management role. The Scrum master protects the team from outside interference. Any stakeholder must speak to the product owner regarding any type of product “requirement” or “desire”.

In traditionally structured organisation, I see a lot of project overhead: programme managers, end-2-end project managers, IT delivery managers, team managers (business, business acceptance testing, IT acceptance testing, engineering …), project officers.  This is typical for a ‘command & control’ structure, with mostly symptoms such as inefficient and unclear communications, re-communications, re-work, etc.

A project manager can become a Scrum master without problem; given that person has the right mind set and attitude (as listed in the article). Cf. article http://www.agileheads.co.uk/project-managers-can-be-scrum-masters-right/

Project managers probably don’t become product owners very often, unless that person has extensive business knowledge and has the right attitude to be occupied with defining the WHAT (and not the HOW).

It’s a fact a number of items have to be taken care in order for a team to have a swift start (e.g. team composition, resource allocation, facilities, etc.). According to me, a Scrum master could handle these items, before the start of the 1st sprint (or during the 1st sprint in terms of logistics).

Hereby an interesting list of tasks for a Scrum master, cf. article http://agiletrail.com/2011/11/14/42-tasks-for-a-scrum-masters-job/

Among the tasks, the Scrum master certainly is occupied with “the bigger picture”, such as keeping in touch with stakeholders on a regular basis; help the team to report to management; being a contact person for everyone in the team and their stakeholders regarding Agile, etc. You don’t need to keep an end-2-end project manager to handle these tasks.

In the list “Role of a Project Manager”, I do not agree with:

•Manages all aspects of project –The project manager is the captain of the project and he provides end to end support from start to end > Well, if you say so. It does sound a lot like a project manager who wants to be in control and micro-manage. I don’t see the need.

•Does Goal setting – The Project Manager needs to understand outcomes and ensures that they are measurable and realistic > the team with the product owner is setting the goal on a sprint level

•Encourages ‘Team Bonding’ – As the master of the entire project, the Project manager ensures that his team is well collaborated and defines the work by understanding their capabilities > this can be a task for the Scrum master

•Is the Focal point – Finally, the project manager is the single point of contact for sharing and communicating any information related to the project and thus has an important role to play > again this can be a task for the Scrum master

 

According me a setup could be:

An agile team of multiple agile teams, working on the same or multiple products -If the teams are working on the same product, there is 1 common product backlog.

The backlog can be managed on a ‘programme’ level (high-level epics/features), is grouped according to feature-set and becomes more fine-grained on a ‘product’ level.

There’s a central “project support office” supporting the programme/project with all practical matters: global budgeting, resource management, facilities, etc.

 

by Frederik

Agile engineering and collaboration culture at Spotify

When thinking about working/collaboration cultures, and how to transform existing organizational cultures towards agile, we know a lot must change regarding organizational structures, processes, people and their mindset.

Spotify is an excellent example of how the whole company is organized in agile way while adopting the principles, and adapting the practices.

Thanks to Henrik Kniberg for creating and sharing this (original link)

“Agile at scale requires trust at scale”

“No politics. No fear.”

Spotify engineering culture (part 1)

“If everything is under control, you’re going too slow.”

“Minimize the need for big projects.”

“Experimental friendly culture.”

“Waste-repellent culture.”

Spotify engineering culture (part 2)

Update: some years later we see many organisations trying to duplicate the Spotify “organisational model”. Be aware, organisations can try to copy the “structure and entities” but (obviously) this doesn’t make your organisations like Spotify! You cannot simply copy an organisational culture… create your own, based upon your vision, principles and values.

Read: https://www.infoq.com/news/2016/10/no-spotify-model