The shorter our sprints are, the faster we get the crucial feedback that is incorporated into our next step—this is how we make our development low-risk or even risk-free. Explaining the value of short sprints can be an issue, though, because not all of the examples used to explain Scrum practices in application development translate well to the mainframe.

Let’s assume we are building a new application. Perhaps a sales-related app. During sprint review, the team has demoed a working “Home” screen which allows a sales officer to see their pipeline. The screen shows all of the money the sales officer has already made this week (closed sales) as well as all of the money that they could potentially make this week (pending sales) combined in the same pipeline. Although this feature was designed based on previously agreed upon requirements, the feedback now is that there is not much value in seeing closed sales and the officer would like to focus only on what is pending so that they can plan their work accordingly. Modifications will now have to be made during the next sprint.

This example not only explains the value of soliciting feedback early and often, but more importantly, shows how this feedback can directly impact or direct the next step. And while the plans for the very next sprint have changed, it’s awesome that this feedback was received so early in the overall process, eliminating the need to add business logic on screens that will no longer be needed. This saves time and money, for sure! Also, this example shows why it is a bad idea to spend months designing the entire application when things could change drastically after the very first review.

For mainframe software development, however, we might have to rethink these examples. On the mainframe, there is a greater chance that the team is working with an inherited product. And while feedback is still solicited early & often (sprintly!), it might not have as much of a direct impact on the immediate next step, for a variety of reasons:

1. While that particular story might need to go back to design/refinement, there are probably many other lines of work/features that can still proceed according to earlier plans. This feedback will not change those plans

2. Unlike the sales application in our example, changing something in mainframe code could necessitate a longer than usual revisit of the overall design. While the team is likely agile and willing to change course, the changes will not come as quickly and might even need to be prioritized behind some already existing work.

3. Mainframe teams could observe that the product owner has potentially already created future sprints fully populated with stories/cards for modifications of code that already exists and is not impacted by this feedback.

And so, when combining all of the above scenarios with the usual issues of low team capacity, high workload, competing priorities, and more, mainframe developers could feel like there is not much value in the outcome of a sprint review, thinking that the meeting is useless and wondering why it is held every other week instead of once every 6 weeks. This attitude isn’t because of the Scrum practice itself, however, but because of day-to-day issues such as corporate processes and practices which do not align with Scrum principles. The feelings are valid and there is no harm in experimenting with different sprint lengths to see which proves to be most productive for a team and its stakeholders.

It is important to remember that the reason we are modifying existing code is because there is an appetite for this change. We have someone paying to make this change happen. That someone is our customer, and the Agile mindset is simply about having a closer relationship with our customers, seeking their feedback early and often, and incorporating that into our plans as frequently as possible.

We could be struggling with some anti- or non-agile mindsets in our workplace today, but as long as we stay true to our promise of transparency and continuous progress to all stakeholders, we can find value in shorter sprints and frequent reviews.

“A developer must be engaged in the customer experience.” I heard that statement in a company town hall meeting once and I could not help but get stuck on the three main words: developer, engaged, customer!

Over lunch that day, I created a funny visual in my head about a developer actually being engaged to marry a customer. And I thought, “Wow it must be an old-timey arranged-marriage type scenario!” My Indian grandparents often told us stories about a time when it was entirely possible to be engaged to someone and yet have no contact with them!

And I thought, “How true…. This is perhaps the culture some teams have, expecting the developer to be engaged with the customer, but with hardly any forums to establish direct contact! Sometimes not even during sprint review!”

Then I started to wonder, how often is the developer having a true interaction with the customer? Are they able to ask questions about the intended use of the feature that is currently being developed, able to seek feedback on a previously delivered feature, able to gauge whether what is being developed is truly what the customer needs to satisfy their needs?

While it began as nothing more than just an amusing thought, I have often wondered about the value of establishing direct contact between the developer and the customer. Is such contact beneficial or detrimental?

Just like my old-timey couple, why is there always a layer of product management chaperoning the happy couple? How about some alone time?

Direct contact can provide many benefits:

1. Nothing will be lost in translation. In fact, nothing is “translated” at all! The developer gets to hear exactly what the customer says.
2. A chance to help the customer understand the product better. There is always a chance that a particular customer representative is not fully aware of the complete set of features/capabilities of the product. Perhaps the customer has been through some organizational change and the new set of people in charge are not as familiar with the product as the initial group. Direct contact with the developer offers an opportunity to strengthen the customer’s awareness of the product and its features.
3. A chance to understand the customer psyche. Are they asking for a particular feature simply because they were used to it being in their former product of choice? Teams could potentially help educate them on other features that deliver similar results.
4. Realtime customer feedback! The main reason we do things the way we do! That precious feedback! Fresh and firsthand! And it could help develop a relationship which could help future communications.

Of course, there are some potential risks to consider:

1. Is the Team ‘polished’ enough for this interaction? When meeting a customer, we are essentially representing our entire organization. Will the team be capable of maintaining allegiance to the company’s vision?
2. Does the team understand the language of presentations? Some presentations are made focused on what the future could bring, some are focused on what is currently available, some could be, as I like to say, “lightly kissed by Sales & Marketing!” An engineer might say, “this will kill you,” while the sales officer may say, “this will cause some discomfort.”
3. Does the team understand that these meetings might not be the best place to make promises about when/which features can be delivered? Also, that they’re not the best place to share frustrations they themselves might be having about the company’s current managerial/development styles?
4. Is the team on board with presenting a “united” front to the customer? Or is someone likely to roll their eyes when another person promises a picture slightly rosier than they would themselves prefer?

Each of these potential risks underscores the need for preparation before meeting with customers. Establishing a unified message and consistent tone will help portray your team and your company in the best light and avoid confusing the customer with mixed signals.

Product Management could act as a much-needed buffer between the hardworking engineering team and the always-demanding customer. They can save the team’s time by distilling the essence of long meetings and presenting the team with a concise set of requirements that can go straight to refinement. The product manager can set the overall vision and the product owner can help fulfill that vision by helping the team remain focused on what is truly the core deliverable.

In conclusion, both team and customer benefit by direct interaction, even when facilitated by product management. This interaction makes for happy engagement and, in the long term, a healthy relationship.

For a mainframe organization that is beginning their “Agile transformation,” it is quite expected that JIRA will be the software of choice for managing software development projects.

Agile and JIRA go hand-in-hand, and rightly so, but it is important to take a step back and acknowledge that these are two very different topics.  It is entirely possible for a team to be Agile without any expertise in JIRA. In fact, it is recommended that a team learn Agile concepts first, before diving into the tools.

Agile is the ‘mindset’, Scrum is the ‘practice’ that helps us be Agile, and JIRA is a software tool that is tailored to work best with existing Scrum/Kanban practices.

It is very likely that while a team will fully embrace Agile or Scrum values, it will struggle with JIRA. This struggle sometimes leads to an overall frustration with day-to-day tasks and unfortunately could result in a shunning of the Scrum practice altogether.

While slowly building familiarity with Jira, a Scrum team should always prioritize upholding the values of Scrum over all else. The “clerical” aspects of JIRA can be handled by the Scrum Master (SM) or the Product Owner (PO), leaving the team free to focus on customer deliverables.

While not comprehensive, a quick understanding of the five Scrum Values (Commitment, Courage, Focus, Openness, and Respect) and how they are reflected in JIRA could be as follows:

Scrum Value #1: Commitment

Upholding the team-approved Definition of Done (DoD) and creating an increment (sprint commitment/ sprint deliverable) that meets that DOD consistently.

JIRA Activity: Moving cards to “Done”

If the team is still new to the concept of breaking down work into sprint-able chunks, it is likely that JIRA cards will not meet the DOD at the end of a sprint. Teams should not feel pressured into closing cards merely to influence metrics such as “velocity.” True value delivered to users will trump fake velocity any day! “Carry over” the cards into the next sprint, and review with the team how any further detail/breakdown can be added to the card. Breaking down the solution/plan is sometimes not possible upfront because the path is not clear either due to increased complexity or because the “area” of code changes is new to the team’s existing skill set. In the retrospective you should discuss ways to produce better stories that can be delivered in a sprint.

Scrum Value #2: Courage

Understanding that fast paced changes are our reality and sometimes the only way to fulfill the requirements is via taking informed risks and delivering Minimum Viable Products (MVPs).

JIRA Activity: Creating epics to organize the iterations as the feature matures. Each epic has multiple stories with potential “links” to each other, denoting dependencies and blockers.

Teams should not feel pressured to deliver a large number of changes in an unreasonable duration simply because they exist as one epic, or because of how the stories were crafted. Instead teams should feel comfortable expecting a mature feature (beyond MVP) will take several iterations, with corresponding epics, to complete (MVP, Phase 1-Enhancements and so forth).

The SM or PO can work together to maintain the intricate web of story relationships or dependencies that sometimes span multiple teams. To a new user of JIRA, the abundance of customizable fields, labels…etc. can be quite daunting. JQL (Jira Query Language) can help but only if the team has had enough time to get familiarized with these tools.

Scrum Value #3: Focus

Various scrum ceremonies, especially the daily stand-up to collaborate on progress and share new information, helping the team to adapt at frequent intervals.

JIRA Activity: Reviewing the daily “burndown” chart, maintaining the “swim lanes” during a sprint, and the backlog throughout the project.

Focus on getting to the MVP and not throwing something together just to finish it by the end of the sprint. Focus on the goal, not the journey. The SM or PO should be able to assist with any “clerical” help in JIRA (changing card status, switching swim lanes, adding comments etc.) until the team members are familiar with the software. As long as a teammate shares what changes need to be made, anyone can help capture and reflect that information in JIRA.

Scrum Value #4: Openness

Openness to sharing progress with our stakeholders, as well as openness to feedback and collaboration.

JIRA Activity: Modifying stories, creating additional tasks/ sub-tasks as needed. Adjusting the backlog priorities accordingly.

Do not limit the sprint review to a formal presentation of fully working software, the team should share interim progress and adjust based on the feedback received. JIRA cards are not set in stone, we can make any changes to suit the team’s needs while maintaining honesty and transparency.

Scrum Value #5: Respect

The entire scrum team attends sprint refinement, planning, review, retrospective and other collaborative meetings. This promotes respect for each role, accountabilities, and diverse perspectives.

JIRA Activity: Update Jira based on the team’s current understanding of the ask. Ensure any team or team members impacted by a change are notified.

JIRA cards often need to be updated based on the results of meetings. It helps to note individuals that have provided input, especially in cross-team meetings. As long as the team is participating in the scrum events, the “clerical” side of things in JIRA can be handled by the SM or the PO.

Timely delivery of commitments is what matters in the end. While JIRA helps the process with transparency and clarity, teams should remain focused on the deliverable while slowly building familiarity and proficiency with this additional software.

The last few months, working from home, I found myself struggling with unexplained hunger pangs and a constant need to snack! When I waited too long to eat, I over-consumed my food, had trouble placing an accurate order, and found it hard to complete a shopping trip because the hunger clouded my judgment!

This is kind of what happens when stakeholders wait too long to see any progress or receive any updates from your team. They are unable to adjust their expectations and hope to see unreasonable amounts of work being delivered.

Successful Scrum practices lead to shorter sprint cycles, which then lead to faster reviews of completed work. There is no hunger for an update or a progress report and the chances of unreasonable demands or tantrums are less likely. This keeps the stakeholders engaged, happy, and satiated.

However, as someone who has struggled with weight & diet issues for decades, I am very aware of the dual perception of fullness! “Satiation” is the feeling of fullness at the end of a meal. “Satiety,” on the other hand, is a measure of how long it takes before one is hungry again. It isn’t enough that the stakeholders feel satiated right now, it is also about maintaining a period of satiety!

In my first few sprints of mainframe software development, I found myself struggling every 10th day!

Things were tricky in Mainframe Land. What was “sprintable” was not necessarily valuable on its own! The team shied away from bringing an incomplete feature for review, and the story most likely got “carried over.” It could easily be 4 or even 6 weeks before any revelation about progress was made, especially to the wider audience that never has access to the JIRA burndown chart or development comments.

I felt conflicted! Do I insist on reviewing the sub-tasks we completed or wait until something more meaningful can be demoed?

I had to take a step back and reflect upon the core Scrum values. A team’s success with Scrum depends on five values: commitment, courage, focus, openness, and respect.

That helped me gain some perspective! I felt that a team should review any and all progress during the sprint review. The focus should be on being transparent and open and not on hosting a grand presentation. Any progress is proof of our focus on our goals and respect for our stakeholder interests.

I sincerely believe that when stakeholders work with a team which is being transparent and open about their progress in a timely and consistent manner, then even if an occasional hiccup happens with missed deadlines or otherwise they will be more likely to forgive the delay and remain focused on the overall progress.

While occasional grand updates might feel amazing for a short period of time, it is only via consistent progress updates that we can truly guarantee longer periods of satiety for all stakeholders.

Overview: Scrum Masters and Developers may complain about Product Owners but viewing them as partners rather than adversaries and collaborating with them can help ensure success.

“My product owner is awful!”

Does that sound scandalous? A mean and unreasonable statement? Or is it a universal issue plaguing every single Development Team all over the world?

Participate in any Agile workshop, scrum team discussion, retrospective, or any lunch or elevator chat and I guarantee someone will mention how and where their Product Owner/Manager is lacking. It is frustrating and a common pain point for many teams.

Scrum has three main roles: Product Owner (PO), Scrum Master, and the Development Team. While some organizations might not use these exact job titles, the responsibilities of each role are very clear and vital to the success of the team as a whole. Having an “awful” one third of the team, therefore, is a serious matter!

An Evolving View of Product Owners

A long time ago, somewhere near the beginning of my career, as an Agile team member, I was good at my exact role and really didn’t care much about any process (or anything else to be frank). I got some cards assigned to me at the beginning of the sprint, I did them well & within the timeframe—all was good. I honestly never interacted with my PO and I still don’t even know or remember who they were. I had zero need for them, so I didn’t seek them out and had no need to analyze their role/participation in my sprint work.

Sometime later, I found myself in a progressive atmosphere where I willingly sought more responsibilities and took greater interest in my work. I needed help with a specific task and was asked to reach out to my PO because they were considered to be the SME for that topic! So, I reached out, got the help I needed and was amazed at the depth of knowledge my PO possessed and how I was able to harness that knowledge to be better at my own job. It was like discovering a new tool or technology I could use to become more efficient in fulfilling my responsibilities.

With time I found myself progressing on my journey to total Agility and my responsibilities changed drastically. I needed more help, had questions that needed a prediction of the future, greater insight into the product, and so on. I reached out to my PO and expected to get all the information on tap and on demand. I was surprised when they said they did not have the answers I needed! Imagine that—a PO who does not know it all! After I recovered from that shock, I insisted they accompany me as we reached out to someone else who gave us the knowledge which we sought.

It was strange because up until then a PO was like a drive-through window for me; I drove up, asked for information, got it, and left. It was quite a one-way exchange. I had never viewed a PO as a true team member, someone who could also be a “seeker” of information and not always the “source.” I guess in many ways I learned that sometimes even the best tools need driver upgrades and maintenance in order to stay current and efficient. The PO does not always know! But they can help you get the answers you need.

The Product Owner Is Your Partner

As my engagement with my product deepens and my needs change, I find myself even more involved with my PO. But this time around, I treat them like a partner, not just a resource. I feel I am, without holding any grudges, as much responsible in helping them achieve knowledge and insight as they are in giving my team vision and clarity to succeed in our joint quest for a quality product.

I text, email, call, send meeting invites, reminders, and Jira comments. If there is a mode of communication that is available and HR-approved, you can bet I use that to communicate with my PO. I insist we meet and plan agendas before involving the entire team in technical discussions. I maintain transparency & honesty by clearly sharing details pertaining to team capacity and resource availability. I also remind, confirm, request, and follow up as needed. My PO is a team member as well, and I don’t think I can achieve success without ensuring each team member has everything they need in order to be successful in their role. Success is ensured by working together, not blaming each other.

I do continue to push back on unreasonable demands, scope creep, and conflicting priorities, and my PO still schedules a weekly meeting where we review missed or delayed sprint commitments, team issues etc. But, whatever we do, we do it together as a team and with an understanding that we need to help each other in fulfilling our responsibilities so that the Development Team has a distraction-free and productive sprint. And while things are not always ideal, no one is being truly “awful.”

This post originally appeared on LinkedIn.

Overview: A Product Owner and Scrum Master discuss the value of Agile Retrospective meetings and provide helpful tips for making them more effective.

Many will say they don’t like Agile Retrospective meetings. They are probably the least favorite of the Agile ceremonies. You are there with your peers and discussing things that went wrong in the last Sprint. We never like to face failures, especially our own. Yet, this could be why the Retrospective meeting is the most important meeting in Agile Scrum.

We should feel a responsibility to others on the team. We should never want to let them down, yet we will. That’s just the way it is, none of us are perfect. It isn’t personal, in fact, we can’t let it be personal. If we do, we will try to hide things and not really discuss the issues that are holding us back. It’s about the functioning of the team and more so about procedure.

The meeting is not about failures—it’s about improving the team. Equally important as examining problems is to look at successes. Bring up something that happened in the last Sprint that shows improvement, that an earlier issue has been rectified. Show the progress you are making. This helps shift the dynamic in the right way.

Scrum Master Perspective

Sometimes in sports there is that team that had a bad half. Things did not come together, and they are behind and heading for a loss. But after half time they come out and look like a different team—and they go on to win. What happened? It was their Retrospective. They took an honest appraisal of what went wrong in the first half and came up with better ways to work together. They may have prepared to face this team with a set of assumptions, but they learned what worked and what didn’t. They adjusted their strategy with what they learned in the first half and use that in the next half to improve and win.

As a Scrum Master, this is how I see the place of a Retrospective in Sprints. It’s an important time to pause between Sprints, review what is working, what isn’t and adjust for better performance in the next Sprint. Great teams, winning teams, learn from experience and know that plans need to change in the real world. This only happens with the willingness to be honest and open and most importantly a willingness to adapt and change to improve.

Product Owner Perspective

As a Product Owner my goal is to be able to deliver quality solutions to users, quickly. Friction within the process slows that down. I want to make sure the team works as efficiently as possible. That means my Stories must be clear, sized correctly and fit in the proper order in the Sprints. The Retrospective gives me insights into how my Stories have been used, and where I can make corrections to improve in the next Sprints.

So, how do you get maximum value out of your Retrospectives? Follow these steps:

1. Focus on the goal of being a better functioning team with fewer issues.
2. Focus on procedure, not personalities.
3. Focus on root causes, not symptoms.
4. Look for and suggest solutions; don’t dwell on the issue itself longer than necessary, but keep at it until you come up with possible solutions.
5. Keep a record–put down what changes you will make to improve, and then in the next meeting, go back to that and see how it’s going.
6. Explain why something impacted the team because the issue alone may not stand out; be detailed in describing how the team’s work was affected.
7. Encourage the team  to make a quick note of any items they want to discuss throughout the Sprint–and require each team member to contribute.
8. The Scrum Master should ideally facilitate the conversation, respecting everyone’s viewpoint while remaining neutral. And never turn it into a lecture!
9. Maintain a simple doc of what was discussed and make it accessible to the entire team.
10.  Lastly, but probably most importantly, not everything is a problem. Share what went well! Don’t overlook successes especially for newly implemented solutions.

The Retrospective meeting is probably the most critical meeting if we intend to improve. Without allocating the time to specifically talk about improvements, how could progress happen?

Originally published in Enterprise Executive.