If you haven’t already checked out our FREE online service, ImpedimentMonkey.com, then check out this overview video describing what it can do for you, your team, and those that you collaborate with to increase the habitability of your team’s delivery environment and deploy continuous improvement on a daily basis.
Last night I spoke at SeaSPIN on the topic “Dollars and Dates Are Killing Agile”. The focus of this talk is how we can speak more like business with the benefit of building organizations that are more supportive of adaptive planning, continuous improvement and team empowerment. If we do not speak the language of the business and continue to create friction without enabling strategic planning needs that businesses have then we are bound to see Agile methods have a short lifespan in most organizations. Below is the topic description and slides:
Agile teams speak in points and iterations, but project and business managers think in terms of dates and dollars. This conceptual and language barrier makes strategic business planning, funding, and project status reporting a significant challenge for Agile teams. Because of these barriers, many successful Agile/Scrum initiatives are discontinued or never expanded.
On November 1st at 2:00pm ET (11:00am PT) for about 45- to 60-minutes, Gil Broza will have me on as an interview guest on his series “Spot On Business” talking about “Agility for the Long Haul”. You may sign up at http://3pvantage.com/csterling/saveMySeat.php?ver=SC to be part of the conversation. Here is a brief description of the interview topic:
If you’ve already started using Agile methods, surely you’ve seen just how much change and adaptation are involved — already at the single team level!If you’ve already applied Agile methods across a program, or several unrelated teams, you’d have noticed that their performance is constrained by downstream and upstream functions. Your teams are likely saying, “We need marketing and sales and the business units and operations to also act like us in order to really make an impact.”And if you’ve been using Agile for more than a couple of years, is performance still great, or is it eroding? Are the Agile mechanisms slowly giving way to “business as usual”?
This product goes along with our first product, AgileEVM, to help companies take advantage of Agile software delivery methods at scale for increased business value and reduced risk on project investments.
Impediment Monkey will make removing roadblocks to daily progress fun and effective. Impediment Monkey takes in, notifies, helps in resolving and makes bashing impediments exciting and objective. Additionally, Impediment Monkey will let you assign, follow up, chart trends and even provides services to support your impediment bashing efforts.
Go to the Impediment Monkey web site and sign up to keep informed and potentially become an early beta tester of the product. We are looking for your insightful feedback to make a product that is fun, effective, and provides expertise to the software development industry. Join us in making it happen.
Matt Heusser, on behalf of InformIT, conducted an interview with me regarding the book Managing Software Debt: Building for Inevitable Change. We discuss what software debt is, some ways that it can be managed, maintaining a single list of work, how software debt is measured, and we even got into training and our product AgileEVM.com. You can read the interview at http://www.informit.com/articles/article.aspx?p=1684785.
Kelly Waters is now providing a great service to the Agile community by integrating content from talented writers and thinkers at All About Agile. If you are interested in furthering your knowledge about tools, practices, process, and people in adopting Agile values and methods this could be a great spot for you. Thank you, Kelly.
I am quite happy about the book that took much of my time over the past couple years has finally come out. Thank you Addison-Wesley for asking me to write a book. Also, I want to thank Jim Highsmith and Alistair Cockburn for accepting the book into their Agile Software Development Series. Finally, I have to thank all of those that have guided, influenced, and supported me over my career and life, with special thanks to my wife and kids who put up with me during the book’s development. My family is truly amazing and I am very lucky to have them!
To get towards continuous deployment, or even continuous validated builds, a team must take care of their automated build, test, analyze, deploy scripts. I always recommend that you have 2 scripts:
And that these scripts are used many times per iteration to reduce the risk of surprises when deploying to downstream server environments, including production. The following diagram shows a generic flow that these deploy and rollback scripts might incorporate to increase the confidence of teams in the continuous deployment of their software to downstream environments.
The incorporation of continuous integration, automated tests (unit, integration, acceptance, smoke), code analysis, and deployment into the deployment scripts provides increased confidence. Teams that I have worked on, coached, and consulted with have found the use of static code analysis with automated build failure when particular metrics are trending in a negative direction enhances their continued confidence in changes they make to the software. The software changes may pass all of the automated tests but the build is still not promoted to the next environment because, for instance, code coverage has gone down more than 0.5% in the past week. I am careful to suggest that teams should probably not set a specific metric bar like “90% code coverage or bust” but rather that the trend of any important metric is not trending in the wrong direction.
Please let us know how your teams move towards continuous delivery or at least continuous deployment to downstream environments with confidence in the comments section of this blog entry. Thanks.
As teams start to use Agile methods for delivering software, it is common for the business to ask for a summary of progress. This is not always easy to do for Agile teams. Teams may have an Agile project management tool, hand-drawn burn up charts, task boards on the wall with other information radiators or spreadsheets where the information about delivery thus far is kept. Teams might even duplicate data in multiple tools so that they are able to generate information for management without inhibiting the team’s progress by making them update more than 1 tool.
AgileEVM allows teams to take the outcomes of their iterations as evidence of delivery and then generates progress reports for the release. The most commonly used report element is the Release Forecast Chart as seen below. It has similar characteristics to a Release Burnup Chart but adds a risk window as Dave Thomas had described in his keynote at Agile 2010. Rather than only showing progress towards a target based on units of work and iterations, the Release Forecast Chart also shows forecasts based on optimistic, pessimistic, and when under volatile conditions. These provide a more holistic picture of the current release progress along with an understanding of the potential risk to plans.
The 5 data points that a teams needs for each iteration are:
- Points committed to at beginning of iteration
- Points delivered in the iteration
- Scope change in the release (either positive or negative)
- Did the team meet their Definition of Done
- Actual cost of iteration (i.e. # of team members * cost per hour * # of hours in iteration)
Most of this information is already part of an Agile team’s iteration data. The addition of actual cost can usually be pulled from your finance department or wherever time tracking against the project is maintained.
Upcoming posts on AgileEVM will describe:
- How an estimated Release Baseline can be developed using simple techniques with your team
- Adding your Definition of Done in AgileEVM
- Managing impediments across your AgileEVM portfolios
- What indicators and advice AgileEVM provides to users in the progress summary
- and Understanding what “under volatile conditions” may mean to your release progress and response to the information