Agile Life – The Key Question

It was January, not the best weather I must say, and I was thinking to myself if the weather had got something to do with how tired and exhausted I was feeling. It was raining, too, everything looked grayish outside.

We were at a conference room inside the headquarters of what was one of our biggest clients in Europe, the client was scolding our boss, and our boss was trying to flip the guilt around. Classic, it is kind of funny when you think about it years later.

– “This deliverable falls way below what I expected to see” – our client claimed.

– “We have delivered what was planned and confirmed on email, we have had tremendous delays due to part of the other team not handling the information we needed, these dependencies have affected the timeline but the deliverable is what we agreed upfront.” – my boss replied.

I actually hadn’t seen both of them talking each other in weeks, even months, had they been following up? Did we failed as a team to escalate issues? We were very thorough in doing exactly what was confirmed in paper, so that they couldn’t accuse us of not doing our part. Was there a mismatch of expectations? I really didn’t know if the situation had changed and our deliverable didn’t add the expected value, I did know we did everything that was agreed. Now I understand it is wasn’t enough; alignment and expectation management had fallen short during this project.

– “Hey Christine, what now? – I asked to my senior colleague

– “To be honest, I think both of them had a point, we will probably ask for more time and include a few new requests they have in order to accommodate changes in business and processes, but part of the work we have done will fall through the cracks. Don’t worry a few more weeks doing overtime, we’ll survive.” – she replied, she had already worked in other projects with this client.

After having some difficult conversations with our client, we agreed to start scheduling “demo” meetings with our business and operational stakeholders in order to show the outcomes of our work and gather feedback from any requirement of the project that would be subject to change. When we were done with the assessment we realized 20% of the requirements were obsolete, some business processes had improved during this period and a good number of new features were not solving some of the issues and pain-points that our stakeholders had been suffering for some time all of which meant another 2 or 3 months of rework and a very upset client, we weren’t happy either.

We had used the Waterfall project management approach, which is a linear methodology for project management which divides each project into; requirement gathering (As-Is model), design (To-Be model), development, testing, deployment.

What did happen here? Let me give you my perspective.

• The As-Is model was probably done by a person in our team that wasn’t an expert on the processes and procedures that we were trying to improve, which means as much as he or she dedicated a lot of time and effort gathering information about the process he or she would never have the same knowledge as a person that actually did the task every single day. Keeping strings attached to these people and gather feedback regularly would have helped increase the quality and impact of the project.

• The As-Is model was prepared with an old scenario, probably more than 6 months, and didn’t acknowledge the possibility of changes, which in the rapidly changing environment that we live in nowadays could have been unrealistic. 6 months can be a lot of time in the environment we work in nowadays, organizational reality and market trends changes really quickly.

• The As-Is model wasn’t validated in a way that would allow everybody impacted by the model to provide feedback, probably what would happen during this phase is that managers would review the documents very quickly, make comments based on their knowledge and decided to approve without double checking every single case with each of the persons that handled these tasks individually, which would result on issues not arising on time to have them in consideration for the project.

• The nature of the project, gathering requirements at the beginning and then delivering the project had nothing to do with the reality of the business where is crucial to keep on talking regularly with your stakeholders to understand their expectations and agree on deadlines and priorities.

• The project wasn’t subject to any kind of inspection or intermediate checks from those that would end up using our work. There was not a proper feedback system in place between us and the real users, which I have come to believe as crucial for successful rollouts.

I could go on and on analyzing more issues on the way tasks were executed but there is no point on doing this because, to be honest, many of these points are real pain points in different projects and across industries, some of them were really difficult to avoid and blaming anyone would just be ineffective. The key takeaways are, expectations weren’t met, rework had to be done, and the perceived value of our work ended up being lower compared to the effort (and overtime) that was put in place.

A few years later I started working for the same client on another project, they had changed the structure of their projects to reduce the amount of time spent in documentation, they had reduced the time to market from definition to testing and inspection and they had put in place a shorter feedback cycle. The client would check our work every two weeks and wouldn’t expect perfection, but a viable product or piece of work upon which they would provide feedback so that we could improve during the next cycle of two weeks, plans and expectations were revised every two weeks, feedback was gathered almost every day, the methodology had been imported from the US, it sounded fancy, Scrum Agile they called it. The most impressive part for me was that people were not doing overtime any more to deliver on time and within quality, believe me, in that industry it was something difficult to achieve and it was difficult for me to believe at first, call me skeptical.

I went to my first daily stand-up meeting (we will talk about this later in the book), and to my surprise one of the questions that each one of us would answer in that meeting was: “What is getting in your way or keeping you from doing your job?”.

I now believe this is one of the most powerful questions a leader can make. They proactively encouraged everybody to put any problem or roadblock in common so that we could tackle it as a team, together. They had put in place the environment for every single person in the room to be able to speak up and openly talk about any risk that would impede delivering with the quality that was expected, with this powerful question, they had generated a sense of self-accountability for each one of us by talking openly and transparently about our duties and issues we faced to deliver them.

I fell in love, I then felt kind of nerdy, you know, after falling in love with a methodology. ☺