photo source

Nowadays the processes used to create software have been considerably evolved from manual and human interaction to test, build and deploy an application to a fully automated process relying on new practices and tools that help teams to deliver an update to production in few minutes or even seconds. If your organization or team still using the old methods and have the willingness to take a step toward these useful and helpful DevOps practices, there are some notions to consider while taking the way.

A new project is in the pipeline and we are ready to kick off this new challenge, Our team is ready and full of energy and enthusiasm. Scoping sessions are scheduled this week. The first session started with a short description of the project, making the focus on the business and strategic impact and how will help the company to accelerate its digital transformation in the perspective of developing new digital products and cloud-based offerings. It’s time to finish the workshop with one conclusion all team members share the same frustration regarding where we want to go. During the week these sessions succeeded one after the other and still having a blur vision, confusing features, and also an organization that we believe is not convenient to drive the boat to the shore.

Exploring the real value​

As a product owner, I have to gather the maximum information about the customer business, their strategic goals, and where they want to land once the project takes off. I remember this quote from Dassault Systemes Dassault Systemes !

If we ask the right questions, we can change the world

Asking pertinent questions is crucial to understand the business and the desired value we expect to provide. For a successful scoping workshop, this job should be prepared before and these reflections and analysis at least started in order to keep the team members away from any frustration or defeatism.

Why The role of the Product Owner is very important at this stage?​

The product owner is the guard of the vision and customer value, keeping the train on track requires a lot of effort regarding the business understanding and mapping this knowledge to user stories that designers, developers are easily able to take in charge and implement.

Based on our experience, our product owner iterated regularly over the backlog to refine the items and get rid of the irrelevant ones, each time he was approached to revise a business rule.

Specifications and requirements​

What kind of format our documents should follow to write down the specifications and requirements and how many details we should draft? this question is indispensable to answer before starting, the more we give attention to what to write the more implementation will be easily taking into consideration all constraints and customer-specific requirements such as solution’s time responding, availability, number of future users. These notes help considerably when it comes to architecture design and technical stack decisions.

Deliverable frequency and type​

While in agile project continuous delivery is at the heart of it and shouldn’t be part of discussions but the frequency of delivery and type of deliverable could be, The reason why a team should agree and state early these points.

The adoption of continuous improvement is totally appreciated while the business is evolving but we have to pay attention before investing in this area causes often lead to delivery postponed even contract issues.

Cost​

Sometimes and due to technical choices such as licences, do not forget to include them in your budget estimation and let stakeholders know about them, When it comes to money transparency is the key to spread trust and avoid undesirable surprises. the rules are:

• calculate an accurate budget and make sure all elements are included.
• define a process that helps to keep the budget flexible regarding features without over budgeting.

Communication​

Whatever the project scope or size, communication is a key to a successful customer value and team satisfaction, Defining communication channels, rules, and tools between stakeholders and project team can considerably impact project progression and target achieving. Communication also implies some values such as transparency about the team’s capabilities what we can and we cannot do, these kinds of statements should be communicated as soon as possibl to help the customer make the best decision.

In my point of view, I prefer to avoid the usage of multiple communication tools and formats with our stakeholders (telephone, email, video-conference, meetings…), this can help keep our exchanges simple, effective.

Regarding internal communication between team members, Personally, I have a lot of appreciation for meetings or face-to-face discussion believing that is the quick and right way to argue a decision or explain a point of view to convince my team-mates of any technical choice. Otherwise using a project management tool to track and monitor is still very useful in order to keep everyone updated and everything documented.

Flexibility and adaptation​

Agile practices come to solves today’s project issues and pains, but at any stage, we should be wedged, In my opinion, we have to cope with challenges, involve the team in every decision, think differently and act like one. Scoping is the stage where we invite all involved people to the same boat with one goal is to reach the destination.

During the latest months, I’ve been asked to move from a small agile team to a large one, why? what changes should I cope with? what obstacles to tackle and what kind of achievements we accomplished? here are the experience story and the learned lessons

Small Agile team​

I've been part of a small agile team of 4 developers, tech-lead, UX designer, Scrum master and a Product owner. Working with scrum method, I do believe that this team size was just perfect as the communication is too smoothly and decision making is quick and effective. We developers were using the git flow branching strategy. A new branch is created for each user story, commit added, pull request created and reviewed then merged into the master. Product owner manage easily his backlog. The scrum master scheduled perfectly our scrum sessions and these one were gainful in term of business understanding and story telling. Thanks to the great work of our UX/UI design integrating the UI and implementing the user experience is definitely optimal thanks to sketch software.

The team size was a key element to a successful journey, providing a great added value at the end of each sprint while delivering high-quality software with security standards-compliant.

Communication and collaboration

When is come to working together and collaborating with a team, communication is a key factor toward success. While this is easy for a small team as we are often setting around the same table or in the same open space we communicate orally and directly trying always to avoid emails and chat as much as we can, but for sure without omitting to give each one its private space and time to concentrate on his tasks with no disturbs. In the other hand and once the team getting larger we first obstacles we start to face is how to communicate and exchange, even harder for taking a decision. Another point is managing meetings which means to manege finding rooms especially as we are working in a co-working building then as we have to take into consideration each one is calendar. Now we are in the meeting room with more than 12 team-mates it took longer than expected, deviation and rarely we end up with a defined actions list assigned people.

I believe either we are a small or a large team there are the right tools and ways to communicate, We need just to avoid applying the ones that work fine for a small team in the context of a large team and vice versa.

Support and expertise

One of the greatest points when you are part of a small team, is that you know each member is scope of expertise which is very useful and effective when it comes to coordinate whether to change a piece of code, to integrate a new technology or document a feature. Unfortunately this advantage disappears along the way a team begins to extend and we start to be distributed which affects our knowledge about expertise mapping in the project and for sure consume more time to find the right source to support you.

I refer to Conway's law stating about organization structure footprint on their production:

Organizations which design systems ... are constrained to produce designs which are copies of the comminication structures of these organizations. "Melvin Conway"

In our organization we understood this quickly and thanks to our agile coach we reorganize our teams and introduced some practices to continue delivering added value feature continuously.

Single Point of Knowledge​

As our team begin to grow and having many members than needed in an agile model, I observed in the lake of coordination, close collaboration, and effective communication, new single points of knowledge taking place in our organization as some people with or without attention monopolize and hold in their corner some specific knowledge or expertise which impacts the pace of productivity, innovation, and rotation. Contrarily to the case of a small team where the knowledge and responsibilities are well shared and all members have almost the same level of knowledge about the project which avoids the 'indispensable member' obstacle and lead to transparent and rapid rotation and delivery.

Team representative and interface​

When I was part of a small team there was a member who keeps the team informed, knows the organization’s culture, and promotes best practices that make our entity inspiring. Often this role appears naturally cause the person playing it holds some qualities that help him representing the team, interfacing with management contrarily in the context of the old school team, a project manager take this responsibility. But can we have many representatives (Leaders) in the team? In my point of view, YES as each member has a different style therefore we can boost the team’s productivity and creativity. Shared leadership led also to reduce responsibilities stress, thrive solidarity. For the company we observed many advantages once we made the move to this model:

• Share the the bigger picture with everyone.
• give the company more options.
• increase in decision making transparency.

Finally, the question is can this model succeed with a large team? From my experience, this can be a huge challenge for the management but also for immature teams who can considerably slow down the decision making.

I’ve been part of different teams small and large and I believe that adopting the right management style and establishing a transparent and honest relationship whether between team members or between teams and the management should always gain the upper hand.

Being the representative of your team is talking about your shared values and practices, defending your team's decisions and choices. But in any case shouldn't be a position that we take over.

It's sound strange at first, difficult to manage, and certainly understanding the reasons behind and how can we take advantage of this practice introduced a couple of years ago.

Mob programming is an approach introduced to the agile world in the purpose of helping the teams establish a common development mindset, sharing the same principles to design and code.

A few months ago my team and I started a new project aiming at providing a digital platform for developers to help them accelerate their time to market. The platform offers a multiple
services such as creating web application scaffold, source code repositories, build pipeline with all high-quality stages like security check, team management and deployment environment.

Obviously the project size is enormous and requires a high quality architecture design, distributed systems best practices and synchronous coding styles so during the scoping and framing phases we decided to adopt the mob programming approach to share and communicate architecture decisions, lean our performances with the goal to promote our autonomy when it comes to developing user stories independently or separately.

our mob programming sessions are scheduled for the whole workday for 4 weeks consecutive, we team up in the same room having only one keyboard and one big screen. Each developer takes control of the keyboard and code for 10 minutes. I believe that respecting the mob programming rules is a key to success in this experience which is full of learning for developers but also for the quality of the product as we build together the skeleton.

I would like to share with you all the rules we followed during our sessions:

• having a comfortable and spacious room with all the necessary tools like big screen and a mechanic keyboard ✌
• defining roles before each session, we've had the Driver who types in code and Navigator who discuss the idea and guide the Driver.
• respecting timing is a key, it's better to hand the keyboard over with a broken test than overtaking.
• we've been driven by basic user stories at the beginning in order to focus on technical architecture.
• we discuss, debate and argue our ideas when we think they are right, no one or idea should be discarded.
• Believing that there no strict model or perfect one to follow, a retrospective is held weekly to evaluate our mob programming enrollment.

Before experiencing the mob programming I was asking my self how can will be productive by letting 8 developers to work on the same thing for weeks, I confess how was am I surprised by what we were able to deliver, a full feature bringing a real added value to our customers. If you ask me for the secret the only answer I have is we were doing the work the most perfect way it could, avoiding broking the build, hard merges, and enduring exchanges by emails or pull requests to agree on a design, interoperability, components communication, and best practice adoption. In addition discussing ideas and approaches helped us a lot to select the best ones.

During these sessions, we build a wonderful team spirit, communication protocols, and a homogeneous mindset. without omitting the impact on our motivation and commitment. I was really happy with this journey and the results harvested at the end.

I highly recommend giving this approach a try even though for a short time, I consider practicing is the best way to understand, evaluate and conclude if it could bring the right expectations for your team.