Continuous learning supports agile adoption in enterprises. A culture change can be needed to enable and support continuous learning. There are several things that managers and agile coaches can do to establish and nurture a continuous learning culture.
At DevOpsDays Amsterdam, Mark Coleman asserted that all organizational's cultural changes start with one person influencing another. He finds that Charles Handy's writings on power and influence help on understanding how an organizations works and how one can go on to change it. Mark discussed Charles Handy's six sources of power and six methods of influence.
Writing in the Wall Street Journal, Rachel Shannon-Solomon suggests that most enterprises are not ready for DevOps, while Gene Kim says that they must make themselves ready if they want to survive.
Agile adoption in organizations where command and control is the most dominant management style can be tricky. There have been situations where an agile transition didn’t deliver the expected improvements, or even failed and was stopped. Several authors suggested ways to adopt agile in organizations with a command and control management style. How did you deal with it when transitioning to agile?
The 8th annual State of Agile Development Survey was announced at the Agile 2013 conference. Previous surveys have provided insight into agile adoption. You can participate in the survey, and get the data before it goes public.
Being one of the principles of the agile manifesto, sustainable pace is considered important by many to deploy agile. But achieving a sustainable pace can be difficult, and teams are often asked to improve their velocity. What did you do to adopt sustainable pace with your team? And how did you improve the speed in which your team delivers, and establish a new sustainable level?
Agile methods have the potential of creating great results. But those great results are not a guarantee; in fact anecdotal evidence suggests that those great results are only achieved by a small percentage of those teams and organizations adopting and adapting agile methods. There are invisible requirements for this success. One of these requirements seems to be safety.
In 2006, The New York Times had 20 engineers, all located in a separate building off-site. Engineering and journalism were organized as completely separate entities, even ad sales departments were separate. How do you change a culture like this into a culture where technology drives and supports journalism?
Two video lessons covering agile coaching and organizational change were released by Pearson/Addison-Wesley in the last quarter of 2012. They provide a different way to increase knowledge on agile adoption for visual and audible learners.
Dan Mezick has written The Culture Game – a how-to book describing 16 learning patterns derived from Agile. InfoQ is publishing a series of extracts from the book. The last extract discusses the concepts of of personal mastery and belief change.
Dan Mezick has written The Culture Game – a how-to book describing 16 learning patterns derived from Agile. InfoQ is publishing a series of extracts from the book. The latest extract discusses the concept of tribal learning and tribal leadership.
The fourth extract from Dan Mezick's book The Culture Game is now available for InfoQ readers. THE CULTURE GAME is a tutorial & reference for creating lasting business agility in organizations. This book provides you with specific tools & techniques to help teams (and the entire enterprise) rapidly respond to change, and describes 16 patterns of team-learning behavior.
Organizations have a need for changing the culture when implementing agile. Different approaches exist to spread agile ideas and make changes happen.
The second extract from Dan Mezick’s new book The Culture Game is now available for InfoQ readers. The book examines the lessons learned about creating and nurturing organisational culture, and encouraging culture change. This extract discusses how to map the lessons of agile to any enterprise.
Tony Wong, a project management blackbelt, enumerates some practical points on individual procutivity. This article wonders how well these apply to software development and contrasts his list with that of other lists.