Working Agile @ Alliander (Our Way of Working)

2

Special thanks to:

Jason Young

Wouter Vermeiden

Dirk Bollen

Martijn Sidler

Berrie Staring

LEGO Images Håkan Forss (@hakanforss)

(LEGO® is a trademark of the LEGO Group, which does not sponsor this publication)

3

ContentWHY WORKING AGILE @ALLIANDER ................................................................................................................ 5

OUR CONTRIBUTION TO THE ENERGY TRANSITION ......................................................................................... 9

MEET ET&NEBM ............................................................................................................................................. 23

OUR PERSPECTIVE ON AGILE SCRUM ............................................................................................................. 27

OUR ROADMAP TO VALUE .............................................................................................................................. 51

SHARING OUR JOURNEY ................................................................................................................................. 79

MEET THE WRITERS ...................................................................................................................................... 105

INDEX ............................................................................................................................................................ 108

Why working Agile @Alliander

5



6

Some things in life can’t be captured by an app...

Dear Readers,

We are thrilled to present Working Agile @ Alliander, Our Way of Working. As early as 2011 the first steps were taken in building the Taskforce Energy Transition IT at Alliander. In the last years the Taskforce has brought forward many innovative solutions, accelerating the energy transition and contributing to our mission; reducing CO2 emissions by 80% in 2050.

Accelerating the energy transition is exciting and necessary. It reshapes our focus on how we use and produce energy. That is a serious paradigm shift, which also means we have to adopt new ways of working – together-. Ways that can facilitate a very fast time to market, early customer value creation, early customer feedback, strong & effective stakeholder collaboration and employ new processes and techniques to manage complex innovative product development. In the past year we have learned a great deal in the art of working together. Moreover, in December 2014 the Taskforce Energy Transition IT has been acknowledged as a fully-grown domain within Alliander IT, opening new doors with a new name: Energy Transition & New Energy Business Models (ET&NEBM).

Agility means many different things to many different people. We certainly do not want to invade those perceptions and beliefs. We would like to share our learnings from our journey towards becoming an Agile organization. We pursue this Agile way of working because we believe it supports and enables our capacity to accelerate the energy transition.

Together, we have discovered these new ways of working in a dynamic and fast-changing environment and aspired to capture them in this book so others can learn and be inspired by our journey. While only a snapshot in time, our primary focus is to share our successes, what we have learned from our failures and how to add energy, focus, respect, transparency, commitment and responsibility for planning innovations and implementations. Most of all, enjoy the reading, because the art of working together begins and ends with having fun in what you do and how you do it, together!

Yours enthusiastically,

Jeroen Scheer


7


8

Our contribution to the Energy Transition

9



10

Vision, Building the Connected Utility It is not just you. Things really are changing faster than ever before.

The energy transition is the shift to sustainable economies by means of renewable energy, energy efficiency and sustainable development. The ultimate goal is to significantly reduce emissions while harnessing an improved security of supply without spending serious societal costs. Alliander facilitates the energy transition in a pro-active manner, and uses innovation in ways of working, products and services to accelerate this facilitation.

In the meantime the world in which we live changes more and more rapidly. You always knew digital was going to change things, but you did not realize how close to home it would hit. In every industry, digital competitors are taking advantage of new platforms, tools, and relationships to undercut rivals, getting closer to customers, and disrupting the usual ways of doing business. The difference is that now, these trends are not just technology trends. They are consumer trends, and potent ones at that. Today, consumers use technology as a lever to exert more and more power over business.

We live in a hyper-connected world, where Facebook, Uber, Spotify and AirBnB completely revolutionize entire industries. Where WhatsApp has grown bigger than email in just a few years. Where cars drive themselves (and you) with less accidents and much greater efficiency and road use that mankind by itself can accomplish. Where work can be done anywhere, from office places to Starbucks. And where devices in homes and outside are connected to a mysterious web to make life more comfortable.

Grid operators like Alliander traditionally connects buildings and grids in a physical manner. But with the dawn of the Internet-of-Everything, we will need to connect and interact with everyone and everything. The distinction between primary, secondary and tertiary devices diminishes in a very rapid manner, when embedded intelligence will integrally span all three areas without taking our artificial and organization boundaries into account. Consumers are certainly not making the distinction anymore.

We can already see this with electric vehicles. Cars are online and directly connected to our grid through the charging infrastructure. The batteries become assets in our grid, and can be used for sophisticated applications in demand and supply management. But consumers are rightfully so in control of their own vehicles, and do not care about our organizational boundaries. This example can be extrapolated towards other devices: every device will have its own connection and purpose in our energy grids.

We will monitor our grid in far more sophisticated and granular way. Digitizing our grid and enabling smart decision making within our regulatory boundaries will become the new norm. Putting our customers in the


11

driver’s seat of their own energy usage, storage and production will become the most important pillar in our strategy. We need to embrace digital tools and platforms to get closer to customers and engage them more deeply, especially in a world where grid operators need to keep in mind that it will be possible for our customers to physically un-connect from our grid when they become self-sufficient.

We need to be at the helm of the transition from a pretty static one-way connection to a dynamic two-way connection. That does not only count in a technical manner, but especially in this hyper-connected world in a social sense. New businesses like Tippiq and Locol are already taking the first steps in this social connection and journey. IT facilitates and enables these developments: it enables the customer driven energy transition.


12

A Fast Changing World In a fast changing world where everything is connected, you need to adapt or you become obsolete. As a crucial part of our countries’ critical infrastructure, we do not have the option for the latter. Therefore we need to accelerate the embracement of these developments.

Companies used to attain dominance through scale. In the first half of the 20th century that scale came from manufacturing and operational excellence, and companies like General Motors (GM) ruled. Later in the century, dominance came from smart supply chains (think of WalMart or Albert Heijn with its ultra-efficient supply chains), or information mastery (think Amazon). But in the 21st century, none of these sources of scale matter. Only customer and their dynamic choices do. This is truly the age of the customer.

Energy is more important than ever: it is very hard to imagine a world without energy as readily and affordably available as it is now. Accelerating growth of new energy technologies is already having a profound impact on energy demand and on the utilities industry. Over the next decade, this trend, driven by policies, technology innovation, rising electricity prices, shifting consumer behavior and other macroeconomic factors, will force a transformation of utility business models. We see many changes and challenges coming towards this energy system in an increasing speed:

• The trend towards radical decentralization of energy production and storage, imposing dynamic two-way energy flows, community management and instant communication

• The arise of new energy business models and market players • The rising interest in hacking energy systems • The electrification of mobility • Rapid developments in automation of many manual tasks

In terms of energy technologies, the biggest changes in adoption are foreseen in four main areas:

1. Distributed Generation. 2. Energy Efficiency. 3. Energy Conservation and Demand Response. 4. Energy Substitution.

First, with the rise of distributed generation, energy from solar PV, better storage technologies, and the proliferation of mini and micro-combined heat and power (CHP), or co-generation stations, are all reducing grid demand. Second, energy efficiency leads to adoption of more efficient lighting and services to manage automation and energy use, which also are driving reductions in energy consumption. In addition, homebuilders, appliance makers and other manufacturers are creating ever more efficient ways to insulate homes and reduce


13

power usage. In the EU energy roadmap to 2050, energy efficiency is the biggest emissions reduction contributor.

Third, with advances in energy conservation and demand response, many companies are seeking ways to help consumers exert more control over their energy demand and the timing of energy consumption. Fourth, the electrification of transport and heating is accelerating, leading to increased energy substitution.

Since Alliander is in a unique position to facilitate these changes in an effective manner, it embraces the challenge of not only adopting and reacting these changes, but rather anticipating and driving the changes needed in order to realize the energy transition.


14

Challenges Utility companies are at a tipping point of change. Technology is being adopted more aggressively as prices fall. The potential for customers to deploy distributed generation without subsidies looms large. Energy companies can navigate through this energy disruption by rethinking their role going forward, evolving from the pure-play transporter of energy and expanding to sophisticated energy services, like beyond-the-meter services such as energy efficiency, storage and automation.

To migrate to such a model, we should focus on engaging with regulators to define new models that will secure the long-term viability of the distribution business via the adoption of new tariff structures, opening up new markets for services, and aligning subsidies. In addition, a real opportunity to improve reliability of supply and increase earnings potential lies in the investment of grid optimization. This comprises automation, sensing devices and real-time analytics capabilities to improve real-time management of the grid. It also includes advanced demand response solutions to encourage consumers to use energy in a more flexible way.

Of course we understand these changes will not take place overnight. However, we believe these changes are coming at a nearly frightening speed and we need to be ahead of this. We also believe we can adopt and anticipate these challenges in order to achieve our goals.

We understand that this is like looking into a crystal ball. It is difficult to fully anticipate the future, since disruptive technologies and black swans can change everything within months. Just travel back in your memory and try to think what life was without your iPhone...

It is clear that the energy system will change, and fundamentally so. We just don’t know at what exact pace and with what technologies it will take place. And since changes are taking place faster and faster, we see a clear need for agile solutions, capable of adopting and enabling these rapid changes. That does not only count for the solutions themselves, but probably more importantly for the way we work. It requires a truly different mindset, in which the customer engagement and experience is at the heart of everything. That is the reason for us to invest so much time and effort in more Agile ways of working.

Since the entire energy industry will fundamentally change, the most certain thing we have is that change will be here to stay. Many things are beyond our control, like economic and political crises, technology innovations, and customer behavior. However, that does not mean we have to avoid them. We need to embrace change and create solutions that are able to cope with these challenges. And that starts with us, not the solutions...


15

The entire energy industry will fundamentally change and that change will be there to stay in the forthcoming decades.

We see many changes coming fast-paced at us. It is difficult to anticipate the future: disruptive technologies can change everything. Changes won't just affect ourselves, but also next generations.


16

Our Response In creating such agile solutions it is apparent that we do not have all the answers. However, based on extensive knowledge and experience in creating flexible, yet robust and scalable IT solutions in many industries, we created a reference set. And as the word itself already implies: it is a generic point of reference, guiding business and IT towards the realization of the new and innovative solutions we are seeking.

We started with setting our own principles1.

• Our highest priority is to satisfy (preferably exceed) our Alliander customers together with our business partners through early and continuous delivery of valuable digital solutions.

• We are welcoming change and continuously changing requirements, even late in development. Agile processes harness change for Alliander’s benefit.

• We deliver working software frequently. At ET NEBM, we use a two week sprint period in which features are delivered.

• Business people and developers must work together daily throughout the project. • We build projects and DevOps teams around motivated individuals. We give them the environment

and support they need, and trust them to get the job done, as individual part of a larger team. • The most efficient and effective method of conveying information to and within development teams

is face to face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development and operations. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity – the art of maximizing the amount of work not done – is essential. • The best architectures, requirements and designs emerge from self-organizing teams, • Within the wide framework and reference architecture provided. • We create a sound balance between process optimization and IT enablement, in order to avoid that

for the last 20% of process adaptation 80% of all IT costs are made. • At regular intervals, the team(s) reflect(s) on how to become more effective, then tunes and adjusts

its behavior accordingly.

1 Not surprisingly, our principles are based on the Principles behind the Agile Manifesto. More about Agile in chapter Our Perspective on Agile Scrum


17


18

Adopting a Reference Framework Besides having a sound set of reference principles, we have created a generic reference architecture, which is based upon the principles of having a set of IT tools that are able to:

• Facilitate a very fast time-to-market • Distinguish between Innovation and Production • Adopt international standards • Integrate standard building blocks that are readily available (internally or externally) • Scale out very fast, but also scale in rapidly • Harness very strict Privacy & Security rules • Distinguish between various market roles without reprogramming • Facilitate pay-per-use financial calculation models

In order to realize the above mentioned principles, we have created an IT landscape where a strict distinction is between business specific front ends and more generic back ends. We distinguish seven layers within this reference framework, not to be mixed with a solution architecture. We need to be able to easily exchange solutions and components within such a reference framework, which can be placed at any layer when such a solution needs to be positioned in that layer.

1. Various data producing and consuming devices 2. Telecommunications with various components to ensure sound communication between devices and IT

back ends 3. Data management capabilities, including data modeling, management and storage 4. Integration capabilities to ensure that the right data is used within the right solution 5. Generic applications, that are in principle not business specific 6. Business specific applications. This is in principle the layer where applications that really create business

value and revenue streams. I.e. where distinctive business / competitive advantage functionality is positioned

7. Presentation towards the solution user regardless the chosen channels and devices

The 8th part of the framework contains common capabilities to ensure that the entire IT landscape keeps functioning well, and can be considered as IT management capabilities. By adopting such a layered reference framework in realizing solutions we have created stable and generic back ends, which are re-useable for many organizations and business units, while adopting fluent rapid changing customer services, often referred to as front ends or business specific applications. These flexible front ends enable various business partners to focus on the execution of their strategies, without being withhold by the repeatedly implementation of the same back end functionalities, like metering data management.


19


20

The Purpose of a Generic Platform Strategy The Reference Framework is often referred to as a Platform Strategy. Businesses can build their specific value creating applications on top of standard (generic) back ends (platforms). This allows business to decrease their valuable time-to-market metric and provides a pure focus on customer-facing applications instead of an entire IT stack per project and/or product.

Generic functionality that is already available from this generic platform:

• Identity & Access Management • Customer Relationship Management (CRM) • Business Process Management • Financial Administration • Web Service (API) management • Integration via scalable Service Bus and Orchestration • Data management

The use of generic platforms does not only provide a faster time-to-market, but also gives significant cost reduction due to that fact that many components are shared and re-used. It also comprises highly scalable solutions that are available in a pay-per-use model. Besides, a very high level of automation from the development via test towards production environments has been established, reducing test and deployment times to a minimum.


21


22

Meet ET&NEBM

23

Meet ET&NEBM

Meet ET&NEBM

24

Meet Energy Transition & New Energy Business Models Wow…that is a long name: Energy Transition & New Energy Business Models @ Alliander IT... We understand that it will take some time to capture it. We do not mind how you exactly call us, we are happy if you understand what you can expect from our team.

The Domain Energy Transition & New Energy Business Models (ET&NEBM) is the successor of the Taskforce Energy Transition IT. After having successfully delivered a target architecture, IT strategy, Proof of Concepts and working solutions within the wide scope of the energy transition, the start of the separate IT domain Digital Grids, and the start of several Emerging Business Areas (EBA’s) focusing on new energy business models, the challenge was given to create a team within IT that is integrally responsible for IT related to the customer-driven energy transition.

At 1 January 2015 this domain ET&NEBM was launched. It is a separate domain within IT, and reports directly to the CIO of Alliander.

We serve several stakeholders. Besides the EBAs, we are very involved in projects for the Innovation Funnel Sustainability & Energy Savings, align closely with Strategy for new opportunities and alliances, and enable new product launches from Customer & Market and our Metering Company.

We have three units that span the entire product life cycle of solutions:

1. Research & Development 2. Information & Portfolio Management 3. Delivery

Our mission is: “we excel in jointly providing innovative digital solutions with our business partners that enable our customers to realize or exceed their ambitions thru new energy business models”.

Our vision to achieve this mission is: “By our combination of innovative working and predictable delivery, encompassing the entire product life cycle process in which we pro-actively co-operate with our business partners, we set the new standard for energy transition IT”.

Meet ET&NEBM

25

Meet ET&NEBM

26

Our Perspective on Agile Scrum

27



28

The Agile Manifesto In February 2001, 17 software developers, including Jeff Sutherland, met at a resort in Utah to discuss lightweight development methods. They published the Agile Manifesto2:

The Agile Manifesto gives us broad guidelines:

1 Individuals and Interactions The first principle of the Manifesto is to value individuals and interactions over processes and tools. Software developers are keen about tools and processes. Every process and tool assists them with getting their work done. However, tools and processes can get in the way of people and communication. We choose tools like Jira, Hipchat and Confluence that facilitate collaboration and communication.

Along with tools, we select processes that emphasize individuals and communication. Peer reviewing fits in here, and so does the daily standup. Retrospectives allow us to speak about the positive things (what to keep) and what could possibly be improved (what to change).

2 Working Software The second principle is to value working software over comprehensive documentation. Traditionally, in product development, it has been a priority to completely document everything: requirements, design, test scripts, manuals, how to use, etc. This is costly however: most of the time, the product itself suffers from the time and effort put in the documentation. Therefore we only write it down when it has value, - not as part of 'documenting' but as part of developing.

2 http://agilemanifesto.org/

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.


29


30

3 Customer Collaboration The third principle, "customer collaboration over contract negotiation", means we should work closely with our customers, invest the effort to discover what they need, and understand that only our customer (such as an end-user or business representative) can tell us what they want. Stakeholders are likely not to have the skills to precisely specify the system and tell a developer what API to implement. And it’s probable they change their minds. Working closely with our customers is something we have to learn and vice versa: Scrum = business + IT.

Contracts with vendors are important and useful, and time spent negotiating them can be very worthwhile, but it shouldn’t get in the way of collaboration. Instead we should be working together as partners: together we want to make it work and create great products for our customers!

4 Responding to Change The fourth principle is to value “responding to change” over “following a plan”.

People and organizations change their wishes and priorities all the time. As product development progresses, our customers might change their mind about the solution. Change is a reality of product development.

Sticking to the plan when the environment changes, probably isn’t a good idea. Planning and changing the plan when necessary is an ongoing activity within our way of working. We have specific gatherings to facilitate planning and changing, like sprint planning meetings, retrospectives and backlog grooming sessions (learn more about these gatherings later on in chapter ‘Our Roadmap to Value’).


31

Customer journey visualization (HOOM)


32

Scrum, a framework for managing product development3 Scrum is an iterative and incremental Agile development framework for managing product development. It defines "a flexible, holistic product development strategy where a Scrum Team works as a unit to reach a common goal". It challenges assumptions of the "traditional, sequential approach" to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need, and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach— through experimentation and observation – accepting that the problem cannot be fully understood or defined until engaged. Instead Scrum focuses on maximizing the team's ability to deliver quickly and respond to emerging requirements in short, iterative cycles.

The twelve principles behind Agile4 Our highest priority is to satisfy the customer through early and continuous delivery of value. Welcome changing requirements, even late in product development. Agile processes harness change for the

customer's competitive advantage. Deliver working features frequently, from a couple of weeks to a couple of months, with a preference for the

shorter timescale. Business people and developers must work together daily throughout the project; A departmental hierarchy or

domain structure is just an administrative necessity. Build projects around motivated individuals. Give them the environment and support they need, and trust

them to get the job done. The most efficient and effective method of conveying information to and within a Scrum Team is face-to-face

conversation. Working features is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to

maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of unnecessary work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior

accordingly.

3 From Wikipedia (http://en.wikipedia.org/wiki/Scrum_(software_development)) 4 Principles behind the Agile Manifesto (http://www.agilemanifesto.org/principles.html)


33


34

Shared Values of Scrum in ET&NEBM Collaboration In addition to the Scrum principles we all share the same values in working together towards creating business value.

Fun We have fun in our work and in working together with the people around us. Going to work whistling is a primary condition of employment. Work is only work if you make it so.

Commitment We are emotionally and intellectually bound to promised courses of action and deliverables. We control our way of working and in that way we become committed to delivery and to success. We are autonomous regarding how to reach our commitments.

Integrity/Honesty We do the right things in the right way for the right reasons. We are honest and keep our promises. We say what we do and we do what we say.

Together We create an environment where each individual in the team is working towards the same goal with open and effective communication by supporting, encouraging, coaching and teaching one another. We rely on each other and value team above individual performances.

Creativity We proactively identify creative, efficient and effective ways of working. We think outside the box and we color outside the lines when required.

Responsibility We take great pride in what we do and how we do it. We stand out from the crowd just by being very good at what we do and back it up by realized actions and results.


35

1.


36


37

Roles & Scrum Structures

Roles & Scrum Structures


38

Scrum Roles 5 Roles There are three core roles and a range of ancillary roles. The core roles are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project). They represent the Scrum Team. Although other roles may be encountered in real projects, Scrum does not define any team roles other than those described below.

Product Owner A part of the Product Owner’s responsibilities is to have a vision of what he wants to build, and share that vision with the Scrum Team. That is key to a successful start of any Agile product development project. The Agile Product Owner does this partially through the product backlog, which is a prioritized list of features for the product.

The Product Owner is the business representative for the product development team. His subject matter expertise and the vision helps the Product Owner make crucial decisions about the product -- whether or not a given feature is required, whether or not it is needed right in the first version, and so on.

The Product Owner works closely with the team and helps them throughout sprints, in understanding constraints, mitigating risks, giving clarifications and etcetera. The Product Owner should be empowered: he has the stakeholders' mandate and trust; he can make decisions by himself. This prevents slowdowns due to decision-making delays.

Though the Product Owner prioritizes the product backlog through the Sprint planning meeting, the team selects the quantity of work they will do during sprints and what number of sprints will probably be required.

Scrum Team The Scrum Team is responsible for delivering shippable increments of product functionality at the end of each Sprint (the Sprint Goal). A team is made up of 3–9 individuals with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etcetera.). The Scrum Team is self-organizing, even though there may be some level of interface with the Agile Program Management.

5 Some parts based on this page from Wikipedia (http://en.wikipedia.org/wiki/Scrum_(software_development)#Roles)


39


40

Scrum Master Scrum is facilitated by a Scrum Master, who is responsible for removing impediments which prevents the team from delivering the sprint goal and features they committed to deliver. The Scrum Master is not a traditional team lead or project manager, but acts as a buffer between the team and any distractions. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of the rules of Scrum, often chairs key meetings, and challenges the team to improve. The role has also been referred to as a servant-leader to reinforce these dual perspectives.

The Scrum Master supports the Product Owner and team, protects the team and the process, and intervenes appropriately when required. This ensures that the ‘heartbeat’ of work is sustainable, that the team stays healthy and motivated and that building up technical debt is prevented. The Product Owner and Scrum Master roles complement each other: The Product Owner is primarily responsible for the “what”— creating the right product. The Scrum Master is primarily responsible for the “how”—using Scrum the right way.

Only when the right product is created with the right process, enduring success can be achieved.

The Project Manager There is no role of project manager in Scrum; because none is needed. The responsibilities of a project manager have been divided up and reassigned among the three Scrum roles; mostly to the Product Owner and the Scrum Team.

• The team takes on the task of identifying, estimating, and managing the stories and tasks. • The Product Owner, for instance, is accountable for managing the (release/product) scope and date,

managing the budget, communicating status, and managing the stakeholders.

Practicing Scrum with the inclusion of a project manager indicates a fundamental misunderstanding of Scrum. This typically leads to conflicting responsibilities, unclear authority, and sub-optimum outcomes. This doesn't imply that the people working as project managers are no longer needed. On the contrary: former project managers often can become great Scrum Masters and sometimes can successfully transition into the Product Owner role.

Further reading If you want to learn more about Agile/Scrum, the fun way is: http://scrumtrainingseries.com


41

Product Owner training (top)

Team at sprint demo (below)


42

Glossary of Scrum Terms User story User stories are the primary way to influence the functionality of the product being developed. They describe the functionality from the perspective of the user and state the goal.

Prioritized product backlog The Product Backlog contains the list of stories. The product backlog order represents the urgency of a story.

Definition of Done A list of criteria, which must be met before a user story is considered "done".

Sprint An iteration of work during which an increment of product functionality is implemented

Sprint planning Determine sprint Backlog (Team + PO), and make things clear to both the Scrum Team and the Product Owner.

Sprint Backlog List of stories the team has committed to implement in the current sprint

Daily stand-up Team members tell about what they accomplished yesterday; what they will do today and obstacles that are impeding progress (impediments). And most important, will the team reach the committed sprint goal.

Sprint Goal Sprint goals are the result of a negotiation between the product owner and the development team. Meaningful

goals are specific and measurable (i.e. "Can handle 5 times more users than previous version"). While some specific product backlog items may not be done at the end of a sprint, it should be very unusual for a team not to meet its sprint goals.

Sprint Burndown Chart A sprint burndown depicts the total task hours remaining per day. This shows you where your team stands regarding completing the tasks that comprise the product backlog items that achieve the goals of the sprint.

Product backlog refinement The process through which product backlog stories are reviewed and revised, providing more detail and ensuring that there is greater clarity in the requirements for that stories. Mid-sprint, this is the PO’s opportunity to provide the rest of the Scrum team with the vision for the next sprint. Sprint Review Meeting The Scrum Team shows what they accomplished during the sprint

Sprint Retrospective Meeting The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint.

Velocity Velocity is how much product backlog effort a team can handle in one sprint (estimation based on previous sprint)

Scrum Space Room or virtual space, which shows the all SCRUM & product aspects in visuals.


43


44

The Challenging Product Owner Role While the Scrum Master is the person who ensures that the team is working together, that impediments to progress are quickly removed and that the team is moving efficiently toward its goal, the Product Owner is the person who makes sure the team is aimed at the right goal. A good team needs both roles to succeed. The Product Owner points the team at the right target; the Scrum Master helps the team get to that target as efficiently as possible.

The Product Owner has the authority to set a goal and shape the vision. The Product Owner is not just a project manager who now also writes requirements and does a little bit of prioritization. If you think of the Product Owner as the provider of a team’s goal, this helps make certain aspects of the Product Owner’s job clear. For instance, the Product Owner is responsible for defining and prioritizing the product backlog to reach the goal. Similarly, the Product Owner is responsible for making sure the project earns a good return on investment.

Responsibilities of the Product Owner Compiling an exhaustive checklist of the responsibilities of the Product Owner is not easy: each product exists within its own context of personal and team competencies, company culture and outside (market) forces. This strongly influences how the Product Owner has to act. So instead of providing a checklist of Product Owner responsibilities (“Look after the budget”, “Attend stand-up meeting”), it is more helpful to think in terms of two things that a Product Owner must share with the team: a vision and boundaries.

Providing Vision Many of the Product Owner’s responsibilities involve establishing and communicating the vision for the product. The best teams are those whose passion has been ignited by a compelling vision shared by the Product Owner. Who will we be selling to? What is unique about our product? What are our competitors doing? How will our product evolve over time? Of course, the questions are different for an application or service that is being delivered to a group of in-house users, but having a shared vision is important for motivating a team and creating a long-term connection between those developing the product and those using it.

Besides providing a good product backlog, the Product Owner adds detail to the vision by communicating with team members and answer questions they could have: How can we work together? What did you imply when you said such-and-such? This way the team will help create better products together with the Product Owner.


45


46

Providing Boundaries Vision and boundaries can be thought of as competing aspects of the project.

The vision shows what the product can become. The boundaries describe the (changing) realities within which the vision must be realized.

Boundaries are provided by the Product Owner and often come in the form of constraints, such as

• I need it in two months. • The website can have a load time of 2 seconds maximum. • We need to reduce the server-maintenance costs by half. • It must have twice the concurrent user capacity of the current version. • The app must look good with a screen resolution of 1024x768.

Time boundaries You can expect the Product Owner to dictate things such as this—especially the date—because the Product Owner is also responsible for defining the boundaries that will determine the success of the product. Most experienced Scrum team members will agree that it is okay for the Product Owner’s to say, “We need to develop at least this much of the product backlog or the product won’t be worth selling.” But many of these same experienced people resist when similar statements are made about deadlines...

The Product Owner’s job is to create the boundaries in which the team will think. These boundaries prevent the team from getting lost in important constraints for the business.


47

The Product Owner’s job is to create the boundaries in which the team will think.


48

Scaling Scrum Scrum of Scrums The Scrum of Scrums meeting allows multiple teams to coordinate on a regular basis throughout the sprint. Team representatives meet after their teams’ Stand Ups to discuss the status quo, the work planned, and any dependencies between the teams. Note that this meeting is tactical in nature. It cannot compensate for a lack of sprint preparation work, such as planning ahead.

Dependency planning; each trajectory on the left has his own color; epic planning plotted over time.


49

Scrum of Scrums


50

Our roadmap to value

51



52

Building our Roadmap to Value Realizing customer value, with lots of innovative new insights, and delivering it just in time (or even better: delivering early), doesn’t happen overnight. It needs meticulous planning, autonomy, experience and trust. The complexity increases in situations where teams want to deliver value to multiple product roadmaps at the same time.

Interactive layers for planning the roadmap Planning the roadmap involves four interactive layers:

1. Vision and strategy 2. Product Portfolios 3. Product Backlogs 4. Scrum Teams

1 Vision and strategy The starting point is a company vision and strategy, which is the highest level of value proposition and is mostly crafted in vision statements. In case of NEBM, we support multiple vision statements of new business initiatives, which have diversified business objectives. The common denominator in reaching these vision statements is a faster time to market, flexible and cost efficient solutions, high quality and early customer feedback.

Although there is no unified vision statement, a diverse spectrum of business objectives can still be achieved. Mostly these are captured in product- or project portfolios, managed by Product Managers and/or Product Owners. For achieving the optimum in delivering business value, NEBM has to manage dependencies between the portfolios. In this stage, the primary content of the roadmap to value is comprised of the business value and metrics the products will deliver.

2 Product Portfolios The product- or project portfolios amplify the unique value propositions to be achieved. Integrated roadmaps of products that all contribute to business objectives. In the case of NEBM Agile development, we see a product (or ‘project’) as a trajectory for its complete life cycle, we do not differentiate in subsequent projects within the lifecycle. We combine the diversified product- or project portfolios of all emerging business areas, and prioritize together with the subsequent product owners to compose accurate and prioritized product backlogs.

Our roadmap to value now includes a high-level list of features and capabilities that enables the business value we want to realize. This is a list with features that everyone is willing to build!


53


54

3 Product Backlogs Within NEBM we deliver predictable value in each sprint cycle, over and over again, in stable teams, without the interruptions of ending a project with an experienced team and starting another one just a few months later. We call this path of incremental value realization: the path of continuous delivery.

With our continuous delivery path, we release value incrementally via a common backlog per feature team, which is created with a lightweight design approach. This means we start by adding the general capabilities we want to offer and incorporate them in end-2-end value chains in combination with the landscape architecture. This is a team activity in combination with direct stakeholders who are part of the end-2-end value chains. The direct result is a shared view of the realization trajectory for the team and its stakeholders, and helps the Product Owner in prioritizing the backlog. The backlog can now be refined in themes, epics and stories and prioritized by means of a skeleton approach in direct value creation. More complex stories, which cannot be split in easier tasks, are viable for enabling designs: short visual explanations as part of the design preparation of a sprint cycle.

Our roadmap to value now includes a minimum viable product (high prioritized backlog stories); we are ready for value delivery!

4 Scrum teams The scrum teams work with refined product backlog stories with an unambiguous definition of done; what user or stakeholder need will be served, how will it specifically look or behave? Enabling design and prototypes can be used to clarify the end result, which is obtained by the Product Owner. Stories are then estimated in poker points and committed to a sprint. Stable teams focus on only a few things at a time.

The Product Owners prioritize amongst the product backlogs and gives focus to the teams. With multiple scrum teams there will always be dependencies. A dependency has to be controlled and teams need to work together to build beyond the stakeholders’ expectations. Via the “scrum of scrums”, where each team is present to discuss dependencies, we eliminate roadblocks and prioritize amongst Product Owners (if necessary). Also, a lot of dependencies are dealt with within the feature teams or across scrum teams “on the fly” during sprint execution.

Because of these processes, the teams are capable of delivering customer value faster with a higher degree of stability and predictability. The team’s performance (velocity) can be measured by the delivered story points or delivered stories, which are ‘done’ within or at the end of the sprint cycle.

Product Owners can ‘pull’ the delivered stories towards a production environment and have the ability to directly measure customer value. This can serve as direct input for the product portfolios and product backlogs in the sprints ahead.


55


56

Go live with the minimal viable product A minimum viable product (MVP) has just enough features to allow the product to be deployed.

minimum viable versus minimal A minimum viable product is not to be confused with a minimum product. It is better to think of an MVP as a product with a minimum feature set. The minimum features depend a lot on the market that is targeted.

A minimum product could be a product that nobody wants (try to avoid that). A minimum viable product is typically deployed to a subset of possible customers, such as early adopters that are more likely to give feedback or are thought to be more forgiving and able to grasp a product vision from an early version.

For a startup or new product development, the goal is to find the most beneficial overlap between minimal and viable. You want people to love the product with high return on investment, while balancing the (investment) risks you have to make.

Sizing the MVP can be tricky. A little bit of working functionality is better than a lot of functionality that does not work. Try to stick to the definition: minimal AND viable.

Product Vision MVP Iteration


57


58

The Product Backlog The product backlog is very simple: an ordered list of the remaining work necessary to bring the product to life and support it throughout its lifecycle. The product backlog is used to:

• Capture requests for modifying a product, i.e. from customer feedback, product managers or owners. This can include adding / removing features and fixing issues

• Ensure the delivery team is given work which maximizes the business benefit to the owner of the product

The Product Backlog does not contain "user stories"; it simply contains items. These items can be expressed as user stories (e.g. requirements/features), bugs, research tasks (spikes) and engineering improvements or any other way that the scrum team finds useful. 6

The Product Owner is responsible for managing the product backlog; the Scrum Master, team, and stakeholders contribute to it; they coauthor stories and help the PO prioritize.

• For ease of reading, we call all these items stories, since they can be treated the same in respect to estimating size and prioritization.

• Whatever the approach, delivery value to customers is what matters.

The product backlog has four qualities: 1 Detailed Appropriately The product backlog stories are detailed appropriately; Higher-priority stories are described in more detail than lower-priority ones.

2 Estimated The product backlog stories are estimated.

3 Evolving The product backlog has an organic quality. It evolves, and its contents changes as new information surfaces about the product and its customers. Existing stories are modified, reprioritized, removed as appropriate.

4 Prioritized All stories in the product backlog are prioritized. The highest-priority stories are implemented first. Once a stories is accepted as “done”, it is removed from the backlog.

6 Based on this page from Wikipedia (http://en.wikipedia.org/wiki/Scrum_(software_development))


59

Excel: Prioritized list of epics Converts to a backlog in JIRA


60

Refining the product backlog The backlog needs regular attention and care: it needs to be refined. Stories are reviewed and revised, providing more detail and ensuring that there is greater clarity in the requirements for that particular story. Best practice is to have mid-sprint session, led by the Product Owner. This is the PO’s opportunity to provide the rest of the Scrum team with the vision for the next sprint. Refining the product backlog is an ongoing process that comprises the steps listed below.

• Create new user stories in response to new insights or newly discovered needs • Existing stories are changed as appropriate or removed if no longer relevant • Order the product backlog. The high priority stories are now found at the top. • The high-priority stories are prepared for the next sprint planning; if too large, they are decomposed

into smaller stories. • The team estimates product backlog stories: assign estimates to stories that are newly estimated or

adjust existing estimates if needed.

Although the Product Owner is responsible for a healthy backlog, refining is a joint process with the Product Owner, Scrum Master and team; stakeholders are involved as appropriate. Stories are discovered and described, prioritized, decomposed, and refined by the entire scrum team. In Scrum, 5-10% of each Sprint should be spent on refining the Product Backlog. Requirements are no longer handed off to the team; rather the team members are co-authors. The Product Owner, Scrum Master and team engage in face-to-face conversations rather than communicating via Hipchat, mail or otherwise.

Although 10% seems like a lot of time, refining the backlog together is very effective. It creates interaction within the scrum team itself and the team with the PO and other stakeholders involved. It removes the line between “the business” and “IT”; scrum = business+IT.


61

High level estimation


62

Sprint Planning and Daily Standup Preparation In the week prior to sprint planning meeting, the user stories at the top of the product backlog have to be prepared by the Product Owner for the upcoming sprint. At Alliander we use sprint goals to set a theme for sprints. It helps us in increasing the chance that we will end up where we wanted to go.

Defining the sprint goal The sprint goal summarizes the purpose of the sprint. If the goal is met, the demo at the end of the sprint should result in the Product Owner having a big smile. The goal helps the team to deliver incremental value. Remember that the goal should give the team some flexibility regarding how features are implemented within the sprint.

Sprint goals are useful for a number of reasons:

• Product Owner, Scrum Master and team are working towards a common goal. • Sprint goals connect the focus of a single sprint to the product as a whole • Sprint goals link a sprint to the expected work in future sprints • Sprint goals help in reviewing the stories on top of the backlog

Selecting a sprint goal can result in changing the priority of stories on the backlog.


63

Sprint demo (Google Hangout)


64

Prepare just enough stories Once the sprint goal is chosen, the product owner prepares just enough stories for the next sprint. Because of changing realities, best time for preparation is…as late as possible. The refining activities in the current sprint focus on the stories for the next sprint. This approach, detailing only the features that are likely to be chosen for the next sprint, helps the backlog to evolve sprint after sprint.

Avoid big stories. Getting the stories ready for the sprint planning meeting requires decomposing large stories until they are small enough to fit into a sprint. Promoting stories to epic may help. Epics are large stories, split into smaller stories. Stories can be completed in a sprint; epics may span multiple sprints.

How many stories should be prepared depends on the team maturity. Best practice is to prepare extra stories for that come in handy when the team’s (or specialists within) have room for more stories than they committed to. These could be low priority stories that don’t relate to the sprint goal but have to be done sometime anyway.

Sizing stories and tasks Estimating stories and tasks allows us to think about their size and the likely complexity necessary to realize them. Estimation facilitates prioritization, and allows us to forecast the products progress.

There are two different estimates:

1. fine-grained estimates in the sprint backlog communicating the size of a task, usually stated in hours 2. rough estimates in the product backlog indicating the rough size of a story in points

The next section discusses the second: sizing the stories in the product backlog.


65

Backlog priority


66

Story points Story points are rough, relative measures of raw effort and size. A story worth one story point is half the size of a story worth two points. A story sized as three points requires as much effort as a story with one point and a story with two points added together. Relative measures take advantage of the fact that size itself is relative; the semantics of big and small depend on our reference point. Often the Fibonacci sequence is used as the amounts of points that can be given: 0, 1, 2, 3, 5, 8, 13, 21 etc… You will quickly see that everyone has a basic understanding of the complexity of stories.

It is recommended to use story points instead of hours because a team can increase the amount of work that can be completed within a timeframe: it “burns” more points per hour. This insight can be used to create a long-term insight in the performance of a team. The benefits of this are discussed in greater detail in the chapter “Lifecycle metrics”

Poker During the planning meeting, the team gathers to attribute an amount of points to every user story that has to be completed. For example, a simple story is attributed 1 point and a difficult story gets 13 points.

During this poker session, every team member first decides for himself how many points to attribute to a story. When the amount of points of two team members differ, the reasons are discussed and the story is re-pokered. Hereafter the points often converge to a single quantity.

Based on the points, the team can commit to an amount of stories to work on in the next sprint.


67

Feature team sprint planning meeting


68

Sprint planning meeting The sprint planning meeting allows the team to commit to the sprint goal and plan their work. It's the Product Owner’s responsibility to make sure the product backlog is well refined prior to the sprint planning meeting.

During sprint planning the team determines how much can be done in the sprint and how to realize the goal. It is the Product Owner’s role to help the team understand what must be done. The Product Owner is not authorized to tell the team how much work should be pulled into the sprint or to identify tasks on behalf of the team.

Scrum cadence The team should commit to only as much work as it can realistically deliver. Limiting the amount of work per sprint to the team’s capacity and capability creates a sustainable pace: there is little benefit in trying to achieve an overly ambitious goal in one sprint only to be exhausted in the next one.

That the product iteration is called a sprint, doesn’t suggest the team should sprint in a rush towards to goal; rather it is about dealing with changes. A sprint in Rugby is a distance an athlete would travel from one place to another. Before an athlete would sprint, the team shortly come together and plan the best route. During the sprint, if the athlete would encounter opposition he might stick with the plan or more likely change the plan; if that is for the better. You can anticipate but not predict hurdles you’re going to encounter. A sprint is not just a product iteration, it tests if the team is a team, that they are good or not and their ability to respond to change.

Scrum favors a smooth, steady flow of work from the product backlog into the sprints, we call this the scrum cadence. Reliability is more valuable than false ambition; it is the prerequisite for making realistic forecasts.

Beware that a commitment is not a guarantee. It can take a new team two to three sprints to learn how to make commitments it can meet. Plus, product development is full of unknowns; uncertainty and risk go hand in hand with innovation. Working hard without reaching the sprint goal happens—but it should be an exception. If it does happen, use the sprint retrospective to identify problems and their causes, and to discover improvement measures.


69

Stakeholder meeting


70

Definition of Done How does the team know that work is done? And how can the Product Owner decide whether a story has been successfully completed? The solution is to agree on the definition of done—a description of the criteria every increment must fulfill. The done criteria typically require product backlog stories to be transformed into working software that is thoroughly tested and adequately documented. Features are consequently implemented, tested, and documented in the same sprint.

Prior to the first sprint, the Product Owner should meet with the Scrum Master and team to create a definition of done that includes the properties every increment must fulfill. Examples would be:

• Jenkins built version on Acceptance Environment and all tests green • -Ok from Product Owner

If specific stories should meet additional criteria, then those criteria can be included in the story as a remark.

Daily Stand-up The Daily Standup (or Stand-Up Meeting) allows the team to manage its work (“will the sprint goal be met?”) and uncovers impediments on a daily basis. The Product Owner should attend the meeting whenever possible. It’s a great opportunity to understand the progress being made and to see if the team needs help (for instance, the product owner might need to answer questions, review in-between results, or help remove impediments). He can also share information and update the team on what he has been working on and is planning to do next. Everyone besides the team attending the Daily Standup should be careful not to interfere with the team’s self-organization. Do not identify or assign tasks, and do not make any comments on the progress achieved by individuals— out loud or through body language. If a stakeholder is concerned about the progress, he should share his view in a constructive manner, perhaps by asking questions. If the Product Owner is worried about meeting the sprint goal, for instance, he can say, “I noticed that the sprint backlog shows a lot of tasks left to do. Is that something of concern to you? Will the sprint goal be met? How can I help?”

Impediment Management Scrum puts an emphasis on impediments management—recognizing and treating problems that impede progress and harm the project. Team members discuss impediments in the Daily Standup, and the Scrum Master ensures that they are resolved as quickly as possible. Even though dealing with problems can seem to slow down the project, it avoids bigger issues and bigger delays later on. Problems provide an opportunity to learn and improve.


71

Sprint Review Meeting


72

Sprint Review & Retrospective Sprint Review meeting The sprint review meeting energizes the process of developing a successful product. This is where the results of the sprint are shown: the work that the team has completed is demonstrated and is assessed against the sprint goal. Sometimes this meeting is called the sprint demo meeting. But it’s more than that; it’s also to see if the product development is going in the right direction: stakeholders can review and provide feedback.

The Product Owner kicks off the meeting. Work done is typically introduced by the Product Owner (this can be done by a list of stories, organized in a narrative fitting the sprint goal). For the demos the team can nominate a member to present the demo or share the task, with individuals demonstrating the particular parts of the features. At Alliander, some teams have the Product Owner demo some of the front-end stories; the ultimate proof that the story has met his expectations. This works very well and adds to the interaction in the form of joint demo-preparation.

The Product Owner only accepts product backlog stories that comply with the definition of done and fulfill the acceptance criteria. For example software code that has been written but not tested is considered not done. These stories earn zero story points for the statics and are returned to the product backlog and ranked according to (revised) priorities.

In the review meeting, everyone can give feedback. Giving feedback can be challenging; give a clear and constructive message to the team, not individuals, when you provide feedback. It is the meeting to react on stories that could be visualized for the first time. A piece of functioning software is what is needed to most people to discover what they will actually want.

Manage stakeholder expectations The expectations of what is shown in the demos sometimes should be managed before the review; In the first sprints early increments might look different than what the final product should look like. Maybe stakeholders expect to see features that are still on the product backlog and they have to wait a few sprints to see the results.

During the review, the stakeholders are asked for feedback on the product(-increment).Do they like what they see? Is functionality missing or is there too much functionality? Is a feature implemented incorrectly? It is not unusual to discover that a change of scope is necessary. If the Product Owner feels that the newly discovered scope is more important than the original expectations, new scope displaces old scope in the Product Backlog


73

Demo: Developer (right) shows his work to the

Product Owner (left)


74

The Sprint Retrospective Each Sprint ends with a retrospective where the team reflects on its own process. They inspect their behavior in retrospective and take action to adapt it for the next sprints. When done well, retrospectives are often the most beneficial meetings for the team.

Sprint retrospectives allow the Scrum Team to inspect how efficient the work is carried out. This meeting is facilitated by the Scrum Master. He helps the team to identify problems and causes, and to discover improvements that will make the work more effective and fun. Some will be within the influence of the team; other (like organizational impediments) will be within the influence of the Scrum Master.

It is human tendency is to jump to conclusions and propose actions too quickly. A series of steps to slow this process down is: Set the stage, gather data, generate insights, and then decide what to do.7

Where the review meeting is a change to inspect and adapt the product (with feedback from the PO and other stakeholders), the retrospective is a change to inspect and adapt its process. It is the key the use scrum as a framework for learning rather than to keep everything as it is. Only learning teams will thrive. It is the Scrum Masters role to create the conditions for such a learning team.

Good Retrospectives have these characteristics:

Focus on the team rather than individuals The team’s Definition of Done is reviewed against the demo and can be adjusted (expanded)

appropriately A list of actionable commitments is created The results of the previous Sprint Retrospective are reviewed The retrospective is relevant for all attendees

7 Read more on retrospectives in Agile Retrospectives, Derby/Larson (2006)


75

Sprint Review


76

Quote: Peldi Guilizzoni Photo: http://www.flickr.com/photos/betsyweber/5056456666


77


78

Sharing our journey

79

Sharing our journey

Sharing our journey

80

Collaboration Model A major contributor to successfully implementing ‘our way of working’ has been the redefinition of the collaboration model between the product managers, Product Owners, Agile Scrum Teams and also the classic functional- and technical maintenance teams. Because value is delivered throughout this end-2-end chain of product lifecycle management, it has to be set up in the right way.

Demand-supply approach Being part of a traditional demand-supply organization, with fixed in-advance (budget) planning and a waterfall project approach, tollgates and execution steps, makes it hard to embed an Agile way of working. Especially when Agile methodologies are perceived as just an IT way of developing software. The drawbacks of the waterfall approach are eminent; customer value creation only at the end of the implementation stage, late customer feedback, inability to adjust the delivered features along the way and a high-risk profile. Just as the waterfall approach is lacking in the flexibility and early customer feedback department, the demand-supply structure is deluding their proponents into thinking that tools and processes solve the problems; instead of people and their interactions. That is why working collaboratively across role and function is best obtained in a multi team-scaling pattern, together with an Agile governance structure.

Agile Governance structure Changing the structure needs pioneers, people with mandate whom are able to lead the creation and facilitation of the portfolio management system. A portfolio management team, including a Chief Product Owner and a Chief Scrum Master will help to prioritize the creation and to manage the Scrum Teams at scale.

Transformational patterns can be used to move towards an Agile Governance Structure:

Waterfall, demand-supply approach Agile Governance structure Business Portfolio Manager and IT Delivery Manager Agile Portfolio Management team Create a project plan, then measure success (according to plan)

Define project constrains, maximize value and quality within those constraints

Project manager, day-2-day project plan management Scrum Team roles: Product Owner, Scrum Master & team Centralized control organization, top down with reporting Decentralized decision-making Handover from Development teams toward Maintenance team

DevOps teams without handovers

Centralized budget planning in advance Budgeting for Scrum projects Project overload by people, budget or scope creep Continuous Delivery Paths Top down project estimations and breakdown structures Scrum refinement and planning poker Detailed functional and technical designs Lightweight envisionment with enabling designs

Sharing our journey

81

Sharing our journey

82

Approach Summary Preparing for development and delivering value for our customers Customer needs and product features are at the heart of the vision. By focusing on the needs, we view the product as a means to an end— serving the customer. Product characteristics, on the other hand, are the critical properties the product must have in order to meet these needs. A touch screen, for instance, is a product characteristic. The underlying need for that characteristic is likely to be ease of use.

Characteristics can be of functional or nonfunctional nature. Functional properties are specific product features, such as being able to make or receive calls. Nonfunctional characteristics include performance, design, and usability. Nonfunctional characteristics can be an important differentiator—they can impact the user experience as well as the extensibility and maintainability of the product, which in turn influence the total cost of ownership and the product’s life expectancy.

Vision to solution Characteristics guide the team by constraining the solution space—the set of all possible solutions. By stating customer needs and detailing a minimum set of product characteristics, we connect needs to the technical solution, placing the customer at the center of our product development effort. Separating needs and characteristics allows us to investigate both why the product is required and also what the product should look like and do. It makes it possible to explore different attributes to find out which one is best suited.

Experiments, prototypes and mock-ups At the start of a new project, we often do not know what we don’t know. Worse, our target customers and lead users don’t know what they don’t know; they are not in a position to tell us correctly what the product must look like and do up front. Creating the vision is therefore best understood as a discovery process, a process of knowledge acquisition and learning that requires experimentation. Experimentation examines the relationship between cause and effect, manipulating the cause until the desired effect has been achieved. The key to effective experimentation is to generate the necessary knowledge rapidly by implementing and testing prototypes and mock-ups. These act as vehicles of knowledge creation and learning. They help us understand what the product should roughly look like and do, what technology and architecture options are viable, and if the idea is actually feasible. Prototypes are usually throwaway artifacts that can be created quickly and inexpensively; sketches made with MS Paint or copy-pasting in PowerPoint of Pages are often sufficient to test an idea!

Sharing our journey

83

Visualization of front-end stories

Sharing our journey

84

End-to-End Business Flows End-To-End (E2E) Business Flows are business processes that span core business missions. E2E Flows always relate to the customer. E2E flows contain Processes, Roles, Applications and their interactions

Defining E2E Flows

1. Define exhaustive list of all E2E flows

2. Describe Processes

3. Describe Roles & interactions

4. Describe Applications & interactions

Example Energie Atlas

1. Energie Atlas Project E2E Flows

• Campagne cash • Klantinitiatie locatie • Locatie Individuele

meetdata • Individuele meetdata

aggregatie • Aggregatie Presentatie • Contact Service

2. Processes • Contact customer; Offer;

Contract; Register; Bill

3. Roles • Sales, Marketing

4. Applications • SAP, SalesForce

Examples of E2E flows

• Acquire-to-Retire • Aggregation-to-

Presentation • Campaign-to-Cash • Concept-to-Product • Contact-to-Service • Data-to-Information • Deployment-to-

Redeployment • EnergyData-to-

Aggregation • Fulfillment-to-Locations • Information-to-

Presentation • Locations-to-EnergyData

• Market-to-Prospect • Order-to-Cash • Proposal-to-Reward • Prospect-to-Order • Service Request-to-

Resolution • Service-to-Satisfaction

Sharing our journey

85

Sharing our journey

86

E2E Process Chain design-sessions For each E2E Business flow, a detailed process chain is made with input from all roles (department-delegates) & applications (subject matter experts) involved.

This result is a common view among all parties involved and a detailed process chain per E2E flow. Important artifact is a list of all things unclear. Next step is to combine the individual process chains to one process chain landscape overview.

Creating a Process Chain Diagram A Swim lane diagram is the best diagram to illustrate process flow through the organization. A process flow consists of a set and series of interrelated work activities that follow a distinct path as inputs get transformed into outputs that mostly add value for the customer. We use a swim lane diagram because:

• It shows a beginning and an end; the entire workflow at a glance • It highlights customer touch points and makes relations with our customers visible. • It shows the activities and where they take place. • It illustrates organizational / system handoffs. (i.e. manual processes.)

Sharing our journey

87

Sharing our journey

88

Visuals to Stories

Front-end mock-up

• Look & Feel clear for everybody involved • Helps in creating themes & user stories for Front End development

Early stage design mockups (flash, clickable)

Process-chain-landscape-overview

• Generates topics which need enabling designs • Helps in creating themes & user stories for integration layer & back-end systems

Sharing our journey

89

Front End Design (Mock-up)

User Stories Front End User Stories for Integration & back-end

Landscape overview

list of items which need enabling designs

Sharing our journey

90

Sharing our journey

91

Story dependencies

Sharing our journey

92

Enabling designs

Stories on top of the backlog will be detailed Just-In-Time. While that is okay for most stories, some stories are part of a bigger theme that is essential in the vision of the product. Probably those ‘themes’ were already addressed in a grooming session and they require a solution.

Because requirements evolve throughout the project, Big Designs Upfront could lead to corrections later on in the project, so model just enough for the sprint ahead. Reference to the solution design in the related stories and the developers get the bigger picture.

Enabling designs allow for getting ready in sprint 0 and development next sprints.

If the environment is not ready or design is not complete, the Scrum Team has to design or organize…while they should be developing!

Enabling designs are created up-front so that design-decisions are made before development. "Enabling designs" means that the design is rich enough so that someone reasonably skilled in the discipline can implement a solution without substantial subsequent clarification. If it is not, there needs to be a continued dialogue with the Product Owner during the sprint to figure out what the story means. This will reduce story process efficiency and cripple velocity.8

8 Jeff Sutherland “Enabling Specifications: The Key to Building Agile Systems” (http://www.scruminc.com/enabling-specifications-key-to-building/)

Sharing our journey

93

Enabling design: Pseudonymization architecture

Sharing our journey

94

ET Acceleration Platform, a Generic Platform Strategy After having executed many siloed pilots in preceding years, in 2012 and 2013 a more focused approach for IT delivery for pilots and Proof-of-Concepts was taken. Since the summer of 2014 this approach resulted in a generic innovative platform, which enables Alliander to separate stable generic backend logic from fluent rapid changing customer services. We call this generic platform ET Acceleration Platform (ETAP). All new innovative IT stacks within Alliander are established according to this model.

What does ETAP enable? ETAP enables various business partners to execute their strategies. At the heart of the approach are the following business principles:

• Fast Time-to-Market • Distinction between Innovation and Production • Future-proof: taking care of Scalability • Fast Deployments: focus on new, to be tested subjects instead of re-inventing known wheels • Market role distinction • Sound Privacy & Security

A Faster Time-to-Market is enabled by focusing on customer-facing applications instead of an entire IT stack per product. Because the ETAP generic functions are already available and ready to roll, it is now much faster to connect new customer services using ETAP than building them in a silo and from scratch. In detail, these generic functions include: Identity and Access Management, Customer Relationship Management, Application Program Management, Service Bus and Orchestration, Data Management and Business Process Management. Of course other integrations are possible.

Many traditional vendors have issues with this setup, since their architecture is based upon tying in customers on their (expanding and expensive) stack. We are realizing this by decoupling of front- and back-end via standardized and re-usable web services. Using modern Open Source IT components. Sometimes very innovative IT solutions are required, since present IT solutions obviously do not offer the (foreseen) functionality or technicality. Cost efficiency is obtained by creating manageable environments and re-using existing components.

ETAP is built, maintained and deployed with an Agile (Scrum) Way of Working; establishing a sound delivery organization embedded in the Agile Governance Structure.

Sharing our journey

95

Sharing our journey

96

Implementing Continuous Delivery Making Continuous Delivery work Customers want new features, they want them fast and they want them tailored to their specific situation. We, at Alliander, want a quick confirmation of business ideas with our customers, deliver high quality products with maximum value and we want a deployment process that we can rely on and that’s always predictable.

We validate our business ideas by having a product development process that is completely repeatable and so reliable that it sends a continuous flow of new features to our customers. This process adheres to the following principles:

• Automate everything • Done is live • When it hurts, do it more often • Quality is key • Improve continuously • The whole team is responsible for the product

To achieve Continuous Delivery and follow the principles, we need to close the traditional gap between development and operations. We do this using a DevOps approach.

Continuous Delivery pipeline We use Jenkins as the Continuous Integration tool for the realization of the automated deployment pipeline. Versions of the software are automatically deployed to Test-, Integration and Acceptance environments. We do not automatically deploy to production; a manual ‘click’ is necessary. For E-atlas the automated deployment pipeline is operational for the front-end GUI, Measurement-Data-Management backend and API’s.

Code Done Unit tests Integrate Acceptance

test Deploy to

production

automatic automatic automatic manual

Sharing our journey

97

Sharing our journey

98

Automated Testing The deployment itself can be reliable; whether software code is good or bad. Automated tests can be created to guarantee the quality of the new software. These tests must succeed before automated deployment continues. For E-atlas automated tests are in place for

• The creation of organizations, users and roles • Importing the housing configuration • Energy measurement API’s (Application Interfaces)

DevOps DevOps ("development" combined with "operations") is a software development method that stresses collaboration and integration between software developers and ICT professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

At Alliander we use a DevOps approach to support Continuous Delivery. The specific goals of a DevOps approach span the entire delivery pipeline, they include improved deployment frequency, which can lead to faster time to market, lower failure rate of new releases and shortened lead time between fixes. A DevOps team is responsibility for the complete pipeline and thus the complete lifecycle of a software product.

The DevOps approach grants developers more control of the environment, giving infrastructure a more application-centric understanding. DevOps aids in software application release management for an organization by standardizing development environments.

Challenges Education of Continuous Delivery principles is a challenge. It is a new way of working and if not addressed as such, this could lead to basic misunderstandings of the terminology, principles and practice of Continuous Delivery. Sometimes Continuous Delivery and DevOps are thought to be the same thing; they are interdependent, but not equivalent.

Some organizations seeking to apply Continuous Delivery focus on improving working practice, but to really embrace Continuous Delivery, organizations must ensure that their employees encompass its primary principles. Continuous Delivery adoption is possible if management is committed and developers and engineers are willing to change the way they work.

Sharing our journey

99

Sharing our journey

100

Lifecycle Metrics Velocity Story points are useful for more reasons than as a pure estimation method: when used correctly and consistently they can also be used to create an overview of the effectiveness of teams over time. At the start of a project, a team has to get used to the subject-matter and possibly to each other. Let’s assume they start out by completing 5 stories, worth 40 points in total. After a few sprints, they will be better acquainted with each other and the subject matter and completed 7 stories, worth 60 points in total. Both sprints were completed in the same amount of time. When the amount of points completed is tracked, the team gains insight in their “velocity”. This is useful information during the poker session because it gives a handhold as to how many points they can complete in a sprint. Usually the velocity of a team increases over time: they become more effective.

When a team is changed, for instance by the introduction of a new team member, it takes some sprints to find a new balance: the effectiveness of the team will probably decrease and the way the new member estimates can differ. Eventually a new balance will be found.

Burn-down rate The scrum master can create burn-down charts of the velocity of the team to gain insight in the “burn-down rate” of the team. Ideally this increases over time. In reality however, a team can temporarily get less effective: they still work full-time on stories but their velocity decreases. The scrum master can signal this by updating and checking the lifecycle metrics periodically. He can then take action to identify impediments and start removing them. If done successfully, the velocity will start to increase again over time.

Cross-team overview Teams do not necessarily have to use the same amount of points for the same stories. (This is preferred however and can be accomplished by using reference stories: simple stories that are shared across teams to develop a comparable estimation method.) When this is absent however, the relative velocities and the changes in them can be used to compare the effectiveness of teams. It might be hard to tell exactly which team is more effective, but you can see teams that are temporarily under performing and take appropriate action.

Sharing our journey

101

Sharing our journey

102

Our Tools Whiteboards We believe in more whiteboard sessions and less Office-documents

Google Hangouts A videoconference platform like WebEx, Microsoft Lync, or similar platforms. Difference is that Google Hangouts worked for both internal and external employees. Hangouts works for free, for small meetings, with no ads and no time limitation. Attendance by mobile users was very easy thanks to the Android and iOS apps.

Jira JIRA is a proprietary issue tracking product, developed by Atlassian. It provides bug tracking, issue tracking, and project management functions. JIRA Agile adds Agile project management to JIRA. Using cards on a team or project board, Scrum Teams can plan their sprints.

Confluence Confluence is a professional wiki and team collaboration software. “Give your team one place to share, find, and collaborate on information they need to get work done.”

Hipchat Group and 1:1 chat with audio, video, and screen sharing.

Jenkins We use Jenkins as the Continuous Integration tool for the realization of the automated deployment pipeline.

Sharing our journey

103

Sharing our journey

104

Meet the writers

105

Meet the writers

Meet the writers

106

Jeroen Scheer Manager Energy Transition & New Energy Business Models at Alliander, co-shaping the smart energy ecosystem and smart grid.

Jeroen Scheer is Manager Energy Transition & New Energy Business Models (ET&NEBM) at Alliander, the largest utility grid operator in the Netherlands. Jeroen is part of the management team of Alliander IT, and leads the digital solutions necessary to accelerate the energy transition. ET&NEBM builds the technology enabling and supporting core business processes varying from Electric Mobility Services, Information Services, and Home Energy Management up to digitalizing the grid network (smart grids).

Jeroen is acknowledged worldwide as one of the energy transition leaders in building the connected utility of the future. He has a track record of 15 years in various roles at multiple utility companies in The Netherlands, Belgium, Germany, Poland and Sweden.

Meet the writers

107

Herwin Stegeman Portfolio Manager Energy Transition & New Energy Business Models at Alliander, co-shaping the creation, maintenance and facilitation of the Energy transition Agile Program Management.

As Portfolio Manager New Energy Business Models, at Alliander IT, Herwin is part of the ET&NEBM leadership team. He guides the Agile Program Management implementation, necessary to prioritize and manage the scaled Scrum process at scale in order to push forward innovative solutions as part of the energy transition.

Herwin has more than 14 years of experience in executing innovative implementation programs in the utility industry and intelligent business operations in The Netherlands, Belgium and South Africa.

Martijn Aukema Agile Information Architect, creating innovation solutions using shared visions through Service Design, Process Mapping and Visualizations

Martijn sees solutions as part of a whole and probably ; He is captivated by customer value. For years he has worked in the field of Business Process Re-engineering, Agile Lean and Scrum.

Martijn helps large companies make organizational changes and effectively improve the way they work. He does this by introducing new technologies that enable the development of new products (like hybrid Cloud Power solutions) or tooling that improves interactions between people;

Martijn currently works with Alliander ET&NEBM as a Scrum Expert.

Index

108

IndexWHY WORKING AGILE @ALLIANDER ................... 5

Some things in life can’t be captured by an app... .......... 6

OUR CONTRIBUTION TO THE ENERGY TRANSITION ......................................................... 9

Vision, Building the Connected Utility ......................... 10

A Fast Changing World ................................................ 12

Challenges .................................................................. 14

Our Response ............................................................. 16 The Purpose of a Generic Platform Strategy ...............20

MEET ET&NEBM ................................................ 23

Meet Energy Transition & New Energy Business Models ................................................................................... 24

OUR PERSPECTIVE ON AGILE SCRUM ................ 27

The Agile Manifesto .................................................... 28

Scrum, a framework for managing product development ................................................................................... 32

The twelve principles behind Agile .............................32

Shared Values of Scrum in ET&NEBM Collaboration .... 34

Scrum Roles .............................................................. 38 Roles ........................................................................... 38 Product Owner ........................................................... 38 Scrum Team ................................................................ 38 Scrum Master ............................................................. 40 The Project Manager .................................................. 40

Glossary of Scrum Terms ............................................ 42 Product backlog refinement ....................................... 42

The Challenging Product Owner Role .......................... 44 Responsibilities of the Product Owner ....................... 44 Providing Vision .......................................................... 44 Providing Boundaries ................................................. 46

Scaling Scrum ............................................................. 48 Scrum of Scrums ......................................................... 48

OUR ROADMAP TO VALUE ................................. 51

Building our Roadmap to Value .................................. 52 Interactive layers for planning the roadmap .............. 52

Go live with the minimal viable product ..................... 56 minimum viable versus minimal ................................ 56

The Product Backlog ................................................... 58 The product backlog has four qualities: ..................... 58

Index

109

Refining the product backlog ......................................60

Sprint Planning and Daily Standup ............................... 62 Preparation .................................................................62 Defining the sprint goal ...............................................62 Prepare just enough stories ........................................64 Sizing stories and tasks ................................................64 Story points .................................................................66 Sprint planning meeting ..............................................68 Definition of Done .......................................................70 Daily Stand-up .............................................................70 Impediment Management ..........................................70

Sprint Review & Retrospective .................................... 72 Sprint Review meeting ................................................72 The Sprint Retrospective .............................................74

SHARING OUR JOURNEY .................................... 79

Collaboration Model ................................................... 80

Approach Summary .................................................... 82 Preparing for development and delivering value for our customers ....................................................................82 Experiments, prototypes and mock-ups .....................82 End-to-End Business Flows ..........................................84 E2E Process Chain design-sessions ..............................86 Creating a Process Chain Diagram ...............................86 Visuals to Stories .........................................................88 Enabling designs ..........................................................92 ET Acceleration Platform, a Generic Platform Strategy .....................................................................................94

Implementing Continuous Delivery ............................. 96 Making Continuous Delivery work ..............................96 Continuous Delivery pipeline ......................................96 Automated Testing ......................................................98 DevOps ........................................................................98

Challenges .................................................................. 98

Lifecycle Metrics........................................................100

Our Tools ..................................................................102

MEET THE WRITERS ..........................................105

Jeroen Scheer ............................................................106

Herwin Stegeman ......................................................107

Martijn Aukema ........................................................107

INDEX ................................................................108

Index

110

To be continued…

Working Agile @ Alliander (Our Way of Working)

Leadership & Management

Transcript of Working Agile @ Alliander (Our Way of Working)