As the Department of Defense focuses on “delivering 75% solutions in months [instead of] 100% solutions in years” Agile is finding its way into big, traditionally managed programs. This event http://www.afei.org/events/2A01/Pages/default.aspx specifically addresses Agile in Defense. My presentation was an invitation following a successful meeting at the ADAPT meeting and also included tips for making Agile successful. See presentation link below. Several of the speakers were from Defense departments and provided good insights.
The Keynote speaker, Dr. Steven J. Hutchison, provided some compelling information starting with his problem statement. He showed the workflow diagram of the defense acquisition process. Dr. Hutchison also showed some compelling information where test integrates throughout the lifecycle process this includes all testing types including OT and others.
Dr. Robert Charette followed with an solid reminder about risk management. The specific types of risk that Dr. Charette discussed included acquisition and that the acquisition folks must be involved. Dr. Charette also cautioned us that several good past change efforts have failed.
Mr. Tony Stout did an excellent job focusing on the people the qualities of good teams and how to build a quality workforce, specifically in Agile environments. This was the second speaker from a test focus. I find this refreshing.
Mr. Ronald Pontius is heading the Council on the changes to governance in order to support agile development. Mr. Pontius updated us on the responses from several agencies and working groups to support section 804 http://www.defense.gov/pubs/pdfs/804Reportfeb2007.pdf.
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.
Last week I did a talk in Lynnwood, WA with the Puget Sound PMI chapter on “Integrating Quality into Project Portfolio Management”. I feel that the slides were the best yet in providing specific indicators and understanding around the troubles with scaling Agile methods and in strategic decision-making at scale. Although stage, phase, or “gated” approaches don’t provide a better answer than Agile methods, they provide an illusion of knowledge and control that Agile methods do not initially bring to the table. This talk goes into patterns for scaling Agile across an organization, the issues inherent in scaling, and ways to identify, specifically from a quality trend perspective, if there is troublesome waters ahead on specific project endeavors. The focus is on those quality indicators being found amongst all the noise in scaled projects to figure out if the project should be re-committed to, transformed, or killed (reference from Johanna Rothman in her book “Manage Your Project Portfolio”) so that value can be optimized.
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.
An ex-colleague of mine, Santosh Kolhatkar, wrote up the following points about introducing an Agile approach inside a large enterprise with an existing traditional SDLC process. What he points out in his writeup regarding a foundation for introducing an Agile approach when there is a heavy focus put onto SDLC compliance and governance is in alignment with what I’ve found to be useful in supporting such efforts in large enterprises. With Santosh’s permission, I have posted his ideas on the subject and thought that it would be useful for some readers of our blog:
Agile is now making waves in the sea of other methodologies and paradigms. Practitioners at the enterprise level are taking note of the new kid with the new shiny toy on the block. And the sharks are circling the waters.
We ran in to this situation at several of our client’s environments. The SDLC processes were so much entrenched that the Agile approach seem to be very radical to those practitioners, so some of the leaders got together and came up with an approach that seem to be less threatening to those paradigms.
The major steps that were taken:
Involve key members of that community.
Identify ‘must have’ components. These are the areas such as compliance, security etc.
Make a list of differences between processes and get feedback from the key members.
Get an agreement on how the existing SDLC and Agile methods will work together. Handoffs and managing the dependencies is crucial.
Outline of before and after an Agile framework is deployed.
Provides an overview of what to expect for the teams that are thinking of using an Agile approach.
Summarize the differences between the existing SDLC practices and Agile framework.
Bring the existing SDLC and Agile methods under one umbrella.
Offer as a one stop shop for the practitioners so they can choose to go SDLC or take an Agile approach.
Have a combined launch of the latest SDLC version and the Agile framework.
Use existing communication channels to reach out to the enterprise audience. People are used to looking for processes and procedures at one location. Using the same location or method will get better results in communications.
Implement ability to push Agile metrics onto program management dashboards.
Agile metrics should be able stand on their own but provide enough visibility that leadership looks for in their conventional metrics.
The metrics should be more real time and close to the actual state of the projects/ programs.
Have an executive sponsor who can serve as Champion for the new Agile framework.
Provides air cover for the adoption of the new Agile framework.
Provides a stamp of approval that is a must in a enterprise environment.
The above areas are minimum needed to make adoption of Agile feasible in enterprise environments with an existing SDLC process. Some combination or extension of the above steps will have to be made to suit specific enterprise situations.
The presentation had too much for the less than 90 minutes that we had for the session. I did not get into scaling Scrum team patterns and heuristics to manage software debt at scale and also less around testing than I’d hoped. Hopefully it was useful for the participants and they got at least one new idea leaving the session. It is difficult to take a 1-day workshop and create a less than 90 minute talk, as I learn again.
This week, an interview from SearchSoftwareQuality.com with me came out on the book Managing Software Debt: Building for Inevitable Change. The interview has 2 parts. The first is a discussion of software debt and the second focuses on addressing software debt. Here are links to the interview:
The Agile Triangle, a concept that was discussed by Jim Highsmith in his book Agile Project Management: Creating Innovative Products, describes how teams and organizations can go beyond the traditional Iron Triangle in defining project success criteria. In the Agile Triangle, the traditional project constraints of schedule, cost, and scope are confined to one point of the triangle. Balancing out the triangle are quality and value. Agile software development practices have provided huge innovations in delivery of working software from an internal and external perspective. Practices such as automated unit testing, Test-Driven Design (TDD), and Continuous Integration (CI) have transformed our industry and enabled new go-to-market strategies for the business of software products.
When looking at the Quality point on the triangle, this is where I see the realm of Managing Software Debt providing a strategy to support greater value generation within the defined project constraints, as shown in the diagram above. Creating a software debt management strategy involves thinking about feedback mechanisms for each type of software debt: technical, quality, configuration management, design, and platform experience. For technical debt, which tends to be focused on code, we can use tools such as Sonar to provide feedback on changes. For quality debt, we can look at defect containment metrics, bugs escaping iterations and into releases, as a feedback mechanism to trend. Configuration management debt could include the ability for an application to use 2 scripts, deploy and rollback, for all environment deployments and promotions along with monitoring branching in source control for potential integration issues (Sonar is integrating this capability, as well). Design debt can be monitored using Sonar and design assertion frameworks such as TisUgly for Java that I created and never marketed well a couple years ago. Finally, we can monitor the effectiveness of our platform experience debt management strategy based on impediment resolution cycle time or other team and management measurements.
This last point about impediment management is incredibly important and doesn’t get enough attention in the Agile community, in my opinion. In fact, as someone who is experienced in supporting enterprise Agile adoptions for defined business objectives, impediment management can be a critical element of sustained Agile software development effectiveness. When organizations hit a wall with impediments, mostly organizational impediments to delivering increased value to customers, they become susceptible to reverting towards past practices to reduce noise and ignore the effects of these impediments. The diagram below shows how impediment management is a wrapper around the Agile Triangle to support increased and sustained value delivery over time.
Impediment management comes down to communication. How are impediments raised? When impediments are not within the team’s realm of control to resolve, how does management support their resolution? At enterprise scale, is there a need to provide visibility to more than 1 or 2 levels higher in the organization? If so, how do these enterprise impediments get handled at strategic levels in the organization? What is your impediment management strategy?
Please let us know your thoughts on the relationship of impediment management and Agile Triangle. Also, tell us in the comments section how you see impediments managed in your organization. What is going well? What could be improved? How are they escalated? We look forward to hearing your thoughts and experiences.
We are truly excited that AgileEVM has been chosen as 1 of the top 12 finalists for the First Look Forum, an event put on by Northwest Entrepreneur Network (NWEN). The entire process has been an amazing and informative experience thus far. We have received coaching from some of the best in the NWEN community on our business plan, executive summary, product pitch, and much more already. If you are part of a startup that does not already have funding and want to learn how to hone your business, we definitely recommend being part of the next NWEN First Look Forum.
Real World Application of Agile and Lean in Technology and Business