Sitting in front on 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?
Is it important 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 is terribly 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 (real one) two years later:
Distill 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, but 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 was chosen as 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 2 years). Framework has been considered as 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 totally 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, 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 2 years to understand that work flows in a team so that demand is balanced with capacity, and not collecting as much demands as possible and then chasing for people (cheap people in fact) to start the work and never achieve it. That is known by everyone in the company and all projects or programs are magically completed at the end of each year by changing its name (no sarcasm).
Continuous Integration was “what?”. This was completely skip 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. Budget also means “manager´s power”. This 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 for ever.
What is the traditional way of managing projects?
This is the roadmap:
- 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 an higher price. (c&r) are selecting some project manager and introduce the contract to experts in order to create the first milestone of the contract: the blueprint. Ideally the blueprint consist of standard blocks. In reality, this is an opportunity to detect new “change requests” coming from experts and not from the client.
- Blueprint is quite interactive and usually the customer and some of its representatives are active. When blueprint ends a huge 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 blueprint has been validated by the customer, this one is handed over to another team: the development team.
- Development. The development team is considered as a service provider and not a project team. The project manager hand over the blue print to the team. At this moment, all the experts and also the customer are no longer available for feedbacks. This 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, usually 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.
- Testing. The development team is handing over the tests (usually not written) to one or two testers in India who also working on something else. The project plan needs to be shorten because of budgeting costs reduction (another corporate department). So instead of 2 months they have 3 weeks.
- Delivery. The planned 3 weeks become 3 months and the project launch has again being 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?
Contract are proceed as usual and one of the consultants might become Product Owner of that development. A scrum master is identified at the beginning and attend 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 2 weeks, the team and they stakeholders gather during a Sprint Review and some options are 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 the sole direction they know, their expertise. Genuinely it is not intentional.
SMEs are “floaters”, they are helping the team to gain certain knowledge. Their job is to transfer their knowledge to the team 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 addressed 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 has been added to that genuine 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 with 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 easy to complex so that the easiest can be release for customer testing as soon as possible. Then, like in product development, additional complexity can be added into the initial process in an incremental manner.
Product roadmap and development strategy recap
- Sprints delivers PSI i.e. features
- Releases delivers 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 easiest but most visible to the hardest.
- Each release should be actionnable so that the users and customer can start a work around of the solution and provide feedback
- Think about the integration of E2E processes.
- Done means ready to deploy and fit to RUN.
- Release phase is deliver 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
- aka member of the Scrum Team
- as a team member, the process owner is self managed and cross-functional.
- works with the Product Owner
- works with the team
- works with Process Customer
- acceptance Test Driven Development (wikipedia)
- think Test automation
- perform acceptance test and/or facilitate user acceptance test workshop / Bootcamp
- 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
- 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 a 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 has to be drawn and visible to all stakeholders
- make the process visible from all stakeholders
- use visual management and facilitation techniques to enhance the product backlog
The challenge is to organize teams end to end and remove the illusion of expertise away. Another point is that you have always 2 different customers with different expectations: one for the process, another for the components of it.
Hope it helps.