Agile Development Blog

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…)

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…)

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…)

Several weeks ago, in an interview with Dave West of  Forrester Research, Dave posed a provocative question to me.

“Do you have to be smart to do Agile?”

In retrospect, Dave’s question reminded me of an old joke: “Have you stopped beating your wife?“  In this “deeply philosophical” question, there is really no good answer. “Yes” looks bad; “No” looks worse. Answering the question about Agile and smartness could be the same. For me to answer “Yes” could be interpreted as, “Gee of course; look how brilliant I am!” To answer “No” could be interpreted as, “Gee of course not! Look at me! I’m as dumb as a doorknob!“

All jokes aside, I answered “No,” to Dave’s question and here is why.

The real question is not about individuals. The real question is, “Do Agile TEAMS have to be smart?” And to that question, I would answer “Yes.“

Agile relies on the collective wisdom of the team, not on the brilliance of one individual. I learned a lot about this, not just in my research of Katzenbach and Smith’s The Wisdom of Teams. I also have experienced it in the variety of teams in which I have worked and with the teams I have mentored. High team E.Q. (emotional quotient) is what makes Agile really hum. In fact, high team collaboration, their ability to invite and manage conflict, and their ability to create consensus, actually is the fiber that weaves the cloth of a high-performance team. High-performance teams have a collective high goal for which they hold themselves mutually accountable. It is about the team and its commitment to one another and their goal.

So, back to our title math question.

• 7 + 2 = 5 if your team mistakes collaboration as working in a “dumb down” or “group think” mode. That is not the intent of Agile collaboration or consensus. We’re an Agile team because we intend to increase our collective wisdom.

• 7 +2 = 9 if you are not gathering all the insights of all the team members to inform your decisions in your work. You are not quite yet truly Agile.

• 7 + 2 = 11 is where the collective wisdom of the Agile team raises its team I.Q. That is, the Agile whole team is indeed greater than the sum of its parts. And besides, as Spinal Tap says, it’s great to, “Go to 11!”

Further Reading:

• #6 Collaborative and Smart – Top 10 Charectieristics of an Agile Organization
• Get Serious About your Meetings with Jean Tabaka and Seth Godin
• Live from LA Success Tour: Advice on Socializing, Testing and Collaborating