Cash-in Comfort (pseudo name)

(Cash-in Comfort is a pseudo name. Corporate policies restrict the usage of the actual company name. All names of individuals in this case study are also pseudo names.)

Cash-in Comfort

Overview

Cash-in Comfort (CiC) provides financial services directly to individual public consumers at over 1.100 branch locations as well as providing services directly over the internet.

Cash-in Comfort relies heavily on our internal application development department to provide the services sought by our customers. The product focused on in this case study is a set of external web applications used directly by our customers to purchase financial services from CiC.

Our industry is heavily regulated, so much of application development involves updating our systems to stay compliant with continuously changing state and federal regulations. We are also continuously adding new financial services and new ways to access services.

Our department is small, so keeping up with demand is difficult.

Tom is the Director of Application Development at Cash-in Comfort. He reports directly to a corporate vice president. Tom has a Master’s degree in Software Engineering where he got his initial introduction to XP and agile thinking in general. Tom took his Scrum Master training from Mike Cohn years ago and has read the first two LeSS books, as well as other foundational literature in the field. Before coming to Cash-in Comfort, Tom had been heavily involved in Scrum for several years at companies in the Southeast, but had not yet tried to formally roll out a LeSS implementation.

I have known Tom for over 10 years, have kept in contact professionally, and have periodically provided him with coaching. Thus, when Tom and I discussed trying to formally adopt LeSS at Cash-in Comfort, he did not see any major obstacles given that the basic Scrum framework was already in place and Tom had the authority to fix most anything that needed fixing. However, as Tom and I were both acutely aware, having the authority to fix something does not guarantee that one has the ability to easily fix it in the short term. For Cash-in Comfort, realizing the advantages that a comprehensive LeSS adoption brings is turning out to be a long term investment in architecture, infrastructure, training and mentoring.

The application development department currently has three cross-functional, cross-component, feature teams working on a single internal open source code base. One of the teams is located at our home office in the southeastern part of the USA, while the other two teams are located in Mexico. The Product Owner is at the home office in the USA. A clear dysfunction that we will explore later is that the Scrum Master works remotely from a third location.

Other than the dysfunction of the Scrum Master, the teams have the basic LeSS structure in place: a single Product Owner with three cross-functional ¹, co-located feature teams. At Cash-in Comfort, we do not consider LeSS adoption as a project that will ever be finished. Rather we see LeSS as part of our perfection goals.

This case study is somewhat unique in that our major difficulties are not organizational design in nature. In contrast to many of the larger organizations that I coach, CiC did not start out with entrenched component or silo teams that had to be disbanded and reformed as feature teams. Due to the small size of the application development group, most of the development team members have always been, by necessity, “generalizing specialists.” Furthermore, even though the Application Development Group has a history of traditional sequential or waterfall development, the initial group had been more or less following the Scrum framework for a number of months. Therefore this case study focuses on the issues faced by smaller IT departments as they adopt LeSS and address the dysfunctions exposed by the LeSS framework. Nevertheless, we believe this is a useful case study, as there are many smaller application development departments that could benefit from a LeSS adoption. We anticipate that other organizations that match the CiC profile (see below) will experience many of the same LeSS adoption issues as CiC, and thus benefit from the lessons we have already learned.

CiC Profile:

• successful mid-sized company
• small enough application development department so that there is a single manager. Everyone reports directly to the head of the application development department.
• the manager of the application development department is educated in, and a promoter of, LeSS
• traditional sequential waterfall thinking and practices dominated product development before the current application development manager was hired.
• recent experience or interest in single-team Scrum
• many of the members of the application development department are contractors.

History and the Journey

Even though we did not face huge organizational redesign issues (a common issue in large-scale adoptions), there were numerous false assumptions and unhelpful patterns of behavior that needed to be addressed. Some of these have been resolved, some are currently being worked and some have not yet risen to the top of the improvement backlog. It is also quite difficult to, in every case, cleanly separate the Scrum adoption issues from the LeSS adoption issues. This is due to the fact that LeSS was introduced very soon after the initial Scrum adoption. Thus, at the point of scaling from one team to three teams, the Scrum adoption by the initial team was not yet mature.

Our senior corporate management is familiar only with traditional development, so reporting, funding, planning and tracking are often expected to be done in a traditional manner. Some managers outside of application development still think that comprehensive up front analysis and design documents are always needed before starting a project and are skeptical of alternative approaches. Others have a fundamental disinterest in the entire software development process and therefore have no interest in even discussing the benefits of the LeSS Framework.

A problem that we face is that in a smaller organization, senior corporate management, outside of application development, is more involved in department budget issues and generally more aware of the operational details of the application development group, than would typically be the case in a larger organization. This increased awareness, coupled with waterfall expectations, has been an issue that Tom has to continually address. Tom has found that trying to explicitly sell LeSS, or even Scrum, has not worked well. Instead, Tom simply uses systems thinking (a key LeSS principle) to discuss issues. For example our executives were used to trying to allocate work to teams months ahead of time. Tom has worked on educating the executives on the system effect of premature allocation and how keeping the teams flexible lets us allocate effort to whichever projects are the highest priority at the moment.

The recommended approach to change a group to the (smaller) LeSS framework is summarised below and compared to our case.

Even though our start was not perfect, rather than give up, we explored the art of the possible for our organization. Senior corporate management never really got in our way, the biggest concern is that they failed to provide the necessary financial support for up-front comprehensive training and coaching.

Tom has found that educating corporate management on one issue at time, as that issue comes up, and doing a more bottom-up adoption for the part of the company outside of application development has been workable in this case.

Dealing with senior management and other stakeholders: At CiC, “lessons learned” in dealing with senior company management (above the application development department) include the following:

• Hold unofficial mini training sessions
  • Prepare for teachable moments, so that when they naturally arise you are able to take advantage of them. Instead of trying to teach the LeSS framework, instead focus on teaching the systems effect of various corporate policies, procedures, and structures. For example, a teachable moment about backlog refinement occurred when development was held up with churn due to negotiating back and forth between the compliance lawyers, Product Owner, and feature teams.
• Repeat concepts even after you think people should understand them
  • Try not to be irritatingly redundant, but instead approach the same concept from many different angles until finally the concept becomes familiar. For example we have had to repeatedly teach the value of keeping Product Backlog items all relatively small and roughly the same size.
• Continuously manage up. Always anticipate, and be prepared for push-back
  • Do your own due diligence in systems thinking here. When you change a policy, procedure, or structure, try to anticipate how the existing organization will push-back in an attempt to maintain the status quo. Have a counter strategy already thought through. For example, the use of business analysts structurally protected our compliance legal experts from having to interact directly with developers. When we adopted a LeSS structure, this structure changed, and sure enough we did get push-back. However we had anticipated the pushback and countered with a simple, let’s try as an experiment, approach.
• Don’t try to sell LeSS directly
  • Keep Scrum and LeSS jargon to a minimum until it is a familiar part of the company’s vocabulary
  • Instead of selling LeSS, evangelize how this approach will solve existing problems. For example when a development team complained about not having enough ready requirements, we promoted how putting the development team in direct communication with stakeholders would get them the answers they need to develop the code.
  • As per the recommended LeSS adoption approach, focus on explaining why, rather than what.
• Immediately begin protecting the team from work that is “off the books” or at least make it visible to the organization
  • One of the LeSS guidelines for getting started is: “Keep project managers away from the teams” Teach the team, Product Owner and all stakeholders, the effect of interrupting the team during a Sprint. Put procedures, policies, and structures in place that support this policy. In CiC the sources of these undisciplined interruptions are usually external to IT, coming from product management, compliance, marketing, customer support, and senior management. Fortunately in CiC we do not have a bunch of project and line managers making things worse. In many organizations that I have coached, cross-functional teams were formed, but team members still reported back to their old functional managers in a matrix-management structure. Those managers are typically a continual source of team interruptions. That problem is not solved until there is a change in the organizational structure. Tom was well aware of these problems when considering taking his current job. Tom made it a condition of acceptance that he be in charge of all IT, so that he could manage the entire value chain from “concept to cash.”
• GET THINGS DONE!
  • Focus on useable increments
    • It is hard to argue with success. In LeSS adoptions, we say, “shipping speaks louder than words.” Deliver “early and often” and you will go a long ways towards getting management support for whatever it is that you need. We don’t have actual data on the impact of using LeSS, but the sentiment seems to be positive. Obviously it is good to be able to frequently show your boss that something is done.
  • Provide regular updates on progress towards a goal together with regular feedback on scope and schedule changes
    • Keep the focus on outcomes instead of output. Discourage performance metrics and navel gazing.
    • Like most products, our product requirements evolve. Corporate management is used to thinking of fixed requirements and “scope creep” as a bad thing that causes us to miss target dates. By using a burn up chart we make visible the relationship between increasing the scope of initiatives and the projected completion date of a given feature set.
• Prioritize improvement issues
  • Although most of the department improvement issues we face are technical in nature, addressing them can and often does have effects visible to management. The product that is the subject of this case study has a long development history that predates Tom’s appointment as head of product development. The product has a lot of technical debt and the development infrastructure is far from agile. We prefer an iterative/incremental approach to fixing technical debt and improving the development infrastructure, but sometimes this is not optimal. However, we have so much technical debt, and so much to fix in our infrastructure, that if we stopped and focused on fixing all technical debt and infrastructure, product development would cease for an unacceptably long time. Thus we have found it necessary to create a backlog of improvement issues and not exceed a reasonable WIP limit in working these issues. Working improvement issues, while simultaneously building product also gives us a nice “inspect and adapt” feedback loop so that “improvements” made based on faulty assumptions get caught and corrected quickly. We have made significant strides in test automation and continuous integration, but we still have a ways to go.
  • In addition to legacy technical and infrastructure debt, a LeSS adaption can face what we call organizational debt. This is often a lingering side-effect of the old “contract game” and waterfall ways of thinking. Although we did “all at once” adopt the basic LeSS organizational design inside of the application development group, we are working the larger organizational debt issues one at a time.

Scaling the Teams at another Site

Our product development originally started with a single Scrum team. We kept it that way as long as possible as we worked with the hypothesis from Jeff Sutherland’s advice: “It’s easier to scale velocity than it is to scale people.²” So we focused on removing as much overhead from the dev teams as possible and automating repetitive tasks such as integration, regression testing, and code releases. A learning organization should also benefit from removing the waste of under-utilizing people, by increasing the skills of existing team members. Eventually it, however, became clear that the current Scrum team was not going to be able to provide the throughput required by the company and that IT was again being regarded as “the bottleneck.” Thankfully we were able to circumvent the pressure of trying to increase throughput by adding more members to the existing scrum team. We instead got agreement and funding to add two additional teams.

Unfortunately it is difficult for CiC to hire experienced IT staff locally. There are several reasons for this. CiC’s home office is in a small rural southern city with no major technology companies to attract IT talent. The few other companies in the region that hire developers tend to be larger stable companies with brand name recognition. So in addition to a paucity of IT staff in the area, there is very little turnover in what staff does exist.

When Tom joined CiC, they were already in the early stages of forming a relationship with an outsourcing company. Coincidently, Tom already had a history of a positive working relationship with the same company. These factors led CiC to outsource the two new teams. Outsourcing introduces its own set of issues, but these issues are compounded by the fact that the new teams are located in Mexico, which introduces the additional problems of multi-site development. I typically advise clients to carefully consider the disadvantages any type of multi-site development that physically separates the development teams from the domain experts. I have seen so much benefit from getting all the parties physically around the same table (or whiteboard) during backlog refinement and other joint meetings. At CiC, however, multi-site development is working reasonably well. Factors that facilitate our success include:

• bringing the off-site teams on-site so as to form personal relationships
• acceptable time zone differences
• heavy use of Skype and other virtualization tools
• lots of interaction between the off-site teams and the home office.

The Mexican teams faced two additional problems. One, the new teams had no experience working in a Scrum organization. Second, the new teams lacked any domain knowledge.

Our new teams started off with many of the misconceptions common to those new to Scrum. Overhead comments include:

• “We have daily scrums, so we’re agile”
• “I don’t like documenting things anyway, so scrum is great!”
• “We need a user story for time we spend in scrum meetings”

As is common when introducing LeSS, we have found that introducing the mechanisms and structure of the LeSS framework is not nearly as difficult as getting everyone to understand and use the thinking tools that underlie LeSS.

When Tom joined CiC and introduced Scrum, the Product Owner did attend CSPO training and the Scrum Master did attend CSM training, but the teams did not get certified Scrum training. Tom, the Scrum Master, and the PO provided whatever training the teams received. Only recently did Tom, the PO, and the SM attend formal LeSS training. The teams are currently scheduled for CSM training. As the members of the LeSS organization are getting more formal education, things are improving. We reiterate the LeSS adoption advice: “first educate everyone in depth.”

To solve the problem of lack of domain knowledge in the Mexican teams we tried adding some of the local developers to the off-shore teams thus creating dispersed teams (teams not-co-located). Tom understood that LeSS normally requires co-located teams (with the exception of the experiment in the second LeSS book’s Multisite chapter, Try… A dispersed feature ‘team’ only if it really hurts on p. 420), but was at a loss of how else to solve the lack of domain knowledge in the off-shore teams. Unfortunately dispersed teams worked very poorly, even with liberal use of Skype and other facilitation tools. Now we have re-organized back into co-located teams and this works much better. We currently do the best we can to compensate for lack of domain knowledge in the off-site teams by lots of inter-team interaction during multi-team backlog refinement and joint design sessions. In addition to these planned coordination events, the off-site teams do regularly interact with the home team via Skype whenever they need knowledge from one of the home team members.

In addition to the off-site teams lacking domain knowledge, we faced the cultural issue of the off-site teams feeling like “orphan teams,” inferior in status to the home team. We did bring some of the off-site team members on-site for a period of time, but one can’t deny that the off-site teams are almost always off-site, so we do the best we can to make the off-site teams feel integral to the company by lots of use of instant messaging, video, and any other any-time communication channel. We also use a cloud-based product backlog so that all the teams have equal access to all the product data.

Scaling the Coordination

An issue inherent when scaling is cross-team coordination. One of the early problem we faced is that the Scrum Master came from a project management background and was trying to do a lot of team coordination. We have had to coach our Scrum Master on her role. In the beginning it was hard for her to understand the difference between being a coordinator and facilitating team coordination. Things are much better now. We have worked hard to help the teams get good peer to peer team communication in place so that coordination happens naturally, emphasizing the advanced LeSS coordination technique called “just talk”. Now we are coaching our Scrum Master to coach the teams to use those mechanisms effectively, and to reflect on how to continuously improve them. Current cross team coordination mechanisms include: cloud-based Product Backlog tool and shared information repository, common email distribution list, face to face interaction between co-located teams, joint team meetings, cross-team groups responsible for certain joint initiatives, coordinating in code, joint design workshops, and common standards.

Scaling the Product Owner, Prioritization, and Clarification

Even though we added additional development teams, we were careful to stay with one Product Owner. Our Product Owner is, correctly, the former Product Manager and head of product management for our product. We were careful to avoid adding any layers between the product development group and the development teams. The product development group, however, was used to a traditional, waterfall, document-centric process of interacting with those outside of product development.

Product management issues: From the product management side of the organization, issues that we have had to address, and continue to address, include:

• Inadequate stakeholder interaction
  • The product development group’s focus is on the product functionality, however, our product has many complex legal compliance issues that vary from state to state. We encourage the development team to get the details of the compliance issues directly from the SMEs in the legal department, but the PO needs to interact with the legal group enough to be aware of all the compliance issues, and place them into the Product Backlog in the appropriate order. The PO tended to operate under the false dichotomy that either she needs to be knowledgeable about all the compliance details, or leave them entirely to someone else. We are continuing to coach her that she only needs to be knowledgeable enough to prioritize the compliance functionality. This same concept extends to other stakeholder groups.
  • Before adopting Scrum, and shortly thereafter, LeSS, our Product Owner had been a traditional Product Manager. As a Product Manager she had traditionally been used to document based interaction with the development teams. Very little direct interaction between the Product Manager and the developers occurred. In a Scrum organization the traditional BA role disappears. Our former Product Manager has had to adjust to the reality that as a PO her interaction with the teams increases. Tom has had to coach the PO on her new relationship with the development teams.
• Clarification instead of prioritization
  • In most of the larger organizations that I coach, product managers often stay at a higher level and do not get too much into the detailed requirements. In making the transition to a PO they typically need to be coached to get more involved – down to the level of PBI by PBI prioritization. At CiC, when we had only one team developing the product, our PO had time to get into many of the requirements details. As we scaled to multiple teams, going to this level of detail left our PO with insufficient time to focus on and understand all the issues relative to prioritization. Understanding these issues requires her to spend more time than she is used to with compliance experts, marketing managers and other stakeholders. Tom coaches her to increase her attention to prioritization even if it means she can’t be involved in all the product details.
• The incorrect fear that there would not be enough time
  • This relates to and multiplies the above issues. With three teams, the new PO incorrectly feared that there would be three times as many meetings to attend, three times as many stories that she would need to get “ready” for each Sprint, and three times as many urgent issues to resolve at any moment in time. Since the PO did not automatically get three times as many hours in a day as before, the PO had to be taught that her fears were unfounded and to focus on prioritization and product strategy. Thankfully the LeSS framework has focused her on the right meetings to attend and given her guidance on how to offload work to the teams and other product management support staff.
• Antagonistic relationship with development team
  • Relationships between application development groups and the businesses they support have traditionally been antagonistic. At CiC we have experienced the same dynamics for the same reasons. It is taking CiC time to build trust and create strong working relationships between IT and the business. Having the PO directly drive the work through prioritization of the backlog is helping. Having the business experts (e.g., compliance lawyers) and the developers talking directly together to accomplish backlog refinement is an especially important form of communication that also helps build trust.
• Not knowing how best to divide work between teams
  • The LeSS framework and guides have helped us to realize the benefit of a learning organization. Our case study product has three, fairly distinct, sub-areas: payday loans, installment loans, and lines of credit. We, at first, divided the work up between the teams along these lines. We have now cross-trained the teams on all the product sub-areas. This is allowing us to achieve much greater product agility by having as many teams work in a given product sub-area as needed.
• Not structured to support multiple development teams
  • This relates to the “not enough time” section above. The Product Owner and product team did not have the right relationships and processes for communicating with, answering questions, and providing guidance to multiple teams. Adopting the LeSS framework has solved this.
• Not knowing how to work with a development team effectively
  • Historically the Product Development Group had very little direct interaction with the development team. The Product Development Group relied on written documentation and a project manager from application development to interact with the developers. Eliminating project managers from the picture introduced some fear and confusion into the Product Management Group. Teaching the PO effective backlog management, including feature by feature prioritization was just one challenge. Effective product backlog refinement, where all parties are at the table including the development team, was new to everyone. Admittedly this is not specifically a LeSS scaling issue, but since we introduced Scrum and LeSS in rapid succession, we mention it here. It is also noteworthy to mention that the LeSS community has a clear and proper view of the PO role that is not universally understood in the Scrum community. Although the LeSS view is the correct view as intended by the founders of Scrum, many organization and consultants misunderstand the PO role as being essentially that of a glorified BA. I thus find that often when coaching organizations that are scaling single team Scrum to LeSS, I need to reinforce and clarify issues that I would typically think of as basic Scrum.

Scaling Code Management

Historically we have had cumbersome code branch management practices. This was bad enough with a single team, but exacerbated with multiple teams working in the same code base. We are moving towards continuous integration, but the problem is more than just changing the behaviors of the development team members. There are legacy architectural and infrastructure issues that have to be concurrently addressed. We are working these issues.

Shipping Every Sprint

We ship every Sprint, but are not limited to Sprint boundaries. In fact, sometimes we ship multiple times in a Sprint. This is consistent with the LeSS rule, “a shippable product each Sprint (or even more frequently).”

Mapping to LeSS Rules and Experiments

In the following section, we will focus on mapping the specific LeSS Framework rules and experiments to our experiences described above.

Already implemented rules that did not cause much disruption to CiC are marked as “done”

• Structure the organization using real teams as the basic organizational building block.
  • done
• Each team is (1) self-managing, (2) cross-functional, and (4) long-lived.
  • done
• Each team is … co-located
  • A Scrum Master that is not co-located is at a tremendous disadvantage when trying to mentor teams. Our dysfunction of having a remote Scrum Master is due to the fact that the Scrum Master is a contractor. Lesson Learned: Negotiate co-location before any contracts are signed. Ensure that each site has at least one co-located Scrum Master.
• The majority of the teams are customer-focused feature teams.
  • done
• Scrum Masters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices. A Scrum Master does not focus on just one team but on the overall organizational system.
  • Our LeSS Scrum Master is an employee of the outsourcing company we have selected. She has had to make quite a transition. Before being assigned to this project, she was a traditional project manager. When assigned to this organization she did take a CSM class, but of course two days of training is not sufficient to prepare one to be an effective Scrum coach. This was complicated by the fact that from our perspective she is a dedicated Scrum Master, but from her organization’s point of view she was, at least initially, also still a project manager. This resulted in undesirable behavior. For example, even though she ceased assigning work to the individual team members, she still had a tendency to act as the teams’ representative and to try to coordinate team activities and interactions. Recently Tom, the PO, and the SM have taken the LeSS practitioner class. Subsequent to this class, all three agreed to work with the outsourcing management to remove the internal title and role of project manager from her job description and to educate the outsourcing management on CiC’s expectations from her as a Scrum Master. A recent conversation with Tom indicates that this issue has been satisfactorily resolved. Even though our SM needs to read more of the foundational literature and to be additionally coached in the thinking tools that underlie LeSS, substantial progress is evident. As noted elsewhere, the teams initially struggled with some of the LeSS concepts. For example, the teams were not used to the idea of taking ownership of direct peer to peer team coordination. Not having a thoroughly grounded Scrum Master exacerbated this problem. Another significant problem was that we did not start with volunteers. Fortunately Tom has done a reasonably good job of coaching our SM. Without Tom as a master teacher/coach, this LeSS adoption would flounder. Lesson Learned: Do not skimp on training and coaching for the Scrum Master. Even in a small organization, there is a crucial need for an experienced coach.
• A Scrum Master is a dedicated full-time role.
  • done
• One Scrum Master can serve 1-3 teams.
  • done
• In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus is the value-delivering capability of the product development system rather than the specific scope of a product.
  • Tom is the only remaining “manager” and he is correctly very much focused on coaching, teaching, and the value-delivery capacity of the system.
• Managers’ role is to improve the product development system by practicing Go See and Help, encouraging Stop & Fix, and “experiments over conformance.”
  • done
• For the product group, establish the complete LeSS structure “at the start”; this is vital for a LeSS adoption.
  • done
• For the larger organization beyond the product group, adopt LeSS evolutionarily using Go and See to create an organization where experimentation and improvement is the norm.
  • CiC has taken this approach. See details in the above section: Dealing with senior management and other stakeholders.
  • Although this standard LeSS advice is intended to focus on peer groups to the product group, such as marketing, we have also used this advice to deal with senior management. Idealy we should have educated senior management up-front, but since this did not occur we have using this approach with them also.
• There is one Product Owner and one Product Backlog for the complete shippable product.
  • There is one Product Owner, but as indicated earlier, nearly all of the PBIs are easily identified as belonging to one of three major sub-areas. Each team identifies with one of these and historically only works on PBIs for their area. This does give a certain level of local optimization, but definitely decreases group-level (i.e., system level) learning and flexibility. It specifically reduces the ability and agility of the PO to focus all the teams on one area when that is the optimal business decision. We have now addressed this by cross-training the teams to work outside of their area of specialization. We only recently did this because we needed more velocity in a given area. Had we started this earlier, before it was actually needed, we would have been in a better position to ramp up the needed area faster. Lesson Learned: Coach Teams to avoid over-specialization. Teach them the advantage to the business.
• The Product Owner shouldn’t work alone on Product Backlog refinement; the PO is supported by the multiple Teams working directly with customers/users and other stakeholders.
  • Our teams, especially the Mexican teams, were not accustomed to being responsible for direct clarification with the SMEs. They would prefer to be handed clear requirements, and simply code specifications that are spoon fed to them. Merely putting the teams in direct contact with the stakeholders is not enough. The teams need to accept requirements clarification as their responsibility. Lesson Learned: Teams need to be trained and coached not only in the practices of LeSS, but more importantly in the thinking behind each of the practices so that they voluntarily embrace new ways of working and collaborating. Make sure that any intermediate group has been eliminated so that the teams have no choice but to accept requirements clarification as their responsibility.
• All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.
  • Our PO, as elaborated above, was not used to backlog refinement as done in real Scrum. A two day CSPO course was not sufficient. Tom has to provide consistent coaching to prevent her from sliding back to old familiar ways. The recent LeSS course has been helpful in reinforcing Tom’s coaching. Lesson Learned: POs may need senior level coaching for an extended period of time.
• One shared Definition of Done for the whole product.
  • done
• Each team can have their own expanded Definition of Done.
  • done
• The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might increase. Broader definitions are preferred.
  • Done. The three sub-areas of our product are distinct enough from the customer’s view, that we could have taken a narrower view and considered them three separate products, but it is clear to everyone that this would have been a mistake and would have reduced product agility. As the company is considering new “financial products”, we are working to make sure that they are not considered new products from the development point of view and that we keep the product definition as broad as possible, e.g. financial services.
• The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently).
  • We do ship almost every Sprint, and sometimes even ship multiple times per Sprint. The team’s DOD comes very close to actually deploying the product, but one small step is still done by a systems admin person.
• There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated whole product.
  • We meet the minimal requirements here. By the end of every Sprint all the teams’ work is integrated, but we are not satisfied with this. Some manual integration is still required at the end of the Sprint. We are currently working on continuous integration. Tom and the teams want this to happen, but there are numerous technical issues in the architecture, build system and deployment processes that are difficult, and take time, to fix. Fixing these issues is complicated by a lack of technical sophistication. Team members continue to need technical mentoring and training. So many of my clients fall down in this area. They assume that members of the development team already have all the technical skills necessary to achieving agility and therefore do not invest in the needed technical training. Lesson Learned: Teams need to be trained and mentored in the technical skills, tools and practices that enable agility.
• Sprint Planning consists of two parts: Sprint Planning Part One is common for all teams while Sprint Planning Part Two is usually done separately for each team.
  • Done
• Sprint Planning Part One is attended by the Product Owner and Team representatives. They together tentatively select the items that each team will work on the next Sprint.
The Teams identify opportunities to work together and final questions are clarified.
  • In the early phases of adoption, teams specialized in a given product sub-area and did not do joint sprint planning part one. We have now cross-trained the teams across the product sub-areas and are enjoying the benefits of a traditional LeSS joint sprint planning part one.
• Each Team has their own Sprint Backlog.
  • done
• Sprint Planning Part Two is for Teams to decide how they will do the selected items.
This usually involves design and the creation of their Sprint Backlogs. The Team forecasts how many items they believe they can complete during the next Sprint.
  • done.
• Each Team has their own Daily Scrum.
  • done
• Cross-team coordination is decided by the teams.
  • Not only decided by the teams but organized and executed by the teams. As noted above, our Scrum Master originally thought her role included coordinating the teams. Lesson learned: Coach the Scrum Master to be a coach. Teach the difference between being a team coordinator and facilitating team coordination.
• Product Backlog Refinement (PBR) is done per team for the items they are likely going to do in the future.
  • done
• There is one product Sprint Review; it is common for all teams. 
Ensure that enough stakeholders join to contribute the information needed for effective inspection and adaptation.
  • Basically done, but still working on getting all the relevant stakeholders to consistently attend.
• Each Team has their own Sprint Retrospective.
  • Done
• An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and create improvement experiments. This is attended by Product Owner, Scrum Masters, Team Representatives, and managers (if there are any).
  • Done

Summary

This case study illustrates the effect on a LeSS adoption, of the support, or lack thereof, from various levels of management.

In our case, top level, executive, management (outside of Application Development) was not interested in, and therefore did not receive, any formal LeSS, or Scrum training. Given their lack of up-front, formal training, Tom has opted to educate them through incremental mentoring. This situation has slowed the success of the LeSS adoption primarily through

1. Lack of funding support for comprehensive up-front training and mentoring.
2. Schedule pressure to deliver functionality, rather than allocating time to clean up technical debt and mature their development infrastructure.

Therefore, if at all possible, try to get executive level management educated in LeSS before attempting a LeSS adoption.

As Director of Application Development, reporting directly to a corporate vice president, Tom’s support has been crucial in organizational design and in facilitating a strong definition of done. Tom is not only fully supportive of LeSS, he deeply understands the principles that underlie LeSS. This support and understanding of the fundamental concepts has been key to our LeSS adoption. Unfortunately, director level management support is missing in many organizations where teams and lower level management desperately want to try LeSS, but lacking educated, director level support, simply cannot get farther than a surface adoption of some of the LeSS practices.

At Cash-in Comfort, we have found that bottom up support is also critical. Teams that do not understand the “why” of the LeSS practices are less likely to fully embrace them. In our case we struggled to get the Mexican teams to embrace direct requirements refinement with the stakeholders. Our teams seemed to think that this is an unusual requirement. The same is true for the whole team taking ownership of the functionality from design to release. The tendency is still to work within each team member’s respective area of expertise. Education and coaching is helping them understand both why direct requirements refinement with the stakeholders is necessary and why it’s important for the whole team to own the functionality they create. The teams are finally starting to understand that these concepts are a standard part of Scrum, and not just one of Tom’s ideas.

Major Lesson Learned: Within the application development division ³, both top down and bottom-up educated and enlightened support is required for an optimal LeSS implementation. However, if you have sufficient top-down support from the beginning, bottom-up support can often be nurtured and usually ultimately obtained through education and volunteering.

You can start with all the bottom-up support you want, but if you lack the level of top-down support necessary to achieve truly cross-functional teams and a strong definition of done, you will have very little success in implementing LeSS no matter how long and how hard you bang your head against the wall. Therefore, do not attempt even a small LeSS implementation without, at minimum, up-front, division level, educated support.

Notes:

1. Well, each team is mostly co-located. Some remote work is not currently high on our impediment list.
2. UPscALE – Upscaled Agile in Medium & Large Enterprises. Organized by Scrum Events & held on 11 March 2015
3. Depending on your org chart, may be called IT or R&D