WHITEPAPER IMPLEMENTING SCRUM

WHITEPAPER IMPLEMENTING SCRUM

© Copyright 2017 Objectbay Group. All rights reserved.

 


Culture Hacking Implementing Scrum & Agile Development Daniel Haslinger, MSc is a Certified Scrum Trainer™ (CST) of the Scrum Alliance and has collected many years of experience with Scrum. In the last couple of years, Daniel has intensively dealt with agile software development and worked as developer, consultant and coach actively in Scrum projects, as well as Scrum Master and Product Owner. He also holds the certification as SAFe Program Consultant. As an agile Coach he helped several organizations with the introduction of agile methods like Scrum, from small Startups to major enterprises. Through training and catalyst coaching and consulting Daniel helps companies with their agile transformation and brings in his rich experience from many previous projects. Daniel professionally develops software now for over 10 years in the field of Java. He intensively deals with agile practices and helps development teams to apply these successfully and use them for continuous improvement.

Dr. Andreas Wintersteiger is a Certified Scrum Trainer™ (CST) and Certified Enterprise Coach™ (CEC, formerly known as CSC) from Scrum Alliance and a Certified SAFe™ Program Consultant (SPC). He is a computer scientist with more than 25 years of experience and has been practicing Agile for more than 15 years now, since the term “Agile” was coined. Together with his team at Objectbay, he has helped major organizations worldwide to implement Scrum and agile practices in more than 70 cases from startups to SMEs to multinational corporations. He is the author of three books, this white paper is an extract from his latest book “Scrum: Your definitive Guide to Success” (2016).

Like with the implementation of any other type of process model, there are also several options to implementing Scrum, which can be combined with each other even. Firstly, there is the simple “Roll-Out model”, in which a Scrum pilot project is started to gain experience. Typically, organizations focus all their attention on this and evaluate the effect of Scrum in their company based on this pilot. In many cases however, this is only of limited significance since pilot projects are often somewhat unrealistic. Plus, as is often seen, a pilot project is too critical to be typical. Nevertheless, after a period of approximately three to six months roll out starts to occur with other teams, organizational units or products or projects. In this model Scrum will always bring forth the problems at the interfaces between old and new. The rollout is therefore "accelerated" through experience from the inside out. The “Big Bang” is the second option, opposed to the first one. Here, the whole organization will be suddenly changed with an effective date to apply Scrum. All affected teams start their first sprint on the same day. With the Big Bang approach typically upfront experiences of coaches are required in the practical implementation of Scrum which is also necessary, because in this variant much more is at stake. The preparation for this scenario is more complex, since it is even started at a scaled level. Note: Many teams start in pilot mode as a "submarine" - that is, initially invisible to management. However, in understanding the mechanism of Scrum, this approach generally discouraged. We advise you to do a top-down approach with the earliest possible involvement of management - Scrum is indeed a framework for change management, and for changes to occur in management commitment will be necessary.

© Copyright Copyright 2017 2016 Objectbay Objectbay Group. Group. All All rights rights reserved. reserved. ©

 


De-facto Standard Scrum has become the leading process model in the agile movement with more than twenty years of development. This is because Scrum is not only a very lightweight and simple process model and therefore scales well, but also because it was the only one with an elaborate training and certification program and became therefore a de-facto standard. Scrum is today internationally used by numerous companies from small to large, including many Fortune 500 as a process framework for software development.

Scalability In light of the standardization and broader use of a process model, the scalability of the model comes to the foreground. Heavyset, complicated and complex process models are difficult or impossible to scale. Such models, particularly in the roll-out across the departmental boundaries, have difficulties which multiply when used beyond the corporate boundaries. Models with many roles and overlapping responsibilities create further problems if other organizational units have to adopt a model. In many large organizations the scalability of Scrum has already been proven. Not only the two creators of Scrum, Jeff Sutherland and Ken Schwaber, report on enterprise Scrum implementations. The “2015 State Of Scrum Report” from the Scrum Alliance 1 reported that approximately one-third of organizations using Scrum have fewer than 500 people, however, more than one-fifth of organizations have more than 20,000 employees.

1. Before the first Sprint When a company begins to work with Scrum, some preparatory work is needed with one or more teams to become effective. Before the first Sprint can be started, a few activities are required.

Product vision As per the Scrum Framework, the Product Owner is required to present a “Product Vision”, a clearly communicated, overarching goal along with a reason for a team. This should be known to all, it should be easy to understand, broad and yet specific or concise enough and it should be shared and engaging. The responsibility of creating a product vision that is easy to communicate is the responsibility of the Product Owner. She also needs inputs from the team in order to flesh this out. Note: One sometimes hears talk of an "Envisioning" phase. I personally take the view that there should be no "phase" in the classical sense that may last for several sprints. Since this would open the back door to a waterfall approach.

Usually, the first essential product delivery components (also known as Epics) arise from the product vision, from which the product backlog is then created.

1

see https://www.scrumalliance.org/why-scrum/state-of-scrum-report/2015-state-of-scrum


 


First version of the Product Backlog The idea of agile development with an emergent Product Backlog is that we can begin without knowing the full details of all the requirements upfront. We even want to get started without knowing the sum of all requirements, as this will need to be defined in the future. The core question that everyone must ask the Product Owner is “With how little of a small backlog (and a clear vision) can we start without wasting the team's time?” - so, how little of it is enough to create something of value? To be agile also means to get started with the core of the idea and over time emerging requirements will be added with the product vision forming a direction to steer towards. And it is exactly with this small first version of the product backlog that we begin. We want to bring the product backlog into the shape of an “iceberg”, meeting the following criteria. Then we can start the first Sprint. 1. Prioritized: Setting a clear priority, at least for the top elements even a clear sequence of the deliverables. 2. Detailed just enough: From fine-grained and full detailed out items for the top priorities to medium grained in the mid of the Product Backlog to coarse grained requirements on the bottom (low priorities). 3. Estimated 4. Emergent: allow the document to evolve over time

Team Finally we need to define the composition of the team, if this is still unclear. The development team quite often is already in place, but it makes sense to even then think about how it should be assembled. For the purposes of the Scrum framework, the answer is simply given by the theory: cross-functional and small. The first challenge when implementing Scrum in many organizations is raised even before the first Sprint. Namely: The “testers” are usually in a different organizational unit, being called “QA”, unfortunately reporting to a different line manager within the organization. The same problem typically also occurs with “architects”, “designers” and other required functions. Already here we see challenges surfacing, that are changes to the organization, even if it is temporary for now. After the successful transition to Scrum, for one or several teams, these changes become more than a temporary Scrum team assignment. Typically the Scrum Team will become the new home organization. Scrum helps organizations to develop effective teams. These teams are an asset that, if invested in, the investment bears fruit. It is therefore absurd to make this "capital" unused or worse, go back to the old arrangement. A well-functioning team should work together.

2. Scrum and the Organization In our Certified Scrum Master trainings one question is often asked: “How does Scrum fit into the rest of the organization and how does the combination work?”. The answer is not easy because it depends very much on how the software development department is embedded in the organization and what significance it has.


 


Product Vendors Let us first consider the case of a product vendor, a company that creates a software or combined product and sells it to the market. In which case the business process of software development is either one of the main business processes or a part thereof (hardware and software in a product) and therefore constitutes an important part of the process. In such companies Scrum has usually a significant effect on the rest of the organization: After a few sprints other organizational units start to see results, which also affect their work, since they often depend on it. For example, in sales more frequent and earlier releases will clearly change the cooperation with the customer. Frequent releases typically change the cooperation with the product marketing and product management. The presence of a "Product Owner" has sometimes massive influence on these organizational units. Not infrequently new business models sometimes arise solely by the model of the frequently delivering to the market (releases). Customer service (support) units in the mid term, may need to take other or expanded roles because of increased product quality and cooperate much more closely with the development teams. In the mid term also other units of the organization will feel the effects of Scrum, which were previously never touched. For example, Controlling and business reporting is typically designed differently in agile organizations from the classic approach. Personell management is significantly changed because also compensation- and career models will change with the implementation of Scrum. Management will be affected and mid to long term become evaluated using different benchmarks: sustainability and long-term goals typically become more important while the short-term (e.g. quarterly) lose significance. Therefore true agile organizations reduce local optimization in favor of long-term, sustainable value creation. Customer satisfaction takes center stage and short-term increase in shareholder value is secondary. For producers of software products that adopt Scrum organization-wide, the world will significantly change. Many companies that have taken this step report significant improvements in the competitiveness of the company. Above all is the example of Salesforce.com, a well known CRM manufacturer who introduced Scrum in 2008 and agile development practices in the big-bang method 2. This was done organizational wide, with the company coming from a desperate situation but has now moved to an excellent position (presentation at the Scrum Gathering 2008).

IT departments in large companies In many companies however, introducing Scrum is different when the situation is like developing software for the internal purpose of the company and software is not its main business. The importance of software though should still be relatively high, after all, IT is the backbone of almost any company today. Unfortunately it is often not perceived as such and the processes that the IT team defines for their work are hardly known anywhere outside of IT. The contact points of IT, and thus also for Scrum with the outside world are many. Mainly with the departments for which the software is going to be developed we now require more intense communication and the integration of these “internal customers” takes place much more intently and more frequently.

2

see http://www.slideshare.net/sgreene/scrum-gathering-2008-stockholm-salesforcecom-presentation


 


Anti Pattern: Ironically, I have experienced in quite a few companies that this is not “desired”. In many cases it is a state of lethargy towards the importance and crucial element of IT in building the product. However, sometimes as mentioned above, it is also due to the overall perception of IT.

In IT-heavy enterprises integrating the results of each team is often cumbersome and slow. There are usually multiple responsibilities, one with enterprise-wide processes and the other on systems that cause the interfaces to need much coordination effort and all this presents practical difficulties to create frequent releases. In practice, I have felt that implementing Scrum in such organizations is more difficult, since the dependencies are significantly larger and due to departmental thinking, associated with the importance of tasks for the department,is therefore more deeply rooted. The introduction of agile practices and Scrum, and a significant organizational change, is therefore more complex and requires way more energy. Much of my experience in this field comes from consulting and coaching in the area of several large telecommunication providers in which the system landscapes have a very high degree of complexity. Similar to financial services, there are often hundreds of products and systems, which together form the backbone of the operations. Only to develop an understanding of the interaction often takes years. Large banks and insurance companies have similar system environments, where it is not so easy to get a “test system” or environment with all major components integrated, in order to have real environments for development and testing. Rapid response to new market situations, new products, but also for example, the rapid implementation of regulatory measures is required, but the complexity of the infrastructure and the associated organization further complicates the agile transformation. Many companies in this field use a so-called “agile release train3”, in which individual prod ucts attach to a release if they want to deliver. This train “departs” for example monthly. With this in place the implementation of Scrum can also be done in a “Roll Out” model now, so that other units can still operate on the classical process models which previously exist, such as waterfall. With the situation described in here, one can see that in these types of environment it becomes even more important if not mandatory to obtain the active support of management. Scrum as a solo act in IT does not work. However, the remaining organizational units benefit enormously once they are enabled to utilize the potential of Scrum. Especially in the areas of sales and customer service, where rapid response is 100% visible major benefits for the department arise.

Not reversible Scrum is usually an irreversible process. In many development departments, as well as in other departmental organizations one phenomenon became visible, which is actually quite easy to explain: Teams members that have worked with Scrum and have come to know the benefits of it, do not want to go back to waterfall or other heavy-weight process models. They rather leave. One occasionally hears of cases where a Scrum pilot was implemented, but was not pursued further and team members returned to their original department - despite the success of the pilot. Not infrequently, these team members look for new challenges outside the company - where they are allowed to work agile again. This step is plausible, because working with Scrum is more fun, is usually more rewarding and way more sustainable.

3

Find out more about Agile Release Trains in Dean Leffingwell’s Book “Agile Requirements”, 2011.


 


3. The Scrum pilot The most common way for the introduction of Scrum in the enterprise is the roll-out variant, namely in several phases. Objectbay’s model consists of four particular phases or “scale levels”. Even when I speak of phases, no analogy to the waterfall model should be considered, there are more releases and everything is done iteratively.

Typically we start doing an assessment where we first try to understand the current situation at hand and screen the existing process. We have developed tools and working aids to assess and measure maturity on multiple levels and for different roles. We help to create transparency for the organization to inspect & adapt. The next step is to create a plan to get started. We view it most important to get started instead of getting stuck in layout out plan for the entirety. Think big but act small and let’s not create a waterfall project for implementing Agile. So while planning is important, it should also be very focussed on revealing realistic, measurable results in the short run. Every organization is different. In every situation. That's why we create an individual plan for only a short period of time. We use the agile tool "Coaching Backlog" consisting of small work items such as training, coaching or consulting deliverables. Together with you and the teams we prioritize and act on the selected items within each iteration. And then move on to the next iteration

Measure & Assess

starting with an inspection of the situation again. We will begin as described above with a pilot “project”. It is important that it is not too small (“sandbox”) and not an unimportant

Using agile tools and principles to implement Agile. Build

project, but a project or product from which the organization can Plan

learn. The evaluation of the pilot is clearly an important factor for further action; therefore the project should be representative of the company's work, and not a “kindergarten project”. It is advisable to start with a maximum of three teams; otherwise the problems of scaling interfere with organizational learning and teams

are exposed to two entirely new paradigms in parallel. Ideally, one tries Scrum initially with just one team of about seven people plus a Scrum Master and a Product Owner. This is the most efficient and lightweight way to start with Scrum. After three to five sprints, a lot of learnings have already emerged. This way of doing is also more of a “homeopathic” deployment scenario. Clearly the one we prefer. In the course of the pilot, the organization learns how Scrum “feels” and where the currently existing processes and organizational structure have weaknesses. These weaknesses surface immediately just by the correct application of Scrum, the teams “feel” it. Just by imagining about how Scrum can work in our organization, most of the already existing problems become visible. That is, we begin to learn what processes and self-defined standards in our business create problems and how difficult it is to eradicate them.


 


Agile Transition Team (ATT) During the whole agile transition, every Scrum Team is supported by Coaches, where one coach typically supports more than one team. During continuous plan, build, measure & assess cycles performed by these coaches, new items emerge and will be put either into each team’s coaching backlog or reported to the ATT.

Transition Backlog Agile Transition Team

Scrum Team 1

Coach

Coaching Backlog

Scrum Team 2

Coach

Development Team Scrum Master Product Owner

informs

Development Team Development Team Scrum Master Product Owner Scrum Master Product Owner

Coaching Backlog

Scrum Team n

Coach

Coaching Backlog

So, the Scrum Masters and Coaches will address each team’s individual impediments directly with the respective team by working with the team’s coaching backlog. All global, high-level items which are not directly related to an individual team will be reported to the ATT, a team of managers who are able and empowered drive organizational change and support the teams on a higher level. To keep communication effective, it is recommended to have one or more of the Coaches on the ATT. The ATT will work like a Scrum Team, producing agile teams instead of Software. They have frequent Standup meetings where they discuss who is working on which items respectively to which people in the organization the items can be delegated. They will also discuss and identify new problems and issues. During the pilot, the ATT is the only high-level instance that drives the transition and the work of the coaches. All information and knowledge arising from the coaching activities will be consolidated in the ATT and documented in a catalogue of best practices for the upcoming rollouts. The ATT and the coaches are further responsible to socialise this knowledge again in new teams.


 


Transition Backlog These global items will be addressed ATT’s transition backlog prioritized by their Product Owner. Typically, there are two kinds of items in the transition backlog: 1) Global, general actions like infrastructure for build & test automation, access rights, availability of key roles like Product Owners, co-location of teams, etc. 2) Rolling out Scrum to new teams

4. Department Roll-Out to other Teams After some time, when the first Scrum team(s) have learned how Scrum really works and what impact in terms of organizational change will occur and a certain level of maturity has been achieved, the next phase follows. We then expand the amount of teams, initially gently, and extend in the medium term to an entire department. At this point it is important to transfer existing learnings to the new teams and to accelerate the learning curve. It is to avoid having to re-learn what others have already learned, often painfully. But, sometimes it is also helpful to have a specific learning and experience learned individually (again) by new teams. Most of the time knowledge and experience can be socialized to new teams from the experienced team members. In this phase the Scrum Masters from pilot teams play an important role in the explanation and knowledge transfer of Scrum in the organization. They have become experts and can speed up the learning curve significantly. The Scrum Master now becomes a coach and helps the new Scrum Masters to cope with the new role and the changes it brings. In this phase, the myriad of team dependencies typically become visible. Add another transparency about the different performance levels of different teams comes in along with the weakness of the organization in terms of crossfunctional teams, with many skills only being available just once.

Enterprise Transition Team (ETT) In large organizations, at this point it might turn out that the Agile Transition Team becomes too big or that some critical decisions to be made require managers from higher layers. In this case, an ETT will be formed. The ETT is a board of managers empowered to make critical decisions related to the further agile transition. Typical decisions made by the ETT are significant changes to the organization’s structure and processes, personnel decisions etc. The ETT meets frequently every couple of weeks to make these decisions. Taking action on these decisions typically becomes the duty of the ATT again. In some cases, an extra task force may be formed. To keep the communication between ATT and ETT effective, we recommend that at least one member is part of both teams.


 


The bitter reality is mercilessly transparent Another set of problems become visible within the organization, which are typically multitasking and lack of technical skills of developers, countless defects, lack of quality, complexity, incomprehensible and not maintainable code, no correct measures and metrics, no automated tests, etc, etc. The whole mess inside the development organization becomes painfully transparent and appears to be an unsolvable big problem. Everything associated with “Agile” seems to be impossible in our situation here and now. But, exactly here this plays into the strengths of Scrum and agile development. Once the bitter reality is visible and transparent to all, it can be tackled step by step. This is the time now, when you should get external help in the form of experienced coaches, who have accompanied other organizations in this way and know well, how this transparency does not turn into frustration, but can be used as energy for the change. In this phase agile practices and principles will be gradually implemented and thus solve one problem after another. Here, a valley of tears is often travelled, because the sins of the past, which become so beautifully visible here, must ultimately be mastered. Quite a few companies we have accompanied as their coaches at first had to discard hundreds or even sometimes thousands of defects (bugs), automated all or most of their manual steps in building their software, making it faster and error free and finally added test automation. Here teams learn a lot about the practices of modern software development and the organizational realities. In addition to the technical subjects, those realities are also relevant for change within the organization. We now clearly see the problems that certain legacy structures and processes come with. Breaking these, accommodating this change is at least as difficult as building technical skills.

Entry to paradise Gradually, however, the jungle thins and there is visible light at the end of the tunnel. Many processes are now much better and more enjoyable for everyone involved. The pain subsides and teams, management and customers obtain the noticeable improvements. Customer satisfaction increases massively, as well as the satisfaction of the teams with their work and also happiness of management. Success sets in and the efforts will be rewarded. Developers love their work and their products, the quality is excellent and (for the first time) it creates confidence in the development teams because they have proven that they provide good quality, regularly and predictably. Over 80% of organizations that have adopted Scrum report that the quality of working life has improved significantly4. This is also the experience that we see with our customers, as we support them as consultants and coaches on their journey. But the journey is far from a piece of cake and can last up to several years, depending on the size of the organization.

5. Rollout to the rest of the organization The learnings from this phase which have already been implemented can now be easily transferred and rolled out to the rest of the organization. In general, the Scrum Masters or even individual team members from the past will act as coaches for those who now take on new roles. The learned practices and established processes such as

4

Source: 2015 State of Scrum Survey, see https://www.scrumalliance.org/why-scrum/state-of-scrum-report/2015-state-of-scrum


 


Continuous Integration/Delivery can now be easily transferred to other parts of the organization. The organizational adjustments can now be transferred much easier, because there is evidence about how they function. There will be internal training and learning packages created to make it easier to drive the changes forward. The spectrum ranges from new roles, such as “Agile Coaches” or “Evangelists” to concrete learning packages for selfstudy or lectures to “communities” within the company, organizing small events and regular meetings. It is important for the sustainability of the changes that this takes place.

Scrum lives inside the organization After a successful implementation of Scrum inside the enterprise a lot of changes are already visible. The organization has significantly changed its way of work and the constant change, in the sense of process improvement, has become normal and is executed by the organization in daily activities. The development teams are more productive and deliver high quality in a reliable time. The Product Owner is able to use evidence based prediction, i.e. based on the actual capacity to make commitments on volume or time of delivery, or to recognize and challenge unrealistic expectations.

Agile values and principles are lived The development teams dominate the practices and techniques of agile software engineering at a professional level. They are self-organizing and regularly deliver predictably valuable working product increments. Teams work independently together with the Product Owners and functional departments providing optimal support for their demands. Communication within the teams and between Scrum teams and stakeholders runs efficiently and effectively. “Faceto-face” with short distances is the preferred way to talk to each other. People understand that ambiguities arise from bad communication, resulting in rework. The cooperation is based on trust, transparency and continuous improvement of inefficient working methods. It is completely normal that problems are addressed and resolved in a timely manner. It is therefore no longer necessary that organizations need to protect themselves from harm, retire to well-defined interfaces, are not interested in other’s results and call for “insurance” by other departments. It is working jointly where all are responsible for the delivery to the customer. This representation is not “Fantasy Land”, but a real world scenario where organizations actually are, those who started some years ago to implement agile software development and Scrum. This world is not easy to achieve, but it is worthwhile to pursue. 


 


About Objectbay Objectbay people are passionate about software development - we enjoy what we do. We develop software for our customers. And we help our customers with own development teams to do it like we do. Our mission is to bring the best project experience in software development to our customers. We bring our learnings and first hand experience of more than 15 years of practicing lean and agile software development to our customers. We do it, that's why we preach it. We do two things: We develop software Our major line of business is to develop individual software for our clients. We have one or more agile teams work on an entire project or have them participate in a larger effort together with the customers' teams. Our teams gain their productivity from our highly automated development infrastructure, their continuous attention to technical excellence and skilled agility due to permanent exposure to internal agile coaching. We help others Our key people have been among the pioneers of the agile movement and we leverage the experience of 15+ years in doing it to consult our customers. We know the issues organizations facing when implementing agile software development because we do it on our own, past, present and future. That's why can bring in practical and real world experience. And, certainly we keep track with latest developments in the field.

Objectbay Software & Consulting GmbH Johann Roithner-Straße 131 4050 Traun, Austria Tel.: +43 (0) 72 29 / 630 63 - 0 offi[email protected] www.objectbay.com


© Copyright 2017 Objectbay Group. All rights reserved.

WHITEPAPER IMPLEMENTING SCRUM

Recommend Documents