10

If a company is to be Agile, "the entire company" needs to be Agile. It's not something you just decide to do, or actually... decide on the development team to do. It's a change in mindset. For example, you can't keep things like traditional "Command and Control" attitudes in the company's top layers, while placing all the responsibility ...


7

I don't think this is specific to frequent releases (though it does exacerbate the problem I guess) as the main problem is "I used this system yesterday just fine and now I can't find the functionality". These probably should help: Invest in great UX. If the tool is intuitive and convenient people will understand how to use the changes without ...


4

My question is therefore around how such users can be brought along on the journey without imposing delays on the development community, who are tasked with implementing technical change? A useful technique is to apply feature toggles. The developers are constantly releasing code to production, but the features are made visible at the pace the business ...


3

This is a really great question, although perhaps a bit too broad to be a good fit for PMSE. Firstly it must be said that the term agile is too often assumed to refer to the Agile Manifesto for Software Development. At least that's how most people on this site are likely to interpret the word. That's a shame because the Manifesto (dated 2001) embodies ideas ...


2

This is why product owner for one team is a full time job. The product owner doesn't usually just work in isolation, a huge part of the product owner's job is getting feedback and buy-in from all the stakeholders. For a team with internal users, the sprint demo/review is a big help. For the example you give, where there are multiple offices and local experts ...


Only top voted, non community-wiki answers of a minimum length are eligible