The agile principles, as contained in the original Agile manifesto, serves as a guide that captures the essence of agile and further describes what it means to be Agile. Hence, by 'going Agile' in my current organization, we had to adapt these principles for the various squads we were coaching, as the majority of our Agile squads were 'business' in nature, as opposed to software development or IT related teams.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Translated: Our highest priority is to satisfy the customer through early and continous delivery of new solutions for bank customers and achieve targeted sales KPIs.
In order to achieve this in business squads, we had to ensure that 1) the squad had a very clear idea of who their customers were 2) how did they ensure that the customers' satisfaction was prioritized.
During my journey as the Agile coach, I had the opportunity to work with an SME product development team, a Customer Experience team, 2 sales planning teams, and 4 other credit card related teams. In the product development teams, the main focus (the actual customer), were the banks' customers who applied for our products like financing or credit cards. On the other hand, the 'customer' for the sales planning teams were usually the internal customers, for example the Head of Consumer Bank, or the managing director, for their team served the purpose of DRIVING the actual growth and market share of these consumer products.
Personally I found out that it would be much more effective to coach the product development teams on Design Thinking principles, and how to incorporate design thinking into the agile way of working. The reason was because these product development teams sometimes built or enhanced their products based on unvalidated assumptions. Let's face it, the majority of retail banking products are not new, be it targeted at individual consumers or SME business owners. Hence, most of the products were just being 'enhanced', or what was being developed was a variation of existing products or services offered. In order to ensure that innovations were consistent, a structured approach to test any hypotheses before building their MVP was needed.
As for the sales planning teams, the only way to ensure their customers were satisfied was to deliver in terms of sales numbers or growth in market share. These teams did not do the actual sales themselves; rather, they drove the growth of their products by driving the sales channels that distributed for them. For them, the more important part was to ensure that any sales initiatives or campaigns launched would really enable and support those sales channels in achieving their targeted numbers. By running agile ceremonies, these sales planning teams could ensure that approvals and discussions related to campaign launches were systematically and properly tracked. Any obstacle that was highlighted was surfaced to the squad lead to help remove in order for user stories to be completed.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Translated: Welcome changes to your current project/initative, even at the final stages of approval. Agile process harness change for the benefit of customer satisfaction.
For business teams, these changes often come from management (Do this, do that, please modify this to ensure compliance, etc. etc....). The main challenge would be for product teams to really ensure that these changes in needs or preferences actually came from the end users (bank customers), rather than just following every instruction from senior leaders in
that they were reporting to. So for example like the credit card teams, they had to ensure that they incorporated and also prioritized efforts to gain valuable insight from customers who had experience with their products. In view of this, the product team has to ensure that focus groups are run frequent enough to gauge that features being developed were desired by customers. The same goes to the Customer Experience squad, whose primary mission is to ensure that the bank's customers were satisfied whenever they interacted with the bank's various touchpoints. Even in the area of managing complaints, the squad has to plan and design the way the complaints were handled in such a way that the complaints were resolved in a satisfactory manner to customerrs. If the squad members felt that thre was a more effective way to manage complaints, they would update the Complaints Management Guidelines accordingly, even if the guidelines were already approved or in the final stages of approval.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Translated: Deliver product enhancements, product variations, guidelines, SOPs or new campaigns/initiatives frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.
In the squads I was coaching, the key was the same as those in a software development team, which was to deliver their 'product', or service, or mission output in short iterations and incrementally. As an example, the sales planning teams had to come up with new campaigns or initiatives to drive efforts to cover any shortfall in KPI targets in order to ensure that 'run rate' was maintained. They also had to ensure that any time to market for boosters or marketing initatives could be launched before any competitor had the same idea. They did this by ensuring that the squad had the capability embedded to deliver the campaign end-to-end, and feedback or any changes from approvers were incorporated as a result of sprint reviews. As for the product development teams, post-Agile, most of the stages of product development were surfaced by way of user stories on their sprint board. The team also used the sprint review to gather feedback from stakeholders while building their MVP.
4. Business people and developers must work together daily throughout the project.
Translated: No translation needed for this principle, as it holds true for both the business and IT squads.
In reality, as best as the supporting IT team could, they met up or came over to the business squads to discuss and further review Change Requests, also known as CRs in our company. In the event that they could not meet up daily, updates were done through Whatsapp or email.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Translation: No translation needed here also, as this principle also affects both business and IT agile teams.
Closely associated with this principle is the concept of Servant Leadership. By being a servant leader, the team always knows that you have their back. Also, by combining the 3 main principles of adult motivation based on Dan Pink's research, namely having a sense of purpose, mastery over important competencies and the chance to be self-directed, individuals will give all they have and utilize their talents to ensure the success of a project.
It was not easy when business teams first embarked on an agile oriented journey. Their leaders had to take time to get used to focusing on the needs of others, before focusing on their own. Leaders were also supposed to handhold and guide their team members whenever they ran into an obstacle, in order for the team members to deliver the committed work for the project/product. Hence, the squad and tribe leads had to be coached to focus on their employees' needs, rather than just their feelings. I had to constantly remind the leaders that we should work on the premise that no one comes to work to do a bad job.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Translation: Again, this is a principle that should be applied in ANY team as the key to effective communication.
When I first took over coaching a certain credit card team, the team members fed-back that the IT squad supporting them was slow and at times unresponsive. Besides that, the same team members also complained that their operations team also was not up to par in terms of support and sometimes could not assist in carrying out certain instructions.
After observing this team's interaction with their stakeholders, I came to the conclusion that a huge number of their pain points were due to ineffective communication. For example, when collaborating with IT production, they tried to communicate by way of having conference calls (which if set up effectively, would have helped in progressing issues). However, what I noticed was that they did not ensure that aids were given out to both parties discussing issues from remote locations. There was no pre-sent graph or process flow sent to the IT production team for ease of reference during the concall. Furthermore, the teams, both IT and this business team, liked to have private conversations that were audible over the phone during the call. They were also heard to be criticizing and giving negative comments relating to the IT teams' deliverables during the call.
The same underlying issue was observed whenever this team tried to enlist the help of their operations counterparts. The team had the tendency to issue instructions over email, even when their operations colleagues were located on the same floor. They could have just walked over to inquire on a certain issue or have a chat to ease matters by just walking over to their area. They were also engaged in fault-finding and not taking ownership of their work at times.
With the observations in hand, I approached their team leader and highlighted the need for more face to face interactions with their stakeholders. I mentioned to her that the best way to reduce instances of miscommunication was by having live discussions whenever they could. Although it was challenging for distributed teams to meet frequently, I coached the team to see that the benefits of applying this core Agile value far outweighed any inconveniences. After some time the team realized this and they now made the effort to engage their business partners and other related parties in person.
7. Working software is the primary measure of progress.
Translation: Working output or increment is the primary measure of progress.
No matter how many quests (epics) or user stories are on the squad's product backlog, they are only deemed to have fulfilled their responsibility as an agile squad if they delivered a product increment, or working output, at the end of the sprint. This was not easy for business squads new to agile to achieve as they were used to coming up with a working campaign or product enhancement after a few months or sometimes up to a year.
In order to ensure that the teams delivered valuable increments, I had to coach them to prioritize the most important features of a product or campaign. In order to adhere to this principle, the teams also needed to fully understand and keep in mind another agile concept, which was the 'definition of ready' for user stories. Many a time a team would pick up user stories which were not ready to be worked on, for example, user stories which had dependencies on other squads for data or leads. A team would not be able to deliver meaningful output or increments if they pull user stories which were not 'ready' into the sprint.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Translation: There should be sufficient work life balance to prevent burnout among collaborating stakeholders when working in an Agile way. Top management should learn and be willing to prioritize on what was delivering the most value to customers in order to prevent high staff turnover.
To be very very honest, I could not influence the senior leadership in adhering to this principle, even to this day. In the business teams, every agilist was pressured as the big bosses wanted everything at the same time. There was no proper consideration on how much a product development team could commit to deliver before the start of every sprint.
Adding to this was the all too frequent ad hoc kind of work added to a squad's sprint by senior leaders who did not bother to prioritize or plan in terms of sprints. Hence it was common to hear frustrated team members giving the feedback that going agile made them work later, have tighter timeline and without much time to reflect on their work.
In order to make things in agile work for business squads, the squad leads have to have the courage to act as gatekeepers to reduce the noise from other stakeholders and to avoid squeezing in additional unplanned work during an ongoing sprint. Sad to say, I have not seen this happening frequently enough in my current organization's day to day routine. Another essential angle to truly transform the organization would be to have senior leadership agree to being coached in the agile way of working and be willing to embrace the underlying principles.
9. Continuous attention to technical excellence and good design enhances agility.
Translation: It may be translated as 1. Getting product design right (as best as you can) the first time, and 2. Continuously devoting resources to properly plan product and campaigns in order to mitigate risks.
The above principle holds true for business teams because when teams work in an agile way of working, the cycle for plan-do-inspect-adapt is much more frequent than in traditional ways of project coordination. By being adaptable and responding to change, agile business squads should be able to come up with desirable and useful products for their target segment. Also, running proper retrospective sessions ensures that a business squad is able to incorporate feedback from customers into their upcoming sprints, thus enhancing technical excellence and product design.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
Translation: When developing products or enhancing processes, it is beneficial to keep in mind the Pareto principle, and to focus on delivering output which is most valuable first.
In the business teams that I am coaching, it is still challenging when holding on to this principle, as it is very common for senior people to want everything done in the same time frame. Prioritization rarely happens. This in turn affects the agile team's ability to strive for sustainable development, as they have to work on every directive from the top.
Sometimes the teams have to realize that there is always a trade-off, as resources and time are usually limited. The most important thing to remember is to work on features and mechanics of certain products/campaigns that really solve customers' pains or helps them in their gains. In most cases the agile team has to decide on which features to prioritize;any unnecessary or 'low value' features may impact the speed to market of the product negatively. However, it will take time for squad leads to learn to say 'no' to senior leadership on postponing items which have low value to customers.
11. The best architectures, requirements, and designs emerge from self-organising teams.
Translation: The best products or campaigns are developed by teams with autonomy on how work is done.
Through experience, a team should be given the opportunity to learn from mistakes and grow from there, as their own self-initiative. It is only by way of learning that a team can grow. In my current organization, there is enough autonomy given on how a team needs to come up with their enhancement, service or new product. Having said that there are still two or three leaders who might need to take a step back and let their reportees come up with ways to solve their own problems. The person who is doing the actual work usually has the best solution to deliver their task; they only need to be supported and motivated in the right way.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Translation: In order to become better as a team, and be able to deliver value to their customers, agile business teams have to constantly reflect on processes and interactions in a continuous fashion.
The teams I coached had the tendency to view retrospectives as some sort of light hearted moment or a chance to take a breather at the end of the sprint. It took them a few sprints to understand that they themselves had to take ownership of suggestions to implement in their subsequent sprints. As coaches, we tried to bring out points for discussion by using creative topic openers to facilitate the session.
Besides that, I tried to make the teams realize the value of doing retrospectives by not just stopping at gathering insights. I made it clear that if they did not take ownership on making things better for themselves, all the rantings and opinions given during retrospective was no more than coffee shop talk, or a nice chat.
It is my hope that the team continues to facilitate fruitful retrospective sessions even when the agile coach is not around. Any team that wants to improve should always make the effort to reflect, no matter whether they are business or IT teams.
Comments