Grey Smith wrote: I'd rather focus on programming and not "Agile" and a bunch of other "tools" which seem to get in the way of me getting any actual programming done.
Grey Smith wrote:I'd rather focus on programming and not "Agile" and a bunch of other "tools" which seem to get in the way of me getting any actual programming done.
Grey Smith wrote:I can put aside how I feel about a particular corporate policy or process and work within its bounds, but when I'm not at work I don't have to act like I like it. I am sorry if I offended you
Andrew -- I read the 16-page Scrum book Jeanne linked to. To me, how ideas are implemented are far more important that what they are in the abstract. Agile and other systems might sound great or awful in the abstract, but what really matters is how people actually use them. I don't put any stock in abstractions, buzzwords, corporate philosophies, etc., because most of the time they don't affect what actually happens day-to-day. Just a bunch of pretty words to dress something up. I have simple ideas about what makes a good workplace and a productive workplace -- open communication (which has to come from the top first as a sign of good faith), committed workers, and a willingness to talk about and accept criticism are three things that come to mind.
For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intel‐ lectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans.