Group items tagged

The reason there's been so much turnover of CIOs in the last ten years is because the end users – the CEOs, the CFOs and the division heads – are unhappy with the results. When IT professionals realize this, and realize that something like Agile gives them the opportunity to create better value for their businesses, then they're going to be a lot more willing to adopt it. I hope that development organizations are starting to see around that corner.

We WANT to go Agile. How do we overcome the skepticism at the CXO level?"

My recommendation would be "try it." Agile doesn't equal risk, but changing development methods does equal some risk

t can be a big deal to say: "I'm going to change our development methodology." It makes people sit up and want to dive into deep detail before getting on board. The question comes in the form of the old development methodology: "Let me see the high level plan and what the change will be in the deliverables and methodology over the next two years." This is exactly what you're trying to avoid by going to an Agile method.

try Agile on a few small projects, measure the results, talk to users about their satisfaction, and then readdress

nitiate the shift in the most change-prone areas first, and then work it backwards through the rest of the organization

It doesn't happen everywhere at all times, and it doesn't work in all areas. It's good to recognize that up front – that software development projects adapt to this easily, but an infrastructure project would have challenges with this approach. So, select a few areas that would naturally lend themselves to Agile, such as application development, gradually introduce it to these areas that need it most, and then measure results.

Again I'd say: "Try it." Agile transition is absolutely about organizational change. To win executive support we need to speak in terms of risk management, measurement and the bottom line.

Independent Software Vendors (ISV) -teams of teams who develop software for sale, including products like network management, supply chain management, mobile applications, etc. This segment now also includes the rapidly emerging Software as a Service (SaaS) vendors. Customers are external to the enterprise.

So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.

ultimate user (mobile device user) is fairly far removed from the major technologies

Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:

Embedded Systems Example - Symbian Software Limited

Clearly, the development of a mobile phone operating system is a highly technical endeavor

mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV

the development process does not lend itself quite so easily to the traditional, customer/user facing, agile Product Manager/Product Owner roles. However, the Product Owner role must still be successfully addressed in this highly technical context.

All our POs come from engineering teams and are senior engineers with product or customer experience.

one PO to two team mapping typically, rarely 3 teams, sometimes 1

IS/IT Examples

role/title of the Business Systems Analyst

is often a reasonably good fit for the Product Owner role.

In the larger IT shop, I have also seen the role filled by Project Managers

In many cases, the self-managing and team-based planning lightens the workload for the project manager in the agile enterprise, and they often have the domain knowledge, inclination and insights necessary to fulfill the Product Owner role. Therefore, many have the time, skills and inclination to fill this role.

In our case, our product owners are in IT. They are the liaison to the business and in many cases speak for the business

Our Business Systems Analysts in IT are filling the role of Product Owner. Their previous responsibility of documenting detailed business requirements and rules now falls to the entire team in the form of user stories and acceptance tests