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.
We recently spoke with Diego Lo Giudice at Forrester Research to share our views on how organizations are measuring the value of Agile. Diego is leading a research effort to uncover how both software vendors and enterprise IT groups are approaching this challenge.
While “Working software is the primary measure of progress” is one of the twelve principles of Agile, working software is not the only measure that software development organizations are using to show progress and to measure the value of Agile to the business. Our own discussions with clients indicate that many try to use velocity and quality (defects) to show that their Agile teams are improving their ability to deliver. A few focus on cycle time or progress to plan. The ‘holy grail’ is to be able to directly connect a software deliverable to measurable business value – improved revenue or decreased business costs.
What metrics does your organization use to measure its Agile efforts? Learn more about Forrester’s research project, or go directly to the survey to share your views (and receive a free copy of the resulting report).
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.
So, without further ado, here are the slides…
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”?
William Caputo wrote a passionate blog entry on why “Software is not an asset” here:
Although I entirely agree with ideas discussed about refactoring and removal of code, I do not think that the blog entry substantiates his claim that software is not an asset. An asset is:
Anything tangible or intangible that is capable of being owned or controlled to produce value and that is held to have positive economic value is considered an asset
Much of the software out there has a positive economic value either in productivity, revenue generation, cost reduction, or other types of economic value. I see removal of code and refactoring code into a more desirable design in order to support changing business needs as essential to countering depreciation of software assets. This was the foundation of Managing Software Debt: Building for Inevitable Change.
When we describe software only as a liability then we also provide reasoning to business that those who work on the software are part of a cost center. This is usually not the best way to operate any software development organization. The focus should be on optimizing the value that existing and newly created software assets support. Rather than only a liability, we can think of assets as what they are defined to be:
Assets are equal to “equity” plus “liabilities.”
The equity can still be there but if the liability is becoming so large that it outweighs the utility of the equity then we have a problem. We should counteract this decay in value by Managing Software Debt effectively as we produce new communications between the software and hardware assets we deploy.
For more information on Innovation Games®, please check out:
- Innovation Games® – play serious games to gather feedback and ideas from customers and stakeholders
- Innovation Games: Creating Breakthrough Products Through Collaborative Play – the book
For more information on Cynefin, please check out the following articles and videos:
- Articles by Dave Snowden – http://www.cognitive-edge.com/articlesbydavesnowden.php
- Podcasts on topic – http://www.cognitive-edge.com/podcasts.php
- Video on Cynefin – http://www.cognitive-edge.com/video-cynefin.php
- Videos on YouTube – http://www.youtube.com/user/CognitiveEdge#p/u (highly recommend how to organise a children’s party)
- Open Source Methods – http://www.cognitive-edge.com/method.php (exercises that can be used)
- Use of narrative – http://www.cognitive-edge.com/articledetails.php?articleid=64
- Safe-fail experimentation – http://www.cognitive-edge.com/method.php?mid=47
Hope this gets folks started in looking at Cynefin and methods around complexity. My one suggestion for anyone getting to know Cynefin is make sure that you don’t look at the “Cynefin Model” and misjudge it to be a basic 4-box model. There are actually 5 domains and a fold at the bottom that have tremendous significance in the model. Not only that, the model is about sense-making rather than categorization. With a focus on these suggestions while learning more about Cynefin I think will help make the experience more beneficial.
As for an experience report from the actual client. A company that I was asked to work with wanted a 2-day Certified ScrumMaster course along with a 3rd day workshop to focus on their specific needs. Of course, during the 2-day class we pulled many specific areas of opportunity and ideas that the group had. The participants were about 1/2 Director and above and the other 1/2 were development team members and project managers. There were about 30 folks in the class and the 2-day class was providing plenty of insights.
One thing that I am focused on in every class is not how can Scrum be implemented but what is the most valuable next steps an individual, team, or organization can make starting the very next day. In the 3rd day workshop we decided to focus on the business goals that implementing more agility would help achieve and a strategy to attain these business goals. Overnight I came up with a loose facilitated session with the following exercises:
1. Impediment Management Exercise using basic facilitation techniques:
- Brainwriting: 10 reasons per individual that Scrum and other agility cannot be implemented effectively at company
- Affinity grouping: on a wall place all items and affinity group them with names to provide context and insights into to the data
- Multi-voting: not a scientific method necessarily, but quick way to get feedback on what is most important on the wall
- Debrief actions to take
2. “Give them a hot tub” – an Innovation Games® exercise (http://innovationgames.com/resources/the-games/)
- Used to identify goals and initiatives that would improve business outcomes focused on software development
3. Ritual Dissent – http://www.cognitive-edge.com/method.php?mid=46
- set up tables with 6-7 folks per table
- each table comes up with a strategy for implementing agility to attain business goals and value of agility (20 minutes)
- 1 person is chosen by table to go to another table and present the strategy for 5 minutes – important that all tables have a chair at the end of it to have the visitor form the other table sit at
- folks at the table that are listening to the strategy are not allowed to speak during the presentation
- at 5 minutes the person presenting turns their chair around with back to folks at table and takes out a notebook
- the folks at the table now ritually tear apart the presented strategy (be sure to tell all of the participants before the exercise that this will be occurring and that their duty is to be as cutting as possible) (3 minutes)
- at 3 minutes the person that presented does not turn around and make eye contact or talk with the table of folks and then just goes back to their own table with all of their notes
- the table uses those notes to modify their strategy (10 minutes)
- the presenter goes to a different table 2-3 more times
- you can end with a round where the folks at the table talk about what they liked about the strategy once it has went through 3-4 rounds but we did not do this (this is called “Ritual Assent”)
- Find out more alternatives and ideas on Ritual Dissent at the Cognitive Edge web site
4. Combine Strategy
- at the end it was fairly simple to pull strategy from all tables and since they shared with each other we decided what the combined strategic alignment and implementation would be presented to executive management
As an epilogue to this, the company did implement most of the strategic plan and found effective changes in their organization even 2 years later since I was there. Hopefully this article provided some opportunities for those facilitating strategic decision-making sessions and added some other options to learn about, Cynefin and Innovation Games® in particular, to your facilitation tool belt.
This presentation is being delivered as a 45-minute lecture and discussion for a company-wide tech talk today. It contains 2 case studies that revolve around moving to a push-button release that reduced the whole product company’s release cycles from 6 months to every week and the effects of a “No Defect” policy on a team’s productivity.
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.