Just because you’re doing scrum, doesn’t mean you’re off the hook with finance and management when it comes to giving a real estimate for completion.

Scrum, as most agile processes, takes the approach that cost and time are fixed and that it’s the scope (or features) that are variable.

“You’ll rarely be remembered for missing a feature…but you’ll never be forgotten for missing a schedule”….. Which is why it’s important to make sure that communication with all stakeholders is crisp and that they understand how projects are being scheduled.

Ken Whitaker has written a detailed article on The Agile Schedule posted on gantthead.com.The article is fairly technical and includes concepts such as the “cone of uncertainty”, “rough order of magnitude”, and “definitive scheduling”.When I took the Scrum Master certification course we covered these concepts at a high level. We also talked about backlog grooming and why a good and consistent backlog grooming will do wonders for improving release scheduling. Although backlog grooming is not a formal component of the Scrum process, Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. Everyone should attend the backlog grooming meeting and help the Scrum product owner prepare the scrum backlog for the next sprint planning meeting. Activities during this meeting often include breaking epics into stories, adding stories to the backlog, clearly defining acceptance criteria and more. If this is done on a consistent basis you will greatly improve your agile release planning.

By now, itÂ’s practically accepted that software development and project management, generally, are being re-imagined by agile management techniques. But in a recent article on Projects@Work, called Â“Agile Drivers,Â” CST Angela Druckman explains why that is. As she explains, there are six factors that are driving agility in organizationsÂ—and theyÂ’re changing the way we conceive of doing business. To summarize, the six factors she identifies are:

The Â“heroÂ” mentality gives way to collective intelligence.

Small teams rule.

Stop applying pressure, start removing impediments.

Focus on business value.

Distributed teams are the norm, not the exceptioin.

Roles will change.

Sound like some topics that have been on your mind lately? If so, I encourage you to take a look at DruckmanÂ’s article here.

Over at InfoQ, Deborah Hartmann Preuss reports on the values of games for teaching the principles of Scrum. If youÂ’ve ever attended a Certified ScrumMaster or Product Owner course, chances are your instructor led the group to a deeper understanding of Scrum and agile principles by playing a game or utilizing an interactive exercise. ItÂ’s an effective strategy for communicating difficult-to-grasp ideas in a fun and memorable way and itÂ’s becoming increasingly common for agile education.

IÂ’ve played a number of games over the course of my agile and Scrum education. If youÂ’re responsible for teaching your team or others in your organization, here are a few helpful links thatÂ’ll give you some proof that games are, in fact, valuable and will provide a few ideas for games to try.

Mike Bria recently posted a story on InfoQ discussing how a group of agilistas are arguing for the creation of a new role within agile and Scrum teams called the Â“agile team lead,Â” designed to effectively replace the ScrumMaster and Project Manager positions. For purists, itÂ’s hard not to be skeptical, especially considering the delicate balance of authority and responsibility that marks the composition of Scrum teams. But for the sake of entertaining the idea, the following criteria summarize the groupÂ’s ideas about the duties that agile team leadership entails:

Â“Continuous Leadership
Understanding the team’s place in the organization’s goals, being a single point of leadership (for the team) and accountability (to stakeholders), building a “safe container” for the team to work within, growing trust and respect between team and stakeholders, and continuously improving team cohesion.

Â“Continuous Planning
Ensuring the team become increasing capable of meeting their own established commitments, ensuring everything remain “big and visible”, manages metrics, making “the plan the bad guy” (as opposed to the people), and ensuring the “plan changes with demand/supply”.

Â“Continuous Risk Reduction
Identifying risks and making their “potential impacts big and visible to the right people”, ensuring risk reduction occurs, and quantifying risk management effectiveness.

Â“Continuous Improvement (Agile Coaching)
Driving the “improvement of the overall Definition of Done“, sensing and drawing attention to performance breakdowns, facilitating team improvements in the right areas, and helping the team learn emerging practices from outside itself.Â”

Though several Scrum and agile practitioners have supported this idea, my favorite response belongs to CST Tobias Mayer, who states: Â“Creating a Â‘roleÂ’ of team lead is the beginning of a slippery slope back to command and control, It is a cop-out, an excuse for not facing the real challenge of nurturing a leader-full team.Â”

I canÂ’t help but agree. This role not only seems to disrupt the balance of power in Scrum and agile, but seems to be moving backwardsÂ—toward traditional management practices. IÂ’m curious to know what you think. Would an agile team lead role solve problems at your organization or just create more? Let me know what you think in the comments.

One of the best ways to illustrate how agile and Scrum can transform the way an organization manages its development is through case studies. Rather than simply saying that agile methods will streamline processes, reduce cycle time, and improve product quality, a case study illustrates how agile and Scrum can achieve those things. Moreover, theyÂ’re inspirational. When you can see that someone at another organization has experienced the same challenges and worked through them to successfully implement agile, it gives you the confidence to embark on that journey yourself.

Do you have an agile or Scrum transformation story youÂ’d like to tell? If so, please post them here in the comments. To make things interesting, the person who submits the best one will receive a free iPod Nano.

Please make sure that the story you submit contains the following three sections:

The Problem. What was going wrong at your organization that made you decide to implement agile or Scrum?

The Application. Once your organization decided to use Scrum to surface dysfunction and transform its processes, how did you go about doing it? What were the first steps you took? Was it an organization-wide adoption or just on the team level? Did you use training or tools?

The Solution. What was the result? Can you quantify the improvements that Scrum and agile helped realize? Have other teams at your organization begun adopting agile management techniques?

I look forward to reading your stories. Deadline for submission is Dec. 31, 2009 and please try to keep your case studies to between 500 and 750 words.

Lately, Â“LeanÂ”Â—which derives from the lean manufacturing practices popularized by Honda and Toyota in the 1980sÂ—has been a popular topic in software development circles. Not only does much of agile development have its roots in LeanÂ’s streamlined, waste-averse practices, but Forester just held its Business Technology Forum which focused on the new concept of Â“Lean IT.Â”

Over at ZDNet, columnist Joe McKendrick wonders aloud what this new term actually means and, more specifically, what it means for teams developing software. Citing WikipediaÂ’s definition of Lean IT as Â“vague and convoluted,Â” he ultimately expresses doubt that Lean IT is much more than a new name for waste-reducing activities that agile developers have been using for years. Without a doubt, McKendrick thinks thereÂ’s value in the principles being advertised as Â“Lean IT,Â” he just doubts that theyÂ’re all that different from strategies that organizations are already using. Read the entire post here.

I just saw this post on InfoQ and it struck me as a really valuable offering for the software development community.For agilists, the idea that learning by example is the best way to learn is embedded in such techniques as pair programming, in which an experienced developer Â“navigatesÂ” and a relative newbie Â“drives.Â” Well, now Antony Marcano and Andy PalmerÂ’s project PairWithUs translates that idea into a series of documentary-style segments that capture the two as they program together. In their words, the project is “agile software development (user stories, tests, code and more), broadcast live and recorded for your future viewing pleasure.” As such, each segment provides a screenshot of code coupled with their commentaryÂ—as Marcano and Palmer talk through the problems they encounter and brainstorm ways to overcome them. This is a great way to help spread best practices and offer insight into dealing with various obstacles. You can watch more than 70 segments theyÂ’ve taped thus far here: http://vimeo.com/user1477180/videos/page:1/sort:newest

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.