Is agile possible in an SAP (ERP) or Business Process related context (Banks) possible?
Sitting in front of my computer and writing these lines let emerge in me an angel and devil fight. Should I push forward everything that doesn’t work or should I explain what works? What if people are feeling injured by these words? What if my customers are feeling offended by these lines? What if people are misinterpreting this post like a revolutionary manifesto? What if I lose most of my contracts?
Or…
Is it essential to share my experience with fellows trying to balance with what they feel and what they feel? Usually, the feeling is that agile is feasible and the fact is that it is complicated or not.
So here my humble insights coming from lots of problem-solving experiments with teams of developers, managers and leaders mostly in large banks but also with SAP S.E. I thank all these people for their trust and their passion on this challenge.
How everything usually begins?
Like everything, you start with a proposal, a first draft to explain how we might proceed:
This is an “appetizer”; this is the ideal world… when you know nothing about the context, the culture, the maturity and the “gremlins” or other “toxins”. This the picture of the CV, the certification paper that opens the door so that someone at your customer side cannot say that you don’t know your job.
Besides the toolbox and because you are a professional, you have to provide a timeline to estimate how much you will cost:
Even if in a bird view, this is about investing in a better future, most of the managers are cost killers, but this is part of the game.
Even if this is mostly false because it is an assumption, I made myself a review of that roadmap (a real one) two years later:
Distil Agile Mindset was “so so”, this means that you are still struggling with the simple, agile ideas like self-management and prioritization. Why? There is magic here or people believing that once you have one or more agile coaches in your enterprise, the job (agile mindset) is done. Hmm. It is acceptable that our clients need time to change? I have to be honest by writing that human nature is what it is and most of the hints came from other agile coaches, or managers hiring other coaches, or “nominated” agile coaches and Head of agile without any experience of agility other than having once hired a scrum master, have watched something about agile on YouTube… Anyway, this is the part of change management that I ‘don’t want to explain today.
Scrum was “so so”. Scrum becomes the main framework, and that’s fine. (Even if you believe in the magic of SAFe or LESS, you have to set up Scrum for the first two years). The framework is a “chocolate box” this means that if you are picking all the white chocolate and leave the black one, you are considering doing Scrum. That’s wrong! It took a while to explain that Scrum is a minimalistic organizational model working as a scaffolding to create agile dynamics. ‘It’s not “by the book”, or “100%”, it is all or nothing. This point was only the pic of the iceberg, and the real problem was resource allocation (this is the name to let individual working in several teams, 10% on this, 20% on that, 40% of those, etc…). You get it, agile ‘doesn’t work in matrix organizations. So so, because it took around two years to understand that workflow in a team so that demand balance with capacity, and not collecting as many orders as possible and then chasing for people (cheap people in fact) to start the work and never achieve it. , and all projects or programs are magically completed at the end of each year by changing its name (no sarcasm).
Continuous Integration was “what?”. Continuous Integration was entirely skipped away because Build has a budget, Run has a budget, Data has a budget, Infrastructure has a budget, Operations is mostly offshore third parties, and nobody cares about Business or Service Desk. Budget means has a manager. The budget also means “‘manager’s power”. Management politics is a war that you will lose.
DevOps was “so so”. Ok, more so than so in fact and that due to the previous paragraph. In reality, even in the Phoenix Project is on most managers desk, DevOps has been completely “trolled”. DevOps means now that the developers have to ensure Service level 1 and 2 (support) in the context I explained in the Scrum paragraph before.
Ok! Even this sounds a bit depressing, we have to adapt to the context, and some old habits are quite complicated to change in big global organizations. And in a second hand, this also no finger pointing but just the consequence of a lack of purpose and overwhelming bureaucracy leading to reproduce obsolete processes forever.
What is the traditional way of managing projects?
This is the roadmap:
1 .Consulting & sales got a contract and a development agreement where both parts are trying to make a win. In reality, consulting & sales (c&r) are looking to get more in their “pipe” and expect to detect new opportunities for change (change requests) where they can charge to a higher price. (c&r) Are selecting some project manager and introduce the contract to experts to create the first milestone of the contract: the blueprint. Ideally, the blueprint consists of standard blocks. In reality, this is an opportunity to detect new “change requests” coming from experts and not from the client.
Blueprint is entirely interactive, and usually, the customer and some of its representatives are active. When the design ends, a massive part of the project budget is consumed. In digital projects, “blueprint” is called “customer journey”, different names, same nature, same effects, same outcomes. Once the customer has validated the blueprint, this one is handed over to another team: the development team.
2. Development. The development team is a service provider and not a project team. The project manager hand over the blueprint to the side. At this moment, all the experts and also the customer is no longer available for feedbacks. The switch from scope to development is at this stage that usually people are remembering agile and are asking for help to ensure the delivery of what has been promised by tiers. The development team needs to understand rapidly what this is all about; usually, no one is collocated, regularly they are also working for one or two other project managers and some requests from different managers. After postponing the deadline one or two times, 70% of the development is ready for testing.
3. Testing. The development team is handing over the tests (usually not written) to one or two testers in India who are also working on something else. The project plan needs to shorten because of budgeting costs reduction (another corporate department). So instead of 2 months, they have three weeks.
4. Delivery. The planned three weeks become three months, and the project launch has again been postponed due to SOX Freeze, system unavailability. The project run over 300% of the budget, get close to one year overtime, and the customer is just happy to get something done.
Note: indeed this a stereotype to explain what is coming now.
Lessons learned towards agile: agile is made for development only, that excludes the project set up, the blueprint, the testing and the delivery. That is just wrong regards project management, totally wrong regards scrum, and the only agility here is for c&s.
How should it looks like?
The contract is proceeded as usual, and one of the consultants might become Product Owner of that development. A scrum master is identified at the beginning and attends all the meetings to meet all stakeholders.
agile principle #1 : you plan it, you make it
The Product Owner and Scrum master are setting up the development team that is 100% dedicated to that project.
To avoid wasting time, the full Scrum team (PO+SM+Developers) are identifying with the customer and its users what the needs are:
agile principle #2: focus on customer and users
From that exercise, the team discover what the real needs are, and the Product Owner is in charge to translate these needs into a vision.
agile principle #3: Product is not the voice of the customer. (S)he translates customers expectations into a vision. The customer has its own voice.
After two weeks, the team and the stakeholders gather during a Sprint Review, and some options shown, and the customer decides what matters and choose one. The others are skipped away or destroyed.
agile principle #4: Requisite is waste
Then the team starts to develop with what they know and build on the top of it.
Every sprint end, the customer can come with change requests which be negotiated with the Product Owner ideally in front of the team.
How to work with experts?
Experts or SME are necessary but not at the project start. Due to their expertise biases, they will pull the project into a single direction they know, their expertise. Genuinely it is not intentional.
SMEs are “floaters”; they are helping the team to gain specific knowledge. Their job is to transfer their knowledge to the side and coach it.
agile principle #5: cross-functional team members and SMEs as coach
Composition of a Scrum Team
Developing or integrating or configuring a business process has a particularity; it is addressing different customers for different purposes:
- one customer for the end-to-end business process
- several customers for the components directed by that business process
The Scrum Team cannot be a Product or functional team; it is always an end-to-end process development team: that's what needs to be developed, right?
agile principle #6: all teams are end-to-end
One role added to that official scrum team, the process owner.
If you are merging Product Owner and Process Owner, you will lose your component customers. In this model, the Product Owner is in charge of both customers and build its development strategy based on components and process.
Components or features like in the figure beyond should be small enough to be completed during one sprint (max sprint length of 2 weeks) and end-to-end processes should be deliverable once a month.
End-to-end processes have to be decomposed from uncomplicated to elaborate so that the easiest can be release for customer testing as soon as possible. Then, as in product development, additional complexity can be added into the initial process incrementally.
Product roadmap and development strategy recap
- Sprints deliver PSI, i.e. features
- Releases offer End-to-end processes incl. these features
- Focus is given to involve both customer and user since the beginning of the solution development.
- Deliver standards from the most accessible but most visible to the hardest.
- Each release should be actionable so that the users and customer can start workaround of the solution and provide feedback
- Think about the integration of E2E processes.
- Done means ready to deploy and fit to RUN.
- The release phase is delivering standard and collect change and start custom.
agile principle #7: The end-to-end (E2E) process is the outcome and not the input of a development process
Role of the Process Owner
develop
- aka member of the Scrum Team
- as a team member, the process owner is self managed and cross-functional.
collaborate
- works with the Product Owner
- works with the team
- works with Process Customer
test
- acceptance Test Driven Development (wikipedia)
- think Test automation
- perform acceptance test and/or facilitate user acceptance test workshop / Bootcamp
co-work
- as a team mate, the Process Owner helps the team to reach the Sprint Goal also for works that are outside his/her comfort zone
equal
- not an authority
- all team members have the same hierarchical level within the Scrum team, that’s the rule of the Scrum Game
Challenges for the Process Owner
- identify the User in an end-to-end (E2E)process and create the User Stories
- update the product roadmap with the Product Owner
- identify the User/Customer for E2E process
- define the persona aka User Role
- collect User Stories from the Users
- update the Product Backlog with the Product Owner
- ensure or write the tests cases
- ensure that the E2E process is INVEST (independent, negotiable, valuable, estimable, sized to fit, testable)
- ensure the integration of E2E processes in a single process
- update the process
- E2E is part of Release DoD
- create the definition of done (DoD) of the E2E process and work with the Product Owner to update the Release DoD accordingly
- E2E drawn and visible to all stakeholders
- make the process visible from all stakeholders
- use visual management and facilitation techniques to enhance the product backlog
Last recommendations
The challenge is to organize teams end to end and remove the illusion of expertise away. Another point is that you always have 2 different customers with different expectations: one for the process, another for the components of it.
Hope it helps.
Pierre
