Agile
Velocity: What Is It?
It’s easy to get confused or overly concerned about measuring velocity. Actually, the concept is almost embarrassingly simple. Velocity in Agile is simply the number of units of work completed in a certain interval. Like in many fields, Agile proponents appropriated existing terminology.
Here is one typical definition, from agilesoftwaredevelopment.com:
In Scrum, Velocity is how much product backlog effort a team can handle in one Sprint. Velocity is usually measured in story points or ideal days per Sprint… This way, if the team delivered software for 30 story points in the last Sprint their Velocity is 30.
Velocity as a capacity planning tool used in Agile software development is calculated from the results of several completed sprints. This velocity is then used in planning future sprints.
Agile's Focus on Disciplined Discovery Aligns with SLIM Suite
As more of our clients adopt Agile methods, they often wonder how SLIM-Estimate fits into the Agile planning process? It’s not uncommon for teams to claim that Agile makes estimation obsolete. But regardless of which features end up in a particular release, businesses still need to know how much functionality can be delivered within a given schedule and budget. Because I have been working with more customers to estimate Agile projects, the first Agile planning and analysis practice suggested by Ellen Gottesdiener & Mary Gorman got my attention ‒ Use Three Planning Horizons: Now-View, Pre-View, and Big-View.
Agile Series Part 4: How Software is like a Marshmallow
It’s tempting to do things that you shouldn’t. In software development, unrealistic deadlines and changing requirements often lead teams to make counterproductive decisions, such as adding additional staff in order to achieve a deadline. This not only creates more defects on the current project but also takes resources away from other projects.
Agile Series Part 3: Embrace Change
“The only thing that is constant is change” ~Heraclitus
This proverb is often told to individuals (like me) who love to see a project follow a plan from start to finish. I’ll be honest, I’m a planner. I’m thrilled when the plans I put in motion actually work out the way I intended. These are the moments when I retort, “the only people who like change are wet babies.” However, more often than not, something changes, which throws off my entire plan and forces me to not only revisit Heraclitus’s proverb but also rethink my plan entirely.
Building software, particularly in Agile development, is no exception. In fact, the second principle of the Agile Manifesto states that developers should: “Welcom[e] changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Agile Series Part 2: Stakeholder Satisfaction
When learning something new, people often try to relate the new information back to something they already know in order to help make sense of the new concept or idea. As a psychology major now working in the software world, I’ve found myself relating a lot of what I’m learning back to the psychological theories and concepts I learned in college. Therefore, it is no surprise that upon reading The Twelve Principles of Agile Software, I’ve discovered that many of their principles map to organizational psych concepts.
Agile Series Part 1: The "Typical" Agile Project
After spending the past few weeks working with the Agile projects in QSM’s historical database, I’ve become interested in Agile Development Theory, particularly due to its popularity. While spending days at a time examining our database, I’m left with numerous data-driven questions. Therefore, I thought I would take this opportunity to write a series of Agile-related blog posts.
QSM’s database contains over 100 Agile projects from the U.S. and abroad. The projects include a variety of application types and their top three programming languages were JAVA, C++, and VB.NET. Seeing this, I thought it might be interesting to examine the “typical” Agile project according to our data.
New Agile White Paper - Predictable Change: Flexing the Five Core Levers of Software Development
Imagine we are starting a new Agile project, one that is key to our competitive position. We need to deliver in six months. Our competition is already in the market, so we must at least match them on features and quality. This project is twice as large as other projects we've done recently, but the project is important enough to put our best people on it. Two teams stand out - their velocity is consistently high on the projects they've completed. If we put those teams together, their combined velocity should do the trick! Well, maybe it's not quite that easy.
Webinar Replay Now Available: Shifting to Agile Methods - The Keys for Long-Term Success
If you were unable to attend our webinar, Shifting to Agile Methods - The Keys for Long-Term Success, a replay is now available.
Changes to the software development process, such as moving toward Agile methods, must demonstrate sustainable results over time versus just short-term wins. There are two keys to reaching long-term success that should be considered up front – the new process must be repeatable and measurable.
In this session, AccuRev’s Chris Lucca and QSM’s Larry Putnam, Jr. explore these two keys to success.
Specifically, they cover:
Webinar: Shifting to Agile Methods - The Keys for Long-Term Success
On Thursday, February 16, 2012 1:00 PM PM EST, QSM will co-host "Shifting to Agile Methods - The Keys for Long-Term Success" together with Accurev.
Changes to the software development process, such as moving toward Agile methods, must demonstrate sustainable results over time versus just short-term wins. There are two keys to reaching long-term success that should be considered up front – the new process must be repeatable and measurable.
In this session, AccuRev’s Chris Lucca and QSM’s Larry Putnam, Jr. will explore these two keys to success.
Forrester Survey on Agile Development
QSM has been collaborating with Forrester Research on a report focused on the current state of Agile development. Prior Forrester data shows an adoption rate of about 38% among developers in 2010 and continuous growth YoY in the last three years. However few have really scaled it to the enterprise level. Have you?
To get a better data representation, we encourage to participate in this survey. Tell us about your current and future Agile development plans. This survey will ask questions like:
