PM’s confessions #1 – The long road to Agile

I’d like to invite you on a journey we went on with one of our partners some time ago. The trip might not be the easiest one we had but as we pride ourselves in going beyond we’re used to picking the hard road. We not only extended our client’s development teams, but also we had a chance to became our partner’s guide by proposing quite different approach to internal software development process and applying several improvements. Let’s not jump to the conclusion though and start in a way a good story should be opened – with the beginning.  

Chapter 1. The beginning

Imagine that your company is a stable provider of IT business solutions operating in quite narrow financial market. Your customers need your product to be customized due to their country’s legal requirements. What makes it difficult is that your product is a huge monolithic app. To provide the highest quality, which is one of your trademarks, you need to enlarge your development teams. Hiring experienced software developers in your hometown seems like mission impossible so instead of looking for Tom Cruise mask you start to search for a new business partner. Hence your company is divided into separated departments such as test, development, BA and so on and you’re the only one that sees the potential of engaging external partner it’s anything but easy. Moreover, you’ve never worked with an external company before so even though you start researching and setting up meetings, you’re afraid of losing money and reputation. Once you selected the company to go with, to decrease the chance of failure you decide to start with a  small team of outsourced developers and verify how would it affect your organization. And that’s the moment when the fun begins ?  

Chapter 2. First handshakes

Workshops happening at our Client office launched the cooperation. The goal of these is to become familiar with the business environment, organizational culture and most importantly – the people from the other side. After getting onboard, shaking some hands and drinking a few beers it was time to come back home and start working. Apart from skills and experience these relations are what would make the cooperation efficient, so what should be done to maintain them? Agile and its practices support building relationship and communication. But how to implement these in the organization where no one heard of it? We decided to go with small steps rather than trying to run the complete Scrum process at once. The first one was to enhance communication flow – which is one of the goals of Daily Scrum. Although the main reason to run Daily is to reorganize the work for the next 24 hours so the previously set objectives could be reached, this meeting have a significant social aspect as well – like I said, small steps. During this step of our journey, we managed to convince our client it’s worth to be in touch on a daily basis and turning the camera on, so we can actually not only hear but also see each other, can help .  

Chapter 3. Developers do not bite

As we went back on the road after establishing basics of communication between developers it was time to extend the range of roles participating in our Daily. Development itself brings no value to the business unless it meets the business requirements, which represent customers’ expectations. Not only being familiar with the product environment but also the ability to quickly resolve any doubts with someone from the business department highly boost effectiveness. That’s why we decided to overcome the split structure of the client organization. Including BA’s in our stand-ups wasn’t an easy task, but after they were convinced developers won’t bite and the positive impact of their participation is real no one complained. To be completely honest – at the end of the day, this idea received nothing but positive feedback.  

Chapter 4. The necessary length of the feedback loop

Being sure the road we took is beneficial for our client we moved forward. One of the important Agile aspects is to shorten the feedback loop. Being aware of Client approach, instead of an earthquake which would take place after proposing classic Sprint Reviews, we decided to keep the small steps method that seemed to work. Our proposal was that each developer/s working on a certain feature would meet with BA’s responsible for that part and present the effects of their work. To make the process even more efficient we decided the feature doesn’t necessarily need to be complete. If there’s something worth showing after developing 70% of the task – go for it. This way the feedback loop became shorter and developers were able to verify if their work fulfils the business requirement and goes in the right directions. 

Chapter 5. No more pointing fingers

Every team has problems, period. And if the number of teams is growing so does the number of problems ? You can escalate those situations, prepare reports showing whose fault it was but does it help to build a friendly work environment? Does it motivate employees to be proactive and willing to deal with any upcoming obstacles? The answer is simple – no. Instead of pointing fingers we suggested running retrospectives, attended by each team engaged into the project – after some time even the BA’s. To assess retrospective as successful it’s outcome should include a plan covering how to improve the processes of software development (the plan should be then applied, of course). And we can talk about successful retrospectives now, the first ones were difficult and confusing. This kind of evaluation can’t be found in classic project management textbooks so the attendees weren’t fully aware of what to expect, how it’s supposed to look and what should be the result. Although we prepared a theoretical introduction, few first retrospectives consisted of monologues from opposite sides on what is wrong from their perspective instead of analysing what should be improved during following stages of the project and how to do it. Luckily as time passed everyone started to see the benefits of this meeting and the positive influence on their work conditions so they begin to actively participate in it. As for today, no one can imagine not revisiting the “Ways of Working” regularly. 

Chapter 6. Sharing is caring

In Software Mind we believe that continuous learning is a part of our job and every experience might teach us something new. Working on a huge app makes it necessary to share knowledge between team members – needless to say, a single person can’t learn about each aspect of such an app in a week. In addition to our regular company’s educational initiatives, we decided to organize internal monthly meetups to speed it up. The agenda was prepared by our team members – they presented the parts of the system they already recognized to the rest of the team. We told our client about those meetings and he decided to implement them inhouse as well on weekly basis. If we assume that all the devs work on the same monolith app in different projects, this kind of knowledge sharing makes sense. Those meetings evolved and now include technical presentations that weren’t t necessarily related to the project. We also had a chance to run some of these workshops and share our technical expertise. Undoubtedly those meetings improved both – business and technical knowledge sharing inside the client’s company. And you can’t forget about the social aspect – sitting in one room with your co-workers from different teams is a great opportunity to meet people and integrate with them as some discussions on presented topics can even evolve to more casual conversations. 

Chapter 7. Pulling down the wall

Visiting each other is a great way of not only maintaining but also improving interpersonal relations. Working with someone whom you had a pint with is much easier than having in mind his avatar from Skype for Business only. That’s why we put great effort to enable each team (consisting of both – our and client’s developers) to have a chance to meet in person at least once a year. 
During pre-release phase, in one of the projects that we participated in, more and more people from different departments (remember how divided the client organization was?) were engaged in preparing release version. Client’s PM decided to run catch-up meetings including BA’s, Testers and Developers once a week. Apart from the knowledge sharing and staying on track with the work progress across the whole project team it allowed developers and testers to finally talk in person, which till that day happened only during statutory meeting. That improved the performance once again– the problems were solved in real-time, and Jira (with all the classic unclear conversations in ticket comment section ?) stopped being the main channel of communication between them. Finally, it led to a decrease in false-positive test results and returns from the test team. 

Chapter 8. Let business and development go hand in hand

As we already said, developers that don’t know the business environment and don’t have comprehensive understating of the requirements are highly limited when it comes to adding business value. You can’t expect that few pages covered with task description would provide all the information – written text leaves space for interpretation that without proper guidance might get you off track. It also can’t be required that the implementation is finished in the estimated time if the estimation is done by someone who just prepares development tasks and does not develop them. To allow sharing knowledge of the business domain and improve predictability of dev team performance (i.e. accuracy of estimates), we convinced our client to involve whole development team in the planning process and let them divide bigger features/functionalities to smaller tasks to predict how long would it take to develop these parts. As in traditional approach to software development process the feedback loop is extended and managing risks is difficult so having big (for one or two weeks) development tasks makes it harder to control the progress, react to all issues in real-time or manage risk. Additionally, if you want developers to feel the ownership and responsibility for their work – let them describe and estimate it. Allowing your team to fully understand the environment of the project, decompose the work to smaller tasks and assess the time necessary to finish it would make it more predictable and manageable.  

Chapter 9. To Scrum or not to Scrum

As we’re reaching the finish line, there’s only one thing left. Although implementing some Scrum-inspired practises in this case allowed to boost the effectiveness, it’s not a magical solution that will work in any conditions. One of projects we did with this Client was mostly about maintenance and bug fixing, and we tried to use Scrum there. You may easily forecast the result – it didn’t end well. But even this small failure, thanks to a precise retrospective, allowed us to learn a lesson and following project with a similar scope of work had been managed with Kanban approach. Starting with theoretical training and practical workshops as a part of knowledge sharing between both organizations, Client’s Team Lead prepared a detailed description of the workflow and board usage. Having one stream of demands allow us to manage the priorities in real-time and see the progress.  

Chapter 10. The end?

What I wrote might seem like another piece glorifying Agile but arguably these practices had the best fit in this case. The main point is that outsourcing is not only about expanding your employees base. Letting into your organization someone experienced who don’t know your work procedures and processes might be a breeze of fresh air for your company. New partner might see the bottlenecks that are invisible for you because you’ve been working in such ways for so long, and it seems like there are no other alternatives. But the knowledge and experience of outsourcing partner is not enough in this case. You need to be open minded and ready for the changes and your partner must not be afraid of saying “You’re doing it wrong, we can show you what and how should be done to improve your work and verify if our suggestions fit your realities while working hand in hand..”. If those conditions are fulfilled, the benefits of teaming up with external company would go far beyond augmenting your staff.  

If you wonder how the journey with our client ended – it did not. We are still moving forward, working side by side, unleashing the complete potential of the development teams. But we’re waiting for another challenge – if you want to invite us to be your guide and support you on your own road just fill the contact form below and transform the end of this story to a begging of another.