I personally believe that I have been working in an Agile way long before that meeting in Utah when the Agile manifesto came out.

I recently found myself reflecting back to the 70's and my time in the Boy Scouts where we learned the patrol method.

There are plenty of anecdotes about companies which, through exceptional feats of agility, have been able to overcome seemingly impossible hurdles and triumph against steep odds. Some of them are even true.

But Agile development, at least with a capital A, remains a huge challenge for many established companies, especially in creating software. After all, it requires them to relinquish control over key aspects of developers and the development process precisely at a time when the risk of failing to exercise effective control can be a career-stopper. So while agility is respected, at least in principle, its wholehearted implementation is sometimes lacking.

Take a few minutes to participate in our newest LinkedIn Poll: How agile is your enterprise to changing market conditions?

We would like to know if you think you are proactive or reactive to changing market conditions!

If you've been on either side of the fence in interviews for a product manager position, the Cranky Product Manager's just finished 6-part video series on "The World's Most Generic Product Management Interview" might appeal to those who need to do a little venting.

The second video highlights a common thread of thinking amongst product managers:

• One side of the story: "Apple has the best products and therefore they must have the best product management."
• The other side: "Apple product managers are powerless. Steve Jobs and his rock star product designers completely drive the product direction while the product managers take notes."

Most CEOs are more focused on sales and revenue numbers than products that create those revenues, so product managers are used to taking the lead. Sometimes that means taking utter responsibility for the success of the product, while at other organizations it's an ongoing educational campaign – and an uphill battle – on what customers will actually spend money on. Some would say that Apple doesn't "really do" product management since the CEO takes ownership of the product instead of the company’s product managers. I would like to reshape your thinking. Apple isn't without product management; they have the ultimate product manager. Apple has one of the world's only Chief Product Managers and THAT is one key to their success.

I’m especially pleased to see Forrester analyst Tom Grant applying Agile principles, visibility and collaboration into his own research. Tom is conducting research on thought leadership in which the entire process will be visible online and the online community can have input into the research methodology.

This is the third and final post in this Scaling Agile series. I've written about the triangle of traps, the challenges of developing complex systems, and smart requirements and intelligent backlogs. In a recent conversation with John Haniotis, VP of Products at Accept, we discussed how to ensure successful adoption of agile methodologies in a large company. John’s experience with enterprise wide adoption of agile (at Intuit) points to two areas to pay attention to: mitigating risk of organizational change and managing the transition.

In my past two posts in the Scaling Agile series, I've written about the triangle of traps and the challenges of developing complex systems when scaling Agile development. Today I would like to focus on the impact and challenges at the team level when developers and product owners are forced to operate in dispersed and distributed environments – a situation that could impose serious dependencies and may have an impact on other teams.

Three points of impact

Developing complex systems stretches the agile methodology with these challenges:

How can agile be adapted to handle these challenges?

• Multiple teams are required, they are distributed, and team members are often not collocated
• There are dependencies across teams requiring tight coordination in order to deliver working versions of the system at the end of each sprint
• The scope of platform/architecture work is too big to be part of a functional team effort
• The backlog for entire system is too big to be managed at the sprint level