“User Stories are short and simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.” (Mike Cohn) Creating users stories is a very common practice in Agile software development. They were first coined in 1998 by Alistair Cockburn (one of the great minds who signed the Agile Manifesto). In his own words, “A user story is a promise for a conversation.”. The following year, Kent Beck, also one of the signatories of the Agile manifesto, introduced the idea in Extreme Programming (XP). Understanding the purpose and usage of user stories is essential to any Agile practitioner. They reflect the values of the Agile Manifesto. Especially the values “people & interactions over processes & tools” and “customer collaboration over contract negotiation”. So, what makes up a good user story? It’s not rocket science, but there is a typical template you should use to ensure it’s useful and maintains consistency. As a < type of user >, I want < some goal > so that < some reason >. Example: As the HR manager, I want a screening quiz so that I can better understand whether or not I want to send possible recruits to the functional manager. Much more than a sentence In 2001, Ron Jeffries — who collaborated with Kent Beck on XP — proposed three incremental steps to keep in mind when creating a good user story, colloquially called the 3Cs: Card: This is the tangible part of the exercise. Simply write the user story on a card. Conversation: In his book User Story Mapping, Jeff Patton says: “User stories get their name from how they should be used, not what should be written”. That’s to say, you can capture more important details and refine the overall story by having conversations about it with others (developers, users, stakeholders, etc.). Confirmation: A user story needs to include information on how to confirm it’s finished. This info should be described in the acceptance criteria section of the user story, typically at the back of the card. After completing these three steps, the team should be able to implement the story. But how do we know what we’ve created will be useful? A good practice to ensure quality is to follow the INVEST acronym: Independant: Implement in any order, no overlap in primary concepts. Negotiable: Possibly more or less of a feature. Valuable: Story needs to be beneficial to the customer. Estimable: Understood well enough to estimate the effort and complexity at the level required. Small: If too large, scope, deliverability, and testability risks will be incurred. The general acceptance is that the story should be small enough to fit in less than a sprint. Testable: Must have a verifiable definition of done — executable requirements are a best practice. INVESTing in good user stories is a worthy endeavor! A step-by-step guide and helpful practices 1/ Focus the user’s vision around three angles: role, need, and business value A user story needs to address the user point of view, not the system point of view, or any other. To help, you can try answering the following questions: Who’s asking for the feature, or who is benefiting from the feature? (role) What is requested? (need) What value is generated from developing the feature? (business value) Different techniques help in defining the users of a system: User profile: to define the responsibilities and tasks User role: to describe context, characteristics and criteria Persona: to define a typical user, a fictional representation of the targeted users 2/ Identify the personas and user roles These personas and user roles will be used throughout product development and referred to in user stories. 3/ Define customer journeys and story maps for a global vision of the product Customer journeys enable us to understand the whole flow and process you want to address in your product for your customers. A story map is also very useful after identifying the customer journey, to further detail your product and prioritise the features you’ll develop. It’s also a great way to convey the vision of the product. For more insight on this subject, check out Jeff Patton’s book User Story Mapping. Check out one of a example of a user story map below… 4/ Conversations to improve and further detail a user story This step is all about having conversations with the different people involved in the product, allowing you to: Get a better understanding of the customer/user needs Break down the user story if necessary (remember the S in INVEST) Define acceptance criteria that allow you to check that the user story is working as intended Estimate the user story Conversations are indeed at the heart of user stories. Without them, they’re meaningless. In the words of Jeff Patton, “good documents are like vacation photos.” Makes sense! Photos look great, but they don’t really tell the whole story. And if you haven’t been part of the conversation, you won’t be able to fully grasp it. This also goes for any document you share. Writing is always subject to interpretation, even when you try to put as much detail as you can in a document. Just look at how law practitioners argue on interpreting the law! So don’t rely on any one document to fully convey a message, but do make sure the people who have a need and the people who will fulfill that need engage in a conversation. The document (i.e. the user story) is simply to remember the conversation, the same way a picture will help you remember the events before and after the picture was taken. 5/ Confirm the User Story with acceptance criteria As mentioned, you need to define acceptance criteria so that the story can be checked. If all acceptance criteria are not filled, the story cannot be considered ‘done’. There is no ‘half-done’ user story, it’s either done or it’s not. To define acceptance criteria, a useful practice is using the format Given/When/Then. < Given > some context < Given > some action is carried out < Then > a particular set of observable consequences should be obtained. An example user story would be, “as a customer, I want to withdraw money at an ATM to avoid long queues in agencies”. To find an acceptance criteria, we can ask the following questions: What do we do if there is not enough money in the account? When should a withdrawal be refused? Resulting acceptance criteria could be:Given the customer has input an amount greater than his account balance, when he/she confirms the amount then the following message appears: “Insufficient funds for the amount selected. Your current balance is: xxx” and the customer is redirected to the select amount screen. Where possible, the acceptance criteria should be expressed as concrete, executable customer tests. TL;DR Users stories are useful tools for expressing user needs for a product. They should encourage simplicity, and convey the user’s point of view. Remember to clarify first and foremost product vision, user roles and personas; involve the customer in the writing process through face-to-face conversations, and respect the INVEST rules. Follow these tips, and you can’t go wrong.

This story begins about a year after I joined a financial institution. The company was going through another restructure, which involved the reorganisation of teams and reprioritisation of work, which in large part affected IT teams.  Teams were formed around different initiatives and systems. However, there were a subset of systems that were considered ‘legacy systems’, which weren’t factored into the restructure. People were allocated to these teams through negotiation between middle layer managers without consultation with the people who would be most affected. Yikes! As a result, there were people who weren’t allocated into any teams, who were then put together to form the team that I would be coaching and supporting. This team was deemed the Technical Optimisation of Applications team (or ToA for short). The ToA team was responsible for looking after nine different legacy systems spread across three product owners (POs). It consisted of seven developers, two dedicated testers, and myself as the Scrum Master. The developers and testers had varying levels of understanding of the nine different systems, meaning we needed to co-create a plan to upskill. It’s worth mentioning that, originally, this team was called the Technical Maintenance for Applications team. Now, language is an extremely important tool in setting expectations. Using the word ‘maintenance’ gave the expectation that the team would only be used to clean up and apply fixes. I wanted the team to adopt a mindset more centred on improvement. Hence, the word optimisation was chosen. Quite an improvement on “maintenance” right?  Overcoming obstacles The first couple of weeks working with the team were particularly rough. Had I known what I know now, I would have gathered the team to co-create our purpose and develop a working agreement within the team, enabling them to get to know each other as people, colleagues and team members. Right off the bat, there was a perception that the legacy systems the team was looking after were going to be decommissioned. This was repeatedly voiced to the team directly by middle layer managers, but with no plan/schedule in sight. One thing that stuck in my mind about this was a conversation I had with a manager: “Do you know what we call your team? We call it the ‘Graveyard Team.’ You know, like where applications go to die’”. My response to him was: “If we are indeed the ‘Graveyard Team’ and you have work that needs to be done on these dying systems, why would we prioritise it to be done?” Followed by radio silence! Three POs were assigned to nine systems, and two out of the three had some previous experience as POs. However, they were all disengaged because the legacy systems they were working on weren’t considered interesting or new. Other teams tried passing work they didn’t want along to the ToA team, so we quickly realised we needed a better working mechanism in place—one that incorporated a backlog, and was understood and adhered to by all. Over 400 backlog items (yes, 400, that’s not a typo) which were up to five years old had built up over the years across the nine systems that the team were responsible for. We knew we had to find a way to reduce these. In addition to this obstacle, the time that it took to deploy changes across systems ranged from three to six months, which impacted our ability to respond quickly to change. The team was also tasked with tackling any priority issues. The financial institution had a system where ‘priority 1’ and ‘priority 2’ issues needed to be dealt with immediately. P1’s wouldn’t happen very often, but when they did, they were all-hands-on-deck situations. P2’s were similar, but had a different service-level agreement. P3’s and P4’s were put into the backlog. Taking the obstacles above into account, as a team, we created the following objectives and key results: We want to understand and resolve P1 and P2 incidents effectively and quickly We want to deploy value-add changes into production effectively with no issues We want to allow enough capacity within the team to make improvements We want to increase our capabilities across the nine systems We split the OKRs into three phases, each for 90 days, and dove right in... PHASE 1: Reduce the number of backlog  items to zero across all systems within three months The whole team agreed that the most important thing to work on immediately was reducing the number of issues in the backlog. The first thing we did was delete any issues that were over four years old, therein testing our hypothesis that if we had deleted something important someone would come back and let us know.  The second thing we did was look at the remaining list to understand which of the nine systems had the most long-standing issues. We also looked at the frequency of the change of deployments into production to see if we could ascertain which of the nine systems had the most activity, and therefore the most urgency.  Once the team understood this, they were able to prioritise which systems to focus on first. For each of the systems, we took the list of issues to the POs to reprioritise, to ensure they were still valuable.  PHASE 2: Deliver valuable business outcomes more effectively With the POs armed with this information, the team implemented a 30-minute, time-boxed triage meeting at the start of each sprint, with all the system POs and the entire team in attendance. Each PO would discuss their priority items and discuss with the other POs why their request was more important than the others, as the team had limited capacity. If we ran out of time to discuss the agreed upon items, it was understood by the team that this meant one of two things: a) The PO and the team were not clear on what needed to be done for the work item b) Large pieces of work needed to be broken down into smaller parts We decided as a team that in each two-week sprint they would have the capacity to work on eight items. The rule of thumb for each item was that it couldn’t take more than three days to develop and test. If the team decided that the task was larger than a three-day effort, it was the POs responsibility to break it down further. For items that took less than three days, the PO needed to explain why this work item was important for them. The team was able to ask questions, discuss, and when this back-and-forth was completed everyone could vote as to whether or not this piece of work should go into the next sprint. Democracy can work wonders in these situations.  The voting process was simple, thumbs up 👍 or thumbs down 👎 but the votes needed to be unanimous. For example, if everyone except one person voted to do a piece of work, then it was either up to the people who voted 👍 to convince the person who voted 👎 otherwise, or vice versa. The team had daily scrums to discuss what they did the previous day, what they were planning to do on the current day, any issues/blockers they had, and whether they needed help. At the end of each sprint the team had a sprint review with POs and stakeholders, evaluating the work that was done so they could provide input and direction. As they discussed these completed work items, they also discussed which release these changes would go into, so the POs could gain visibility of non-functional requirements like change awareness and comms to the affected customers. The team would then have their own sprint retrospectives, which were quite standard, with the one exception that we would ask extra questions: “What’s one thing you learned this sprint?” and “What’s one thing that you would like to learn next sprint?”. This encouraged a learning mindset, and facilitated discussion around which team members could pair in the following week to build capability. Every now and then, P1 and P2 incidents on the systems we looked after would occur. All current work would stop, the team would go into incident mode, and swarm to resolve the issue. It didn’t matter if you knew the system or not, as having visibility and context of why the team needed to stop working and solve the incident raised understanding of the system as a whole. Using all the aforementioned mechanics, the team was able to reduce the number of work items in the backlog of nine different systems to zero in three months, all while building their abilities to manage new work items generated by POs.  Using Jira, we were able to determine that—before working this way—the average age of work items from creation to production was about 12 months. By the time I left the organisation, the average age was 14-30 days 🙌 PHASE 3: Enhancements to our systems Once the team reduced the number of backlog items to zero across systems and started delivering business outcomes more effectively, the POs started generating new work items for the systems. These new work items would go through the same process as before, using the triage method. The team was now delivering consistently on around six to eight work items per sprint, and discussing improvements to make their lives easier (e.g. testing and deployments). The team, along with the POs, agreed to reduce the number of work item slots to six and use the remaining two slots as system improvement slots. The team started to generate their own system improvement ideas into the backlog. These ideas were discussed in the same triage meeting, using the same process, ensuring that the team and the POs understood why it was important and what precisely needed to be done.  A rule was also put in place where no improvement work would be started unless all the requested work items in the six slots were completed first. This provided an indication of whether we were effective as a team in completing the work in the six slots, or if we needed to adjust the work limit. Improvement, that’s the key word here. Once the team had the time, the people and the morale to better their processes and understand their capacity, everything changed for the better. Simply surviving, keeping your head above the water—especially in a development environment—is not conducive to good business or happy teams. Wrapping up, a few bullet points that you might incorporate into your own projects and workflows... What did we discover/learn along the way? We didn’t fully realise until six months in that we were a fully-funded team with the freedom to work on whatever improvements we wanted. There was a lot of manual work entering issues and defects from our service management systems to Jira. To resolve this bottleneck, we developed an integration component that synchronises with Service Manager, so that any issue that gets logged there and assigned to our team will automatically generate a Jira card and place it into our backlog. We discovered that, without a clear reason to work on a system, just having a developer explain the system to another dev and tester was not effective. Our goal here became actually learning the system from doing the work, rather than simply being told how the system functions. Out of this evolved a working agreement that any piece of work needed to have one primary developer (someone who knows the system in and out) to act in a consulting role, and another dev and another tester to work together on how to solve the issue. It was important for us as a team (including the PO) to understand how we wanted to engage with each other, and what events and processes we wanted to follow. By defining and agreeing to terms within our own team we were able to back each other up when other managers sought to push work onto the team. Eventually the POs that had their work done for a few consecutive weeks would acknowledge this pattern, and would negotiate with the other POs to allow other pieces of work to be done. A few rules of thumb Pair together, and have a primary person on a system teaching another team member. This improves capabilities across systems over time. Fully realising this goal means no longer having any single point dependencies in your team. Fix the amount of available work item slots per sprint (eight slots) to increase transparency about workload. Fully realising this goal means your PO understands or can challenge the number of available slots. Only allow the team to work on enhancements after all outstanding issues are resolved. This allows you to focus more effectively on improvements. The desired endpoint here is having zero issues in your backlog, and the capacity to work on new requests and enhancements.  Refuse any work from POs larger than three days worth of effort, request that they break it down further into smaller pieces.

This story begins about a year after I joined a financial institution. The company was going through another restructure, which involved the reorganisation of teams and reprioritisation of work, which in large part affected IT teams.  Teams were formed around different initiatives and systems. However, there were a subset of systems that were considered ‘legacy systems’, which weren’t factored into the restructure. People were allocated to these teams through negotiation between middle layer managers without consultation with the people who would be most affected. Yikes! As a result, there were people who weren’t allocated into any teams, who were then put together to form the team that I would be coaching and supporting. This team was deemed the Technical Optimisation of Applications team (or ToA for short). The ToA team was responsible for looking after nine different legacy systems spread across three product owners (POs). It consisted of seven developers, two dedicated testers, and myself as the Scrum Master. The developers and testers had varying levels of understanding of the nine different systems, meaning we needed to co-create a plan to upskill. It’s worth mentioning that, originally, this team was called the Technical Maintenance for Applications team. Now, language is an extremely important tool in setting expectations. Using the word ‘maintenance’ gave the expectation that the team would only be used to clean up and apply fixes. I wanted the team to adopt a mindset more centred on improvement. Hence, the word optimisation was chosen. Quite an improvement on “maintenance” right?  Overcoming obstacles The first couple of weeks working with the team were particularly rough. Had I known what I know now, I would have gathered the team to co-create our purpose and develop a working agreement within the team, enabling them to get to know each other as people, colleagues and team members. Right off the bat, there was a perception that the legacy systems the team was looking after were going to be decommissioned. This was repeatedly voiced to the team directly by middle layer managers, but with no plan/schedule in sight. One thing that stuck in my mind about this was a conversation I had with a manager: “Do you know what we call your team? We call it the ‘Graveyard Team.’ You know, like where applications go to die’”. My response to him was: “If we are indeed the ‘Graveyard Team’ and you have work that needs to be done on these dying systems, why would we prioritise it to be done?” Followed by radio silence! Three POs were assigned to nine systems, and two out of the three had some previous experience as POs. However, they were all disengaged because the legacy systems they were working on weren’t considered interesting or new. Other teams tried passing work they didn’t want along to the ToA team, so we quickly realised we needed a better working mechanism in place—one that incorporated a backlog, and was understood and adhered to by all. Over 400 backlog items (yes, 400, that’s not a typo) which were up to five years old had built up over the years across the nine systems that the team were responsible for. We knew we had to find a way to reduce these. In addition to this obstacle, the time that it took to deploy changes across systems ranged from three to six months, which impacted our ability to respond quickly to change. The team was also tasked with tackling any priority issues. The financial institution had a system where ‘priority 1’ and ‘priority 2’ issues needed to be dealt with immediately. P1’s wouldn’t happen very often, but when they did, they were all-hands-on-deck situations. P2’s were similar, but had a different service-level agreement. P3’s and P4’s were put into the backlog. Taking the obstacles above into account, as a team, we created the following objectives and key results: We want to understand and resolve P1 and P2 incidents effectively and quickly We want to deploy value-add changes into production effectively with no issues We want to allow enough capacity within the team to make improvements We want to increase our capabilities across the nine systems We split the OKRs into three phases, each for 90 days, and dove right in... PHASE 1: Reduce the number of backlog  items to zero across all systems within three months The whole team agreed that the most important thing to work on immediately was reducing the number of issues in the backlog. The first thing we did was delete any issues that were over four years old, therein testing our hypothesis that if we had deleted something important someone would come back and let us know.  The second thing we did was look at the remaining list to understand which of the nine systems had the most long-standing issues. We also looked at the frequency of the change of deployments into production to see if we could ascertain which of the nine systems had the most activity, and therefore the most urgency.  Once the team understood this, they were able to prioritise which systems to focus on first. For each of the systems, we took the list of issues to the POs to reprioritise, to ensure they were still valuable.  PHASE 2: Deliver valuable business outcomes more effectively With the POs armed with this information, the team implemented a 30-minute, time-boxed triage meeting at the start of each sprint, with all the system POs and the entire team in attendance. Each PO would discuss their priority items and discuss with the other POs why their request was more important than the others, as the team had limited capacity. If we ran out of time to discuss the agreed upon items, it was understood by the team that this meant one of two things: a) The PO and the team were not clear on what needed to be done for the work item b) Large pieces of work needed to be broken down into smaller parts We decided as a team that in each two-week sprint they would have the capacity to work on eight items. The rule of thumb for each item was that it couldn’t take more than three days to develop and test. If the team decided that the task was larger than a three-day effort, it was the POs responsibility to break it down further. For items that took less than three days, the PO needed to explain why this work item was important for them. The team was able to ask questions, discuss, and when this back-and-forth was completed everyone could vote as to whether or not this piece of work should go into the next sprint. Democracy can work wonders in these situations.  The voting process was simple, thumbs up 👍 or thumbs down 👎 but the votes needed to be unanimous. For example, if everyone except one person voted to do a piece of work, then it was either up to the people who voted 👍 to convince the person who voted 👎 otherwise, or vice versa. The team had daily scrums to discuss what they did the previous day, what they were planning to do on the current day, any issues/blockers they had, and whether they needed help. At the end of each sprint the team had a sprint review with POs and stakeholders, evaluating the work that was done so they could provide input and direction. As they discussed these completed work items, they also discussed which release these changes would go into, so the POs could gain visibility of non-functional requirements like change awareness and comms to the affected customers. The team would then have their own sprint retrospectives, which were quite standard, with the one exception that we would ask extra questions: “What’s one thing you learned this sprint?” and “What’s one thing that you would like to learn next sprint?”. This encouraged a learning mindset, and facilitated discussion around which team members could pair in the following week to build capability. Every now and then, P1 and P2 incidents on the systems we looked after would occur. All current work would stop, the team would go into incident mode, and swarm to resolve the issue. It didn’t matter if you knew the system or not, as having visibility and context of why the team needed to stop working and solve the incident raised understanding of the system as a whole. Using all the aforementioned mechanics, the team was able to reduce the number of work items in the backlog of nine different systems to zero in three months, all while building their abilities to manage new work items generated by POs.  Using Jira, we were able to determine that—before working this way—the average age of work items from creation to production was about 12 months. By the time I left the organisation, the average age was 14-30 days 🙌 PHASE 3: Enhancements to our systems Once the team reduced the number of backlog items to zero across systems and started delivering business outcomes more effectively, the POs started generating new work items for the systems. These new work items would go through the same process as before, using the triage method. The team was now delivering consistently on around six to eight work items per sprint, and discussing improvements to make their lives easier (e.g. testing and deployments). The team, along with the POs, agreed to reduce the number of work item slots to six and use the remaining two slots as system improvement slots. The team started to generate their own system improvement ideas into the backlog. These ideas were discussed in the same triage meeting, using the same process, ensuring that the team and the POs understood why it was important and what precisely needed to be done.  A rule was also put in place where no improvement work would be started unless all the requested work items in the six slots were completed first. This provided an indication of whether we were effective as a team in completing the work in the six slots, or if we needed to adjust the work limit. Improvement, that’s the key word here. Once the team had the time, the people and the morale to better their processes and understand their capacity, everything changed for the better. Simply surviving, keeping your head above the water—especially in a development environment—is not conducive to good business or happy teams. Wrapping up, a few bullet points that you might incorporate into your own projects and workflows... What did we discover/learn along the way? We didn’t fully realise until six months in that we were a fully-funded team with the freedom to work on whatever improvements we wanted. There was a lot of manual work entering issues and defects from our service management systems to Jira. To resolve this bottleneck, we developed an integration component that synchronises with Service Manager, so that any issue that gets logged there and assigned to our team will automatically generate a Jira card and place it into our backlog. We discovered that, without a clear reason to work on a system, just having a developer explain the system to another dev and tester was not effective. Our goal here became actually learning the system from doing the work, rather than simply being told how the system functions. Out of this evolved a working agreement that any piece of work needed to have one primary developer (someone who knows the system in and out) to act in a consulting role, and another dev and another tester to work together on how to solve the issue. It was important for us as a team (including the PO) to understand how we wanted to engage with each other, and what events and processes we wanted to follow. By defining and agreeing to terms within our own team we were able to back each other up when other managers sought to push work onto the team. Eventually the POs that had their work done for a few consecutive weeks would acknowledge this pattern, and would negotiate with the other POs to allow other pieces of work to be done. A few rules of thumb Pair together, and have a primary person on a system teaching another team member. This improves capabilities across systems over time. Fully realising this goal means no longer having any single point dependencies in your team. Fix the amount of available work item slots per sprint (eight slots) to increase transparency about workload. Fully realising this goal means your PO understands or can challenge the number of available slots. Only allow the team to work on enhancements after all outstanding issues are resolved. This allows you to focus more effectively on improvements. The desired endpoint here is having zero issues in your backlog, and the capacity to work on new requests and enhancements.  Refuse any work from POs larger than three days worth of effort, request that they break it down further into smaller pieces.

Over the last few years, digital transformation has been steadily bandied about as one of the hottest corporate buzzwords in the industry. Today, it’s the talk of the town. It’s what many organisations are experiencing as they adopt innovative ways to do business. We hear about companies investing more and more into new technologies, digital data, business process automation, and even culture makeovers. But what exactly are they trying to achieve and most importantly - why? For more insights on this topic, I recently sat down with Daryl Teo, formerly the Associate Director of Digital Transformation at the group enterprise of Singtel, who has a proven track record of leading and implementing digital transformation initiatives for both startups and distinguished brands. He currently leads the New Digital Business & Product division at the international arm of Singtel, supporting key initiatives in Esports (Gaming) and Digital Financial Services. Why is it important for companies to innovate and adopt new ways of working? These days, customer preferences have really changed. With social media and the advancements of digital technology, it’s not sufficient to just focus on what products and services you’re offering. It’s very important to focus on R&D or any other kinds of innovative ways that you can outthink your competitors. You also need to make sure that at the crux of it all, you are providing your customers with what they’re looking for and how you’re solving their pain points. Why is it especially important for a big company? Big companies today have the benefit of having key strategic advantages such as their existing customer base and a lot of economies of scale they can tap on.  However, it’s also very interesting to look at how new startups have just come in and built very different and innovative business models just by focusing on one key aspect of the entire customer journey. Just by focusing on that one key aspect, they will be able to dedicate a lot more focus and understanding of their customer, which leads to being able to innovate very precisely on how to really one-up the customer journey.  This is something that big companies can replicate in greater capacity. I guess there’s always that myth that big companies move slowly but if you look at what the biggest companies in the world today are doing, I think it’s very prevalent that a lot of them have started to move a lot faster. If they can move at that speed of startups by being a lot more innovative in what they’re doing, they naturally have the strategic advantages that startups don’t, which are very big customer bases that allows them to upsell and cross sell to. They are also able to focus on longer term strategic goals because they have longer runways, and existing revenue streams they can tap on to invest more into R&D and future products. You’ve held key roles in leading digital transformation initiatives for both startups and bigger companies. Is there an ideal or “best” approach to digital transformation?  Broadly speaking, at the heart of the whole digital experience and a good digital transformation programme, it’s very important to bear in mind why you are even doing it in the first place. The key focus should really be on the consumer or the end customer. After you look at that, we can break it down into several smaller areas. The way I really like to put it is Process, Profits, Product, and People. Firstly, key business process innovation - how do you make sure that you change your way of working into something that is newer? How can you improve on it by leveraging new digital technologies that were not available in the past? That’s the first bit - the way you’re doing things and the way you’re serving your customer.  The second one is to look at the business model, especially those business models which have existed across the years. In this day and age, when you have different digital methods and channels that you can sell your products from, can you start to do it a lot more efficiently? Can you be more effective in terms of problem-solving and delivering what your customers are looking for? Does that business model then enable you to pass on lower cost of serving, for example, into more affordable products and services?  The third bit is around what exactly is the right product mix you’re selling. For example, take Facebook - they have done innovation really successfully. They have moved from a social network into many other things like communication and payments. Or look at Amazon and what they have been doing with Cloud computing and AWS. I think these are great examples of how we cannot be just looking at our current business models. It makes perfect financial and strategic sense to look at what customers would be willing to buy from you, what you can leverage based on your existing services, and what you can sell to customers to open up new revenue streams.  The final bit is around people. The most fundamental underlying bit is how do you make sure that when you pursue digital transformation, you also grow the people you’re working with, grow the people you are serving, help them pick up new skills around technology, and how to stay relevant in this climate where technologies change all the time. By improving your own employees and end customers, you’ll be able to build a much better ecosystem.  You mentioned Process, Profits, Products, and People in your digital transformation approach. With these four key tenets in place, what are some key results you can expect to see in the organisation? It really depends on what is or who you’re trying to serve, what you’re trying to solve, and what you’re trying to deliver. Digital transformation will take many different forms. A lot of successful business digital transformation projects out there have very clear objectives. With a very clear objective, that will enable you to branch out, dissect, and focus on a more strategic kind of objective that you’re trying to solve.  For instance, if I want to pursue customer satisfaction, then the net promoter score and eventual customer feedback in terms of both quantitative rankings and qualitative anecdotes will become very useful for me to really gauge how successful that transformation has been so far.  In a more corporate sense, there must always be a business case - what is the process before, what are the numbers before, and what is it right now. If you look at things like metrics from an operational point of view, are there some key numbers that have changed? For example, products delivered and customers served within a certain time period because of new technology. These are some considerations you can eventually translate into faster revenue recognition. Am I selling a lot more? Is my cost much better? Has my margin increased? Those are some of the many areas digital transformation can accentuate. Digital Transformation - A Necessary Disruption Thank you Daryl! Indeed, in this fast-changing world where businesses are constantly in competition to distinguish themselves from their rivals, time-honoured and traditional models need to evolve. Not only have consumers become more demanding and complex, companies eventually have to find new ways and tools to deliver value, increase revenue, and improve ways of working. Fundamentally, it’s not just about surviving, but thriving. Change is here - it’s time to embrace it.

On December 8th, I had the honour of attending and speaking at Agile Vietnam Conference 2019 in Hanoi. This was the second time I had spoken at this community-led conference and in both instances, I’ve had a great experience. I had the pleasure of seeing Shane Hastie from ICAgile and InfoQ again, who delivered a great keynote on the topic of Edge of Agility. Shane reminded us that the operating model that will drive agile organisations in the near future is placing customers in the center of the organisation. Delighting the customer will be the norm; not generating profits. And if your organisation is not moving towards that right now, you might risk falling further behind. Once all this becomes the norm, what then? The Edge of Agile will come when societies become Agile. This was the case illustrated by Dr. Rashina Hoda, as she described how New Zealand demonstrated agile values when responding to the country’s worst terror attack on 15 March 2019. Agile Nation Values 1. People and Interactions over Protocols and Rules 2. Community collaboration over closed decision making 3. Policies and actions over speeches and promises 4. Responding to change over following the status quo You can watch her talk on TEDx. The second talk I attended was given by Giang Đào, whose insights tackled how to break away from the trap of having a negative mindset. Giang shone a light on the fact that the way we see reality is not the actual truth, but a perceived reality shaped by our senses combined with our pre-established belief system. Once we become aware of our own limitations and biases, we can start trying to see things as they are. The third talk was given by a duo of coaches living in Vietnam, Chris Kruppa and Marco Passuello, and the topic was Agile Leadership. They presented 4 pillars of Agile Leadership: Adaptability, Integrity, Empathy, and Vulnerability, and how to use these pillars to guide our decision-making process. After lunch, Doi Pham, one of the leads of Agile Vietnam, gave the second keynote about Agile transformations in Vietnam. Next, a group from Japan, led by Jean-Baptiste Vasseur, shared a new Retrospective format with the attendees called Fun, Done, Learn. The full questions were: 1. How much the team is enjoying their work, and workplace (Fun)? 2. How much the team is learning, and improving (Learn)? 3. How much the team is able to deliver/get to Done (Done)? Check out their original article on Medium. They asked participants to engage in this retrospective style in the context of the conference. We brainstormed what we got done, what we learned, and what was fun about it. The activity itself was a lot of fun - I highly recommend you try this retrospective style with your teams. Our team writing our Fun, Done, Learn stickies My talk was the last talk of the day. The topic I chose was a favourite of mine: Demystifying Estimation. I had written about estimation before and after encountering more and more teams that still struggle on how to use (or not use) estimations on their work, I decided to create a talk about it. In my talk, I deconstructed the concept of estimation, introduced a framework of how to present estimations as a range of dates with confidence levels — instead of a single date/deadline — how to use relative estimation and historical data to forecast future work, and sources of distractions. Me with my Troublemaker’s hat. I really enjoy attending and speaking at conferences. It’s a space for sharing and learning, but also networking. As described in this article, I’ve learned many new things, shared my experience with Estimation, and met many amazing agilists. What else could you ask for? A note on the current situation of the world Conferences like these probably won’t happen for a while until the situation changes. But people are creative and rise to meet new challenges. I’m already seeing many remote conferences popping up everywhere, so knowledge sharing and networking opportunities are always going to be there - they will just look a little different. I recently attended a knowledge sharing workshop about remote working: Suddenly Distributed, attended by several big names in the remote work industry: Lisette Sutherland, Mark Kilby, Judy Res, Steve McCann, Charles Humble, and the one and only Shane Hastie; facilitated by David Horowitz. Knowledge sharing workshop, on a suddenly remote world Stay connected, stay safe.

I recently conducted a workshop with General Assembly in Singapore and at the end of the workshop, a participant came up to me and asked: “How did you start workshopping? How does one begin?” The question allowed me to recollect the informal way of how I began my workshopping journey and it got me pondering over the steps one could take to gain confidence from facilitating to leading, and eventually designing workshops. So let me tell you my story. When I was a young girl, I used to see my mum busying herself in the kitchen, whipping up an awesome meal for the family. I used to hang around near her and just observe what she was doing. I was also quite the chatty daughter so I’d fill the silence with “What are you cooking?”, “Why?”, “What is that?”, “Where does that come from?” You get the picture. What does this have to do with workshopping? Well, this leads into the first step of my workshopping journey. Research and participate This not only sparked the beginning of my interest, but till this day, continues to fuel it. I began by understanding the landscape. A workshop is essentially a discussion space, so what other discussion spaces are there? Hackathons, talks, seminars, focus groups etc. I immersed myself in them by participating in these discussions to see what they were all about. Some of the things I paid particular attention to were: the demographics of the attendees (understanding the audience), looking at what people were asking, what were they curious to know? How did the facilitators answer and what were the methods employed in their workshops? Also on the workshop sequence; how did they start and end? What was the workshop trying to achieve? Then, retrospect. What topics were of interest to me? How did the facilitator or workshop lead engage the audience across their differing demographics? Did I think it was a successful workshop? Why? What would I do differently if given the chance? Now that I had an idea of what it was, I wanted to know how it was done. How does one actualise a workshop? Hello, step 2: Co-ordinate What were the physical building blocks? To cook, you need a few essential things such as a chopping board, pots and pans, utensils, a stove perhaps, and even a sink. This was the set up. For me, knowing the landscape was simply not enough, I had to get my hands dirty. I wasn’t ready to be in front of an audience but I was sure I could learn a thing or two behind the scenes. So I got involved in workshops by helping out with the logistics. On hindsight, being a runner really helped me in planning workshops, and understanding why site recces are important and have a strong say in how the workshops are run. Were there whiteboards? Could the walls be written on? Was there a monitor or projector to aid in visual presentation or would I have to dabble in visual facilitation (Bikablo style)? Were markers and post-its required or were we going digital? If so, how would the participants collaborate and share? This part is intricate and every workshop will be different. But with practice comes experience, and you will know the things to look out and plan for. The setup has a strong say in how the workshop is organised. Know the set up, build your workshop. But… that’s not enough is it? “Nothing ever becomes real ‘till it is experienced.” — John Keats So, it was time to get into the thick of it. Facilitate After lurking around in the kitchen observing, probing, and getting my mum the equipment she needed, I decided that I could move on to the next stage. I was going to help cook — cutting the vegetables, cleaning the meat etc. I began to understand why she would use certain spices over others and the different cooking methods: boiling, stir-fry, deep-fry, broiling, blanching, etc. This was when cooking started to become real for me. This was also true for workshop facilitating. I was still not ready to be in the limelight (total accountability) but that didn’t stop me from standing behind someone who was experienced and confident. I had a safety net. The hands-on practice allowed me to be exposed in the workshop but I was not totally accountable and responsible for the success of the workshop. I was learning, and I could observe the leads and ask questions that boosted my practical experience. However, as I understood the activities and their objectives, I realised I could get involved as a facilitator. Facilitating affords intimacy with a smaller group within the workshop, and it’s more personal versus presentational. Most importantly, I could get feedback from my lead and peers, and I could begin sharing my experience with others. After facilitating at workshops for a while, I knew I was ready for more. I was a workshop genius, I could lead a workshop now, yes? Similarly, I wanted to put my cooking prowess to the test by cooking dinner for the family. I started with much excitement but after some taste tests, I realised my food wasn’t as great. I called my mum into the kitchen and she helped me to identify missing ingredients — the special touch that brought the flavours together. We cooked the rest of the dishes together, with her as the head chef and I, the sous chef. I wasn’t the lead, but I was close. It was then that I realised that the next significant step would be to co-lead rather than lead a workshop immediately. Dinner was great by the way, thanks for asking. Co-lead After a few rounds of facilitating, I was ready to emerge from the lead’s shadow. Although there was still a safety net, there was a stronger feeling of accountability and responsibility. I could take more ownership over workshop objectives and the outcomes we wanted. There was an added element of coordinating with stakeholders, and understanding their needs and their desired outcomes. Together with the lead, I could come up with the activities and their objectives, and lead the workshop team towards the outcome/direction. I started to grow in confidence as I began to lead. Yet, I did not stop retrospecting on this new position, and actively seeking feedback from the team and workshop participants in order to improve. Now, I felt that I was finally ready to be the head chef. (About time!) Lead With all the experience gained, now was the time to step out of my comfort zone. Not only did I have to lead the workshop, but also the team with me. Like the head chef, I was comfortable and excited to come up with my own recipes depending on the workshop objective. I could design the workshop with total accountability. I could sift through all the methods I’ve ever come across and select those that would best fit the workshop objective. With stakeholders, I could plan on a strategic level as I could be privy to the wider goals of their organisation and how the workshop fits into the bigger picture. This includes advising based on the objectives of the workshop and high-level planning — how long should the workshop be, whether we would need to recruit specific workshop participants, and thinking about the potential activities that could marry well to fulfil the workshop objective. With the team, I would crowdsource ideas and decide on activities, explain why some activities might work better than others, and pull on experience to look at a variety of factors. For instance, demographics of the workshop participants, workshop space and equipment, and the workshop team. I became more adept at fielding questions while also allowing space for the team to step up in this area. During the workshop, I would be able to make informed decisions to augment the workshop as it progressed (if need be). But alas, this is a learning journey! Workshopping is a muscle. You’ve got to keep exercising it. Repeat If you progress through the stages but only think as a lead, there is a tendency for stagnation. Keep going back to the basics — research and participate, co-ordinate, facilitate etc. It allows you to stay up to date with the latest trends in workshopping while constantly flexing and honing your skill. Be in the know of new ideas, methods, and topics that are of interest. Before ending off, I’ve thought to leave some pointers that I’ve gathered along my journey: - When you are standing in front of people, there will always be the fear of failure. Acknowledge it and press on. You have something to share and an audience who is looking to receive. - Don’t be afraid to get back to a question if the answer doesn’t come to you immediately. I find that introducing a “Parking Lot” in workshops where participants of the workshop can post questions at any point and you can subsequently review it helps a lot. - Having good body language is ¾ of the battle won. - You’ll always be learning. Adopt the appropriate attitude and nothing much will faze you. - Check out the 7Ps Framework for Gamestorming, designed by James Macanufo. It’s such a good tool for planning workshops and meetings! Alright, it’s dinner time. Gonna whip up some food! Till next time! TL;DR - Research and participate to understand the environment - Coordinate to train flexibility in workshop-planning based on workshopping space - Facilitate with a safety net under that tightrope - Co-lead to gain confidence - Lead to experience and train strategic thinking in the face of accountability - Repeat for relevancy and proficiency

Many of us are trying to find ways to adjust to what is now becoming our biggest work-from-home experiment. Whether your organisation has adopted a sweeping remote work policy, or you collaborate with global team members or clients who have done so, many now find themselves in a new, potentially confusing environment.  The circumstances surrounding the coronavirus, and its effects on teamwork, motivated us to dig a bit deeper into what works, and what doesn't, when 'work-from-home' becomes the new norm. Agile transformations are, by nature, difficult without face-to-face contact. But difficult is not impossible. When it comes to coaching, transformations actually run into many of the same obstacles we’ve explored in the first four parts of this series: missing microinteractions and body language, relying on informal communication, having to alter behavioural patterns. This post will address those challenges, and others that are more specific to Agile projects. First and foremost, if you’re working on the client-side of an Agile transformation, it’s important to set expectations early in regards to time, progress and discipline—all of which require a bit extra from teams working remotely. Let’s talk strategy After remote interactions are in place, the transformation must be planned using much short interactions, and in smaller groups. A few general tips: Keep a clear and available online roadmap using Trello or JIRA Run weekly catch-ups with your sponsor to show evidence of progress. Design small experiments to be run in small groups, in short periods (think weeks, not months). Keep everyone involved in a single experiment connected using a group text chat or voice/video chat tools. Have a plan to broadcast progress to the whole department/company, with an emphasis on visual information. Be mindful of social factors, and ask for feedback about how the transformation is affecting daily work. Video logs can be a more personal and powerful tool to use here. Remote Coaching from point A to point B As a general rule, pilots should be reduced in number when working remotely. Remember, each experiment takes time and energy, so be mindful of how many you plan to run in parallel. After pilots, make sure you have the tools and communication methods in place to understand results, and bring people together for online discussions when necessary. When it’s time to roll out practices you learned during pilot experiments, take a gradual approach. Each new team must adhere to the steps followed by the pilot team until Agile is more firmly ingrained in the remote work culture. Remember, scaling in normal conditions is already a complex matter, so when you’re attempting to scale remotely, moderate your expectations in terms of time and difficulty. If you’re using Scrum, some structure will be in place that can be replicated remotely. From our experience at PALO IT, some simple planning and preparation by the Agile Coach or Scrum Master can often make coaching sessions much smoother. Long meetings tend to be ineffective in remote environments. It’s too easy to lose focus and lack interaction. Keep this in mind during coaching and sprint planning especially, and be sure to make user stories clear and visible using a task management tool.  For more complex concepts, use screen sharing with audio. You won’t have a physical whiteboard to draw on, so using virtual whiteboard tools can also be helpful. If you see your team starting to lose focus, you probably need to up the speed of the session, and encourage more interaction. Make sure everyone has an opportunity to speak. Those who are shy need to be catered to as well! When you reach a sprint retrospective, put everyone on the same video call, and collect feedback to prioritise the overall discussion. You’ll be facing a lack of visual components here, so again, using a virtual whiteboard or a specific online retrospective tool (eg: Scatterspoke, IdeaBoardz) can be extremely helpful. Retrospectives have a tendency to drag a bit in remote environments, and may take some time to progress, so make sure you’re providing your team with concrete information from the previous sprint. This sets the scene and drives the discussion. In that same vein, when it’s time to gather data, limit the number of items per participant. Nobody likes a monologue in this scenario. If you don't have access to a virtual whiteboard or online retrospective tool, you’re going to be responsible for collecting all information and organising it visually. One way to save time here is to ask your team to prepare their points, and send to you via private chat ahead of time. Sprint reviews can be a timekiller, as it's necessary to switch presenters once in a while. Be aware of this when scheduling. Remote voice/video calls with the Product Owner and the stakeholders are key here. Remember to keep reviews concise, laying out the points that will be discussed at the very beginning of the session. Stakeholders should also have access to your deployed application, making it easier for them to show examples, or explain their requests or doubts. For the daily scrum, voice/video calls are a must. Text updates are a big no-no. Monitor time spent by every team member, and share the task manager screen while people are speaking. This ensures everyone is aware of what task/story is on the docket. Prolonged silences can be common after each individual update, but there’s no need to lag, set a rule in place that each person indicates the next team member to speak after their turn.  Of all the sessions of a Scrum delivery team, backlog grooming is usually the hardest. People tend to diverge a lot when facilitation isn’t on par, or the item you’re grooming is still too raw. Large items can be extra-difficult as they might carry a lot of doubt, concern, and questions. To aid in this setting, establish agreements about when something is ready for grooming. What kind of information does your team want? Do they need the user story to be completely written? Work these questions out well beforehand. Also, set a timer for every item and make sure the team is well aware of the running clock. When time is up, let the team decide if they’d like to continue the discussion or not. Always stick to your timebox. If you haven’t yet, check out the rest of our series on remote work culture series: Part 1 — Tools of the trade Part 2 — Common pitfalls Part 3 — Let's get visible Part 4 — Routines and regimens Keep on the lookout for our upcoming whitepaper, coalescing our Agile experts’ thoughts and experiences.

Many of us are trying to find ways to adjust to what is now becoming our biggest work-from-home experiment. Whether your organisation has adopted a sweeping remote work policy, or you collaborate with global team members or clients who have done so, many now find themselves in a new, potentially confusing environment.  The circumstances surrounding the coronavirus, and its effects on teamwork, motivated us to dig a bit deeper into what works, and what doesn't, when 'work-from-home' is the new norm. Part four of this series is all about remote team routines and regimens. Breaking bad habits, forming good ones, and sticking to them. One good thing about working in an office is that you can build a solid schedule. For most, this helps to boost both focus and performance. Commuting every day, having a proper lunchtime, organising your own desk, or even dressing in your chosen work outfit to set the tone for your day. These rituals create boundaries that help us feel safe and confident in our work. But, they don’t have the same weight in a remote work culture, and some might find it difficult to keep an ‘office pace’ when they’re not physically among colleagues. What's your structure? Boundaries can go a long way when working from home. Structuring your day around a defined timetable can help your brain enter ‘the zone’.  Find a proper time to start work, to have lunch, and to end your day. Hold yourself accountable to that schedule. Treat messages just as you would were you in the office, and don’t slack off or wait too long to collaborate with teammates. On the other side of that coin, be wary of working during off-hours, when you’d usually spend time with friends and family. This doesn’t mean fully replicating your office work schedule. In fact, splitting time more strictly between different activities is often beneficial here. Perhaps you can use mornings for reading and responding to emails and messages, and afternoons to focus on high-priority projects and collaboration. When it comes to office space and attire, boundaries are important as well. Many find wearing their normal work outfit gets them in the same groove they’d otherwise be in in an office, and organising a dedicated part of their living space to serve as a work haven increases productivity. This isn’t universal. For some, pyjamas and a dining room table are fine! But for others, structure is quite crucial. Regardless, find a routine that works for you, and stick to it. Teambuilding As social creatures, it’s important that we interpret each other as more than commands and messages on a screen. When you’re in an office environment, a good team doesn’t only talk about work. Friendly chat is an important component of team cohesion. Without water cooler or coffee break talk, the habit of casually catching up with one another can often slip away. Managers—encourage small talk among team members, be leaders and make this commonplace by using remote tools. If you’re part of a shy group of individuals, take the initiative and open up to your team!  Calls shouldn’t always be status reports, they should also be conversations. It’s as simple as saying “what’s up?” but these efforts instil a sense of trust and safety across organisations in a remote environment. These bonds can also be strengthened by making individuals feel recognised in their work. When someone achieves stand-out results, make sure the whole team or organisation is well aware of this success. A team that achieves together, celebrates together, regardless of the environment. Be mindful that this appraisal doesn’t take shape as a “manager thing” or a “boss thing”, but rather a team-wide habit of showing appreciation to those who do their best. Practicing remote education Learning and teaching requires routine as well, and webinars are a good option for introducing knowledge remotely. You can use slides or digitise posters, but make sure to first reserve a time for interaction. Virtual boards and online tools like Google drawings are also an option when trying to run exercises or collect data. Training and workshops operate in a very specific way when all participants are co-located, but the challenge is quite different when in a remote environment. Keep interactive during these sessions. Ask questions. Start conversations rather than just speaking at length about a subject. This gets people out of their comfort zone, encourages participation, and eliminates the common pitfall of the passive audience. One final thought—it’s easy to lose focus when on a remote call. Interactions and games can help alleviate this issue, but what’s extra important is regulating the max amount of participants. This saves time, leads to productive discussions, and allows everyone to have their voice heard. If you haven’t yet, check out the rest of our series on remote work culture series: Part 1 — Tools of the trade Part 2 — Common pitfalls Part 3 — Let's get visible Part 5 — Agile Coaching

Many of us are trying to find ways to adjust to what is now becoming our biggest work-from-home experiment. Whether your organisation has adopted a sweeping remote work policy, or you collaborate with global team members or clients who have done so, many now find themselves in a new, potentially confusing environment.  The circumstances surrounding the coronavirus, and its effects on teamwork, motivated us to dig a bit deeper into what works, and what doesn't, when 'work from home' is the new norm. Part three of this series is all about visibility—being seen by your team, and having the ability to see others. Many view this as the most difficult obstacle to overcome when working remotely, but truthfully, it doesn’t have to be. Coordination is key Whether your work is specialised (very few can perform each task) or general (almost anyone can do it), when your team grows, so does the complexity of coordinating. Dealing with deadlines, timelines and priorities is especially challenging, and remote work can make this process even messier. For managers and leaders, this is a tall order. Imagine trying to understand what every team member is doing, aligning goals and alleviating struggles, all at once, with no one in the same room together. If you are working in the same location, you can simply walk over to someone’s desk and ask what they’re up to. Remotely, this isn’t an option, and eventually people will encounter frequent interruptions in their work, usually caused by long, unproductive status meetings. We talk a bit more about this in part 2 of this series. So what’s the quick fix?  Well, there are several tools at your disposal, but visual management is a concept that can be extra helpful here. Simply making information visible to your team leads to less effort and time spent coordinating, and less disturbance. Task management tools can organise work and give visibility in this way, leading to quick planning and even quicker reactions, and a good task management tool works using virtual boards. These simulate a physical canvas, and offer everyone the ability to indicate what they’re working on, and keep team members synchronised in terms of scheduling and status.  The defining quality of a good board is its flexibility. It should be split into sessions, columns or buckets that you can mould to your own workflow and team setup. This flexibility paves the way for a quick feedback loop. Trying different virtual boards is key, there’s no simple choice that will work for every team. But, if you work to find the right option you’ll find that information seems to magically become more accessible, and team cohesion improves. Cards (or tickets) can further increase visibility of work when using virtual boards. Every card represents a single unit of work, and provides concise information related to that work. A useful card should also have comment functionality. Having a broad view of these cards allows managers to better understand the overall capacity of their team. Rather than assuming how busy everyone is, the information is right out in the open. If work is accumulating in some particular place, or good or bad habits are forming, managers can take action quickly in response to these trends. Ultimately, relying on universally visible tools is going to boost responsibility and accountability. Assigning a task doesn’t need to be a difficult process just because teams are working remotely. When it comes to work loads, team members may not even have to ask for help, as everyone can visibly see when someone is overwhelmed with tasks. The result? Less pressure, higher morale, happier teams! If you haven’t yet, check out the rest of our series on remote work culture series: Part 1 — Tools of the trade Part 2 — Common pitfalls Part 4 — Routines and regimens Part 5 — Agile Coaching

Many of us are trying to find ways to adjust to what is now becoming our biggest work-from-home experiment. Whether your organisation has adopted a sweeping remote work policy, or you collaborate with global team members or clients who have done so, many now find themselves in a new, potentially confusing environment. The circumstances surrounding the coronavirus, and its effects on teamwork, motivated us to dig a bit deeper into what works, and what doesn't, when 'work from home' is the new norm. In part two of this series, we’re delving into the more common pitfalls faced when adopting a remote work culture. If you missed part one on tools of the trade, be sure to give it a read. Getting right to the point When you're moving into a remote work culture, you need to eliminate fluff, prioritise clarity and summarise concepts using bullet points. Big sentences are too bulky, confusing and don't sound like a conversation. Consider face-to-face dialogue—if you want to ask something or share an idea, you need to focus and be direct. Any other method of communication should strive for the same. Also, watch out when someone is taking too long to communicate using remote chats. He or she is probably trying to write what would better be communicated as a long-form email, and not participating in the conversation. Look out for the Godzilla email Emails are the most common mode of remote communication, and when people shift to remote work they tend to rely on them more than usual. Threads will be longer, heavier and less objective. One strategy to avoid this is to set rules for email use. For instance, you can use email to: share a summary of discussions (if you don't have a wiki in place), broadcast very specific information, and share files (if you don't have a file repository). You should avoid emails when you want to start a conversation or want to ask a question. For those purposes, a simple voice or video call, or private group chat gets the job done and in turn will boost team communication. The general rule here is, if you personally feel that a long email (or thread) would be more effective if replaced by a conversation, you’re probably right. Voice and video come first Non-verbal is an important part of all communication. Body language, facial expressions, tone of voice—all of this helps people to pass along a message, and the lack of it can lead to misunderstanding. That’s why voice or video are a must for complex or sensitive topics, and everyone should be able to join a voice or video chat when necessary. Sometimes the need for it is not obvious, but you can identify some signs, like overly-long chat conversations or back-and-forth emails that drag on for ages. Once you see this becoming routine, interrupt the flow, and put everyone involved on a call. Tools that can help in this endeavour include:   Video/Voice chat tools Google Hangouts, Skype, Zello (Voice only)  Team chat tools Slack, Microsoft Teams  Messaging tools Whatsapp, WeChat, Telegram Meetings...again!? Bad meeting planning is a problem in co-located workspaces, and in remote spaces it's even more damaging. When a team starts to work remotely, the first concern of most managers is "will they really be working, or just slacking off?" An undue reaction to this concern is to plan several check-ins, chats, status reports and the like to ensure work is being done. It’s important to keep in mind that every time someone’s workflow is disrupted, productivity and work quality suffer. Have you ever been right in the middle of a task that requires your utmost attention and energy, only to have someone break your concentration? Then you know how detrimental this can be. At the onset of remote work culture, meetings will happen, it’s only natural. But, you can improve their relevance and flow as time goes on. Anytime you hold a meeting, ask yourself a question: can we avoid doing this again? Suss out what kind of information you could gather in the moment to avoid disturbing colleagues again. Status report meetings in particular can be easily avoided by implementing a task manager. JIRA and Trello are both strong options. Large-scale meetings can be avoided by narrowing what needs to be discussed. Three or four smaller meetings with the right crowd are much more beneficial than one three-hour whale of a meeting where every person on the call tries to handle their business at once. While managers might view this as optimising time, for everyone else, it’s quite the opposite. It’s not necessary to include every person in every conversation. On the topic of inclusion, only hold meetings when you need everyone involved to be contributing to the conversation. If it’s just a dialogue between two people, or even a one-way message someone is trying to get across, there are better ways of approaching this communication. If there is one must-have for remote meetings, it’s a timebox, and—you guessed it—it should be short. Anything longer than an hour is ineffective. Also, make sure you include short breaks within that timebox. Finally, if you really need a long roster of people discussing something regularly, create a solid schedule so people can organise their days around the meeting. In this situation, remember that it’s nigh impossible to coordinate everyone’s availability.  The key here is finding a balance. Keeping get-togethers scarce enough that people value, or even look forward to the chat, while still keeping them frequent enough to optimise information flow. Simulating your office The best way to establish good remote communication is to simulate an environment where everyone is in the same room. In a physical workplace, if you need to have a quick chat with someone, you wouldn’t send an invite, you’d just walk over to your colleague and tap them on the shoulder. But this can get messy in a remote work culture. All the back-and-forth exchange required when scheduling a call can be gruelling. To avoid this, just pick up the phone, and call! If someone doesn’t answer, you can assume they were busy, and try again later. In the long run, this helps in team awareness, and leads to the prioritisation of voice and video calls. Again, if you’re in a physical workplace, you often overhear conversations, and join ad hoc discussions. Communication happens all the time, all around us, and it’s easy to take that for granted. Luckily, this can be simulated, more or less, in a remote environment thanks to open voice/video rooms. You can implement an open room by having a voice or video call that’s constantly online, where a specific group of people can connect during work hours. This way, anytime someone wants to talk to the group he or she can join the call and speak. Inside the room, people can also speak to each other whenever they want, without the need to schedule a call. If conversations get too extensive, individuals can disconnect, connect in a private call, and sort it out. Of course, each room member also needs to be aware of their surroundings (the mute button is key!) A team text omnichannel can mimic a physical environment as well. If all team communication starts there, more than one person can follow any conversation, even if they are not directly involved. The common pitfall here is letting the channel act as a disturbance. If conversations get too long or too specific, participants must migrate to a more private group chat, or join a voice/video call to deep-dive without disturbing someone who doesn't want that level of detail.  Implementing a remote work culture isn’t as huge of a leap as some make it out to be. Knowing the common pitfalls before jumping in head-first is half the battle. If you haven’t yet, check out the rest of our series on remote work culture series: Part 1 — Tools of the trade Part 3 — Let's get visible Part 4 — Routines and regimens Part 5 — Agile Coaching

Remote communication is much easier than it used to be, as most people have personal communication tools on their phones, and are used to being connected remotely with their friends and family. Even small events can be arranged remotely and asynchronously these days. So, performing tasks remotely is not something new, but if your client has decided to work remotely, it's necessary to clarify all challenges that come with this remote work. A couple points to note: Nothing will ever beat face-to-face communication. Nothing will ever beat co-located teams in terms of communication effectiveness. That being said, remote work culture can still bring immense value to the client. The following tips—and this blog series as a whole—are not an extensive and exhaustive list, but rather a strong baseline for you to expand upon.  Remote work tools Emails might be more comfortable for people who just started to work remotely, but they shouldn’t be the main source of communication for remote teams. In fact, in some cases they can damage information flow. Emails still have a role to play, but they must never be the go-to. Below is a list of tools that can help you to establish different communication channels that are essential in providing a stellar remote communication culture. Be mindful that although you might already know how to use most of these tools, teams that just jumped into remote work may have not have a clue! It's your job to help them transition. Working efficiently in a remote environment without most of these tools is nearly impossible, so it's necessary to build the setup before you start working remotely. These tools cover video, voice, text and whiteboards, and their absence will increase difficulty and affect the overall quality of communication.   Task management tools Trello, JIRA   Video/Voice chat tools Google Hangouts, Skype, Zello (Voice only)   Team chat tools Slack, Microsoft Teams  Messaging tools WhatsApp , WeChat, Telegram   File sharing tools Dropbox, Google Drive, One Drive   Cloud office suite tools Google Docs, Slides, Drawing, Spreadsheets, Office 365 Wiki information repository tools Confluence, Sharepoint All-in-one tools Basecamp, Notion Virtual whiteboard tools MIRO, Google Jamboard, Microsoft Whiteboard, Google Drawing Interactive meeting tools Mentimeter, Klaxoon Getting in touch with teams Communication can sometimes go awry. This scenario is even more common when you’re dealing with remote communication. When this is the case, it’s important to first consider the nature of communication. Synchronous communication - Co-located work communication tends to be synchronous. For example, when you need to talk to someone or ask them something, you can simply go to his/her desk. Once you do it, you either get immediate feedback, get what you needed, or acknowledge that the person was too busy to talk to you at the moment. The feedback loop is short. Asynchronous communication - Remote work communication tends to be asynchronous. In other words, you don't get immediate feedback about your question or request. The feedback loop is long. Usually, it’s an email you sent, or a voice message. So, what's the best type of communication? Well, the right question is rather, am I using the right type of communication? If you need to solve something with some urgency, synchronous communication is the best choice. Making voice/video platforms readily available is the best option here. If you need to talk to people about something that simply can't wait, just call them! If they are busy they will decline the call and call you later, and in this way you reduce your feedback loop. Synchronous communication can also happen with messengers and group chat platforms when the receiver is available, but sometimes these platforms don't properly cater to the urgency of this kind of communication. Synchronous communication, when not used in the right manner, can lead to interruption and disturbance in people's work. So tread lightly, and be aware of others. If you can wait for the information you need, you should use asynchronous communication. Group chat or messaging platforms are a good choice here. If you need something that can wait, just drop someone a message. The amount of information or message complexity is the defining factor here. If you are about to ask ten questions or write down a 50-paragraph message/email, you need to step back and think twice about what you’re trying to accomplish. In this case, you can use asynchronous communication (scheduling a call) to start synchronous communication flow (using the call to discuss the problem). Conversations are usually synchronous communication, so if you see an email thread that can be solved with a chat (text/video/voice), connect the individuals to speak to each other. Helpful tools (and categories of tools) in these instances include:    Video/Voice chat tools Google Hangouts, Skype, Zoom, Zello (Voice only)  Team chat tools Slack, Microsoft Teams  Messaging tools WhatsApp , WeChat, Telegram If you haven’t yet, check out the rest of our series on remote work culture series: Part 2 — Common pitfalls Part 3 — Let's get visible Part 4 — Routines and regimens Part 5 — Agile Coaching

Why great ingredients don’t always make a great cake. Your oven is the wrong temperature. If you’ve got a command-and-control person trying to facilitate the self-organisation of a cross-functional team, you’re going to be in for a bad time. You’re substituting ingredients. A self-organising team knows what skills and behaviours are needed to get its best outcomes. Ask the team what they’re missing, instead of assuming a specific role is required. Don’t compromise on your team’s needs by handing them ‘x-factor-perts’ or alternatives, unless you have strong supporting data as well as team acceptance that they can help. You’re adding extra ingredients. For teams trying to understand what each of them bring to the table and self-organise around what’s missing, having that conversation becomes nigh impossible when there’s more than 10 people in the batter — you’re going to end up with banter. It’s also really damaging when the conversation proves some roles/skills as unnecessary, so you’re better off starting with the bare minimum. You’re using the wrong sized tin. Match the skillset required, not a prescribed number or pattern of roles. Ask the team what they need to achieve their immediate outcomes, and bring in the fewest possible people required to deliver that. Repeat carefully over time — don’t overdeliver by throwing more people at a problem. You’re not using a reliable recipe. You’ve probably applied a framework, a set of roles, or a way of working that is completely inapplicable for the intent or the product of your team. Or maybe, you’ve applied to the letter a method that has shown little to no evidence of success for any other team! You’re opening the oven door too soon. Don’t deflate the cake! Let the team find their mojo. Don’t expect to see ground-breaking success in a few weeks — it takes that long just to get to know each other and figure out if the right people are in the room for the job at hand. You’re taking too long to put the cake in the oven. You’ve been whisking and beating and fluffing yourselves into a team for weeks, drafting up role descriptions, presenting proposals, sprint plans, proof of concepts and team structures, and getting approval from committees. The best way to find out if the right people are in the room is to give them the freedom to experiment with ways of working using real work, and by taking away the fear of being reprimanded. Facilitate team norming activities while they’re on the journey to ensure that skills and personalities are both right for the team. You’re not measuring your ingredients accurately. Don’t copy-paste metrics that worked for another team, and then shame yourselves for not being ‘as good’. Understand what progress means for your team, as it’s the only way for a team to find real opportunities of self-improvement. Do you want to measure and improve output, culture, speed of execution, team health? You can be brave and invent your own measures of progress; it doesn’t matter if no-one else has used “apples” as a metric. If you can define “apples” for your audience, and measure the growth of your orchard, then go for it! Your raising agents are out-of-date. Sadly, a lot of us don’t continuously engage in learning and self-development. While there are tried and tested ways of doing a lot of things, there is often an opportunity for something new or different to work even better. When there are different levels of curiosity or desire to grow within a team, that team is likely to coalesce into like-minded specialist blocks that in turn inhibits creativity and diversity of knowledge. You’re not following the method properly. If you’re going to use an existing recipe and the cake doesn’t look/taste quite right, you have to have followed the recipe exactly to be able to blame the recipe. I’m not a methodology cultist, but I do believe teams are rarely able to mimic ‘models’ in their entirety and therefore don’t always see the benefits their creators had. It’s unfortunate though that teams often blame the formula when things don’t go according to plan. Recognise the tweaks you’ve made, the environment your ingredients are in, and either address those opportunities directly by creating practices that work for you, or, go back to trying to follow the recipe by the book in order to understand if they really work, and more importantly, if they’ll really work for your team. Maybe you need a gluten-free recipe instead?

Tough times don't last, but tough companies do... Technology is changing everything about our everyday personal and working life at an exponential rate. Within the scope of our economy and business, many of these changes allow for greater opportunity and efficiency to be realised, but they also open the door for greater risks (e.g. cyber-security concerns, automation/disruption of entire industries, more competition entering the market, etc.) and on a scale we have not yet had to deal with. To maintain or improve competitive advantage in times such as these, companies are not only having to develop a greater level of resilience both in their approach to policy and risk mitigation, but also with respect to their human capital. To continue to thrive in the technological revolution, businesses must also be made up of teams with a high level of collective resilience. Resilience is defined as the ability to recover from or adjust easily to adversity or a sudden change in circumstance. Given this day and age now dictates such change is the new norm, companies now seek to hire a high proportion of highly resilient individuals, believing that if they put them on the same team, the company as a whole will also naturally be more resilient and in-turn more capable of overcoming obstacles, discovering innovation and embracing failure; as well as be more prepared to take on calculated risks to realise further growth, opportunity and overall competitive advantage. While this seems to make sense on the surface level, how we deal with adversity and change as individuals—as opposed to a collective—in a team environment, can be entirely different. To use the above school of thought in a sporting context, it would be like saying that we could put a team of accomplished athletes together, all from completely different disciplines, and expect that because they are all great athletes in their own right, that they would be able to win a gold medal in a sport they've never trained in together before. Gold might be a possible outcome if they had sufficient time to train in their new discipline, and as a team, but without this training opportunity even the supremely fit and highly skilled would be unlikely to succeed. So it would seem that having a team made up of highly resilient individuals doesn't necessarily mean your team will have the necessary wear-with-all to go the distance. Collective resilience forms when the tether of a team unit has been trialled and tested, only then can this skill become a learned behaviour, enabling a team to master the ability to operate under difficult or unexpected circumstances. So, how does a company go about building its 'collective resilience'? Resilience is like a muscle, it needs to be trained to grow in strength, skill, flexibility and endurance. Teams who have built a high level of collective resilience have most often been exposed to a number of situations together that, over time, have helped them successfully train this muscle. Businesses, however, don't necessarily need to expose their teams to 'do or die' situations for this muscle to have opportunity enough to be trained. The colour palette of circumstance requiring teams to face adversity or unexpected change has many shades, but in every scenario there are three key elements of shared experience which enable teams to thrive. Collective Ritual Without the right team culture, any challenge that comes along will be met with roadblocks, including: dissension, lack of accountability, miscommunication, distrust, panic, playing the blame game, bias, exclusion, secrecy, alienation toward leadership, etc. When these kinds of destructive team dynamics emerge in challenging situations, they have the ability to amplify any fractures that already exist in company culture and displace staff at an accelerated rate. This oftentimes leads to an exacerbation of the existing challenge, or additional fires that need to be addressed. Not ideal by any stretch of the imagination. This is why it is so important teams adopt ritual based activities as an everyday aspect of their work/life flow. Team rituals give a sense of purpose, value and meaning to its members, and are usually repeated enactments of a very specific type of engagement. Team members have accepted that this level of interaction will form part of their regular work/life flow, and more importantly, want to participate in it! Team rituals allow trust, open communication, collaboration and a sense of belonging—all crucial elements in a team with high collective resilience. A sure-fire way for you to know when you have created a ritual-based team culture is when your team starts referring to each other as "tight-knit" or "like a family." However, rituals don't happen by accident, and require concerted effort by all team members for them to be successful. Components of effective team rituals include: Buy-In - The best rituals are the ones that get the broadest buy-in from the team to participate. A ritual is only a ritual if team members feel that it is 100% their choice as to whether they engage or not. This strengthens the outcomes achieved with these activities, as the team is meeting because they want to be there, instead of have to. Involving your team in the planning of rituals is important, so you can be sure they are something the vast majority of the team actually want to take part in. Having a Trigger - What triggers the ritual? Was it a team milestone being achieved? A collective interest or passion shared by the group? A cause the team wants to support? Or perhaps it is simply a willingness by the team to come away from their desks together at an allotted time, for a specific purpose, to spend some time together. Team members will choose to engage differently dependant on the type of ritual so it is important there are a variety of reasons for them to get involved. Frequency - Making your team wait for the annual Christmas party to come around won't breed the desired culture. Create a number of rituals for different triggers, times, and purposes to ensure the team are given a variety of ways to interact. The frequency of these rituals should be set ahead of time. This gives way to a more sustained connection between members, as they plan to make time to engage with each other, learn how to engage as a team in various environments, and fosters a sense of trust. Knowing they can believe in this process provides additional layers of intrinsic and extrinsic motivation for team members. Particularly if the team is in the midst of facing a collective challenge, as it gives them a light at the end of the tunnel. This could take the form of monthly board game nights, monthly all-hands meeting, regular team lunches, fortnightly lean coffees, rock climbing...the world is your oyster! Servanthood - The best rituals are ones where the team takes turns in the planning and execution of rituals. The team's desire to pull together to make these rituals happen is one of the most important aspects of the bonding/trust dynamic that occurs during this process. Activities where team members are simply required to show up on time ordinarily have less buy-in than those where members have had to actively get involved in planning. Team members are also stretched out of their comfort zone in this process, as they are often required to do things outside of their professional skillset. Maybe one of your Full Stack Devs may need to do the baking for Lean Coffee, or perhaps a quieter team member will need to lead the awards ceremony. Members are also held accountable to come through for the whole group in these circumstances, so the entire team gets to witness the reliability, dependability, and multi-faceted nature of each and every colleague. 2. Collective Challenge Usually, teams faced with a challenge whom also have a strong ritual-based team culture will naturally gravitate away from counterproductive measures in dealing with a crisis, and instead approach the challenge collaboratively, focusing on each individual member's strengths. This in turn allows more collective resilience as a team. Teams, however, have no way of knowing just how strong their collective resilience really is until they have tried to jump over a few of these hurdles together. Sounds scary, but what's scarier is for teams to wait until a crisis hits to test out the strength of their resilience muscles. Instead of waiting around, seek out positive ways you can emulate challenges for your team. Hack-a-thons, sports teams, fitness challenges, and scenario-based team building activities are all good choices. Participating in these simulated experiences gives them a safe space to practice—where stakes are relatively low—making sound decisions and communicating as a team under pressure. It also clues the team in to one another's strengths and weaknesses, and allows for the opportunity to engage in rational, supportive responses; all of which are critical skills a team needs if and when the proverbial really does hit the fan. 3. Collective Sacrifice The definition of sacrifice is to give up (something valued) for the sake of other considerations. This is the final ingredient present in situations that allow collective resilience to thrive. Nothing pulls a group of people together like the experience of shared sacrifice—or suffering. It is well documented that many survivors of shared experiences involving sacrifice or suffering create lifelong bonds, and in those moments of hardship perform extraordinary feats of bravery, compassion and selflessness for one another. In many instances, these survivors were complete strangers beforehand. The depth of empathy, understanding and compassion experienced in these trying times bonds them in ways no other type of experience can. Whilst it is highly unlikely your team will face a life changing or traumatic event, they will face moments where the hours are long, the stakes are high, and they feel physical, emotional and mental fatigue. Sometimes, the sacrifices individuals have to make are unavoidable. But, if you're supported by a strong ritual-based team culture, more often than not your team will choose to face these challenges as they arise together, in spite of sacrifice. Teams will emerging stronger, more capable, more in-sync, more aligned, more empathetic, more confident and, yes, far more resilient. A couple take-home thoughts Every team, no matter their resilience level, is capable of generating a high level of 'collective resilience' if given the right developmental environment. If you welcome opportunities to connect with your team. If you engage in rituals that build trust, collaboration, open communication and belonging. If you approach each challenge as an opportunity to learn and grow, and view sacrifices made in these circumstances as a rite of passage—your team will arise stronger than ever, well-equipped to realise your company's full competitive advantage in these ever-changing times of technological change.

“Working software is the primary measure of progress”… so states one of the principles of the Agile Manifesto. This means that if you ain’t got no working software, you ain’t got no real progress. This mindset, at the very least, should be the conviction of agile teams. It stands in stark contrast to the traditional measure of progress by the activities completed in a project timeline. How would you know if the software is working? When it meets the various criteria that it is expected to fulfil. The way to ensure those criteria are met is via testing. It is first and foremost the developer’s responsibility to test his or her software to ensure it is working. This should not come as a surprise since it is not a new topic. This idea of developers testing is where things start to get interesting. Effort wise, there are essentially two ways to test: manual and automated approach. In this post, I would like to explore manual testing. Experientially from the past, I will have to admit that the most tempting approach for developers would be the manual testing approach (unless they have been test infected). This is especially true when one is under time pressure. With manual testing, I have the following advantages: - Focus on coding the functionality right from the get-go. I can save time by not figuring out how to test the code beforehand. - Do quick checks without spending time to write a unit or functional test code. How many quick checks, though, will depend on how confident I am of my code. - I do not need to learn how to use a test harness framework. - Avoid the pain of setting up, configuring, and updating the build environment in order for automated tests to run .. on both my development and build machine. I can still produce working software quickly and much faster than the automated testing approach. So as a developer, why wouldn’t I just test manually? The unseen slippery slope starts when I get comfortable using a manual testing approach. Among the many unrealistic precognition skills expected of the developer, a common one is to estimate the effort needed to deliver a certain functionality. Since I am already comfortable with manual testing, by default, the estimate given will be based on the development and manual testing effort needed. Therefore, for any given feature, the estimate will be development effort + manual testing effort. Except that the effort to retest the other features to ensure they are not broken is not accounted for. A couple of things will start to happen: 1. More bugs and issues will be discovered as time goes by since not all aspects of the software are retested upon every change 2. With point (1) left unchecked, the team will fail to deliver working software every iteration (or for the Scrum folks, potentially shippable product increment every Sprint ) 3. The teams spends more time fixing bugs and less time on new features 4. The team asks for more time 5. In the meantime, when estimates for a feature is requested, the estimates given continues to be the development effort + manual testing effort, further masking the unaccounted manual work required to retest other parts of the system. This gives a false view of progress since without retesting, we do not know how much of the software is actually working. Who then, is going to take up the slack of retesting other features? (A really bad strategy will be to add testers to the team, pass the bucket to them, and introduce testing iterations/sprints) Ideally, the effort estimation should be given along these lines: - Effort for the 1st feature: development effort + manual testing effort for 1st feature - Effort for 2nd feature: development effort + manual testing effort for 2nd feature + manual testing effort for 1st feature (to ensure nothing is broken) - Effort for 3rd feature : development effort + manual testing effort for 3rd feature + manual testing effort for 2nd feature + manual testing for 1st feature (for the same reason) - Effort for nth feature : development effort + manual testing effort for nth feature + manual testing effort n-1 feature + manual testing effort n-2 feature + … + to manual testing for 1st feature) This estimation is probably more realistic, though not necessarily easier for the project/product sponsor to swallow. Even with this approach, it is not without its own problems. Consider these issues: 1. In a development team setting, you may not be the one re-testing the feature that you developed. This is especially true if someone else is working on a related feature but may need to do a regression test on the feature you previously developed to ensure nothing is broken. It may take more effort for that person to retest your feature. Also, some scenarios that require testing may be left out (unless you documented the manual test steps, which I trust most developers would loathe) 2. In a best case scenario, the manual testing effort for each feature is constant. You will get a linear increase of effort required for manual testing. If the manual testing effort differs across features, you can be looking at an exponential increase of manual testing effort. If you start to feel that this is not a sustainable strategy, you are right. 3. This effort given is based on estimation. What happens if development effort overshoots? Will the manual testing time be reduced? If there is more than one feature that needs to be tested, will those get compromised as well? (we know the answer to this, but let’s keep quiet to prevent embarrassment) In conclusion, what seems to be a good idea (with good intention) of delivering working software quickly using manual testing can easily degenerate into a drag. Would we still have working software? Nope. How, then, is the progress? None. Manual testing sounded like a good idea, except now it isn’t anymore. If only we have started differently.. .. and then we move on to another project and repeat the same approach.

This blog post is inspired by Barry Overeem’s whitepaper — The 8 Stances of a Scrum Master. After reading Barry’s personal experiences, I had an epiphany about the different stances of the Scrum Master role and I realised that I could relate it with my own Scrum journey. While strolling down memory lane, I reflected on one of the most important aspects of experience — continuous learning. As a Scrum Master, I have always maintained the importance of learning and experimenting. This belief has not only pushed me to improve, but also helped my teams to learn and grow alongside me. What it means to adopt the stance of a student: 1. Drop your Knowledge Ego (“We come nearest to the great when we are great in humility” — Rabindranath Tagore): You may have read every book on Scrum available on this planet, but may still learn something new from someone who experiments more often at work. I was an aggressive reader during my initial years as a Scrum master, and read quite a lot of books and articles during that time. It gave me a false sense of mastery resulting in an “I KNOW EVERYTHING” attitude. Fortunately, I decided to enrol myself for Professional Scrum Master training where I had the opportunity to get rid of my ego. I went with an intention to validate my knowledge and came out learning so much more about Scrum. (P.S. The biggest takeaway from the training was the importance of upholding the values behind the framework.) 2. Curiosity (“I have no special talents. I am only passionately curious.” — Albert Einstein): The experience that we have should not stop us from being curious. On the contrary, it should promote curiosity to enrich our overall development. As a Scrum Master, I came across numerous occasions where I provided a direct solution to my teams based on my past experiences. This made me feel very happy and proud. However, I soon realised that I was paralysing my own team by depriving them of the opportunity to be creative and exploratory while crafting a solution that best fits their situation. I was not only hindering my team’s growth, but my own as well. After this realisation, I created a system around this “solution habit” which enables me to ask why (to myself and to my team) before jumping into solutions. This new “Why” system has been quite effective in keeping me inquisitive. 3. Questions (“The Greatest gift is not being afraid to ask the questions” — Ruby Dee): Even though we read a lot of books, articles or blogs during our lifetimes, how often do we question ourselves while reading or after reading? This include questions like “How does this relate to my situation?”, “Will this help in my current situation?” or “How different is my situation?”. These are some of the exploratory questions we must ask ourselves in order to relate and learn something new. We can experiment with this at our workplace. After all, most of us don’t ask a question thinking “I may sound STUPID”. The best way to refrain from being called stupid is to be upfront, and ask the question for clarity and validation. 4. Keep Sharing (“With great knowledge comes the greater responsibility to share it”): Sharing is an important part to learn and grow. Our understanding of anything is only as good as our capability to share and teach. This does not mean we must always block people’s calendar involuntarily and speak for hours on a topic which may not interest them at all. It can be as small as a discussion with your mentor over tea/coffee or even a lunch with a set agenda for the people who may be interested. If nothing works, then write an article/blog. This will help you improve your skills as a writer and validate your knowledge at the same time.

In early September, PALO IT participated in Startup Weekend Singapore 2019 as a way of giving back to the community, as well as to lend our support to all aspiring entrepreneurs in our ecosystem. This was also aligned to our value of “We Share, it’s in our DNA” where we believe in the power of collaboration and leading by influence. In this short recap, our Managing Director Vincent Desclaux and Design Lead Vini Mota shares about their interesting experiences as SWSG mentors in this pioneering hackathon celebrating innovation. Tell us more about your capacity as mentors in SWSG. We mentored 5 teams in total, each with varying ideas and fields of expertise including Travel, Security, and F&B. Each session lasted about 30 minutes, with most of the time spent on providing them with feedback, new perspectives, potential pitfalls, and pitch adjustments.  As most of them concentrated heavily on their ideas and solutions, there were many times where we had to refocus their attention back to the question of “Why?” and help them reflect on their problem statements. We achieved this by sharing our experiences with similar products. What were some of the most-asked questions and what advice did you give them? 1. How can I validate my idea and do people really need this? Some ideas were more complex to test and prototype than others. We recommended the teams to do their market research first. We also realised that some teams postulated solutions to problems that don’t exist or only exist because of a personal experience or need, so we tried to challenge them in a way to protect them from making mistakes as the cost to make such an idea happen might be unreasonable. 2. How do I make my product / idea unique? Some teams were struggling to differentiate their product from existing products in the market. However, this was not a problem as long as their ideas maintained a fair competitive advantage. We kept challenging them with basic questions like “what” and “why” of the product, stimulating them to reposition their value proposition and finally find a sustainable competitive advantage. 3. What is the best way to pitch our idea to the judges? Pitching their ideas to the judge was one of the most challenging parts of their journey, and the common recommendation from our side revolved around how to present and engage the audience. We advised teams regarding simplification of the overall idea, addressing the problem that they were trying to solve, and providing context to a viable solution that their product was supposed to offer. What were some of the challenges you faced during the mentoring sessions? We had to jump from one concept to another every half hour. It was context switching at its peak! We also only had a limited time to try to maximise the help and insights we were giving, while ensuring each member of the team had an opportunity to speak to prevent one from imposing his/her ideas on to the rest. Afterword Building strong innovation capabilities and solving problems through transformative concepts is what we do on a daily basis with more than 15 major clients. We have a team of experts that leverage design thinking, agile methodologies, and lean startup to translate any problem statement into a digital experience.

In recent years, Latin America has developed a strong entrepreneurial culture, and has become the perfect arena for innovators. Startups, SMEs and MNCs alike are in tough competition to dominate the market. These businesses are not only in a battle for market share, but also for talent. Today more than ever, it is critical for organisations to transform their business, open themselves to innovation, launch new products and services, automate, adapt and prepare their culture for the future. Mexico, for one, is a fast-growing region for startups. We’ve seen the emergence of dozens of new players, from crypto wallet (i.e Bitso), fintechs (i.e. Konfio, Albo, Vexi, Klar Kiwi, Flick), to the entrance of big players like Amazon (and unorthodox ones like Rappi) into the financial market. Exciting for sure! This niche is full of innovators, but that being said, entrepreneurs may be focusing too exclusively on financial services, and ignoring other big opportunities. The laundry list of future goals New, disruptive technologies are going to be key in sustaining profitability over the next decade. It’s been said before, but it’s worth reiterating that developments like AI, IoT, Blockchain, quantum computing, 3D printing, and virtual reality are now commonplace, and the synergy of these new technologies are already proliferating.  Depending on whether your business is innovating or not, these new developments could be seen as either an opportunity or a risk... In Latin America, there are still many businesses who are not prepared for this scale of technological change. They have heaps of data, but lack governance, and in many respects rely on manual operation. Moreover (and perhaps most importantly) their company culture is not built for accelerating innovation. Companies might adopt new tech, sure, but as long as their teams don’t have the resources and/or strategy to innovate they won’t come out on the right side of this battle. So, what’s the way forward? It’s easy to say “let’s innovate!” but much more difficult to start this practice in reality. Enter service design, DevOps, big data & API governance and Agile transformation. These practices/methodologies are key in moving companies to greener pastures.  DevOps in particular might sit front and centre. DevOps transformation is an enlightening experience, as it serves as a learning journey for organisations to root out dated mindsets and misguided practices in software delivery. We’ve touched on innovation tools, as well as strategy, but there’s something missing from this equation...what’s the purpose of our creations? Making the jump towards positive impact The emergence of new technologies offers an opportunity to create better solutions for the greatest global challenges of our generation. Take 3D printing for example—with it, digital manufacturing is precise, less wasteful and delivered immediately. In some years, manufacturing will be on demand, and everyday people will be able to build any object, regardless of its complexity. Thanks to affordability, soon, millions of new people will be able to create and innovate. But who will prevail on the business side? Our humble prediction: business models that will make waves in the future are those that address global issues—poverty, education, food safety, water, climate change, energy, security and health. (As a side note, if you're interested in reading more on the subject of technological automation, check out Gerd Leonhard’s work, Technology Vs. Humanity: The Coming Clash Between Man and Machine) As food for thought, consider the ability of Blockchain to fight corruption, IoT to enhance public security, AI to fight climate change, and bioengineering to guarantee clean water and healthy protein. Make no mistake, technology has always had the inherent capability to be used for good, but today more than ever, our developments are actually powerful enough to solve major, global issues. We’ve covered a lot of ground here, and if one thing is apparent, it’s that Latin America is cooking up change. The utensils for this change? New technologies. Our kitchen? New process methodologies and re-evaluated business culture. The secret ingredient? Purpose. The main course?  Human prosperity.

A man bursts into the board room, he’s three hours late to the meeting, and scrambling to present what he’s been working tirelessly on—a pitch for ecommerce transformation. The presentation goes well enough, but before walking out the door, the man doubles back to the board of directors. His take-home message? “I don’t think your company is asking the right questions...” When it comes to high-stakes project pitches, the word unorthodox comes to mind. Let me ask you, is this the image of an individual you’d have heading a multinational company a decade later? On this, the tenth anniversary of PALO IT, the answer is a resounding “yes!” But in 2009, Stanislas Bocquet was chasing a vision that, while concrete in his mind, had yet to take shape in the world. “A lot of companies, especially at that time, weren’t asking the right questions. They didn’t need a quick solution, they needed something larger, an omni-channel strategy,” says Stanislas. The story of PALO IT has many perspectives, and you’d be remiss put its history on the back of any one person, but Stanislas’ story is, at the very least, one worth hearing out, and at the most, a microcosm for everything that makes PALO IT what it is today. Beginnings After backpacking through South America in the late 90’s, Stanislas found his calling at his first startup. The company was grappling with a technology that was riding the crest of the Internet wave, but would later explode onto the scene—live-streaming content. After selling the company in 2001 (fun fact: it’s still in existence today), Stanislas took his talents to an investment fund, managing startups that were part of a portfolio mostly dealing with mobile Internet. The work allowed him to come in contact with dozens of entrepreneurs who had all their chips in technology, and decision makers from a variety of backgrounds deploying an even greater variety of management styles. Leafing through a magazine in 2002, Stanislas stumbled upon an interview with the founder of a company called Valtech describing his new vision for business culture. Something clicked then. “It was a moment of clarity” says Stanislas, “I thought ‘this is exactly what I’ve been thinking’, this is how a business should be run.” Soon after, he joined Valtech to focus on business development. While ecstatic to be on board with a company who shared his values, it wasn’t all peaches and cream, as anyone who worked in technology in the early 00’s will tell you. The dot-com bubble burst, and companies started disappearing Avengers Snap-style. There were two great lessons during this period: first, it’s important to have an international footprint, a business spread across multiple locations and markets (not having all your eggs in one basket, so to speak); second, it’s important to be flexible enough to quickly adapt your value proposal. The market may have been in a freefall, but there was still a lot of long-term potential. These years ended up being quite fruitful for companies that played their cards right, but there were rumblings of something new on the horizon. “I spent a lot of time speaking to people my parents age during that time, people in their 50’s,” explains Stanislas, “I realised that many of them had been laid off because they’d become redundant or too costly to retain. If they still had work, they were unhappy with it, they didn’t really enjoy what they were doing later in life.” “Something needed to change in the way business was being run…” Making the leap When it came to industry, the path forward for Stanislas was clear right from the start, “In the tech industry, there was no need to stress about the future. There was so much to do, so much happening, and we were still just at the beginning of this massive transformation.” As far as culture, he wanted a business built on independence and power, where individuals felt inspired to act, not just follow. One night Stanislas took a list of 130 CIOs and key decision makers from major IT companies and emailed each and every one. While initially expecting a lack of feedback, within 24 hours more than 20 of those individuals wanted to speak to Stanislas about his concept, and over the next five months, he met with over 60 of them personally. The response gave him both a wealth of insight (which formed the backbone of PALO IT’s reliance on a continuous, democratic feedback loop) and the confidence he needed to put everything he had behind his work. And by everything, I mean everything. Stanislas sold his flat and his car to finance his project. Large-scale ambition needs large-scale funding—that reality became apparent very quickly, and after some back-and-forth he partnered with Synchrone Technology for additional funding. The company firmly settled on the pillars of Agile, open source, and a strong internal team. Sounds familiar, but the offer looked quite different back then, exclusively targeting large MNCs. As anyone in the startup game will tell you, there are always initial growing pains. The first 12-15 months of business were slow, to say the least. Contacts were made, people were interested, but deals were left in limbo. That takes us back to the thunderstruck boardroom, and the bold-faced message of “asking the right questions...” After eight months of deliberation, the company Stanislas pitched to finally decided to get on board. Things moved fast. Within one week a team of six was recruited to run a project on open source ecommerce technology and Agile methodology, and voila, PALO IT was born. Growing into who we are today The project opened the floodgates, with more and more clients signing on. Soon after, open source guru Francois Zaninotto, and business development extraordinaire Frédéric Bernaroyat joined, they’re still with PALO IT today. Mélanie Bacrot also joined as the company’s first recruiter and HR manager in Paris. From 2009-2011 the team grew to 80, and in 2012, the company officially changed its name to PALO IT to better reflect the brand’s identity and values. ‘PALO’ inspired by the massive amount of innovation and growth going on in Palo Alto and Silicon Valley, and ‘IT’ acting as a double meaning for information technology and innovation transformation. At a chance meeting with an old friend of Stanislas’, Tanguy Fournier Le Ray, the two got to talking about the market climate in Singapore. Fast-forward to 2014 and PALO IT has opened its first office in Singapore. Current CIO Cédric Mainguy, and Head of Digital Technology François De Serres, made the jump from Paris to Singapore to help expand. Hong Kong opened its doors in 2014, with Agile Coach Sophie Pagé joining as the office’s first hire. Sophie is still with the team today as well. Around this time the business separated from Synchrone to allow the company to fully embrace an organisational model that fits the culture Stanislas initially sought to inspire, “We’ve continuously grown every year, 30 - 40 percent organic growth annually, and we’ve grown in our thought process as well,” explains Stanislas. That growth continued in Mexico, as Julien Rousselet and Guillaume d'Herbemont kicked business off in 2016. Meanwhile, Frédéric pioneered the Bangkok office in 2017, bringing the company to Thailand. The list goes on, with each country’s success spurred on by a team of passionate individuals who were willing to take risks to build PALO IT into what it is now. All the while, the business has also undergone a different kind of evolution, one that’s become increasingly crucial and relevant in the 21st century—working towards the greater good. The values that work as the cornerstone of PALO IT spurred every office in this direction, eventually resulting in designation as a Happy at Work company in 2018 and a B Corp organisation in 2019. Accolades aside, this key element in PALO IT’s identity will only grow as the years go by. Onwards and upwards Ten years have flown by, but a lot of Stanislas’ experiences—and the whole team’s experiences for that matter—have set the tone for the last decade. Namely, great ideas might be born in bubbles, but they don’t expand there. You don’t build a company like PALO IT without continuous feedback. You listen to your customers, listen to your clients, listen to the market, and listen to your team. “I’m very proud of where we are today,” says Stanislas, “To see that all our international offices are aligned in terms of vision, strategy, business model, everything. This is very rare. I’ve had a long journey, but you don’t see this type of cohesion within an organisation often, and I think that shows just how strong our company culture is.” He goes on, “Now PALO IT is larger than me, larger than individuals, its own entity, and everyone within the company owns a piece of our success. What we have now is an incredible tool to build out our own path to concretely impact the world in a positive way. We all own that tool, and that responsibility."

In the fast-paced society we‘re living in, it’s very common to experience stress, anxiety or tension. Multi-tasking, mind-wandering, and always focusing on what’s “next” makes us become less aware about how we feel in our mind, body and spirit. How do we take the time to pause and maintain focus? Mindfulness is an essential super life skill that builds mental resilience and reduce stress levels so that we can lead happier and healthier lives in the present moment. Cultivating Mindfulness enhances all your other skills, whether at home, work, travelling or even when you’re just spending time with your friends and family. So why not start applying it? According to the Mindful Nation UK Report, Mindfulness means “Paying attention to what’s happening in the present moment in the mind, body and external environment, with an attitude of curiosity and kindness”. Research has shown that we spend 47% of our time Mind-wandering (Resource: Killingsworth, 2010; Mindful Leadership Institute, 2010). How much impact does this have on our self-awareness, performance, leadership, and most importantly, our happiness? Mindfulness is about becoming aware of our state of mind, body, emotions, and spirit; becoming aware about our mind-wandering and bringing our attention back, while creating calmness and clarity. This is also known as cultivating meta-attention: “The attention of attention, the ability to know your attention has wandered”(Resource: Search Inside Yourself Program, 2019). In my work as an Agile Coach, Facilitator, and Yoga Teacher, I facilitate Mindfulness practices at PALO IT and for our clients. I often work with tech teams and individuals under immense pressure to deliver digital products on time, who constantly spend their days behind their screens focusing on finishing their work as fast as they can while maintaining consistency and quality. In addition to that, they also have to spend time on their other projects, as well as on learning and development activities. Don’t you think that our racing, busy minds deserve a peaceful moment of calmness and clarity, like a mini holiday throughout our days? The beauty of Mindfulness is that it can be cultivated and applied anytime, anywhere. It does not matter if you are behind your desk at work, walking outside to grab lunch, or waiting for a new meeting to start. Mindfulness practices don’t have to take much time or effort, but are highly effective and bring many benefits to our state of mind. Therefore, I would like to share a few micro Mindfulness practices that I facilitate for my clients and colleagues which you could practice too. Mindfulness practices are accessible for anyone regardless of age, background, gender or experience. I would like to invite you to practice these micro practices and experience the benefits for yourself. 1. A Minute to Arrive or Depart: How many of us have back-to-back meetings or rush from one meeting to another where context switching is important? Many of us multitask throughout the day and look ahead to what’s coming next instead of focusing on the present moment. To be able to “slow down”, pause, take a breath, and re-focus before a next activity starts, the practice “A Minute to Arrive or Depart” is extremely helpful. In workshops and trainings that I facilitate, I often start and end with a guided “Minute to Arrive” (at the start of a session) or “A Minute to Depart” (at the end of a session) for participants. I facilitate it as a guided Mindfulness practice, but you can also do it individually, without any “voice-over” guidance. These are the steps: - Sit up straight on your chair with your feet grounded next to each other on the floor. - Make sure you have a bit of free space around you (e.g. push yourself slightly away from your table or move your chair to an open space). - Lengthen your spine, place your palms on your knees facing up towards the ceiling. - Relax your shoulders, relax your neck, soften your facial muscles and slowly close your eyes to take this moment as a “Minute to Arrive”. - Become aware of your breath — how does your breath feel in this present moment? Take a deep breath into your nostrils (chest expands) and take a deep breath out through your nostrils (chest falls). - Continue to breathe through your nostrils at your own pace, while making your inhalations and exhalations deeper and deeper. - Bring your attention to your body and observe your body: How does your body feel in this present moment? If you feel any tension points or stress in your body, shift the focus of your breath to those tension points and continue to breathe deeply. Feel how your body starts to relax through your breath. - Bring your attention to your mind and observe your mind: How does your mind feel in this present moment? You may have some personal thoughts or work-related thoughts. Happy thoughts, frustrated thoughts, or even angry thoughts. Whatever thoughts you have wandering through your mind, just acknowledge them — they are okay. Just let them float by like clouds in the sky. Continue to breathe deeply. - Bring your attention to your heart: What is your intention for today? For the next activity you are about to start? For the meeting you are entering? For the deadline you are facing? Set an intention for yourself. Reset your focus and continue to breathe deeply. - Slowly bring the palms of your hands together and start rubbing them together, creating energy and warmth in between your palms. Once you feel the warmth, slowly open them and cover your face with your palms momentarily (keeping your eyes closed), bringing back the positive, warm energy back to your body. You can massage your face gently with your fingertips. - Slowly open your eyes, roll your shoulders back, and rotate your neck and head. - Maintain your deep breath throughout the day. Take pauses and focus again on your breath at any time you experience stress, anxiety or pressure. - You are ready to kick-start your day, meeting or work! Facilitating a Guided Mindfulness Practice “A Minute to Arrive” during PALO IT’s B Corp Celebration Event in June 2019 in Singapore. Participants experiencing the Guided Mindfulness Practice “A Minute to Arrive” during PALO IT’s B Corp Celebration Event in June 2019 in Singapore. 2. Gratitude Journaling: Being grateful towards people, things, and events in your life is a very fulfilling and effective way to strengthen your emotional resilience, reduce stress, and experience happiness and positive emotions. Maintaining a Gratitude Journal helps you focus on the positive things in your life, while also reaping the benefits of journaling, writing your thoughts, and “clearing the clouds” in your mind. These are the steps: - Choose a notebook/journal and a pen you love or feel personally attached to, and nominate them as your Gratitude Journal and Pen. - Select a timing during the day which is convenient for you to write in your Gratitude Journal (e.g. before starting on your work, during your lunch break or at the end of your day). - Write a minimum of three items that you are grateful for each day. You can be as creative as you want; gratitude can be found in many ways! (e.g. the help you received from your colleague, a problem you solved at work or the mindful walk you took during your break.) - Repeat this exercise daily for a minimum of 7 days. On day 8, take a moment to pause, take a few deep breaths, and look back at your Gratitude Journal and read what you wrote down during the past 7 days. Reflect on your appreciations and gratitudes: Which emotions do you feel? Do you see any patterns in the items that you wrote? Become aware of how this practice makes you feel. 3. Appreciation Sharing: Remember that whatever you are grateful for or appreciate in your life, at work or at home does not need to be saved for the Gratitude Journal. Share them openly with your team mates, boss, friends, and family, and tell them how much you appreciate them, what you are grateful for, and experience how that makes you feel! Everyone likes to know that they are appreciated and their positive reactions can give you a positive energy boost too. It’s great for team-building and camaraderie too, especially if you want to become aware and be mindful of the power of teamwork! An easy and quick way to apply this at work is to start a team meeting (e.g. retrospective) with a 5–10 minutes Appreciation Sharing circle where teammates can share their appreciation with each other in a fun and lively way, verbally or through Kudo cards. In order to reap the benefits of these micro practices, I would like to invite you to continue cultivating these beautiful Mindfulness practices in the cadence and pace that works for you. It’s not about the duration of each practice, but the concept of repeating it often (frequency) and making it a habit, even if it’s just for a few minutes daily. And last but not least, be sure to share your experiences on your Mindfulness practices with others so that others can reap the benefits too. Just like a mini-holiday, Mindfulness is a gift to yourself and others, so remember to pass it along! Facilitating a Guided Mindfulness Practice “A Minute to Depart” during a Regional Conference in July 2019 in Bangkok for one of Asia’s leading general insurers. Participants experiencing the Guided Mindfulness Practice “A Minute to Depart” during a Regional Conference in July 2019 in Bangkok for one of Asia’s leading general insurers.

As an increasing amount of technological advances are made every day, it’s becoming more apparent that many jobs are in danger of being replaced by automation. How then, do we best prepare ourselves for this radical change and future-proof our careers? To educate myself on this outwardly complex subject, I recently had the opportunity to attend an insightful panel discussion with our Head of Digital Technology, Sean Burke-Gaffney, who spoke about the challenges many of us are facing or will soon face, while expounding some of the solutions that could be used to ameliorate the problems of tomorrow. Many of us are looking at Artificial Intelligence with sceptical lenses, while others are very excited about the opportunities it can unlock. Which camp are you in? I’m definitely in the camp of the optimistic. Not only am I optimistic but I am also hopeful. If you look at the history of civilisation and cultural history of this region, you will see many examples of revolutionary change and in spite of this — perhaps even because of this — people have managed to adapt; all societies do this and need to continue doing so. I think it’s incumbent upon us all to try and get ahead of any potentially negative effects of this transitional period in which advanced technology becomes mainstream. Yet I’m hugely excited. I think we, our children, and their children are going to have opportunities that were unimaginable 20, 30 years ago. We will be given opportunities to improve ourselves and our world, and this will be enabled by technology. If we are looking ahead to the future, what kind of core skills do we need to develop? Firstly, people need to be trained to understand how programming or code is implemented and how machines work. This does not mean everyone must be a programmer or a coder. In the same way we understand about cars, you don’t need to know how an internal combustion engine works, but you do need to know how to drive one. Secondly, there are some soft skills that need to be nurtured. One of them is how to co-exist with advanced computing machines. Cooperation with these machines is going to be required in order for us to successfully navigate the changes that advanced technology like AI will bring to us. You can’t be fearful of advanced machines and ostracise them. If we do that, we will find that it is us who are actually ostracised and miss the benefits that technology can bestow. We need to embrace AI and advanced robotics, and integrate them properly into our culture and our lives. Finally, I want to make a point about education, which has many aspects but I think an important one is that educational institutions must teach our young people differently. Education should be appraised from a new perspective. We need quickly to imagine how we educate people who have already passed through traditional learning streams, and show them how to reinvent their careers and facilitate the formation of new skills and new orientations. Speaking of education, is the classic school system that we have today still going to work in 20, 30 years? I believe that a classical education should always remain critical; physics, chemistry, mathematics, literature, language, and sociology are foundations of a learning mind. People also need to have a general arts background. In technology, we often talk about teaching people to be T-Shaped; that is to know a lot about one thing and only a little about generalities. At PALO IT, I try to encourage people to be Y-Shaped; that is to know a fair amount about a few things, a little about many things and then have some deep expertise on one or two things. This period of advanced technological change tends to be worrisome and even stressful for people, so another key attitude we need to inculcate in our children now is the acceptance of impermanence or ambiguity. What I mean by this is that it is now the norm that your focus today will not be your focus tomorrow, and this is okay. Not only does that need to be okay, we also need to be people to be nimble-minded to accept and take advantage of massive change. I can’t begin to guess what our education system will be teaching years from now, but I can confidently predict that it will be assisted by AI. Likewise, how can we best prepare for this career challenge? I have always lived by a mantra and I preach this mantra to the people I work with: Go with your passion. Trust your heart and it will always guide you to the right place; use your head to keep you focused and in movement. If you find yourself dissatisfied with the skills that you have or are in a position where you think your job has reached a dead end, look for something that excites you and then vigorously pursue the learning opportunities around it. Opening doors lead to opening doors. Secondly, the notion of lifelong learning is one that I have espoused both personally and professionally. It is my belief that if you are not constantly learning things, then you become static and that’s the career kiss of death. That being said, most people underestimate the pace of change and don’t take the opportunities offered to them until they really need them. How can we address this? It’s a job for the leaders among us to impress on people the need to avail themselves of opportunity. At PALO IT, we’re pretty vocal about encouraging people to educate themselves. What I find is that many don’t feel like they have the time. We need to talk about making time and taking time, and less about the training itself. I look at leadership as the place where this activity begins. Afterword There’s an interesting story that I would like to tell about technology change. It involves something we all use without thinking every day — ice. In the very early days we had Ice 1.0. It was only available in the northern hemisphere where the weather was always cold and to the people who lived near rivers (and not the ocean). It could not be made as it could only be harvested, and storing or transporting it required a particular set of skills, tools and machines unique to these communities. Next we had Ice 2.0. The invention of refrigeration as a technology made ice available to people in areas where it was warm. As a technology, it was quite large in scale. We had vast warehouses where ice was made and this gave rise to a new kind of job — the iceman. He travelled in a wagon filled with huge blocks of ice and carried these blocks of ice to people’s homes who then kept them in a new invention called an icebox, which allowed us to keep our food stored for longer periods. Now we have Ice 3.0 — enabled by the invention of the portable refrigerator. With miniaturisation, optimised refrigeration methods, and a connection to indoor plumbing sometime later, we now think nothing of having ice cubes coming out of our fridge automatically. Now think about the kinds of jobs that have existed and disappeared, have arisen and disappeared again, and arisen anew only to begin disappearing yet again all around a simple commodity like ice. This is a metaphor for how we should treat the coming of AI.

I was recently invited to be a part of a panel to share my thoughts on how aspiring techies could build a career in tech and what such a career would entail. The discussion was very engaging and I learned a lot about the different motivations that could encourage such a transition. Because of my role in PALO IT, I work with multiple clients and teammates who are just getting started with their careers in the tech industry, and I thought I would share a little insight into what I’ve learned in hopes of helping aspiring techies. They Are Called Fundamentals For A Reason I have come across team members who became good at a specific tool or framework after going through training and working with it for a while. While this is great, they may lack an understanding of some fundamental concepts, and I would like to take this opportunity to urge everyone to go deeper and always understand the fundamentals behind the tool or framework. It would not only make your knowledge and experience transferable across various platforms, but also make you more confident in your skills. These would include programming fundamentals, infrastructure elements, testing techniques, release management, and even software development lifecycle. Master A Specific Skill Each one of us is different. Some people prefer to be subject matter experts, while others prefer to be a jack of all trades and master of none. In my opinion, focusing on a specific area, be it development, operations, or security earlier on in your career would give you a strong core expertise. Generally, you can master a specific skill by working in an area for a couple of years. It does not require working with the same set of tools and applications but rather a specific function. For example, although a developer may be using multiple programming languages, he or she is essentially still getting better at programming with each step. Last but not least, and this may only be relevant if you are a consultant (which is my background), you may not always have the opportunity to work within a specific area for a long time. I would encourage you to explore how you can work on a certain skill set while working on various projects. There are excellent technical training resources available online for specific skills. They generally provide a great way to pick up skills at your own pace in easy-to-consume formats. Coupled with hands-on experience, they might be all you need to become an expert. Deliver Value To Your Customers Based on your role at work, you may have many internal and external users or customers. They are the reason you design and build the applications you do now. It is very important to recognise who these people are and if they derive value out of your work, and changing the way you do things if that might not be the case. Being aware of the problems that you are solving also tends to be a very good motivator to do even better. Keep Learning This might be the biggest cliche in a ‘career in tech’ blog post but for good reason, one cannot stress the importance of continuous learning. Technology is ever-changing at an increasingly fast pace so it is absolutely vital for everyone in the industry to keep learning. Here are some of my recommendations: Keep going back to the basics In my experience, reviewing the basics of a technique or an approach would generally trigger a completely new set of insights that would be immensely helpful in your current context, so I would recommend making it a habit to go back to the basics on a regular basis to see how you could be better at what you do. Cross-learn Cross-learning is applicable within technology as well. That is not to say that if you are a developer, you should take up painting (which by the way, is something that you should totally do if it is of your interest or helps you keep your sanity). Instead, if you are a system administrator, pick up coding or vice versa — a developer with a keen sense of infrastructure would not just be a valuable asset for a team — they would become a better developer. You should be learning more about development, operations, architecture, data, and security, and putting your newfound knowledge into practice. Be in the know If you are willing to invest some time, it is really easy to keep abreast about where the industry is headed, the challenges ahead, and what the hot-button topics everyone is talking about. It could be as simple as subscribing to some tech blogs, and following someone on Twitter or LinkedIn. Meetups, conferences and hackathons are also other great ways to get a deeper understanding of a specific topic, platform, or tool. Keep experimenting & innovating I have always understood concepts or frameworks by using them and may have been guilty of testing certain things in an environment where they might not be the best fit. I wouldn’t advise trying things which might jeopardise your current projects (very rare) so I would suggest applying different principles to your current problems and trying new tools that may solve specific problems in your overall solution. Through experimentation, we learn and innovate. Be creative with your solutions and if you fail, learn from that experience and be better next time. Find A Mentor Someone who has overcame the challenges you are currently facing and can offer their experience to guide you through your journey is very important. They might be someone you work with or have worked with in the past and have your best interests at heart. A mentor would provide technical guidance, serve as a career coach, and help you with any work-related or personal challenges that you might have. They could also leverage on their network and influence to find specific opportunities for you. I believe the role of a mentor is always important, but it is even more vital at the beginning or in the earlier stages of your career. That being said, it is obviously very important for your mentor to have your best interests at heart and for you to trust them. In certain cases, specifically when it comes to difficult conversations related to work, it might be easier to have a mentor outside your current organisation. Don’t shy away from asking someone you look up to to play this role. People are generally open to helping others and you could always give something back to them for their time and guidance, such as feedback or even a nice meal. Improve Your Soft Skills Skills like communication, empathy, consciousness, and working well with others are keys for success in a tech career. Ensure that you are improving your interpersonal communication, effectiveness, and leadership skills as they would play a significant role in ensuring success in your career. Due to the possible disruption posed by artificial intelligence and machine learning, they are even more relevant. Network Build strong bonds with the people you work with and actively network and maintain relationships with others. Helping out someone by providing feedback or connecting them to someone else who could be of immense value can help strengthen your bond. When the situation arises, your network would serve as a great support mechanism. Share As A Way To Learn Recognising the need to learn at a faster pace, a lot of organisations have embraced “shared learning” and have espoused many initiatives like brown-bag lunches, sharing sessions, and even mini-hackathons. Whatever form they might come in, I would encourage you to be a part of these and share your knowledge whenever you find a topic of interest. You will not only learn a new topic or technique, but also get to hone your public speaking skills and get some very valuable feedback while doing so. Company lunches could be a safe space to get started and build your confidence along the way. Coach Your Team And Organisation Transformation efforts typically require a cultural and mindset shift across the organisation. In my experience, it could be a very engaging experience to help an organisation through such a change. Technical coaches are needed to help tech teams improve the quality of products they are working on. If you would eventually like to have a bigger impact through coaching teams, I would urge you to start doing this within your team and eventually move on to your whole organisation. Take Charge, It’s Your Career In conclusion, I would suggest being conscious of your strengths, mastering a key area, developing experience in other areas, and continually learning. With the help of your mentor, drive your career forward and if at times that means having a hard conversation with someone, have it sooner rather than later. I hope that self-awareness gives you the confidence you need and this post serves as a blueprint for success in your career. Most importantly, remember that you are the author of your own story.

What do you do to be productive? In the past year, I’ve been using different tools and strategies to help me focus more and thus, be more productive at work. In this article, I’ll share with you three of these productivity hacks to increase your focus and delve into the science behind why they work. Noises When I was still writing code, I would listen to different music playlists ranging from rock to electronic, electro-pop, and pop. Sometimes though, when I had to solve a more complicated problem, I would shut the music off. I never really stopped to ask myself why that was — I just did it. What was it about music that made writing code easier? And what about those times when I needed silence? These days, I’m mostly reading or writing, and I’ve found that listening to music is a big distraction (I imagine classical music would be a good choice, though). So I found an alternative to fill the void: Noisli. Noisli does exactly what its name suggests — play different types of noises to you. It comes with a variety of sounds such as the rustling of leaves, singing of birds, ocean waves, and the ambience of a coffee shop. What I found that works best for me is the combination of three options together: wind, rain, and thunder. When I put these on, I can focus better than when I’m not listening to anything or the regular noises at my office. I also work really well in cafes. The sounds of cafes somehow stays at the back of my mind and do not distract me for most of the time. Why this works There is a ton of research out there on the different types of noises and how they affect concentration levels. Most of us are familiar with the term ‘white noise’ and have a decent idea of what it means. While doing research for this article, I realised that I didn’t know exactly what it meant and also found the existence of other types of noises, like brown and pink noises. In summary, white noise is the mix of all frequency of sounds distributed equally. Pink noise, on the other hand, is louder at low frequency and softer at high frequency. Brown noise is similar to pink noise, but stronger at low frequency and absent at high frequency, giving it a distinct muffled sound. To get a sense of what they actually sound like, check out their pure representations at the Simply Noise website. So what sound is better for doing focused work? As with everything, it seems that the best answer is: It depends. However, there is a lot of research that shows that the best environment for focused, productive work is actually the absence of sound. That’s right, silence is the best strategy. If you want to give silence a go and don’t have an obvious option, try visiting your local library. Unfortunately, nowadays, other than in the library, silence is a rare occurrence. From open-concept offices to noisy cafes, it’s hard to find a place where silence is the norm. Research shows that you can use a different colour of sounds for different environments, as well as classical, or other types of non-intrusive music styles to improve focus in a noisy environment. Bursts of Focused Work: The Pomodoro Technique Another hack that I like to use for productivity is the Pomodoro technique. If you don’t know what that is, it’s actually quite simple: Commit to a focused time free of distractions for 25 minutes, then rest for 5 minutes; repeat. I found this nice app that implements this technique in the form of planting trees, called Forest. The planting of each tree takes 25 minutes. When you are successful in not opening any other app for the duration of the 25-minute session, you will get a full tree. But if you try to open a messaging app before you finish planting one, the tree will die. And you don’t want your tree to die, do you? You can also see all successfully and unsuccessfully planted trees of your forest and sort them by day, week, month, or year. According to the app, I’m not doing this too well. But I’ve found out that I’m better at planting trees when I disable all my messaging apps’ notifications just before I start to plant a tree. This is the third technique I’ve found helpful to remain focused and I’ll cover it below. Why this works The Pomodoro technique is based on a time management technique to increase your ability to maintain concentrated attention over prolonged periods of time. This is what psychologists call Vigilance or Sustained Concentration. The technique is grounded by the simple idea to commit to a short burst of concentration, and then taking a break from that intense mind-work. The idea of taking frequent breaks to improve productivity is based on a lot of science. Working on short bursts followed by taking breaks, or even napshave been shown to improve productivity. On the other hand, too much of a good thing is not that good. Too many breaks may imply that you are procrastinating and avoiding a difficult problem. Reducing distractions: Disabling notifications I noticed that I unconsciously check my phone for messages every few minutes - a habit I only noticed after I started using the Pomodoro technique. I noticed that I would unlock my screen to look at notifications sometimes in the same minute! I installed a phone-usage app to show how much I use my phone (a flawed metric, but illuminating nonetheless). As shown below, there are days when I unlock my phone more than 200 times! Why this works It’s no secret that apps nowadays are being built to get us hooked. That’s why more and more apps make use of notifications to bring us back to their platforms. However, even though checking a notification may take less than a minute, one research shows that it can take up to 23 minutes to get back into the original flow. And if you consider that on average we touch our phones more than 2000 times a day, we have the potential of being 40% more productive every day by being more mindful about how we use our technology in our hands. Taking back control of your time For me, the combination of these three techniques/tools - Noisli, Pomodoro/Forest app, and disabling my phone’s notifications has been really helpful to improve my focus. As a matter of fact, I’m using all these three techniques right now as I’m writing this article. So if you are looking for a few ideas to improve productivity, try these out and let us know.

Can chemicals play a role in our workplace? If we were to pose this question to the employees of a bank, or maybe even a tech company, their response would probably be: NO! To some extent, this answer is correct as we don’t see any test-tubes being used in our office. Unknowing to most, a few chemicals do in fact, play a vital role in every workplace. This is not quite evident as these chemical changes happen in our bodies rather than in a laboratory. Let me introduce you to our “happy” chemicals: Oxytocin: More commonly known as the love hormone or the cuddle hormone. This chemical helps you build trust and form strong relationships. It is not very difficult to get this common chemical flowing within us. You can significantly improve the Oxytocin levels in your team by replacing distant ‘hello’ waves with handshakes, and further improve it by replacing greetings with hugs (Ensure the hug is in consent with the other person or else you may be reported to the HR team for inappropriate behaviour. Also, you don’t want to be known as the creepy hug guy in the team). When a team is committing to a mission, provide them with an environment and encourage them to put their hands together at the end. This helps with the circulation of Oxytocin. Oxytocin is very selfless in nature, so you can stimulate the flow of this chemical by praising people in front of someone else, or by simply taking the time to ask “How are you?” Serotonin: This particular chemical gets triggered when we feel important or significant. We can increase the flow of this chemical just by sharing a meal with a team member. This chemical starts to flow when we remember what we have achieved in our past, so it is a good idea to reflect on our team’s accomplishments every now and then to receive a healthy supply of this chemical (which to me is an unbelievable deal). The deficiency of Serotonin may result in depression. Endorphins: Endorphins flow in order to produce relief from pain or to produce a feeling of well-being, which in turn, also reduces anxiety. This is a common occurrence with runners - they receive a burst of this chemical and will feel happy after an exhaustive run. As tempting as it might be, we simply can’t ask people to run around their workplace every time they feel stressed. Instead of running, we can create and promote an environment that generates happiness through laughter. This includes watching something fun together, encouraging people to share funny stories, messages and emails with each other, listening to a great song together, or going for a short walk out in the sun. We can also help them co-create and align themselves with the purpose behind their work, and revisit it time and time again. Lastly, we can change the format of meetings so that they can become more engaging and eventful instead of dull and monotonous, and organise charity initiatives such as blood or book donation drives. All of these activities help to boost the flow of endorphins within us and make us feel happy, especially during stressful times. Dopamine: Dopamine is closely associated with inspiration and recognition. This chemical helps us move towards our goals, and gives us a sense of happiness and satisfaction while achieving them. Since this is the chemical that helps us take action towards our goals, the onus is on us not to set very long term goals for ourselves. If we create goals that span over a very long time, we may run into dopamine deficiency. A recommended practice is to break down your bigger goal into smaller goals and celebrate when you successfully achieve something. This ensures the continuous flow of dopamine in your team. In my experience, I have seen amazing positive changes in team dynamics just by replacing distant waves to high-fives, taking coffee breaks with the whole team to discuss non-work stuff, and going for lunches or dinners together as a team at least once a week. Teams gradually improve on their awesomeness scale when these chemicals are in action. As time goes by, they become more accountable, reliable, trusting, proud, transparent, and fun to work with. Additionally, the improved trust levels result in improved understanding and amazing collaboration. So what’s your team’s daily dose of happiness?

Getting the opportunity to travel for work is a privilege that not many get to enjoy, lest moving to another country to experience a working life. I sat down with a few colleagues who have had the great opportunity to work from the various offices that we are based in, around the world, to get a peek into what their experiences have been like. Mention Sydney and the first thing that comes to my mind is Bondi Beach or the many coffee joints that have popped up over the years. The capital city of New South Wales, Sydney, best known for its picturesque harbourfront overlooking the Sydney Harbour Bridge and Sydney Opera House, is home to many exciting tech companies and startups looking to be the next Airbnb and Uber. This week, I sat down with Guillaume Teillet, a Software Engineer at PALO IT Singapore, who had experienced a short stint at our Sydney office. Hey Guillaume, could you share how you got the opportunity to work in our Sydney office? In 2017, I went to the company retreat in Bangkok and Tanguy, our Regional Managing Director, gave a speech about the Internal Mobility Program in PALO IT. A few weeks later, during my annual review, I expressed interest to Jessica, our Chief Happiness Officer, and told her that I was interested to apply for the Internal Mobility program offered by PALO IT. It was very timely at that point in time as our Australia office was just established and I have never been to Australia. I thought it was the perfect opportunity for me to explore the city and I discussed with Tanguy about the possibility of joining the team for a short project. Within a few months from our conversation, Tanguy got back to me and I joined our Australia office for three months, right after our company’s retreat to Bali in 2018. During my time in Sydney, I joined a team of 6 people (3 developers, 1 Agile Coach, 1 Product Owner and 1 Business Analyst) on an innovative trigger-based insurance project. We developed a web application in React that allows customers and the insurance company create customised insurance products. We built the backend with C# .NET and deployed the project on Azure. This project was a great opportunity for me to improve my skills in Microsoft technologies. PALO IT Australia is an intimate team of 15 people. The office is located in a co-working space called Tank Stream Labs and for this project, we were working from there. In the co-working space, each company would have its own dedicated space while sharing the common facilities (meeting rooms, pantry, pool table etc.). It’s always nice to be able to share a coffee or a drink with individuals from other companies and exchange ideas on the way we work. We’ve heard a lot about the work culture in Sydney. Could you share more with us? “No worries mate!” would best summarise the Australian mindset at work! The work culture in Sydney is so different compared to what I have experienced before — in Sydney, the work-life balance is very good and I feel that people are relatively more relaxed at work. It was amazing to be able to mix work and team moments, just around a cup of coffee or a pool game! More importantly, how did you look into maximising your stay there? What did you do over the weekends? Over the weekends, I took the opportunity to discover the rich Australian culture through visiting food festivals and attending operas in the world-famous Sydney Opera House. I used the time I had to discover the countryside as well — I did a road trip with my girlfriend and my sister, travelling from Airlie Beach to Cairns. We even took a plane to fly over the Great Barrier Reef, observed kangaroos in the wild and flew over the city center. We also managed to witness the fireworks at the Sydney Opera House on New Year’s Eve! During the Christmas break, I also took a flight to New Caledonia, a French territory three hours away from Sydney. I had never thought about visiting New Caledonia before because it is a very isolated island in the Pacific. Being only a few hours away, I told myself I could not miss this opportunity! The overall experience I had there was amazing. I will not want to trade it for anything else! What stood out the most for you? On the professional side of things, I really learned a lot about new tools and the technologies from Microsoft. I would like to take this opportunity to thank my colleagues, Alex and Sang, for being great team players and mentors. On the personal side, the beautiful landscape and the diverse culture of the country stood out the most for me! Australia is a wonderful place in the world and it was amazing to be able to discover their work ethics and culture. The three months were definitely too short to be able to discover every part of Australia. I definitely need to go back as there is so much more that I have yet to discover! Would you go back again, if given the opportunity? YES! YES! YES! Definitely! In fact, I am already in the talks to see if there are other opportunities for me to experience working from the other offices or going back to Australia. It was definitely a fantastic experience and I cannot emphasise how beneficial this internal mobility program has been for me. I enjoyed my time in Australia and the Sydney team was very welcoming. It was a real pleasure to work with all of them! Aside from reminiscing the good times in Sydney, I could clearly tell what stood out for Guillaume were the fun times he had “working” with the colleagues in our Sydney office. I mean, doesn’t this picture say it all? I nodded and smiled as I spoke to him about his experience, but really, deep down inside I was jealous. Perhaps, I’ll take the opportunity to walk over to HR right now and express my interest to do the same. We shall see! Internal Mobility Program PALO IT’s Internal Mobility Program was set up to allow our employees to work from the many offices we are based in, ranging from a few weeks to a few months. This program hopes to provide a dynamic working experience within PALO IT, where its employees grow holistically and are able to experience the diverse culture and work environment the company has to offer.

The title of this article might throw you. How, after all, can an Agile team have a ‘funk’, or a bad smell? To explain this, I have to walk you through an analogy I ran into while reading the book The Power of Habit by Charles Duhigg. Today, Febreze is a household name for our air-freshening needs. Little known, however, is the fact their product was on the brink of failure despite being “a breath of fresh air.” When Procter & Gamble came up with Febreze, they expected their product to fly off the shelf. Instead, sales dwindled. People who needed Febreze most did not realise the strong odour in their house. For example, when marketers visited a woman with nine cats in her living room, they realised she had grown used to the foul odour and did not notice the smell at all. People who have become accustomed to bad odour in their living environment will often get used to the smell and ignore it. Similarly, in an organisation that prides itself on running Agile, bad practices that everyone has become accustomed to can often be ignored. This situation is more than often  indicative of deeper problems. Let’s explore a few different Agile ‘smells’ and how you can Febreze them out of your organisation. 1. Silence is not golden Organisations, no matter how big or small, encounter breakdowns in communication. It might seem intuitive to tell your team to speak up, but that’s easier said than done. Creeping scope, unclear user stories and delayed deliveries are caused by a lack of communication. If your team members don’t talk to each other regularly each day, it’s time to start sniffing around for the underlying problem, and there’s no better way to discover issues and blockers than face-to-face conversations. Your organisation can foster collaboration by allowing team members to work in proximity to each other. For a global team, they should use portals like Slack and Google Hangouts to foster communication. It’s also essential to hold a standup meeting every day. A 15-minute, face-to-face meeting lets the team sync for the iteration and communicate any impediments that could block development and delivery. To ensure the meeting is fruitful, the information being shared should be measured in quality, not quantity. 2. Leaving users out of the equation Unlike a traditional waterfall process, an Agile team should strive to shorten the feedback loop to its users. Startups and SMEs often lack the resources and time to reach out to users, combined with a lack of communication between both parties, the product is in danger of not responding to the needs of users. Users are your most important stakeholders, their opinions can help the organisation frame and validate your vision for features and functionality. You can analyse the most popular requests submitted by users and use it to groom the product backlog. By talking to users, you can obtain important data and trends that are crucial to product development. You should check this feedback loop every iteration so you don’t build a product that doesn’t meet user needs. 3. Playing the blame game If you are new to developing a product or software it can be a baptism by fire. Time and time again, when you release new software, complaints from clients will come flooding in. Imagine waking up one day, you smell burning fumes, you walk to your kitchen and discover a piece of burnt toast in the toaster. You naturally wonder who is responsible for making your kitchen smell like a barbecue. As survival instinct kicks in, we often shift blame to others. It’s very typical for people inside an organisation to start pointing fingers—most likely at the development and the QA team. This blame game is very destructive to team morale, which in turn hinders future product development. To combat this, we have to be honest with each other. An organisation should not seek to single out any members of the team. As a team, it’s essential to understand that the team either succeeds or fails together—teams should seek to make rational decisions together as a cohesive unit. 4. Fearing failure People usually want to avoid a failed project because it’s considered detrimental to their career. As a result, fewer people take the risk of starting a project that might not succeed. Management might also rashly set up an insurmountable amount of hurdles for the team to overcome, so much that they end up catching themselves in a ‘paralysis by analysis’ situation, where every idea needs to get signed off before execution. Even if people are taking risks, they take the lowest amount to ensure they won’t fail. In this video, you can see SpaceX made plenty of mistakes before creating a functional orbital rocket booster. We often dislike the idea of failure, as we fear we might lose valuable resources and time. This might be true if you are managing a factory that requires consistent performance in a pre-defined set of standards. However, if we apply that in an ever-evolving business, the idea of avoiding failure can strangle the innovation of an organisation as a whole. Don’t play it safe, learn to let go and embrace failure. The culture of experimentation is very crucial to an organisation. Your product might not currently boast every feature you’d like it to, but if you never take it to market, you’ll be in the dark in terms of user feedback and unable to build the best possible iteration in the long-term. 5. Dealing with drill sergeants Management wants to see results: a rise in revenue and profit, an ever-growing user base and brand awareness amongst the public. When growth stalls, management often falls into panic mode, “what are we doing wrong?” In a time of crisis and panic, management often falls for the fallacy “great leaders don’t tell you what to do, they show how it’s done.” Leading by example is crucial, but this top-down approach can cause teams to become indifferent. It also suffocates their spirit of innovation. In Agile, leadership is not only about barking orders, but also lending a pair of ears to any suggestions coming your way. As servant-leaders, management should make sure employees understand the vision, starting with the "why", and let the teams define the "how”. In Agile organisations, management should guide teams with questions. Questions such as “What do you recommend?” are very useful to inspire teams. According to David J. Snowden and Mary E. Boone, executives at one shoe manufacturer once opened up the brainstorming process for new shoe styles to the entire company. As a result, a security guard submitted a design for a shoe that became one of their best sellers. It’s essential to trust the talent in your organisation.You never know who will come up with the next groundbreaking idea. So, slow down and smell the roses. Appreciate your team’s talent and embrace change when it drifts your way. Maybe then you’ll be able to sniff out the deeper issues in your Agile team.

Can you sense the drop in ENERGY, when the retrospectives become boring? This article is based on one of the experimental retrospectives that I have facilitated using Rory’s Story cubes and Liberating Structures by Henri Lipmanowicz and Keith McCandless. Sprint Retrospective is a very important event in Scrum as this is one of the most crucial feedback loops for the entire system. I consider it as the heart of the Scrum ecosystem as this is where you would formally get an opportunity to meet and talk about improvements around your ways of working and agreements that bind the entire process together. To be a Scrum master is like being a thermostat. We must recognize the drop in engagement and participation levels of teams and adjust the course to improve the overall experience. Every team goes through an inevitable drop in energy over a period of time. When you feel the energy drop in the retrospectives, then one of the highly engaging and energetic ways to do retrospectives is by using the Story cubes. Story cubes are considered as children’s toys, but they possess the ability to connect with people on a visual-spatial intellectual level. How to conduct a ‘Story Cube Retrospection’: Although there are a lot of ways out there, I have personalised it a bit. Things you may need: Whiteboard Markers 9 cubes from the Story cube set. Sticky notes for “1–2–4-All”. Request people to stand for this activity. Preparation: Create Three columns on the board i.e. Happy, Sad, Action. Let the team roll the dices and pick them up one at a time. Every dice will have an image on the surface, let the team members talk about the experience from sprint which comes to their mind while looking at the image. Make a note on either the happy list or sad list. Repeat this activity for all the 9 dices. Now against each happy or sad item, get the team to dot vote what they want to pick up to improve on the next sprint (Recommendation is to pick just one or maximum two, depending on your timebox). Now, for every item that is selected, run a “1–2–4-All” session. 2. How to run a 1–2–4-All session: Let the team members brainstorm over the topic individually and make notes on a sticky note — Timebox — 1 minute. Repeat the same activity in pairs (exchange the ideas in a brief manner) — Timebox — 2 minutes. Repeat the same activity in quartets (exchange the ideas in a brief manner) — Timebox — 4 minutes. Repeat the same activity with the entire group sharing and noting the most suitable solutions around the topic — Timebox — 5 mins. Note: You can customize the repetition based on your group size. Once you have run the 1–2–4-All for the selected item, you will have solid actionable items derived by the team to conclude the sprint retrospective. I have facilitated quite a lot of retrospectives as a Scrum practitioner and from my understanding, one of the best ways to conduct retrospectives is to keep changing the way you run it. On average, I recommend trying a new way every three sprints, which gives the team a sense of familiarity while at the same time, enabling them to learn new creative ways to do retrospectives. Happy Retrospection!! P.S Thank you Nagesh for including me in the Liberating Structure user group Bangalore.

Enterprise mobile apps have moved from ‘nice to have’ to ‘mission critical’ tools for many organisations in the recent times. A recent study has found that demand for custom apps that allows employees to be more productive is on the rise. However, the process of deploying a mobile app for an enterprise is not only hard to navigate, but also taxing on the finances. "Organisations spend countless hours and a fortune working on the design, user experience, development, testing, infrastructure and finally training; only to realise that the seeds of the apps have sprouted weeds instead of fruits — and by this, I mean ‘low adoption’." ‘Adoption’ is the word that haunts most of the organisations when it comes to enterprise apps. As a product owner myself, after our product went live; with the roll out plan heavy on internal marketing (right from marketing videos, posters, surveys and town-hall meetings to other engagement activities) and dedicated trainings (pit stops, classroom trainings, refresher trainings and tutorial videos), I waited patiently to see the fruits of the effort the team had put in. I’ll be honest — at first, I was definitely not disappointed. The increasing adoption rate was really satisfying to see. But soon enough I realised that the beautiful graph of adoption was what we can call a ‘Typical Adoption’. To give you a background, we had tried to follow almost all the best practices available for creating the good enterprise app. ‘Involve ends users upfront’ — check, ‘quick and multiple feedback loops’ — check, we even worked hard to get our internal marketing and training tactics right. As you get the point — I was pretty puzzled on why the adoption was taking a hit. So with a mind full of questions, I got down to do some industry research on adoption of enterprise apps. So I decided to charge and chart out a strategy to analyse and fix the 'typical adoption' problem for enterprise apps. Step 1 - Analytics - Measuring the results Everyone needs analytics. When it comes to adoption of mobile apps, analytics should be the basis of every decision taken — right from strategic to tactical. "Trying to improve adoption rate is like changing wheels of a moving car so that the car runs faster, and analytics would help you point out which wheels to change." The metrics you would want to measure would differ based on the type of app you are dealing with. Holistically, there are two categories of apps — engagement driven and transaction driven. For our case in point, we would consider that the app is transaction driven. Primarily, we need to look at two main buckets of data — performance and usage (no brainer). However, getting the data categorised as per metrics is only the start. After we have the data in place, comes the herculean task — making sense of the data! And the best way to do this, as per what I did, is through segmentation approach. The first level is to identify the ‘Repeating customers’ versus the ‘One time customers’. You’ll be able to get this information via the retention and churn data. The reason why it is of utmost importance to get these two segments right is because you’ll have to analyse and handle these two segments in a very different manner. For repeating customers, you want to know why they came back to use your app, and for one time users — why then they didn’t. The next step is to look for patterns within the segments. In my case, I was able to identify specific personas using the demographic information of the users and team structure. Step 2 - Asking the Users - Survey & Interviews In our case, gathering feedback is like killing two birds with one stone. First, it would give us actionable insights which would help us on our quest for higher adoption, and secondly talking to the users and taking their feedback makes them feel that you care enough to consider their views. This will increase the feeling of ownership and could win you with some internal advocates of the app. We need different sets of information from the personas identified, and hence the best way is to design different short surveys based on the personas. The survey should not be very long and the user should be able to complete in 1 to 3 minutes. Any longer and you might lose their attention. Surveys should be designed keeping in mind the potential problems users might be facing. This would streamline the thought process of the users and help you gather structured data rather than haphazard feedback with no actionable insights. Once you have the survey data, analyse the responses to identify the top users who gave clear and useful feedback. These are the users with whom you want to discuss more and pick their brains for insights. Set up interviews (ideal length  –  30 minutes) and gather detailed feedback. Step 3 - Identify the problem Now that you have all the data you need, it’s time for the moment of truth. This is where you map your findings, look for patterns and deduce potential reasons for the low adoption. From my experience, there are 4 potential reasons why enterprise mobile apps fail. 1. Users ear disruption of existing processes Change management is hard. People don't like changes - unless something is really broken. While this may be one of the hardest issue to solve, it is definitely possible. Here are some suggestions to ease out the transition - Communicate the benefits of the change clearly. This should be the core theme of your internal marketing. Have a robust support initiative. The end users should never feel stranded with a pile of issues with the new system. Use the top-down approach. A subtle push and guidance from management will reinforce the trust of the end users in your product. 2. Users don't feel confident enough to use new technology for important processes. (Fear of screwing up) Considering everything you do is related to technology in some way or the other, you would probably not face this problem. But my project has a very specific segment of users who weren’t comfortable using tablet devices. They preferred paper over a tablet, and that was one of the culprits. So here are some of the approaches we took to mitigate the issue – One on one training sessions with the users. Users from this segment don’t usually come out and ask questions in group trainings (due to the fear of feeling stupid), leaving them with unanswered questions and hence leading to low or no adoption. Tip  –  include role plays during the training. I would be repeating myself, but there is no replacement for a good support initiative. Make sure you are always reachable and in their radar. 3. (The most dreaded one) Priorities of the users versus value proposition "Fun fact — end users do not have spare time. So if your product demands them to spend time which doesn’t result in time saved down the line, it is very unlikely that they would keep using the tool. Thus, leading to the downward spiral in adoption rates." While your product may still have a strong value proposition, that might not be what your end users are looking for. In most cases, this issue should not happen if you have done your UX study right. But sometimes the processes are so complex (specially in financial institutions), that a digital clone of a manual process may end up being more taxing for the users. While there might be way to coax your users to adopt your product even in this situation, I would recommend the hard way – going back to the drawing board. 4. Users aren't aware of the capabilities of the product. Alas, while we thought we had a failsafe training plan in place  –  we realised many of our users weren’t aware of what all they can do with the app. However, this issue is relatively easy to solve. Here are some tips on how you can do it better – Opt for short videos which the users can refer to at their own time. Make a FAQ page for the app on the internet. If your company has already jumped in the chat bot bandwagon – that is also a good idea.

Throughout the years, many people have learnt to implement agile but are still struggling with how to run big transformation programs. Many big organisations take initiatives building a central team of coaches for transforming the whole organisation into agile, but there are some mistakes that should be avoided. While working with big organisations as a member of an agile transformation team, I have learnt some anti-patterns that I am going to elaborate in this article. This is the first article in the series to cover mainly seven anti-patterns: One size fits all. Too long preparation time All at once Ignorance of supporting environment Ignorance of technical practices Vendor management and distribute team excuses Agile as a delivery engine In this article I am explaining the first anti-pattern: One size fits all Each product is different from another in terms of complexity, team structure and vendor association. How then, do standardisation of tools and practices work? This is one of the most common anti-patterns of agile transformation programs. Many organisations try to standardise agile practices, tools, and behaviours. In my experience, I have seen people recommending, or worse, forcing teams to use enterprise-level best practices or tools. There is no best-practice, because the best practice does not leave a room for improvement; which is against the agile principle of continuous improvement. Secondly, recommending standard practices defeats the purpose of flexibility in agile, which was the original reason of not making agile frameworks prescriptive. For instance, there are many big organisations that write their own agile methodology and prescribe all the practices, tools and how to implement them. Also, they call it “<company name> + Agile Methodology”. Often this appears to be a compromised version of agile. Similarly, organisations choose one standard agile tool for all teams without knowing if it would be comfortable and suitable for teams. The most common pattern is using one electronic tool for all teams that use Kanban. However, there are better tools available to serve the purpose. For example, recommending Atlassian Jira in the whole organization can lead problems for kanban teams. Instead, they might use Swift Kanban or Trello which are a better fit for Kanban. The more alarming situation is when the teams are co-located and can use physical boards, but are forced to use the electronic tool because it is a recommended standard enterprise level tool. Why is Standardisation Harmful? As every human being is different and forcing them to behave, talk and work in the same way can be counter-productive. Having a standard agile methodology in every situation proves to be harmful. I have seen support teams struggle with fixed iterations, novice teams struggle with a continuous flow of work and support functions struggle with writing user stories. Hence, standardisation only leads to frustration in people and compromise in business benefits. It mostly happens when people focus more on practices rather than on values and principles. Moreover, not having trust on teams for experimentation and not letting them choose their own suitable way of working can harm productivity. Custom Fit  As you might be convinced by now, “one size fits all” does not work. What is then the solution? The answer is “custom fit”. The first step is to understand the context of the team, product nature, people, and business expectations. Then, choose your framework, set of practices and principles accordingly. Try and continuously learn from your mistakes. This way, the method will evolve over the period of time and you will find the “suitable model” for you. Don’t stop improving! Please share your experiences. Do you use standard tools and practices? Are they working for you? Have you evolved your method over the period of time? Stay Curious! Coming Soon: Second anti-pattern – Too long preparation time.

How to foster mentorship in a team? The traditional way of helping someone improve in their work is to provide constructive feedback. i.e., you observe something, you tell the person “here is what I have observed, and I think you could improve by doing this…”. At PALO IT, we meet regularly to share and learn from each other. In our last team gathering, I suggested we try the Feedforward exercise inspired by Avraham Kluger, Organisational Consultant, and Marshall Goldsmith, Executive Coach. It is a technique to give and frame suggestions in a much more powerful and positive way than standard feedback. Let’s start! 1/ Introduce the exercise by saying something like: “We are going to do a Feedforward exercise where each of us is going to receive suggestions from the others. Each suggestion should be treated as a gift. A gift is something you receive, you don’t always like it but you always say thank you.” This way of introducing the exercise is to reinforce an attitude that should always prevail: respect each others’ ideas, don’t be judgmental and express yourself. 2/ Ask your team members to each think of one thing they want to improve. It can be anything. 3/ Form pairs. In each pair, team member A says “I want to improve…”. Team member B says “Then you could try to…”. 4/ Reverse roles. Team member B says “I want to improve…”. Team member A says “Then you could try to…”. 5/ Split and form new pairs. Continue until everyone has talked to everyone. At the end, I asked each team member to give me one word to express what they felt and the results were amazing: “Energised”, “Positive”, “Great”, “Inspired”. And they asked to do it again the next time we meet! The numerous benefits of this practice The “no judgement” style makes people feel comfortable on both sides, receiving and providing suggestions. Because the person receiving advice is choosing the topic, it is perceived in a much more positive way than typical feedback. We don’t focus on saying what is not done well up to now, but what you can start doing from this moment forward. Again reinforcing positive communication methods. Team members get advice from different people with different backgrounds and skills. Team members get to give advice even though they may be junior. It is a way to learn to be self-introspective regardless of experience, as well as gain confidence in expressing ideas. Everyone participates, but with an one-to-one approach. This puts less pressure on people who are shy. I recommend you, as a Leader, to also participate. It makes everyone feel on the same level. You will lead by example and of course you end up learning new things as well. Conclusion For all the reasons above, Feedforward is a much more positive exercise than giving feedback in a traditional manner. You can also use it for one-to-one sessions with your team members, however I think the group version is even more powerful. If you want to learn more about this Feedforward interpersonal improvement activity designed for team and organisations, I invite you to watch the following video: And you? Have you ever tried it yourself? I would love to hear about your experience!

It all started with an idea that came about during a conversation I had with my boss, Nadege Bide, when we had just finished a project for a banking client in 2017. During our dinner to celebrate the completion of the project, we were discussing how we could apply the functionality of some aspects of our new product into UX practices. I immediately saw an opportunity coupled with a clear vision to make a promising new project. Enthusiastically I manifested my desire to transform the idea into a reality and sooner that I knew, I got the approval to work in the project envisioned. “The idea of the project was to help UX designers with qualitative user research. A project that I named RestitUX.” Alongside other talented Palowans I was able lead the project of RestitUX from inception to MVP, relying on prior research to come up with the following product:   The Product PALO IT to present its interview research and speech-to-text technologies internally. The main features of the MVP includes: Create questions based on objectives: User needs addressed: This gives guidance to anyone who wants to do interviews (UX, PO… and even marketing or sales people) and make sure that every question asked will respond to an objective of the research. Conduct interviews with speech-to-text transcription and tags: User needs addressed: Allows users to index and structure information as they conduct the interview to save time during the analysis. While we usually encourage at least two people when conducting interviews, at PALO IT, it might not always be possible. Edit text and selection of the most important content to export it in a .txt file: User needs addressed: Based on our participant feedback , one insight we found during our research phase was the desire to be able to easily analyse each interview. The functionality of highlighting text allows the user to be able to see the information that interests them with minimum effort. Transcribing a recorded interview: User need addressed: Users that do exploratory user-research prefer not to write questions beforehand and ask questions in a more spontaneous way. For this kind of interviews, the users can input a recorded file to get it transcribed from speech-to-text and have the tool analyse it.   How We Made It 1. User research phase In order to make a product that addresses its users needs and desires, I was given the opportunity to lead a formal user research where I interviewed  different designers of PALO IT’s design team from across our international offices (Singapore, Hong Kong, Mexico, Paris…). I got the opportunity to interact with designers from different backgrounds and experience levels to understand and define a strategy that ultimately creates the most inclusive design possible for our target audience. We wanted our targeted users to be able to express the way they work, their pain points, their habits, etc.. The challenge was not bias my research or findings, in order to do so, I took note of all the important feedback from the participants to later define the most important solutions in speedboat workshop with some of the other colleagues from PALO. The idea was to put myself in our client’s shoes, when they think they know their users by heart (which in most cases turns out they dont know them as well as they thought). (more on the speedboat workshop later down in the article). 2. Competitor analysis Part of the vision I had when I first started the project was based on an inspiration that came from a speech-to-text app called “cassette”, that I fell in love with during my Masters in UX design. Typically, at PALO IT, we usually conduct functional benchmarks of existing products to ensure that we are able to identify existing solutions in the market and build the best product possible. At the end, RestitUX is the result of a blend of two of my favorite apps I benchmarked. Existing Solutions Cassette: An app for user research that allows people to transcribe information from speech-to-text while using bookmarks to define key moments during the interview. I found the concept of the app great, even though I found it to be a bit too simple. Trint: Trint is a speech-to-text service that allows users to transcribe recorded interviews. Some colleagues at work had told me about this new service which had proven to be quite useful, but painfully expensive. Note: We are using functionalities of tools that already exist but enhanced with an improved user experience. The goal of the project was to create a tool that will make Palowans more productive without needing to outsource apps to work efficiently and effectively, such as leveraging on speech-to-text technologies.   3. Framing and ideation workshops: Doing ideation workshops and framing the perimeter of the project is a classic process we have at PALO IT – the ideas are gathered in 5 days within a Design sprint, sometimes along what we call the inception sprint. At PALO IT, we have a complete deck of “innovation games” we like to use, depending on the insights we got from the users. This time I used the famous speedboat innovation game which allows us to have a view of the pain points they encounter during their process as the anchors of the boat t and all the desires and opportunities as the sails of the boat. The goal is to later involve people being able to vote for the ideas they consider the most valuable to them. After that we then got to co-designing the customer journeys of the users (3 personas in total) 4. Prototyping, Testing, Repeating… PALO IT is a development company and I learned a lot about working in lean UX with developers to bring an idea to life with all the code infrastructure needed to function. For this I also learnt a few of the skills product owners use to collaborate with developers in order to create a product. As for a true agile product, we got to work on the MVP by prioritizing the backlog. In order to do that, we used classic Kanban and Scrum. For those who are not familiar with these Kanban method board is a board tracking the process flow while maintaining the number of work-in-progress activities. On the other hand, a Scrum board is a board tracking work in Sprints. A Sprint is a short, consistent and repetitive period of time (which is normally 2 weeks). You can find the detailed difference between the two > here <. As a product designer, I was asked to understand how to write good user stories. I got a better understanding of how to write user stories and how to use trello or other software such as pipepify to do such tasks. The normal way of creating a user story is in this manner: As <persona> I want <what?> So that <benefit for the user?>. Tip: When building a product that has many User stories, it’s a good idea to give them numbers such as US#31 (User Story #31) to be able to refer to them more easily when having discussions with the development team. If you want to learn more about it I highly recommend this tutorial .  5. Things I learned during the process: POC vs MVP During the production segment of restitUX, I realized that I was mixing the terms POC and MVP. Put simply: An MVP is a minimal form of your complete product that is tested with the end users/customers. Whereas a POC is a smaller project, typically used internally not publicly, to verify a certain concept or theory that may be achieved in development. During this project a combination of both was used. We used POCs in the form of SPIKES to validate the feasibility of my ideas and eventually create a functional tool that would be used internally in the form of an MVP. If the term SPIKE is not familiar to you, in agile software development, a spike is a story that cannot be estimated until a development team runs an investigation of the feasibility of this story.   6. Debugging and testing When it comes to debugging, this is the first time I have actually experienced this part of the process, I originally thought that the debugging was the job of the development team, but it is actually a third-party that should do the testing and debugging to make sure every possible manipulation within the tool is working in optimal shape. There are different types of automatic testing so that a software can grow in a scalable way such as Cucumber, a tool we use at PALO IT. Now restit UX is being used by our Palowans and iteration v2 will come soon from the user’s feedback! This is a good example of how we all work together on a daily basis to make our client’s user’s life easier…   Final Thoughts The value of being able to work in this project was the opportunity to follow the proper design process for the creation of a product (from idea to MVP) in Period of 4 months. PALO IT is company that has Coding and agile development embedded to its core. If you want to get to know how to work with developers in an agile framework, this makes a great base ground for upcoming designers who want to make the transition into product design where you get to see the whole cycle of a the creation of product. Transition into product design The project RestitUX has allowed me to do a transition from UX/UI design into the field of digital product design as I was able to learn how to lead the project from inception to MVP delivery. In Justin Edmund‘s words, “A product designer oversees product vision from a high level (how does this feature make sense for where we want to be in 6 months) to a low execution level (how does styling this button this way impact how the user flows through this function)”. I am glad I was able to officially make this transition, as it has always been my original intent ever since I started learning about digital design and marketing back in 2011, Smashing Magazine.

My experience working both with startups and at PALO IT has taught me that Agile practices don’t only apply to software development teams. Agile represents a new way to increase the efficiency of any team, respond to changing requirements, and deliver value to clients. Misconceptions of Agile It’s true that the Agile Manifesto was at first written for software development. However, the underlying “why” behind the manifesto is all about increasing adaptability and delivering valuable outcomes for customers, regardless of the domain. It allows companies to flourish in markets that are increasingly uncertain and complex. Agile helps businesses deliver instant value at scale. For organisations to survive the volatile market, they found it rational to embrace Agile. Today there are over 70 different Agile practices, many of which are still evolving. So let's debunk the myth that Agile is only for software development... Getting flexible with budgeting At the heart of traditional project management, the budgeting process and the budgeting mindset are still king. Organisations are used to drawing up quarterly budgets, reassessing them at the end of each period and making changes where needed. In order for organisations to become more responsive to the changing needs of the customers, the budgeting process must be addressed for organisations to become more Agile. As Biarte Bogsnes pointed out in Implementing Beyond Budgeting: Unlocking the Performance Potential, "One of the most stubborn myths in traditional management is that the only way to manage cost is through detailed annual cost budgets, with a tight follow-up to ensure that no more is spent than is handed out”. Lack of flexibility can lead to wasted resources and effort if it no longer responds to the customer’s needs. To put this misconception to bed, organisations can benefit from transitioning from a traditional budgeting process to 'Beyond Budgeting'—the practice of creating shorter rolling budgets and reviewing them at regular intervals. Credit: Bjarte Bogsnes No matter what team you belong to, a company survives on delivering value to their clients. If your team is constantly looking to improve their work in shorter intervals, than the budgeting within the organisation must match the strategic vision. Toyota, for example, made resources available just-in-time to meet each customer order. Embracing Agile doesn't mean abandoning the construction of a roadmap, it's still essential for companies to adhere iterations to a long-term goal, but this goal should be accompanied by a cost-conscious mindset and make resources available as needed. Traditional budgeting has in many ways obstructed the nimbleness of companies. If other teams and projects can adopt Agile to become more efficient, it can lead to more valuable outcomes for the customers. Limiting work-in-progress and maintaining workflow Imagine chewing a piece of gum and watching TV at the same time. It’s easy to do both at the same time right? Now try to engage in a conversation with someone while reading a book. It’s an impossible task. The idea of “multi-tasking” has always been a buzzword in the business world. However, when we try to multitask, it diminishes our brain’s ability to focus and maintain attention on a single goal. When we multitask too much, we don't perform any task well, as our brain is overloaded. This idea can similarly apply to the workflow of any non-software project. Kanban methodology has taught us that we should limit our work-in-progress.Instead of juggling 10 tasks at the same time, it’s much more productive to focus on, at most, three tasks at hand. Credit: Roger Brown Any team would benefit from adopting a 'stop starting, start finishing' mindset. According to the graph above, distributing time to different projects actually harms progress more than you'd think it would, and creates waste that further hinders customer value. Computer scientist Jerry Weinberg has shown that even if you account for a 10% penalty for each context switch, in reality, the cost is even higher. Even as Agile preaches the positives of forming a cross-functional team, team members should not seek to multitask different projects with a wide spectrum of context. For example, when a team member leaves to do work that is not related to the team’s work, the rest of the team has to compensate for time lost, as well as help the returning member catch up on context. Setting work-in-progress limits helps teams to reduce context switching and avoid slowing down the whole team with an ever-expanding scope of work. This practice also reduces the number of mistakes committed by teams overloaded with tasks. The implementation of Agile Marketing To encourage non-software development teams to embrace Agile, it’s important to demonstrate the value and cultural change that an Agile approach can deliver. Agile Marketing is a shining example. Agile Marketing can be defined as an Agile approach in which teams “identify and focus their collective efforts on high-value projects, complete those projects cooperatively, measure their impact, and then continuously and incrementally improve the results over time” - Andrea Fryrear, author of Death of a Marketer Since the approach embraces rapid iterations and data-driven decision making, it ensures your marketing investment is being optimised. Credit: Inbics To implement Agile Marketing, teams should seek to develop flexible roadmaps of projects and tests instead of rigid upfront planning that's not adaptable to changing conditions. For example, a marketing team can release a part of a marketing campaign to selected users. Through this approach, the team can collect valuable data and user metrics to determine their likes and dislikes. The collection of this data will also help marketing teams to continuously improve their content. Agile Marketing embraces the visualisation of a team’s current workflow, and the transparency of each project is amplified by increasing communication and honesty. Agile supports the team to collectively own the process of each project, and encourages them to speak up and contribute to the overall project vision. With the aid of project management tools, stakeholders and team members can be aware of what’s going on at all times during the project lifecycle, including the team’s responsibilities and budgeting. In addition, Agile Marketing serves as a risk buffer, as companies no longer have to pour huge funds into a single marketing campaign that may not resonate with users. As long as you can help teams improve communication and workflow, you're one step closer to Agile success. In reality, there is no one-size-fits-all approach to introducing Agile to your non-software development projects and teams—but make no mistake, there's a fit that works for you. Don’t be afraid to experiment! You needn't coerce your team into an approach that doesn't fit their needs. Instead, strive for continuous improvement, and never be complacent about adopting new ways of implementing Agile.