Customer & Service Provider interface – the End of the Story

Customer & Service Provider interface … the End of the Story 

With the start of the-then-new job in October 2015 I started writing about my experience – and especially the shortfalls – in our customer and service provider relationship. It turned out to become a triptych. This is the final – the wrap-up.

To catch up you might want to read the first post: “Customer & Service Provider – Epic fails” and the second in this series: “Customer & Service Provider – silver lining on the horizon“.

You might ask yourself … why is that the end of the story? Improvements in processes usually don’t have an end. Well, let’s see.

The Modified Setting

In the meantime we upgraded from 2,5 software developer to even 3,5 software developers. Ambition behind is …

You might guess it? …

Come on …

YES! Right – on the first attempt.

Speed up the delivery of features. Our senior management is delighted by the achievements so far – however is far from being satisfied with the results, the outcome. Still, there is great belief that more people build more results. True! BUT we’re still having the issue of not well-defined requirements and still having long periods of wait for answers from our business leads.

On a daily basis we’re still in communication mode. Twice a week our project manager and the project manager of the service provider meet to exchange progress and start discussion on new topics. Again, communication proves to be a gold nugget!

The Now Situation

Missing product management – It became so obvious, so non-neglectable, so crystal-clear. Reason behind the low througput of our development cycle is not the lack of software developers – that’s a symptomatic solution. No, root cause is: we’re lacking a professional approach to manage our products – product management is missing. Usually, product management’s major duty is to define requirements on their products and harmonize the various needs and demands from all involved parties – customer, departments, management.

If we just had some people doing exactly this job. World would be much clearer!

  • Prioritization would be easier – since the product management would clearly include management in the overall prioritization process.
  • Definition of requirements would be clearer – only well-defined stories were handed over to our service provider.
  • Decision points would be clearer – product management is the definition point for detailed questions and processes.
  • Communication would be simpler – it’s simply clear whom to ask for guidance.
  • Development would be faster – no impediments any more … why should it be slow now?

In my last post, I raised a lot of points:

  • Multiple stakeholders talking to the service provider
  • No clear communication of priorities, requirements and goals
  • Fundamental changes in design after going live
  • Bad requirement quality
  • Silo thinking
  • Low quality – not well thought-out
  • No consistent prioritization

All of them – I really believe – all of them could be solved with the implementation of an organizational change – introduce product management.

So, you might ask yourself why is this the end of the story? Well, that’s an easy one. Despite my continued effort to convince my senior management about the absolute need to improve the organization by introducing a product management person (yes, one person!), I failed. “Too expensive”. I personally decided to quit.

Lesson learned?

I’m still convinced we changed a lot for the good in the customer / service provider interface. Agile patterns did a great difference for all of us. Furthermore, the service provider did invest in agile coaching (and architecture consultancy as well … not all is gold …) and showed great willingness to cooperate – to improve.

Go on, improve your interface. It’s well worth the effort! Ah, and don’t forget to secure your senior management’s backing in early stages 🙂

Customer & Service Provider – silver lining on the horizon

Customer & Service Provider interface … epic fails and how to overcome them

In a recent post I was talking about an interesting situation regarding the collaboration with our service provider (see http://www.agile-minds.com/customer-service-provider-epic-fails/). After some weeks I’d like to take a chance to draw some conclusions and report back some successes and learnings. I definitely see some silver lining on the horizon regarding the collaboration part – but also discovered some real black holes within our organisation. It’s always the same: process insufficiencies will always show up – latest – in the IT department …

The Modified Setting

Now in the development partnership with our service provider we pay for 2,5 software developers + 0,75 project management person. This means we added significant ressources to the aspect of project planning, communication and management.

Our project management person and the pendant at the service provider really met twice a week to discuss progress, issues and need for further planning on specific tasks. In addition to that it’s me and the general manager of the service provider meeting almost weekly to discuss issues and problems. This approach helped to improve the communication a lot. We’re now in a continuous dialog. Understanding of each other has raised enormously. A great step!

The New Situation

We are still not happy with the outcome – but the reasons have changed dramatically. Previously, we as an organization were not able to articulate our needs and get this information over to our service provider. We changed our communication paradigm and introduced the face-to-face communicaion twice a week. Now, the service provider has a ways better view of our requirements and is eager to start implementation. However, a lot of our stories lack quality from a subject matter view. How did we come to this point?

Multiple stakeholders talking to the service provider – We only have one person talking about new requirements – our project manager. He’s responsible to collect requirements in-house and communicate them back to our service provider. This works quite good. We’ve setup internal bi-weekly calls to collect and prioritize requirements. We’ve had our first quarterly face-to-face meeting where we started to build and organize the company backlog.

No clear communication of priorities, requirements and goals – Flag it as solved with the previous point.

Fundamental changes in design after going live – This is still an ongoing topic. But it’s a question of educating our internal people. Since we’ve one single person doing the communication towards the service provider it’s one of his duties to explain people that if there’s a change in requirements after going live we’ll treat this change as a new requirement – and this needs to get prioritized and implemented. Education.

The New Symptoms

No progress over all – Nope. Having progress. Or eager to go on. But …

Bad requirement quality – This was not transparent so far. But it came up when we introduced the new way of working. It became clearer and clearer that our subject matter experts – the stakeholder – didn’t exactly know what they wanted – not even at the point when they were talking to the service provider. Or they knew what they wanted – but didn’t consider the other business units in the design phase.

The Idea … did work out so far

The two aspects I’ve decided to implement

  • Setting up a stable and reliable single face of contact on working level
  • Introducing basic agile principles to get to stable requirements

worked out smoothly so far. As usual the introduction of agile aspects increased transparency of involved processes and especially the quality of the different artifacts a lot. And new issues turned up.

Quality of Requirements

As said previously the introduction of agile principles – well, I’d say of new communication patterns – produced process insufficiencies of our own organization.

Silo thinking – our business is separated in different business units. The different units have their own targets and try hard to reach them. There is no competition between the units – but everybody takes care of their own business. Two of the business units eventually use the same instance of the student information system. Especially between those units we have a lot of cases where e.g. the layout of the exam certificates differs, rule sets for course acceptance differ, specializations of courses differ and so on. Small differences – which might be needed … or not – which have a big, big impact on implementation capacities. It’s a difference to create different rule sets for courses – double the implementation work. And why? Ah, the business stakeholder didn’t have time to discuss their individual needs and combine them into mutual needs.

Low quality – not well thought-out – Another point we found is the quality and depth of the various business requirements. A lot of our business requirements arrive at our project manager at a stage where it says “We need a proper implementation of …”. Well, what does “proper” mean? Many times we experience developers from the service provider receiving last-minute changes – still. That’s one of the focus points for future improvements.

No consistent prioritization – Our exec management wants to review the implementation prioritization. Fair enough. We’ve agreed on having a call/meeting every second month. In this call we’ll run through the company backlog and listen carefully to what exec management sees as top priorities. In parallel we have our working calls with the business stakeholder every second week. Together, I believe, we’ll arrive at a prioritization which puts most important topics first.

My biggest learning out of this so far?

No matter how big the issue – start introducing agile patterns. Here especially the communication, company backlog and the face-to-face meeting helped a lot to unveil the real issues behind the “bad customer / service provider” interface.

The nice part about the agile pattern is the transparency. It automatically points you to the real pain points – through transparency.

Stay tuned and read on – to be continued.

SCRUM & Planning2 – HOW will we do this?

SCRUM Planning2: Architecting the unknown – The HOW.

In SCRUM Planning2 the focus is entirely on the team identifying the HOW of the WHAT being introduced by the product owner during the course of Planning1.

In Planning1 the product owner described WHAT the user stories actually contain and WHAT the result of the finished stories should look like. Now the team has the challenge to discuss HOW this user story should be implemented. Planning2 is really essential to the team to discuss, plan, architect, argue and agree on how the business user story should be implemented in software. Both, Planning1 and Planning2 are essential activities for the team to finally commit to what they plan to deliver within this sprint iteration.

In our company, we had user stories where individual software developers were sitting days and days to solve one huge technological question. Before entering Planning2 we still were at one user story worth around 40 story points. During Planning2 the whole team came together and discussed the findings of the individual software developers. And magically, they came to a solution – valued 8 story points – implemented during this one sprint and delivered as commited. The miracle of communication!

Planning2 – in essence – reserves real quality time for the team to think through the challenges of the user stories. Allow time to discuss, to argue, to joke, to de-focus, to be creative. A good result of Planning2 is a whiteboard full of tasks associated with the user stories.

SCRUM Planning Board

Ideally, the whiteboard contains a collection of tasks being identified during the discussions in Planning2. The sum of the tasks finally deliver the user story – the associated business value. In our Planning2 sessions we introduced a color coding scheme to reflect the kind of work to be done. Green – for example – stands for quality assurance testing tasks. The more experienced the team, the better the team members know each other – and trust them – the more trustworhty actually the result of Planning2.

When the team is finished with Planning2 they continue with the commitment. During commitment they discuss what user stories they are able and willing to commit. The commitment is “carved in stone”. The scrum master pushes the team to deliver their commitment and the product owner trusts on the team to actually deliver what they commited.

The commitment is all about trust and honor.

Lessons Learned?

  • Allow the team to discuss and actually understand HOW they will deliver the WHAT
  • Leave the team alone in a room – create an atmosphere of intimacy and privacy
  • The team commits to deliver – the commitment is “carved in stone”
  • Use color coding schemes for user story tasks