The Virtual Coffee Series will be an ongoing, unsponsored, informal online event. People from across INTRASOFT International will meet, greet and share experiences over their continuing agile journeys. No scripts, no fixed agendas. Just friends sharing stuff. If we manage to get a sponsor we might as well offer snack and coffee, delivered at your doorstep!
Session #1: DG11 – Telco services provider Missing Use Cases (MUCs) project
Participants:
Lampros Lamprou: Agile Coach (AC) of the project
Info for Lampros Lamprou at #WeAre
Sotiris Sgontzos (S.S.): Project Manager (PM) and Product Owner (PO) of the project
Bio: 10 years of experience on business/technology consultation and projects' delivery. Deep experience in large scale Transformation Programs at major Mobile & Fixed Telco Operator, by launching numerous projects in different business areas while working with large and diverse teams. During Missing Use case’s project for telco services provider he fulfilled Product Owner’s role.
Dimitris Psarris (D.P.): Team Lead and Scrum Master (ScM) of the project
Bio: Dimitris is a Principal BSS/OSS Consultant with more than 10 years’ experience in Telco industry. He is specialized in Oracle solutions and obtains a variety of Oracle certifications (Digital BSS Transformation/RODOD, RSDOD/SNO/OSM Implementation Specialist). He is expert in Oracle OSM. He has participated in major Transformation projects for Telco Operators all over Europe (telco services provider, VODAFONE, AMC, GLOBUL/TELENOR, COSMOROM, CYTA, CableNet, Orange, MTN). During Missing Use case’s project for telco services provider he fulfilled Scrum Master’s role.
Theofanis Fragkoulis (T.F.): Software Engineer and member of the Dev team of the project
Bio: IT generalist and experienced consultant. Holder of B.Sc. in Computer Science. Having more than 10 years of experience in Telecom and other industries with a variety of roles. Have taken part in various integration projects with clients as telco services provider, Ericsson, and Telia. Experience in Consumer Goods and Services industry with roles as Product manager and software engineer. Prefer to work at the borderline between technology and business and keep constantly updated with technology trends.
Note: The facilitation and questioning were done by Lampros Lamprou.
Greetings all and thank you for being here on a busy Wednesday afternoon! As I have already told you, I want us to reflect, through a series of emergent questions, on how we managed the agile adaptation of the MUCs project. What’s the aftertaste in your mouths after some time has gone by? So, let’s get the show started, shall we?
Q: Agile knocked on your door. Your project has been decided to turn agile. How would you describe your experience so far? What has changed?
D.P.: Agile was imposed on the project. Just to be clear, when it was announced I objected; it seemed like a huge overhead! I was not willing to accept it! Not far down the road, I want to say a couple of weeks in, I changed my mind. We approached it astray from doctrines and agreed to do as much of it as would fit without breaking the project. So not 100% agile as per some specific framework but agile enough to start noticing results. We became shiftier and more results driven. The team had greater understanding of what was expected of them, both on team and individual level. Decision making got lightning fast; and from the proper stakeholders. Still, there was room for improvement. We adopted slowly but steadily. We still fight to understand our roles wearing different hats but as more time will be granted to us under the agile umbrella, we will figure out more and rip additional benefits. To sum up, it helped greatly that we refrained from a strict approach over a fixed contract clearly cut for a prescriptive approach!
Q: Even so, in strict/traditional contracts, adapting to agile, do you still see benefit? Does it make sense to pursuit it?
D.P.: Yes! There is! As stated already, right decisions by the right people and work gets smoother and we more effective.
Q: Is this because of how we formed teams in an agile kind of way and with all the events that we introduced, or not?
D.P.: Not just the events. The team gets power through agile. That brings responsibility and generates commitment and eventually team cohesion. Decentralizing did quite a lot!
Q: What about you guys? Same question for you.
S.S.: We experienced mixed feelings when management announced the agile transformation of the project. We were already looking at a tight schedule in a technology area we never dealt with before. So, we felt like they were now asking more from us; there was an ever-growing fear of overhead. The transition happened after the analysis phase of the project and the designs were there. We had already delivered documents, got signoffs from stakeholders, anything that is foreseen in the waterfall logic. After 9 months in (agile) I noticed the following:
- junior staff was asked to step up and work with and for the team; not just execute tasks handed over to them by a greater authority,
- people from different technologies working together to agree on a plan that helps all with little need for management intervention,
- people stepping up and gaining ‘leadership’ roles, driving things.
I am more than happy with what we managed to achieve whilst in this very tight contract. Yes, we had issues with excessive and frequent testing both on our end and on the customer end; but it eventually helped us deliver bug-free code! So, at the end of the day, the customer got deliverables that exceeded the expected quality and what was set as a standard. That brought us more contracts with this client. Now moving forward and as we onboard new people, this agile process is helping them catch up a lot faster and easier as compared to the past.
Q: This all sounds like a fairytale! Too good to be true! Let me challenge it, try and decompose. Let’s try and match parts of the agile process to the wins you all noted. What from agile brought about what win in your project? E.g. did retros make you guys more of a team and not individual contributors? Did the fact that you physically had to be present and actively participate in all those agile events, boost your commitment? What happened?
S.S.: If I had to make one stand out, I’d say our daily scrum. Starting from just two seniors that were driving the conversation, more stepped up and realized that all had a saying in how work progresses. Retros helped us solve internal issues. During our 1st retro we just emptied up tons of frustration that had accumulated within us and had to come out. Parts of the discussions led to actual improvements in how we work and cooperate.
Q: You’re talking of a “catharsis” event. Let me ask; should we have no agile adaptation, hence no retrospectives, would there be a way for you to emulate what happened there and get the same benefits?
D.P.: We might have held some sort of lessons learned on it, but most probably dodged it only to jump quickly onto new assignments.
Q: So, this standardization by agile helped, is no meaningless overhead?
S.S.: When the time factor kicks in its difficult to cut time out of production and throw a retro.
Q: But that’s exactly my point. Is it worth it?
S.S.: I leave that to the two of you (D.P. & T.F.) to answer…
T.F.: Retro adds value. We tend to underestimate it or deem it second in class, but it needs to be there! It fosters improvement on many levels.
D.P.: Apart from events, however, clear cut roles in agile helped a lot! I’ll insist on this. With no agile we’d have separate intra-teams, silos if you may, we would have to synch through the PM, teams would be ill represented, accusations and ball toss would rule the game. The realization of “team” through agile helped solve that quickly. The ScM does specific stuff and so does the PO and the team and so on.
Q: So, if you were to be presented with the question: how do you proceed from now on, agile or traditional? What would you choose?
D.P.: Agile! Given the appropriate environment of course.
T.F.: Same here.
Q: Despite all the implications you guys faced? It’s not an easy ride in our kind of projects! Is it so powerful after all?
T.F.: Yes. Being part of the development team (and not in a leading role) I quickly realized this approach would help me gain voice and be heard; work better!
Q: It is however still unclear to me how was the decision to go agile was made. Did management come out one day and simply announce it? Why and how so? Would you have it any other way?
S.S.: Well it was two-fold. Both from within II and the client side. II wanted to take the turn towards new development approaches and the client started realizing there were a lot of issues with prescriptive approaches in big projects (design gaps, slow delivery to name but a few). So, they just said one Thursday morning, do you want to switch to agile?
Q: Was that coined by the client or us?
S.S.: By the client, they understood that something had to be done to break traditional pitfalls and the timing with II transformation program was remarkable. And is now the client that is pushing other vendors to switch to agile as a result of our collaboration.
Q: Was any of this reflected in the contract?
S.S.: For phase 1 no, the contract remained fixed even though we managed to deliver additional scope. We didn’t get any bonus budget. On our phase 2 contract however, and having had the experience from before, we managed to agree on a different and more iterative budgeting scheme.
Q: So, are we noticing a change in the contracting process and relevant contents therein?
S.S.: Not yet! Contracting is still done traditionally. But budgeting and the release of money against sprint deliverables portrays a slow but actual turn toward the future.
Q: Turning my attention now to client engagement; how well did we manage to work with our external stakeholders and bring them in our events? Were they responsive? How did they react to continuous requests for engagement?
D.P.: Not quite ideal. First of all, there was no PO from their side, it was our guy. But even so we managed to identify and cooperate with one single point of contact from their side and with him we managed to address scope management and change (as well as sprint deliverables) in a much more efficient way as compared to before. Communications and cooperation, even outside of agile events, thickened for sure.
T.F.: I second. Client was much more engaged throughout the project’s lifecycle.
S.S.: I’ll just note here how weird it was for me to be in charge of an II team but at the same time having (through my role) to represent the customer’s interest. I had to think and respond like the customer. What I tried to achieve and think I managed it, is to convince them that I am on their side of the story; I am not the dev team. In doing so, they slowly started putting trust in my decisions and leadership. That also spawned flexibility on their side with regard to how much water they were willing to put in their wine. That also affected approval times. Initially they elaborated a lot on our input but as time went by, they trusted us more and challenged our input less and less. But having been very clear from the start that this agile project would require them to be more involved they actually did; they were there. And our excellent results led to statements like: “I don’t want to run in waterfall again or with another vendor”.
~laughs~
Q: If I had to bring a message back to II management, concerning our agile transformation program, what would that be?
S.S.: No pain, no gain!
D.P.: It’s well worth the while!
S.S.: That’s true, it’s worth the while. It initially seems too big to handle, but it pays off!
T.F.: Rephrasing S.S. I’ll say more gain, less pain! In a very complex and competitive environment, agile helps rationalize our approaches and processes as well as helps us grow our people in a more meaningful way.
Q: Last question; does the way the Agile Center of Excellence (ACoE) assigns coaches to projects work? What do you think? What other kind of participation would you expect from ACs? How could you help the team of coaches become more efficient?
S.S.: Without coaching nothing would be possible, without your help we wouldn’t have managed to adapt. Just make sure the inception phase is planned and rolled out in a timely fashion, so the team faces no surprises. Give them time to digest the change and not force things.
Q: Given this happens, how would then have the coach in the project; more active, less active?
S.S.: I’d change nothing. Perhaps a bit more of a structured approach on training us against scope management. How to write, cut and properly size user stories for example. And educating the customer accordingly.
Q: Anything else?
D.P.: Onboarding for me was adequate. I dearly enjoyed it, nothing would have been achieved without it; and I treasured the fact that we had a fixed coach for the entire duration of the project. I knew who to talk to at all times. Please keep that, it’s important!
T.F.: Involvement of the coach was adequate. A lot more got funneled from the coach to the ScM and PO but OK, eventually it reached the team.
Gentlemen thank you for this. Was quite enlightening! We’ll talk soon, take care!!
Author: Lampros Lamprou.