Virtual Coffee Series

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 #2: Public Sector project

Participants:

 

Lampros Lamprou: Agile Coach (AC) of the project

Info for Lampros Lamprou at #WeAre

 

Nick Pittas (N.P.): Senior Project Manager (PM) and Product Owner (PO) of the project

Bio: Dr. Pittas is an experienced Senior Project Manager who has over 15 years of hands-on experience on the government sector, as well as private projects of significant scale and complexity, within his range of employment. He has proven ability to initiate, lead and manage complex tasks balancing cost, time, quality and scope issues with a customer-centric approach. Results oriented, will effectively analyze and recompose elements to achieve the objective within required limitations. Adapts easily in evolving environments with discipline and works effectively with teams. Possesses excellent presentation and interpersonal skills in English (written and oral). Experienced in customer handling, technical project management, project-product management, software analysis/design, programming, training and knowledge transfer.

 

Lampros Xagoraris (L.X.): Lead Software engineer and Scrum Master (ScM) of the project

Bio: Lampros Xagoraris is from Athens, where he works as a lead software engineer at INTRASOFT International, being a member of a team implementing large-scale information technology (IT) and web applications for private and public sector. Having graduated as an Electrical & Computer Engineer form N.T.U.A., he has 15 years of experience as a Java software engineer and has worked in companies like Oracle and OTE. He counts running, cycling and photography among his interests.

Note: The facilitation and questioning were done by Lampros Lamprou.

 

So, guys, as I was saying, this is the second call in the series, and I have to say there has been great interest in the first one.

N.P.: Hold on, let’s start with the basics, you owe us coffee. We came to the office for coffee and you’re not here!

L.L.: That is so true Nick, I do owe you coffee; raincheck for when we all meet at the office (I am remote today).

N.P.: OK, we’ll hold you accountable for that promise.

L.L.: Let’s start. As I said there’s no script, only a series of emergent questions. With, that said, I would wish to emphasize a bit on the peculiarities of your DG (DG6 – Public Sector); and as you can see Nick I have shaved and have a fresh haircut for this session!

~laughs~

L.L.: So, DG6 and Agile; or to put it differently, Public Sector and Agile. Now, both of you are experienced in Agile, you have seen it before I joined the project, so what’s your take/opinion for this attempt, to try and apply Agile practices and instill an Agile mindset in projects that “talk” to the public sector; both within borders but also internationally. Whoever wishes to take the ball be my guest.

N.P.: Shall I start Lampro?

L.X.: Go ahead!

N.P.: For me the problem in public sector is two-fold: No.1 it is a technology issue, the client is not that engaged as in the enterprise realm, which manifests in sponsors not being so helpful on the project; they tend to wait for you as a project team, to completely run the show; but this is a native problem in public sector projects. No. 2 is that most of the sector’s clients are technologically infantile. So, taking that to a strict methodology, whatever that methodology is, you have to flex for the incoming fluctuation of the client. That’s a huge challenge for all methodologies, not just Agile. Take for example traditional prescriptive approaches or other iterative ones from early Agile approaches; you need planning, which is the bottom line for me, that envelops and matches your clients’ adolescence and scope fluctuation. So in our project, our rule of thumb and project foundation, which was not applied as strictly (the team was not so empowered to be able to put feat against the ground to the client) is that the PO or pseudo-PO to perform an amount of re-planning vs. what the client insists on. So, this role (PO) and process (refinement) that we introduced allowed for the team to become more efficient and satisfy a public sector client, with all the difficulties we previously mentioned. So, to sum it up, in public sector projects we have to be extra cautious with the methodologies we select, as teams will never have the amount of empowerment they need, at least in terms of planning, and will have to face technologically callow stakeholders (there will be no guidelines provided to you by them to follow – you will be in most cases flying blind).

L.X.: I would like to add that public sector clients are also lagging behind when it comes to Agile practices and technologies, they don’t know this, so it’s difficult to utilize Agile practices when, for example, the client constantly changes their priorities, requirements, that blow up any planning attempt you may have performed. You can’t schedule, or at least it comes at a loss of heart!

N.P.: It also affects development Lampro

L.X.: Yes, there as well. As we have already seen with this current project, where the client says they will provide e.g. the necessary requirements for us to proceed but they fail to do so, and we are unable to register progress. That is both delaying, changing etc.

N.P.: Of course, in all non-internal projects, and not like in our products where the PO is your actual client, fluctuation is always there. When you have a real external client, not internal (and not that this diminishes its business value), control of the project has a 3rd party that is not you! So, things will fluctuate! That’s typical, little or medium to high amount of fluctuation, whatever, it will always be there! But even if the PO was 100% the owner, you would still experience fluctuation in planning. What about you Lampro??

L.L.: In this very moment, and listening to what you guys have to say, I want to say that what you describe is actually the case, and as you described Nick the pseudo (or proxy to put it in agile terms) PO is basically nothing more than a liaison between the project team and the actual client. He short of negotiates the scope with the actual client and then works as a bridge between the two ends of the project.

N.P.: This however, helped a lot in our case!!

L.L.: Yes indeed! Now, experiencing this peculiarity, of constantly changing scope, in the sense of an immature, ambiguous backlog that hinders planning, how were you able to manage this prior to agile, before II decided to transform, and how differently do you see us (if at all) handling this now? Have you seen anything? Is there any benefit at all in this difficult landscape?

N.P.: The team was utilizing similar approaches from before. We had small chunks of work being delivered before anyway, to be able to manage the fluctuation we talked about, because anything else was work-therapy, both in scheduling and planning, besides our conventional deliverables, the team was working like that but we now made it more formal! So, we had benefit there!

L.L.: Someone would strongly expect, due to the nature of DG6’s clientele, to hear about pure prescriptive approaches, waterfall in example, a pure phase gated governance scheme.

N.P.: No no no, this never happened…

L.L.: How so?

N.P.: Because if you try this you fail; anyone who tries to follow such an approach with an inelastic customer, such as the public sector, attempt to finalize the analysis and design phases before starting to build, they will not deliver; or run a high risk of failing to deliver in any case. One of DG6’s common practices that I suppose comes from the experience of how to deliver to the public sector, was that it overlapped tasks while cutting them in smaller chunks. We were taking the risk of developing while still in analysis and proposal exchanges. And yes, there was mitigation, there were drawbacks, but the prescriptive alternative (a pure waterfall) was bringing either conflict or extra costs!

L.L.: Can we then say, that the agile mindset and practice, not just the formalities and processes, is kind of emergent? Does it come naturally out of the nature of the projects’ we run, you run in your sector, and that you would otherwise fail to survive?

N.P.: Our team has something unique. It’s a technologically advanced team, with an up-to-date modus operandi; Public sector has a deep public sector side (~laughs~) which means that it comprise a bit more linear projects; I cannot speak on behalf of all DG6 projects, but for those that we were involved we had those practices; not so formalized, e.g. we did not have JIRA boards as now, or we did not dub our mode as Scrumban, but the flexibility was there. That background helped a lot in formalizing it and for the team to accept the new flow of work. So, a lot of stuff now have names, daily, planning, etc. Things that were happening previously, yes, but in an informal manner. That’s why I think we had narrow adaptation cost in terms of the type of projects we handle. Or at least that’s my take!

L.X.: What I want to add is that the principles and guidelines of agile we were already following; we were not calling it agile, scrum or whatever, but were trying to work with whopping specifications and cut them down to small chunks, develop them, distribute, and proceed in a step by step manner; with the risk of having the client change it of course, but that’s something we still have!

L.L.: Just want to note here guys, that all frameworks, including scrum that you both know, are empirical in nature, which in your case it practically means that you followed a different path to end up in a similar (to scrum) approach because this is what ultimately works. You can argue that what you brought to the table we were already doing but we didn’t have names for them. And that’s basically what Agile comes to say, that the best practices from teams across industries, the collection of it, is what comprises agile.

N.P.: No no no, on the contrary I would say that we got chance (for something we were practicing imperfectly) to make it more formal and upscale it. So, I’m taking this in reverse to your conclusion. So, what we were doing that may have not been aligned and compatible with other teams, we got the chance to make it so and perhaps take that to how we manage projects and the group overall. Perhaps also to draw some lines between teams and project governance. Now moving forward, in the projects to come we want to make this even more strict. What we had before was loose. We have now set the foundation to make it more formal. In the next project we wish to secure the way the team works and care for its seclusion, while always of course keeping in mind we deliver to the public sector.

L.L.: So, you say we were in a much looser approach, we were in a ‘green’ Scrumban so to speak, but consciously chose to be there because of our clients’ lack of elasticity. Given that DG6’s landscape and clientele will not change in the foreseeable future, what makes you think that a stricter approach (full blown scrum) will be even more effective?

N.P.: Not all clients are the same; some of them are more mature than others and have been handling systems for years, so a good planning there could be performed in a stricter manner. And have the client be a partaker of the process. In less experienced clients perhaps, this will not roll out that well (needless to mention cases here) or in big monolithic projects (turnkey solution projects). This project had some requirements documented, but more of a wish list, just a general idea of what they wanted. Another upcoming project we have for example would be a good candidate where we could tighten the process, involve the client, and minimize project costs; because drawbacks, regardless of us finding ways to deliver, incur costs. Having the client engaged and avoiding having to build things twice or three times, as has been the case in this project and in others, brings operating costs down. So, the agile framework has an overall impact to the performance of the project and of the company in proportion.

L.L.: Nick allow me to interrupt, and Lampro you correct as well if I’m wrong, what you’re practically saying is that after we perform an assessment on who we have in front of us, client’s receptiveness in agile approaches keeping in mind agile wants/brings the customer in, with your current experience you see benefit from such approaches? Would you want DG6, with the assessment we just mentioned, to walk toward that direction? There’s stuff to take out of this…or not?

N.P.: The team certainly wants...DG6 is a different discussion and has to do with other projects, situations and discussions that are not easily comprehended by our team. Our division was always agile savvy, trained, so by default we wanted this work approach. We were fertile ground. But I consider it to be a very good practice to operate with, especially in big projects. Again, for DG6 I cannot generalize. Perhaps colleagues from other teams have different experiences, because as you said before, this thing is empirical. We personally would like to identify mature clients that will enable us to operate in a strict agile approach, with them as partakers, both operationally and delivery of the project.

L.L.: Lampro?

L.X.: I think we benefited from adopting Agile, Scrumban in particular, the formalization we introduced, for example the team backlog, gave the team a transparent view of what is to be developed, what we have to cope with despite of the injected changes (sometimes even radical ones) we talked before, and better plan for the expected work. Now we have the inherent risk (both team wise but also DG6 wise) of not being dedicated to a specific project; as resources we’re not fixed to projects and carry multiple projects on our shoulders that evidently create anomalies in our attempts to do agile. It makes it harder!

N.P.: This also has to do with the nature of the team, in the matrix we’re both horizontally and vertically placed and there’s external fluctuation there as well. But in all honesty guys, we can’t just leave a project to turn red for 5 hours of work, even if that means leaving work behind. There’s an amount of rationalization that is performed by both the team and management that I think is both wanted and necessary! Obviously Lampros (Xagoraris) talks of big projects that engage horizontally with a lot of people on a permanent basis, but OK, as I said external fluctuations are everybody’s reality, I guess your team also experiences that…

Now I have a question for you…if you have nothing else for us…

L.L.: Please, be my guest!

N.P.: And it’s a sincere question, compared to other DG6 projects, the team you worked with, what could we fix and how do we compare to those other DG6 teams that follow agile?

L.L.: From DG6 you’re the pioneers of agile. We did do some attempts with other projects, we probed other teams, but it did not flourish for a collection of reasons.

N.P.: So, we’re the only ones in DG6?

L.L.: That is correct!

N.P.: So, in the absence of competition we’re the best!!

L.L.: Absolutely!!

~laughs~

N.P.: So, we run the race alone and we win!

L.L.: I was extremely skeptical at the beginning I have to be honest, there was bad precedence. The guys in the teams clearly wanted it, because many of them know agile and the benefits therein, but on the governance structures, the timing was not ideal.

N.P.: I think however that things, given time and a certain amount of flexibility, could work similarly for other projects…

L.L.: But to answer your question, even if there were other adapting teams in DG6 I would refrain from comparing because...

N.P.: You know what, if there were pointers that could help, we would want this!

L.L.: First of all, Nick you’re incomparable as you’re II’s first Scrumban project. It is only now that others are starting. What I will say is that with the challenges this project has with not just having a cumbersome end client but also an intermediate associate, the team did exceedingly well. The team had a backlog, it kept it going, maintained it properly and results already speak. The team despite odds managed to deliver on time and scope. It managed to work with the scope, cut it down to User Stories, analyze incoming stuff while building and in general it exercised maturity. I’ve noticed quite a lot there. But what I also notice in general, not inherent to the project that is, there’s a big issue in transparency. In the traditional SW development world, teams have been led to operate in a semi-transparent mode, because for good or for bad corporations try to hide certain ‘ills’ from propagating outward; nothing related to individuals of course or their performance…

N.P.: I am going to claim ignorance of what you’re saying…

~laughs~

L.L.: So, what I would change to return to your question, and take this as a wish, whether you continue your agile journey with or without me, pay special attention to transparency. That can come in the form of an information radiator (board), and be very cordial with events like planning, retrospectives and of course dailies, because right there, in these events you cultivate trust and eventually team spirit! You may already have that, given you work together for a long time, but in other project teams this is absent and it’s the only vehicle we have toward achieving trust.

N.P.: I understand and agree! However please forgive me I am running out of time!

L.L.: One last question guys and we’re all off! If I had to bring a message back to II management, concerning our agile transformation program, what would that be?

N.P.: Management should create those structures so that all levels understand the benefits of empowering the teams. That would be my message to II’s management. I understand there might be strategic planning on adopting agile, but this has to flow from a level 9 engineer toward our executive management. The plan by itself is not enough. We need to start making steps toward it, all of us! Embody the plan, especially in domains like ours (public sector) with demanding clients, outdated formats, etc.

L.L.: So, Nick in general you’re pro agile, right?

N.P.: Yes, absolutely! But it needs to be all of us. It says nothing if I am agile and you impose things to me and my team that inhibit the adaptation. That will only lead to a masqueraded adoption with no measurable outcomes, and we don’t want that, we truly want to be agile.

L.L.: Lampro (Xagoraris) lets close with you…same question!

L.X.: I will also agree. Agile brings more benefits than drawbacks. As Nick said, wherever possible (through careful assessing) it needs to be deployed. And my second point would be on attunement. Either we all become agile or it does not work. Agile teams need to work with agile teams and have agile management. Otherwise its practically impossible to get things done.

L.L.: So agile across II would also be your message to management?

L.X.: Wherever and whenever possible yes!

L.L.: And the teams you speak of, are not just development teams, but all teams within and around an agile project, right?

L.X.: Absolutely! And don’t forget that we as a business segment have challenging contracts and clients. It is difficult for II to convince the customer to go agile; we need to approach this carefully and with time allow for the noted market shift to agile grow in them. They need to realize on their own the strengths of agile!

L.L.: Lampro (Xagoraris) would you see benefit from consulting toward our clients? Having II’s ACoE hosting training and consulting events for our clients to help them better understand the practice? Would clients be willing to receive it?

L.X.:  Absolutely. An educated customer would really help! At least grasp the overall idea of what we’re trying to achieve through agile.

L.L.: Were your clients receptive to agile, given that this contract was partially written in agile terms?

L.X.: Not really! We run agile without them knowing. And that’s one of the problems, they pop out of nowhere with changes and requests!!

L.L.: I see.

 

Gentlemen I want to sincerely thank you for this. I know your time is limited! We’ll talk soon, take care!!