Agile Pilot within Waterfall Culture and Mindset - HELP!
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?
What is your role? What is your background? What is your experience in Scrum?
If someone put a gun to your head and said, "How long do you think the re-write will take? You have 60 seconds to give me your best guess", what would you say, knowing that your life would be ended if you did not answer? Note that you don't have to be accurate -- no one will shoot you if you're wrong -- but you have to give them your best guess in 60 seconds-- otherwise they will shoot you.
I have to say, if what they're currently doing is so successful, I question why they want to change. "Be more Agile" is kind of a "false" adoption goal, and could set your pilot project up for complete failure. Seems like your org really needs some coaching because "be more Agile" is not a good place to start really. We need to get deeper into their business goals and current situation.
My role is setting up the team and ensuring the goals mentioned are achieved (deliver the replacement and build experience of tools and delivery in the team). Basically I am a Technical PM. I am a recent Scrum Master, but don't have much experience. I am only responsible for delivery - not strategy - this direction is coming from rather high up and the organisation wants to have options for more than one method of delivery. I agree that it would have been good to know they why's, but i'm afraid I don't. So we are where we are.
As for the rewrite, this has been attempted a couple of times before, but failed, for different reasons. I know one of the attempts took over 1 year and wasn't delivered. This was done as more DSDM as far as I understand, but everyone had left so there is little history. It was attempted nearly 10 yrs ago.
Their idea was to pick from one of many projects and to try to develop it in Agile. I don't think this is particularly new, some may get consultancies in and run it with key personnel shadowing it, they have tried that before but it failed because they didnt have the right balance of resources retaining the knowledge or buy in. This attempt is to get them not just watching but doing. The resources chosen have been selected because they think they possess the right characteristics, they just don't have the experience. That is why I am getting externals in who DO have experience to coach, but some people will have to learn on the job. I have a lot of the risks down but am looking to find others who have experienced similar situations and how they managed.
> We have been given a directive to try to be more Agile...
Well, at least you seem to have executive sponsorship for this agile transformation. There'll be cultural and technical barriers to overcome, but the political ones are apparently mitigated. Is this quite true though?
Where does the directive come from? Does it come from senior management, or a departmental middle manager? Assuming it comes from the top, if your company is very large you can expect layers of middle management and vested interests to deal with. You can expect people who will *not* be on board with the directive, and who could be rooting for the transformation to fail so they can continue "as normal". Moreover, since the business case for this transformation is unclear, who can really blame them?
These twists in the political landscape will have to be navigated, and it may fall to *you* to establish a direct line to the seniors, and to connect the transformation strategy with its operational implementation. As a first action, you must find out *why* this agile transition has become a strategic goal, and the problems it is meant to solve. If you don't know the answer yourself, you can hardly explain it to others. Assuming you can get this clarification, your next action should be to agree an actual transformation strategy so that this goal can be achieved.
> 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 advice is DON'T stop them from doing that, at least not to begin with. An agile transformation strategy usually needs to be done in baby steps. There are exceptions such as Jeff Sutherland's Shock Therapy approach, but most organizations don't have the appetite for much 'shock'. They are too risk-averse, and are reluctant to substantially change an operating model that is in flight.
The first step in a managed agile transformation strategy - the strategy you need to agree with the executive sponsors - should be to build transparency. Transparency always comes first. Don't try and change or improve the process until you get good transparency in place, and the stakeholders can see what is going on and where improvements can be made.
So don't try and squash people who say ''I can't do this until so and so finishes his bit etc'. On the contrary, that's exactly the sort of information you need to expose. An agile team should own its process, and if it doesn't, you need to show it. In fact this is often a good way to get buy-in at an early stage of agile adoption, because people often think in terms of blame and are not yet ready to work collaboratively. If you set up a Kanban or task board, and position it as a tool for that transparency, team members will be able to say "look, it's not my fault, it's that useless lot over there!". And guess what? Each team will be able to do this, and then the executive sponsors will be able to see that teams do *not* in fact own their processes as they had assumed. Furthermore, each team can then be coached to question the work they are taking on board when they aren't in a position to finish it, and what they can do to induct work in such a way that impediments are unlikely to happen. These are the questions that encourage change, and it is a seed from which more useful inspection and adaptation patterns can grow.
Chaps - many thanks for your views, I think we are covered from support from management, its more of a cultural thing with the technical guys that will need some coaching - I like that advice regarding 'let it happen its all part of it', I think there is only so much you can prepare for - it will be interesting to see how their empowerment will translate into action!