I have just run across a web site about applying agile practices, specifically from Extreme Programming (XP) to architecture. This site, called “Architectural Practices – Extreme Project Management for Architects” has a great deal of information.
Continue reading Agile Practices Applied to Architecture
I read an article in Wired yesterday that was modified from a book “Freakonomics
Continue reading Asymmetry of Knowledge and Abuse of Agile Practice
Index cards are an excellent tool to use to optimize communication. There are two primary types of use for index cards.
Continue reading Index Cards as an Agile Work Tool
Pair programming appears to be the most controversial of all the Extreme Programming (XP) practices. It invokes such a violent emotional response in some people that they quickly dismiss all of XP just because of this one practice.
Continue reading Pair Programming in Software Development
Plan driven methodologies which attempt to mechanize the process of doing work are in opposition to the three Agile Work Principles.
We are Creators
A plan methodology attempts to define intermediate and end work products independently of the input and effort of those who perform the work of creating the work products. This disenfranchises people from their work and leads to low morale. It also establishes a heirarchy of value for the people working on an effort where those who create the plans are perceived as more important or valuable than those who execute on the plans.
Change is Natural
This principle is usually acknowledged, but is usually described as a “problem” to be dealt with rather than as a basic principle to be fully embraced. A plan methodology has “change control” or “change management” and “risk management” and puts the whole notion of change in a negative light. This approach also disenfranchises people because they are constantly placed in opposition to reality.
Reality is Perceived
Plans attempt to legislate reality. “Thus and so must the project go” results in a constant struggle between the plan and peoples’ perception of reality. Plans marginalize the importance of perception on the belief that reality can be objectively understood. If reality can be objectively understood, then it can be mechanistically manipulated. Thus results can be pre-determined without regard for the perception of those results.
Waste is the result of activities or environmental conditions that prevent a team from reaching its goal. The opposite of waste is something that adds value (more, faster or higher quality) to the desired result.
Continue reading Eliminate Waste
A few more words are in order about how Truthfulness is the foundation upon which the three Agile Axioms rest. Taking them one at a time:
Continue reading Truthfulness and the Three Agile Axioms
Mishkin Berteig, the founder of Berteig Consulting Inc. and the Agile Advice blog has been listed on the Control Chaos web site as a Certified Scrum Master Practicing. This certification represents acknowledgement of Mishkin’s real-world experience as a Scrum Master. Scrum is a collection of management patterns used to implement agile principles and practices for new product development.
An article called Are You Ready for the Agile Future presents a brief discussion about the role of HR in an agile organization. There are several very good ideas. The basic idea is that the HR function must adapt to the nature of agility. This in turn means, for example, hiring people that are agile, nimble, adaptable etc.
There are however some mis-steps in the article.
Continue reading Agile HR – Sort Of
Two interesting visual presentations of the progress of adoption of Scrum practices. These are marginally software-specific but could very easily be adapted to non-software agile work situations.
http://wiki.scrums.org/index.cgi?ScrumScoreboard
The Agile Manifesto, aimed squarely at software development, is inaccurate when considered against the more general target of Agile Work. The Agile Software Manifesto reads in part:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Continue reading Considering the Agile Manifesto and the Axioms of Agile Work
Summary: In this well-written, engaging book, author Jim Collins describes six critical factors that he and his research team found common in companies that transformed themselves from a long period of mediocre or bad results to a long period of great financial results. Although focused on publicly-traded companies in the United States, the results of this research can easily be extended to apply to other types of organizations.
Good to Great describes the following six concepts:
Some of these concepts are very close to the underlying principles of agile work. For example, in the Scrum methodology, the first five principles are all represented. The Scrum Master embodies some of the attributes of level 5 leadership. A self-organizing team gets the right people in the right position. The daily scrum and the sprint planning meetings are designed to help the team confront the brutal facts. The sprint goal embodies at a local level the simplicity of the hedgehog concept. And the practices in general are a manifestation of a culture of discipline.
Who Should Read this Book? Anyone interested in creating a lasting positive transformation in an organization should read this book. In particular, individuals who are coaching teams or organizations should read this book since the concepts also appear to apply at a sub-organizational level.
This link was seen on a scrum-toronto list, referring to an e-book called Stealth Methodology Adoption. The title is brilliant, and reflects, in my view, a significant means of adoption of Agile technologies at this point in the maturity of this market.
Continue reading Stealth Methodology Adoption
Queues of work form at three types of levels in an agile organization.
At the largest level is the project portfolio. The queue for this level contains all the projects that are not yet being actively worked upon by project teams.
At the intermediate level is the backlog of project functionality. The queue for this level contains packages of business function or infrastructure components necessary to implement business function. These packages are selected by a project team to fit into a single iteration.
The packages in turn are also elements in a queue. This smallest level of queue contains individual tasks required to implement all the business function and infrastructure that make up a selected package of work. The team members select tasks off this queue based on priority and dependencies.
In many agile methods, the queue management approach is fairly explicit at the intermediate and small levels. However, very little is said about the largest level. Some organizations have solved this by limiting the size of projects:
To be successful, high-tech CIOs recommend biting off projects in small chunks…. Gregoire notes that Dell is growing so fast that at the end of an 18-month project, the company would be significantly different from when it began. “A project has to take less than six months [to complete]. That’s the only way we can make sure [it stays] with the business,” he says. (http://www.cio.com/archive/120198/tech.html)
Four weeks ago my wife, Melanie, reviewed a paper I was writing about Agile Work. When I talked to her about it, she asked me why we aren’t using these practices for managing our household.
Continue reading Agile Household Management
