Agile Development Blog

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.

Are there organizational characteristics that can predict how hard it will be to adopt an Agile approach?

DW – When I review organizations I tend to look at the following:

• Departmentalization – How much investment has an organization had with the departments that comprises it? Organizations that have a heavy departmental focus, with measurement and career defined by those departments often find moving to Agile hard.

• Measurement – How is the IT organization measured? If the measures are connected with delivery on plans and defects then it may be hard to move to an approach with transparent communication (advertise problems) and change throughout.

• Business relationships – This is very important. IT organizations that treat the business as external, often troublesome departments that they continually try to cheat often have some issues with Agile adoption.

• Desire – Perhaps the most important single factor is a real desire to change. Seeing this manifest in teams, organizations and management is a real key, everything else can be fixed.

RAM – Any team/organization can and should go to Agile/Lean for all its great benefits. The trick is to build a self-funding, self-reinforcing loop of success that you can build on. You can’t mandate Agile, but you can flash-cut 100′s with executive support.

Our customers insist on fixed contract costs and delivery timeframes. We find ourselves spending too much time up front and not Agile enough. Is there a way to really make Agile work if you can’t get the customer on board to changes in cost?

DW – Fixed price and fixed timescales are not always bad. In fact many Agile processes introduce time boxes. What is crucial is that something gives to support this. Managing the backlog is key to these sorts of projects and having the right relationship with the customer such that they also feel they are in this as well. Meaning they know that the time, cost is fixed so ‘how do we deliver the right software’. One of the most exciting things about Agile development is not that you build the software faster or cheaper, but that you build the right software. You build software the customer wants and avoid WASTE! So work with the customer on the 3 types of plan (roadmap, release and sprint) and ensure you deliver what they want, working with them to manage what that means.

RAM - I agree with Dave this is not a roadblock. Many teams adopt Agile by just doing it on an existing project. Once you get some experience and success, you are in a great place to negotiate future contracts into a more cooperative model versus an adversarial contract. It is easier to negotiate from a position of confidence and strength, after you have proof.

For a specific project (not ongoing product development with a backlog) with a specific business case, you must control scope tightly and provide a delivery date to the business. How does Lean/Agile adapt to that scenario?

DW – Agile is all about planning. You need to build out at least three plans based on the scope of this project. A product roadmap or overall high level plan – this should sprinkle the features described in the business case into a series of chunks which will comprise the main releases. From there you define the releases – again based on high level knowledge – then do detailed planning for the first iteration (or iteration 0 if you like that sort of stuff).

So, how are the plans done – Well there is some interesting work done by Mike Cohn on Agile planning. His approach, and most approaches I have seen, do high level plans using the intelligence of crowds – Basically you go through the high level feature list and attribute some sort of size (story points seems to work) to each one based on experience of the group (planning poker works well here). You then assume a velocity (how fast can you deliver X). You then execute a detailed planning activity for the first iteration and feed back that experience into the plan. Thus an explicitly manage the ‘Cone of uncertainty’ .

RAM – Rally has a great whitepaper on the five levels of planning – it provides good context to Dave’s answer. The way to start Agile is to pick a time box and manage the heck out of the scope, so there should be no issue here.

How does Agile development with flexible team structures dovetail w/ organizations that have financial accounting practices that are cost-center based that drive the organization? Project that are managed by Project more adaptable?

DW – Cost center based approaches tend to be driven by organizations’ belief that you manage development resources as elements of a production line using techniques like utilization, cost and quality to manage them. These are false beliefs for the majority of most development teams. By combining IT teams with the business, it is possible to share measures and value and create cross-functional teams that add value. Supporting these teams needs to be communities of practice who are responsible for skills, development and technical promotion.

Of course I am describing the perfect world. In the short term you have to manage around the organization creating teams that show the value of breaking down those barriers. Once you demonstrate success, then change occurs. So, my recommendation is find a group of people who sit in cost centers but do not act like that and create a team. Measure them on value (as well as cost) and see if you can improve the result.

RAM – Totally agree with Dave. Cost centers are for accounting, your job is to deliver value to dominate your industry and make your customers very happy.

Look for Parts 2 and 3 of the Lean webinar Q&A  later this week.