Näytetään tekstit, joissa on tunniste Agile Enterprise Scrum motivation. Näytä kaikki tekstit
Näytetään tekstit, joissa on tunniste Agile Enterprise Scrum motivation. Näytä kaikki tekstit

torstai 14. huhtikuuta 2011

Agile in Enterprise

Brief comment on Agile vs. Enterprise, being an Agile fan and Certified ScrumMaster working in a huge organization (mostly from Scrum point of view):

The IT Skeptic wrote

"Both Agile and Lean seem based on a rosy view of human behaviour that many in IT Ops would regard as naive.

The concept of small teams seems to be predicated on Renaissance Man, the miracle polymath who can fulfill multiple roles and leap tall buildings; who is seemingly skilled at most things, and interested in everything else. Human progress can be put down in large part to specialisation, and Agile seems to want to put that into reverse. Developers who understand operations; wild creative types who respect risk mitigation; project managers who are relaxed about changing deliverables; programmers who are good at supporting and training end users; system geeks whom can focus on business value; hackers who document."


Then on other hand take Daniel Pink's great TEDTalk where he nails down with scientific research how only intrinsic motivators - autonomy, mastery and purpose - drive knowledge workers for better performance solving complex problems: http://www.ted.com/talks/dan_pink_on_motivation.html


I think Skeptic is totally right - and totally wrong. It's all about applying right methods in right places. As Pink points out traditional ways of working with extrinsic motivators kick ass for Simple Problems and running a production system is such - mostly. It's not about coming with great new ideas so it's not necessarily an optimal place for Agile. Agile needs autonomy and if your environment cannot cope with it, don't do Agile. Agile, and Scrum especially work best for time limited projects developing new solutions, where autonomy can be allowed.

Besides, lot of IT projects nowadays are actually taking off-the-shelf products and then customizing them (as little as possible) to meet customer requirements. Agile works excellent for this kind of project needing prototyping and then finding best balance in the traditional time, cost, features -triangle.

Skeptic's disbelief in finding those Renaissance Men people for Agile projects is partly sound. They are hard to find, and having a team of them is dream scenario. But Agile is Agile, it can and should be adapted to situation and limitations every time. If team is not self-driven, take more control. If it's not multi-talented, make sure to fill the gaps with extra resources. Also when money is involved there will (or at least should) be some stakeholder control, project and budget management frameworks one needs to adapt to etc. Pure Agile is actually rare, trade-offs must be made in Enterprise world. This puts lots of responsibility on the shoulders of Agile coach (ScrumMaster), who should be able to handle and adapt to the situation. In the end his/her professional skills can make or break the project.

Then on the other hand there's too much Agile abuse. IT industry is in love with Scrum and every project must be Scrum now - too often without proper knowledge, consideration and real empowerment for the team. Project doesn't become Agile by calling it Scrum and having stand-up meetings every now and then. Seeing people stating day after day same status reports (i.e. "I haven't done anything"), hearing "We don't write documentation, we are Agile" while calling it Test-Driven Development without anybody actually testing anything is far too common.

ScrumMasters, take pride in making Agile work.


Wikipedia on Motivation