17 October 2012

Agile Adoption Webinar (Part 1): Questions & Answers

Last week, Planbox invited Greg Geracie and Steven Starke from Actuation Consulting for a live webinar about agile adoption. The webinar was based on their recently published study, in which they uncover 5 common key factors that were all present in high-performing product teams. In addition, they authors discuss recent trends in project management methodologies.  

Watch the full webinar recording here. 

  In this first part of a series of 2 blog posts about the agile adoption webinar, we will share with you some questions that attendees had for our guest speakers. Thank you to Greg and Steven for having provided some very insightful answers.

  Questions & Answers   Q. Limited resources seems to play a major role in our company going full Agile. We don't have a business analyst (BA), our Product Manager is part-time, and our development teams span across products. Is this a common roadblock or are we just not disciplined?  A. (Greg) - In my experience, fully implementing Agile is more resource intensive - not less. The Agile process is particularly demanding of a product manager's time. Executive teams often don't fully understand the resource intensive nature of Agile implementation and underestimate the need for additional resources. This frequently means that market-facing and more strategic activities suffer as the team devotes its energy to covering pressing tactical activities. This is costly in the long run. Under-staffing is not uncommon, particularly now, as organizations have aggressively downsized due to the current economic situation. However, to be most effective the team needs to be properly staffed.   Q.Did you find a correlation between a particular type of methodology and a higher rate project success? A. (Greg) - The short answer is no, but we intend to take a closer look at this in next years study.   Q. Is the high prevalence of waterfall because waterfall works (in some cases) or because Lean/Agile is hard to embed in the larger cultures? A. (Greg) - I think there is truth to both of your comments. From my perspective, no single product development methodology is a panacea for all the types of product development challenges. So waterfall continues to be robustly used, even if the current conventional wisdom is that it's "old school" and part of the past, because it's effective when used under the right conditions, particularly within large and complex organizations with large and complex projects. Waterfall continues to have a tight hold on manufacturing type environments where predictability is highly valued. (Steve) - The waterfall approach is much easier to govern for Senior Managers and Executives as opposed to an Agile approach. Especially, in a world where outside bodies are required to regulate the work, a waterfall approach is easier to explain and very deliberate in terms of deliverables. It may take "longer" but it may pass an audit much quicker. That reason alone is why some organizations are very pro-waterfall and why it's still very prevalent throughout the industry.   Q. Diana Larsen's new book - Liftoff has a very specific process for chartering Agile teams and projects. It's a great way to communicate strategic and tactical vision. Would something like that inform the team with enough information to enable them to help "on board" new members? A. (Steve) - I have not read Diana's book so I can't speak to specifics on it's effectiveness. However, generally speaking, any tool or approach that increases communication around both strategic vision and and tactical execution would definitely help in providing the additional context required to effectively on board new team members.   Q.What does the data show about which methodology is dominant in different phases of a project? A. (Greg) - Excellent question! The data does not break the responses down into the different project phases but looks at the prevalence of the dominant process overall. However, you raise an interesting point given the findings.   Q. I've seen some organizations describe the workflow such that the process of deciding what goes into a product is waterfall, but how it gets built is "Agile" (iterative incremental). Can your findings expose situations such as these? A. (Greg) - Since this was the first time we ran the study (we'll continue to conduct it annually) we did not structure the questions to capture the situations you're referencing. However, as noted earlier, given that we have established a baseline we can now dive into the findings with more rigor, which we intend to do in upcoming surveys.   Q. What do you think of "valve software-like" approaches with flat hierarchies and self-organizing teams? A. (Greg) - I'm well known for being product development methodology agnostic. I believe that you have to select the best approach based upon what you're trying to achieve, the skills available to you and the team, the level of available resources, etc. However, whenever you can have a streamlined and self-motivated team with an internally driven sense of purpose and high levels of commitment you're more likely to succeed (in my experience).  (Steve) - I completely agree with Greg. Self-organizing teams, acting in the true spirit of getting the work done, despite role and organizational structure constraints, are extremely successful and valuable to an organization.The only word of caution is to ensure that "self-organizing" doesn't mean "self-governing". A certain amount of organizational governance is still required to ensure the team is heading in the right direction based on organizational goals and objectives.   Q. Why is there a positive correlation between increase in waterfall and size of company? A. (Greg) - Several factors likely contribute to this. First, large organizations typically have large and complex product development projects and waterfall is normally chosen to address these types of challenges. Second, large organizations need to train a significant amount of personnel to fully convert to Agile, so even if they decide to do so, it'll take much longer and be more costly (assuming that they don't decide to outsource development). Third, mature organizations that are successful in the marketplace have less reason to change what has worked for them. And even if they decide to change, it'll take longer to turn the battleship around.   Q. Does "blended" mean that some teams are waterfall and some agile, or that some processes are waterfall and some processes agile? A. (Greg) - Blended actually means - in terms of our survey results - that organizations are using an iterative incremental methodology (Agile) and combining it with waterfall in some fashion. The actual way this is being done at the "local" level varies based upon the organization. We're aware of at least 5 different variations on this theme and we're convinced there are even more that we have yet to encounter.   Q. Will you be sharing any details about the blended methodologies - how do companies blend the two methods, different by project, by project phase etc? Also, why is blending done? A. (Greg) - We did not collect the actual ways this is being done in the survey data but have since gleaned some insight into what's actually taking place from follow on conversations. You can expect to see more details about what we have learned in next years white paper.   Q. Regarding factor four [Assigning core product team members based on the skills needed] - given resources in companies are always tight, how do you suggest multiple projects are staffed and supported through launch? A. (Steve) - I truly believe the size of the portfolio will dictate the level of enterprise resource management required to sustain product development through launch. As soon as assumptions are made with resource allocations, is as soon as projects are understaffed.Resources managers really need to understand what the true outcomes are of the project and ensure resources are staffed until those outcomes are achieved - through launch. A well functioning enterprise resource manager role can balance out the resource pool and look for opportunities between resources and projects as different products approach launch at different times. A role within a PMO can serve this need or someone specifically hired to do enterprise resource management.   You might also be interested in: Agile Adoption Webinar (Part 2): Infographic
comments powered by Disqus