startup Archives - TOWA Software

AgileDesign

Building valuable products: Remote agile teams

Numerous teams are constructing their work into a hierarchy of epic, feature, user story, and task. Using the Scaled Agile Framework (SAFe) has made this hierarchy popular, but many other teams are following that model using the same structure.

Epics provide big valuable products or big valuable changes to products. You construct them into shorter pieces of value so you can deliver solutions to your users sooner than waiting for a killer solution at the end.

Features are constructed into high-value stories, which, according to the definition, should provide value in production, and again it occurs faster than building a whole feature.

But there is a hidden pattern in the way teams are constructing work into an epic-feature-story hierarchy. Teams use agile tools to manage epics, features, stories, and tasks. But they too often use them to articulate a work breakdown structure (WBS) instead of a value breakdown structure (VBS).

WBS refers to the common, age-old project-management practice of breaking tasks into smaller chunks, allowing teams to estimate time and costs for completion. VBS, instead, focuses on product delivery and sub-products, not tasks and sub-tasks.

Please follow us to detail our findings in building valuable products.

Old thinking ways result in poor user stories

WBS has been used to plan development work for a long time, so it is deeply embedded in our brains. And when we were project-driven, this was a great practice.

But with the agile movement for project culture and toward product culture, this method no longer works. You need to think in terms of product delivery and product value.

Rewire your brain

Here are two ideas to help people reframe agile development as a value breakdown structure (VBS) instead of a work breakdown structure (WBS).

Method 1: Really understand what you are building, and why…

Here, ask yourself and the team to articulate, at a high level, what they are building. Note that you’re not listing the steps to build it (that’s WBS) but instead are describing what it is (VBS).

Collaborate to create a list of what you are building

Let’s imagine the team says you’re building four things:

A new report here
Modifying an existing report with X
A new detail view with a graph for Y
Bringing function Z, from older version to newer

The answer could be a list such as the one above, or it could be a one-sentence answer such as “an space ship.”

With the team decide whether it’s an epic, feature, or story

In a VBS, epics, features, and stories are the same thing: value delivery. It’s just that each has different rules and syntax due to each having a different level of risk.

Epics are highest risk, features are less risky, and stories the least risky. So epics require more precision to secure you have thought through the risks and have the best chance of success.

Additionally, every epic, feature, and story creates or modifies a product.

So your team need to decide based on the following guidelines:

Epics are value that will be delivered to production or be production ready in more than two months.
Features can be delivered in a sprint.
Stories can be delivered in less time than a sprint.

Group similar types with their product value

Simply ask yourself “How long would it take to deliver this value to production?”

Then simply assign the correct type to the piece of value! Just like that, you now have epics, features, and stories in your backlog.

Look at the blocks

Some believe that all valuable work must be visible from the epic level, because the epic level (in SAFe) is also the portfolio level. And the portfolio level is where you make financial decisions about work.

But this is not actually correct. All three types—stories, features, and epics—are about value. The goal is to decentralize value decision making and push it downwards, where the risks are low. Stories and features are small, and the product owners and product managers are trusted and empowered to prioritize those types of work.

People can also feel as if these stories and features are “orphaned” if they don’t trace to a higher-level container. But, in fact, they do trace to a higher-level container: the product value they are associated with.

Remember that all three types either modify or create products. Just ensure that every epic, feature, and story traces to a product.

Team work and break down all features and epics

You might have a pile of epics, features, and stories that need to be built. If all of the work is small, you may have only stories. If all the work is big, you may have a list of epics. Or you may have any combination, strictly based on the size of the work. There is no hierarchy here, just a pile of different size work to do.

Big items such as epics and features need to be decomposed so they can be prioritized with the other lower-level work. You can do this by asking, “What is a smaller piece of value we could do more quickly than this whole thing?” And as you de-construct them, you don’t do it into tasks but into value items.

And once you decompose features and epics into smaller value chunks, you once again ask, “How long would this take to put into production, or to make production-ready?” And again you give them the appropriate epic/feature/story type. Repeat this until every epic and feature has been disintegrated to the story level.

Stories do not disintegrated into smaller value; you can disintegrated those into tasks. Note that tasks are the only element in the hierarchy that are like those found in a WBS. They are tasks, not value chunks.

In other words, the epics, features, and stories are all value chunks. The tasks are tasks, and they are optional.

Eventually every epic is separated into features. Every feature is separated into stories. And all of them are value chunks, not tasks. And thus you have a VBS instead of a WBS.

Now the story backlog

So at the story level, you will have a bunch of stories, some of which are standalone, some that trace to features, and some that trace to features that in turn trace to epics. But all stories can now be prioritized against one another.

And if they do trace upward, that will be considered during sprint planning. You want to finish a whole feature if possible, so a high-priority feature would increase the priority of the stories as well.

Bottom line is that epic versus feature versus story is simply a first-level guess at the size of the effort to deliver value.

Method 2: Adjusting an existing backlog

For teams with an existing backlog that’s more WBS than VBS, this can be quite easy to repair.

Grab the current list of epics, features, and stories and leave it open in the background.
Notice there is a mix of some items that are WBS tasks, and some that are products or value of the VBS type. It is common to have a mix of both styles.
Extract the products or value, and create a fresh backlog with only value delivery items.

To accomplish step 3, take a task-style backlog item and ask, “What product or sub-product does this create or improve?” The answer will be the real VBS item that should be in your backlog instead. If you can’t figure out the answer, then why would you do that task?

The third step can be fun and satisfying for your teams. Their new epics, features, and stories are true value work items. Each work item needs refinement, development, test, and deployment. Each is valuable to users.

Imagine that your storyboard columns were “refine, develop, test, deploy, done.” Notice that a WBS task-style story doesn’t work on a board such as this: “test component Z” would make sense only in the test column, rather than flowing through them all.

Value-type VBS stories, on the other hand, flow through all of this. “New finance report X,” for example: Refine your understanding of it. Develop it. Test it. Deploy it. Done! Value to the user is achieved. But when “Test component Z” moves to done, direct user value has not been achieved.

Real value on delivery

Once you move away from a WBS to a real VBS, you can easily report on value delivery. Which epics closed? That is value delivery. Which features closed? Value delivery. Stories? Value delivery.

So your value delivery reports can simply be reporting on work items closed. And it only works if the work items are real value delivery items, not work breakdown tasks. If every item is a value delivery item, these reports are satisfying and informative.

If someone wants a report of value delivery for their dollars, they can now show their recently done backlog and answer that question by just using their work management tools instead of creating PowerPoint presentation. It’s a beautiful and better way!

Change your focus to value

Many people see their agile work management tools as a hierarchy of epic, feature, and story. And the WBS mindset win, they fit the WBS into the containers of epic, feature, and story.

Instead, focus on products, sub-products, and value delivery. Refine and adjust existing backlogs by separating tasks from value. Think of the epic-feature-story hierarchy as nothing more than a first estimate on time. Epics take more than a three months. Features require 1 sprint. Stories are done within a sprint. And all are value delivery items.

October 30, 2020 0 Comments by MSc. Adrian Lopez

AgileInnovation

Tips for distributed agile teams

“Agile development isn’t any longer considered to work for collocated teams only. Also, teams, projects, and organizations that are distributed are asked to focus on delivering value. Yet, with Agile’s emphasis on -among other things- face-to-face communication, this seems like a contradiction. So the question arises, how to adhere to the Agile principles when applying them in a distributed environment.”

ere you will learn about the key success factors for distributed teams. Readers will understand that also distributed teams can benefit from a value system and from principles that are beneficial for small teams. In fact, the two trends – distribution in terms of globalization and Agility – can even complement each other.

Many organizations find themselves faced with the challenge of making distributed agile work. Mergers and market consolidation, geographic expansion, and offshoring have made multi-site development the norm rather than the exception. Companies with sites in competitive labor markets can find distributed team members as an alternative when they can’t recruit locally.

Agile can work in a distributed environment, but it requires work; more effort than you’d expect if you’ve never done it before. Here are eight hacks that can make it easier.

Why distributing the team might make sense

You might not be able to get all the people with the right skills in the same location, but the world is filled with talented, motivated people, and being open to working in a distributed way opens up your options.

Besides, today’s technical professionals have more choices about where they live and work. They may like where they live and not want to move. In short, the people you need may not all live in the same location.

Local culture matters. If you’re developing a product that needs to appeal to customers in different countries around the world, you’ll need people who know the local culture and language. There are also political or security reasons for distributing development—from tax advantages for doing work in certain countries, to restrictions on data crossing country borders, to the need for people on the team with particular security clearances.

As you can see, there are a lot of reasons a business would choose to have a distributed team, and whether we like it or not, the number of remote workers is only going to grow. With that in mind, here are eight simple distributed-agile hacks that can set the right tone for a successful remote team.

1. Recruit motivated individuals

It is possible to make distributed development work; open-source projects do it all the time. They have a couple of advantages that other initiatives often lack.

Their team members are often exceptionally self-motivated, at least if they are committers.
They often don’t have to deal with stakeholders or requirements, because they are often building a project for themselves, so they know the problem domain very well.

In more normal situations, having highly motivated team members is really important, and the remote team members are going to have to be exceptionally self-motivated. that’s because they are going to have to work harder to communicate, stay engaged, and stay focused and productive. They won’t have the informal network of co-located team members to fall back on.

The co-located team members are going to have to work harder, too. They are going to have to make a special effort to engage their remote team members.

2. Create self-organizing teams

The worst thing to do when forming any team is to assign people to work on it; it kills motivation and destroys initiative. Since distributed work is even harder than co-located work—because it requires even greater motivation—the distributed team needs to be strong, with members who are committed to the mission, to the way of working, and to each other. That level of commitment doesn’t happen by accident.

Letting people choose to be part of the team—to work with one another—is an important first step. They must want to work in an agile way, and they must want to work with one another. Let people volunteer to join the effort, and then bring them together to establish their norms and working agreements.

3. Co-locate, at the start, to let teams form, storm, and norm

Forming a team usually takes at least a couple of sprints, sometimes longer. You will make your life, and theirs, much harder if you don’t invest in helping them develop into a high-performing team. It takes time and experience working together as a team to develop the trust, commitment, and mutual accountability that they need to perform well together and to be transparent about the state of the work.

Artificial team-building exercises do little to help teams go through the forming-storming-norming-performing process. Bringing teams together for a couple of sprints is really the best way to develop the working relationships that are essential to future performance.

4. If the effort is large, have co-located teams at each site

Let’s say that an organization has sites in multiple locations, as well as multiple teams, each with team members at every location. In this situation, you’re going to end up maximizing the amount of extra work for everyone.

Instead, you should try to form co-located teams at each location and let them figure out how to share the work among themselves, extending Scrum with a scaled agile approach such as SAFe or Nexus. In this approach, multiple teams are working on the same product.

With a scaled Scrum approach such as Nexus, you help multiple Scrum teams simplify cross-team collaboration by resolving and preventing cross-team conflicts and ensuring that they deliver an integrated product increment with every sprint.

Regardless of which framework you use, you should make sure each team has a Scrum Master. Masters will not only help their own team perform better, but they will also help everyone else who needs to collaborate with that team.

5. Co-locate development teams with their product owner

This sounds obvious, but I’ve encountered plenty of strange situations where this is not the case. I’ve seen companies with the development team in one location and the product owner in another. This really hurts collaboration and communication, so don’t do it. Find a different team or a different product owner, move the product owner to the same time zone, or empower a local delegate for the remote product owner if the product owner is co-located with another team.

6. Invest in collaboration, but invest first in teams

Collaboration technology really helps teams be more effective—distributed source-code management, continuous integration, continuous delivery tools, wikis, video conferencing, and chat platforms such as Slack all help high-performance distributed teams be more effective. But they can’t make a low-performance team into a high-performance team. Lack of these tools can decrease the effectiveness of even a high-performance team, however.

7. Share the pain of time-zone separation

When a team has members at multiple sites, they demonstrate mutual respect by sharing the burden of working odd hours. Some teams make the mistake of having the team with the most members set the workday rules, but this sends the message to teams at other sites that their contributions are not valued as much. Making everyone share the burden is not only fairer, but it also creates a sense of empathy with what other team members have to endure.

8. Minimize wait times

Different time zones increase wait times. When a person at one site must wait for a team member at another to start the day to resolve a blocking issue, the rest of the day is lost. These delays add up. The daily stand-up can help uncover these problems, but the team will have to look not only at today’s work but potentially at tomorrow’s as well to know what issues might block them. It won’t be perfect, however, and some additional delay is inevitable.

Flattening roles and refining the product backlog to spot potential conflicts earlier can help. With dependencies reduced, and with teams having members who potentially can work on any product backlog item, blocking issues and slow hand-offs will be less frequent. But the issues can’t be eliminated.

No shortcuts to great teams

Distributed agile development is harder than co-located agile development. Time zone differences make collaboration more challenging. However, teams with members working at the same site but in different buildings will find collaboration more challenging as well. Being agile requires transparency, which doesn’t exist unless team members trust one another, and developing trust requires time spent working together.

Organizations make a big mistake when they think of teams as simply a group of individuals. A great team is far more than the sum of its members’ contributions. Being part of a great team is motivating—it challenges people to do their best, and it rewards them with a sense of shared accomplishment that individual accomplishment cannot. Great teams take time and investment to build, and they are worth preserving when they come together.

“When distributing work, for whatever reason, focus on forming great teams at the beginning. These teams can be formed with distributed individuals if they are motivated and supported, but it does take more practice on everyone’s part.”

Risk Management Banking Industry Trends

Fintechs and nonbanks now have a substantial influence in the banking industry. They are highly agile, innovative, and aim at exceeding the demands of modern customers in banking services and experiences. Established retail banks need to compete and often play catch-up. Still, they acknowledge the need to change, and change fast.

October 7, 2020 0 Comments by MSc. Adrian Lopez

AgileInnovation

Agile culture for remote teams

Distributed teams or remote teams are more important now than ever, the new normal requires teams and individuals to work from home or in different locations to deliver products and services. How can we use it to thrive agile culture?

Agile development was originally conceived for clustered teams, or teams physically located together in the same room. In keeping with the idea that “the most efficient and effective method of communicating information to and within a development team is face-to-face conversation”, early agile teams were meant to work together in proximity.

But today most businesses have a few–or many–distributed teams. This isn’t just a trend; it makes good sense. Distributed teams can work on projects around the clock, and strong talent can be found in less competitive markets. (Not to mention, talent is easily retained by not requiring an undesired relocation.) But the benefits of distributed teams aren’t without some trade-offs. For many distributed teams, it’s difficult to adopt the agile practice of face-to-face interactions.

Other challenges that emerge for distributed software teams:

Coordinating across time zones
Building rapport when everyone is not in the same office
Collaborating among different development cultures
Scheduling meetings or informal conversations when both teams are online at the same time for only a few hours (or less)

These are real problems. But not impossible ones. Let’s walk through some strategies to help bridge the distance gap between local and remote teams, and ideas to help mitigate other potential issues as well.

How to structure cross-border teams

Good software architecture dictates modular design, so structure your teams the same way. Every team should be self-sufficient in developing a single piece of technology, which minimizes the amount of collaboration required with teams in other offices/locations and makes them generally autonomous. When a project does require teams in different locations to pitch in, they can focus on their integration points and APIs.

Code reviews also play an important role. Since people are online at different times, distributing knowledge of the code between teams makes support and maintenance much easier. If a production issue emerges when the team is not online, another team can easily step in to support and resolve the issue, thanks to the know-how they gained from cross-team or cross-location code reviews.

Building rapport and co-worker affinity

It’s important in any team, especially in agile projects to have solid rapport across the team. Personal connection builds trust, minimizes missed expectations, eases self-organization, and boosts morale. Within your office, take the time to get to know everyone on your team. And, as much as possible, do the same with the people you work within remote teams. Personal connections are important. The stronger they become, the greater the chance of seeing these colleagues as any other, rather than distant coworkers from unfamiliar places without good relationships.

TIP: At Towa, each new employee posts a “intro blog” on our internal Communication tool, Towa’s content collaboration platform. The blog introduces the new hire professionally as well as personally (hobbies, interests, family, etc.) which really helps bridge the gap between offices. The more we know each other as people, the stronger we are working together as teams.

Above all, nothing replaces meeting face to face. Team members in each office will benefit from regular face time, and that includes video conferencing as well as visits to remote offices.

Video conferencing tools like Zoom help bridge the gap between teams, especially for distributed agile teams. However, teams that rely on Zoom should be aware of certain limitations.

Video conferencing often allows for a very short window of communication, while working in the same office gives significant visibility into another’s world: challenges, successes, and opportunities.
Zoom has done well to address network hiccups. Still, there may be times when network issues occur between buildings that can make video and audio choppy or difficult to understand.
Most people still think of Zoom video conferencing as scheduled time. Create a culture of using video chat for spontaneous casual conversation. Also, use instant messaging tools like Slack, Whatsapp, or Teams for quick communication.

To help mitigate some video conferencing issues, encourage team members to have regular 1:1 video chat sessions. These can be less formal, and help facilitate knowledge sharing in a casual way. Teammates can use these moments to build rapport and work better together.

Remember, tone, voice, and posture play a significant part in communication. In-person time helps the team know their remote colleagues in higher fidelity, which, in turn, makes future video conferencing more effective.

Building a united culture

There are four simple ways teams can make working across offices easier and share a common culture:

Over communicate decisions across all teammates
Setting up the development environment for easy collaboration
Clearly define the definition of Done
Create guidelines for filing effective bug reports

Let’s talk more about it.

First, when moving from a co-located office to a distributed culture, communication becomes significantly harder. The first challenge is training the team to understand that, when decisions are made, they need to be communicated. This may sound obvious, but it’s easy to forget! Oftentimes important decisions are made in hallway conversations, informal local team meetings, or by individuals. Plus, it can be easy to dismiss small decisions as unimportant.

Communicate even minute details until both teams find a healthy groove.

When decisions are made, everyone in each office needs to understand the decision and ideally why it was made. Don’t use email. It’s too easy to lose important information. Use a content management system like a wiki where team members can easily browse for updates across the team (and get notified of updates via email or Slack group chat tool). You can also use Slack to create channels for individuals and teams to communicate and see updates. Delays caused by team members working on outdated information, hitting a roadblock, and then asking a question costs the team significantly more time than proactively sharing information.

Second, consistent development environments across the team make it easier to work together and track down issues. Spend time creating a simple “Getting Started” guide and overcome first-day friction by automating the setup as much as possible.

Third, when working between teams, clear standards around the definition of “complete” makes it easier to manage expectations and build agreement across teams. A firm definition of complete eliminates the ambiguity in the work. For instance, when shipping a release that involves multiple teams, make it clear what it means to be complete: code written, pull request created, code reviewed, tested, and merged into the appropriate branch.

And finally, when problems come up. Having clear guidelines for bug reports and troubleshooting how-tos makes it easier for anyone on the team to track down an issue. Code review and good automated tests also share knowledge about the code base and empower the affected team to make the fix and validate that the change doesn’t have any unexpected side effects. Thus, no team becomes a blocker.

Maximize the golden hours

Every photographer knows “the golden hours” – just before and after sunrise and sunset–is one of the most effective times to take great landscape photos. The golden hours for distributed software teams are when the local and remote teams are both in their respective posts at the same time. When all teams are online, this is a great time for stand-ups.

For teams that share work between time zones, stand-up is a great time to pass the baton so the team just coming online can pick up where the other team left off. And holding stand-up via video conference makes it easy to ask questions and get up to speed so everyone is off and running as soon as the meeting is done.

Sometimes teams are so far apart that meetings will cause some form of pain for one team. (Get up at 6 a.m. for stand-up with the other team? Umm… no thanks.) Rotate the meeting time so it’s a shared burden, rather than continually subjecting the foreign team to the odd hours–a sure-fire way to destroy morale. Closely monitor the entire team’s engagement at stand-up. If there is an undue tension, or the team is not getting a lot out of it, team members will begin to disengage and stop listening or sharing. And stand-up doesn’t absolutely have to be a daily meeting. Meet with the remote team a few times a week and use the other days for a local stand-up. Similarly, a stand-up doesn’t have to be a morning routine, either. Whatever time of day is most convenient for everyone involved is the best time of day.

Every team is remote

In a distributed organization, the reality is that every team is remote. All teams need to adapt and learn how to share work between locations, communicate effectively, and grow a consistent culture across geographies. The most effective teams don’t just make the remote team adapt to their own culture because they understand that every team can learn something from the others. They seek to find and share successful practices across all locations. They also embrace “we” rather than an “us vs. them” culture.

Because the new reality is that most will become distributed. Businesses are working at home, we all need to manage a work/life balance. Teams that embrace both structure and transparency scale more efficiently. When your project scales beyond your location, the culture will be set up to do the right thing.

October 6, 2020 0 Comments by MSc. Adrian Lopez

Software Development Services

Engagement

Services