As some of you have already begun to notice, the Rally Engineering team is now in full effect with their very own Blog.
This blog provides a great opportunity to (1) gain further insight into Rally’s development environment, (2) ask questions and interact with a high performing Agile engineering team and (3) learn tip’s and tricks from the team’s experience working in a wide variety of technologies.
I have read all their posts and there is something in there for all the rolls and levels of experience on agile teams. It is unique because of the open authoring model for all members of a fast growing set of agile teams.
We received lots of great questions and shared them with the webinar attendees, but thought they would also be valuable to other Agile practitioners. This first series of questions tackle the obstacles of adopting Agile. Stay tuned for the remaining questions in later posts.
What are the biggest blockers you see to good Agile?
DW – My pet peeves are people that resist change without really thinking about it. That treat software like car production and think that you can plan, deliver in that manner. These same people often lament the ability of the software teams to deliver good code at the right price. Software is a fundamental part of business change – If you need a new part to your business it will most likely require software, which may require development and integration. Connecting up their development with the people who have the problem is the first step to success, empowering teams to try new things and question the status quo in support of those business needs is key. Organizations that put artificial walls between the problem and the solution are the biggest blockers. These may come in the form of planning processes, business access, travel budgets, governance models, standards or culture.
RAM – Good Agile development is a mindset change like Dave is describing above. Overly aggressive or passive plans are the biggest blockers to “good Agile.” You need to think about this change as incremental and iterative with a strong focus on continuous improvement and learning through inspect and adapt feedback loops.
Before I dive into Part 3 on my series about Agile Process Overhead, I wanted to review where we are and interject a little wisdom around all of this.
You may recall that I had a client come to me with great concern (frustration?) about all the “overhead” in adopting Agile. Specifically, they wanted to address:
What goes in the Sprint Backlog?
How do you allocate your time effectively?
How do you “plan” for unplanned work?
Each of these seemed to cause a lot of overhead for their ScrumMaster and the team. That confused me and so I decided to post some ideas about them. I addressed the first bullet in Part 1 of this series, and the second bullet in Part 2.
So let’s take a break before moving on to Part 3,: “How do you ‘plan’ for unplanned work?” Here is what I want to raise as a guiding mental model: the 5 Orders of Ignorance. This may appear to have nothing to do with the perceived process overhead with Agile. I think it has everything to do with it.
If we are looking at process overhead, I think applying the 5 Orders of Ignorance is great guidance:
0th Order Ignorance: Lack of Ignorance
I (probably) know something
1st Order Ignorance: Lack of Knowledge
I do not know something
2nd Order Ignorance: Lack of Awareness
I do not know that I do not know something
3rd Order Ignorance: Lack of Process
I do not know a (suitably effective) way to find out that I don’t know something
4th Order Ignorance: Meta-Ignorance
I do not know about the 5 Orders of Ignorance
Where do you think the troubled team is in the 5 Orders of Ignorance when they are struggling with Agile Process Overhead in the guise of an overloaded Sprint Backlog, allocating team members, and planning for unplanned work? How do you think Agile and Lean approaches actually directly impact the 5 Orders of Ignorance? And, in so doing, can you see ways that, in attacking the 5 Orders of Ignorance, they directly impact costs to teams and organizations in a variety of domains?
If you have ever wondered what to do with the growing number of features in your software applications, you are not the only one. There is some useful guidance from The Standish Group survey quantifing that only 20% of all delivered software features are “often or always used.” For a team under the pressure of today’s economy to do more with less, here is a way to conceptually cut 80% of your effort and still deliver the high-value essentials. But wait it gets better. If you do not completely elaborate, build, test or document these features, you save once. But you also save again: with the future maintenance costs, the training users, the bug fixing and the regressing these features would have required. This is clearly the biggest lever for cutting software development costs using Agile. And yet it seems to be the hardest to attain.
Features used in Commercial Software - Reported by Jim Johnson of the Standish Group at XP2002
This pairing back to the simple, important few takes tons of discipline and that level of discipline is only be made easier as your agility maturity increases. Most agile books and coaches will call this the discipline of “Brutal Prioritization.” The folks from 37Signals call it: “Getting Real.” In either case, brutal prioritization means two things:
Not letting the fat slip into the backlog
Keeping the backlog prioritized by value and risk
First, lets talk about fat or wasteful features. Please note, fat or wasteful features come from all directions from the business and customers, but also from developers, support, and product owners. Your features may be fat or wasteful if they:
Do not help the most important user persona in your domain achieve breakthrough results or competitive advantage
Have not be proven to work and are based on a hopes and prayers
Look like pets that someone is protecting
Are weak features that degrade the product because they are not complete enough to meet minimum expectations
So if you are in the customer role or customer proxy role such as the Scrum product owner role, the technical product management or a business analyst role, it is your job to control yourself and help the team to keep the fat off the backlog. If you are on the agile team, it is your job to keep these roles honest about WHY these features are so valuable. This leads right to ranking the items into a prioritized backlog. (A few comments in this area would be really helpful – let’s hear what you use to spot fat features?)
[ UPDATE: Fall 2009 Locations have now been announced for Boston, Seattle, Chicago and London ]
In December 2008, we ran the prototype to our recently announced Agile Success Tour in Austin, Texas. This event was extremely well received, and the majority of attendees would recommend this event to their colleagues. Given the high satisfaction level, I can almost guarantee you will not want to miss the one nearest you. So consider registering for upcoming events in Denver, Los Angeles or New York City. Short of living in Chicago and attending Agile 2009 in August, it has to be the best way to learn from your local peers about the actual benefits and best practices of adopting, scaling and cutting costs with Agile software development.
I was the moderator at our Austin event and while there, we captured short videos of our customers/presenters. These customer videos give you a sample of what you can expect to see and feel in your community.
The videos include comments from:
Israel Gat – former VP of Development at BMC
Jack Yang –Director of Engineering, HomeAway
Gary Allison – VP of Engineering, Convio
Erik Huddleston — CTO, Inovis
I really enjoyed two things about the event. First, attendees got to hear and discuss multiple approaches to Agile adoption, tooling Agile lifecycle management and the business drivers that drove their move to Agile. Second, the interplay between local leaders, including members of the Agile Austin community, resulted in shared learning while enhancing the local professional network. In addition to a brief presentation by Israel, these gentlemen were all allotted enough time to share their stories, answer a few of my questions and field audience questions. Following the panel, breakout groups allowed folks to dive deep on hot topics, get introductions to Rally partners and learn about major enhancements to Rally’s services and applications for Agile lifecycle management. Of course the event was executed flawlessly by our great marketing team including Sonya Breakstone and Michelle Burrows, and was facilitated by Julie Chickering, our Texas-based coach.
The Denver event is set for Tuesday, March 18th in downtown Denver. This event will include:
Peggy Reed — VP of Development at Avaya
Lloyd Star — VP of Engineering/Development at Beatport
Pete Fischer — Product Manager at eCollege
Ray Bagley — Director, Product Planning & Management at Spatial
The Los Angeles event is set for Thursday, March 26th in Manhattan Beach, CA. The event will include:
Christophe Louvion, CTO at Gorilla Nation
Laureen Knudsen, Sr. Dir. of Program Management at Qualcomm
David Annis, VP of Software Development at UTI from Arizona
Chris Babcock, VP of Technology at Real Capital Markets
The New York City event is set for Thursday, April 2nd. This event will include:
Jochen Krebs, Dir. of Program Management at AOL
Brian Stockmoe, Sr. Dir. of Program Management at NBC Universal
Land du Pont, Executive Dir. of Product at Conde Nast Digital
Micah Silverman, Founder & Principal at MPower IT
So, please consider sending a senior member or members of your team to learn from and share with your local peers. Additionally, Israel Gat is slated to participate in each of these three events, where he will share his stories and insights from BMC and other Agile organizations.
Registration is online and is limited to the first 100 people. I do not believe there is an event with a higher return on your personal investment for these times. Agile is proven to dramatically cut costs and increase innovation in any sized software development team. If you are not realizing major benefits from Agile in your organization, you will feel the pull to get started at this event.
As a warm-up to these events, you might also consider having members of your organization attend or view the recordings of a new, two-part Webinar series on Agile Cuts Costs that includes Jean Tabaka and me.
This Friday, February 27th, I will be speaking on a panel at the New Jersey Technology Council’s 2009 CIO Conference called “Moving to a Virtual World” ( www.njtc.org). The panel is on Cloud Computing and it is a mixed collection of vendors and CIO’s talking about the rapid arrival, the clear benefits and struggles of adopting Cloud Computing.
At Rally, we have gained some firsthand knowledge of these technologies, platforms and applications as we try to find the most energy efficient, stable and cost effective solutions for us and our customers. As a small fast growing technology company, we are an ideal customer for Cloud Computing and I am sitting on this panel as a user, supplier and leader on software development for the cloud. (We use Amazon EC2, VMWare ESX, Salesforce and seven App-Exchange Apps, Google Apps Premier to run our business and manage our own multi-tenant SaaS/PaaS application in the cloud.)
In preparation for the panel, I was brushing up on some of the latest news and views on this topic.
Here are the worthwhile Cloud Computing links that I used to prepare my talking points:
Cloud Computing – you have to start on Wikipedia to make sure your definition is grounded
In the mid-1990’s, I worked on a great team (which included three members of Rally’s current technical team) as a consultant and eventually as a Director of IT at US WEST Communications in a part of the IT organization that became known at the Global Village Labs.
Sherman, a 25-year veteran of the Bell system, was rebelling against slow IT services in the age of the 1996 Telecommunications deregulation act. To meet the rapidly changing needs of open network, he built this amazingly agile organization that leveraged Mosaic and then Netscape browsers to screen scrape mainframes using ORAPerl.
We used these agile teams of 5 to 10 people to build tools for customer service representatives and field technicians. These were typically simple tools that bridged a couple of mainframes to build compound views that could answer really tough questions.
These questions were hard because each role was only trained in a limited scope in limited mainframes and that full training took 24 months. So we used early Internet technology to open the access and bridge that gap with simple tools.
We made it into Fortune Magazine because our time to market was measured in months and our ROI was 1000%. In our agile model, we delivered our first working increment to the business on test servers in a fixed time box of six weeks. If these solutions showed value and promise for 5 users, we would run another 6-week time box and then roll the application to 50 users. Successful projects then went on to 500, 5,000 and then up to 20,000+ users following this 6-week time box approach. Marginally valuable applications got tabled at the end of the 5 or 50 user-demonstration time-box.
As a result, we grew the group from the initial 10 folks to the 150 person organization in IT in just 18 months. (See the internal brochure we used to drive business to our group – (BTW, this was really fun to research on the Internet – such good memories.)
QSMA Agile Impact Report showing Agile teams 25 to 50% faster versus 7,500 other projects
50% Faster Time to Market OR 50% Less Staff?
It was all about Time to Market (TTM) for GV Labs and for most folks adopting Agile in this decade. However, now with the cost-cutting focus of these turbulent times, we see many organizations trading off some of the TTM for cost savings. As a result, they will use fewer Agile teams on a project and deliver a lower throughput per agile, time-box cycle. In many cases they are using fewer people, because they have fewer people due to staff cuts. (If you have not taken staff cuts and are wondering how to do that and maximize your Agile success, read an earlier article of mine on TechTarget – Cutting Your Way to Increased Agility and my post on Israel Gat’s Social Contract for Agile Software Development)
Of course this is a continuum of speed and these savings exist in either getting done faster with more or getting done slower with less. You and your organization should be careful to consider the total cost and benefit of the project when right-sizing the team size to completion date. There is an optimal range for most projects and with true agile project teams you get the benefit of adjusting this based on actual performance over short time-boxes.
To gain these benefits, you have to actually become Agile and not just adopt some of the practices. Agile means dedicating you and your team to learning and continuous improvement. We did it at US WEST in the 90’s and QSMA shows how many of our customers are doing it today.
If you truely become agile in these times, you can accelerate out of this downtrun smarter, stronger and leaner.
I have linked to Israel’s work before and I have seen him talk about the social contract that he made at BMC in 2006.
However this new post and the attached slide share decks give the seldom-heard whole story. Israel has also provided a new introduction with a solid historical as well as current context; this makes the social contract concept even easier to apply in today’s turbulent times.
This post hits the heart and mind of leaders of Agile teams. I have responsibility for our product development and operations teams at Rally. This post caused me to find ways to double my efforts to lead our team from “within” as we are expanding with a new office/team as well as continuing down the flow-pull-innovate road of agile expertise.
Check out some of Israel’s other great work by visiting his blog, The Agile Executive
Side note: Many people love to give folks that live in Boulder, Colorado a ribbing about spiritual “woo-woo” focus (home of natural food including soy and herbal tea, Naropa Insitute and plenty of hippies).
I think many skeptics like to give that same line to folks who talk about the “people” side of effective Agile enterprise adoption.
Israel’s post is all about managing and leading the team – without this kind of leadership you will be destine to always remain an Agile amateur. Think big about your Agile adoption, but also think big about your personal journey to this level of team leadership. Everyone wins on this journey and this posts keeps you on the rails, especially in these times.
On Monday at SD West, Scott Ambler presented recently updated survey results from a 600 person survey on Agile Development.His results are just the latest in a series of surveys around the move toward Agile Development.Scott’s results came with an assertion that the Agile development trend has “Hit the Wall.”Though Scott could ask that question based on his results, I suggest that he stop and ask the question, Why does his survey show no additional adoption since 2005, but other surveys shows a completely different story? I can not answer that question, but it would be great for Scott to go to the next level.
As a result of Scott’s quote, I decided to dig into what we can learn about Agile adoption in the marketplace and what it means to a software development organization today.
First, I dug into other surveys’ that are represented well at Methods and Tools and the latest information from Forrester.Carey Schwaber has updated their survey of 1,017 North America and European enterprises.The survey was done in Q3 2007, reported in February at “Agile Enterprise Adoption in 2007“.
She found that:
26% are Already Using Agile and an additional 42% are aware
Adoption of Agile increased 56% from 17% in 2006, to 26% in 2007
Awareness increased 45% from 29% in 2006, to 42% in 2007
Her conclusions were as follows:
Agile adoption has accelerated
Large Enterprises are more likely to adopt Agile
Financial Service sector is the leading the pack to take Enterprise adoption
Agile adoption is correlated with adoption of open source, SOA, ALM and SaaS
The Methods and Tool survey found that from 512 respondents in February 2008 versus 232 in 2005 that:
Overall usage had increase by 77 % in adoption from 2005 to 2008
Between fully deployed, partially deployed and partially implement the 2008 versus 2005 results looked like this:(48% in 2008 compared to 37% in 2005)
Fully Deployed 2008 – 17% and in 2005 – 8%
Partially Deployed 2008 – 14% and in 2005 – 12%
Partial implementation 2008 – 17% and in 2005 – 17%
As an organization adopting or scaling agile, I know that I would like to know three things:
Is this a fad?
Am I behind the curve in adoption?
What real benefits are coming as a result of these efforts?
First, the accelerating year over year adoption and awareness rates point to the fact that is not a fad that it is not flaming out.
Second, if you were to plot this against a normal distribution curve that follows an empirical rule where 68% of the curve is one standard deviation from the norm, you would get a picture like this:
Where the area under the curve represents the entire population of adopters, you might come to the following conclusions:
Agile adoption is across the Chasm (into the early mainstream area) by everyone’s accounts with between 17% (Ambler), 26% (Forrester) and 31% (Methods and Tools) of the market using/having deployed Agile.
So are you behind the curve? That really depends on what market and technologies you are using:
Yes, if you are building web 2.0, SOA, SaaS or with Open Source tools
Yes, if you are in the Financial Services Industry
Yes, if you think of your development team in the early mainstream or pragmatic adopter.
No, if you are using mainframe, embedded or client server technologies
No, if you are in the retail and public sector industries
What is the ROI and benefits of Agile Adoption?
Studies like the QSM studies on BMC’s Agile Adoption are showing great results with 4X improvement is delivery speed, 11% lower defect counts for and 20 to 50% productivity improvements.
Though Scott’s survey showed flat growth in adoption, I believe he needs to look at his survey population to understand the discrepancies from the other surveys. All the other surveys point to periods of continued growth as Agile becomes more mainstream across many industries and technologies.
RallyDev.com
If we are looking at process overhead, I think applying the 5 Orders of Ignorance is great guidance:
