When Agile teams start to plateau (or worse yet slide back to the old ways), I often hear this complaint:

“There is too much time in meetings with Agile Software Development, we give up!”

I usually follow that up with a question: What are you doing to fix that?

An overabundance of meeting time is a problem that many organizations face, but I’d argue that Agile practices are the solution instead of the cause.

If I can get the team to ask me for suggestions, I always point them to my friend Jean Tabaka’s great reference book on running Agile meetings – called Collaboration Explained. But today I saw yet another wonderful nugget from Seth Godin about general meetings.

Seth Godin’s Suggestions on Serious Meeting Practices

Many of his suggestions relate to the practices of Agile and are disciplines we use at Rally to keep from meeting to death.  Seth’s portion in quotes below: 

• “Remove all the chairs from the conference room. I’m serious.“
  New employees to an Agile team or company often laugh at the idea of a daily stand-up meeting, but literally standing during the meeting encourages people to be concise, attentive and then get on with their work. The best stand-ups at our company happen at around 9:00 am daily.

• “Understand that all problems are not the same. So why are your meetings? Does every issue deserve an hour? Why is there a default length?“
  Agile helps us drive this discipline. Stand-up meetings are less than 15 minutes, iteration planning is a half-day for a new team and 1-2 hours for seasoned team.  Release planning is a 4 to 8 hours and my require a part of second day to handle dependencies across multiple synchronized teams. Allocate the right time for the right purpose, and bring in a professional Agile facilitator (or assign a neutral party from another department if you don’t have the budget) to keep the goals of the meeting moving. Having a agenda with time limits per section helps. So does a big buzzer (we have one of these at each table of attendees) to hit when people get off topic.

• “If someone is more than two minutes later than the last person to the meeting, they have to pay a fine of $10 to the coffee fund.“
  We do this at our executive stand-up meetings (with a slightly lighter sentence), and recommend customers do the same. Late attendees pay $1; if you’re late AND the last one in the door, it’s $5.

• “Require preparation. Give people things to read or do before the meeting, and if they don’t, kick them out.”
  Before release planning, we create a collaborative web site where materials are stored. All pre-reading is assigned in advance, and all attendees have to load their slides to the site before the meeting begins. We even have a “no thumb drive” rule to discourage last-minute slide creation.

So what’s my point? Don’t blame the methods and practices for your lack of personal discipline and commitment to get better.

If you are going to win in this global economy, you have to find ways to constantly improve, and Lean and Agile development are proven cures. It is too easy to give up, so instead stand-up and, as Christopher Avery teaches, take some personal responsibility to make it better – start from within!

Do you have other meeting guidelines that you’ve used successfully? How much of your company’s meeting addiction gets blamed on Agile practices? How has your organization adapted to better meeting discipline?

In this final post of questions and answers from the webinar Dave West from Forrester and I did on Scaling Agility, we cover Agile champions. You can view the archive of this webinar as well as the other webinar in the series, Realizing the Promise of Agile: Creating Leaner, Meaner and Faster Product Development.

DW – Dave West from Forrester
RAM – Ryan Martens from Rally

To work with the business to become Lean, who is an effective champion? Who is an ineffective champion?

DW – Lean businesses have to come from the business. I have seen effective leadership in many places, but always in the business. This might be a Business Unit or a division or it might be across the whole company – But the change needs to come from the business and be expressed in their terms.

RAM – Nothing to add here.

Do groups/departments/teams outside dev typically resist the adoption of Lean activity because of the perception of “loss of control” or authority?

DW – It is true to say that change is always difficult and that any change to undermine the existing power structures in an organization is a problem. I have seen successful implementation of Lean thinking in the following situations. Firstly, there needs to be a reason to change. At the organizational level that can be market forces, cost, and competition. At the BU or project level, failed projects or new products are always a good lead in. Add to the reason a clear plan around the change where power and career are considered. Answer questions like ‘what does this change mean to x ?’

In general the adoption of Lean thinking makes sense, but even if people see the value if it adversely affects them, it is hard to get buy in. Make sure it does not !!

(more…)

The LA Agile Success Tour concluded with 5 open space sessions. For my other live posts from the LA event, see:

• 5 Stories of Agile Success
  
• What Would You Ask Your CEO to Bring in Agile?

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.

Get something small, but get it done!

Socializing Agile, led by Israel Gat

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.

Agile Collaboration, led by Jean Tabaka

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.

Jean has a different view, called the 5 Levels of Planning.

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.

Quality and Testing, led by Zach Nies (me)

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.

(more…)

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.

Chris Babcock – VP of Technology at Real Capital Markets

• 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

(more…)

This post continues on our series of questions and answers from the webinar Dave West from Forrester and I did on Scaling Agility with Lean: Proven Methods of Operational Efficiency.

At Rally, we often get questions about how Agile fits in with a variety of other practices and processes, so the below questions about Agile and CMMI, Agile and RUP, and Agile and Architecture come as no surprise. Stay tuned for the final Q&A on Agile champions.

DW – is Dave West from Forrester

RAM – is Ryan Martens from Rally

How can Agile be integrated in a CMMI certified application in regards to the tremendous amounts of required CMMI artifacts (documentation)?

DW – The flippant answer is it can’t. ☺  But actually I have seen some great systems integrators use CMMI to help check list their processes of which some of those processes are Agile.  Agile development works really well at the team level, but it needs to be surrounded with other processes. CMMI makes sure you remember those processes, some of which are inside the Agile team, others are not.  The PA’s always seem to imply lots of documentation, but they do not have.  You can keep the documentation to a minimum, but still deliver them.  Do not, however, burden the Agile team with proving their compliance – Use the checklist, build the software and get others to prove they did what they said they did.

RAM – I am not quite as negative as Dave on this topic. CMMI and Agile combine just fine. There are a number of proof points that are easily found from past Agile conferences and by searching “Agile and CMMI.”  The problem is that many folk misinterpret CMMI and are convinced that it mandates waterfall, heavy process and heavy documentation.  According to SEI, it does not.  Most teams would not adopt CMMI without a specific business need.

(more…)

I’ve been thinking about leaning a lot lately, and not of the pressed-wood bookshelf nuisance variety. I talk about Lean with my colleague and President of Rally, Ryan Martens. So when I talk about a leaning bookshelf, I’m referring to my interest in Lean in all its forms. I am talking about the books I’ve been reading  that pertain to Lean. And, more specifically, how can I turn my “Leaning bookshelf” into a continuous “learning bookshelf”?  How can I think about my evolution of thought and practice with regard to Agile as influenced by Lean? What could be a good, rewarding goal?

And so, through discussions with Ryan and some of my own quiet thought, I came up with a goal of improving my notion of learning. Yes, for me, that seems to be what I am discovering more and more about Lean:

• How to learn
• How to teach others to learn
• How to encourage organizational learning
• How to avoid/eliminate re-learning

And so in this post, I thought I would share what I am reading, have read, or am about to read, and ask you for your comments and recommendations with regard to my leaning—>learning path. Some of the books may not look directly associated with Lean. I just know that they have been part of my lean learning journey.

The Contents of My Leaning Bookshelf:

1. Getting the Right Thing Done – Pascal Dennis
2. Hitotsubashi on Knowledge Management – Hirotaka Takeuchi and Ikujiro Nonaka
3. Implementing Lean Software Development: from Concept to Cash – Mary and Tom Poppendieck
4. Lean Software Development: An Agile Toolkit – Mary Poppendieck and Tom Poppendieck
5. Lean Thinking – James P. Womack amd Daniel T. Jones
6. Lean Transformation: How to Change Your Business into a Lean Enterprise – Bruce A. Henderson and Jorge L.Larco
7. Learning to See – Mike Rother and John Shook
8. Managing to Learn – John Shook
9. Product Development for the Lean Enterprise – Michael N. Kennedy
10. Ready, Set, Dominate – Michael Kennedy, Kent Harmon, Ed Minnock
11. Scaling Lean and Agile Development – Craig Larman, Bas Vodde
12. Scrumban – Corey Ladas
13. The Knowledge-Creating Company – Ikujiro Nonaka and Hirotaka Takeuchi
14. The Elegant Solution – Matthew E. May
15. The Toyota Way – Jeffrey Liker
16. Thinking Beyond Lean – Michael A. Cusumano and Kentaro Nobeoka
17. The Art of Lean Software Development – Curt Hibbs, Steve Jewett, & Mike Sullivan
18. The Goal – Eliyahu M. Goldratt

Looking at my leaning bookshelf and thinking of my focus on learning, I realize I haven’t included any Senge books or others about organizational learning. That will have to wait for another post.

What books are important to you on your leaning/learning path?

Last Thursday, Dave West from Forrester and I did a live webinar on Scaling Agility with Lean: Proven Methods of Operational Efficiency.

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.

You can also check out the first webinar, hosted by Jean Tabaka and Johnny Scarborough from Global Logic, on Realizing the Promise of Agile: Creating Leaner, Meaner and Faster Product Development.

DW – is Dave West from Forrester

RAM – is Ryan Martens from Rally

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.

(more…)

Okay, that wasn’t exactly how it was said. However, the title of this post reflects a comment I overheard recently while facilitating an operations and architecture team’s retrospective.

We first looked at basic facts about how their quarter had “gone”: what events stuck out in their minds, what the basic acts and information were that surrounded their day-to-day work. Just the facts. From there we checked out the impact of those facts, that information, those events, on them. Was this a good thing? Was that a bad thing? Were these helpful things or challenging things? We were seeking reflection on the quarter to then help draw out some insights into trends or recurring issues and themes.

After this, I asked the group of 8 people: “What still puzzles you?”

No one had ever asked them that before. They leaped at the opportunity to express frustration about where they sit (or don’t sit) in the Agile development approach. Did they have “a seat at the Agile table” or not? Here they were, the operational experts. They held grave concerns about the operational scaffolding upon which prioritized features were being built across the multiple application teams. And yet they felt that the collective Product Owners could not see this. ‘Tis a puzzle.

Once the group had aired their puzzles and concerns, I then asked for their recommendations. And that is when, verbatim, one of the team members said, “Well, we need to push it up their backlog!” Now, as a facilitator, I am asked to write what is spoken and also to not comment. But this was priceless!

In any case, how DO we push something up someone’s backlog? And why is PUSH even considered the only way to get onto a backlog or backlogs. Here are some ideas that then swarmed around in my head:

• how do we articulate the value of operational and architectural items?

• who do we articulate this value to?

• how do we convey that value across multiple teams’ backlogs (i.e. influencing multiple Product Owners)?

• how do we then coordinate operational items being completed for the next major release across all backlogs?

So, maybe pain is the only sometimes way to help articulate the value of operational work: “It will cost our customers this much pain if we don’t do this.”

The moral of this story: Pushing things up your (or someone else’s) backlog sounds painful; find another way.

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.

Recommendation - Use Rally’s Mash-up Platform to provide those insights.