Category Archives: Agile Methodology

Effort Estimation and Story Points Demystified

I recently worked with some teams in India that were obsessed with effort estimation.  It turned out their real problem wasn’t estimation, it was keeping the product in a properly tested, shippable state all the time — the basic requirement of Scrum.  If the product is always shippable, and the user stories are always small, and the Product Owner is always prioritizing, we can always ship a product with the important stuff in it.  If we get some estimates wrong, it just means we’ll omit the less important features.  This isn’t a perfect situation, but it’s much better than what most companies do: ship late, or ship untested.

Agile teams generally use relative estimation approaches such as story points, sometimes a Fibonacci scale, sometimes an exponential scale.  To learn how, watch this example of a Backlog Grooming Meeting.  Note that the Scrum team does not pay much attention to the points during the example Sprint Planning Meeting.  They are mostly to help the Product Owner make forecasts.

 

Playing it SAFe, Can a Large Organization Become Agile Without Changing Anything?

We’ve noticed someone selling a prescriptive approach to large scale Agile that actually appears to be 80% waterfall.  An 80/20 waterfall/agile hybrid approach may be a positive step, but we’re concerned that this scaled agile framework confuses people about what a truly Agile approach to large scale development would be.
Let’s examine some principles from the Agile Manifesto:
  • Business people and developers must work together daily throughout the project.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
On the other hand, the easy, safe prescription for scaling seems to deliberately institutionalize some bad ideas we usually call impediments:
  • A three layer stack with proxy Product Owners in the bottom layer, enmeshed in coding teams.  Somewhere above the pseudo-Product Owners, other silos contain the stuff we usually consider Product Owner work: vision, product management, release management, portfolio management.  In our experience it’s better for self-organizing teams to work directly with the *real* decision makers responsible for the vision as it emerges.  The Scrum Product Owner was never supposed to be an artificially elevated middle manager.  According to Kent Beck, the first known XP project failed because the “Goal Donor” was not the “Gold Owner.” We want regular face to face contact between business decision makers and development teams so all learn from each other.
  • Teams contain “Developers & Testers” but UX, architecture, integration (by the “System Team”), and “release train engineering” occur elsewhere.  In Scrum, these are team responsibilities, so we want truly cross-functional teams, usually with business requirements experts, UI/UX designers, etc. right on the teams.  Scrum encourages a rigorous definition of done.  Teams will be more Agile if they learn to integrate their work with other teams. This will be difficult at scale, but coordination roles only make this worse.
  • Somewhere up in the whipped cream layer of this cake we find czars such as the “Enterprise Architect” working on “Architectural Epics” guaranteed to lead to architectural bloat.  I assume this was created to appease senior technical guys who have grown rusty at everything but PowerPoint.  One place I worked with found their (waterfall era) Architecture Center Of Excellence ivory tower to be such a huge impediment they disbanded it and put the architects right on Scrum development teams, right in the team rooms.  An assigned “architect” role is utterly incompatible with the Agile principle “The best architectures, requirements, and designs emerge from self-organizing teams.”  Scrum teams are responsible for the design of the software they build.  If we must use multiple teams on one product/portfolio and we believe in team self organization, ScrumMasters must create environments that encourage teams to coordinate with each other through communities of practice, not implementation czars.
The 20% of this that’s Agile is the stuff that’s relatively easy to change in an organization: putting testers on the teams (except not integration testers evidently), working in iterations, acknowledging that architecture will evolve, and co-opting (occasionally abusing) Agile jargon.  Maybe a couple steps forward for some orgs, but far from ideal.  I think it will appeal to companies that are concerned with keeping cozy spots for everyone, avoiding the uncomfortable ambiguity and uncertainty where real breakthroughs occur.

Agile and PPM – Q&A

On October 27th, I co-presented the webinar, “A Marriage Made in Heaven: Agile and Project Portfolio Management”, with Russ King, Vice President, Product Development, Results Positive, Inc. and Caleb Brown, Systems Engineer at CollabNet. We explored the benefits of marrying Agile Project Management and PPM and we did a live demo showing this using HP’s PPM solution and CollabNet’s ScrumWorks Pro to demonstrate the powerful capabilities of managing a resource constrained project portfolio.

Judging by the number of questions, the audience was clearly heavily engaged. We had a 15 minute Q&A and did not come close to answering all of the questions, so I’ve listed most of them here and provided a response. I also encourage you to try ScrumWorks Pro for free.

As promised, here’s the follow up to the live audience questions.

Q: How feasible is Agile on Projects & Programs?
A: Agile is typically thought of in the context of individual projects. Companies sometimes fail to scale that paradigm to a program level, where the program is a superset of multiple projects, each running its own lifecycle and release plan. The trick is to weave those separate lines of development (projects) into a coherent and seamless deliverable (program). The complexity comes in gathering meaningful metrics and planning releases that thread the elements together. This is exceedingly difficult to do manually. CollabNet’s ScrumWorks Pro is a tool that can make this manageable. It supports the planning of complex releases that weave in multiple development threads.

Q: Will this process will be feasible for maintenance related projects (Incident handling, less than 8 hours development works, etc.,)?
A: From the PPM perspective, an individual defect is not in and of itself a project and as such, would not be tracked. What might be tracked is a larger group of maintenance items in the form of an Epic. From an Agile perspective, a bug report or defect is just another piece of deliverable business value, like a User Story or any other Product Backlog Item. From a bug report, the product owner and team would create a Product Backlog Item (PBI), along with success criteria (definition of done). It is prioritized against all of the other Product Backlog Item by the product owner. Again, multiple bugs/defects are often grouped in an Epic.

Q: It seems the PPM is geared toward a waterfall process. It appears there is only visibility into the Development phase, but with agile, you could potentially address all phases within a single sprint. Is that just because of the way this implementation was set up or is it there isn’t a true marriage of the agile within PPM?
A: PPM in this scenario is focused on evaluating the ROI of different projects and deciding where to make investments. Agile is focused on execution of the projects that are chosen. That said, the scenario we propose makes the entire organization more Agile, in that the feedback loop is instantaneous. This allows those that are making the investment decisions to adapt and make course corrections that are indicated by that feedback loop. The integration gives all team members the ability to work in a more Agile fashion, and gives Stakeholders and Project managers the ability to benefit from the faster feedback and data generated by the team working this way.

Q: Can the tasks in Scrum WorksPro be connected to tasks, timelines in Source forge?
A: Not with Sourceforge. However this is possible with Collabnet Teamforge, the current commercial version of Sourceforge.

Q: Can you clarify what part of Agile PPM can be done in scrum works pro without need for HP PPM?
A: ScrumWorks Pro is focused on project execution and project management. As such ScrumWorks does a number of things not accomplished in HP PPM. These include PBI tracking and prioritization, Task management sprint planning, release planning, team velocity, forecasting, and many other functions related to the management of an Agile project.

Q: So are you proposing (in the demo) to combine a phase/waterfall planning and design phase, but then execute in an agile framework?
A: Combining HP PPM and ScrumWorks Pro adds to the agility of the entire organization. Feedback loops between the development team and the PMO are enhanced allowing the PMO to make course corrections required. I would not say that as a result the entire enterprise has become agile – only that they’ve become more agile. Generally, we do not see many organizations that practice a pure version of ANY methodology –be it Agile or otherwise. The reality is that organizations have a mix of methodologies, like Scrum, Kanban, Waterfall, hybrids, etc. Different teams in large organizations will often build software differently, so the challenge is to roll up the data from those disparate teams. Despite their differences, there are a number of common metrics you can track regardless of project type. These include actual cost versus budgeted cost, scope change, personnel/resource change, delivery dates, and others. Tools like ScrumWorks and HP PPM do a good job in tracking these kinds of numbers.

Q: Continuing from the first question, from a portfolio perspective, having “”open-ended”” project budgets within the Agile/SDLC process is not in the best interest of my customer. How does budget planning and Agile development work together while still having some control over costs?
A: Project prioritization and the associated budgeting/funding are is under the purview of the PPM tools. The agile project management tool tracks the amount of time individuals spend on the project. The integration between the HP PPM tool and the Agile Project Management tool, allows you to easily compare budgets against actuals.

Q: In agile, what are the differences between being adaptive to late changes in requirements within a sprint and scope change?
A: Scope change refers to any added or subtracted scope, typically measured in some form of relative effort unit like Story Points. As such, scope may be added as a team discovers more about an existing requirement. In other words, if the team finds out that a requirement is more complex than was originally envisioned, they may re-estimate the number of story points and this might add scope to a sprint. The opposite could also be true. Whether this occurs because of a discovery inside a sprint or outside of it doesn’t change the nature of how it is tracked or reported upon.

Q: When a committed backlog item could not be completed in a sprint, naturally it holds the top most priority in the following sprint. How does ScrumWorks helps in tracking this item from the beginning to end?
A: An unfinished PBI may or may not be a high enough priority in a future sprint. The determination is made by the product owners. In any event, any activity against that PBI is tracked. Tasks completed that relate to that PBI are tracked, as are those that were uncompleted.

Q: What certification do CollabNet-trained scrum masters receive?
A: Those who attend one of our Certified Scrum Master or Certified Product Owner training are eligible to take the exam deliver by the Scrum Alliance. It should be noted that CollabNet is one of the leaders in ScrumMaster product Owner training. We have more Certified Scrum Trainers on staff than any other vendor, and we’ve trained more than 12,000 ScrumMasters.  We also give away free online Scrum Master training to supplement the certified training.

Q: If an organization wants to be able to report a metric of time to resolution for individual PBIs, what settings are available in this integration to include/exclude a PBI from the current active lists so that a countdown starts appropriately?
A: Forecast reports in ScrumWorks can be filtered on any number of aspects, allowing a user to deliver estimates on individual tasks, Stories, Epics or Themes. By the way, you can try out ScrumWorks Pro either in a hosted environment or as a free download.

Scrum Coaching for Agile Success

The Scrum Alliance has published a new whitepaper called “Coaching is Key for Scrum Success” which outlines some of the problems organizations face when implementing Scrum, how Scrum coaching can help, and what to look for in a Scrum coach. Most organizations run into issues when first implementing Scrum. Rather than let these problems continue to plague the Agile implementation and jeopardize the risk of success, many organizations find that working with a Scrum coach early in the process helps to avoid “Scrum-But” and reverting to old ways of doing things. Scrum coaches can also help to minimize learning curves, resolve organizational impediments and identify potential stumbling blocks early on. Scrum coaches help to streamline agile transformation by bringing an outside view of the organization to remove intrinsic bias and taking the time pressure off the product line managers by providing guidance and management of the Scrum implementation.

What should you look for in a good Scrum coach? First, a good Scrum coach should be experienced, accredited and an active and respected member of the Scrum community. They should be knowledgeable about Scrum and organizational cultures and exhibit strong leadership, collaboration and communication skills. Lastly they should be inspirational and able to inspire teams to change and try ways of doing things. If you are interested in reading this whitepaper you can download it for free on the Scrum Alliance website: http://www.scrumalliance.org/resources/1879
If you are interested in learning more about private coaching and what it can do for your organization, we invite you to talk to one of our Scrum trainers and coaches. Visit http://www.danube.com/company/bios

Release Planning Using Agile

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.

How is Agile Changing the Way We Work?

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.

Share Your Story

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.

Lean IT

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.

Learning by Example

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

How Do We Learn?

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.