As IÂ’ve discussed here before, Lean manufacturing, typified by Toyota and HondaÂ’s production system of the 1980s, was one of the most influential precursors to agile development practices. Specifically, LeanÂ’s emphasis on ongoing evaluation of the teamÂ’s performance, constant pursuit of process improvement, and continued waste elimination can be directly observed in agileÂ’s tenets of incremental and iterative inspection and adaptation. Tony Baer, an analyst who covers agile, discussed how Lean has become a hot topic of discussion of late among the agile community. According to BaerÂ’s post, this debate boils down to two arguments: Â“First is the contention that value stream analysis will add unnecessary bottlenecks, and second is that software development is a special case to which manufacturing metaphors do not apply.Â”
BaerÂ’s take on these issues tends to align with my own thinking. Firstly, he acknowledges that it does seem a little contradictory for a development methodology that privileges a reactive approach to emerging conditions to place such an emphasis on value stream analysis. However, he still acknowledges the value of this kind of analysis. In the case of the latter argument, Baer cites a concern among developers that software development is categorically different from any other kind of construction or development process that occurs in the real world. Certainly, such criticisms are correct: Software development is not governed by a stable set of physical properties like, say, bridge building is. However, LeanÂ’s valuesÂ—as described aboveÂ—are all applicable to project management, regardless of what is being produced. After all, Lean is essentially a philosophical approach, in which teams and organizations commit to continuous improvementÂ—by reflecting on processes and taking whatever steps necessary to improve them.
Vikas Hazrati filed a fascinating report recently over at InfoQ, in which he discusses an experiment conducted by agilist Steve Bockman. In the experiment, Bockman tasked eight subjects to build a particular kind of paper airplane within a five-minute time box. He then provided three different ways to learn how to construct the airplane: written instructions (i.e. documentation); a completed airplane (i.e. reverse engineering); and step-by-step demonstration (i.e. mentoring). The results showed that a mere 12.5 percent of the test subjects could successfully replicate the airplane design using only documentation, while 25 percent could build it once they had a completed plane to study. However, 100 percent of the test subjects were able to successfully build the airplane when Bockman walked them through every step of the process.
This is especially interesting to me because of its relevance to agile methodologies. For example, in software development, there is a name for step-by-step demonstration: Pair programming. Agile organizations will often pair an experienced developer with a relative newbie so that the less experienced developer can Â“driveÂ” while the veteran developer observes and provides guiding feedback when necessary. Many traditional project managers regard pair programming as a waste of resources (the common criticism is that itÂ’s using two people to do the work of one), but BockmanÂ’s experiment suggests that such an investment in teaching through demonstration or mentoring is infinitely more effective than other means.
What are the most effective teaching methods your organization uses? Have you had experiences that contradict BockmanÂ’s study? Please leave your thoughts in the comments section.
In a recent post at InfoQ, Mike Bria reports on two recent articles by Johanna Rothman which discuss best practices for agile implementation. The right way to go about an agile transformation is a controversial subject, in which some agile practitioners advocate an Â“all-inÂ” approach to adoption and other recommend a Â“toe-dippingÂ” strategy. According to Rothman, both approaches are valid, but what matters is the context in which these approaches are applied. Rothman recommends that an Â“all-inÂ” approach is appropriate, but only at the project level. Similarly, she believes that Â“toe-dippingÂ” is also a good idea, but, again, only at the organizational level.
This is consistent with other literature IÂ’ve read on the subject. And, at least for those who know agile and Scrum well, an understandable piece of advice. After all, by beginning an agile transformation with a by-the-book implementation at the project level, the organization can expand its installation in an incremental and iterative fashion. (Sound familiar?) That is, this method actually harnesses agileÂ’s most important principles to provide a framework for expanding it throughout an organization. For example, just as agile does not require development teams to identify all requirements of a project at the outset, an isolated deployment of agile functions like a pilot, allowing the team to observe impediments and collect requirements (and best practices) as the team makes its way through its initial sprints. Once this pilot team feels it has a strong understanding of project management with agile and has amassed some best practices, itÂ’s time for the organization to take the next step in an incremental rollout and create a second agile project team.
Because agile represents such a significant shift in both how work is done and how teams conceive of work, implementing agile at the entire organization from the outset would likely result in disaster. Considering that the single biggest impediment to successful Scrum adoptions is cultural, beginning with a pilot team allows a supportive buzz to build throughout the organization that will lessen resistance when other teams are asked to adopt agile methods.
I just came across a really interesting read on the Dr. DobbÂ’s site. In Ivar Jacobson and Bertrand MeyerÂ’s article Â“Methods Need Theory,Â” the two consider the natural impulse for the creator of something to tout it as the latest and greatest. Drawing parallels to the fashion industryÂ’s flash-in-the-pan fads, Jacobson and Meyer suggest that software, like fashion, is not immune to the crazes its most influential tastemakers promote. Certainly, software has seen various management paradigms rise and fall in terms of popularity and the majority of their article focuses on todayÂ’s most headline-grabbing trend: agility.
Now, agile has been repeatedly taken to task for being a vague method. After all, itÂ’s really just an umbrella term that collects all the practices that fall beneath it. Of those, several which had their heydayÂ—DSDM, CrystalÂ—have fallen by the wayside. Scrum seems to have emerged the victor in this fight, with its careful balance of structure and flexibility.
One interesting thing to note about Scrum is that it was, in large part, inspired by complex adaptive systems theory, which is, in essence, a theory of evolution. The idea was that Scrum teamsÂ—through regular points of inspection and adaptationÂ—would follow the path toward survival, much like a species learning to adapt in the midst of an evolving climate or food chain. This article, written by Laszlo Szalvay of Danube, a Scrum company, suggests that, if thatÂ’s the case, Scrum has a mechanism built into it to ensure that it stays relevant to emerging conditions.
What do you think? Are Scrum and generalized agile flavors of the week or built to last?
Most agile methodologies were created to be used with small teams who are all located in the room. So what happens in agile environments where there are many teams, some of which are un-collocated, working on complex development projects? The answer is to employ an agile tool. However, agile tools have historically focused on communication and collaborationÂ—that is, they have been most effective at simply uniting team members who are geographically distributed, ensuring that everyone is apprised of task progress and other critical updates. But as agile methods continue to grow in popularity and are increasingly adopted by large organizations, agile management tools must keep pace with the amplified complexity of developing software within such environments.
One of the most common challenges faced by such organizations is program management. That is, because many organizations develop product features that will be utilized across a range of products, it is necessary to monitor progress at the program level (where the completion dates of various product features converge to create the product itself).
Luckily, software publisher Danube Technologies has been paying close attention to the problems faced by agile practitioners working within deeply complex development environments. Its ScrumWorks Pro tool has always delivered great collaboration and task management functionality, but now ScrumWorks Pro 4 addresses the need for a robust program management platform with the concept of Â“Epics.Â” Epics allow users to create cross-product themes at the program level, which, in turn, percolate down to the constituent products. In essence, an Epic is like an uber-PBI, which has its own scope and allows organizations to gauge progress not only at the Epic level, but also across multiple products, a single product, or programs.
This is a major step forward in program management. You can read more about this release of ScrumWorks Pro here or watch a screencast here.