Posts

Showing posts from March, 2015

Can Scrum Teams Have Managers.

"Is it safe to say PM has to acquire new skills to make himself fit in the scrum process? "  This question was asked in a scrum forum on Linked In, and many interesting and valuable answers were given. It is pasted here verbatim because I want my answers to this question to come home with me, and to be available to my clients, peers, and colleagues. The fear of "working without management" or "losing my management job" is pretty fierce in larger organizations, and I think it can be a misplaced or imaginary fear. This answer was specifically pointed to people in a Scrum-specific forum, but information here applies generally in any number of organizational change contexts. Even in our migration to Anzeneering , we have seen/felt the powers permission and support. On to my answers: Strictly, yes.  The biggest and most difficult difference is not telling individuals what to do. It's hard for the individuals at first too. It's easier, onc...

QCon London: Taking back development (Take Agile Back).

Ruud Wijnands and I just completed QCon London. I have a few new contacts, a few new stories, and we were able to present "Take Agile Back" -- a talk in three parts: Take Back Agile: "If this is agile, take it back." Take Back Agile: "Give me my agile back." Take Back Agile: "... to your team."  The point was not to shore up the defenses and protect the whole velocity/timebox/points/meetings nightmare, but to remind people that there were reasons that XP (and scrum) worked, and to return our thoughts to the experiments that resulted in a successful, productive, social process that got stuff done. There are underpinnings to consider. Safety (anzeneering) is one. It has to be safe to experiment in order to do things more intensely. We see people repeat some practices, but deny the right to modify the system via experiments and validated learning. This is a mistake. We need to find o ur own "two questions" and focus on nev...

On The Agile Manifesto

Everyone points to the four "preferences" part of the manifesto and ignores the more important first paragraph, and the far more important second page ("principles"). Key phrase: "We are uncovering better ways of developing software by doing it and helping others do it." That's different than "we are cementing our idea of software development process by teaching it and certifying others to teach it." It's different from "we are making people feel better." It's different from "we don't write documentation" or "we force velocity as high as possible" If we lose that key phrase, we lose it all.