Making New Agile Teams Successful breakout with Erika Peace of ICS and Chris Browne of Rally
Having now returned to Boulder and unpacked my bags, I wanted to reflect on the great experience I had moderating our most recent Agile Success Tour event in DC.
Our 5 executive panelists provided such great insight into their Agile adoptions, each with a different perspective.
The Q&A session that followed brought out puzzles and challenges from the participants, and it was great to feel their energy and passion to learn more. This flowed so wonderfully into the 5 breakout sessions that no one even wanted to take a break afterward!
In fact, the energy stayed so high through our final remarks and lunch that it fed even more insights from our panel. And, the audience was so highly engaged that many chose to stick around after the event to continue one-on-one as well as group discussions.
It was a pleasure and an honor to once again be a part of an Agile event that provided such genuine value to its participants.
One other note from DC: as usual, Israel Gat did a great job with his pre-event engagement work with the panelists. And, he has continued his tradition of capturing pivotal moments and pithy insights in his post-event blog entries. I encourage you to read his Threads from Washington, DC post for a breakdown of some of his favorite discussions from the event.
“You learn more quickly under the guidance of experienced teachers. You waste a lot of time going down blind alleys if you have no one to lead you.”-W. Somerset Maugham (1874 – 1965)
Filmed at Rally’s Agile Success Tour events, these videos detail the real-life agile implementations of software/IT executives who have taken the enterprise agile journey and are now realizing the benefits of enterprise-scale software Agility.
Our coaching and technical account teams (including Jean and myself) provided guidance to many of these panelists during their initial steps in their journey. It gives me great pleasure to see them now become the teachers and share their expertise with the new generation of practitioners.
Don’t pass up this great opportunity to learn from the experiences of others!
On June 25th, Rally hosted the Atlanta swing of the Agile Success Tour, where local software and IT leaders met to share Agile implementation stories, ask for advice and participate in group breakout sessions.
Learn about upcoming dates in your area by visiting here. These events are free, but registration is required.
Below are 3 themes that developed at the event:
1. Executing as a distributed Agile organization almost requires a tool
Many of the discussions focused on best practices for Agile adoption in a globally distributed team. One of the points that gained consensus among the attendees was that a distributed Agile team should use a tool as an ‘information radiator’. The tool helps to provide visibility into the teams iteration and release status regardless of where each team member sits and in what time zone.
Using a tool in a distributed organization helps to overcome some of the collaborative issues the group would otherwise face in the form of daily standups, blocking issues, and team velocity. Also, the group agreed that nothing goes as far toward team building as getting the team together – even if it is just once a year at the beginning of a release or to do retrospectives.
2. Agile can help quantify the case for additional resources – and understand why they are needed
My personal favorite discussion was when one group member asked “Does the team have to be a certain size in order to adopt Agile?” We thought he was assuming that a large team or organization would have a difficult time adopting Agile. Actually his question was based on the fact that his team was just two individuals.
As the discussion progressed, we all agreed that building a product backlog, then prioritizing and sizing the stories would allow him to articulate exactly what the two-some was capable of committing to in any particular iteration. If that much value was not enough in the agreed upon timebox, perhaps the business should consider more resources for this team.
3. We’d like to adopt Agile – how do we ‘sell’ it internally?
Many of the folks participating were anxious to get started – even before they came to the event. Where they were often getting stuck was in how to articulate the ‘why’ to the business. Some great points that were shared were:
Focus on the value of adopting Agile – and be specific. A recent study that was presented at the event highlights the fact that Agile teams are 50% faster to market and 25% more productive compared to industry averages.
Agile represents a fundamental shift in our approach to resourcing. How the work is organized will depend on what software you are developing, but the key is the team will create greater visibility about priorities, and put those decisions back in the hands of the business.
Avoid using Agile ‘jargon’. Many people who don’t understand Agile will associate negatives with the words we all know and love: Scrum, sprint, backlog, user story – these are all Greek to non-Agile folks, and should be avoided when trying to gain buy in. Create associations and use well known equivalents as you gain consensus to move forward.
With Agile, we focus on the shippable increment. This point should resonate well with the business. When was the last time they got to see the product evolve every two weeks in demonstrations? One shared example from our executive panel was that the team would e-mail stakeholders an AVI demo every month. These folks could see the product demo (and it’s progress from one month to the next) on the plane, at their desk, on their own time. She knew success was at hand when the team didn’t send out a demo one time and an executive from the business called asking where his demo was – he was anxious to see it!
Last week I attended the Agile Success Tour in Santa Clara, CA. I noticed 5 themes to the discussions and breakout sessions with the nearly 200 software and IT leaders in attendance.
Catch the next event in Atlanta on June 25. The event is free, but registration is required.
1. Product Owners are very important
Waterfall product marketing will find it difficult to adapt to the new responsibilities of Agile teams, unless they learn what is expected of the Product Owner. An absent or uneducated Product Owner can handicap a project before it even gets started.
2. For Agile to be successful, you must gain consensus and commitment
When rolling out new Agile teams, you must get consensus both from the team members converting to Agile and your management. Everyone involved needs to understand that growing pains will occur, but ultimately lead to higher performance. In addition, you must dive in and get started with a “burn the boats” mentality that prevents anyone from considering turning back. See Jean’s post on 12 Agile Failure Modes for more on behaviors that can inhibit your success.
3. Distributed teams, though popular, are hard to make successful
With obstacles like quality of life, cultural and time zone differences, and the drag from waiting for decisions, distributed teams pose special challenges that require Agile teams to inspect and adapt with respect to all. Team building at each location, enhancing communication, mentors, travel, group pictures, and sharing the load all help break down barriers that can prevent distributed Agile teams from reaching their potential.
4. Successful Agile adoption can help companies realize quantifiable benefits
Jean Tabaka shared how companies who are adopting Agile development are seeing significant cost savings in their development organizations with faster ROI, improved time-to-market, and increased productivity. In tough economic times, speeding up Agile adoption to help companies realize cost-savings quickly is more critical than ever before.
5. An Agile community is a valuable tool
Agile development may have simple values, but it is not always easy to implement. Capitalizing on the “wisdom of crowds” and learning from each other’s experience are key to avoiding common pitfalls.
The next round of Agile Success Tours starts next week as Rally customers share their stories in a community-building event. We coordinate these events for the purpose of learning from do-ers. This is not a Rally sales pitch or a parade of “experts”; this is a place where software and IT leaders can share with their peers the best practices and roadblocks to Agile adoption. Peggy Reed, one of our phenomenal speakers from the Denver event and Avaya’s Director of Contact Center Reporting, said:
“I would totally recommend this event to people who are moving from another methodology to Agile. There are moments of truth when you move to Agile that are really tough for organizations. Having some help in a community that shares those moments of truth and change makes it understandable. You can see your progress if you share your journey with other people.”
In addition to the speakers below, Israel Gat, former VP of Development at BMC Software, will be at all three events sharing his enterprise Agile adoption story. The event is free, but registration is required.
June 4, 2009 – Santa Clara, CA
Leigh Anne Glasson, VP IT Applications Engineering, VMware
Did you find these posts valuable? Any advice on how we can improve this for next time?
Agile 101, led by Christophe Louvion
What is your pain? Command and control, changing priorities during the sprint, hybrid process, making decisions outside the team that affect the team, improper tooling, moving resources around.
Root causes: Lack of self organization caused by lack of education, lack of an Agile driver, internal or external customer pressure, lack of executive vision, fear of change, skill set mismatches, ask teams to do things that don’t work well, lack of action items with a clear owner and clear deadlines.
Christophe had people in his breakout commit to action items. Christophe is going to call each of these people and verify if they accomplished their action items, like Lisa who committed to requesting a coach to come into their company and help them with their hybrid Agile process.
Pains: The sausage factory syndrome, the business doesn’t want to know how the software is made, but give me what I ask for when I need it. Market dynamics like drops in ad revenue and other drops in the market.
Solution: Innovation is now affordable because we can all experiment, try something in your sprint and if it doesn’t work out you only have 2 weeks invested. Read the book Innovators Dilemma by Clayton Christenson.
Risk management is important to executives, and Agile reduces it significantly. Money quantification, understand the value of what you’re delivering. Look at Capers Jones and his 2008 book Applied Software Measurement and his 2007 book Estimating Software Costs.
Agile Governance and Compliance, led by Laureen Knudsen
Pains: People live in rigid environments and don’t want to change. People don’t want to show their work because it’s too raw and there is fear around failing fast by validating your work with actual customers. There were questions about what is the earliest point to show things to customers.
Organizationally what is happening to enable collaboration? Organizations need to communicate down about vision, and the teams need to communicate up areas of process improvement. There was talk about servant leaders, and how command and control managers actually make people dumber. Most Agile teams start with iteration planning, standups and the end of the iteration demo.
Start with a Vision, this is the first level of planning that the leadership team owns.
Then move to a Roadmap where you talk about themes of releases. It’s important to talk in themes and the Product Council is the feedback mechanism for that process.
Then Release planning is next. It is important for everyone to be involved in the Release planning.
Then think about taking the Release theme and how the Iterations build toward that goal.
Then Daily examine what you did toward that goal yesterday, what you are going to do today, and what is getting in your way.
Each level then provides a feedback loop to the higher level of planning. At Rally everyone is involved in these 5 levels of planning within every department in the company.
Pains: Integrating testing teams in with development teams, making testing teams more effective and how to introduce Test Driven Development into the development team. An important way to integrate testing and development is to integrate and involve both roles in planning sessions. Testing should be part of the definition of done and involve testers in creating a story’s acceptance criteria.
The group talked about how to break down the walls between testers and developers, by focusing on the reality that everyone owns the quality of the software being developed. When testing is integrated into the process it makes them more effective. Finally, a few teams are trying to use Test Driven Development. Test Driven Development can’t be imposed onto the team, the key developers on the team need to lead by example by embracing TDD practices.
This and other great questions from the LA Agile Success Tour below. My next post will cover the open space breakout sessions.
Question: What would you ask your CEO to bring Agile into your organization?
Christophe – Are you ready to get rid of 50% of your managers? Jean – Agile brings about organization change, 20% of engineers won’t adjust. Israel – What are you trying to accomplish? Pick one and focus on it. Chris – Why just Agile in engineering? The whole business can use Agile throughout the whole organization. Laureen – Are you really committed to the change?
Question: What metrics do you ask the teams and upper management to embrace?
Chris – Measure what you want to improve and care about like: velocity, unit test coverage for the team. For the executives, align business metrics with your development metrics and make it as public as possible. Laureen – Make sure you have a goal before you come up with your metrics. What do the metrics mean to us? Data should support your goals. David – Had no metrics before Agile, now we can have value based metrics that the business can use. Israel – Establish a baseline before you do any process changes – you need to know where you stand. Pick the metrics to help you know where you stand and establish that baseline. Christophe – One tracked 3 metrics: dollars, customer satisfaction, and time to market.
Question: What do you believe is the #1 discipline that had to change or understand to enable successful Agile adoption?
Chris – The toughest and most important one is getting the development team to embrace continuous integration, it reveals so many of the improvement areas within the development team. This is hard because it can expose so many sacred cows within the organization. Getting to a point where you are always ready to release is key. Israel – Changing how the sales force and marketing departments sell products. Getting these groups able to sell value and benefits to the customer rather than a pure feature focus. This is key to end-to-end Agile. Laureen – Agile isn’t just another process with associated documents; it’s a change with how people interact with each other on a day to day basis. If people don’t want to grow and change with the business, then they may need to leave your organization. Christophe – Are you good at multitasking? Instead ask: Are you good at single tasking? Limit the amount of work in progress! Nothing gets done when you focus on too many things. The most difficult thing is to get teams to focus on one thing at a time. David – Moving away from an upfront requirements document to user stories that can change over time. A key piece was to break the stories down into smaller and smaller stories that can be worked during the iterations. Even people who thought they understood this process of breaking stories down struggled.
Question: How do you educate clients to Agile in a service provider based businesses?
Israel – Involve your customers with the iterations, the release planning events, and the end of iteration demos. The commitment is small from the customer and the benefits are tremendous in that the customer can be involved in the development process. Chris – Agile is such a wonderful and easy way to get customer involvement. Each iteration, they deploy to an external environment where they get feedback. Create a feedback loop with your customer so they can see how their feedback affects the direction of the product.
Question: How do you do performance management in a highly functional organization?
Christophe – I don’t do formal performance appraisals in my organization. Do the right thing for your team. Jean – Look at performance with this question: In what ways did you contribute to the success of this team? David – Unlike Christophe, it’s a little different in big organizations with SOX issues. If you have managers that span Scrum teams, make sure they understand what’s going on in the Scrum teams. Your focus as a manager totally shifts from micromanagement to one of removing impediments, roadblocks, and preparing the team for the next project. Israel – Keep information about how the team is doing secret to the team. Decouple the performance appraisal process from the process improvement within the team.
Question: How do you estimate how much work will go into a release and do more development and do it faster?
Christophe – Make sure you fix the date of your release and vary scope. David – I agree, resources are fixed, time is fixed and scope varies. Laureen – We use a train analogy. There is no question when the train is leaving, the question is what features will be on the train. David – When we started we had about 60% estimation accuracy. We now have over 90% accuracy in our estimates. A key point is DON’T LOAD YOURSELF TO 100% CAPACITY. Give yourself some flexibility, someone might get sick.
I’m live here at the LA Agile Success Tour with the success stories of our panelists. In my next post, I’ll cover the Q&A.
Israel Gat – Cutter Consortium member on Agile, former VP from BMC, IBM, Microsoft and EMC
Software is becoming pervasive in our lives. The key will be how we align the functionality of that software with what the customers actually need, not our guesses about what we think they might need.
A key component of this is agility in the process between developing software and getting that value into our customer’s hands. He used Flickr and IMVU as examples of the power of using constant deployment as a method to effortlessly deliver software, and ultimately value, to customers.
Introduced to Agile in 2000 as a reaction to his “death march” experience at another company, where his team worked 100-hour weeks. He moved into a development management role and took on the goal of delivering projects on schedule, in a way that was healthy for the team. One of his development leads discovered the XP methodology and they never looked back.
Tracking project metrics was an important part of his role at one company. He shows empirical evidence of the benefits of Agile. With waterfall, time = 31 weeks, 16 critical defects and 153 stories. With Agile, time = 19 weeks, 0 critical defects and 234 story points. He was most proud of 0 critical defects into the market.
Benefits from Agile – faster development, more manageable codebase, fewer defects. Industry average is 15 to 50 bugs per 1,000 lines of code. With each release, through refactoring and Agile development, they are decreasing the size of their code base. Yes, that’s right, more features, with higher quality, with 100,000 fewer lines of code.
Laureen Knudsen – Sr. Dir. of Program Management at Qualcomm
The Denver Agile Success Tour continued with four open space sessions. For about 20% of the room, this was the first open space session they have ever participated in. Groups broke into discussions on leadership, testing, scaling and tooling and then did a read-out to share their conclusions with the larger audience. (For my other live posts from the Denver event, see 5 Stories of Agile Success and What’s On Your Mind?)
#1 Open Space – Executives and Agile Adoption, led by Israel Gat
This group included new as well mature Agile folks and teams of 9 to 280 people – Given that spread, there was an overwhelming agreement that “our executives do not understand it” and “I, the executive, wants the whole iron triangle fixed – time, budget and scope.” For executives who do not understand agile, it is very hard for people to communicate “What is in it for the executive?”
Conclusion – Socializing Agile is as important as doing Agile well. Your adoption will regress if your executives are not sold. Without time spent with executives, there is a bitter slide back down coming for the team. A slide like this is really hard to recover from.
Recommendation – At the point of scaling your agile adoption, contract up-front with your executive on the results, but only pick only one dimension. (Productivity, Time-to-Market or Quality)
#2 Open Space – Testing, Quality and Leadership, led by Zach Nies and Peggy Reed from Avaya
Topic time spent on willingness of test teams to move to Agile and what does pulling testing forward mean? Can I be Agile if I do not test inside the iteration? At Avaya, they do a lot of testing outside the iteration due a large matrix of configurations.
Conclusion – Make sure testing team is at iteration planning and release planning. Always honor your time box and retrospect on your testing coverage.
Recommendation – Focus on making story sizes smaller to bring testing into the iteration.
#3 Open Space – Scaling and Large Scale Adoption, led by Evan Campbell
Topics focused on collecting metrics while the guerrilla insurgency is working and before they get “busted” doing Agile. The result of not collecting metrics means getting stuck in an “Agile Ghetto.” Top-down adoption approaches are becoming more common, but came back to Rally’s Enterprise Adoption model called Flow-Pull-Innovate that is based on Lean.
Conclusion – It is inevitable that you are going to have to evangelize the Agile adoption. Start building the case from day 1.
Recommendation - Focus on the change management process for large scale adoption. Practices are a key focus for small teams, but not the key focus of large scale adoption.
#4 Open Space – Tooling Agile, led by Karen Kagiyama and Amy Wiley
Tools enable best practices, and integrations are inevitable because one tool cannot support all types and nuances of development teams and technology needs. Continuous integration, build management and test coverage metrics and reports correlate into the context of iteration, release, and program of teams are critical for know “where are we right now?”
Conclusion – The ultimate goal is a single dashboard to support the insights and planning.
Answer 1 - Started with whiteboards and sticky notes.
Answer 2 – Started with in-house tool, then open source and finally Rally.
Answer 3 – Started with Rally training for the first year with a Rally pilot in parallel to show management and staff the whole solution.
Answer 4 – Put good consultants alongside the team from day 1 to apprenticeship with the best – we went Rally training and consulting.
Question: We have lots of concurrent features in parallel. Does anyone do concurrent feature branches?
Answer 1 – Peggy – At Avaya we do this, but first go back to the product owner to prioritize better. We use private views in ClearCase to manage features branches with continuous integration in the views.
Answer 2 – Israel – Never allow the backlog to be larger than twice the capacity of a release.
Question: Please talk about the adoption challenges of adopting with your external customers.
Answer 1 – Israel – It took us 18 months to change the perception of my group with sales. It was critical to get field engineers to come to release planning and every iteration demo. They get exposed to the software engineering approach and real status and built the best evangelists and advocates in the process.
Answer 2 – Richard – Rally has developed a social networking site with what most people see as shocking openness. As a result, we have had tremendous success in engaging customers and focusing priorities.
Question: What is the cheapest and best way to get started as an individual?
Answer 1 – Take trips to visit other local companies – everyone says yes.
Answer 2 – “XP in Trenches” – was recent great book find- read a ton of books but most only focused on single team.
Answer 3 – Richard – Come be a fly on the wall at a Rally release planning.
Question: Big Six Sigma background – What tools do you use QFD to find what customer really wants?
Answer 1 – Failed with all upfront tools, only thing that works is communication in every iteration. Too many edge cases in our industrial software. Given up trying to spec this in advance. Invest more in bringing the customer in.
Answer 2 – Israel – Try to reach the point where the developer can code faster than marketers can release. As soon as that happens, you can decouple and get more feedback during the cycle. You are also able to bring more of the business into learning after you decouple.
Question: How do you solve the coordination of many teams in a large adoption? Tell me more about Meta Scrum.
Answer 1 – We do a meta scrum every week with the owners of seven product lines. In parallel the product owners and development leads do the same.
Answer 2 – Israel – Scrum of Scrums everyday with all the ScrumMasters following a 10 to 15 minute approach.
RallyDev.com
