I am currently working in an organisation currently which has an evolved waterfall method and shared resource utilisation nailed down so well that they now have actually quite a successful track record with delivery in this. Many years of investment and planning and automation of management process has led to a machine that is actually quite smooth in terms of requirements to delivery planning.
We have been given a directive to try to be more Agile, the reason for which is unclear but trying to keep things short - we are where we are. They want to Pilot and Agile Scrum project. Replace a legacy desktop application to Web based open source tech (Java, MySQL etc)
Business: A huge number of departments, SME's in each, not technical, who run various applications. If they want change, they contact a Requirements who then produce a requirements document.
I have had a Product Owner assigned from the business who knows the current system and business process. He will be completely new in both technique and delivery. Risk.
Technical: They have silos of teams in terms of physical location (but same building) and technical area. Architecture, Technical/Data Analysts, ETL, Java and Test. Currently produce estimates based on completed documents by the previous team, driving the design process through. No one seems to have a problem with it. Everything is dependency linked, Architecture do their docs, Data and ETL plug their bits in, docs get approved and then Test quotes on all of it.
100% dedicated team (normally its 30%), all sitting together size of 7 comprising:
2 Java devs, 1 external to be placed with scrum experience and mentor the internal
1 Data Analyst - modelling and implementing tables/procs etc for Dev
1 ETL - inputs from external systems and outputs to..
1 Scrum Master - External
1 Product Owner - business
2 week Sprints, pure Scrum method.
This project is full of risk:
Tech: New techs to implement, JBOSS, MySQL, GIT, Jenkins, Eggplant etc that allow for Cont Int, Regression test tools people have never used, reporting tools and bolt ons that are all new and little to no experience
Skills: Silo development means responsibilities and job profiles are traditionally so defined that people automatically revert to what their bit is before moving on
Business: Lack of vision, and lack of experience in IT change/Prod Own process.
Culture: Potentially going to result in current process being implemented every 2 weeks, with some technical additions to support the regression area. Is this a bad thing?
1. Deliver a replacement solution
2. Build capability within the department for delivering in Agile - use internals to learn
I have to be pragmatic with the people I have, the skills I have and the people working is going to be a massive challenge for all, I have people who hopefully are open to working in a different way, but I need some advice as to practical things and arguments I can provide to people to stop them arguing the 'I can't do this until so and so finishes his bit etc'. My argument so far is, there is always work you can help with, it may not be DB or ETL stuff but you can do other things. Example of an argument. I went to see ETL. They said they work off mapping documents DA's produce after looking at the relationships. Hence they say they cannot quote or do anything until they have that document.
I have already made it clear that their current 'job spec' doesn't fit Agile - they will do more/different stuff and must be willing (they say yes but do they mean it, we shall see), but does anyone have any practical advice/experience they can share that can assist with this cultural move that will help me accelerate the mindset shift?