Real Scrum and More

Citation preview

Real Scrum and More

Alex Manfield MEng PMP PSM

Real Scrum and More Copyright © 2014

Alex Manfield

Cover: Tsou Lee This book contains proprietary information protected by copyright. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and

recording for any purpose other than the purchaser’s personal use without the written permission of the Author. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein. ISBN: 978-1-326-39423-3

Last revision: Aug 2015 [email protected]

Acknowledgments www.scrumalliance.org www.scaledagileframework.com Wikipedia Google



Warning and Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.

Trademarks All registered trademarks mentioned in this book belong to their respective owners.

To my wife Sita

5 (lethal) Phases of an Unmanaged Project.

Wild enthusiasm, dejected disillusionment, search for the guilty, punishment of the innocent, and promotion of those not involved. An unmanaged project is like a black hole that sucks up every person, resource, and dollar—and still doesn’t deliver what it’s supposed to.

- Bonnie Biafore

“Adding people to a late project makes it later.” - Fred Brooks



Today’s technology demand skilled individuals to perform their job since product development is becoming increasingly complex. However it’s not possible for everyone to learn all the available technology before development of a new product begins. Therefore predicting the risk involved and developing plans to mitigate or transfer it, is a time consuming activity and the results are difficult to measure. Time to market is also shortened, and projects are demanding products or services with little tolerance to bugs.

This situation creates the need for skillset and motivation of all the participants in the development in order to bring the project to a successful conclusion. Scrum, like other Agile methodologies used in SDLC (Software Development Life Cycle) are based on small interactions and are getting a very positive impact on the software industry today.

This book describe the Scrum framework and explore other Agile methodologies to improve the chances of success for projects running under different environments.

Contents Real Scrum and More 1. Scrum Framework Intro Agile vs Waterfall Scrum Infrastructure ZI Cycle Scrum terminology Main Actors User Stories Missing Requirements 2. Meetings Intro Planning Estimating Review Meeting Retrospective Meeting Daily Scrum Meeting Communication CTS 3. Enterprise Agile Management Intro Agile Transition Transformation Scrum Integration Scrum of Scrums Team & Leadership SH Management Risk Management Megaprojects 4. Change Management Change Management Traditional Change Control Agile Change Control Strategic Choices Real Projects 5. Design & Testing Intro Design Testing The Lab Environment

Complexity Code Review Unit Test Code Analysis Legacy Code 6. Virtual Teams Virtual Teams Continuous Integration 7. More Agile Intro Scrum & UML Sales & Marketing FDD SAFe Extreme Programming (XP) Lean & Agile Stage Gate Kanban 8. Tutorials Scrum - Meetings XP - Scale Teams FDD 9. Software Tools Intro Management CRM & Marketing Collaboration Software Development Agile & Scrum

1. Scrum Framework Intro Agile vs Waterfall Scrum Infrastructure ZI Cycle Scrum terminology Main Actors User Stories Missing Requirements

Intro

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”. It challenges assumptions of the “traditional, sequential approach” to product development. Scrum enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members and daily face to face communication among all team members and disciplines in the project. [1]

In the above definition there are many interesting points that could be discussed. First of all, the Agile concept which is defined in the following Agile Manifesto [2]:

“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.”

Jeff Sutherland and Ken Schwaber are the main developers of Scrum. Scrum is a methodology designed to accomplish Software Projects but it can also be adapted to other industries or Services.

Let’s have a closer look at the first line: “We are uncovering better ways…” This is important since it highlight the intrinsic “work in progress” nature of Agile. For instance there are companies that follow literally Scrum but still struggle to get some real benefit out of it. Why ? There could be many reasons since each company has it’s own culture and it’s own ways to do things, but many times the Agile process is seen like a treatment (a pill) expecting to do the magic by its own. More or less like a washing machine, you push the button and you get the job done.





Unfortunately this is not going to work, at least not before having understood the Agile principles and values. For instance I’ve attended many times the DSM (Daily Scrum Meetings) where people was so scared to talk each other that even the value of doing it as a simple status meeting was compromised.

People are especially scared if a line management participate at the DSM, but this is not the only reason for its failure as we’ll see later. Many DO Agile without BEING Agile !

The Agile Manifesto is based on 12 principles:

• Customer satisfaction by rapid delivery of useful software

• Welcome changing requirements, even late in development

• Working software is delivered frequently (weeks rather than months) • Close, daily cooperation between business people and developers

• Projects are built around motivated individuals, who should be trusted • Face-to-face conversation is the best form of communication (co-location)

• Working software is the principal measure of progress

• Sustainable development, able to maintain a constant pace

• Continuous attention to technical excellence and good design • Simplicity—the art of maximizing the amount of work not done—is essential • Self-organizing teams

• Regular adaptation to changing circumstances

The ‘Holistic’ approach is probably the most beneficial message of the Agile manifesto: the Team works as one unit to reach a common goal. This has a lot of implications, starting from our cultural approach to do things up to communicating with others, and promoting a positive and ‘problem solving’ attitude. In Scrum the Team is made by people having different skillset, in other words the Team is expected to be self-organizing and cross-functional. This again can be implemented where there is Respect for the individual and these days we need to be open to different cultures if we want to manage different Team members successfully.

It takes years, not months, to implement Agile development fully in an organization. Why? Because people has to adopt the new philosophy and change their habit accordingly.





For instance, take the face to face (F2F) communication as advocated by Scrum. It’s true that F2F is important and effective, but it has to be tested and practiced on the field and because Agile is an ‘Ongoing set of principles’ it has to be adjusted to the real needs. For instance in many Open Source companies F2F is banned. The reason ? If you discuss something with your peer and you come to some useful conclusion, how are you going to share it with the rest of the Team? Notice how banning the F2F (which apparently seems anti-agile) brings you to a new solution which surely Agile. Info MUST be shared and if you form a group then you isolate the knowledge inside it.





The importance of educating the upper management about Agile is evident largely when their ignorance about the methodology messes up projects. The first advantage of Agile is quality not speed. Agile brings with it organizational transformations. Agile requires change and continuous improvement, not just in development but also in all practices that touch products. Upper management need to learn & adapt. Agile should transform the organization not just adopt it.

What is then the main goal of Scrum ?

• Speed

• Good Communication

• Good Software

The answer is Quality.

Agile vs Waterfall

Waterfall is a predictive process whereas Agile is not a process but a philosophy based on adaptation. This means that the Agile principles welcome changes. Many processes like Scrum has been developed based on Agile principles, ans surprisingly, the development of such processes occurred before the Agile Manifesto was elaborated. Agility is the ability to take advantage of opportunities or to meet challenges with calculated risk. It is the most significant competitive advantage today. [5]





Agile projects are successful three times more often than non- agile projects, according to the 2011 CHAOS report from the Standish Group. [14] The report say that “The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.” The Standish Group defines project success as on time, on budget, and with all planned features. They do not report how many projects are

in their database but say that the results are from projects conducted from 2002 through 2010. The following graph shows the specific results reported.

Agile projects have a 37% faster time to market compared to the industry average. Source: Mah 2008.



Waterfall limitations

• AssumingRequirementsnotchangingandbeing completely understood. • Assuming Technology is working without any problems.

• Assuming People being as predictable and reliable as machines. • To respect the deadline, quality gets sacrificed.

Management actually believes that it can predict the cost, delivery, schedule, and functionality, and plans accordingly. However this model has been reported as false in many projects.

Developers and project managers pretend they can plan, predict and

deliver but ultimately they are essentially without controls.

Parkinson’s Law: “work expands so as to fill the time available for its completion”



Scrum Infrastructure

Scrum is one of several light-weight agile methods that use an iterative and incremental approach for the development of information systems.

The Scrum method brings a small team together to work on a specified set of features over a period of usually 30-days or so (a Sprint).

Both the term Scrum and Sprint are borrowed from the sport of Rugby. A scrum is where the two teams are engaged in a huddle to begin play following a period where play has been stopped. The fast moving period of play from the point of the scrum until play ends again is called a sprint.

Transparency, Inspection & Adaptation are the main pillars of Scrum and define the Empirical Management adopted by of Scrum [5]

Inspection and adaptation: We must frequently inspect where we are so that we can adapt our next steps to optimize the results. The frequency of the inspection and adaptation depends on how much risk we can take. Transparency: When we make an inspection, we must be able to assess what we are seeing in the same terms as our goal. If our goal is to develop a system with some features and functionality, then we have to inspect something that is a feature, function, or a discrete subset of either. Transparency is the nature of the increment as a completed piece of functionality, such that we can employ it to our purposes as well as determine our progress. We’ll discuss now about a real life example

of Transparency and CI (Continuous Improvement) cycle because managing change is essential if we want to become Agile. Transparency is really important (not just in Agile) but in general, that’s why many Agile processes (like XP) mention Transparency as one of their values. Transparency is related to communication but it’s NOT the same, for instance you meet an old friend after many years and you start talking with her for an hour. You talk about many things but, are you sure she is telling you the real story? Transparency means just that: speak the truth. This is so important that, for instance it’s part of the Code of Conduct of any Professional Project Manager (PMP) since he has to always report the truth about the real condition of his project to the upper management or anybody asking for it. But there is more of it as we’ll see soon in the ZI cycle.

When an enterprise decide to become Agile they usually want to improve their productivity. Now the question is: do you want to improve? If the answer is yes then this means they have to change because improvement is nothing but change. Once Einstein said: “We want things to improve but we continue to do the same things”. There cannot be real improvement without change and this is valid at all levels. The real challenge is not how good we’re on doing our job, but how good we’re on changing the way we do it, because the world is continuously changing. A quick example: a new emerging role appear on the market. Those who are able to qualify for that role are among the first able to get into that new role. This means they’ve to invest in trainings, courses, practice and probably change their mind about few things before they can succeed.



ZI Cycle

What if we do NOT improve? What prevent us to perform? These are just few of the questions that the ZI cycle will try to answer. ZI stand for Zero Improvement cycle and will help us to understand

why CI is good for us.

Mark is a senior developer and is quite familiar with its job and responsibilities. He likes to follow good processes and be predictive and (in general) he doesn’t like much to change. Tommy is the CTO and is going to hire a new PO to make sure the Team will improve the productivity because the CEO wanted more features in the new release to be implemented faster than before. Mary is the new PO, just hired. We’ll see later what are the main responsibilities of a PO, but just to keep it simple we can say that the PO represent the client and gives directions to the Team about what to do and with which priority. Tommy: “Hi, this is the Team and they all work for me. We just want to find a way to improve our Scrum process” Mary: “That’s great, what are your expectations on me?” Tommy: “Well, I want you to take care of the development process and make sure everything goes smoothly starting from writing good requirements for the developers. You’ll also look at the current implementation of Scrum and find suitable changes if needed like a Business Analyst will do. We’re a small team and there is no Scrum Master, you’ll support my business requirements since I act as the main stakeholder for this project”. Mary “OK, I’ll support you, but will you support me?” Tommy: “Of course.”

Mary enter the ZI cycle, and after few days she started proposing few changes. However some developers resisted to those changes, Mark is one of them. He’s a reputed senior developer and he’s in the company since longer than Tommy. Tommy just cannot ignore his view and he’s struggling to support Mary. After few weeks, he starts getting a negative feedback from the Team about Mary, and he’s not sure what to do since he decided to hire her. After few months the productivity did not improve and Tommy was even more concerned about Mary because the Team did not seem to

respect her views. Despite she had a brilliant experience, for some reason she seemed to struggle on improving the performance of his Team, and Tommy was not able to get the expected results. Perhaps her character or personality was clashing with Mark ? Ultimately Tommy decided to dismiss her while still in the probation period.

Basically Tommy hired Mary to improve the process but he could not get the expected results. What prevented Mary to perform? Tommy said he was ready to support her but still nothing good happen to the productivity. This is just a fictional representation of the real life environment, and in real life things are certainly more complex, but we can highlight few facts here. Of course we assumed at the very beginning that all actors were technically skilled in their respective roles:

• Mary asked for Tommy’s support and he always replied to her emails and met her face to face regularly. • Mary proposed few changes but some part of the Team refused to accept them. • After few weeks some part of the Team started disagreeing with Mary • Tommy was under pressure from the CEO, and despite he supported Mary to enter his company, he could not see the expected benefits and ultimately he had no other option than making her redundant.





At the end of this cycle we can see the following (simplified) situation:

• The cycle start over again but the morale of the Team is decreased and the productivity is lower at each start. • Tommy think Mary’s attitude was not effective with his Team and he’ll possibly start examining another candidate in the coming week. • The CEO, after seeing that no improvement has been done, will start doubting over the overall capacity of his Team. He’s constantly under pressure to deliver a better software but he’s unable to achieve that. Sales and key accounts are chasing him, and he started doubting everybody including Tommy. Soon after Mary left, one more junior developer was dismissed because of his poor performance and since

the company missed few important sales, the CEO reported that the product had to improve if the company wanted to stay competitive. • After his announcement few people started looking for new opportunities.

Nobody win here, everybody lose.

Let’s try to analyze each actor in the ZI cycle. Statistically (assuming a normal distribution) in every company there are people resisting change, say 15% will resist, no matter what you do. Another 15% will support you, and the remaining 70% is neutral. Why people resist to change? There are many reasons of course, including the followings:

• They want to maintain their status

• They fear that if somebody will improve their productivity, the company will no longer need them, and they can even lose their job. • They fear to exit their ‘comfort zone’

• They feel they’re not paid enough to improve

What are the common strategies people use to resist change? These depend on people and the situation of course, but we can probably find the common ones listed below: • Disagree

• Criticize

• Ignore changes

• Misunderstand changes

• Hinder & backstabbing

One thing is worth noting: respect and communication always goes

together. If you do not respect a person you’re probably unwilling to talk with him. Ignoring Mary or criticize her are common strategies to avoid change. It’s interesting to notice that the character or personal attitude of Mary has little to do with the resistance she experienced with the Team, although in real life personality can have a major impact of course. Those who resist are more concerned with their ‘comfort area’ not with the personality of Mary. In fact they’ll exhibit the same resistance with anyone trying to introduce a change, no matter her experience or character. In the case of Mary, we could say that there was nothing personal about her, although the outcome most probably had a significant impact on her personal life.

Let’s see Tommy now. He was technically sound and working in the company since the last 4 years. He’s opinions are respected by the Team and the CEO. During one F2F meeting with Mary, she asked “What side are you?” He replied”I’m on my own side”. That’s the wrong answer. We’ll see later in CTS that the Team need support both internal and external, and Mary when representing the upper management, desperately needed that support because PO represent the client (stakeholder) in front of the Team. Tommy replied to emails and met Mary F2F but support is not enough. We could not see much Transparency in Tommy’s activities. Did he support Mary Transparently in front of the Team during the meetings? No. Did he support her when people criticized her changes when she was not present? No. He was surprised and not sure what to do and who to trust. Many projects fail just because they lacked support from the upper management. This project was no exception. I would say that the major responsibility in this case was on Tommy’s shoulders. Now let see how Mary did. She was probably fair in proposing those changes but she could probably improve on her first interview with Tommy by asking if

he was really willing to improve. This means making sure he was really prepared to change. Next she would have explained all the implications that comes with change and the various strategies the Tommy could expect from the Team, or at least from the 15% of it. Where she should have better focused her efforts? 15% of people who resist change will not change easily just because you ask them to do it. No matter what efforts you spend there. With the other 15% you’ve nothing to do because they’ll always support you. The remaining 70% is where Mary should focus more because by getting them on her side, she gets 85% of consent and the 15% of resistance will automatically join them in the due time. What is the strategy Mary could use to work on the Team? Again this is subjective and depending on the real situation, but just to keep it simple:

With people who resist the change, she could check if they’ve clearly understood the process she’s talking about. If they criticize she could challenge them with open questions about Scrum, and how this can be successfully implemented:

Mark :”That’s not going to work with us” Mary: “Do you know why?” Mark: “Because it doesn’t make sense the way we develop our software” Mary: “Do you know the meaning of Empirical Management in Scrum?” Mark: “No idea” Mary: “Well, it doesn’t make much sense discussing on the validity of a method if we don’t understand it in the first place. Therefore I suggest that we get a basic training on Scrum and why I proposed such changes with a final Quiz. Then we could check how Scrum could improve our current process and where we need to act if it doesn’t”.

The PO in Scrum share some responsibilities with the Business Analyst, but (ideally) for the implementation of Scrum, Mary should ask the Scrum Master to support her. In this case there is no Scrum Master and Mary will do it . A company able to improve will have a better products, will be more profitable, will have a stronger position on the market and finally will be able to secure a stable position to its employees.

Accepting changes require maturity and a sense of Team. We’ll see later the typical phases to form a Team.

Bermuda Triangle This is where airplanes and ships disappear. When applied to Scrum in this triangle we miss people mainly because of poor transparency. For instance, imagine A is a new developer that has just joined the company. A doesn’t know a technical detail that he needed to move forward , so he asks a question to B. B reply to the question but she also report back to C, the CTO with some comments. In this case transparency is violated. C then will talk to A trying to figure out why he asked that question. Assuming the question was legitimate, A will soon feel frustrated by the lack of transparency, and may also feel demotivated to stay on the long-run.

No-Impediments circle Developeers usually don’t talk much about impediments. Reasons may include: fear, demotivation, poor interest to improve, poor sense of Team, poor ownership of their own work. Aa a general rule if the Scrum Master do not hear of impediments during the DSM, then one or more impediments are in place. Actually by not having an impediment to discuss is usually a major impediment by itself.

We need to be able to take advantage of opportunities and respond effectively to challenges. We need to be able to explore many ideas,

change our minds, and let the best solution emerge. If you see an opportunity or want to mount an initiative, you can not only achieve your goals but also focus them in order to deliver only the most valuable functionality. With more control and a faster, less risky process, you can get something off the ground within 30 days and continue to improve it. [5]

Scrum does not prescribe. Scrum includes general guidelines about how to do development and principles to be applied when these recommendation are insufficient. [6]

Today most of the organizations want to gain more flexibility, more creativity, more productivity, and more profits. They want to please their customers and outdo their competitors. Many organizations have decided to use Scrum as one of their key strategies. Sometimes it is used for critical work only; sometimes a new development or information technology (IT) organization is created in parallel with the existing waterfall organization. Sometimes the entire enterprise is transformed to become more agile, more flexible, and more competitive. Regardless of what is desired, a change from the normal way of doing things is required. [5] Not all projects can be successfully developed with Scrum but certainly many of them can be managed within its framework. Large or critical projects like Military or Nuclear plants may have issues with Agile or Scrum SDLC (Software Development Lifecycle) since Teams can be very large and distributed and many procedures need to be enforced with documentation, safety regulations and specific testing patterns. However, by switching the company culture to Agile, Scrum can be scaled to address large and complex projects as well.

One important step to notice when implementing Scrum in an organization is that Scrum is not an approach or process that can be modified to fit the existing organizational culture; the culture must change to enable Scrum. [5]

• Scrum is a tool that can be used to achieve agility.

• Scrum is an agile process to manage and control development work. • Scrum is a wrapper for existing engineering practices.

• Scrum is a team-based approach to developing systems when requirements are changing rapidly. • Scrum controls the chaos of conflicting interests and needs.

• Scrum improves communication and maximizes cooperation. • Scrum detects and removes anything that gets in the way of developing • and delivering products.

• Scrum is a way to maximize productivity.

• Scrum scales from single projects to entire organizations, and has managed development for multiple interrelated products and projects with over a thousand team members. • Scrum is a way for everyone to feel good about their job, their contributions, and know they have done the very best they possibly could.

Scrum require Agility in the entire organization. Many organizations attempting to implement Scrum modify the parts that require breaking through organizational impediments, and end up robbing themselves of most of the benefits.



Scrum terminology

User stories are functional descriptions of the work to be done.

Sprint backlog: A sprint backlog is a negotiated set of items from the product backlog that a team commits to complete during the time box of a sprint.

Release backlog is a set of features we want to implement for the product under development.

The product backlog is a list of PBI (Product Backlog Items) containing all the features we want to implement in a product. The product backlog is:

• Dynamic, Items may be deleted or added at any time during the project. • Prioritized, Items with the highest priority are completed first. • Progressively refined, Lower priority items are intentionally course-grained. • Should be updated for the next 2/3 Sprints

• Contain epics or user stories (epics are groups of related user stories)

Usually the topmost PBI has higher priority.





Items in the sprint backlog are broken into detailed Tasks for the team members to complete. Tasks should not last more than 8hrs. Sometimes tasks are also indicated as Work Items. The team works collaboratively to complete the items in the sprint backlog, meeting each day (during a daily scrum) to share struggles and progress and update the sprint backlog and burn down chart accordingly. The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress and is a powerful predictive tool. There are 3 important concepts related to the Burn down chart:

• Velocity (speed)

• Effort

• Done

The Velocity measure how much ‘work’ the Team was able to ‘burn’,

whereas the effort is a time independent measure used to estimate how much effort was required for a specific Task to be completed. Work in this case is equivalent to Effort as defined below.

Effort measure the relative size of a User Story to other user stories. Efforts are usually measured in Story Points (SP), arbitrary numbers which could be defined in series as below:

2,4,8,16,32 or 1,2,3,5,8 (Fibonacci )

We’ll see later why we’ve defined only 5 SP per series. Story point are time independent, therefore they do no indicate the duration in time needed to complete a Task, but just the effort needed when compared to similar tasks. Eg if you need to walk for 4hrs you have an effort which is different compared to running or climbing for the same amount of time. Efforts can also be indicated in time units (hrs) but I personally prefer to use SPs.





The definition of ‘Done’ is also very important to understand when a

Task can be considered completed.

The Scrum Master could write a typical definition of ‘Done’ as below and this will be applicable to each PBI:

• Completed & Tested

• Refactored

• Potentially shippable

Note that the Sprint execution completes when the timebox expires and if a task was completed, say at 90%, this task will be inserted back into the Product Backlog for the next Sprint. This means that to respect the deadline we accept to deliver less features by reducing the Scope of the Project.

Eg, suppose you have 100SP in a Sprint (30days) and your Team completed just 5SP at the end of day#2. This means that the remaining work is 95SP. Since the Sprint is time boxed we have now a line passing across two points P0(0,0) and P1(2,95) and therefore we can figure out if the Team will be able to finish in time from day#1 assuming the Velocity (5/Day) will remain the same.





It’s worth noting that the performance of the Team may have many root causes including poor requirements and bad communication which are probably the most common of all. The Product Owner (PO) and Scrum Master (SM) defined later and being part of the Team, share therefore equal responsibilities.

The Kanban board display all the Tasks the Team has committed to, arranged in multiple columns like: To Do, Started, Done Both Kanban and the Burn down chart are also called Information Radiators and should be kept well visible in the Team room.





Sprint Planning Meeting At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to negotiate which Product Backlog Items they will attempt to convert to working product during the Sprint. The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement without accruing technical debt. The team “pulls” work from the Product Backlog to the Sprint Backlog.

Daily Scrum Execution Every day at the same time and place, the Scrum Development Team members spend a total of 15 minutes reporting to each other. Each team member summarizes what he did the previous day, what he will do today, and what impediments he faces.

Sprint Review Meeting After Sprint execution, the team holds a Sprint Review Meeting to demonstrate a working product increment to the Product Owner and everyone else who is interested.

Sprint Retrospective Meeting Each Sprint ends with a retrospective. At this meeting, the team reflects on its own process. They inspect their behavior and take action to adapt it for future Sprints. Dedicated Scrum Masters will find alternatives to the stale, fearful meetings everyone has come to expect. An in-depth retrospective requires an environment of psychological safety not found in most organizations. Without safety, the retrospective discussion will either avoid the uncomfortable issues or deteriorate into blaming and hostility. [8]

One aspect of Scrum, that is intended to keep this method very agile, is its size. Most Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.

Main Actors

• Team

• Scrum Master

• Product Owner

Product Owner : identifies the features that will be included in the next sprint and set the priority of each. He gives Directions to the Team. Build Bz Case, manage ROI & Risk. Make the Release Plan with the Team & determine Priorities. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner represents the stakeholders and is the voice of the customer. [4]

Scrum Master : acts much like the project manager. While the Scrum Master does not micro-manage the teams deliverables, this person ensures that the sprint is on track and enforces the key rules that guide Scrum such as; no new features can be added to the sprint once it

is kicked off, and team members cannot be pulled off to work on other side project in the middle of a sprint. A Project Coordinator may become the Scrum Master, but a line Manager should NOT do the Scrum Master. The role has also been referred to as a servant-leader to reinforce these dual perspectives.

The Scrum Master differs from a project manager in that the latter may have people management responsibilities unrelated to the role of Scrum Master. The Scrum Master role excludes any such additional people responsibilities. In fact, there is no role of project manager in Scrum at all, because none is needed. The traditional responsibilities of a project manager have been divided up and reassigned among the three Scrum roles. [4]

Team Member : (also called developer) unlike traditional software development methods, in Scrum there is little separation of duties between team members. Each team member may fill the role of analyst, designer, software developer, tester, and documentation writer.

All of the above roles have Leadership over the project, that’s why the Team is selforganizing and no role has authority over the other.

The whole Team need to be empowered with Responsibility & Ownership, working towards common objectives and understanding ‘Why’ the task is done.

PO This role deserve particular attention since from her depends in large part the performance of the Team. PO is responsible to guide the Team through the functional requirements as intended by the Stakeholder. To keep it simple we’ll identify the Stakeholder (SH) with the customer although a SH is

usually defined as anyone who has an interest in the Project. Notice that the CEO and the end user are also SHs. By representing the SH, the PO’s role is partially comparable to the traditional role of the Business Analyst (BA) as defined by the CBAP (Certified BA Professional) certification which is worldwide recognized as a standard for this role. Therefore we’ll now see what knowledge the PO should have to effectively do this role. The Body of Knowledge of the BA (BABOK) is also the counterpart equivalent to the Body of Knowledge of the Project Manager (PMBOK).

BABOK [9] defines the activities of the BA grouped in different areas as follows.

The Business Analysis Body of Knowledge defines 6 knowledge areas (KAs), which group together related sets of tasks and techniques. Each of these tasks and techniques describes the typical knowledge, skills, processes, and deliverables that the business analyst requires to be able to perform those tasks competently. While a flow of tasks and processes is suggested by these knowledge areas, the BABOK is deliberately not setting out a prescribed methodology. Indeed, version 2.0 has separated techniques from the knowledge area tasks, into a new section. [10]



A Solution meets a business need, by solving problems or allowing the organization to take advantage of an opportunity. A solution can be subdivided into components, including the information systems that support it, the people who operate it.

Solution scope is the set of capabilities a solution must support to meet the business need. Project scope is the work necessary to construct and implement a particular solution.

A Requirement is a condition needed by a stakeholder to solve a problem or achieve an objective.

A Task is an essential piece of work that must be performed as part of business analysis. Tasks may be performed formally or informally. A task accomplishes a result in an output that creates value. [3]

Although the PO should understand all the 6 KAs involved in the BA process, probably for most projects, only the following 4 KAs are essential:

Elicitation Requirement Analysis Business Analysis Planning and Monitoring Requirements Management and Communication

Business Analysis Planning and Monitoring How BA plan the tasks and activities for Business Analysis. It covers Stakeholder Analysis, selecting an approach to managing issues, risks and requirements; deciding how to monitor and report on requirements activities; and negotiating how to manage change on a project.

Requirements Management and Communication How Business Analysts ensure that the project team and stakeholders stay in agreement on project scope. It covers communicating requirements; resolving conflicts; gaining formal approval; baselining and tracking requirements through to implementation. [10]

Baselining comes from baseline which is the reference status against which we can measure the progress done. Eg. for a Sprint of 30days the time baseline is 30days and by measuring the progress against it we can check whether our project is going to complete in time or not.

The above 4 KAs are usually enough when most of the SHs are internal to the organization (including the management that will finance the project) and the deliverable is an internal product. We’ll now have a look at the first 2 KAs in more detail. Please keep in mind that Scrum is a light weight project framework and that most of the documentation described in the BABOK is not required in Scrum (see the Agile manifesto about it). Elicitation How BA work with stakeholders to help them understand their requirements within the scope of a project. It covers eliciting requirements; brainstorming; analyzing documents; running focus groups; analyzing system interfaces; interviewing; observing; prototyping; facilitating requirements workshops; reverse engineering existing systems; and collecting input via surveys and questionnaires. [10]

1. Business requirements What the needed achievements will be, and the quality measures (i.e. KPIs or tangible objectives). Eg. The ability to accept and process customer feedback about the provided service.

2. Functional requirements

They describe what the system, process, or product/service must do in order to fulfil the business requirements

3. Non-Functional Requirements They are requirements that do not perform a specific function for the business requirement but are needed to support the functionality like performance, scalability, security, quality of service ..

A quick way to remember the quality of good Requirements is the 4C rule, stating that requirements should be:

• Correct

• Complete

• Consistent

• Checkable

It’s essential for the PO to really understand the requirements, that she gather not just asking WHAT the SH wants. The PO should also ask WHY he wants it and listen actively. The WHY is essential to develop the right attitude for this role and the simple reason is because often (not to say always) the SH don’t know what he wants. He starts with some idea, some draft but then he need the PO’s help to translate the business requirements into some functional requirements. There is also another skill that the PO should have: knowing well the software they want to make, their product. This is important when the project is going to enhance an existing software, and more in general the PO should have at least a solid technical understanding of the IT industry.

“Nothing is impossible for the man who doesn’t have to do it himself” - A.H. Weiler

Writing Textual Information is a type of skill often overlooked by many POs.

PO will seat with the SH during the elicitation and she’ll need to take note of what she hear. This is sometimes tricky. PO could use the laptop or a template or just a plain sheet of paper, but in any case she need to transfer this information for later analysis and therefore we need to understand how we could do that. During the conversation PO should capture not only the business requirements but also the priorities associated with them. Often this priority is embedded in few specific verbs which need to be recognized. We need also to remember that usually SHs are quite busy and if we’re successful doing proper elicitation, they’ll be just glad to have saved some time in future clarifications.

Traditional words: ‘Shall’ Required functionality ‘Should’ Desired ‘May’ Optional

Recommended words 1. “The system shall … [Priority = High].” 2. “The system shall … [Priority = Medium].” 3. “The system shall … [Priority = Low].”

This is compliance to the IEEE 830–style software requirements specification

Negative Sentences During the elicitation process we may listen to negative sentences and for clarity purposes, we should always try to transform them into positive ones.

• cannot ( “not able to”)

• may not (“not permitted to”)

all users with 3 or more accounts should not be migrated (negative)

the system shall migrate only users with fewer than 3 accounts (positive)

The publisher will not have the permission to change the default user the system admin shall be able to change the default user

Training score & rewards will not be visible to default users the system shall display training score & rewards to publishers & admin

Abbreviations The abbreviation i.e. stands for the Latin phrase id est, which means “that is.” The abbreviation e.g. stands for the Latin phrase exempli gratia, which means “for example.”





The image of the tree is funny and significant at the same time. Often it’s found on the team room where traditional waterfall projects are executed. Starting from top-left :

1. How the customer explained it 2. How the project leader understood 3. How the analyst designed 4. How the programmer wrote it 5. How the consultant described it then from bot-left: 6. How the project was documented 7. What operations installed 8. How the customer was billed 9. How it was supported 10. What the cusomer really needed

Requirement Analysis This process is needed once the elicitation is completed. Please remember that in Scrum all KAs are incremental and performed during the whole duration of the project. Therefore by ‘completed’ we mean with respect to the interaction not ‘final’ since in Agile everything is interactive and progress is achieved in small increments. The main activities in this KA are:

• Prioritize

• Assumptions

• Verification

• Validation

The first 2 are gathered in the elicitation process but new assumptions may also surface during the analysis.

Requirement Verification is done through the following steps: Inspection, Demonstration, Test, and Analysis and essentially the goal here is to discover ambiguous requirements and eliminate them.

Requirement Validation means identify unneeded requirements and retain only the valued ones. Note that sometimes requirements are confused with features, however they’re not the same. A requirement is a capability that a product must possess or something a product must do in order to ultimately satisfy a customer need.

A feature is a set of related requirements that allows the user to satisfy a business objective or need. [11]

User Stories

They actually come from XP but are widely used in Scrum as well. The development of user stories (US) occurs in three parts:

• The Card

• The Conversation

• The Confirmation

The Card: named for the standard index cards on which a user story is often captured, Cards include the brief description of the user story, its relative size to other user stories ( story points), and the priority of the functionality. The cards are used for planning the work that will be completed during each iteration of development. If the size of the user story gets too big to complete within a single iteration then it should be broken into smaller stories. Usually a card is 4x6” and contain also dependencies, acceptance test, value points (value points represent the business value associated with the US)

The Conversation: the US stimulate the Conversation between the Product Owner and the Team. While the conversation itself is not an actual deliverable, it is a critical step in the user story development process. Discussions about each US with the SHs are essential to flesh out details. The details of the conversations are documented in the form of acceptance tests called “The Confirmation”.

The Confirmation: Acceptance tests are details which are captured from the Conversation that can be used to verify that the user story has been successfully implemented. When index cards are used, the acceptance tests are typically written on the back of the card itself. Acceptance tests can and should be captured whenever they are thought of, however, at the beginning of each iteration there is a defined period of time which is set aside to generate acceptance tests.

Using these 3 parts, the goal of the user story is to plan which functionality will be developed during each iteration, provide enough detail that a developer pretty much understands what needs to be coded, and provide a means to verify that they have achieved the goal. If the developer needs more details, more conversations are had, the details of which are documented as more acceptance tests.

Here are some sample user stories (the Card) for a job board:

• I want to post a resume

• I want to search for a job

• I want to electronically submit my resume for jobs I like

Some user stories follow a more formal structure than others. One formal approach suggested by Mike Cohn follows the structure:

As a [Role] I want [Action] so that [Benefit]

At first, structuring your US descriptions like this may seem cumbersome, but it makes sure that you aren’t forgetting WHO you are designing the functionality for and WHY. Often the last part [Benefit] is left out but this is not advisable unless is very clear the purpose of the US.

As a job seeker I want to post my resume so that recruiters and employers can find it.

As a job seeker I want to search for a job so that I’m in control of my job search.

As a job seeker I want to electronically submit my resume for jobs I like so that I will increase the changes of receiving an interview.

Here are some acceptance tests for the US “I want to search for a job”

Test with keyword, salary, and location search parameters Test that the search results are returned in 2 seconds or less

Note that the acceptance criteria started with ‘Test’ but this not mandatory as they can just be written in plain common language.

Some comparisons can be made between user stories and use cases used in UML, but there are key differences that should be remembered.

• Use Cases are almost always larger in scope than user stories. • Use Cases are more like a contract while Use Stories are a planning tool. • US emphasize verbal communication.

• US are a list of requirements, stories describe a user’s goals.

Here are few common issues the PO could have to face with US. The Team may report in the retrospective meeting about unclear requirements. What could be the root cause?

Often this is due to PO writing unclear US and the Team expecting the US to describe in details the work to be done. The latter can be resolved by implementing proper Scrum methodology (Conversation), whereas the first point require PO to understand the purpose of US and developing textual and verbal communication skills as described here. It’s important to know that in Scrum developers should not expect requirements to be completed and clear before they can start working on them. In Scrum the whole Team need to discuss & clarify requirements during the Planning with PO (the Conversation part of the US).

1.Therefore the Card containing the title of the US and perhaps few acceptance criteria is first completed by PO & SH. 2.Next, during the Planning the Conversation must happen discovering issues to US or adding new of them to the backlog. 3.Finally the Confirmation occur when the PO will write down the results of this Conversation by editing the US in the backlog.

There is also another detail that is worth remembering: after the US has been updated in the backlog, we can say it’s completed but this doesn’t mean ‘Final’ since ‘Final’ is not applicable in the Agile process that by definition is incremental and always ready for changes. We can just say that the US has been completed with the best information we had, and that the Team may start working on it. PO will provide any other details required during the development. Until this is not understood and practiced we’ll continue to get complaints for unclear requirements.

I just want to stress this point once more: US are not contractual obligations, they are dynamic and may evolve with time. They’re not meant to be completed by the PO. The whole Team will complete them. Moreover Completed doesn’t mean Final since US can always change (possibly not during Sprint execution)

We’ve already mentioned about priorities and they’re really important if we want to execute our US by addressing the needs of the SH. In anything we do, we need to realize that our resources are limited (time, people, equipments..). Therefore we should first try to execute what is more important and only after that, all the other US will be executed.

From the SH point of view we could have the following priorities: New or Incremental Revenues

Catch-Up Competition Operative Efficiency (Cost savings)

A simple way to weighting them is to use the MoSCoW method: Must, Should, Could, Won’t.

M - MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. S - SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary. C - COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit. W - WON’T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

There is another short term that is useful to remember how to write good US: INVEST (Indipendent, Negotiable, Valuable, Estimable, Small, Testable)

Indipendent : you can divide larger dependent user stories into smaller stories such that one of the new smaller stories contains and isolates the overlapping portion of the larger stories.

Negotiable : User stories can always be changed or rewritten up until the point of coding. This further supports the flexibility associated with agile methodologies. Since requirements often evolve or rise and fall in priority, user stories should be able to adapt with the changing requirements.

Valuable : A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable.

Estimable : You should always be able to estimate the size of a user story.

Small : User stories shouldn’t be too big or too small.

Testable: User stories must be testable in order to ensure that development is complete and has been done correctly. So when are user stories not-testable? Often, if the analyst isn’t careful, non- functionality requirements are written in a manner which is untestable. Consider the example, “pages should always load quickly”. There are two untestable components of this statement; “always” and “quickly”. A testable statement would be “pages should load within 1.5 seconds 97% of the time”.

Notice that you can create US just for analysis or testing purposes although these are seen as non-valuable activities for the client. In a Lean context all that is not producing a value for a customer is considered as a waste. In this context testing or QA is therefore just a waste ! Of course we all know that this is a ‘necessary’ waste because nobody will risk to ship a piece of software to the client without having it tested.

Take another example: “As a developer I want to implement the API for alphanumeric search” here there is no added value for the client, and it’s clearly stated that this US is an implementation (hidded to the client) not something visible by the client. Real userstories go from outside the system boundary to inside the system, or vice versa (as depicted in the UML use-case diagram). If we see a story focused only on things happening inside the system, it’s a sign that this is implementation, not something that create a value for the user.

The concept is that a ‘user story’ should talk about the ‘user’ not a developer. Doing the latter will probably create a task whereas the US should focus on what the user consider as a value. We all know that other tasks are necessary to build that value but it’s a good habit NOT to focus on developers work while defining the US.

Acceptance Criteria (AC) They are the Confirmation of the US and incredibly important in Scrum because they spell out what a Product Owner expects and what a Team needs to accomplish. They are used to confirm when the software is working as intended, which means the story is completed

1.Usability: Be sure to include measures of usability in the acceptance criteria. Indicate how to answer the question: Is it easy to use? The key is to identify the right measurements and make sure each is quantifiable. 2.Functionality: Identify specific user tasks, business processes, or functions that must be in place at the end of the project. A functional requirement might be: The user can choose from multiple sizes. 3.Error handling: Enumerate error cases and how each should be handled. For example, if a user performs the steps in the wrong order, how will the software handle it? 4.Performance: Test system performance from the perspective of an individual user. For example: Is the UI responsive? 5.Stress tests: Describe how the system responds when it is under stress because there are many users, transactions, or queries.

Here are some examples: I can limit the search by format/type. I can delineate the search by date range. I can limit the search to publisher information such as title, author, subject, place, publisher and call number. I can restrict the search to a particular website/catalogue, collection.

I can find advanced search options – advanced search options are carried through as filters to search results page. I can filter by availability.

In short AC are relatively high level (not every detail needs to be in writing) and may help:

define the boundaries for a user story/feature the team gain a shared understanding of the story/feature developers and testers to derive tests developers know when to stop adding more functionality to a story

Here are few more examples: [7] US05 As an internet banking customer I want to see a rolling balance for my everyday accounts so that I know the balance of my account after each transaction is applied

AC The rolling balance is displayed correctly The rolling balance is calculated correctly for each transaction The balance is displayed for every transaction for the full period of time transactions are available The balance is not displayed if a filter has been applied

What about Details ? Where do I get details such:

The column heading is “Description” The rolling balance format is 99,999,999,999.9 D/CR We shall use a dropdown rather than checkboxes

These kind of details normally come up in the Conversation about the story between PO and the Team. This could be at the sprint planning or when the team starts coding this particular story.

The details the team capture before coding go into two places:

1. Team internal documentation 2. Automated acceptance tests

Team internal documentation The purpose of team internal documentation (done by the Team) is solely to serve as a reminder for (potentially forgetful) team members. How much of the details need to be written down depends on the team and whether people write down any details at all is entirely up to them. (Note that this is different from external documentation such as a user guide which would be part of scope)

Automated acceptance tests Acceptance criteria can be expressed in (almost) plain English for use by the chosen testing framework. This means that tests provide value as documentation, automated acceptance tests and as a feedback loop for developers doing BDD (or TDD).

Epics They are used to group together multiple related User Stories. In this way we can look at US without missing the big picture. Epics are grouped in Story Maps where the epic is placed on top of the column and the (child) User Stories just below it.

Splitting User Stories Sometimes US need to be split in order for the Team to estimate them. Here are some common techniques used to split them:

• Horizontal Splitting

• Vertical Splitting

• Split by Main Flow & Exceptions flows

Horizontal Splitting The first approach is called horizontal splitting and involves breaking up user stories by the kind of work that needs to be done or the application layers that are involved. So, work that has to be done for the UI, databases, a front-end, a back-end and testing is split up into groups of tasks. This is typically how teams work in a more traditional (waterfall) development context.

However there are few issues related with the horizontal splitting: Individual items do not deliver the whole business value: Suppose that

a team works on an order process for a webshop in a sprint. If they would split up the work horizontally, they would end up with work for design, database, front-end and testing. Although the items are certainly smaller, they don’t deliver any business value separately.

Increases bottlenecks, instead of reducing them: Horizontal splitting is often accompanied by so-called ‘silo thinking’ adding barriers to the product integration. Every member is taken from one of the silos required for software development. The ‘design guy’ will take care of design, the ‘database guy’ will set up the database, the ‘developer’ writes the code and the ‘tester’ does the testing. If team members are not interchangeable there is a good chance of bottlenecks. If the ‘design guy’ can’t get his work done on time, this will impact the tasks that follow the design. Because team members can’t help each other out, every delay, problem or interruption will impact the entire sprint.

Horizontal slices can’t be prioritized: How can a product owner prioritize a backlog if it consists of horizontal slices? Because none of the items deliver business value in themselves, a product owner will be unable to prioritize the work.

So, horizontal splitting of user stories may result in smaller items, but severely limits the ability of a team to deliver business value, work around bottlenecks and prioritize work and it may increases the risk of failing the sprint. [12]

Vertical Splitting This is more useful in Agile. If a user story is split vertically, it is split in such a manner that the smaller items still generate some business value. The functionality will not be split across technical layers or tasks, but across functional layers. So, if the user story is ‘As customer I want to pay for my order, so I can get my products’, it can, for example, be split into smaller user stories like ‘As customer I want to pay by wire transfer, so I can get my products’ or ‘As customer I want to pay with my credit card, so I can get my products’. [12]

Split by Main (MF) & Exceptions flows (EF) Functionality often involves a main flow and one or more exceptions flows. The MF describes how functionality behaves when everything goes well. If there a deviations, exceptions or other problems, EF are invoked. Take this user story for logging in to a secure website: [12]

As buyer I want to login so that I can buy my products;

If we consider a regular login procedure, we can identify a MF and several potential EF:

As buyer I want to log in with my account, so that I can access my products (MF); As buyer I want to be able to reset my password when my login fails, so I can try to log in again (EF); As buyer I want to be given the option to register a new account if my login is not known, so I can gain access to my products (EF); As Admin I want to block buyers that log in incorrectly three times in a row, so I can protect the site against hackers (EF);

Benefits of Scrum Management: You know exactly how many and which requirements you have completed and which are ready for use at the end of each iteration.

Control: If the information reflects completion later than desired, you can reduce the size or amount of remaining functionality to be done.

Risk management: The development team completed only 2 units of functionality in each of the first three iterations. At the end of the third iteration, a forecast would indicate that completion wouldn’t occur until the middle of the tenth iteration.

The Team is self-monitoring its progress and is responsible for the quality of the software.

Missing Requirements

Too many software projects fail to deliver what their customers request. Over the years, customers explain the failures: The developers don’t pay attention to what we ask them to build. And developers explain that: The customers don’t tell us what they want. Most of the time they don’t even know what they want. Describing a software system’s responsibilities is hard. It requires speaking and active listening. Writing good software is hard. Testing software is also hard. But the hardest job in software is communicating clearly about what we want the system to do.

Missing requirements are a common type of requirement defect. They are hard to spot because they’re invisible! The following techniques will help you detect previously undiscovered requirements.

Decompose high-level requirements into enough detail to reveal exactly what is being requested. A vague, high-level requirement that leaves much to the reader’s interpretation will lead to a gap between what the requester has in mind and what the developer builds.

Ensure that all user classes have provided input. Make sure that each user requirement has at least one identified user class who will receive value from the requirement.

Trace system requirements, user requirements, event-response lists, and business rules to their corresponding functional requirements to make sure that all the necessary functionality was derived.

Check boundary values for missing requirements. Suppose that one requirement states, “If the price of the order is less than $100, the shipping charge is $5.95” and another says, “If the price of the order is more than $100, the shipping charge is 6 percent of the total order price.” But what’s the shipping charge for an order with a price of exactly $100? It’s not specified, so a requirement is missing, or at least poorly written.

Represent requirements information in more than one way. It’s difficult to read a mass of text and notice the item that’s absent. Some analysis models visually represent requirements at a high level of abstraction— the forest, not the trees. You might study a model and realize that there should be an arrow from one box to another; that missing arrow represents a missing requirement.

Sets of requirements with complex Boolean logic (ANDs, ORs, and NOTs) often are incomplete. If a combination of logical conditions has no corresponding functional requirement, the developer has to deduce what the system should do or chase down an answer. “Else” conditions frequently are overlooked. Represent complex logic by using decision tables or decision trees to cover all the possible situations.

Create a checklist of common functional areas to consider for your projects. Examples include error logging, backup and restore, access security, reporting, printing, preview capabilities, and configuring user preferences. Periodically compare this list with the functions you’ve already specified to look for gaps.

A data model can reveal missing functionality. All data entities that the system will manipulate must have corresponding functionality to create them, read them from an external source, update current values, and/ or delete them. The acronym CRUD is often used to refer to these four common operations. Make sure you can identify functionality in your application to perform these operations on all of your entities that need them.

Watch out for the dreaded trap of analysis paralysis, spending too much time on requirements elicitation in an attempt to avoid overlooking any requirements. At some point you need to establish a relatively stable requirements baseline that describes what you’ll be implementing in the next release or iteration. But expect to perform some additional elicitation throughout the course of the project, no matter what life cycle the project is following.

I once encountered a development team that was implementing a content portal that was intended to do many things, including upload, edit, and publish content to a website. There were approximately 1,000 pieces of existing content, organized in a hierarchy. The content management team assumed that users would be able to navigate the hierarchy to quickly find a specific piece of content for editing. They did not specify requirements regarding the user interface navigation. However, when the developers implemented the user interface to navigate to content, they organized all of the content in a single level, not hierarchically, and showed only 20 items per screen. To find a specific piece of content, a user might have to navigate through as many as 50 screens. A little more specification and dialogue between developers and the content management team could have avoided considerable rework.

You will never document 100 percent of the requirements for a software system. But the requirements you don’t specify pose a risk that the project might deliver a solution different from what stakeholders expect. Two likely culprits behind missed expectations are assumed and implied requirements.

Assumed requirements are those that people expect without having explicitly expressed them. What you assume as being obvious might not be the same as assumptions that various developers make. Implied requirements are necessary because of another requirement but aren’t explicitly stated. Developers can’t implement functionality they don’t know about. Assumed and implied requirements both rely on a certain amount of telepathy and clairvoyance, which are not strong technical foundations for a software project.

To reduce these risks, try to identify knowledge gaps waiting to be filled with implied and assumed requirements. Ask, “What are we assuming?” during elicitation sessions. If you come across an assumption during requirements discussions, record it and confirm its validity. People often assume that things have to be the way they’ve always been because they’re so familiar with an existing system or business process. If

you’re developing a replacement system, review the previous system’s features to determine whether they’re truly required in the replacement.

To identify implied requirements, study the results of initial elicitation sessions to identify areas of incompleteness. Does a vague, high-level requirement need to be fleshed out into more detail so the stakeholders all understand it? Is a requirement that might be part of a logical set (say, saving an incomplete web form) lacking its counterpart (retrieving a saved form for further work)? You might need to re-interview some of the same stakeholders to have them look for missing requirements. Also, think of new stakeholders who know the topic and can spot gaps.

Read between the lines to identify features or characteristics the customers expect to be included without having said so. Ask context- free questions, high-level and open-ended questions that elicit information about global characteristics of both the business problem and the potential solution. The customer’s response to questions such as “What kind of precision is required in the product?” or “Can you help me understand why you don’t agree with Miguel’s reply?” can lead to insights that questions with standard yes/no or A/B/C answers do not.

We all know that you’re not going to discover and document every single requirement for a software system of any size. If you keep your eyes open for missing, assumed, and implied requirements, though, you’ll close a lot of the gaps that otherwise might cause development headaches farther down the road. [13]

Credits

[1] http://www.ryangreenhall.com/articles/bdd-by-example.html [2] http://en.wikipedia.org/wiki/Agile_software_development [3] http://www.iiba.org/babok-guide.aspx [4]http://en.wikipedia.org/wiki/Scrum_%28software_ development%29 [5] Software in 30 days, Ken Schwaber [6] The Enterprise and Scrum, Ken Schwaber [7] http://nomad8.com/acceptance_criteria/ [8] Scrum Reference Card by Michael James [9] The Guide to the Business Analysis Body of Knowledge Version 2.0 [10]http://en.wikipedia.org/wiki/A_Guide_to_the_Business_ Analysis_Body_of_Knowledge#Knowledge_Areas [11] Software Requirements, by Karl Wiegers [12] http://www.christiaanverwijs.nl [13] http://www.modernanalyst.com - Joy Beatty [14] www.standishgroup.com/

2. Meetings Intro Planning Estimating Review Meeting Retrospective Meeting Daily Scrum Meeting Communication Practical Communication CTS

Intro

Meetings are an important part of any project management framework and Scrum is no exception. We need to really understand the process if we want to give our contribution to the Team. In this chapter we’ll see how communication, planning and estimates will fit into these meetings and how we can optimize meetings in real projects. Scrum recommend only few types of meetings as discussed below, but regardless of the Project Management framework used, meetings should be held as least as possible and follows some basic rules: [1]

1.Make sure you really need a meeting before scheduling it. Could this be resolved by 10 minutes on the phone or via email instead? 2.Every meeting should have a purpose: You either need to make a decision or complete an action together. 3.Do not schedule more time than you need. Most meetings are scheduled for a full hour, when they should be 20 minutes, 30 minutes, or 45 minutes—max. 4.Start & end on time. Don’t wait for stragglers—it only encourages them. 5.Only invite the people who absolutely need to be there. The more

people in a meeting, the less that gets done. 6.Be friendly, welcome everybody and make sure you’ll run the meeting till the end without losing focus. 7.Distribute the supporting documents (including the agenda) to the audience at least 4hours ahead or the day before. 8.Book your meeting space ahead of time and make sure everything you need is working (wallboard, projector..) 9.Mute your phone and do not check emails during the meeting, lead by example. 10.Keep track of next steps or issues as the meeting goes on. You’ll discuss later with the relevant people. 11.Prepare the Minutes of Meeting (MOM) after the meeting is over and mail it to all the participants. Indicate also the actions and who is assigned to do them. 12.Watch body language. You can easily tell if people are bored, disengaged, or feel like their time is being wasted, so long as you look for it.

This is the list of the main Scrum meetings

• Sprint Grooming

• Sprint Planning

• Sprint Review

• Sprint Retrospective

• Daily Scrum

Grooming (Refinement) This meeting focus only on few Top priority PBI (Product Backlog Items) whereas the work to be included in the Sprint will be discussed in the Sprint Planning later. Grooming should not take more than 5% of the whole Sprint duration (Ken Schwaber) and the SM should try to follow the guidelines discussed above to save time and keep focus on the goal of this meeting.

Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. Teams have found it useful to take a little time out of Sprint Execution (every Sprint) to help prepare the Product Backlog for the next Sprint Planning Meeting. In the Grooming Meeting, the team estimates the amount of effort they would expend to complete items in the Product Backlog and provides other technical information to help the Product Owner prioritize them. Large vague items are split and clarified, considering both business and technical concerns. Sometimes a subset of the team, in conjunction with the Product Owner and other stakeholders, will compose and split Product Backlog Items before involving the entire team in estimation. A skilled Scrum Master can help the team identify thin vertical slices of work that still have business value, while promoting a rigorous definition of “Done” that includes proper testing and refactoring. [2]

Who should attend this meeting? PO, SM, the key Team members, and if necessary the key SHs.

Planning

The work to be performed in the Sprint is planned in this Meeting which is created by the collaborative work of the entire Scrum Team.

There are two defined artifacts that result from a sprint planning meeting:

•A sprint goal

•A sprint backlog

The two parts of the Sprint Planning Meeting answer the following questions:

1.What will be delivered in the next Sprint? 2.Which US the Team will commit to?

1. In this part, the Team works to forecast the functionality that will be developed during the Sprint. The Product Owner presents ordered PBIs to the Team and they all collaborates to understand the work of the Sprint. New US can be added and some can be deleted. The same apply for the Acceptance Criteria which are part of the US of course. The PO will also provide priorities and additional details. As you’ll have probably noticed this part includes the Conversation and the Confirmation both essential to complete and estimate the US.

2. Large US will be decomposed in smaller Tasks in order to estimate them. The Team will estimate and commit to execute some PBI in the new Sprint. The list of these PBI is called Sprint backlog. The process of estimating will be discussed in the following pages.

Note: in practical, the Team is usually unable to estimate unless we provide them with more design details. These details usually comes from the User Experience Designer (UXD) as prototypes (wireframes or storyboards) representing the functional part of the user interface (UI). We’ll see later how this could be done in a real project.

The Sprint Goal A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the PO. The following are few examples for an eCommerce application:

Implement basic shopping cart functionality including add, remove, and update quantities. Develop the checkout process: pay for an order, pick shipping, order gift wrapping, etc.

The sprint goal can be used for quick reporting to those outside the sprint.

It gives the Team some flexibility regarding the functionality implemented within the Sprint and as they work, it keeps this goal in mind.

In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. Velocity is used in sprint planning to help estimating a US.

Estimating

Estimating is an art, not very accurate but still we like to believe that estimating is not guessing. Some people believe that estimating is just guessing and therefore cannot be calculated since math is not an opinion. This is wrong as the whole statistics deal with calculated probabilities. Guessing is just trying your luck as you do, for instance with the national lottery where we have absolutely no clue of what could be the outcome. However when we estimate something we usually have more data that we can use to calculate the ‘basis of estimate’. “Through carefully planned equations, hierarchical listing of elements, standard calculations, checklists of project elements and other methods… These calculations formulate a Basis of Estimate” [4]

Here are some of the common practices used to estimate a task:

Analogous estimating

• PERT

• Regression analysis

• Poker

In Scrum we mostly use the last one, but we’ll have a quick overview to the others as well.

Analogous estimating It is one form of expert judgment and it also known as Top-down Estimating. This technique is used to determine the duration of the project. After finalizing the high level scope/requirement, the PM will refer & compare the previously completed projects similar activities with the current activities and determine the duration. This estimation technique will be applied to determine the duration when the detailed information about the project is not available, usually during the early stages of the project. This technique will look the scope/ requirement as a whole single unit to estimate. This estimate will give a ball-park idea about the estimation and will have bigger variance.

Eg : To estimate the time required to update the project, we need to compare similar past projects and estimate the duration with historical data and expert judgment.

PERT Project Evaluation and Review Technique is widely used in traditional project management to estimate activities’ duration in the project. It’s a statistical technique that evaluate 3 parameters and it’s therefore also called 3points estimate. PERT is able to estimate with 50% of probability the activity‘s duration (EAD) and the technique is applied by asking the Team what are the estimated durations for the following scenarios:

• M= most likely

• P= pessimistic

• O= optimistic

EAD = (P+4M+O)/6

Here is a quick example applied to Scrum and using SPs from the Fibonacci series:

M=5 P=8 O=3

EAD=5.16

Regression analysis In statistics, regression analysis is a statistical process for estimating the relationships among variables. It includes many techniques for modeling and analyzing several variables, when the focus is on the relationship between a dependent variable and one or more independent variables. More specifically, regression analysis helps one understand how the typical value of the dependent variable (or ‘criterion variable’) changes when any one of the independent variables is varied, while the other independent variables are held fixed. Regression models predict a value of the Y variable given known values of the X variables. Prediction within the range of values in the dataset used for modelfitting is known informally as interpolation. [3]

Regression can be linear or nonlinear, a simple example of linear interpolation is given below. Assuming in the last project we estimated 20US and we found later that we underestimated about 35% of them. In the current project we have 30US to be estimated, what we should expect the rate of underestimated US to be this time? If we use the same process and constraints, the linear regression is:

20/35=30/x x=52.5%

Poker In Scrum one of the easiest way to estimate is by using the Poker method. This is possible only after the US has been discussed by the Team,

completed, committed and updated by the PO. If you don’t have cards, you could use the method below:

1. Draw on the wallboard 5 boxes containing the series you want to use for the SPs (the example uses Fibonacci) 2. Count up to 3 and ask the Team members to show their fingers when you hit 3. They need to do it simultaneously and without looking each other. 3. In case they all raised the same fingers you can just convert them in SP and update the US. If they have chosen a different number, then they should find consensus by discussing each other.





It’s important for the Team to have a good commitment and that everybody commit about that. In this way the SM gets buy-in from the Team and everybody agrees that the work, effort and US are realistic and achievable.

Note that Scrum’s main goal is quality not speed and that although the Sprint is time boxed, the velocity should be sustainable without compromising on pace & quality. Quality Assurance (QA) is a way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers. [5]

At the end of the meeting SM should make sure that everybody has enough work to do and he should also keep an updated work Calendar listing who is off during the execution of the Sprint.

Just to give you an idea, usually 4Hrs meeting are enough for 2 weeks Spring. However this can be optimized as we’ll see later in this chapter.

It is worth noting that underestimation is usually prevalent and perhaps more dangerous.

“it’s difficult to estimate even if you take in account that it’s difficult.” - Hofstadter’s Law

Who should attend this meeting? PO, SM & Team



Review Meeting

After Sprint execution, the team holds a Sprint Review Meeting to demonstrate a working product increment to the Product Owner and everyone else who is interested. The meeting should feature a live demonstration, not a report. After the demonstration, the Product Owner reviews the commitments made at the Sprint Planning Meeting and declares which items he now considers done. For example, a software item that is merely “code complete” is considered not done, because untested software isn’t shippable. Incomplete items are returned to the Product Backlog and ranked according to the Product Owner’s revised priorities as candidates for future Sprints. The Scrum Master helps the Product Owner and stakeholders convert their feedback to new Product Backlog Items for prioritization by the Product Owner. Often, new scope discovery outpaces the team’s rate of development. 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. The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend. It is the opportunity to inspect and adapt the product as it emerges, and iteratively refine everyone’s understanding of the requirements. New products, particularly software products, are hard to visualize in a vacuum. Many customers need to be able to react to a piece of functioning software to discover what they will actually want. Iterative development, a value-driven approach, allows the creation of products that couldn’t have been specified up

front in a plan-driven approach. [2]

PO has a significant role in this meeting since he’s responsible to accept the work done as completed and fully compliant to the initial business requirements. To do this he can use a specific tool called Coverage Matrix or Requirements Traceability matrix. This matrix ensures that each business need is tied to an actual requirement (US), and that each requirement is tied to a deliverable.

A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many-to- many relationship to determine the completeness of the relationship. It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the product to the matching parts of high-level design, detailed design, test plan, and test cases. [6]



There are few tips the PO could do to enhance the impact of this meeting:

• Record live a demo of the system for those SHs that could not attend the presentation • Distribute minutes of meeting (MOM)

Who should attend this meeting? PO, SM & Team (and any interested SH)

Retrospective Meeting

Each Sprint ends with a retrospective. At this meeting, the team reflects on its own process. They inspect their behaviour and take action to adapt it for future Sprints. Dedicated SM will find alternatives to the stale, fearful meetings everyone has come to expect. An in-depth retrospective requires an environment of psychological safety not found in most organizations. Without safety, the retrospective discussion will either avoid the uncomfortable issues or deteriorate into blaming and hostility. A common impediment to full transparency on the team is the presence of people who conduct performance appraisals. [2] With Agile there should be transparency of intent and an open mind to mistakes and issues that are inevitable in any organization. We need to accept failure and to learn from it so that we can continually improve ourselves and lead by example.

Geographically dispersed teams usually do not collaborate as well as those in team rooms. Retrospectives often expose organizational impediments. Once a team has resolved the impediments within its immediate influence, the SM should work to expand that influence, chipping away at the organizational impediments. SM should use a variety of techniques to facilitate retrospectives, including silent writing, timelines, and satisfaction histograms. In all cases, the goals are to gain a common understanding of multiple perspectives and to develop actions that will take the team to the next level. [2]

This meeting can be done in many different ways, what I found to be most effective in my experience is to combine 3 questions with the Star Fish technique as described below. Please remember that this is not a Performance Meeting (the whole Team is responsible for quality not the individual) nor a blaming meeting. Try to create to do list and prioritize it, discuss friendly about incomplete actions and make Fun!

Questions

1. What went Well? 2. What went Wrong? 3. What is the main open issue?

Star Fish technique You can start this technique by drawing a template on the wallboard.

Keep Doing Is a good starting point for team members to focus on typically all the good things that they liked about a project. You might want to encourage people to think about things in terms of, what would they miss if they didn’t have a particular practice, technique, technology, person, role, etc. A good example from a real session I’ve been in before is ‘Running performance benchmarking and tuning during an iteration helps to identify regressions or slowdowns so we can address them earlier’.

Do Less Helps to focus on practices that might need a bit more refining or that were simply not helpful in the current circumstance. Perhaps they add value but not as much as other practices could. An example here is that perhaps stand ups have become status meetings and so there should less of talking to one person (and more of talking to each other) during them.

Do More Is another type of focus that helps further highlight those points that team members might want to try more. A good example is that people are pair programming but a better understanding of the code might be gained by swapping more programming partners.

Stop Doing This related to activities that are not very helpful to development practices or not adding much value.

Start Doing Is a great opportunity for team members to suggest new things to try. Perhaps you might want to try a burn up chart on the whiteboard or try some new open source tool to help improving developer productivity.

Getting people to either write things up under the starfish in this manner is a great visual technique of estimating the overall health of your project. Most of the points on the starfish also try to coerce people into

actually creating action items instead of simply saying that something was not good. [7]

Daily Scrum Meeting

DSM is a short meeting lasting approximately 15 minute where all the Team members (including SM and PO if she want to participate) are standing up. The purpose of this meeting is for the team to discuss what they accomplished the day before, what they will accomplish over the coming day, and to raise any obstacles that they have encountered that may impede progress.

1.What did you accomplish yesterday? 2.What will you do today? 3.What obstacles are impeding you progress? The SM should remember the open issues that require his help and discuss them with the PO after this meeting. Team members may also be encouraged to briefly talk each other in order to get answers for any particular topic.

Release Meeting – Celebrate ! Depending on the deadlines, we may have a major release, say every 3 months and that will be a good time to celebrate. Team members, PO, SM and SH all worked together to deliver the intended product and celebrating this event will only have good impact on the overall Team. This celebration could also be a good opportunity to inform the audience about your plans for the future, and implicitly to gain buy-in from them.

It provides a way to say ‘thank you’ to your team and helps with motivation. Always publicize your successes both internally and externally. This will help raise you and your teams profile and credentials for future projects. Completion of a project and the steps along the way can be intrinsically

rewarding for project team members. Outwardly celebrating successes also can be a source of motivation for the team. When project milestones are reached, they should be communicated to project team members and stakeholders. “True motivation comes from achievement, personal development, job satisfaction and recognition.” - Frederick Herzberg

With time, it’s easy for the DSM to become just a Status meeting. This part become dominant and the meeting get boring. Try this: Peter is a developer, and from his point of view, all he needs is to talk maybe with a couple of other developers to get his job done. Why relate all the story to everybody? You’ll get the answer in the next paragraph.



Communication

We’ll now discuss about few communication tools that are really important for any PO or SM to make sure the message between the parties has been fully understood.

Four Sides Communication Model





• Factual Information: statements which are part of the news

like data and facts

• Self revelation: the speaker - conscious or not - tells something about himself, values, emotions etc. • In the Relationship-layer is expressed resp. received, how the sender gets along with the receiver and what he thinks of him. • The Appeal contains the desire, advice, instruction and effects that the speaker is seeking for.

Here is an interesting example [8]

Two people are eating a home cooked meal together. The one who didn’t cook says: “There is something green in the soup.” Sender Matter layer: There is something green. Self-revealing layer: I don’t know what it is. Relationship layer: You should know what it is. Appeal layer: Tell me what it is!

Receiver Matter layer: There is something green. Self-revealing layer: You do not know what the green item is, and that makes you feel uncomfortable. Relationship layer: You think my cooking is questionable. Appeal layer: I should only cook what you know in the future!

The other answers: “If you don’t like the taste, you can cook it yourself.”

Active Listening This is a method used to listen and respond to others in a structured and deliberate way. It requires a listener to understand and actively

evaluate what he or she heard. Actively listening can be used to achieve a number of goals during Elicitation since by adopting this technique the BA is able to listen, elaborate and rephrase the requirement with his own words.

Here is a simple example: The traffic peak time is between 4-6pm and Peter need to pick up his children at 4pm every Tuesday crossing downtown. His brother Bob, lives nearby the school and arrives home everyday at 3.30pm, except Monday and Friday when he’ll go to Gym and will come back at 6pm. What could suggest BA after actively listen to this story? Peter could probably ask Bob to pick up his children since he lives nearby and he’ll be free at 4pm.

Active Voice Active voice is a grammatical voice common in many of the world’s languages. It’s used in a clause whose subject expresses the agent of the main verb. That is, the subject does the action designated by the verb. A sentence whose agent is marked as grammatical subject is called an active sentence. In contrast, a sentence in which the subject has the role of patient or theme is named a passive sentence, and its verb is expressed in passive voice. While doing elicitation, PO should always try to convert sentences into active voice.

Hare are few examples: Harry ate six shrimp at dinner. (active) At dinner, six shrimp were eaten by Harry. (passive)

Beautiful giraffes roam the savannah. (active) The savannah is roamed by beautiful giraffes. (passive)

Sue changed the flat tire. (active) The flat tire was changed by Sue. (passive)

We are going to watch a movie tonight. (active) A movie is going to be watched by us tonight. (passive)

Ambiguity It can be very insidious since it can lead to misinterpretations of the requirements with a resulting time waste for all the Team members and the Stakeholders. Ambiguity issues include the following:

Some members may intend the requirement in a different way and therefore they do not raise any doubts. It’s interesting to note that in this case they say they’ve understood the requirement (but not as the PO intended).

Some members do raise doubts because they have recognized ambiguity. In this case the PO can easily clarify to them the right meaning of the requirement.

To effectively deal with point 1, PO need to make sure that the Team has clearly understood the requirements. Showing a prototype of the feature can usually help as well as asking open questions to the Team.

Ambiguity is an attribute of any concept, idea, statement or claim whose meaning, intention or interpretation cannot be definitively resolved according to a rule or process consisting of a finite number of steps. The concept of ambiguity is generally contrasted with vagueness. In ambiguity, specific and distinct interpretations are permitted (although some may not be immediately apparent), whereas with information that is vague, it is difficult to form any interpretation at the desired level of specificity. Context may play a role in resolving ambiguity. For example, the same piece of information may be ambiguous in one context and unambiguous in another. [9]

Here is an example:

“Put the box on the table by the window in the kitchen” could mean any of the following:

• Put the box onto the table that is by the window in the kitchen.

• Take the box that is on the table and put it by the window in the kitchen. • Take the box off the table that is by the window and put it in the kitchen.

Open & Closed questions When we ask questions we can generally have 2 types of questions: open and closed. If we need to gather more information probably we want to ask open questions. Closed questions: they can be answered with Yes or No. Eg have you ever been to London? Open questions: they cannot be answered with a simple Yes or No. Eg. Can you tell me what you did yesterday.

Optimization Process optimization is the discipline of adjusting a process so as to optimize some specified set of parameters without violating some constraint. The most common goals are minimizing cost, maximizing throughput, and/or efficiency. This is one of the major quantitative tools in industrial decision making. [10]

When it comes to meetings, time is important and we should try to optimize them with the guidelines given in this chapter. Additional optimization can also achieved by combining multiple meetings together. For instance Review, Retrospective and Planning could be done all in a single session. This is not uncommon and can save some time keeping

the audience focused on the goal of the meeting.

For instance, in real projects having 1week sprint all the 3 meetings could be held in just 2hrs providing we distribute the relevant documentation in advance to all the participants. This works well when the Team is performing (see later) and not exceeding the 7+2 members.

It’s quite interesting how the best intentions and methodologies do not always work as expected. The reason often lie in the lack of communication.

Try this: George works on the Back End whereas Tommy on the Front End. Ask George if he knows how Tommy calculate the average in the FE. He doesn’t know, but PO should know it. Every devs know just enough to complete their task. It’s good enough for them, and they do not really see the need to communicate to the other Team Members (TM) providing they can do their job. That’s why some of them said once that ‘DSM is only a waste of time’. From their perspective it appear true, but we need to go beyond and to find the real reason for this. What TM do may impact other’s work, and this is why they need to communicate as much as possible the outcome of their discussions to the PO and the rest of the Team. On a regular basis. Anyboby can write a piece of code, but only great programmers write code that humans can understand. Have you noticed the communication context here? Communication means respect, as soon as you stop respecting a person, you’ll stop communicating with her.

CTS

CTS is a short for Comm, Trust and Support, 3 great principles to manage your Scrum. There are many articles and topics on how to manage an Agile Team but, spite of the best intentions I’ve seen often that the resulting strategy just goes in the opposite direction. Ultimately what we get is a TM or PO pretty demotivated, and the company’s turnover

increases. We want collaboration and enthusiasm but we really promote the opposite and demotivate people to stay with us. Why? I found my answer working with real teams, and I want to share it with you, if we improve CTS, results are bond to be positive.

C for Communication. Yes we all do the DSM everyday but, with time, this meeting becomes just a (boring) status meeting without people getting really interested to hear what others do. No questions whatever they say and no clarifications are asked. They’ll watch the clock to close it within 15min. This was not the intended purpose of DSM. TIC is the real purpose of the DSM: Transparently Improve Communication.

Ask questions if you need, and share with others what you do. As a developer, Mark may feel it as a waste of time, why? He just need to interact with few others to get his code done. That’s it. He don’t care much if others may benefit of knowing how he fixed his issue. This is a wrong attitude, if it’s relevant to the Team, Mark should always share it. It cost time of course, but in the True spirit of a ‘Performing Team’, this info is a value for the company and should be shared with all.

PO will also come to know what is going on, and will be able to answer more questions improving the overall productivity. Communication means many things. It enhance the value of Respect. No Respect no Communication and bad things will happen. This apply to the Team and to large cultures as well. History teaches us that when cultures do not respect each other, communication will die. One culture will try to dominate and exploit the other, and conflicts will inevitably arise.

T for Trust. What happen when the Team do not trust the PO? “He doesn’t know the product why wasting time to involve him?” It’s true that, at the beginning, PO may not know the product’s details like other TM, but he need to know more than what a developer knows. He need to dive into the details of the application, yet this is not enough. He need the upper manager (say the Director) to trust him openly in front of the Team. The Director shall do this because he hired the PO, he wants PO to perform and by doing this he’s protecting his investment. If

the Director cannot trust the PO,why the Team should? “Hey guys Bob is the PO, for any problems you must contact him. He’ll get back to me in case he doesn’t have the answer”. This is the way to go. If you don’t trust a person it’s likely you don’t communicate with him. However the opposite is also true, therefore to increase trust, communication is the key. Of course the above works fine if PO does the homework. He really need to dive into details and provide good answers, the best he can.

S as Support. During a Raid, Marines move in a queue. But there is something more interesting in this. The guy behind you takes care of your safety, and you take care of the guy in front of you. This is the true spirit of collaboration a Team should develop. Not just doing things for yourself, but sharing what you know (when it’s relevant of course) with others. Without this support most of the projects are bond to fail. Lacking of upper management support, is one of the main reasons for project failure. People sometimes are scared to openly support others, sometimes they think this is going too personal. This is not the case; stick to the business and support others you trust. Do it openly when necessary, avoid gossips and focus on the real issues (not how they may appear). Supporting a person openly has a huge impact on people. It tells very clearly to everyone that the person you’re supporting is worth and, ultimately represent you in front of the Team. This brings multiple values to the company like loyalty, transparency, productivity, enthusiasm and true collaboration. With these values in place everything is possible.

It require much less energy to smile than to be tense the whole day, and by developing positive values you’ll find yourself (surprisingly) happy at work. This is my experience.

There is even more about communication; the information we exchange is a value for the company, and if we do not save it somewhere that value is wasted. Take a US (User Story) for instance: it’s a planning tool, not a contract

like a Use Case. This means that between the US and its implementation you will have (quite normally) a lot of questions going on in the Team. Usually the PO address them as well the SM. However the company should think to save the important Q&A into a FAQ or (better) a Wiki. For instance: PO is refining a US, in the meantime Bob (the designer) goes and talk to Amy (a developer). At the end of the day the outcome is lost if Amy (that had the issue) do not inform the Team of the outcome. Of course this need to be done only if the topic is relevant for the whole Team. PO receive the email and update Wiki. By doing so Amy has updated the Team and PO has saved the information. Everybody will be able search it later on in a single place. This will improve the overall productivity and the knowledge of the product. Moreover by informing others we express respect for their work. This is good to promote true collaboration among TMs.

Credits

[1] http://www.thedailymuse.com/ [2] Scrum Reference Card by Michael James [3] http://en.wikipedia.org/wiki/Regression_analysis [4] http://en.wikipedia.org/wiki/Basis_of_estimate [5] http://en.wikipedia.org/wiki/Quality_assurance [6] http://en.wikipedia.org/wiki/Traceability_matrix [7] https://www.thekua.com/rant/2006/03/the-retrospective-starfish/ [8] http://en.wikipedia.org/wiki/Four-sides_model [9] http://en.wikipedia.org/wiki/Ambiguity [10] http://en.wikipedia.org/wiki/Process_optimization

3. Enterprise Agile Management Intro Agile Transition Transformation Scrum Integration Scrum of Scrums Team & Leadership SH Management Risk Management Megaprojects

Intro

Many organizations are deciding to switch to Scrum. As with many other types of organizational transformation, the results depend on many factors but one thing is common for all: the wrong process produces the wrong results [1]

Performance The overall performance is probably one of the strongest motivation to change and it can be assessed in different ways including a tool called Balanced Scorecard (BSC). The BSC is a strategy performance management tool, a semi-standard structured report, supported by design methods and automation tools, that can be used by managers to keep track of the execution of activities by the staff within their control and to monitor the consequences arising from these actions. [4]

The characteristic of the BSC is the presentation of a mixture of financial and nonfinancial measures (KPI) each compared to a ‘target’ value within a single concise report. The report is not meant to be a replacement for traditional financial or operational reports but a succinct summary that captures the information most relevant to those reading it. It is the method by which this ‘most relevant’ information

is determined (i.e., the design processes used to select the content) that most differentiates the various versions of the tool in circulation. The balanced scorecard also gives light to the company’s vision and mission. These two elements must always be referred when preparing a balance scorecard. [4]

A KPI is a type of performance measurement and an organization may use KPIs to evaluate its success, or to evaluate the success of a particular activity in which it is engaged. The following are examples of KPIs : • Cycle Time – from the beginning to the end of your process

• Rejection rate

• Availability / Uptime

• Mean time between failure (MTBF)

• Mean time to repair

• Unplanned availability

• IT Project Execution

• Earned Value

• Estimate to Complete

• Labour Spent /month

• Dollars Spent /month

• Planned Dollars /month

Scorecards This tool help dividing the enterprise in 4 main perspectives:

• Financial: encourages the identification of a few relevant high-level financial measures. In particular, designers were encouraged to choose measures that helped inform the answer to the question “How do we look to shareholders?” Examples: cash flow, sales growth, operating income, return

on equity.

• Customer: encourages the identification of measures that answer the question “How do customers see us?” Examples: percent of sales from new products, on time delivery, share of important customers’ purchases, ranking by important customers. • Internal business processes: encourages the identification of measures that answer the question “What must we excel at?” Examples: cycle time, unit cost, yield, new product introductions. • Learning and growth: encourages the identification of measures that answer the question “How can we continue to improve, create value and innovate?”. Examples: time to develop new generation of products, life cycle to product maturity, time to market versus competition.



There are few ways an enterprise could implement Agile, here are listed few possible scenarios:

• Agile Transition

• Scrum Integration

• Scrum of Scrums

• Agile Integration

Agile Integration will be discussed in a separate chapter.

Agile Transition

The enterprise will embrace Agile as an opportunity to change the cultural attitude of all the people working in it. It’s a long term transition which implicates a major transformation of the whole organization usually causing a good deal of upheaval at all levels. The transformation project must be led with commitment from the top and must employ excellent and consistent communication. The vision must be clear. The entire organization must participate and realize the benefits. The goal is a learning organization that continually renews and improves itself. The reward is excellence.

In the transformation to Scrum, the entire organization may work in a controlled chaos for several years. Ultimately, software releases become better and better, the employees are happy to come to work, and customers begin to love working with the organization. However, the transformation is dependent on the senior executive who initiated it.

The most successful person in an organization is a senior executive who rolls out Scrum throughout the entire organization. This person knows what it takes to achieve significant organizational transformation. This person knows that cultural transformation has to be pervasive and complete in order to take root. When such a person describes the successes, he or she doesn’t talk about what “I” did but about what

other people did.

Changing an organization culture to Agile may require years not months. Too often, this person is promoted out of the organization or recruited elsewhere before the other people who understand the new way of thinking and working are promoted throughout the organization, and before the transformation has been anchored into the organization. So when the senior executive leaves, the improvements unravel. The old culture, which was layered over but never rooted out, reasserts itself. The excellence and continuous improvement slowly decrease. The organization stays much, much better than it was before they started using Scrum, but it isn’t what it could have been. People become careful. Within several years, the organization is not as bad as it was when it started, but it is not an agile Scrum organization either. Opportunity has been lost.

While switching to Scrum we should remember two things:

• Do Not Try to Change or Adapt Scrum

• Do not hesitate

To implement Scrum, an organization has to make two major changes. First, the software developers have to be formed into teams and taught how to create software using Scrum. Second, any impediments to the optimized creation and delivery of software must be removed. These impediments are discovered as the developers use Scrum. The first change will improve software delivery; the second will remedy impediments to productivity and return on investment.

Once you decide to implement Scrum within your organization, a journey begins with a belief that the effort will be rewarded with a more effective software process and a more responsive and competitive company.

• Start the transformation

• Communicate vision & strategy

Start the Transformation Project The first play lays the groundwork for rest of the project. During it, you will learn what Scrum is and how to use it to improve and become agile. The vision, goals, strategies, and tactics for the project are developed in this play, along with the budget and road map. The road map is very tentative and fully dependent on the energy and commitment of the transition team and the ability of the organization to change. The energy for the transformation starts here, and the communication channels are initiated at this point.

Urgency arises from the organization’s need to provide competitive services and products. If it cannot, its customers will go elsewhere. The most senior executive who wants the transformation forms a new enterprise transformation project. He or she is the leader of the project and must be committed to the transformation. He forms a project team called the transformation team. This team is the heart of the transformation. It includes key executives who want the transformation to happen. The transformation team’s job is to guide the organization from the current urgent situation to the envisioned state. It first develops a vision of what the organization will look like when the transformation is complete.

If people are worried that they don’t know what to do or how to do it, communications are not effective. Inadequate communication causes opacity, spin, and rumors. The message that the transformation team crafts and expands has to be clear.

A communication plan is a written document that describes

• what you want to accomplish with your association

communications (your objectives),

• ways in which those objectives can be accomplished (your goals or program of work), • to whom your association communications will be addressed (your audiences),

• how you will accomplish your objectives (the tools and timetable), and • how you will measure the results of your program (evaluation).

Communications include all written, spoken, and electronic interaction with association audiences. A communication plan encompasses objectives, goals, and tools for all communications

Everyone knows the existing culture of the organization: how managers act, how to get things done, how to get promoted, how to get a salary increase or bonus, how mistakes are handled, and so on. Even if they don’t like the way things are at work, they are comfortable in knowing how things are. If people do not understand the vision for the future and where they fit into it, no matter how good it is, they will resist it.

Employees at all levels need to know exactly what impact the proposed changes will have on them, their jobs, and their families’ security.

The very first communication about the transformation should come from senior management to the entire organization. It should happen everywhere at once. The executives should describe the problem, the urgency, and the vision Everyone in the organization needs to see progress toward the vision.

The heart of Scrum is inspection and adaptation. Adaptation is how a new way of managing and developing software emerges. The transformation team continues to inspect what is going on, what the metrics show, and what impediments are being reported.

Transformation

Scrum does not define how an enterprise or business unit operates, and it is typically not the only development process present in a large organization. As a result, “Scrum projects” must interface with the rest of the enterprise in a graceful fashion, which comes with a unique set of challenges. Are you struggling with adoption, but not sure why? You’re not alone. Here are few of the most common challenges faced when adopting scrum.

1. Corporate Culture is Putting up Roadblocks A strong corporate culture not accustomed to the Agile mindset can be a hard environment for implementing Scrum methods. Recently I’ve been working for 2 multinationals as a consultant. They used “Scrum Terminology” without having Scrum in place. Probably by doing that the upper management was happy to show off a competitive advantage and aggressive delivery. But in reality the enthusiasm of “learn as we go” is often used as an excuse to justify a lack of organization, or more often just a chaotic culture about software development. (SDLC)

According to a recent survey conducted by VersionOne, an agile management software manufacturer, the “inability to change organizational culture” was considered a barrier to agile adoption by over half the participants. Even after going agile, 24% of the companies admitted their agile projects failed because the “company philosophy or culture was at odds with core agile values.” It’s easy to see how adopting Scrum processes can be a challenge if the Agile philosophy itself isn’t fully embraced. In some cases, the company’s incentive structure may reward non-agile benchmarks while inadvertently discouraging agile success. That’s a tough one to manage because philosophy and “the big picture” tend to pale in comparison to the biweekly paycheck. In many cases, roadblocks are actually a symptom of a larger cultural issue within the organization or a failure to truly commit to going agile across the board.

2. Team Members are Resistant to Change Closely related to the organizational culture, but perhaps bringing it down to a more personal level, 42% of respondents in the VersionOne survey stated that “general resistance to change” created a barrier to going agile. Change is inherently difficult and uncomfortable, especially for veteran team members who have a long history of waterfall successes to look back on. The average Joe sitting at a workstation in the Engineering Development team can throw a monkey wrench into a transformation when he maintains a stubborn “this is how we’ve always done it” attitude. Even if you’re lucky enough to have top-level support for Agile transformation, it’s hard to achieve success if team members aren’t on board with Scrum methods.

3. We’re Putting a Round Peg in a Square Hole Unfortunately, when a company maintains a non-agile framework and tries to shoehorn agile practices into it, they end up accomplishing less, being less productive, achieving lower quality results… and somehow deciding that it’s Scrum that doesn’t work. Large, complex projects with multiple communicating subsystems that depend on each other require choreographing the right pieces and parts. For example, Large IT organizations are accustomed to tracking progress against predictive schedules and Gantt charts and milestones. Each milestone has a specific set of activities, planned for completion by specified dates.

The Project Manager tracks actual progress, notes deviations from the plan, and responds to the deviations as needed to begin work, get the project back on schedule, or modify the schedule.

Scrum projects do not have the same kind of milestones. In Scrum projects we do not waste much time with Project Plans and schedules that 90% of the time will notbemet. Progress is tracked by task or feature completion rather than against a predicted or desired schedule. If the framework for this concept is not in place, Scrum adoption is very difficult. In fact, the third biggest barrier to adopting Scrum according to 35% of survey participants was “trying to fit agile elements into a non-agile framework.”

While transformation is not easy, it is possible. Whether you need help with change management, team building, training or overall strategy, a tailored approach to Agile Adoption can simplify the process. Here are a few ways to make the move to Agile go as smoothly as possible:

Review these Agile Transformation Case Studies to learn from other successes. Bring in a qualified Agile Coach to guide you through the transformation process. Schedule an Agile Strategy Session to create a plan for moving to Agile. Download our Agile Planning Engagement document to start putting a plan in place.



Scrum Integration

Organizations can be broadly divided into 3 different types [5]:

• Functional

• Matrix

• Projectized

Functional The functional organization has different functional areas each one controlled by a Functional Manager (FM) who is responsible for budget. The project manager (PM) is just a coordinator which facilitate project activities among the FMs. This is a line management organization where the FM is a leader having authority over his own Team.



Switching to Scrum in this case would require the organization to switch first into a Matrix type and then assigning the roles of SM & PO as below.



Projectized In this type of organization the PM manage the projects with full

authority over the budget and the Team.

A simple way to switch to Scrum in this case would be to assign the role of SM to the PM and adding the PO role to the Team. PO & SM will then report directly to the CEO for their respective project and the CEO will not interfere with the Team.

Matrix (balanced) In this type of organization the PM manage the projects with limited authority and the budget is managed jointly by FM & PM. A simple way to switch to Scrum in this case would be to assign the role of SM to the PM and adding the PO role to the Team. PO & SM will then report directly to each FM for their respective project and each FM will not interfere with the Team.





Scrum of Scrums

Not all organizations are ready to embrace Agile from ground up. Probably the recognize the tremendous advantage to manage projects with Scrum but the organization is not ready to uproot its culture and

this is especially true when large enterprises are getting involved.

Agile software development continues its forward march. Technical practices like Test Driven Development and Continuous Integration introduced by Extreme Programming at the start of the decade are now common place. The short sprints and product backlogs of Scrum are changing the way development work is project managed. Yet to fully realize the benefits of Agile companies need to change how they go about project governance.

Governance – and the related issue of requirements – is the next challenge for Agile development. [2]

The traditional model Traditionally projects start with the definition of a set of requirements and a defined set of expected benefits. Based on this information a budget can be set and resources allocated. The governance process is thereafter largely concerned with ensuring the requirements are met within a given timeframe and within the agreed budget. [2]

Assuming all goes well, the benefits are delivered at the end of the project – although it might be months before the benefits can be measured and a final assessment made of value added (or destroyed). Consequently while projects are in flight they are governed by metrics such as time elapsed, features competed or budget spent.

While many Agile projects have been governed by this model it imposed limitations on the projects. Maximising value – and chances of success – from an Agile project means letting the requirements evolve in tandem with the software. As the software is created needs are identified and added to the potential work.

There is a widely held view that Agile and Governance are in conflict. The primary concern seems to be that Agile methods promote self organizing as a major virtue, and that governance as it is conventionally practiced, is seen as a threat to that independence. Further governance

is perhaps viewed as review of prescribed deliverables against plans, which again is in potential conflict with the empirical Agile approach. [3]

In practice, if governance is practiced correctly, these concerns are unfounded. Governance should be about ensuring stakeholder objectives are met in a reasonable, cost effective manner. Of course one of the issues is that many organizations practice governance as a check that the required processes are being followed. Whereas effective governance is principle and policy led, and there is no conflict between this and the Agile process. The Agile Governance Pattern is a process pattern describing how a straightforward Agile process in an enterprise context can support a governance review process with perfectly adequate feedback on project achievements and concerns. [3]

I think the main point here is defining what is Scrum and what is an Enterprise and then trying to understand how these two objects can fit together. Scrum is a lightweight framework to manage projects inspired by the Agile manifesto. An enterprise (organization) is defined as a social entity, such as an institution or an association, that has a collective goal and is linked to an external environment. [7] PMI define a project as a temporary group activity designed to produce a unique product, service or result. [8] We can see that Scrum is designed to manage projects not an entire organization although the Agile principles can be extended to many activities inside the enterprise. An ongoing project is not a project but a process. Eg, purchase order processing is just one example.

Businesses worldwide, are experiencing a common increase of changes, uncertainty and unpredictability in the business environment. And the situation is not going to get any better, in fact it’s going to get worse. Large uncertainties and unpredictability are fast becoming the norms of everyday life. [6]

Businesses don’t like surprises. And they don’t like surprises because surprises can be dangerous. Unexpected changes can harm a business because enterprises are fragile, they are easily damaged and broken by unexpected and unpredictable changes and events.

How can we deal with this problem? We can solve it by building an enterprise that is not easily damaged and broken by unexpected and unpredictable changes and events. An enterprise that is agile to rapidly adapt to tomorrow’s surprises. It is not easy to create such an enterprise because it requires the development of a whole new set of business practices as well as radical changes across the whole enterprise.

Note that agility is not just about speed of response, it is about rapid adaptation that ultimately brings quality. In other words, enterprise elements are adapting in response to unexpected and unpredictable changes and events, new opportunities and customer requirements, new technologies and changes to industry structures.

What is an Agile Enterprise? An agile enterprise is a fast moving, adaptable and robust business. It is capable of rapid adaptation in response to unexpected and unpredicted changes and events, market opportunities, and customer requirements. Such a business is founded on processes and structures that facilitate speed, adaptation and robustness and that deliver a coordinated enterprise that is capable of achieving competitive performance in a highly dynamic and unpredictable business environment.

How do we build Agile Enterprises? It requires strategic vision to commit to embracing the emerging business environment. This involves creating an agile strategy that manifests principles of adaptation across the value chain. An enterprise’s agility drastically reduces if only part of the value chain is agile, hence, an Agile Enterprise needs an Agile Governance to drive Agility across the organization. Purpose of this governance is not to control but to ensure alignment of agile execution with agile strategy. It also takes responsibility of investing in team’s agility. This agile governance needs

to be very “lightweight” to justify agility of the process. In this article we will focus on how to create an Agile Governance as a building block for an Agile Enterprise. In physics the higher the mass (m) the higher the energy (E) associated with it movement (v). When a large mass enterprise is moving in one direction it will take a lot of energy to change its direction.

E= kmv^2

This doesn’t happen when the enterprise is Agile since less mass will ensure greater adaptability. To have less mass we need to run the organization based on a lean, Agile architecture.

How can we create lightweight Agile governance without compromising Agility? In order to understand Agile Governance, we need to understand the following two key concepts:

• Communities of Practice (CoPs)

• Scrum of Scrum (SoS)

Communities of Practice (CoP) They are nothing but Teams who share a concern or a passion for something they do and learn how to do it better as they interact regularly. You need one team leader per Team (could be the SM) and the focus is coordination.

What are the characteristics of CoPs?

• Formally committed to an organizational domain e.g. architecture, user experience, quality assurance etc. • Self-organizing

• Carry a community backlog

• Define domain roadmap

• Promote best practices

• Manage domain dependencies across teams

• Coordination and synergy

• Knowledge sharing and problem solving

Imagine a software project where you have 8 Agile teams working on delivering a single product. As you can easily guess, this project will have some common elements and lot of integration points. As an example, all teams need common user management, consistent look and feel, consistent error handling, common QA practices, and moreover a unified architecture to deliver a well integrated projects. Obviously, project needs multiple architects, UI designers and QA folks. It is old fashioned to create a dedicated team for each functional domain e.g. architects or UI designers or QA folks. It is too unproductive and non- agile to put these smart guys virtually away from the real teams. What can we do to bring the agility in team structure? We just need two simple steps: • Ensure that people in these functional domains are cross- functional and skilled while maintaining their area of expertise. • Create virtual CoPs who virtually maintain their domain specific backlog. These CoPs must be self-organizing.

So far so good, we solved the problem of creating silos while developing crossfunctional agile teams, however, we also introduced a new dimension by team virtualization. How do we ensure that these virtual teams are functioning well? How can we make these virtual teams more scalable?

Let’s introduce another concept called Scrum of Scrum (SoS), which helps in making Agile Governance scalable. SoS is introduced by Scrum but you can apply this concept in any Agile format. The scrum of scrums (SoS) is an important technique in scaling Scrum to large project teams. This concept allows clusters of teams to discuss their work, focusing especially on areas of overlap and integration. SoS creates an virtual environment to members of various Scrum teams to

function as Scrum of Scrum.

As you will notice that CoP and SoS are similar concepts (virtual) but with slight difference (vertical vs horizontal functions). Both concepts are used by many Agile teams. We can make process even more scalable by merging these concepts together. This merger provides us an Agile Governance which focuses on the strategic element of the organizations. As you will notice in the following diagram, you can implement SoS horizontally for the Agile Governance and Vertically for the CoPs. This approach makes CoPs more effective.





Team & Leadership

The whole process of building a team could be simplified in the following steps:

• Acquire

• Develop

• Manage

Acquire The typical method of hiring for technical positions – only based on Degrees and CV is dangerous in a lot of ways. Does it really matter where someone’s degree is from? Can you really trust a CV or a reference?

There are probably 2 important factors when it comes to recruiting the right candidate:

• Technical Skillset

• Behavior

The first one deal with technical ability to solve problems. It’s good to have of course and, ideally, a technical mind can always learn new technologies in a relatively short time, that’s why I call this a short-term ability.

The second is the way the candidate will operate in the organization as a whole, it’s the ‘holistic’ perspective. This will incorporate aspects like character, ethics, sense perception, productivity and a multitude of attitudes like learning, problem solving or coping with stress. Everything is printed in the DNA including the body language, preferences and the colour of his hairs. This is what I call a long-term ability.

When you hire somebody you can always ask to change or improve the short-term abilities but you can expect little or no improvements in the long-term ones, unless the candidate has a strong motivation to change.

Tech skillset We could assess technical skillsets in a variety of ways including qualifications, interviews and quizzes but probably the best way is to see what the candidate has accomplished so far. It’s not about the years of experience but about what you’ve achieved in those years. Imagine your uncle has started playing the guitar 20 years back. He has surely 20 years experience with that instrument but what he has achieved you’ll only know after you hear him playing his repertory.

The projects you’ve done speak about your achievements. Open source is a gift to those who need to hire technical people. With open source, you can track someone’s work and contributions (good and bad) over a lengthy period of time. That means you can judge people by their actions instead of just their words. You can make a decision based on the things that really matter: [1]

Quality Programing is all about decisions. Lots and lots of them. Decisions are guided by your cultural vantage point, values, and ideals. Look at the specific decisions made by a candidate in coding, testing, and community arguments to see whether you’ve got a cultural match.

Passion By definition, involvement in open source requires at least some passion. Go for happy and average over frustrated and great Find someone who’s enthusiastic.

Completion percentage All the smarts, proper cultural leanings, and passion don’t amount to valuable software if a person can’t get stuff done. Unfortunately, lots of programmers can’t. So look for that zeal to ship. If you want something done, ask the busiest person you know.

Behavior It’s difficult to assess the human behavior in the short time normally available during an interview. The 4-side model we’ve discussed before shows that many factors are involved during the physical interview and that’s why Scrum advocates for face to face communication among all the other possible forms of communication. There are books about interviews and how effectively we can conduct them, and I would suggest to have a look at them to make sure we do not miss any important question, but more that this probably is worth looking at what type of activities the candidate is doing or she has done in the past. It’s a broad discussion to find out what is the dominant attitude of the candidate, her main concerns, strengths and weaknesses. It could also help creating a scenario where she have to move forward by taking specific decisions. Without the attitude, the skill is nothing.

Halo effect The halo effect is a cognitive bias in which an observer’s overall impression of a person influences the observer’s feelings and thoughts about that person’s character. [9] A simple example of this concept is moving people which are technically able in their field to cover other roles for which they have limited or no experience. A good programmer may not necessarily be a good leader or a good teacher. Eg, we should not move people into management roles just because they’ve good technical skills.

Below are few terms commonly used by the Human Resources (HR) department: Role, Responsibilities and Duties.

Role Is a descriptor of an associated set of tasks; may be performed by many people; and one person can perform many roles. For example, an organisation may have ten people who can perform the role of project manager, although traditionally each project only has one project manager at any one time; and a person who is able to perform the role

of project manager may also be able to perform the role of business analyst and tester. [10]

Responsibilities Are major areas of accountability and are the primary functions of a job. Eg, a BA could be responsible to gather requirements and to do the financial analysis of the balance sheet every year.

Duties are functions that the jobholder performs to meet the job’s responsibilities. For example, a recruiter has the responsibility to recruit job candidates; the recruiter performs the duty of interviewing to find qualified job candidates. [11]

It’s worth noting that the most important asset in a company are people, and skilled people are most productive when they manage themselves. People take their commitment more seriously than other people’s commitment for them. People have many creative moments during downtime. People always do the best they can. And under pressure to work harder, people automatically and increasingly reduce quality.

Teams and people do their best work when they aren’t interrupted. Teams improve most when they solve their own problems. And broadband, face-to-face communication is the most productive way for teams to work together.

Teams are more productive than the same number of individuals. Products are more robust when a team has all of the cross-functional skills focused on the work. Changes in team composition often lower productivity for a time.[1]

Develop Developing the Team is an ongoing process requiring good communication skills and empathy.

The Forming – Storming – Norming – Performing model of group development was first proposed by Bruce Tuckman in 1965, who maintained that these phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results. [12]

The main focus is to build mutual TRUST among the team members as this is essential to effectively build something together.

Forming: people meet together. The individual’s behavior is driven by a desire to be accepted by the others, and avoid controversy or conflict. Serious issues and feelings are avoided, and people focus on being busy with routines, such as team organization, who does what, when to meet each other.. Storming: people start addressing project work. It’s necessary to the growth of the team and it can be contentious, unpleasant and even painful to members of the team who are averse to conflict. Tolerance of each team member and their differences should be emphasized. Norming: members start working together with TRUST and support each other. The team manages to have one goal and come to a mutual plan for the team at this stage. Some may have to give up their own ideas and agree with others to make the team function. Performing: start performing as a Team. Not all teams reach this stage. These highperforming teams can function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision. By this time, they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decision-making process without supervision. It’s the self-organizing team advocated by Agile.

It’s also good to remember that Co-location is an important factor to improve communication, and should be practiced as much as possible. Co-location means to have all the team members sharing a common space.

Manage Managing a team involves different skillset and probably the most important of them is communication. It has been said that 90% of the time of a PM is spent in communication, and interestingly 55% of it is non-verbal. [8] Essentially the manager should know what to communicate, what not to communicate and how to do it.

In any project we should keep track of the calendars each team members is working on, and distribute the RACI matrix. RACI describes the participation by various roles in completing tasks or deliverables for a project or business process. It is especially useful in clarifying roles and responsibilities in cross-functional/departmental projects and processes. [10]

RACI is widely used to help managing the SHs and has few different meanings. Here I’ll use the following meaning, having a descending order of authority: Responsible, Assistant, Consulted and Informed.



Managing a team is not necessarily a hierarchic line management activity. In Scrum the SM is a servant-leader whose main objective is to apply Scrum and remove impediments not to assign tasks and monitor performances.

Resolving issues is part of the SM activities and can usually be done in the following ways:

• Escalating the issue

• Training

• Applying ground rules

It’s also important that all issues are logged and discussed with the relevant people.

Conflict Management It’s quite natural that conflicts arises when working in a Team, and they’re not necessarily a negative aspect. A resolved conflict may turn into a selling point for the whole Team that is able to catch the opportunity to grow into a more mature status. Again the focus is on communication, and as a general rule, those having the problem should help resolving it. There’s no need to blame anyone. Most conflict situations can be resolved without blaming others, so don’t turn your conflict handling into a finger-pointing exercise. In the oriental philosophy there a saying: ‘when you point your finger against someone, there are three more fingers pointing towards you’ In the end, it really doesn’t matter who started it or what happened or who did what. There’s a problem to be fixed and how you got to this point won’t make much difference to how you resolve it.

Teams members can (and should) come with preventive actions since conflicts can be reduced by informing the Team of the project status and continuously motivating them about the work challenges.

Eg, every month the PO could inform the Team about the long-term roadmap and the challenges the Team is going to face asking for everyone feedback.

When facing conflicts the following roadmap can help the right solution to emerge:

1.Identify the REAL problem (NOT as it may appear) 2.Analyze it 3.Identify Solutions 4.Pick One 5.Implement it 6.Verify it

Interestingly the main sources of conflicts are not due to personality’s clashes but rather to issues related with time. Here are the main causes listed in descending order:

• Schedule

• Priorities

• Resources

• Technical issues

• Administrative issues

• Cost

• Personality

The best resolutions technique is known as ‘problem solving’ and it’s probably more an attitude rather than a simple technique. Below are listed the common techniques used to resolve conflicts:

• Confronting (problem solving): give & take attitude

• Collaborating: trying to incorporate multiple viewpoints to reach consensus.

Eg. “Let’s see what other says and try to

reach a consensus”

• Compromising : solutions with shared satisfactions from all parties. Eg. “Let’s do a little of what both of you says” • Withdrawal (avoid, postpone): the issue remain and possibly will worsen • Forcing: this is anti-Agile and should be taken only under emergency’s situations.

Leadership Has been described as “a process of social influence in which one person can enlist the aid and support of others in the accomplishment of a common task”. Some define leadership as “organizing a group of people to achieve a common goal”. [13]

In Scrum all are leaders therefore it’s interesting to better understand this concept. There are several styles of leadership and the manager will apply them depending on the context.

Situational leadership theory says that there is no single “best” style of leadership. Effective leadership is task-relevant, and the most successful leaders are those that adapt their leadership style to the maturity (“the capacity to set high but attainable goals, willingness and ability to take responsibility for the task, and relevant education and/or experience of an individual or a group for the task”) of the individual or group they are attempting to lead or influence. Effective leadership varies, not only with the person or group that is being influenced, but it also depends on the task, job or function that needs to be accomplished. [14]

Leadership styles mostly used in Agile include the followings:

• Facilitating: is any activity that makes tasks for others easier. • Coaching: helping others achieve their goals. • Selling: while the leader is still providing the direction (PO), she is using 2-way communication and providing the socio-emotional

support that will allow the individual or group being influenced to buy into the process;

• Participating: how the task is accomplished

• Delegating: the leader is still involved in decisions, however, the process and responsibility has been passed to the individual or group. The leader stays involved to monitor progress.

Learn to listen By improving listening skills, the manager can enhance the effectiveness of their teams. At the same time, projecting the message that you’re willing to listen will make team members more willing to talk in the first place about what’s bothering them or keeping them from being as effective as they feel they could be otherwise. At the same time It’s important to remain flexible and reachable.

It’s also important to remember that the individual should try to develop various qualities to better perform in the Agile context, including the followings:

• Curiosity

• Creativity

• Courage

• Emotional Resilience (the ability of a material to absorb energy when it is deformed elastically, and release that energy upon unloading.) • Critical Thinking

• Vision

• Flexibility

• Honesty

Motivational Theories Motivation is the driving force that causes the flux from desire to will in life. For example, hunger is a motivation that elicits a desire to eat. [15] A motivated team is prompted to perform and achieve its goals and there are few theories that discuss the motivation in more details.

McGregor’s Theory of X-Y This theory deals with the perceptions managers hold on their employees, not the way they generally behave. X: in this vision people must be watched to work. This raise the need for a line management where somebody has to tell others what and how to do it. Y: in this vision, people are willing to work. This is the right attitude for a self-managing Team.

Maslow Hierarchy of needs Maslow wanted to understand what motivates people. He believed that individuals possess a set of motivation systems unrelated to rewards or unconscious desires. Maslow studied what he called exemplary people such as Albert Einstein, Jane Addams, Eleanor Roosevelt, and Frederick Douglass rather than mentally ill or neurotic people, writing that “the study of crippled, stunted, immature, and unhealthy specimens can yield only a cripple psychology and a cripple philosophy. [16]

Maslow stated that people are motivated to achieve certain needs. When one need is fulfilled a person seeks to fulfill the next one, and so on. The earliest and most widespread version of Maslow’s hierarchy of needs includes five motivational needs which can be divided into basic needs (physiological, safety, love, and esteem) and growth needs (self- actualization).

In Maslow’s view the highest motivation is to contribute and to use our skills for selffulfillment. An example of this could be the Open Source model.

McClelland This theory says that, regardless of our gender, culture, or age, we all have three motivating drivers, and one of these will be our dominant motivating driver. This dominant motivator is largely dependent on our culture and life experiences. According to McClelland, these motivators are learned (which is why this theory is sometimes called the Learned Needs Theory).

Here are the 3 main driving factors for the individual as per McClelland:

Achievement Has a strong need to set and accomplish challenging goals. Takes calculated risks to accomplish their goals. Likes to receive regular feedback on their progress and achievements. Often likes to work alone.

Affiliation Wants to belong to the group. Wants to be liked, and will often go along with whatever the rest of the group wants to do. Favours collaboration over competition. Doesn’t like high risk or uncertainty.

Power Wants to control and influence others. Likes to win arguments. Enjoys competition and winning. Enjoys status and recognition.

McClelland’s theory can help you to identify the dominant motivators of people on your team. You can then use this information to influence how you set goals and provide feedback.

Eg. One of your team members recently created a report that was so thorough and well-written that the board of directors asked you to

make sure that she was praised for her efforts. So, at your monthly staff meeting, you stood up in front of the group, and congratulated her on her achievement, and for the good impression she made for the team. However, instead of smiling and appreciating the attention, she looked embarrassed. She lowered her head, and as soon as she could, she left and went to her office. Using McClelland’s theory you would have known that her main motivational driver is affiliation, which means that she never wants to stand out in a crowd. So, your feedback would have been far more effective, and appreciated, if you had praised her in private. [17]

Herzberg (2-Factors theory) This theory identify 2 main factors: Hygiene & Motivation. Herzberg distinguishes between: Motivators (e.g. challenging work, recognition, responsibility) which give positive satisfaction, arising from intrinsic conditions of the job itself, such as recognition, achievement, or personal growth, and Hygiene factors (e.g. status, job security, salary and fringe benefits) which do not give positive satisfaction, although dissatisfaction results from their absence. These are extrinsic to the work itself, and include aspects such as company policies, supervisory practices, or wages/salary. Essentially, hygiene factors are needed to ensure that an employee is not dissatisfied. Motivation factors are needed in order to motivate an employee to higher performance.

Eg. Hygiene Factors Good relations with People, working conditions Job security Salary Fringe benefits

Eg. Motivating factors Responsibility Growth Self-Realization

SH Management

A stakeholder is the person, or organization that is actively involved in the project, or whose interests may positively or negatively affect the project. One of the most critical aspects of project management is doing what’s necessary to develop and control relationships with all individuals that the project impacts. In this paragraph we’ll discuss the main techniques to identify stakeholders, analysing their influence on the project, and developing strategies to communicate, set boundaries, and manage competing expectations. It’s surely one of the most important activities of the manager, and in Scrum this is mostly related with PO. Once you’ve identified who’s what with the RACI matrix, you then need to manage their expectations. The number one reason for project success (or failure) is due to earlier SH involvement. If we come to know the expectations of one SH at the end of the project, we may need to implement a major change to accommodate her expectations. That’s why the cost of change is low at the beginning and high at the end of the project. SH influence should be mapped in the Influence Matrix.

Both SH Influence and Risk are high at the beginning and low at the end of the project.

Your list of stakeholders can be very large, and you probably don’t want to expend equal emphasis or energy on every stakeholder. Stakeholder analysis involves three key steps:

• Identify the relevant information for each stakeholder: relevant information are things like their particular interest in the project, their role in the project, their level of authority (position), needs, and expectations of the project. • Identify the potential impact or support of each stakeholder: this can be simple like using two measures low and high.

• Assess how key stakeholders are likely to react to various situations:another measure like low sensitivity or high sensitivity



Risk Management

Risk management is the identification, assessment, and prioritization of risks (defined in ISO 31000 as the effect of uncertainty on objectives, whether positive or negative) followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate event or to maximize the realization of opportunities. [18]

When managing Scrum projects it’s a responsibility of the PO to manage risks and assess them. The overall process can divided in the following phases (in order): Identify, Assess, Control, Review

Identify Risks are about events that, when triggered, cause problems or benefits. Hence, risk identification can start with the source of our problems and those of our competitors (benefit), or with the problem itself. Risk sources may be internal or external to the system that is the target

of risk management (use mitigation instead of management since by its own definition risk deals with factors of decision-making that cannot be managed). Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport. [18]

Assess Once risks have been identified, they must then be assessed as to their potential severity of impact (generally a negative impact, such as damage or loss) and to the probability of occurrence. These quantities can be either simple to measure, in the case of the value of a lost building, or impossible to know for sure in the case of the probability of an unlikely event occurring. Even a short-term positive improvement can have long-term negative impacts.

Control Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these 4 major categories:

• Avoidance (eliminate, withdraw from or not become involved) • Reduction (optimize – mitigate)

• Sharing (transfer – outsource or insure)

• Retention (accept and budget)

Risk avoidance includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the legal liability that comes with it.

Risk reduction or “optimization” involves reducing the severity of the loss from occurring. Eg. sprinklers are designed to put out a fire to reduce the risk of loss by fire.

Sharing means involving a 3rd party company to share the burden of

loss or the benefit of gain, from a risk, and the measures to reduce a risk. A typical example is the car insurance which covers the case of accident.

Retention involves accepting the loss, or benefit of gain, from a risk when it occurs. Life insurance falls in this category. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. War and earthquakes are just few of the possible examples.

Another important concept related with risk is the Failure Modes and Effects Analysis (FMEA) which is a systematic, proactive method for evaluating a process to identify where and how it might fail and to assess the relative impact of different failures, in order to identify the parts of the process that are most in need of change. FMEA includes review of the following:

• Steps in the process

• Failure modes (What could go wrong?)

• Failure causes (Why would the failure happen?)

• Failure effects (What would be the consequences of each failure?)

Each failure mode gets a numeric score that quantifies (a) likelihood that the failure will occur, (b) likelihood that the failure will not be detected, and (c) the amount of harm or damage the failure mode may cause to a person or to equipment. The product of these three scores is the Risk Priority Number (RPN) for that failure mode.

RPN = Probability * Impact * Detection

Usually Probability, Impact and Detection have data values ranging from 1-10.

The sum of the RPNs for the failure modes is the overall RPN for the process. As an organization works to improve a process, it can anticipate and compare the effects of proposed changes by calculating hypothetical RPNs of different scenarios. Just remember that the RPN is a measure for comparison within one process only; it is not a measure for comparing risk between processes or organizations. [19] As the name suggest, the RPN is not a measure of risk, but of risk priority. You would apply your limited resources to the most important problems. The RPN gives you a model to allocate these resources. Higher numbers are higher priority, so you should work on an RPN of 900, before you put resources on an RPN of 30.





A practical example of risk assessment for a US can be described as below: “As a Buyer I want to know the shipping cost so that I can chose a different courier” Item 8 is the highest-risk item, so we want to be sure to test changing shipping addresses and verify the updated costs. We might want to automate an end-to-end test with this scenario. Item 5 is not a big issue, maybe we have already tested our postal code

validation and feel good about it, so we don’t need to test it more. [20]





Megaprojects

Megaprojects are large-scale, complex ventures that typically cost US$1 billion or more, take many years to develop and build, involve multiple public and private stakeholders, are transformational, and impact millions of people [21]

These projects have some peculiarities when compared to ‘traditional’ projects, and probably few considerations are worth the time for any Agile manager who have to work in such projects. Megaprojects are designed to ambitiously change the structure of society, as opposed to smaller and more conventional projects that ‘live’ in the society without attempting to impact it with major changes. Because of this characteristic, megaprojects are not just magnified versions of smaller projects but a completely different type of project in terms of costs, lead times, complexity, and stakeholder involvement.

Megaprojects are increasingly used as the preferred delivery model for goods and services across a range of businesses and sectors, including infrastructure, water and energy, information technology, industrial processing plants, mining, government administrative systems, banking, defense, intelligence, air and space exploration. Examples of megaprojects are high-speed rail lines, airports, seaports, motorways,

hospitals, national health or pension information and communication technology (ICT) systems, national broadband, the Olympics and offshore oil and gas extraction.

To illustrate just how big megaprojects are, consider one of the largest dollar figures in public economic debate in recent years—the size of the U.S. debt to China. This debt is approximately US$1 trillion and is considered so large it may destabilize the world economy if the debt is not managed prudently.



The driving forces behind megaprojects can be summarized in the followings:

• Technological The excitement engineers and technologists get in pushing the envelope for what is possible in “longest- tallest-fastest” types of projects • Political The rapture politicians get from building monuments to themselves and for their causes, and from the visibility this generates with the public and media • Economic The delight business people and trade unions get from making lots of money and jobs off megaprojects, includingmoney made for contractors, workers in constructionand transportation, consultants, bankers, investors, landowners, lawyers, and developers • Aesthetic The pleasure designers and people who love good design get from building and using something very large that is also iconic and beautiful, such as the Golden Gate Bridge

The main issues with Megaprojects include the followings:

• Megaprojects are inherently risky due to long planning horizons and complex interfaces (Flyvbjerg, 2006). • Often, projects are led by planners and managers without deep domain experience who keep changing throughout the long project cycles that apply to megaprojects, leaving leadership weak. • Technology and designs are often non-standard, leading to “uniqueness bias” among planners and managers, who tend to see their projects as singular, which impedes learning from other projects • The project scope or ambition level will typically change significantly over time. • Decision making, planning, and management are typically

multiactor processes involving multiple stakeholders, both public and private, with conflicting interests.

• Misinformation about costs, schedules, benefits, and risks is the norm throughout project development and the decisionmaking process. The result is cost overruns, delays, and benefit shortfalls that undermine project viability during project implementation and operations.

As a consequence 9 out of 10 such projects have cost overruns and this trend doesn’t seems to improve over time.

On one side, megaprojects as a delivery model for public and private ventures have never been more in demand, and the size and frequency of megaprojects have never been larger. On the other side, performance in megaproject management is strikingly poor and has not improved for the 70-year period.

It is, undoubtedly, quite common for project promoters and their planners and managers to believe their projects will benefit society and they, therefore, are justified in “cooking” costs and benefits to get projects built (Wachs, 1990; Pickrell, 1992). Such reasoning is faulty, however. Underestimating costs and overestimating benefits for a given project (which is the common pattern, as described above) leads to a falsely high benefit–cost ratio for that project, which in turn leads to two problems. First, the project may be started despite the fact it is not financially and economically viable. Or, second, it may be started instead of another project, which would have shown to yield higher returns than the project started had the real costs and benefits of both projects been known. Both cases result in Pareto inefficiency; that is, the misallocation of resources and, for public projects, waste of taxpayers’ money.

Not just for economic efficiency but for ethical reasons too Megaprojects are affected by a starting paradox: demand & performance. In most

democracies, for project promoters, planners, and managers to deliberately misinform legislators, administrators, bankers, the public, and the media about costs and benefits would not only be considered unethical but, in some cases also illegal.

Fortunately, signs of improvement in megaproject management have recently appeared. The tacit consensus that misrepresentation is an acceptable business model for project development is under attack. Shortly after taking office, U.S. President Barack Obama openly identified “the costly overruns, the fraud and abuse, the endless excuses” in public procurement for major projects as key policy problems (White House, 2009). The Washington Post rightly called this “a dramatic new form of discourse” [21]

Credits

[1] Software in 30 days, Ken Schwaber [2] http://www.e-technologymanagement.com [3] http://everware-cbdi.com/ds-test2 [4] http://en.wikipedia.org/wiki/Balanced_scorecard [5] Effective Stress Management ,Alex Manfield [6] http://www.agilehelpline.com [7] http://en.wikipedia.org/wiki/Organization [8] http://www.pmi.org [9] http://en.wikipedia.org/wiki/Halo_effect [10] http://en.wikipedia.org/wiki/RACI_matrix [11]http://office.microsoft.com/en-us/word-help/write-effective-job- descriptionsHA001189474.aspx [12]http://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_ development [13] http://en.wikipedia.org/wiki/Leadership [14] http://en.wikipedia.org/wiki/Situational_leadership_theory [15] http://en.wikipedia.org/wiki/Motivation [16] http://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs [17]http://www.mindtools.com/pages/article/human-motivation- theory.htm [18] http://en.wikipedia.org/wiki/Risk_management [19] http://www.ihi.org [20] Addison-Wesley Agile Testing, A Practical Guide for Testers and Agile Teams (2009) [21] Bent Flyvbjerg, Saïd Business School, Oxford University, UK

4. Change Management Change Management Traditional Change Control Agile Change Control Strategic Choices Real Projects



Change Management

This chapter do not deal with Organization Change intended as a transitioning process to move from one state (current) to a desired future state. That is discussed in a different chapter.

Here we’re going to discuss, in a project management context, changes related with the scope of the project. There are few definitions as below:

Change management refer to a project management process wherein changes to the scope of a project are formally introduced and approved (or rejected). [1] Change control within quality management systems (QMS) and information technology (IT) systems is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. [6] Integrated Change Control is the process of “…reviewing all change requests, approving changes, and controlling changes to the deliverables and organizational assets” [7]

It’s probably worth to remember that specs don’t deal with the reality that once you start building something, everything changes.

Traditional Change Control

Change control starts with a change request and the process appear rigorous and formal. [7] Everyone must follow the change control process, regardless of her position in the organization. If your sponsor or the customer demands a change, you may have to implement it, but you still have to submit a change request, log the change, analyse the impacts, and so forth. Change requests can include corrective and preventive actions, as well as defect repairs. Usually a SH fills out a change request, change requests can come from any stakeholder on the project.



Change log: Each change request is documented in a change log. The change log has information such as:

• Change ID

• Category

• Description

• Submitted by

• Date submitted

• Status

Analysis: You need to fully understand the impact of the change request across all areas of the project. This is where the project management plan comes in handy. Even if the change is not optional, you should still analyze and document the impact on all areas of the project and try to explore options to the change request.

CCB meeting: The change request and the completed analysis go to the Change Control Board. The CCB approves the change, denies the change, or defers the decision until more information is available and the status gets updated.

Communication: The change isn’t approved and the SH is advised of the reasons behind it.

Document updates: For changes that are approved, the project management plan and the appropriate project documents are updated and SH are updated.

Implementation: Changes are implemented in the project.

Verification: All approved change requests are verified in the Control Quality process to ensure that they were implemented as approved.

Monitor and Control Project Work The main objective of this process is to check that the work being performed to create the project deliverables remains in line with the baseline plan. The project’s baseline is used to measure how performance

deviates from the plan. Your performance measurement would only be meaningful if you had an accurate baseline.

A project’s baseline is defined as the original scope, cost and schedule and must be completely defined and documented before the project execution and control activities can begin. Whenever progress is not in line with the plan then the PM will need to take some form of corrective action.

The key to understanding integrated change control is that this compares actual work results against the plan, and then makes any adjustments required in order to ensure that the plan and the actual results are in harmony.

These actions or take place within integrated change control. In summary, Monitor and Control Project Work Is all about managing the way that the project scope is executed.

As an example, suppose that you need to change the number of resources being used on future work, then you could issue and change request to modify the use of such future resources. The main inputs to integrated change control are the performance reports that will provide the evidence that such changes are necessary, and allow you to determine if it is necessary to take any such corrective actions. [8]

Included in these performance reports are the forecasts of future project performance, and these will help you determine appropriate preventative action to ‘head-off’ such problems before they arise in the first place. The two major outputs from integrated change control are the change requests mentioned above, and the main output will be updates to incorporate such changes within the project management plan.

Perform Integrated Change Control Every single change that is requested or otherwise, will be processed through the Perform Integrated Change Control process.

Integrated change control is where the impact of any change is assessed against the project, and this is the reason why this is called ‘integrated’. If a change were to occur in one part of a project, it needs to be assessed across the whole project.

The main difference between integrated change control and Monitor and Control Project Work, is that whereas Perform Integrated Change Control focuses on managing any change to project scope – Monitor and Control Project Work focuses on managing the way that such scope is executed.

For example, if a new application is requested to be added to an IT solution project, then such a change request would need to be re- evaluated via the Perform Integrated Change Control process to ensure that the impact to the rest of the system is known and understood before or such a change is approved or otherwise. There are few points that can improve the traditional process: Keep Project Tasks Separate from Feature Requests One of the biggest advantages of using project management software is it allows you to organize and manage your project tasks, feature requests, and bug reports.

When a project sponsor or stakeholder requests a new feature, you must treat it separately from your on-going project activities. This enables you to maintain the scope of your project and ensure that it stays within schedule and budget. Although a feature request can seem minor, on- going small changes to your project scope can accumulate to have a significant overall impact on the project. If you let these feature requests snowball, you’ll soon be buried in an avalanche.

With change requests separated from your ongoing tasks, you’ll be able to identify which requests can be implemented as part of the project without delaying final shipping or causing cost overruns. In the end, keeping project tasks and feature requests separate allows you, the

project manager, to better recognize and track changes to the project requirements. You’ll keep your clients happy by completing your projects on time, and you’ll keep your team happy by not working them to death. [9]

Use Online Communication and Collaboration Tools The success of a project relies on effective communication. Online communication and collaboration tools (including Web conferencing, file sharing, and message boards) are a great way of storing and organizing information in a centralized location.

Face-to-face meetings are ideal but not always available, especially when you are involved with stakeholders who are not easily accessible or are geographically located in another part of the country. Those long-distance phone calls can add up quickly. Web conferencing tools are a great way in replacing those calls or meetings, all while providing an effective communication platform. With the support of both audio and visual technologies, Web conferencing enables project managers to frequently work in real time with project stakeholders, providing status updates, and overcoming obstacles before they develop into major issues.

Feature creep is often a result of unclear project planning and a lack of ongoing access to project documentation. Accessible information is key to the success of your project. Imagine that you’re away from the office on vacation and a project stakeholder is trying to obtain a document located in your e-mail inbox. What do they do? They can give you a call, providing you have your smartphone with you, but with online collaboration tools, project team members and SH can have access to up-to-date project information (such as a change log), allowing them to make effective project decisions regardless of their geographical location, and without having to disturb you.

As we’ve seen in this paragraph the whole process try to predict and control rather than adapt to changes that are inevitable in the real world.

Agile Change Control

Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project. Agile understand that because requirements evolve over time, any early investment in detailed documentation will only be wasted. Therefore Agile will elicitate just enough initial requirements to identify the project scope and develop a high-level schedule and estimate; that’s all you really need early in a project, so that’s all you should do. Because requirements change frequently you need a streamlined, flexible approach to requirements change management. Agile want to develop software which is both highquality and high-value, and the easiest way to develop high-value software is to implement the highest priority requirements first. This enables them to maximize stakeholder ROI. In short, agile strive to truly manage change, not to prevent it. The Agile approach is designed to manage the work items (PBI) needed to be accomplished by the team. PBI are potentially committed by the Team. Potentially because the Team may not actually have sufficient time or resources to do them in the Sprint timebox. With this approach your software development team has a stack of prioritized and estimated work items, including requirements, which need to be addressed. PO (through SH) is responsible for prioritizing the requirements whereas developers are responsible for estimating. The priorities of non-requirement work items (eg. bugs fixing) are either negotiated by the team with PO or are addressed as part of slack time within the schedule. The “lifecycle” of a typical development iteration is as follows:

Start At the start of an iteration the team takes the highest priority requirements from the top of the stack which they believe they can implement within that iteration. If you have not been planning ahead you will need to discuss each of the requirements that you pulled off the stack so that the team can plan how it will proceed during the iteration. In short, you should do some planning at the beginning of each iteration using dedicated software tools or whiteboards.

Execution The team then develops working software which meets the intent of the requirements, working closely with SH throughout the iteration to ensure that they build software which meets their actual needs. This will likely include some grooming to explore the requirements in greater detail.

End The team will demo the working software to a wider audience to show that they actually did what they promised to do.

Scrum suggests that you freeze the requirements for the current iteration to provide a level of stability for the developers. This is true if we consider the Sprint execution as a whole. However nothing is stopping from replacing a US not yet started with another one (possibly) having the same effort (SP). This way we can just respond to the requested changes without having to complete the current Sprint and without having to expand its deadline.



If you do this then any change to a requirement you’re currently implementing should be treated as just another new requirement. Other SDLC like XP support changing requirements during the iteration. It’s worth remembering that US need not to be very detailed, and this include of course the acceptance criteria. The reason behind is that details are likely to change during the Sprint execution so we’re spending time to plan something that is bound to change. Is it worth the effort? No.

Many organizations have convinced themselves that they need to define the requirements up front, that they need comprehensive documentation before project teams can begin development. They often do this in the name of minimizing financial risk, they want to know what they’re going to get for their money, but as a result they incur incredible wastage and actually increase financial risk. The Chaos Study [5] reports that 51% of all projects are challenged (they’re severely late and/or over budget). However, the Standish Group has also looked at a subset of traditional teams which eventually delivered into production and asked the question, “Of the functionality which was delivered, how much of it was actually used?” The results

shows that an astounding 45% of the functionality was never used [2]

For complex requirements which are approaching the top of the stack, you may choose to plan them a few days or weeks in advance of implementing them so as to increase the speed of development. Note that any detailed planning in advance of actually needing the information should be viewed as a risk because the priorities could change and you may never need that information. You just need enough detail to estimate the later requirements. It’s reasonable to associate an ROM (rough order-of-magnitude) estimate with requirements further down on the stack, so you’ll need just enough information about the requirement to do exactly that.

Why Requirements Change People change their minds for many reasons, and do so on a regular basis. This happens because: they missed a requirement, a stakeholder was working with an existing system and realized that it’s missing a feature, they identified a defect. A bug should also be considered a requirement. Ultimately PO realize she didn’t understand their actual need. It’s common to show a SH your working system to date only to have them realize that what they asked for really isn’t what they want after all. This is one reason why active SH participation and short iterations are important to your success. The political landscape within your organization is likely dynamic. When the balance of political power shifts amongst your stakeholders, and it always does, so do their priorities. These changing political priorities will often motivate changes to requirements. The marketplace changes. Perhaps a competitor will release a new product which implements features that your product doesn’t. Legislation changes. Perhaps new legislation requires new features, or changes to existing features, in your software. The bottom line is that if you try to “freeze” the requirements early in the lifecycle you pretty much guarantee that you won’t build what people actually need, instead you’ll build what they initially thought they wanted. That’s not a great strategy for success.

Prioritizing Requirements New requirements, including defects identified as part of your user testing activities, are prioritized by your project stakeholders and added to the stack in the appropriate place. Your project stakeholders have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit. However, stakeholders must also be responsible for making decisions and providing information in a timely manner. Fundamentally a single person needs to be the final authority when it comes to requirement prioritization. In Scrum this person is called the PO. Although there are often many project stakeholders - end users, managers, architects, operations staff, and so on - the product owner is responsible for representing them all.

Estimating Requirements Developers are responsible for estimating the effort required to implement the requirements which they will work on. Although you may fear that developers don’t have the requisite estimating skills, and this is often true at first, the fact is that it doesn’t take long for people to get pretty good at estimating when they know that they’re going to have to live up to those estimates.

Smaller requirements are easier to estimate. Shall statements, such as “the system shall convert feet to meters”, are an example of very small requirements. User stories are a little larger but still relatively easy to estimate. Use cases, a staple of the Rational Unified Process (RUP) can become too large to estimate effectively although you can reorganize them into smaller and more manageable artifacts if you’re flexible. A good rule of thumb is that a requirement must be implementable within a single iteration. Scrum teams usually have 1 to 4 weeks long iterations, whereas XP teams often choose 1 or 2 weeks as an iteration length. Short iterations reduce the feedback cycle making it easier to stay on track. Successful teams will deploy a working copy of their system at the end of each iteration into a demo environment where their potential stakeholders have access to it. This provides another opportunity for

feedback, often generating new or improved requirements, and shows stakeholders that the team is making progress and thus their money is being invested wisely.

Why this is Desirable This approach is desirable to IT professionals because it enables us to always be working on the highest-value functionality, as defined by our stakeholders, at all points in time. This is not only a good business decision, it is also very satisfying for developers because they know that their work is actually having a positive impact on the organization.

There are several reasons why this is incredibly attractive for stakeholders: they get concrete feedback on a regular basis. By developing working software on a regular basis stakeholders can actually see what they’re getting for their IT investment. They have control over the scope. The stakeholders can add new requirements, change priorities, or rework existing requirements whenever they want. To do so, they merely modify what is currently in the stack. If the team hasn’t gotten to the requirement yet, then it really doesn’t matter that the requirement has changed. They have control over the schedule. The stakeholders can fund the project for as long as they need to. The development team is always working on the highest priority requirements which are currently identified, and they produce working software each iteration. The implication is that at various points in the project, SHs should be able to say “OK, this is good enough for now, let’s deploy this into production”, giving them control over the schedule. They have control over the budget. At the beginning of each iteration the stakeholders can decide to fund the team for as much, or as little, as they see fit. If the team has been doing a good job then the stakeholders are likely to continue the same level of funding. If they team is doing a great job then they may decide to increase the funding, and similarly if the team is doing a poor job then they should decrease or even cut funding. The implication is that not only do stakeholders have control over the budget, they can also treat their IT investment as a true investment portfolio and put their money into the project teams which

provide the greatest ROI. In short, with this sort of approach stakeholders are now in a position where they can govern their IT portfolio effectively. [3]

Once we have accepted changes to occur, we also need to track them to make sure the Team response was adequate. A common tool used to do this is the Traceability Matrix already discussed in this book.

All agile methodologies include integrated practices and processes that manage evolving requirements to efficiently develop a continuous stream of new software capabilities.

Agile development is all about speed, responsiveness to change and quality. In theory (not always achieved in practice of course) requirements and solutions evolve through collaboration between self- organizing, cross-functional teams. Change management is all about ensuring that standardised methods and procedures are used to manage all the changes that occur to whatever it is you are building (a product or system) from the planning of that change through to its implementation. The objective is to ensure that no unnecessary changes are made, that any negative impacts are minimised, that resources are used efficiently, and to provide traceability. So the question is: can you have the one with the other. One is fast and flexible and the other is perceived as not!

Every software project is a compromise: a balancing act between capability, speed and robustness. In an ideal world software would be delivered quickly, it would be function-rich, it would have been thoroughly tested and checked, and it would be provisioned appropriately. Unfortunately this is not an ideal world and we are forever looking for ways to get the product out to the client as quickly as possible. But you shouldn’t compromise functionality or quality simply for the sake of speed. And that’s the potential danger with agile development. If not done properly by suitably qualified and competent people using

understood and agreed control processes, you can easily compromise ‘quality’ in turn, causing more problems later on down the line, simply for the sake of speed right at this moment. We should always remember that the real goal of Agile is quality not speed. Poor software quality costs $150+ billion per year in the US and over $500 billion worldwide then it is easy to see that this is not a minor issue. [10]

So, how do you manage to have control and still be agile? How can you be responsive while simultaneously ensuring that your solution is going in the right direction and without compromising quality if you do not have effective change management procedures in place? Change Management does not have to be heavy weight and intrusive.

Why requirements management is important It is more expensive to fix delivered defects than those captured earlier in the lifecycle, and poor requirements are behind the majority of delivered defects. Still think that effective requirements management shouldn’t be the top priority in the SDLC and Application Lifecycle Management (ALM) optimization? What does requirements management mean?

It is easy to understand where the problems start. Many organizations still use text-based documents to inform their elicitation and requirements review and do so outside of a change management control or workflow system. An organization cannot realistically optimize their requirements management practices unless they understand the key components of requirements management itself. Effective requirements management is built on three key pillars:

• Elicitation through visualization

• Collaboration and commitment

• Change management and traceability

Elicitation through visualization

Text-based documents present too much detail too soon and don’t include a visual expression of business need, leaving room for ambiguity. Mapping out the process flows – who does what, and when – equates to a more tangible understanding of what’s being asked for. It is this understanding which clarifies the bigger picture and encourages stakeholder buy-in. Putting requirements within the context of these activities results in more complete requirements and identifies gaps and omissions earlier in the process. Visualizations – namely simulations or ’mock-ups’ of user interfaces – created before any actual development takes place, significantly reduces costs and rework time. Collaboration and commitment Strong collaboration encourages commitment from key stakeholders. Review and feedback processes must be simple, quick and thorough. They must avoid the duplication of effort and redundancy associated with document-centric or mass email approaches. Complex business systems can easily result in sprawling requirement reviews and multiple inputs and document versions.

While visual-based requirements can provide focus, ongoing collaboration is vital if the final delivery, often many months later, is to reflect the constantly changing realities of the business need. Keeping all stakeholders informed throughout using a single channel avoids surprises during the approval process and simplifies the coordination of collaboration activities.

A lot of interest is given today to ALM, but what exactly is ALM? It is the product lifecycle management (governance, development, and maintenance) of application software and it encompasses: Requirements management Software architecture Programming, Testing, Maintenance, Change management, Project management,

Release management

Shortly we can say that ALM is the right balance of the following resources:

• People

• Process

• Tools

Many ALM tools are available today like TFS and Jira, but there is no magical tool able to make your company Agile without involving People and the Processes you currently have in place.

Change management and traceability Managing change throughout the life of a requirement, from elicitation to delivery, is crucial. Business objectives change quickly and downstream phases, such as development and testing, must be similarly flexible. Even agile development teams, with their emphasis on closer collaboration and tight integration between business owners and development, can struggle without it. Projects grow and teams become spread out, crossing technical and geographic boundaries: upstream changes become harder to control. But even before a single line of code is written, there is a logical flow within requirements management, from high-level objectives to business requirements, before they are broken out into the functional and non-functional and passed on to design. Changes at every stage impact the others. Bi-directional traceability and real-time impact analysis can keep stakeholders aligned. And changes do not stop as the process moves into development – market forces continue to exert business pressure, while technical opportunities and challenges pull developers in new directions. Capturing requirements quickly and effectively, maintaining visibility throughout as priorities change and paths shift, ultimately delivers applications that reflect true business needs and meets the primary goal

of effective requirements management.

Strategic Choices

Strategy is a high level plan to achieve one or more goals under conditions of uncertainty. [1] I’ve seen few times good people getting fired for the “sake of business”, when actually the strategy in place was quite against the business. This is probably more common in consultancies, where the client is always right. But, is that always true?

My view is that the client is always right if his (or her) expectations are realistic. For instance we’ve a contract with the client, but now he wants more features at no extra cost. Another example the client asks for a consultant but the deadline, which caused the previous consultant to fail, is now even tighter. In this situation the next consultant is likely to fail as the previous one. Is a retreat always a shame or it could be a strategic way to save more lives and to prepare for the next battle?

As a consultancy company what could be the best strategy with a client having high expectations? Please the customer by firing more people for the sake of business, or building a stronger team and escalating the contact to seek a more suitable opportunity? If the consultancy chose to fire more people, than there is a conflict of interest: to protect your business you fire more people, but without people you can’t do business.

Let’s see the following example taken from a real case.

Company A has a pain in testing area where A1 is the test manager. A1 is under pressure and unable to motivate and manage his people because his expectations are too high. This make him fix unrealistic deadlines for his people, and everyone has progressively left him alone.

A1 pain increases, and he calls the consultancy C to help him. C is happy and grateful that A1 offered them this opportunity, and C1 (upper manager) puts C2, his best man, under A1. A1 high expectations make also C2 to fail in a month. His predecessor quitted in 2mo under A1. Therefore A1 ask for the head of C2. Now C1 is embarassed and he needs to take a quick decision:

1. Acknowledge the failure, and replace C2 to please A1. This way he’ll limit the damage and possibly gain new business from A. 2. Escalate to the upper manager of A1 and seek help from him.

Choice #1 C1 can show his boss (C0), that he’s able to control the situation. This is the most convincing tactic to show the upper management that we’ve identified the problem and that we’re going to clean the bug. After all C2 was not a good fit for the job, but now C3 will replace C2 and will do a good job. This is how C1 will seek the buy in from C0. C0 has some trust in C1 and will wait for good things to happen with A. After a month C3 will fail, and A1 will ask his head as he did with C2. The loop starts over again upto C4, then CE (CEO of C) will start questioning C0: “what’s going on with A? Why we’re not able to deliver? Just now I spoke with their MD and she told me they’ve decided to start with our competitor next week.” C0 will then call C1 in a meeting telling about his disappointment about how he managed A. C0 priority is to please CE in order to protect his position and his salary. C1 therefore is getting troubles from the outside and the inside of his own company. After 6mo C1 quit get fired or quit the company, and the loop start over again.

Choice #2 C1 wants to test if some Agile principles will work in this situation. He takes some time with A1 and fix an appointment with A0 (manager of A1). “Dear Peter, we’re a leading consultancy in software development, and it’s extremely important for us to establish a long term partnership with

you. You’re a leader in your sector and we want to be your first choice for consultancy services. Our services meet the highest standards as we hire only the best people. Recently I’ve put my man under A1 but his expectations has caused him to fail. I also spoke with the program manager about A1’s expectations and she told me the project has been delayed since the last 2mo. Could you pls help me to deliver my services through some other contact? “ If A0 gives another contact to C1, then he may have good chances to succeed in his next project. Else C1 will need to find another contact in A who may help him to perform.

The Outcome Choice #1: C1 will postpone the problem with A1, and will need regular replacements to continue to work with A. With time C1 will get regular pressure from C0, and C2-Cn will also get their share, until they’ll all quit. When there will be no one left, C0 will get an increasing pressure from CE, until he’ll look at C1 as the next one to fire. In this situation C1 has sacrificed his people for the sake of a business that could not be sustained for long. C1 protected his own position with the hope to increase the business, but ultimately he failed to get there. Fear moved C1 in this decision and with fear worries always come.

Choice #2: With this option C1 was uncertain to find another contact in A, but he was certain about the type of contact he was looking for. It was no more about A choosing C, but C choosing A instead. If no other contact is available in A, C1 can always use his time to find a better client. Accepting to retire is sometimes better than start a battle that you know is out of your control. In such battle is difficult to win and it’s probably better to consolidate your resources for other battles.

This way C1 showed the followings:

• Courage: by changing his strategy

• Transparency: by sharing his pain with A0

• Leadership: by protecting and motivating his team.

Real Projects

Now that we’ve seen few basic concepts about Scrum it’s time to dive a little more in the Agile world and understand how we should plan for our new project and why. The following is a broad range of thoughts about what we should plan and what we should avoid to do; the main message is: stay Lean.

The traditional way to manage a project start with planning and generating documents to assess the overall project. Is that wrong? No, not necessarily. Is that mandatory or necessary? No either. Agile value documentation sure, but they value more a working software. The focus is on priorities.

When we start thinking to our project we probably have thousands features in mind because we want it to be unique, amazing, user friendly, reliable and with an online community well established, a marketplace where we can sell plugins, modules for all the major products out there, themes, social networks interfaces and so on… This is all nice but we need to be realistic since our resources are limited and we don’t want the launch to happen in few decades. Therefore the main point here is: plan for something that you can really make and cut out all the rest, be pragmatic. Less means less people, options, features, meetings, paperwork and promises.

Next we need to have a problem if we want to provide a solution for it. When you solve your own problem, you create a tool that you’re passionate about. And passion is key. Passion means you’ll truly use it and care about it. And that’s the best way to get others to feel passionate about it too. [4]

Funding may need to startup but we should really think twice before getting a loan or investors in our project. If you turn to outsiders for funding, you’ll have to answer to them too. Expectations are raised. Investors want their money back – and quickly. The sad fact is cashing in often begins to trump building a quality product. [4] Constrains are not necessarily bad, they promote innovation, creativity and a quicker time to market which is good.

Another point to note is the scope in relation to time, cost & quality. Do we want to deploy something or do we want to deploy something good? There is a huge difference in this, quality. An easy way to launch on time and on budget is to keep them fixed. Never throw more time or money at a problem, just scale back the scope. You’ll deliver less features but with an acceptable quality. There is always time to add features later on. [4]

Priorities, as we’ve seen before, are important to decide what to do first. There is always a way to prioritize the work and we just need to accept that some of the ‘supercharging’ features we’ve thought about can just wait a little more before getting implemented. We know this is not the end of the world.

Staying lean is all about doing or having less in order to achieve the same or more. Basically we want to deploy with what we have now. To achieve this we want less of the following: Long term contracts, Excess staff, Permanent decisions, Meetings about other meetings, hardware or software traps, Proprietary data formats, Long-term roadmaps [4] In short: simplicity is the key and if we’re lean the chances to successfully respond to Change are much more and easier to implement. We can’t buy the agility we get from being small and lean.

We usually think of debt in terms of money but it comes in other forms too. You can easily build up code and design debt. Hack together some bad code that’s functional but still a bit hairy and you’re building up debt. Throw together a design that’s good enough but not really good

and you’ve done it again. [4]

Tom Poppendieck defines technical debt as everything that makes your code harder to change. It’s what potentially will create issues during the development of your software. What you’ve done or you omitted to do.



Technical debt can be Deliberate or Inadvertent. Prudent and deliberate This is reserved for business drivers who have a compelling ROI for a product that has to ship immediately — i.e., responding to a threat to the business bottom line or exploiting an opportunity that positively affects the bottom line. Examples where this could be justified could be: Entry into a new market — First to market may mean that less quality or features with more workarounds might be acceptable. Regulatory or legal requirement — Compliance projects can entail that not meeting dates could have severe financial and operational impact to business.

Peak-period opportunity — Within retail, the Christmas period is increasingly becoming the most critical part of the annual cycle, and failure to launch prior to Christmas could have a significant negative impact on the company’s performance.

Reckless and deliberate This reflects poor management, where usually corners are being cut in order to hit a deadline that is related to perceived operational needs rather than to an underlying clear business case. This is a very common cause of technical debt. Examples include: Rushing the project to completion because there are lots more projects to deliver in the pipeline. Pushing the project through because the client wants it on a set date, and no one has built a relationship with the client to discuss the details, nor has the client been informed of the effect on quality if the delivery is rushed. Cutting corners because teams have been incentivized to deliver projects into production by a specified date.

Reckless and inadvertent This happens typically to programmers who are incompetent and unaware of the implications of adding/removing a piece of code — thus incurring a huge technical debt. Technical debt in this case needs to be carefully managed by using processes and tools — through pair programming, code reviews, continuous integration, automated testing, etc.

Prudent and inadvertent This is a natural occurrence. Teams would like to improve upon whatever has been done after gaining experience and relevant knowledge. Technical debt can also be short-term and long-term debt. A short-term debt is reactive and a tactical measure (pushing a release with known Severity 3 bugs), whereas a long-term one is a proactive and strategic one (not providing support for a platform that may not exist after two to three years). The implication is that short-term debt should be paid off quickly, preferably as part of the next release cycle, whereas long-term debt can be carried on for a few years or longer.

Attitudes toward technical debt Different companies have different philosophies about the usefulness of technical debt, just as they do with financial debt. Some companies want to avoid taking on any debt at all, while others see debt as a useful tool and just want to know how to use it wisely. Few companies track debt versus team velocity. Once a team’s velocity begins to drop as a result of servicing its technical debt, the team focuses on reducing its debt until its velocity recovers. Other approaches include tracking rework, and teams use that as a measure of how much debt they are accumulating.

Servicing the technical debt The first step in servicing the debt is to identify any such issues and register them — making the debt visible to the team. These could be made part of the product backlog or even be part of a separate technical debt backlog for purposes of tracking. The team can then evaluate and prioritize, taking into account the effort required and the “pain” caused by the technical debt and its frequency. The PO would need to make a conscious decision whether the “economics” justifies the cost of the technical debt. It has to be kept in mind that not all technical debt need be repaid; eg. one can live with issues relating to a product nearing its end of its life. However, it is important during this time that technical debt is not accumulated, since that would only cripple the system Similar to the payment of financial debt, it is prudent to repay the “high interest” technical debt first. It is preferable that technical debt be repaid incrementally (like making a monthly mortgage payment) through use of practices such as peer reviews, TDD, refactoring, continuous integration, automated testing or code review.

Sometime we’re pushed above the limits in the attempt to close our technical debt. As a developer you may already know this story. You started doing an exciting new project, ambitious and satisfying at the same time. You wanted the new feature to be completed in time since you’ve so many other things in the pipeline to be added to it. It’s quite a simple thing to do after all. Perhaps you were a little optimistic

when you estimated the deadline but you wanted to make it done. Yes you admit to yourself it was more a wish rather than an estimate. But you keep it under control now, it’s there safe in your mind, you just need some more time to make it. Now it’s late again, you didn’t walked with Susan and your kids to that shop, you missed your favorite show again but it’s only for this night you said to yourself. Tomorrow the work will be done and you’ll finally be released from all this nonsense.

You know this is false, you’re lying to yourself, in the hope that something will save you. Don’t be a hero, live in the present. One thing in 4hrs work, another is 5 days and counting. How many other things you could have done in this time? Do less, be kind with yourself, put a roof to your desires and do not allow them to overgrow above that. Be realistic and learn to say no. That’s probably the best thing to do when we’re trying push ourselves above the limit.

I don’t want to achieve immortality through my work… I want to achieve it through not dying. —Woody Allen

Credits

[1] http://en.wikipedia.org/ [2] http://agilemodeling.com/essays/examiningBRUF.htm [3] http://www.agilemodeling.com/essays/changeManagement.htm [4] Getting Real, 37Signals [5] www.standishgroup.com/ [6] http://en.wikipedia.org/wiki/Change_control [7] www.pmi.org PMBOK [8] http://www.pm-primer.com/perform-integrated-change-control/ [9]http://esj.com/Articles/2010/10/05/Managing-Requirement- Changes.aspx?Page=2 [10] Capers Jones, Software quality 2011 - A Survey of the state of the art

5. Design & Testing Intro Design Testing The Lab Environment Complexity Code Review Unit Test Code Analysis Legacy Code

Intro

Design and Testing are two of the most crucial activities in any Agile team and the reason is because Design is usually needed by Developers (Devs) before they start coding and Testing is usually done after Devs have completed their code. There are multiple ways to Design & Test our software and we’ll see in this chapter what options are available to streamline this process and achieve full agility.

The biggest waste in software is created from waiting for software as it moves from one state to another: Waiting to code, waiting to test, waiting to deploy. Reducing or eliminating these waits leads to faster iterations which is the key to success. [Eric Ries]

Continuous delivery of value is the main goal of Agile testing and we’ve already seen the concept of Quality Assurance (QA). It’s against Scrum methodology to have a testing Team (QA) separated from the development team. QA can be used to test the Sprint as a customer (SH) would do, but it’s essential that Devs start testing their code if we want to deliver a Sprint with less bugs. Those bugs are called ‘Technical Debt’ and we’re accumulating this deb with every Sprint,

unless we’re able to improve our Scrum. For each US we can add a testing Task to be completed by Devs as any other PBI. As a general rule we should stress the point that everyone is expected to fix problems in the code regardless of who wrote it.

Rather than relying on testers to find bugs for programmers to fix, the team should produce nearly bug-free code on their own. Code Review or Unit Test can be implemented to help in this process. On traditionally managed projects, UXD (User Experience Design) is generally viewed as an up-front Activity. On a Scrum project, however, we ideally want UX designers working alongside other team members (UX, Devs & QA are all part of the Team).

One possible solution is to keep the Sprint short, say 1 week and start the whole process as below. The US review includes loading the revised US in the collaboration tool to make them available to all Team members. UXD in this case works one week ahead and QA one week behind Devs.

• Elicitation

• Analysis

• Design

• US review

• Send invitations

• Review, Retro, Planning

Send invitation occur only when the minimum requirements have been loaded in the system. US need not to be completed with lot of details as these details are part of the Conversation phase discussed previously and performed by the whole team. Invitations are important to allow team members to have a quick view on the next meetings and to elaborate further about the requirements. Review, Retro, Planning

are held during the same meeting just in that sequence. For a Sprint duration of 1 week we can have 2hrs meeting on Fri and leave Devs doing their work for the rest of the week without interruptions.



UED and development can occur in parallel tracks. (Adapted courtesy of Lynn Miller.)

Design

UXD is the functional perspective of the user interface. Eg. For an eCommerce website UXD includes how easy is to add an item to the cart or how easy is to checkout without registering. The User Interface (UI) is the visual perspective of controls, widgets and elements on the main application. Eg. In the above example how they appear in the web page. Many factors can influence a user’s experience with a system. To address the variety, factors influencing user experience have been classified into three main categories: user’s state and previous experience, system properties, and the usage context (situation). Studying typical users, contexts, interactions and resulting emotions help in designing the system and improving the UXD.

Common agile advice is that user interface design should be done entirely within the iteration in which the underlying feature is developed. However, this sometimes runs counter to arguments that the overall usability of a system is improved when designers are allowed to think about the overall user interface upfront. First, will the development of the user interface generate significant, useful new knowledge? Yes, in many cases developing some of the main user interface components or the navigational model will generate significant, useful new knowledge about the product. The early development of parts of the user interface allow for the system to be shown to real or likely users in an early form.

Feedback from these users will result in new knowledge about the product and this knowledge can be used to make sure the team is developing the most valuable product possible. Second, will developing the user interface reduce risk? It probably doesn’t eliminate technical risk. However, early development of features that show off the user interface often reduces the most serious risk facing most projects: the risk of developing the wrong product. A high prioritization of features that will show off significant userfacing functionality will allow for more early feedback from users. This is the best way of avoiding the risk of building the wrong product.

Finally, if the cost of developing the user interface will be significantly lower, that would be another point in favor of scheduling such features early. So, because of the additional learning and risk reduction, it seems reasonable to move earlier in the schedule those themes that will allow users to provide the most feedback on the usability and functionality of the system.

This does not mean that we would work on the user interface in isolation or separate from the functionality that exists beneath the user interface. Rather, this means that it might be appropriate to move forward in the scheduling those features with significant user interface components that would allow us to get the most useful feedback from customers and users. [1]

Testing

Testing is quite important in any project and particularly in Agile and some implementations of Agile advocate for specific test methodologies to be adopted during the iteration. Bugs that are not found during QA or development are called Escaped Defects and are normally found by customers. Agile testing is a software testing practice that follows the principles of agile software development and involves all members of a cross- functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example also called Acceptance Test Driven Development (ATDD) is used to capture examples of desired and undesired behavior and guide coding. [2]

Everyone on an agile team is a tester. Anyone can pick up testing tasks although testers may need specific skills to succeed. Good testers have an instinct and understanding for where and how software might fail, and how to track down failures. Testers might have special expertise and experience in testing, but a good agile tester isn’t afraid to jump into

a design discussion with suggestions that will help testability or create a more elegant solution. An agile testing mindset is one that is results- oriented, craftsman-like, collaborative, eager to learn, and passionate about delivering business value in a timely manner. [16] Devs are now working on the US and writing code. What will do testers before any stories are ready to test? UI testers need to test the US but this is possible when the US is reflected in some testable feature on the front-end. If not they’ll need to wait till this will happen. In any case Devs should write their own code and test it.

UAT User Acceptance Testing (UAT) is one way to reduce or eliminate change requests, and drastically reduce project costs. UAT can be done during the Sprint execution and the Review Meeting and it is conducted to determine if the business requirements are met. UAT consists of verifying that a solution works for the user. It is not system testing (ensuring software does not crash and meets documented requirements).

The customer specifies scenarios to test when a user story has been correctly implemented. A US can have one or many acceptance tests, whatever it takes to ensure the functionality works. Acceptance tests are black-box system tests. Each acceptance test represents some expected result from the system. Customers (SH) are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release. A US is not considered complete until it has passed its acceptance tests.

OAT Operational acceptance testing (OAT) is used to conduct operational readiness (prerelease) of a product, service or system as part of a quality management system. OAT is a common type of non-functional software testing, used mainly in software support and software maintenance projects. This type of testing focuses on the operational readiness

of the system to be supported, or which is to become the production environment. Hence, it is also known as operational readiness testing (ORT). [4] Usually OAT occurs after user acceptance testing (UAT) since it is a final verification before a system is released. The following is a list of the main tests performed in OAT:

• Maintainability

• IT Service Management (Supportability)

• Installation

• Component Testing

• Performance, Stress and Volume,

• Security and Penetration

• Backup and Restore

• Failover (Within the same data centre)

• Component fail-over

• Network fail-over

• Recovery (across data centres)

• Data recovery

• Application/system recovery

• Monitoring and Alerts (to ensure proper alerts are configured in the system if something goes wrong)

Regression Test This is a type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes such as enhancements, patches or configuration changes, have been made to them. The intent of regression testing is to ensure that a change such as those mentioned above has not introduced new faults. One of the main

reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software. [5] Regression testing is achieved after the bug fixed, means testing the operation whether the fixed defect is affecting remaining functionality of the application or not. Usually in regression testing bug fixed module is tested. During regression testing tester always check the entire system whether the fixed bug make any adverse effect in the existing system or not.

SIT System integration testing (SIT) is a testing process that exercises a software system’s coexistence with others. With multiple integrated systems, assuming that each have already passed system testing, SIT proceeds to test their required interactions. Following this, the deliverables are passed on to acceptance testing. SIT is extremely useful in SoS (Scrum of Scrums) since we need to integrate the deliverables (a potentially shippable piece of software) generated by distributed Teams into one consistent product. We can use SIT to make sure the final product integrate well with each deliverable. [6]

CI Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed as part of extreme programming (XP). [10]

This practice advocates the use of a revision control system for the project’s source code. All artifacts required to build the project should be placed in the repository. In this practice and in the revision control community, the convention is that the system should be buildable from a fresh checkout and not require additional dependencies. Extreme Programming advocate Martin Fowler, also mentions that where branching is supported by tools, its use should be minimized. Instead, it is preferred for changes to be integrated rather than for multiple

versions of the software to be maintained simultaneously. The mainline (or trunk) should be the place for the working version of the software. A single command should have the capability of building the entire system and once the code is built, all tests should run to confirm that it behaves as the developers expect it to behave. By committing regularly, every committer can reduce the number of conflicting changes moreover the system should build commits to the current working version in order to verify that they integrate correctly. A common practice is to use Automated Continuous Integration (although it can also be done manually). We’ll see later which tools can do this.





TDD Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the

developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or ‘rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. [8]

It’s worth to stress the point that TDD is a software development process NOT a testing activity (as the name may initially suggest). It’s a development process used to design and write better code, and is a way of managing fear during programming. Fear in the legitimate way (as Kent said): this is a hard problem and I can’t see the end from the beginning sense. If pain is nature’s way of saying “Stop!”, fear is nature’s way of saying “Be careful.” The problem is that fear has a host of other effects:

• Makes you tentative

• Makes you grumpy

• Makes you want to communicate less

• Makes you shy from feedback

None of these effects are helpful when programming, especially when programming something hard. So, how can you face a difficult situation and:

• Instead of being tentative, begin learning concretely as quickly as possible. • Instead of clamming up, communicate more clearly.

• Instead of avoiding feedback, search out helpful, concrete feedback.[12]



The main focus in TDD can also be described as: Red (make the test fail), Green (make the test pass), Refactor (optimize it), however despite its name, TDD is a programming practice, not a testing technique.



Add a test In TDD, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed “new” feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature’s specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.

Run all tests and see if the new one fails This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new

test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.

Write some code The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it. At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and ‘allowed for’ at any stage.

Run tests If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.

Refactor the code Now the code should be cleaned up as necessary (optimized). Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck’s four rules of simple design to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.

The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass

Repeat Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging. Continuous integration helps by providing revertible checkpoints. When using external libraries it is important not to make increments that are so small as to be effectively merely testing the library itself, unless there is some reason to believe that the library is buggy or is not sufficiently feature- complete to serve all the needs of the main program being written. [9]

There are various aspects to using test-driven development, for example the principles of “keep it simple stupid” (KISS) and “You aren’t gonna need it” (YAGNI). By focusing on writing only the code necessary to pass tests, designs can often be cleaner and clearer than is achieved by other methods.[1] In Test-Driven Development by Example, Kent Beck also suggests the principle “Fake it till you make it”.

Test-driven development offers the ability to take small steps when required. It allows a programmer to focus on the task at hand as the first goal is to make the test pass. Exceptional cases and error handling are not considered initially, and tests to create these extraneous circumstances are implemented separately. Test-driven development ensures in this way that all written code is covered by at least one test. This gives the programming team, and subsequent users, a greater level of confidence in the code.

While it is true that more code is required with TDD than without TDD because of the unit test code, the total code implementation time could be shorter based on a model by Müller and Padberg. Large numbers of tests help to limit the number of defects in the code. The early and frequent nature of the testing helps to catch defects early in the development cycle, preventing them from becoming endemic and expensive problems. Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project.

TDD can lead to more modularized, flexible, and extensible code. This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This leads to smaller, more focused classes, looser coupling, and cleaner interfaces. The use of the mock object design pattern also contributes to the overall modularization of the code because this pattern requires that the code be written so that modules can be switched easily between mock versions for unit testing and “real” versions for deployment.

Because no more code is written than necessary to pass a failing test case, automated tests tend to cover every code path. For example, for a TDD developer to add an else branch to an existing if statement, the developer would first have to write a failing test case that motivates the branch. As a result, the automated tests resulting from TDD tend to be very thorough: they detect any unexpected changes in the code’s behaviour. This detects problems that can arise where a change later in the development cycle unexpectedly alters other functionality. [9]

Just one example to clarify how this works. Imagine that you need to program a Java class to parse an HTTP query string. [13]

Often, the best way to make the increments smaller is to start with seemingly trivial cases. “I need my class to put one name/value pair into a HashMap”

public void testOneNameValuePair() { QueryString qs = new QueryString(“name=value”); assertEquals(1, qs.count()); }

Red: The code didn’t compile, so I wrote a do-nothing QueryString class and count() method.

public class QueryString { public QueryString(String queryString) {} public int count() { return 0; } }

Green: That gave me the red bar I expected. To make this test pass, I hardcoded the right answer.

public int count() { return 1; }

Refactor. I didn’t like the QueryString name so I renamed it.

BDD Behavior Driven Development (BDD) is a software development process based on testdriven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and objectoriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development, with the aim of delivering “software that matters” [11] BDD starts with a Conversation involving the stakeholders of the software being developed and those involved in its development. Typically this will involve: business sponsors, users, business analysts, developers, QA and project managers. The goal is to develop a shared understanding of the features to be implemented, the business value those features provide along with a set of acceptance criteria for each feature so that we know when we are “done”. BDD has the same benefits of TDD, but probably the most important is: Thinking through solutions, before starting to code. Usually Devs like to jump into coding to figure out the problem although many times they don’t understand the path well enough. A past supervisor told me several times during reviews that I need to get better at seeing “the forest for the trees”. When I sit down and write out

the behavior that I need to implement, I force myself to think things out further and catch scenarios before they get to QA. [15] Let’s consider a US in the standard format as below: As a [Role] I want [Feature] So that I receive [Value]

Once a story has been identified we then focus on the scenarios that describe how the user expects the system to behave using BDD in a sequence of steps. Acceptance criteria should be written in terms of scenarios and implemented as classes: Given [initial context], when [event occurs], then [ensure some outcomes].

Given [Context] When [Event Occurs] Then [Outcome]

The following is a simple BDD example US: Play Tabs [14] As a music fan I would like to convert guitar tabs to music So that I can hear what they sound like

Scenario: My song

E|––––––––––– B|––––––––––– D|–––-0—0––––––A|-0—2—3–––-2—0–—0—0—

G|–––––––––––

E|––––––––3––— When the guitar plays Then the following notes will be played A0 A2 A3 D0 D0 A2 A0 E3 A0 A0

Translated in code it could be written as follows:

package com.tabplayer.steps;

import org.jbehave.scenario.annotations.Given; import org.jbehave.scenario.annotations.Then; import org.jbehave.scenario.annotations.When; import org.jbehave.scenario.steps.Steps;

public class PlayTabSteps extends Steps {

@Given(“tab $asciiTab”) public void tab(String asciiTab) { }

@When(“the guitar plays”) public void guitarPlays() { }

@Then(“the following notes will be played $notes”) public void theFollowingNotesWillBePlayed(Stri ng notes) { } }

ATDD Acceptance Test-Driven Development (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers. It encompasses many of the same

practices as BDD and TDD. [7] ATDD helps to ensure that all project members understand precisely what needs to be done and implemented. This workflow usually involves establishing the criteria first, most often from a user perspective, and creating concrete examples. Thereafter, acceptance tests are developed and run to see the results of failure with the right code based on these examples. Minimal code is then developed to run the program, more acceptance tests are run again, and the results are validated. Refactoring is then carried out based on the results of the acceptance tests before the final program is developed for use. ATDD is a practice that emphasizes the importance of open communication and feedback within the team. It focuses on progressively driving value out of the system, demonstrating how that value is delivered via automated acceptance criteria. ATDD is not just a tool, it’s a development philosophy and encourages the whole Team to think in terms of business goals. Each feature must deliver real and measurable business value. This is important because if your feature doesn’t trace back to at least one business goal, then you should be wondering why you are implementing it in the first place.

Below you’ll find an example of how to implement ATDD for an eCommerce website:

• Goal: sell more products from our website. Feature: use online tools to increment sales. • This could be translated into some functional requirements using the US format: ‘As a seller I want to sell online products so that I can increase my revenue.’ In the Acceptance Criteria we may also add: use Google AdWords to improve our ranking. • Translating the above US into BDD format: Given a buyer who need our product, When she Google for it, she will see the link to our website and Then she’ll select and add the product to the shopping cart.

As you can see this works fine for PO and Devs and helps everyone

to understand the requirements. Testers benefit from a higher-quality and better tested product from the word go, and can spend less time on manual testing, focusing on higher value work such as exploratory testing.



The Lab Environment

A lab environment (LEN) is a collection of virtual and physical machines, which you can use to develop and test applications. You can create and manage lab environments with the Lab Management features of Microsoft Test Manager (MTM). We’ll see in a dedicated chapter how to configure LEN and below are listed the main benefits of using it:

1. Use a test plan to run automated tests − you can run a collection of automated tests, called a test plan, and view the progress using Microsoft Test Manager.

2. Use a build-deploy-test workflow − you can use a build-deploy- test workflow to test multi-tiered applications automatically. A typical example is a workflow that starts a build, deploys the build files onto the appropriate machines in a lab environment, and then performs automated tests. In addition, you can schedule your workflow to run at specific intervals. 3. Collect diagnostic data from all machines, even during manual testing − you can collect diagnostic data from multiple machines simultaneously. For example, during a single test run, you can collect IntelliTrace, test impact, and other forms of data from a web server, a database server, and a client. 4. Automatic test agent installation − Lab Management automatically installs test agents on every machine in your environment.



This LEN has a client/server topology, which is often used to test an application that has server and client components. In a client/server topology, all of the client and server machines used to test your application are in your lab environment. When you use this topology, you can collect test data from every machine that impacts your tests.



This LEN has a server topology, which is often used to run manual tests on server applications, and which allows testers to use their own client machines to verify bugs in the environment. In a backend topology, your lab environment contains only servers. When you use this type of topology, you typically connect to the servers in the lab environment using a client machine that is not part the environment.

System Center Virtual Machine Manager (SCVMM) is a collection of virtual machines on which you can run tests. You create and manage them with Microsoft Test Manager. A virtual machine (VM) is a software-based emulation of a computer. Typically, you use LEN when you’re testing an application that runs on servers, such as a web application. You run the server components on lab machines, and run your web browser or client app on your own local machine.

If you use Lab Management with SCVMM, you can also get these benefits while using LEN:

• Quickly reproduce machine configurations − You can store collections of virtual machines that are configured to recreate typical production environments. You can then perform each test run on a new copy of a stored environment. • Reproduce the exact conditions of a bug – When a test run fails, you can store a copy of the state of your lab environment, and access it from your build results or a work item. • Run multiple copies of a lab environment at the same time – You can run multiple copies of your lab environment at the same time without naming conflicts.

Complexity

Complexity is crucial to reduce bugs and improve the testing process and it is a term that encompasses numerous properties of a piece of

software, all of which affect internal interactions. According to several commentators, there is a distinction between the terms complex and complicated. Complicated implies being difficult to understand but with time and effort, ultimately knowable. Complex, on the other hand, describes the interactions between a number of entities. As the number of entities increases, the number of interactions between them would increase exponentially, and it would get to a point where it would be impossible to know and understand all of them. Similarly, higher levels of complexity in software increase the risk of unintentionally interfering with interactions and so increases the chance of introducing defects when making changes. [17]

Several metrics have been developed to measure code complexity. Here we’ll discuss one of the most popular developed by Thomas J. McCabe called Cyclomatic complexity. It directly measures the number of linearly independent paths through a program’s source code.

In the example below, the program begins executing at the red node, then enters a loop (group of three nodes immediately below the red node). On exiting the loop, there is a conditional statement (group below the loop), and finally the program exits at the blue node. This graph has 9 edges, 8 nodes, and 1 connected component, so the cyclomatic complexity of the program is 9 - 8 + (2*1) = 3. [18]



In the chapter dedicated to software tools, we’ll see which are available to the programmers.



Code Review

Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.[21]

Capers Jones’ ongoing analysis of over 12,000 software development projects showed that the latent defect discovery rate of formal inspection is in the 60-65% range. For informal inspection, the figure is less than 50%. The latent defect discovery rate for most forms of testing is about 30%. Typical code review rates are about 150 lines of code per hour. Inspecting and reviewing more than a few hundred lines of code per hour for critical software (such as safety critical embedded software) may be too fast to find errors. Industry data indicates that code reviews can accomplish at most an 85% defect removal rate with an average rate of about 65% [21]

Another interesting study has been conducted by Steve McConnell’s and published in his book Code Complete shows the typical percentage of bugs found using each bug detection technique. The most interesting facts are that the modal rates don’t rise above 75% for any one technique, and that the techniques average about 40 percent. The best bug detection rate, if you are only using one of the above four categories, is 68%. The average detection rate if you are using all four is 99%. Giving programmers a program with 15 known bugs, telling them to use a variety of techniques to find bugs, and observing how many they find: no one found more than 9, and the average was 5. If you want to ship high quality code, you should invest in more than one of formal code review, design inspection, testing, and quality assurance. Testing catches fewer bugs per hour than human inspection of code, but it might be catching different types of bugs. You should definitely try to measure where you are finding bugs in your code and the percentage of bugs you are catching before release – 85% is poor, and 99% is exceptional. [22]

We should also consider the cost of fixing bugs not just the absolute numbers. For instance bug fixing may cost 25$/each during Code Review, 200$/ each during QA and 1000$/each when found by customers (escaped defects). This gives a better picture of how important is to fix bugs and when. To keep it simple we could say that:

• Code 1-1: One bug in code is just one bug - though fixing it might produce more. • Design 1-10: One bug in Design may result in 10+ bugs in the coding phase • Reqs 1-100: One bug in Requirements may result in 100+ bugs in the coding phase

The main functional aspects that are important to look at are:

• error handling

• input validation

• output validation.

Coincidentally, this is the type of thing that a good unit test focuses on as well. The main not functional aspects to look at are around simplicity, style and understanding of the problem area.

In general, the 2 methods used for peer review are: formal (heavy) and informal (light).

Formal code review meetings and printed copies of code, takes much of company’s resources and keep developers from actually developing the product. It gets the job done, but also slows down the development process.

Should you do formal peer code reviews? Absolutely. Just as a quick side note, I have very little experience with paired programming, but I don’t believe that reviews would conflict with these methods.

I’d introduce two forms of code reviews:

• Peer code reviews

• Group code reviews

Peer code reviews Even if paired programming works for you, it never hurts to get another set of eyes on the code. The benefits to this are:

It gets a set of fresh eyes on the code, someone who may have more intimate knowledge of areas of the code base that you (and/or your

partner) may not be as familiar with. This can expose knock-on issues. It makes you (the pair) re-validate your solution prior to submission. As the reviewer knows nothing about what you’ve written, you have to explain it in its entirety. This can expose edge cases that you hadn’t thought of, or invalid logic.

Peer code reviews (in my world) are conducted prior to every submission. How this carries over in the paired programming world, I’m unsure of.

Group code reviews These happen less frequently than peer code reviews. I would generally pull my group (or a subsection of my group) in a meeting room for an informal code review. I’d generally pick some code that was written by a random person on the team, preferably code that was written from scratch - refactored code doesn’t expose issues like fresh code.

Make sure everyone knows that these reviews are not meant to embarrass and are not used to reflect performance. They are merely to ensure that your team coding standards are followed and to help everyone be better engineers and thus, become more useful to the team (and further career growth, etc etc) - and make sure that this is the true intent of the reviews. If anyone suspects anything different, these will become feared and less productive.

I would go through the code somewhat informally, letting anyone in the room point out different solutions that they may have or logic flaws that they encounter. This is meant to be more of a group discussion than a leader sitting there telling everyone how they should code.

Here are the main benefits and guidelines for Code Review:

• Committing early and often. It’s far easier to run multiple small reviews than a single huge one • Encouraging developers to produce well-documented code

before review is issued

• Committing code to a ‘test’ branch first and pushing it to the main one after it successfully passes the review • Tracking defects in order to make sure they are actually fixed after the review • Reviewing the code, not the authors

Nothing is commercially published without corrections from several professional editors. Find the acknowledgments in any book and you’ll find reviewers who helped “remove defects.” No matter how smart or diligent the author, the review process is necessary to produce a high- quality work. (And even then, what author hasn’t found five more errors after seeing the first edition?) Why do we think it’s any different in software development? Why should we expect our developers to write pages of detailed code (and prose) without mistakes? Only code review will ensure that new hires don’t make mistakes that veterans would avoid. [20]

Any software company with a mature product that needs to be updated is potentially in this position: adding new features without breaking the product. I personally experienced huge software bugs with a UK company having no regression testing and a ridiculous idea about software quality. A new bug emerged regularly with every new patch released and the impact on the customers was terrible. Fixing bugs cost money but the cost is raising when they pass from Devs to QA to Customers.

Competitive Advantage A successfully-implemented code review process is a competitive advantage. No one wants to give away the secret of how to release fewer defects efficiently especially when this involves discussing with others internal details related to company IP (Intellectual Property) or

know-how.

Before & After Code Review can be done before or after the code goes to the main repository of the version control system, (SVN) and usually committed changes do include Unit test as well.

Before Pros

• Company’s coding quality standards are met before the work is committed to the main repository. • This scenario helps to make sure the review has been performed, not postponed or omitted • Pre-commit reviews ensure other developers in your team won’t be affected by bugs that may be found during a review

Before Cons

• Decreases productivity of each developer, since further work on the submitted code is impossible until a successful review, and takes even longer if multiple reviewers are involved

After Pros

• A developer can work and commit changes to the repository continuously • Other team members see the code changes and can alter their work accordingly • Some changes can be complex and require multiple steps and it’s convenient to examine each step separately after all of them have been committed

After Cons

• Increased chances of poor code quality into the main repository, hence affecting the entire team’s work • When defects are found, it may take a while for the developer

to switch back to the module they had been working on

When Devs write code their productivity is not simply how much code they write but how much correct code they write. This means taking into account rework due to errors and omissions. If we have to reduce the time we spend in the testing phase, we would do better to give up some unit testing in favour of keeping more formal code reviews. Some development groups still don’t use code review as a regular part of their process are. Why? There are probably 2 main reasons:

1. Personality (ego) 2. The hassle of packaging source code for review and scheduling review meetings.

Let’s talk about egos first. When someone else is looking over their work, any programmer will naturally evaluate what the person thinks of it. This can either be interpreted as a constructive process or a critical one, and this interpretation can create 2 different classes of programmers. The first class are collaborators – programmers who, when they are confronted with a problem, will do what it takes to figure it out (or at least come up with a workaround), which often includes asking a peer who knows the answer already or is willing to bounce around ideas. They see and use peer review as a beneficial process. The second class are isolationists – those programmers who, when confronted with a problem they are unable to solve, will continue to thrash unproductively on it rather than reveal to their peers that they need help. On a side note, this dichotomy of approaches certainly isn’t unique to programmers, and exists on a larger scale in personalities in general. Why do these classes tend to be so distinct among programmers? The main reason is the latter class of programmer tends to have a short career in software development. Their body of knowledge becomes constrained to what they can figure out on their own, which even for the brightest individuals (in a field of bright individuals) is limited. [20]

Unit Test

Unit Testing (or API Testing) is a software testing method by which individual units of source code (…) are tested to determine if they are fit for use. In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. In OOP, a unit is often an entire interface, such as a class, but could be an individual method. [23]

A Test Case (or test script) is a group of conditions under which a tester will determine whether the application is working as expected and ideally, each test case is independent from the others. Test cases can be divided into several Steps, multiple Test Cases can be grouped into Test Suites and Test Suites are listed in the Test Plan. We’ll see in a dedicated chapter few tools used to manage Test Plans.

By definition, Unit testing cannot see the big picture of your program since it’s done at the ‘unit’ level and therefore it will not catch integration errors (eg. A method called twice by mistake).

There are several frameworks that help creating unit tests, in this book we’ll use NUnit but the concept is quite common to all. [23]

NUnit is an open source Automated Unit Testing framework for Microsoft .NET and can help improving code quality, regression testing and reducing costs. Test Cases built with Microsoft Test Manager can run NUnit tests as well. Here is a quick sample of NUnit, note that the test class has the [TestFixture] attribute, whereas the test method(s) have the [Test] attribute: using NUnit.Framework; [TestFixture] public class ExampleTestOfNUnit

{ [Test] public void TestMultiplication() { Assert.AreEqual(8, 2*2, “Multiplication”);

// Equivalently, since version 2.4 NUnit offers a new and // more intuitive assertion syntax based on constraint objects // [http://www.nunit.org/index. php?p=constraintModel&r=2.4.7]: Assert.That(2*2, Is.EqualTo(4), “Multiplication constraint-based”); } }



Code Analysis

Code analysis is the analysis of computer software, usually the source code, and can be static or dynamic. Static analysis is performed without actually executing the code whereas Dynamic analysis is performed by executing the code. The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. [25]

Ideally, such tools (see later in this book) would automatically find security flaws with such a high degree of confidence that what’s found is indeed a flaw.

Strengths Scales well, can be run on lots of software, and repeatedly Useful for things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, and so forth Output is good for developers, highlights the precise source files and line numbers that are affected

Weaknesses Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however. High numbers of false positives. Frequently can’t find configuration issues, since they are not represented in the code. Difficult to ‘prove’ that an identified security issue is an actual vulnerability. Many of these tools have difficulty analysing code that can’t be compiled. Analysts frequently can’t compile code because they don’t have the right libraries, all the compilation instructions, all the code, etc.

There are other tools which can be used to help Code Analysis and here are listed the most popular:

• Code Coverage • Sequence Diagrams • DGML (Direct Graph Markup Language)

Code Coverage This is a technique used to measure the degree to which the source code of a program is executed and tested by a particular test suite. A program with high code coverage has been executed (and possibly tested) and has a lower chance of containing software bugs than a program with low code coverage. Many different metrics can be used to calculate code coverage; some of the most basic are the percent of program subroutines and the percent of program statements called during execution of the test suite.

Basic coverage criteria There are a number of coverage criteria, the main ones being:

• Function coverage - Has each function (or subroutine) in the program been called? • Statement coverage - Has each statement in the program been executed? • Branch coverage - Has each branch of each control structure (such as in if and case statements) been executed? For example, given an ‘if statement’, have both the true and false branches been executed? Another way of saying this is, has every edge in the program been executed? • Condition coverage (or predicate coverage) - Has each Boolean sub-expression evaluated both to true and false?





Sequence Diagrams They are widely used in UML and shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. Messages may be synchronous (requiring a response) or asynchronous (not requiring a response). The Return from or answer to a message uses a dashed line and a line-style arrowhead. Sequence Diagrams are supported by Visual Studio and other tools.

1. Object lifeline 2. Message/Stimulus 3. Iteration 4. Self-reference 5. Return 6. Anonymous object 7. Object name 8. Sequence number 9. Condition 10. Basic comment

DGML (Direct Graph Markup Language) It is an XML-based file format for directed graphs supported by Visual Studio and other tools. Here is a simple example of how the graph is made from an XML file [26]

















Legacy Code

From the Agile point of view legacy code is just untested code. It doesn’t necessarily mean OLD code. Virtually all untested code is legacy code. Do you like CI and Agile but you have to maintain millions line of old code? Here are some interesting ideas to do that. In many countries, not just developing countries people have found jobs to maintain legacy code. In countries such as India and China, several cities exploded in size and wealth over the last decade because of the outsourcing industry, and much of this outsourcing relates to legacy code.

The CEO was under pressure by his competitors and he decided the product’s deadline. Eventually this was communicated to Devs.How they react? The developer will “feel the obligation to respond out of respect, fear or misguided loyalty” and reluctantly commit to the deadline. The developer opens his secret toolbox and does everything possible to make the short-term deadline by using tools such as hardcoding, copy- paste-modify programming, skipping testing, working overtime, and other quality-destroying shortcuts. Nobody notices the use of these ‘tools,’ and so the deadline is made. Management rewards developers for their hard work and applauds their “great teamwork” and “fighting spirit.” These quality-destroying shortcuts result in bad legacy code, which slows down the development and the organization falls behind its competition. A predictable scenario unfolds. They need to reclaim the market and therefore make new promises, starting the vicious cycle all over again. The technical debt—the legacy code—makes development go slower. The learning debt—lack of renewal in developer skills— compounds this slowdown. Developers are so busy keeping unrealistic commitments that they have no time to keep up to date and refresh their skills.

Most companies do a poor job at educating developers. We frequently hear, “Everybody who graduated from university can code,” thereby

implying that educating basic development skills is unnecessary. Sadly often it’s otherwise. Many developers in large product groups lack fundamental skills such as good design of software, efficiently working with editors, effectively using their programming language, or automating tasks by writing scripts. Organizations are failing to educate in these areas because many business leaders have reasonably but incorrectly assumed that people learned these skills at university unaware that a computer science curriculum does not teach software development skills, and that most university professors do not know and cannot teach modern development practices. In contrast, lean organizations invest in educating their employees. One study shows that Japanese lean companies spend eight times as much effort educating new employees than their USA counterparts and twice as much as their European counterparts. [4]

Organizations also need to recognize the importance of continuous improvement. They not only need to provide education in basic skills, they need to create an environment in which employees are constantly challenged and learning. How? Managers acting as teachers, peers educating one another and code review, for instance, is an excellent opportunity for all Devs to share knowledge and to improve.

People subconsciously retard their own intellectual growth. They come to rely on cliches and habits. Once they reach the age of their own personal comfort with the world, they stop learning and their mind runs on idle for the rest of their days. They may progress organizationally, they may be ambitious and eager, and they may even work night and day. But they learn no more. [4]

There are few points to be considered when dealing with legacy code:

1. Avoid rewriting legacy code 2. Clean up around the point of change 3. Rewrite just ‘lethal’ code

When confronted with legacy code, developers frequently suggest rewrite, redesign, or rearchitect—scrap the legacy and write it again. Next time it will be better… Resist that temptation. Why? In a product group with a 30-year-old code base, a developer asked us if we could help refactor a 5000-line function. We thought he was exaggerating. But when we paired up and measured the function, we discovered it was slightly larger than 5000 lines of code (LOC). How are 5000 LOC functions created? Does a developer wake up and think, “Gosh, what a wonderful day today! Let’s write a 5000 LOC function?” Probably not. When a developer writes new code, he usually will write it with decent quality. But over time the quality degrades. A function becomes 5000 LOC. Why does this happen? The customer requests a new requirement and this is hacked in because of poor development skills or unrealistic schedules. Code quality goes down and the effort needed to make changes goes up.

Growing healthy code is a key strategy for eliminating legacy code. You can do so by cleaning up your neighborhood; by gradually fixing your “broken windows” [HT99]. Every time you make a change, look around your change point—the neighborhood— for code that can be improved—the broken windows—and add a couple of tests and refactor (see Figure 9.7). When starting this practice, every change is a little slower. But over time the code improves and the development speed increases because of the healthier code base.

Sometimes it is impossible to gradually grow the code base healthfully. For example, suppose that part of the low-level code is written in PL/M and no one is willing to learn PL/M. Or, part of your code base is written in a home-grown language, whose compiler only runs on VAX/ VMS. When gradual change is impossible —the legacy is lethal— then it is necessary to remove that part of the code instead of letting it kill your product. While replacing lethal code: cover it with test, and avoid adding functionality (to the old and new code).

Credits

[1] Prentice Hall Agile Estimating and Planning (2006) [2] http://en.wikipedia.org/wiki/Agile_testing [3]http://en.wikipedia.org/wiki/User_acceptance_testing#User_ acceptance_testing [4] http://en.wikipedia.org/wiki/Operational_acceptance_testing [5] http://en.wikipedia.org/wiki/Regression_testing [6] http://en.wikipedia.org/wiki/System_integration_testing [7] http://en.wikipedia.org/wiki/ATDD [8] http://en.wikipedia.org/wiki/Test-driven_development [9] Test-Driven Development by Example [10] http://en.wikipedia.org/wiki/Continuous_integration [11] http://en.wikipedia.org/wiki/Behavior-driven_development [12] Test-Driven Development By Example, Kent Beck [13]http://www.jamesshore.com/Agile-Book/test_driven_ development.html [14] http://www.ryangreenhall.com/articles/bdd-by-example.html [15]http://geekswithblogs.net/Aligned/archive/2013/07/26/benefits- of-behavior-drivendevelopment.aspx [16] Addison-Wesley Agile Testing, A Practical Guide for Testers and Agile Teams (2009) [17] http://en.wikipedia.org/wiki/Programming_complexity [19] http://en.wikipedia.org/wiki/Cyclomatic_complexity [20] Best Kept Secrets of Peer Code Review (SmartBear) [21] http://en.wikipedia.org/wiki/Code_review [22]https://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in- your-code/ [23] http://en.wikipedia.org/wiki/Unit_testing [24] http://www.nunit.org/index.php?p=quickStart&r=2.2.10 [25] https://www.owasp.org/index.php/Main_Page [26] http://en.wikipedia.org/wiki/DGML

6. Virtual Teams Virtual Teams Continuous Integration

Virtual Teams

A virtual team (also known as a geographically dispersed team, distributed team, or remote team, is a group of individuals who work across time, space and organizational boundaries with links strengthened by webs of communication technology [1]

Scaling Scrum and Virtual Teams (VT) are often interconnected and today Virtual teams have a broad range of applications including software development and R&D.

There are 2 main aspects related with a VT– purpose and people. Purpose is the most critical aspect and is what holds a virtual team together. VT do not have hierarchy or any other common structures because they may not be from the same organization, and purpose here brings and holds the team together. Purpose have to come internally during the team building activity whereas people need to work as a team not just as single individuals. This has been discussed previously about the process of forming, storming, norming & performing.

The structure found by Powell & Piccoli is the following: [2]

Inputs Design of a VT means simply that it should be planned. This means structuring the interactions; what kind of communication tools are used, how much face-to-face time will be possible, etc. Research has found that team building exercises, the establishment of shared norms and the establishment of a clear team structure helps the team to succeed. Researchers have found that having more face-to-face meetings improved the empowerment of VT, which leads to better learning. Numerous communication problems can be diverted by creating shared knowledge databases in order to allow all the team members to have the same information and to know that others have it, too.

With cultural differences also coordination problems and obstacles to effective communication can be involved. These problems may be solved by actively understanding and accepting differences in cultures.

The technical expertise of a team seems to have a positive effect on the team’s performance and the satisfaction of belonging to the team.

Teams should also have consistent training to improve team performance. For instance, mentoring is a good way to make personal ties to more

experienced VT professionals. Consistent training may help developing skills, trust, team work, and individual satisfaction.

Socio-emotional processes This section introduces the emotional problems involved and mitigation tactics needed to achieve cohesion and trust among team members. Overall, the research about this reports “a positive link between socio- emotional process and outcomes of the virtual team project.” Because of geographical distribution, face-to-face time occurs only rarely. This, according to research, results in weaker social links between team-mates and leads the team to be more task-focused than socially focused. If face-to-face meetings are feasible, meetings should be held as much as possible at the beginning of the team formation in order to bring team-mates closer and form interpersonal bonds. These meetings should focus more on relationship building than on actual business. However, with socializing different cultural preferences have to be remembered. If face-to-face meetings are not possible or feasible to the desired extent, other approaches can be applied. Leaders can help foster relationship building and general team building in many ways, e.g. by providing continuous feedback, listening to team members‟ opinions and suggestions, clearly stating the team member roles and having consistency in their leadership style.

Trust can be particularly problematic with VT, because it is arguable whether people can be expected to trust each other if they have never met face–to-face. Furthermore, trust is noted to be crucial in successful teams, but usually there is not much time to build it little by little because often the teams are short-lived in projects. To achieve high trust early in the group’s life, the team need social and enthusiastic communication and they need to cope well with technical uncertainty and individual initiatives.

Task processes Task processes are the different functions that happen when a team is doing its work. They start from selecting excellent communicators

for the team members and the right technology for them to use. Some empirically found that VT are failing to communicate due to wrong or lacking contextual information, unevenly distributed information, interpretation of the meaning of silence and technical problems. Because of the lack of face-to-face time, the team can miss nonverbal communication altogether. The extensive reliance on communication technology leads to reduced impact and difficulties in management compared to the traditional teams. In one study researchers tested the question of whether adding video to electronic communication helps to explain a detailed task (a map route) to another person. They found that for native speaker pairs it did not bring any additional benefits, but for nonnative speaker pairs it brought significant improvement to the task.

It is, naturally, more difficult to coordinate virtual teams in different time zones, cultures and mental models. Collaboration norms have to develop for the team to function well. As mentioned before, periodical face-to-face meetings are a good way to form relationships and also a good vehicle to coordinate activities and to drive the project forward.

Outputs Output in virtual teams means all the things that come out of the work processes of the team. When comparing the performance of traditional and virtual teams, the results are mixed. Some studies find traditional teams and some VT to be better. The majority of studies have found the teams to be about at the same level. The main factors are:

Training Strategy/goal setting Developing shared language Team building Team cohesiveness Communication Coordination and commitment of the teams The appropriate task-technology fit

Competitive and collaborative conflict behaviours (conversely, the same study found that avoidance and compromise conflict behaviour had a negative impact)

The results from different student studies are mixed concerning working in a VT found that teams which used their dialogue technique were more satisfied with decisions made in the team. One study found that a traditional team started out more satisfied than a virtual team. Then, in less than a year, the satisfaction of the VT rose and exceeded the satisfaction of the traditional team. Furthermore, some studies have found that women, generally, are happier in virtual teams than men.

We can visualize at least four possible models for global teaming:

• On-site, where we move the team to a customer location

• Onshore, where we move the team to the home country (HQ)

• Offshore, where the work is removed completely from the home country

Each of these approaches will have its own issues. As we move from top to bottom, we expect to see the cost of the outsource decline, although this decline is not always the case. Also, as we move down the list, management of the outsource becomes increasingly problematic. We are going from in-house work to the other side of the planet. Luckily, high-quality technical people exist all over the world so some of the difficulties may be more perceived than real.

Advantages Increased productivity: VT often see an increase in productivity because more personal flexibility is achieved, commute time is reduced, and work is not limited by the traditional 9-5 work day schedule. In turn, the company never sees an off hour. The team on the other side of the

globe simply picks up where the prior team left off. This approach is commonly referred to as “Follow the Sun Approach”. This advantage can translate to a much faster time to market for new products and technology.

Extended market opportunity: This is a major benefit of geographically dispersed teams due to direct access to different market opportunities. With work teams located in different parts of the globe, organizations are able to establish their presence with customers worldwide. This also gives small business owners the ability to compete on a global scale as well without being limited to a particular customer base.

Knowledge transfer: This is one of the most important benefits of a virtual team; utilizing people with different types of knowledge spread out across the globe can be very beneficial to any organization. Online meetings, remote computer access, wireless technology, and conferencing systems offer a way for participants to join a complex discussion from anywhere in the world. This benefit can enable most companies to compete on a global scale.

Statistics Related to Virtual Work Both fully virtual teams and organizations that employ some virtual workers experience a high ROI in retention, company loyalty and valuable output.

Disadvantages Communication deficiency: The biggest disadvantage that any VT can suffer from is the lack of efficiency in communication, partly due to constraints in virtual communication mediums. This is also primarily due to the fact that humans communicate better when they are able to communicate with their body language. Inevitably, virtual teams may face obstacles due to restrictions of the Internet which in turn may lead to incorrect assumptions if a message is not laid out clearly. Failure to properly communicate and clearly address messages or emails could lead to frustration and eventually failure.

Poor leadership and management: Poor leadership can result in the failure of any team, whether virtual or not; however, it becomes a much more prominent problem in VT. Messages must be sent across accurately and clearly. Inability to effectively communicate to members of the team can all greatly affect a project.

Incompetent team members: VT, as any team, need competent and experienced team members due to the distance factor which can overtly affect the timing and completion date of a project. Projects are more likely to fail or delay if the team consists of individuals who are lazy or lack sufficient knowledge to complete their assigned tasks.

In order for a highly distributed (multiple time zone) scrum team to function, they must have tools that allow for communication and some level of control. We have used some of these tools and we are writing this book as a distributed team. Examples are: Microsoft TFS, GitHub, AWS, SkyPe and Lync.

Some of the issues would apply to traditional program management as well as to Scrum. However, we have seen mitigation of some of these issues through the tight control provided by the Sprints and the daily scrum meeting and the benefits of network technology. Time zone problems become serious when dealing with distributed teams. This is especially true when we are trying to have meaningful Daily Scrum meetings and the times are extremely inconvenient for some team members. One possible solution is to perform different Daily Scrum meetings at different time and then communicating everybody the results of those meeting. In practical this would simply translate into a follow up of the main impediments which need to be escalated at higher level. The SM is usually responsible to do that. The time zone issue is not necessarily a problem and can be a gift as well as an impediment. For instance when the VT develop the new feature in the night, QA could test it in the morning stretching the duration of the day from 8hrs to 16hrs ideally. Something a simple low-speed Internet connection can cause so much

delay that video is out of the question. In this case it’s essential to make sure the VT can effectively work remotely and communicate at full speed with the rest of the team. In any project communication is everything especially when VT are involved. A video image of the speaker may not be necessary, but display of documents and movies of failures are usually beneficial.

One major upside to outsourcing is the expansion of potential team members. The enterprise can go quickly from a relatively small local team to a worldwide team, with the attendant potential for enhanced and specialized skill sets. For example,India is noted for having Capability Maturity Model firms at level five, the highest achievable. Another upside may be the reduction in cost of staffing, particularly when team members hail from less affluent economies; for example, Mexico or India.We suggest that product quality should be foremost, but the costing imperative makes a great deal of sense, particularly when the skills available in the less affluent economy rival or exceed those available locally. Sometimes the distant team members are actually closer to the customer. In this case we can send the team member instead of using expensive airplane flights to travel to meetings, reviews, and other interactions.

The good control derived from frequent quasi-formal reviews and the daily scrum meeting brings a necessary feedback mechanism into the world of outsourcing. By combining the outsourcing, most enterprises will have a winning system to complete their work. Usually teams that form spontaneously are far more productive than those put together by a manager. An emergent team is an entity with which we work, not something that management works on. Every time we work with people rather than over them, we increase our leverage because we decrease the amount of effort needed to move the group in the desired direction. Respect for the individual has been advocated in the Agile manifesto

and is a success key for Team management.

In Scrum scaling a team of, say 300 developers will result in creating 30 Scrum teams. The challenge is not to make them performing but integrating their work into a single and consistent deliverable.

The term offshore can be divided in 2 different groups: long-term and short-term. offshore for short-term projects, is usually applied where unfamiliarity (of the domain and client) is a dominant problem; for example, a 6-month project for a travel website, then a 12-month project for a retail chain point-ofsale system, ad infinitum. Offshore for long-term is usually applied with an onshore partner which is familiar with the project, such as a dedicated development center in China working on a telecommunications product.

One of the most important aspects to be considered when dealing with an offshore team is to make sure they understand Agile. If necessary we need to educate the offshore customer and management that agile is a set of values and principles (rather than a specific practice such as time boxed iterations) and that these values imply a close and ongoing collaboration with feedback loops between the real customer and real developers.

We need to share with the offshore team the essential ideas of agile development and Scrum if we use that.

1. Introduce Scrum (and its key values of transparency and empirical process control), explaining the events that the customer needs to participate in the Sprint Planning Meeting and Sprint Review, the Product Backlog, the Scrum rules, and so forth. 2. Clarify especially for the customer the Product Owner role, responsibilities and actions. 3. Present a comparison chart about Waterfall and Agile

While co-located teams often benefit most from a leader who acts as a facilitator, virtual teams need a manager who provides clearly defined

direction and removes all ambiguity from the process. In a geographically distributed team, trust is measured almost exclusively in terms of reliability. Reliability needs to be firmly established and this usually happen after 2-3 cycles. Because of that, face-to face meetings can be limited to once a year or so. In a dedicated chapter we’ll see which tools can be used to plan VT meetings.

Continuous Integration

Before looking at this section it’s probably worth to have seen the ZI cycle discussed in Chapter 1. Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed as part of extreme programming (XP). Its main aim is to prevent integration problems and is especially useful in large distributed VT. CI can be seen as an intensification of practices of periodic integration advocated by earlier published methods of incremental and iterative software development. [3]

CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. Initially this was conceived of as running all unit tests and verifying they all passed before committing to the mainline. This helps avoid one developer’s work in progress breaking another developer’s copy. If necessary, partially complete features can be disabled before committing. In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying quality control in general — small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes. This continuous application of quality control aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying

quality control after completing all development. This is very similar to the original idea of integrating more frequently to make integration easier, only applied to QA processes. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

When discussing about CI, people usually think to the tools. However Continuous integration is a practice—it is about what people do, not about what tools they use. As a project starts to scale, it is easy to be deceived into thinking that the team is practicing continuous integration just because all of the tools are set up and running. If developers do not have the discipline to integrate their changes on a regular basis or to maintain the integration environment in a good working order, they are not practicing continuous integration. Most problems implementing CI are organizational and not technical.

Adopting CI requires a change in human behaviour. There are companies with an excellent automated build but where developers did not integrate their code frequently. Even worse, the message “thou shall not break the build” was strongly promoted, for example, by shaming the people who broke the build. The result? Developers would delay their integrations out of fear of breaking the build. Despite their excellent alwaysgreen (always passing) automated build, they are doing the opposite of CI.

When a developer is unit-test-driving his code, he ensures that his local copy is always working. All the tests pass all the time. In theory, he is able to integrate code every TDD cycle; in practice, he integrates after a couple of cycles. CI on large products is hard precisely because it is a developer practice. If it were only about tools and automation, you could simply start a CI project or hire a company to “install CI.” But as a developer practice, CI requires a change to the daily habits of all developers. With many people, this is hard, takes time, and requires coaching. [4]

CI and iterative and incremental development in Scrum have the

same strategy. However, CI is a more fine-grained level than a Scrum iteration. Both reduce variability, uncertainty, and risk by working in small batches.

Large changes should be avoided as they’ll easily generate bugs. Large changes to a stable system will destabilize and break it in large ways. The larger the change, the more time it takes to get the system back to a stable state. This bring to the Agile concept of embracing changes. Why this is so crucial? Because the systems we’re going to design are too complex to be fully planned ahead. Instead of ‘building’ the system we ‘grow’ it since it’s an incremental and evolutionary process. A developer continuously integrates his work while working on a task. He does not wait for the task or the whole feature to be complete and then “bolt it” on the system. Rather, whenever a small amount of work can be integrated without breaking the system, then he integrates it. The more time it takes to integrate changes into the code repository, the less frequently developers will do it. Changes are batched for the sake of efficiency. Integration effort is impacted by the process overhead (the transaction cost), such as approvals and reviews needed before developers are allowed to integrate. Reduce this overhead or find creative ways to do things differently.

A developer should only integrate changes that do not break existing tests. Ideally, he runs all the tests before integrating. For this to be possible, the tests must run very fast. If they are slow, the developer will delay the integration to “work more efficiently.” However, running all the tests quickly is hard for large systems. Therefore, developers only run a subset of tests before checking in, and a CI system runs the remaining tests. The CI system acts as a safety net by giving the developer feedback about the tests he did not run. What happens when the CI system is slow? First, there will be many changes during one cycle, increasing the chance the build breaks. Second, developers do not integrate their changes in the broken build; rather, they batch them. Finally, when the build is fixed, all developers integrate their batched changes, leading to a high chance of breaking the build again.

Therefore, the safety-net-feedback cycle has to be fast. This decreases the chance the build will break and increases the ability to check in more frequently.

Developers need to integrate on the mainline or trunk. Making changes on a separate branch means that the integration with the main branch is delayed. The current status is not visible, so you do not know if everything works together. Branching during development breaks the purpose of CI and should be avoided. There are exceptions: First, customers might not want to upgrade their product to the latest release but still want patches. Thus, release branches are needed. Second, when scaling up a CI system, it can be useful to have very short-lived branches that are automatically integrated in the mainline.

Developers can usually do CI in 2 different ways: Synchronous and Asynchronous. Synchronous integration means a developer waits for his code to be integrated successfully. Asynchronous integration means the developer is supported by a CI system running tests while he moves on to work on something else. Asynchronous integration seems more efficient but often leads to sloppiness and broken builds. On the other hand, synchronous integration doesn’t work when the build takes too long, as in large products. When setting up a multi-stage CI system, you might consider using synchronous integration on the low level while using asynchronous integration for running higherlevel tests. It is not very hard to have a CI system compile everything but it’s not very useful. You want to have as many tests as possible running in your CI system. The more automated tests, the better your safety net and the more confidence your system is working. For new products, creating automated tests is not hard. However, many large products have legacy code without automated tests. Developers need to add automated tests and the faster the better.

The easiest way to speed up the build is to buy more hardware. Throw a couple of extra computers, extra memory, or a faster network connection at the problem and it goes away. Upgrading existing hardware takes investment and only minimum effort, making it the easiest and best choice.

Build incrementally may save a lot of time but it’s hard to have 100% reliable incremental builds and to prevent corruption of the incremental build, it’s a good idea to also keep a clean daily build. Deploying incrementally can help but especially dynamic upgrading requires changes to the system, making this option difficult to achieve.

Unmanaged dependencies are a common reason for slow builds. Examples: Header files including many other header files, or multiple link cycles to resolve cyclic link dependencies. Reducing dependencies speeds up your build and, as a side effect, improves the structure of your product.

Refactoring the code, not just the production code but the unit tests as well, can drastically reduce the time to build. A CI system can effectively include visual management an ‘information radiator’ as defined in Scrum. When the build breaks, a visual signal indicates failure. The intent is not for managers to punish the developer who broke the build; it is for developers to see the status of the build. What would they do with this information? Investigate what is going on or delay their integration when the build fails. If, after some time, the visual signal still indicates failure, more people may explore why it is not fixed.

Credits

[1] http://en.wikipedia.org/wiki/Virtual_team [2] http://en.wikipedia.org/wiki/Virtual_team [3] http://en.wikipedia.org/wiki/Continuous_integration [4] Addison-Wesley Practices for Scaling Lean and Agile Development

7. More Agile Intro Scrum & UML Sales & Marketing FDD SAFe Extreme Programming (XP) Lean & Agile Stage Gate Kanban

Intro

We’ve found the Agile methodology to be realistic and effective in most projects and Scrum implementation enough lightweight to be used successfully by an increasing number of companies around the world. However Scrum is not the only implementation of Agile and in this chapter we’ll alternatives successfully implemented in many projects.

Scrum & UML

The Unified Modeling Language (UML) is a general-purpose modeling language in the field of software engineering, which is designed to provide a standard way to visualize the design of a system. [1] One of the most used UML diagrams is the Use Case which is a representation of a user’s interaction with the system and made up by the followings:

• Use Case Diagram

• Narrative

• Activity Diagram (Scenario)

Why we should use a Use Case in Scrum? There is no need for such artifact in Scrum since the User Story already includes all you need to define a functional requirement. However sometimes Devs and QA want to have a workflow diagram to better understand a complex US. In this case a flowchart, like the activity diagram or a use case diagram could help. Keep in mind however that a use case is like a contract between the user and the BA whereas a User Story is a collaborative tool used to promote interaction across the Team in order to gain commitment. In a user story developers have a voice whereas a use case define what the user expects from the interaction with the system.

A use case diagram could be helpful, because it is pretty straightforward, and gives a high level idea about the user interaction. However I won’t recommend to use any other UML diagram in Scrum. In an agile project the requirements will probably change so frequently that your diagrams will become obsolete in few days. In this case you have to redraw them, which is essentially a waste of time.



Sales & Marketing

Scrum was born for software development but it can also be used in different industries as we’re going to see here. In other words, Scrum is a very pragmatic way to get things done.

Marketing is a service business, is the process of communicating the value of a product or service to customers, for the purpose of selling that product or service. [3] In school you’re taught to get the 4 Ps of marketing right (product,

price, promotion, and place), and bam—you have success, but it’s not always that simple, because what is success? After all, in marketing it is not always black and white how to quantify success especially if you are using more than one promotion and one channel to get to the market. Who is responsible for that success? Does marketing open the door and sales close it? [2]

At the centre of all of this are the people marketing serves as the 4 Ps of marketing that they teach in school leave out the most important ingredient: the people who are your ultimate consumers, the people you service in your company who have expectations of your programs. We can see the marketing department as being on loan to sales, having as a main task to make their job easier.

The ability to change is the key ingredient for anything’s survival, including a marketing career. This is where agility comes in, and we will be talking throughout this book about practical ways to become more agile in your thinking as well as your marketing. [2]

Scrum may work well in marketing providing the team is self-organized and crossfunctional. We can have in the same team marketing and content designers and basically we can have the same meetings we hold in Scrum and the same artifacts as kanban or burndown charts. Because Scrum allows you to break down complex projects into manageable tasks, it forces you to think about the specific actions needed to reach a goal, and it encourages reviewing and revising those actions with your team. The ultimate goal is always in mind, but the steps necessary to achieve it are the main focus. Of course, while there’s nothing about Scrum that’s unique to software, that doesn’t mean that your sales, marketing, or management teams will be able to leverage it in exactly the same way that your software development team does. To make sure that Scrum translates throughout your organization it’s important to consider three key things: [4]

1. Sprint length: Because of the iterative nature of technical companies and the type of

products they create and sell, software development teams typically opt to use sprints that last between one and two weeks long. Depending on the goals and objectives of your non-technical teams, however, sprints may need to be shorter or longer. Just be careful not to incorporate so much time between sprints that your teams lose their sense of urgency.

2. The “product” to be worked on: With software development, this step is simple. With sales and marketing, it can be a bit more difficult to define what exactly the “product” is. More or less, your goal here is to define what exactly the team will be working on and what their activities will yield.

3. The team functions necessary to complete a sprint: In other words, who are the equivalent developers, testers, etc. on the non-technical team, and how do those functions translate to those organizational environments? It can be challenging to get all of the people necessary to accomplish a meaningful increment onto one team, but it is possible.

Defining Processes in the Service Industry One approach to defining processes in the service industries would be to use a quality function deployment (QFD) to establish the voice of the customer. The voice of the customer is important when selling a manufactured product. When selling a service, it is even more important due to the “soft” nature of the service. These transactional activities are amenable to the use of scrum teams, who can participate in the following activities: [5]

• Quality function deployment

• Pugh concept selection

• Opinion surveys

• Mail-out

• In-person

• Telephone

• Internet

• Ethnographic methods

A top-level product backlog for a scrum team for capturing the voice of the customer can look like the following:

1. Set goals and objectives 2. Set schedule and budget 3. Preliminary work with a focus group 4. Set population and sampling rules 5. Assess expectations regarding missing data 6. Procedures for population and sampling 7. Design survey

Below you’ll find an example of Marketing product backlog. Note that we’ve tasks instead of US.



FDD

Feature-driven design (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner. [6]

FDD can manage large teams (ideally up to 500 Devs) and could be the right move towards agility for the organizations deeply-rooted in traditional ‘waterfall’ way of software development and “command and control” style of management. Such organizations usually face many challenges while transitioning to agile methods. In fact one of the biggest challenge is changing the traditional mindset to an agile one.

Agile methods like Scrum or XP introduce a completely different paradigm – minimal upfront requirements specification and design, new

terminologies, roles, a Boolean measure of “Done” (i.e. either “Done” or “Not Done” ). However FDD has certain characteristics which the traditionalists can better understand and this would hopefully make the Agile journey less painful. FDD invests comparatively more time in upfront requirements specifications and design as compared to other agile methods. It has a well defined sequential modeling and planning steps for this purpose. The FDD roles like Project Manager, Development Manager, Chief Architect are perceived more favorably by traditionalists since they sound more familiar than Scrum roles like SM, Product Owner. Unlike other agile methods like XP and Scrum which do not give credit to partially done work, FDD defines completeness of work in terms of discrete percentages. Eg. a feature which has completed design inspection is considered 44 % complete. This will get more buy-in from the project managers and team members used to conventional way of tracking the project. Like traditional methods, FDD stresses on individual code ownership, design inspections and code inspections. [7]

FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities. In the figure on the right, the meta-process model for these activities is displayed. During the first two sequential activities, an overall model shape is established. [6]

In FDD concept of Quality is broadened so as not just to test the code, but also include things such as coding standards, measuring audits and metrics in the code. FDD is:

• Highly and short iterative.

• Emphasizes quality at all steps

• Delivers frequent, tangible working results at all steps

• Provides accurate and meaningful progress and status information, with the minimum of overhead and disruption for the developers. • Is liked by client, managers and developers

FDD defines six key roles and implies a number of others. The Project Manager (PM) is the administrative head of the project responsible for reporting progress, managing budgets, fighting for headcount, and managing equipment, space, and resources, etc. The Chief Architect (CA) is responsible for the overall design of the system. He is responsible for running the workshop design sessions where the team collaborates in the design of the system. The work requires both excellent technical and modeling skills as well as good facilitation skills. He or she steers the project through the technical obstacles confronting the project. The Development Manager (DM) is responsible for leading the day- to-day development activities. In a facilitating role requiring good technical skills, the Development Manager is responsible for resolving everyday conflicts for resources when the Chief Programmers cannot do it between themselves. The Chief Programmers are experienced developers who have been through the entire software development lifecycle a few times. They participate in the high-level requirements analysis and design activities of the project and are responsible for leading small teams of three to six developers through low level analysis, design and development of the new software’s features. The Class Owners are developers who work as members of small development teams under the guidance of a Chief Programmer to design, code, test, and document the features required by the new software system. The Domain Experts are users, sponsors, business analysts, or any

mix of these. They are the knowledge base that the developers rely on to enable them to deliver the correct system. Domain Experts need good verbal written and presentation skills. Their knowledge and participation are absolutely critical to the success of the system being built. [7]

The supporting roles include the followings:

The Release Manager ensures that the Chief Programmers report progress each week. He then reports directly to the Project Manager.

A Language Guru is a person who is responsible for knowing a programming language or a specific technology inside out. In projects where a programming language or technology is used for the first time, then this role is special. The Build Engineer is responsible for setting up, maintaining, and running the regular build process. The Toolsmith creates small development tools for the development team, test team, and data conversion team. The System Administrator configures, manages, and troubleshoots any servers and network of workstations specific to the project team.

Testers are responsible for independently verifying that the system’s functions meet the users’ requirements and that the system performs those functions correctly. Deployers convert existing data to the new formats required by the new system and work on the physical deployment of new releases of the system. Technical Writers write and prepare online and printed user documentation.



Develop overall model The focus of this phase is to arrive at an overall object model for the product. FDD users refer to this as the “shape” model and, as the name implies, it’s intended as a high-level starting point. The Chief Architect or Chief Programmer (CP) leads this session and breaks it into smaller, business area–specific sessions on larger projects. On these large projects, the team will develop domain area specific models and then combine into an overall, complete model.

Build feature list The knowledge that was gathered during the initial modeling was used to identify a list of features. This was done by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity formed the categorized feature list. Features in this respect were small pieces of clientvalued functions expressed in the form “ ”, for example: ‘Calculate the total of a sale’ or ‘Validate the password of a user’. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces. Building a list of features is analogous to XP’s user stories and these will direct the team’s development work. The role of the CP is to decompose the high-level model into a series of business activities. Features are expressed in terms of something of business value to the customer. To give you an idea of size, each feature will be from 1 to 10 days in length. Like XP, FDD has the concept of a split for longer features.

Plan by feature After the feature list had been completed, the next step was to produce the development plan. Class ownership has been done by ordering and assigning features (or feature sets) as classes to chief programmers. A small planning team comprising the CP, project manager, and development manager plans the order of feature delivery. This planning is much more specific than with XP, as developers are assigned individual class-level work. The CP takes ownership for the complete feature. The CP acts as a kind of “mini” project manager as he or she assigns work and monitors progress for a particular set of features. The project manager is more concerned with the overall plan and progress.

Design by feature A design package was produced for each feature. A CP select a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the CP worked out detailed sequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written and finally a design inspection is held. The CP takes a set of features and designs an object model with the requisite methods and properties. Though the CP definitely leads this stage, the whole development team will have some degree of input. The output of this phase is a fairly detailed design for that feature set.

Build by feature Working from the design package produced during the Design by Feature process, the class owners implement the items necessary for their class to support the design for the feature(s) in the work package. The code developed is then unit tested and code inspected, the order of which is determined by the Chief Programmer. After a successful code inspection, the code is permitted to build. Build by feature is where developers create the software, complete their unit tests, and integrate into the product. FDD also requires code inspections or walkthroughs at this point in the cycle. The CP has the final say whether a component is released for build. Milestones

Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project it is however important to mark the progress made on each feature. FDD therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during the ‘Design By Feature’ activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. FDD uses 6 milestones to track progress of each feature through process IV and V, Design by Feature (DBF) and Build by Feature (BBF). The first 3 milestones are completed during the DBF process. The last three milestones are completed during the BBF process. The 6 milestones are completed sequentially for each feature being developed. A milestone is reported complete only when all the work for that task has been finished and verified to be so. These 6 milestones are as follows:

The Domain Walkthrough milestone is attained on completing the domain walkthrough and the optional task of studying the referenced documents.

The design milestone is attained on completion of the three tasks

• Develop the sequence Diagram(s)

• Refine the Object Model

• Write Class and Method Prologues

The Design Inspection milestone is attained on successfully passing the design inspection task

• The Code milestone is attained on completion of the implement classes and methods task. • The Code Inspection milestone is attained on completed of the code inspection task. This includes the completion of any modifications required by the inspection and the completion

of any unit testing performed after the code inspection.

• The ‘Promote to Build’ milestone is attained when all the code for a feature has been checked into the version control system used to generate “the build”.

A percentage weighting is assigned to each milestone. So we can say that a feature that has reached the coding stage is 44% complete. The weighting percentages assigned to each milestone varies from situation to situation, depending upon the level of effort put into it. Now the percentage of completeness for every feature in the feature list is calculated. Doing this for all the features in a Feature Set, gives us the completion percentage of the Feature Set. This is done for each major Feature Set and then for the whole project. In this way we can count the number of features not started, the number in progress, and the number completed for the project. [8]





SAFe

SAFe is a publicly available framework to enable the enterprise to become more agile. As Scrum is to the Agile team, SAFe is to the Agile enterprise. Essentially when the number of team members exceed 10 then you should probably think to scale up. For a defense project I’ve managed up to 250 team members splitted in several Scrum Teams using SAFe. By large team I mean more than a thousand people, though it can be just as effective for teams of 50–100 people.



SAFe is a publicly available framework to enable the enterprise to become more agile. As Scrum is to the Agile team, SAFe is to the Agile enterprise.

SAFe makes a distinction between content (what the system does) and design (how the system does it). There is separate “authority” for content and design.

The Product Manager (Program Manager, PM) has content authority at the program level. The System Architect has design authority at the program level. SAFe operate at 3 levels: Portfolio Management Program (like Scrum of Scrums) Team (like Scrum)

Team

A team in SAFe might be 8 to ten people, with everything they need to deliver software, end-to-end: requirements, coding, testing and deployment. Several teams create what SAFe calls a release train, which organizes around a program. That’s a single project, or at least, one program-of-projects. It has a single line item in a budget – the company is buying one specific thing. This is the “small project” the executive talks about.

Historically, scrum, extreme programming and other agile methods tend to focus, and stop, at the team level. SAFe presents a single, unified view of the work to executives, allowing them to drill down for details or up for trends and analysis.

After planning, the team works on the next program increment (PI), and a small team needs to steer, or coordinate that work to success. SAFe calls that the release management team, which typically consists of the Release Train Engineer (a program facilitator, chief scrum master for the train), Product Management, and a few executives who are not committed to that program full-time. It may also include development managers, senior testers, architects and other roles on the program that could give input. This is the group that communicates with external groups on timing, and takes corrective action when there are schedule problems. SAFe suggests that the group meet weekly.

Program ART : is the agile release train (frequent so you don’t need to worry if you miss one) PSI: potentially shippable increment is usually 5-Sprints (one Release). PSI is defined by PM (Project Manager)

ART (Agile Release Train) is like a train formed by several agile teams (coaches), typically consisting of 50-125 individuals. ART serves as the program-level value delivery mechanism in SAFe and delivers a value

stream for the organization.

ART is managed by the RTE (release train engineer) which is the Scrum Master of the Train. A value stream is a sequence of activities intended to produce a consistent set of deliverables of value to customers. Value streams are realized via the ART. Adoption focuses on identifying a value stream. Between 5 and 10 teams work together on a train. They synchronize their release boundaries and their iteration boundaries. Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI). Release trains are organized around the enterprise’s significant value streams-those long-lived flows of products, systems, solutions, or services wherein an optimized development and delivery strategy creates the greatest economic benefit.

ART aligns teams to a common mission, provides for a routine 8-12 week planning, development and retrospective cadence. and implements continuous product development flow. Each train has the dedicated resources necessary to continuously define, built, and test valuable and evaluate-able system-level solutions every two weeks, and can release software at any time the market demands.

Like a real train, the release train runs on a schedule, though that schedule can be as flexible as your organization needs it to be. This Program Increment (PI) is described in more detail below. SAFe suggests that people involved in a release train be dedicated full-time to that release train, regardless of reporting structure.

The release train supports a long-term program that may have many teams and projects inside of it. The teams synchronize, lining up sprints and releases, so the code can be deployed at the same time for each increment. Older versions of SAFe suggested a “hardening sprint” (or two), not for testing within teams as much as for coordinating interfaces between teams. It might be best to think of the hardening sprint as a transitional step – something new program teams need to make the release train successful.

Each release train meets once at the beginning of each release cycle to develop Program Increment Objectives, and the team-level objectives that make the increment objectives possible. The meeting is typically two days long. In addition to simply planning, the meeting has other benefits, like allowing the team to have a sense of team-ness, to create the face-to-face conversations that make real progress possible. The meeting include representatives from both business and technology; over the course of the event the two groups merge and align, again reducing friction and errors from misunderstanding.

SAFe defines an artefact hierarchy of Epics, Features, and User Stories. The program backlog is a prioritized list of features. Features can originate at the Program level, or they can derive from Epics defined at the Portfolio level. Features decompose to User Stories which flow to Team-level backlogs. Features are prioritized. There are business epics (customer-facing) and architectural epics (technology solutions). Business and architectural epics are managed in parallel Kanban systems.

Portfolio PPM has a central role in Strategy, Investment Funding, Program Management and Governance. Investment Themes drive budget allocations. Themes are done as part of the budgeting process with a lifespan of 6-12 months.

The portfolio vision sketches out epics, strategy and value streams. The program level, where 50-125 people at a time work on a specific program, is well-represented. Below the program level is the team level. A portfolio is a collection of these programs, the total amount of budget dollars within IT going into software development. SAFe calls this “Program Portfolio Management,” and suggests that one office have the responsibility for strategy and investment funding, program

management and funding.

One of SAFe’s public claims is that “spaghetti-code can’t scale.” To avoid crappy code, SAFe suggests a handful of practices that are aimed more at prevention than traditional test/fit testing. SAFe starts with Agile Architecture, a principal that architecture is emergent, but the system architecture needs to evolve ahead of the newest features, to make adding those features possible. It includes continuous integration, having the software build and automated checks run for every check- in. SAFe advocates test-first as a philosophy, not just unit tests but also at the specification level. This practice of creating concrete examples, down to the inputs and expected results as a collaborative, whole team effort is called Acceptance Test Driven Development in SAFe.

SAFe also includes classic extreme programming practices like pair work, not just for programmers but for many roles, along with refactoring (improving the design of existing code) and collective ownership. Collective ownership of code gets more complex with multiple teams, but it also means that teams can make corrections instead of creating a “ticket,” or “make-work” for another team. This prevents the first team from being blocked and also does not create priority problems for team two – as team one’s priority and blocker will probably be team two’s “nice to have.”

At the portfolio level, SAFe is essentially looking at the IT organization’s ability to deliver, and perhaps support/maintain, working software. The metrics that SAFe suggests are things like employee engagement, customer satisfaction (these may be internal), agility, time-to-market, quality and the ability to work with partners outside of the software organization. These terms may seem a bit light, or qualitative, but SAFe provides specific, clearly measurable meanings to each of these terms. In addition to these hard measures, SAFe suggests burn-up charts to manage the process of an individual epic and a bar chart showing actual and to-be-done work to compare the progress of multiple epics at one time.

Where most agile development organizations focus at the team level, on sprints or iteration, SAFe focuses on the program, which could be five to 15 teams. The “programlevel sprint” in SAFe is the Program Increment (PI), formerly known as the Potentially Shippable Increment (PSI). The goal of the PI is to accomplish the PI objectives.

Now we start to see the pieces of SAFe coming together: Release Planning defines the objectives for the Agile Release Train, which are built during the Program Increment.

SAFe also supports different cases for release schedules: releasing on the PI cadence, releasing less frequently or releasing more frequently. While the development cadence is 10 weeks, release can happen at any time. Former Agile Conference Chair Johanna Rothman, and new author of “Agile and Lean Program Management,” suggests that small batches are possible even within large program teams. As she puts it, “I want small releases every single day (if possible), and monthly if not daily.” [14]

In his 2013 blog post “UnSAFe at any Speed,” Ken Schwaber argues that SAFe is essentially the Rational Unified Process (RUP) rebranded as agile, and that after the failure of RUP in the marketplace, the RUP people came to agile.

Reading the SAFe descriptions, however, gives a different impression. Most of the pieces of SAFe are familiar, borrowed from existing agile methods that work. The package and the organization may be new, but most of the pieces of SAFe are practices with some success behind them.

One advantage of SAFe is how easy it is to transition to. You “just” train key implementers, leadership, management, and the team in a few days then flip a switch, in a manner of speaking. While obviously there’d be a lot more to do for the adoption of Lean-Agile development, the new structure can accommodate managers, directors, architects, analysts and every other role, with no need for painful transitions or

job changes.

That leads to a concern that SAFe is a transitional step, just the first and least painful. SAFe may be a good step, and an improvement, for a large organization, but you’ll need to work on a case by case approach to make it successfull in your organization. Agile coach Yves Hanoulle puts it this way “For most of these I would say, SAFe goes further as they are ready to go, but not far enough as they should go.”[14]

Most of the time we just focus on a methodology, we have little time to share the business value with the Team and this means that developers are most of the time disconnected from the business value, which is ultimately what they need to deliver. A user story is in fact the integration between a business value and functional requirements.

One of the things that got me started is that the value of a project is defined by why over how: value = why / how. So when you focus only on “how” and the “why” is zero, it doesn’t really help: If the why is zero, you can have a 1000 for how, but the end result will still end up with zero. So it is really important to focus on why before focusing on how, or at least at the same time. Where, like as in the agile manifesto, it doesn’t mean that we shouldn’t do anything on how. Tools and practices are important, but the why is more important. If I look back at all the books that we have in the agile community, unfortunately they all focus on how to do it. [14]

Extreme Programming (XP)

XP is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer

requirements can be adopted. Other elements of XP include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer’s requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels. As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of pair programming. [9]

On XP a team can usually have 5-20 total team members, ideally all full-time.

Main differences between Scrum and XP Both agile methodologies are based on the iterative and incremental development. They do have similarities but also have differences and here is a brief highlight:

Scrum is more high level, focusing on the management of the project (e.g. the requirements or features are managed) rather than specifying or defining engineering practice such as pair programming or test driven development

• Once sprint starts, customer cannot change the requirements, in other words (ideally) the customer will have to wait until the sprint finishes. In XP however, requirements can change anytime. • Both XP and Scrum define the role of a coach, In Scrum it is called Scrum Master and requires (or strongly recommended) certification, whereas, XP defines the role of coach quite informally and the role may float between members of the

team.

• Scrum and XP are often used together: Scrum defines the framework and XP defines the engineering practices and they fit together nicely. • XP teams work in a strict priority order. Features to be developed are prioritized by the customer (PO) and the team is required to work on them in that order. By contrast, in Scrum the PO prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items.

I’ve never seen a Scrum team not choose to work on the highest-priority item. And a Scrum team will very likely choose to work on the second most important. However, at some point one of the high priority items may not be a good fit for the sprint being planned-maybe a key person who should work on it will be swamped by work on higher priority items. Or maybe it makes sense to work on a slightly lower priority item (let’s say #10 on the product backlog instead of #6) because the team will be working in the code where #10 would be implemented. [10]

XP Roles On-site customers—often just called customers—are responsible for defining the software the team builds. The equivalent role in Scrum is the SH. The rest of the team can and should contribute suggestions and ideas, but the customers are ultimately responsible for determining what stakeholders find valuable. Customers’ most important activity is release planning and they may or may not be real customers, depending on the type of project.

The product manager job is to maintain and promote the product vision and in addition to that, they’re also (often) responsible for ensuring a successful deployment of the product to market. The equivalent role in

Scrum is the PO.

Domain experts (aka subject matter experts - SME) Most software operates in a particular industry, such as finance, that has its own specialized rules for doing business. To succeed in that industry, the software must implement those rules faithfully and exactly. These rules are domain rules, and knowledge of these rules is domain knowledge. The team’s domain experts are responsible for figuring out technical details and having the answers at their fingertips. They’re are experts in their field like financial analysts, nuclear engineers or marketing managers.

UX and UI designers These roles are the same as in Scrum

Business Analysts - BA Analysts help customers think of details they might otherwise forget and help programmers express technical trade-offs in business terms.

Programmers & Testers They have similar roles in Scrum. Testers are specialized programmers that help XP teams produce quality results from the beginning. Some XP Teams do not have testers because developers are expected to write their own unit tests. Coaches Note that XP leaders lead by example, helping the team reach its potential rather than creating jobs and assigning tasks. To emphasize this difference, XP leaders are called coaches (SM in Scrum). One of the most important things the coaches can do is to help the team interact with the rest of the organization. They help the team generate organizational trust and goodwill, and they often take responsibility for any reporting needed.

Project managers They help the team to work with the rest of the organization, the project governance often indicated as steering committee.

Project Community Every team has an ecosystem surrounding it which extends beyond the team to the project community, which includes everyone who affects or is affected by the project. (SH, Sponsor, CTO, CEO, HR etc..)

XP Cycle XP teams (ideally) perform nearly every software development activity simultaneously. Analysis, design, coding, testing, and even deployment occur with rapid frequency.

Design and Coding XP uses incremental design and architecture to continuously create and improve the design in small steps. This work is driven by test-driven development (TDD), an activity that inextricably weaves together testing, coding, design, and architecture. To support this process, programmers work in pairs, which increases the amount of brainpower brought to bear on each task and ensures that one person in each pair always has time to think about larger design issues. Programmers are also responsible for managing their development environment. They use a version control system for configuration management and maintain their own automated build. Programmers integrate their code every few hours and ensure that every integration is technically capable of deployment. To support this effort, programmers also maintain coding standards and share ownership of the code. The team shares a joint aesthetic for the code, and everyone is expected to fix problems in the code regardless of who wrote it.

Testing XP includes a sophisticated suite of testing practices. Each member of the team— programmers, customers, and testers—makes his own

contribution to software quality. Well-functioning XP teams produce only a handful of bugs per month in completed work. Programmers provide the first line of defense with test-driven development. TDD produces automated unit and integration tests. In some cases, programmers may also create end-to-end tests. These tests help ensure that the software does what the programmers intended. Likewise, customer tests help ensure that the programmers’ intent matches customers’ expectations. Customers review work in progress to ensure that the UI works the way they expect. They also produce examples for programmers to automate that provide examples of tricky business rules. Finally, testers help the team understand whether their efforts are in fact producing highquality code. They use exploratory testing to look for surprises and gaps in the software. When the testers find a bug, the team conducts root-cause analysis and considers how to improve their process to prevent similar bugs from occurring in the future. Testers also explore the software’s non-functional characteristics, such as performance and stability. Customers then use this information to decide whether to create additional stories. The team doesn’t perform any manual regression testing. TDD and customer testing leads to a sophisticated suite of automated regression tests. When bugs are found, programmers create automated tests to show that the bugs have been resolved. This suite is sufficient to prevent regressions. Every time programmers integrate (once every few hours), they run the entire suite of regression tests to check if anything has broken. The team also supports their quality efforts through pair programming, energized work, and iteration slack. These practices enhance the brainpower that each team member has available for creating high quality software.

Deployment XP teams keep their software ready to deploy at the end of any iteration. They deploy the software to internal stakeholders every week in preparation for the weekly iteration demo. Deployment to

real customers is scheduled according to business needs. As long as the team is active, it maintains the software it has released. Depending on the organization, the team may also support its own software (a batman is helpful in this case; see “Iteration Planning” in Chapter 8). In other cases, a separate support team may take over. Similarly, when the project ends, the team may hand off maintenance duties to another team. In this case, the team creates documentation and provides training as necessary during its last few weeks.

Note that the exact structure of your team isn’t that important as long as it has all the knowledge it needs. This means that if project managers and testers are typical for your organization, you just include them otherwise, you don’t necessarily need to hire them.





Lean & Agile

Lean (or Lean Manufacturing) , is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. Essentially, lean is centered on preserving value with less work (and waste) and is a management philosophy derived mostly from the Toyota Production System (TPS) [11]

Essentially Lean embraces the same concepts of Agile. A fundamental principle of lean manufacturing is demand-based flow manufacturing. In this type of production setting, inventory is only pulled through each production center when it is needed to meet a customer’s order. The benefits of this goal include: • decreased cycle time

• less inventory

• increased productivity

• increased capital equipment utilization

Another key Lean principle is to focus on long-term results. Lean architecture is about doing what’s important now that will keep you in the game for the long term. This is the same concept of minimizing the technical debt that we’ve seen in Agile. Here are the 7 Key Principles of Lean Software Development:

1. Eliminate Waste 2. Build Quality In 3. Create Knowledge 4. Defer Commitment 5. Deliver Fast 6. Respect People 7. Optimise the Whole

Probably point 4 need to be discussed more in details to avoid any misunderstanding.

It doesn’t mean you should put off committing to anything indefinitely, or defer all decisions – that would obviously be a very bad idea. Defer Commitment mean to decide as late as possible, particularly for decisions that are irreversible, or at least will be impractical to reverse. Time box critical decisions for the latest point they can be made without causing problems and of course it is important not to take decisions too late. In areas of complexity or uncertainty, where things are very likely to change, this is especially useful. This is in line with the agile concept of not planning too much ahead (when details are limited) but instead to grow the product progressively through small interactions.

In a nutshell, Lean says to relentlessly eliminate anything that isn’t adding value and only work on what we absolutely need to be doing at this moment in time. Eliminating waste means eliminating useless meetings, tasks and documentation. But it also means eliminating time spent building what “we know” we’ll need in the future (things are constantly changing so we often end up not needing them – or if we do, we have to rework them because conditions and our understanding has changed by then). It also means eliminating inefficient ways of working – like multitasking – so we can deliver fast.

Lean also puts a very strong emphasis on what it calls “the system” – that is, the way that the team operates as a whole. We always need to be looking at our work from a top level to ensure we’re optimizing for the whole. For example, many managers want to “optimize” individual developers by ensuring they’re always at 100% – but most of the time, this is actually counter-productive. Let’s not have people coding something that isn’t needed (or fully defined yet) just for the sake of coding, because that actually creates more work for us in the future.

Along those lines, Lean says to respect that the people doing the work are the ones that best know how to do it. Give them what they need to be effective and then trust them to do it. Software development is about learning, so structure the work to ensure we’re continuously learning. And because of that, defer decisions until the last responsible moment

(because we’ll know more by then). Finally, develop in a way that builds quality into our product, because there’s no way to continuously deliver fast if we have to keep going back to clean up our messes. [12]

“Organizations that are truly lean have a strong competitive advantage because they respond very rapidly and in a highly disciplined manner to market demand, rather than try to predict the future.” – Mary Poppendieck



Stage Gate

A stage-gate (Phase-gate) model, is a project management technique in which a project (e.g., new product development, process improvement, business change) is divided into stages or phases, separated by gates. At each gate, the continuation of the process is decided by (typically) a manager or a steering committee. The decision is based on the information available at the time, including the business case, risk analysis, and availability of necessary resources (e.g., money, people with correct competencies). [13]

Phase The traditional phase-gate process has five phases and five gates:

• Scoping (the work to be done)

• Build business case (why we do this work)

• Development

• Testing and validation

• Launch

Gates Provide various points during the process where an assessment of the quality of an idea is undertaken. It includes three main issues:

• Quality of execution: Checks whether the previous step is

executed in a quality fashion.

• Business rationale: Does the project continue to look like an attractive idea from an economic and business perspective. • Action plan: The proposed action plan and the requested resources reasonable and sound.

A gate meeting can lead to four results: go, kill, hold, recycle, or “Conditional go” and Gates have a common structure and consist of three main elements:

• Deliverables: What the project manager and team deliver to the decision point. These deliverables are decided at the output of the previous gate, and are based on a standard menu of deliverables for each gate. • Criteria: Questions or metrics on which the project is judged in order to determine a result (go/kill/hold/recycle) and make a prioritization decision. • Outputs: Results of the gate review—a decision (go/kill/ hold/recycle), along with an approved action plan for the next gate, and a list of deliverables and date for the next gate.



Kanban

Kanban (literally signboard or billboard in Japanese) is a scheduling system for lean and just-in-time (JIT) production. Kanban is usually used during the Daily Scrum a system to control the logistical chain

from a production point of view, and is not an inventory control system. It was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production.

Kanban is also used in Scrum to indicate the wallboard (an information radiator) where the Tasks or US are shown under different categories like ‘non started’, ‘started’, ‘Done’. This is a very effective way to show the team members the status of a particular task.

Kanban, is part of an approach where the “pull” comes from the demand. The supply or production is determined according to the actual demand of the customers. In contexts where supply time is lengthy and demand is difficult to forecast, often, the best one can do is to respond quickly to observed demand. This situation is exactly what a kanban system accomplishes, in that it is used as a demand signal that immediately travels through the supply chain. This ensures that intermediate stocks held in the supply chain are better managed, and are usually smaller. Where the supply response is not quick enough to meet actual demand fluctuations, thereby causing significant lost sales, stock building may be deemed more appropriate, and is achieved by placing more kanban in the system.

Kanban cards They are a key component of kanban and signal the need to move materials within a manufacturing or production facility or move materials from an outside supplier in to the production facility. The kanban card is, in effect, a message that signals that there is a depletion of product, parts, or inventory that, when received, the kanban will trigger the replenishment of that product, part, or inventory. Consumption therefore drives demand for more production, and demand for more product is signaled by the kanban card. Kanban cards therefore help create a demand-driven system.

It is widely held by proponents of lean production and manufacturing that demanddriven systems lead to faster turnarounds in production

and lower inventory levels, thereby helping companies implementing such systems to be more competitive. The secret to a good kanban system is to calculate just enough kanban cards required for each product. Most factories using kanban use the coloured board system.



Credits

[1] http://en.wikipedia.org/wiki/Unified_Modeling_Language [2] Apress Agile Marketing (2011) [3] http://en.wikipedia.org/wiki/Marketing [4] http://labs.openviewpartners.com/scrum-for-non-technical-teams/ [5] Scrum Project Management , CRC Press [6] http://en.wikipedia.org/wiki/Feature_Driven_Development [7] FDD (Feature Driven Development) , Gopinath [8] Feature Driven Development, Sadhna Goyal [9] http://en.wikipedia.org/wiki/Extreme_programming [10] Differences Between Serum and Extreme Programming, Mike Cohn [11] http://en.wikipedia.org/wiki/Lean_manufacturing [12]http://www.hackerchick.com/2012/01/agile-vs-lean-yeah-yeah- whats-thedifference.html [13] http://en.wikipedia.org/wiki/Phase%E2%80%93gate_model [14] http://www.cio.com

8. Tutorials Scrum - Meetings XP - Scale Teams FDD

In this chapter we’ll see some practical examples of how to bind together the concepts we’ve seen so far.



Scrum - Meetings

Daily Scrum As a general rule we should have meetings as least as possible to avoid unnecessary interruptions. Devs (and all team members) hate getting interrupted and for good reasons. When you need to solve a problem you want silence and concentration since there are usually many ways to solve a problem but only few solutions are optimal. To find the right solution you need to explore all the others and this take time and concentration. The short duration of the meeting is not an excuse to that. We hear often the manager saying “It’s only 30min meeting” but this doesn’t mean that participants need not to focus on the meeting before getting into it. Prepare documents or demo or just review the main topics takes time and distract from the current task. Moreover after the meeting Devs need to recollect where they were and this again will take time before they get productive. As an average the time you spend on the meeting need always to be increased by a constant to accommodate the time to prepare for it and the time to regain your productivity back as before.

The situation worsen when the organizer do not send the invitation in time and do not attach all the relevant details to it. The result is that people will not have a clue of what they’re going to do and often not even enough time to prepare for the meeting or to stop properly their current task. This creates concerns (at the best) on the participants and will not help creating a positive and collaborative attitude during the meeting.

Let’s now see a typical Daily Scrum meeting with Bob, the SM The meeting need to be conducted everyday at 9.00am and Tom is the PO. The team is made by 8 members including QA and UXD but SM and PO are in a different office since there was not enough space in the team room for all.

SM enters the room and reach its corner few minutes before 9 : ‘Hi everybody’. Peter: ‘Hi Bob, Mark works from home today’ Bob: ‘Ok no problem. Let’s start with Linda’ Linda: ‘yesterday I fixed the bug in the UI and today I’m going to work with Daniel with the login class’ Bob: ‘Any impediments?’ Linda: ‘No,not so far’ Bob: ‘Great thank you. Amy please’

Amy: ‘Yesterday I had few meetings and I implemented the class for the password. The license of TFS is going to expire in 2 days although’ Bob: ‘any other impediments?’ Amy: ‘No’ Bob: ‘Great thank you..’ Bob asked everybody to tell what they did and what they were going to do today and they all answered his questions. This was the last team member: Bob: ‘Robert please’ Robert: ‘Yes yesterday I worked with Mark and today I’m going to complete the US08. No impediments’ Bob: ‘Great thank you everybody, have a good work’. The meeting lasted 10min.

Anything wrong with this? What? There are few issues here but before reading on please try to figure out yourself. If you do it you’ll probably find that it worth the time. Ready?

1. Mark was not in, but he is a team member and need to participate to this meeting, therefore Bob should have called him before starting the meeting. SkyPe, Lync or whatever tool the company have, should be used to connect him to the rest of the team. A USB speaker equipped with microphone is usually all you need to do this. 2. Amy has a potential impediment (TFS) which is going to hit her productivity in few days. This need immediate attention and Bob should remember to escalate this issue to the CTO or the administrator to ensure the issue is resolved in time. 3. Robert worked with Mark but he didn’t say on what. Moreover having Mark on the line could have helped Bob to find out more on this. US05 may not have the highest priority but Tom is not present to verify that. The PO is the one who gives directions to the Team and if he was present during the Daily Scrum he could have given his voice about this.

Bob can use his diary during the meeting to note down important issues that need to be escalated. All other issues need not to be written down, why? Because the team is self-organizing and need to find its own way to resolve the internal issues. If this do not happen in few days then Bob will need to facilitate the communication to make sure this happen. This can be done at the end of the Daily Scrum by suggesting a solution to the team members like involving everybody (including those who works from home) during any internal meeting they do. The team members need to

grow from forming to storming to norming and finally to performing as a team not just as single individuals working in the same room.

Review Meeting This meeting gives the opportunity to the team to show a live demo of a potentially shippable product to the audience. In this case a live demo is needed, no power point presentations or prototypes and wireframes, just the live product. The meeting starts at 9.00 and the actors are the same as before except for Carlos that joined the team recently. Bob entered the room few min before but nobody was there. At 9.03 Peter came in with his diary. Bob waited till 9.15 when one half the people were in the room, then he asked Peter to find out about the missing ones. Peter: ‘Daniel is gone for a quick smoke but he’ll be here in a minute, he said’ At 9.20 Bob started although Lisa was still missing: ‘Hi everybody, today we’ve the Review followed by the Retrospective meeting’. Daniel: ‘where is Lisa?’ Tom (PO): ‘She is off today’ Bob: ‘OK, so we start with the demo now. Robert can you please show us what you’ve done in this Sprint?’ Robert connected his laptop to the projector and navigated through the webpage showing what they did. At the end of his demo Bob asked the PO whether he was satisfied with the demo.

Tom: ‘Yes, fine’ he said. Bob: ‘OK, anybody comments here?’ Everybody was fine with the demo and Bob said they were now going to move to the Retrospective.

Anything wrong with this? There are few issues here but before reading on, please try to figure out yourself.

1. This is easy, the meeting did not start in time. 20min are too much and unless all the people are present any meeting would not be effective. Waiting so much for the missing ones is only encouraging the present ones to get late the next time. Therefore the next

time, PO or anyone else should help getting everybody in the room few min before the

meeting starts. Po should also have told Bob that Lisa was off and Daniel should have not gone for smoking, surely not at that time. Once started, Bob would have better requested the audience, politely, to get in time for the next meeting as this way they wasted everybody’s time. 2. Tom didn’t ask a single question during the meeting and usually there are 2 reasons for that: a) The demo was boring and he was just doing something else, b) the demo was really nice and needed no additional questions. Usually option a) has more probabilities to occur therefore is always good make sure have their notebook, smartphone and whatever switched off during these meetings to avoid distractions. 3. QA did not ask a question either. What about UAT and OAT discussed earlier in this book? Did anybody care to check if all the business requirements were really mapped to the US? (Traceability Matrix) 4. Have been all the US developed? If not what shall we do with the unfinished ones? PO should have checked that the US completed were done as per the definition of ‘Done’. Any US not passing that definition, should have been moved back to the product backlog and completed in the next Sprint.

Retrospective The purpose of this meeting is to understand how the team performed during the current Sprint and if any issues are there. It’s quite important that line management do not participate to this meeting. The purpose is to let the people talk freely without being intimidated by the higher management. PO and SM are just part of the team without authority over the members and therefore this is the best way to inspire a relaxed atmosphere and achieve a free talk. The participants are the same as before. Bob started by drawing the StarFish on the wallboard. Bob: ‘OK, what do you think we should keep the same? One minute from now’ The members started writing on their post-it then Bob collected their comments and stick them on the wallboard. Bob went through the 5 areas (see the StarFish technique) then asked the team to group each post-it and to vote them. Each member voted up to 2 times by signing the post-it (even twice) with a marker.

Most of the comments were about poor requirements. Devs didn’t get proper requirements because the acceptance criteria did not help much to figure out how to start coding that particular US. They wasted a significant amount of time by asking UDX and PO how to develop those US and that was the main reason for bugs and few unfinished US. At the end Bob wrote down the outcome on his diary, just the top important points voted by the members and closed the meeting; he felt the people were not very happy with the outcome and he didn’t want to waste their time further.

Anything wrong with this? There are few issues here but before reading on please try to figure out yourself.

1. Carlos was a new developer and first of all Bob should have checked with him whether he was familiar or not with Scrum, to understand what they were going to do. Granted. 2. StarFish is a good template to avoid missing any important point, but there was no discussion at all at the end of this meeting and this is not good for a retrospective. To stimulate the audience I normally ask 3 Open questions: what we did wrong, what we did well and what is the main open issue? These adds up to the StarFish outcome and Bob should note down all the answers as well for the MOM (minutes of meeting) to be sent at the end of the meeting. 3. To save time Bob could have took a picture of the wallboard from his smartphone, but the discussion need to be started. 4. Poor requirements and acceptance criteria (they’re part of the US) may be caused by several factors. A common one is the team ‘expecting’ clear and detailed requirements before they can code properly. This is a wrong attitude and anti-Agile. The US is made by 3 parts: Card, Conversation and Confirmation. The Card contain the title of the US, priority and story points. The Conversation is nothing but the discussion with the team about the US and how it has been conceived by PO and SH, and the Confirmation is the resulting acceptance criteria

on which the team agreed upon. Without Conversation there cannot be a good Confirmation and therefore no clear requirements for Devs. This process has to be done during the Planning but here we can see the results of that missing part.

Planning Bob sent the invitations to the team and he checked that all the relevant documentation was included in the mail. In an ideal world the team should have some time to explore the new US that will be discussed during the meeting. This means that for a one week Sprint Bob should send the invitation for the meeting by Thursday, say 2pm so that the Team will have Thursday afternoon to look at the new US. Another point is: when shall we do all these meetings to minimize the interruptions? I found that for one week Sprint we could do all the 3 meetings in sequence (Review, Retro and Planning) in less than 2hrs. This was very convenient for all but of course UXD, PO and SM need to work hard to get things ready in time.

During the planning PO shows the US to the rest of the Team. He previously discussed them with the SH and loaded into the system (TFS, see later). The main outcome of this meeting is as follows:

1. Discuss the new US (Conversation) 2. Confirm priorities (PO) 3. Refine the Acceptance Criteria 4. Estimate the US 5. Commit them to the Sprint backlog 6. Update the system (TFS)

Most of the work is described by PO whereas SM is needed to estimate, conduct the meeting and prepare the MOM. SM should note down anything that need to be resolved and who’s supposed to do what. Ultimately this need to be included in the MOM. In general the purpose of the MOM is to ensure SM and the rest of the

Team are all on the same page and have clearly understood what need to be done.

Let’s start. Bob enters the room: ‘Good morning everyone. Today we’re going to plan for the next Sprint. Have you seen the new US posted on the system?’ Robert: ‘Yes I’ve seen them but some acceptance criteria (AC) are just a copy and paste from the previous Sprint. Requirements are not very clear.’ Tom: ‘where is Mark?’ Linda: ‘he works from home today’. Bob: ‘All right I’ll call him now with Skype’ Mark joined the team and Bob shared his desktop with him. Then Bob opened the US01 and showed its AC. Bob: ‘what is not clear with this US?’ Robert exposed his doubts, then Daniel added his own comments on top of that. Tom answered all their questions and they agreed to estimate. Bob: ‘we’ll now if you all agree we’ll try to estimate US01, are you ready?’ Bob used the ‘poker method’ where all team members were supposed to show their fingers when Bob counted to 3. Bob: ‘One , two, three’. Most of the members showed 4 , others chose 3. Bob: ‘Fine, now please find consensus’ They all agreed on 4 and the estimation went on the same way for all the US.

Anything wrong with this? There are few issues, sure but before reading on please try to figure out yourself.

1. Bob didn’t know about Mark working from home. Nothing terrible about it, just a minor issue but nice to check it the next time.

2. Robert raised an important point sometimes overlooked in such meetings and it showed up that the whole purpose of the Planning was probably missed by many. Initially SH write down the high-level features (business requirements) they want to implement in the next Sprint. Then PO translate them into functional requirements (US) and he try to figure out the AC for them. Notice that PO must know very well the product to do that. The next step is a refinement of those US between SH, UXD & PO. Usually UXD interact with the Team (usually the front-end developers) in order to get the final prototype for the US. Up to here there is nothing terribly wrong with the process, the main point raised by Robert can be splitted in two parts. a) He said the AC were inaccurate or just copied from the previous Sprint and PO is responsible for this. PO need to improve on this and write better AC the next time, but this is only half the story. 3. b) Robert, and probably most of the Devs intended the Planning where SH & PO had to give them the correct requirements before they can proceed on coding them. This is wrong and anti-agile and shows that the Conversation part of the US was missing from this meeting. It’s true that they all discussed the US but the general feeling was: “As a developer I’m waiting for the requirements” and “As a PO I need to write clear AC before the Planning starts so that Devs can estimate”. Bad, the point is that Devs should not ‘passively’ wait for the requirements. They’re ‘actively’ contributing to write the US (and the associated AC). During the Planning the US need not to be completed and fully detailed, and they cannot be since Devs perspective is missing. US are not a contract (like Use Cases), they are a work in progress and can be changed during the Planning or deleted and new US can also be added in the agile concept of ‘embracing changes’. Defining a US is a collaborative work of all the Team, not just the PO and SHs.

Before the meeting completed SM asks the Team for the Sprint Goal. This is a simple sentence stating the purpose of the Sprint and is useful for the team members to remember what is the focus and an easy way for external SHs to understand what the team is doing. When the meeting is over, SM needs to write the MOM. This would only take 10min if he noted down all the important points during the

meeting. Here is an example of MOM sent by email to all the participants: Hi all Thanks for attending this meeting. Please have below the main points discussed today: Review The Team performed the live demo for 90% of the Sprint. This week was shorter because of the holi- days and UXD came back only Wed but the work was almost completed. We also discussed few issues re- lated to UX & JS (Javascript)

Retro(current Sprint) The Team is moving from Normingto Performing. They need to better understand the value of what they develop and to take the responsibility to in- volve all Team members especially for the API ar- chitecture.

SP tot. 17 (*) Work Done : 90% approx

Start Doing:Feedback over deployed features & US (*) , Kanban board responsibility. Do More:Inter Team Comms (****), steady workflow (**), update QA after changes (**), Code review (**), Deploy (**) Keep Same: Unit Testing Do Less: none Stop Doing: none

•What we did well : quality •What we did wrong: poor communication •What is the main open issue: poor team culture (not Performing as a team yet)

Planning(Next Sprint ) PO updated the US after the Conversation, and the Team estimated the remaining work for the unfinished and the new US. Next Wednesday we’ll meet again to estimate the US04 since the design was missing at this time.

Here are the new Tasks which could also be considered for the next Sprint:

QA: Implement Selenium (Browser Automation) Stored Procedure for Supplier Search Permissions for Suppliers Bugs Fixing Deactivate Users Add Page Footer Public URL

Sprint Goal(Current Sprint ) “Visitor Login and Permissions”

Actions PO: please move unfinished Tasks from current Sprint to the next one Daniel: please make sure the new TFS license is activated by next Tue PS, Linda: please provide prototype for the new US and attach the latest version in TFS > User Story >Storyboards Team: please involve all members during tech dis- cussions & Lync Mark when working from home. All the unfinished US will be completed by Wed before the planning meeting.

* SP=Story Point (measure the effort for each Task), US= User Stories

XP - Scale Teams

Scaling Scrum (Scrum of Scrums) or XP makes little difference since both Agile SDLCs use a comparable number of team members, and both adopt similar techniques to get things done. There are several ways to scale a team as we’ve discussed previously. In this example we’ll see the hierarchical approach proposed by Rumpe & Scholtz (2003). XP is a code-oriented, light-weight software engineering methodology, suited merely for small-sized teams who develop software that relies on vague or rapidly changing requirements. [1] XP is designed for a single small team of less than a dozen team members, therefore, it has its problems to scale up for larger projects. However there is still a number of areas, where hundreds of developers work on producing one single software product. Eg, the telecommunication industry is under enormous pressure to add and improve functionality of their products.

The main obstacles against scaling up of XP are lack of documentation (therefore the exponential increase of necessary communication between developers), lack of stable interfaces and stable requirements. Consequently, scaling up of XP will probably be indispensable in order to adopt methodical practices from other methodologies. There are four basic activities in the XP approach: coding, testing, listening and designing. As a light-weight methodology XP explicitly abandons any explicit activity of documenting and analyzing the system. Analysis remains an implicit, but continuous activity that happens in everyday communication with the customer. Documentation is explicitly discouraged. [1]

The hierarchical approach starts from the XP approach and builds a hierarchical structure upon it. The advantages of this approach have partly been discussed before: While largely retaining a light-weight methodology, it becomes feasible to structure larger projects into a bunch of smaller XP projects that still have a common target to achieve. The approach basically consists of two important elements:

On the top-level we set up a goal-oriented project management (called steering committee) that organizes the high-level structure Each of the localized tasks are solved by their own XP teams.



The 5 major principles of the hierarchical approach are a combination and adaptation of corresponding XP principles:

• Customer participation: the solution is worked out with the customer/employee to reach a high acceptance. This is in particular important for the customers to accept the resulting new software system / company structure. • The whole system is divided up into subsystems with a lean and crisp interface. The inputs and outputs, namely the data structures and the information flow between the subsystems need to be clearly defined. Subsystems are implemented respectively evolved through XP teams. • Each XP team has as target its associated subsystem, thus contributing to the main target, namely the development of the whole system. • The worked out software solutions will be improved like an incremental process to be successful very quickly. In a number of releases the team explores and extends the desired

system functionality.

• The hierarchical approach needs to be well organized with a project team and a steering committee followed by a Genesis program. The steering committee is an ideal place to develop and maintain the common system metaphor. This cannot be decentralized in several XP teams, but needs a central coordination.

By organizing the software development process in a hierarchical manner the focus is given on one common target and a structured process to reach this goal is used. The involvement of the employees will lead to a high acceptance for the solution. Ideally XP project teams are defined in a similar way as company departments are. As we’ve already discussed before, one of the main issues when scaling a team is communication and Brook’s law stated that by increasing the number of team members above a certain threshold the project get stuck with communication issues.

In practical the end date for a project cannot be decreased below a certain point by just adding project members. If this number exceeds a certain point, the communication overhead takes over.



To improve the communication the hierarchical model makes use of a moderator among the different teams. The moderator is a servant-leader and increases the project efficiency with a number of advantages:

• Communication gets more effective and time efficient.

• All, even “difficult” project member are involved.

• The moderator has an considerable influence on time economy and target achievement.

Team work plays an essential role in the steering committee as well as in the XP subprojects, where often development tasks are rather complex, and capacity and expertise, respectively of small project groups are too limited to guarantee the overall project success. Moderation makes an essential contribution so that defined project targets can be achieved within the optimal time with the optimal level of effort, creativity, and engagement.

Moderation in XP projects aims at involving all project members

as efficiently as possible in all project phases. This ensures that the members’ ideas and energies can be bundled up and therefore optimally brought into the project. As a consequence, all team members pull together.

• all project members are concentrated on the working content, only • all results get transparent

• the cooperation, team spirit and therefore, the overall company culture improves • the motivation of each XP project member increases

XP – success points One of the most innovative aspects of XP is pair programming which a kind of continuous (extreme) code review. XP assumes that people work best in pairs so that they complement each other’s strengths and weaknesses and so that knowledge can be spread between members of the team. The benefits as far as design, bug elimination, etc., can make two programmers at one computer be much more effective than they would be if they were each at separate computers. Here is an excerpt from a book report on The Costs and Benefits of Pair Programming (Laurie Williams & Alstair Cockburn), which talks about the benefits of pair programming.

Economics. A recent controlled experiment found only a small development cost for adding the second person. However, the resulting code also had fewer defects. The defect removal savings should more than offsets the development cost increase.

Satisfaction. People working in pairs found the experience more enjoyable than working alone.

Design quality. The study also found that the pairs produced shorter

programs than their solo peers, indicating superior designs. Interviewees made the same comments.

Continuous Reviews. Pair programming’s shoulder-to-shoulder technique serves as a continual design and code review, leading to most efficient defect removal rates.

Problem solving. Interview participants constantly refer to the team’s ability to solve “impossible” problems faster.

Learning. Pair programmers repeatedly cite how much they learn from each other.

Team Building and Communication. Interview participants describe that people learn to discuss and work together. This improves team communication and effectiveness.

Staff and Project Management. Since multiple people have familiarity with each piece of code, pair programming reduces staff-loss risk. Pairs and roles are changed often so that people can get the benefit of what each other has learned, and get a good feel for all the different areas of the system. [2]

Sometimes we’ve the impression that Agile means speed and especially XP where coding is everything. However we need to keep in mind that writing more code will not necessarily improve the productivity of your team and XP activities : code, test, listen & design can be significantly improved by adopting the following points. XP doesn’t necessarily require black-belt experts. It does require a habit of thinking:

• Pair programming doubles the brainpower available during coding, and gives one person in each pair the opportunity to think about strategic, long-term issues. • Energized work acknowledges that developers do their best,

most productive work when they’re energized and motivated.

• An informative workspace gives the whole team more opportunities to notice what’s working well and what isn’t. • Root-cause analysis is a useful tool for identifying the underlying causes of your problems. • Retrospectives provide a way to analyze and improve the entire development process.

Another important aspect, valid for all Agile methodologies is the ubiquitous language. Why it’s needed? Because in any project communication takes approx. 90% of the time and it need to be effective if we want to succeed. This means that our language should be understandable by all. We should be able to explain how the system works the way domain expert understand it. We should avoid programmer jargon, such as the names of design patterns or coding styles. We should make sure our domain expert are able to identify potential problems in the business logic and we should be able to translate business requirements into US which Devs can understand.

Sample project XP approaches its schedule in terms of customer value. The team works on stories phrased from the customer’s point of view and verifiable by customer testing. After each iteration, the iteration demo shows the team’s current progress to stakeholders, allowing them to verify that the results are valuable and to decide whether to continue development. [3]

A friend (Aaron) recently spent a man-month writing 1,500 lines of prototype code that generated $7.8 million in revenue during its first demo. As a graduate student, he interned with a technology company doing research on handwriting recognition with digital pens containing sensors and recording equipment. A customer made an offhand remark

about how useful it might be to use those special pens with printed maps. Suddenly, Aaron had a research assignment. The largest potential customer used an existing software package to send map data to field agents to plan routes and identify waypoints. Aaron modified the pen software to send coordinate information on printed pages. Then he found a way to encode the pen’s necessary calibration data on color laser printouts. The final step was to use the API of the customer’s software to enter special pen events— mark waypoint, identify route, etc. In effect, all of his code merely replaced the clunky mouse-based UI with the act of drawing on a custom-printed map, then docking the pen. A few minutes into the first demo, the customer led the sales rep to the control room for a field exercise. After installing the software and connecting the pen’s dock, the rep handed the pen and a printed map to one of the techs. The tech had never seen the product before and had no training, but he immediately circled an objective on the map and docked the pen. In seconds, the objective appeared on the vehicle displays as well as on the PDAs of the field agents. The customer placed an order for a license and hardware for everyone at the location. That’s business results. [3]

FDD

Despite the many advances in software development, it is not uncommon for projects lasting two or more years to use a function-driven process: from functional specs to design to code to test to deployment. Along the way, some have made minor modifications to the theme, allowing some influence from iterations. Nevertheless, many software projects exceed budget, blow schedule, and deliver something less than desired. As if that weren’t enough pressure, the ever-increasing pace of technological advances makes it less and less likely that a project lasting more than two years will ever succeed. In fact, more and more, we are mentoring projects with total schedules of 90, 120, or 180 days—or perhaps 9, 12, or 18 months. One market- leader we work with considers any project longer than 180 days as

high-risk. Why? Their business changes so rapidly and the supporting technology changes so rapidly that planning nine months out adds risk to the project. [4]

FDD is a model-driven short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two week “design by feature, build by feature” iterations. Staff your project with good people, do whatever it takes to keep them happy, and use simple, well-bounded processes to guide them along the way. Simple, well-defined processes work best. This is the core of FDD which uniquely: [4]

• Uses very small blocks of client-valued functionality, called features • Rather than using format like “the user does this, the system does that” , FDD organizes those little blocks into business- related groupings • Java Modeling in Color with UML

• Focuses developers on producing working results every 2 weeks, • Facilitates inspections

• Provides detailed planning and measurement guidance,

• Promotes concurrent development within each “design by feature, build by feature” increment, • Tracks and reports progress with surprising accuracy, and

• Supports both detailed tracking within a project and higher- level summaries for higher-level clients and management, in business terms.

A feature is a client-valued function that can be implemented in two weeks or less. Features use this template:

the a(n)

Where an object is a person, place, or thing (including roles, moments in time or intervals of time, or catalog-entry-like descriptions). For example,

• Calculate the total of a sale.

• Assess the fulfillment timeliness of a sale.

• Calculate the total purchases by a customer.

A feature set is a grouping of business-related features. We name a feature set this way:

a(n) An example is “making a product sale.”

And we name a major feature set this way: management

An example is “product-sales management.” Consider the following:

We can write feature, feature set and major feature as below:

Features Calculate the total of a sale. Assess the fulfillment timeliness for a sale. Calculate the total purchases by a customer. Calculate the tax for a sale. Assess the current preferences of a customer.

Feature set Making a product sale to a customer

Major feature set Product-sale management

Usually when you take a new methodology (like FDD) and and apply it to real life situations and projects, you need to adapt it to fit with what you are trying to deliver.

Sample Project Let’s assume we want to build ‘BestFit’, an eCommerce web site that utilised a mixture of Kanban and FDD to quickly deliver a new web site in 28 days. [5]

Traditionally, the waterfall approach was to gather all requirements, build the infrastructure, then the code, and finally make the front end. This information gathering and the writing of functional and technical specs can take a long time to complete. Then, when the development begins, the whole spec needed to be delivered before the site could launch. By which time 6 months has passed and requirements may well have changed and what is delivered is not necessarily what the business or the market needs.

FDD tries to get around this by defining the requirements as features, then the SH and the Team prioritize these features into a backlog of work and then Devs deliver these features in the order that offers the most business value.

The pre-requisites for this are:

• The general technical approach needs to be agreed

• Technologies need to be discussed

• Terminology needs to be agreed and basic development

• Testing and live environments need to be created.

Now the main feature of BestFit is to sell items, so the first feature that we need to work on is that “the user needs to be able to buy products on a web page”.

At first, the developers approach could be to start building a database infrastructure that could be used for the whole site. They may also want designs for pages, sorting, pagination, customer and suppliers tables, couriers etc. You need to be careful here as that is not what was required by the feature. All the feature required was for the user to be able to buy products. Nothing else.

So to deliver this feature, we just need a database where products are stored, the html page with some code that would allow a user to buy a product and the payment gateway. For all the rest the administrator will take care. Of course nothing is stopping us to think of a flexible architecture for BestFit (and we should) but no energy should be wasted in developing unwanted features for now. Once complete and tested, the feature can then be released.

The next feature is “the user wants to compare two or more products” and here is where the system shall display multiple products with data retrieved from the database. Again, the developers only needed to work on a code that delivers the feature’s requirement.

Managing Changes What happen if a new feature comes in during the development? In Agile responding to change is more valuable than following a

plan. FDD plans and considers the plan a required part of any project. However, blindly following a plan without being able to adapt and respond to change is a pattern for failure, not a pattern for success. The priority decides which feature should be developed first. Therefore if Devs are working on a feature and a more important request is added, FDD can manage it in the traditional way through a control change management board (CCB) or directly through Class Owners. If the feature is approved, the class owners (working on that feature) must work together as a feature team to implement it. Flexibility and adaptiveness are essential for organizations to survive and Class owners are responsible for all changes related to new features. FDD encourages strong code ownership. The main idea is that every developer knows the owned code and better realizes the consequence of changes.

Jeff De Luca mentioned that FDD may accommodate up to 10% change in project requirements without slipping the deadline. The idea here is that the changing requirements for the software system do not mean that the business itself has changed. Therefore the problem domain should still represent the valid picture of business. The new requirements should not affect the majority of already implemented features.

Devs turnover Since FDD advocates for code ownership, what happen when a developer leaves the company? FDD try to manage this issue in 3 points:

• Sufficient code documentation simplifies understanding somebody else’s code; • Developers know what other people’s code does, since they reviewed the design. • Developers will look at each other’s code during code review;

FDD vs XP Both methodologies successfully utilize iterative development to avoid main weakness of waterfall when errors are discovered at later stage

Both methodologies are lightweight, but XP is lighter: it does not produce code documentation and keeps code review informal.

XP is better suited for the projects with frequently changing or poorly defined user requirements.

FDD is not very good at shooting the moving target. However, when user requirements are rather stable, it offers higher success repeatability than waterfall.

FDD scales better. It has a hierarchy within the development team that allows keeping iteration teams small even when the project team is big.

As a part of the methodology FDD offers progress tracking and reporting capabilities. This comforts managers and makes it more attractive for big companies.

FDD project might be managed manually, but the project management tools reduce the overhead of keeping the database of features and generating the reports. XP does not seem to require any special tools.

FDD is better prepared to work with team where developers’ experience varies. The most experience/productive members become chief programmers. However, in the small team of equally strong developers some recourses may be left under-utilized: author observed the developers be idle while CP prepares list of features for the next iteration.

Both methodologies require discipline and do not replace the need for good manager.

Both methodologies offer some extremely useful techniques that may

be applied in any development methodologies, even in waterfall. The two of my favorites are unit testing and code review. [6]

Credits

[1] Scaling The Management Of XP Projects, Bernhard Rumpe, Peter Scholz. [2] www.codeproject.comWhat Is Extreme Programming (Clifton, Dunlap) [3] O’Reilly The Art of Agile Development [4] Feature-Driven Development, J.De Luca, P.Coad, E. Lefebvre [5]http://www.mike-dixon.com/2012/01/24/a-practical-example-of- feature-drivendevelopment/ [6] Comparing XP and FDD in academic and regulated environments, Serguei Khramtchenko

9. Software Tools Intro Management CRM & Marketing Collaboration Software Development Agile & Scrum

Intro

In this chapter we’ll see some practical tools that could help us implementing Agile and collaborating with others. Many tools are open source and free. The OS we’re targeting here is Windows but many tools are also available under others OS. The tools I’m discussing here may not be the best available in the market and many excellent tools will be also missing. However the followings are what I’ve used and they did their job pretty well so far. They are broadly divided in the following categories:

• Management

• CRM & Marketing

• Collaboration

• Development

• Agile & Scrum

Few tools described here are web-based therefore, before getting into the details of each one, I’ll briefly show you how to install a web server on your system. The web server we’re going to use is XAMPP (Apache, MySQL, PHP).

XAMPP is quite popular if you want to have your own web server running PHP applications without uploading your PHP files on a Linux server. This tool is regularly updated with the latest version of PHP and it’s easy to install and run.

1. Download XAMPP from the following link: https://www.apachefriends.org/download.html#641

2. Run the installer and select the components you need to install. For simplicity leave the default directory as C:\XAMPP and do not install Bitnami.





3. When the installation completes, open the control panel and start the web server Apache and PHP as below:





Now that the web server and PHP are working, you can run any PHP application compatible with the PHP version installed (for XAMPP 1.8.3 is PHP 5.5.11). Be careful that not all PHP applications support the latest version of PHP. Some of them just work with PHP 5.3 or below.

If port 8080 is already taken, you need to change it in the config file of Apache (from the control panel).

To test XAMPP just open your browser on the following link: http://www.localhost.com/xampp/

The main screen will shows up. From there you can click on phpMyAdmin which is a PHP application used to manage the database. To run most of the PHP applications, usually you need first to create a database. Let’s call myApp my PHP application (ie, Collabtive), you can create a new database Collabtive as below:

1. Goto http://www.localhost.com/xampp/ 2. Click phpMyAdmin and create the database ‘Collabtive’ (any name)

Next to run Collabtive you’ll need to:

1. download it from the website 2. unzip into C:\xampp\htdocs\collabtive 3. open your browser and point to: http://www.localhost.com/collabtive/ 4. finally just follows the steps to install it.

Management

We’ll now see few tools which may help you managing your projects.

HRLocker This software allows you to manage your HR department with features including: Time Off, Time On, HR Documents, Reports, Timesheets. HR Locker offers businesses a cost effective way to manage human resources related tasks. Users can schedule time off for employees, including annual leave and absences. The company’s employees can submit requests through the HR Locker system. When this happens, the manager receives an email so they can review the request and approve or deny it. Users can review their annual leave allowances, days taken to date, days carried over, days booked ahead and remaining balances at any time. HR Locker can also handle human resources documents, with click to publish functionality. The application supplies its user with a safe place to store important company documents which can only by seen by the user and any employees they choose to give access to. HR Locker include time sheet capabilities as well as reporting features.

HRLocker is cloud based (SaaS) and here are few scrshots that can help you better understand the application.









Time Zone Managing distributed teams can be challenging especially when the time zone is significantly different from the local time. Fortunately there are few tools that can help on this:

timeanddate.com First you select the cities where you’re participants will be attending the meeting, then the tools will show you a feasible schedule.







worldtimebuddy.com With this tools you get in few clicks the feasible time to arrange a meeting in different locations.



Office 365 This is a subscription-based online office and software plus services suite which offers access to various services and software built around the Microsoft Office platform. In December 2011, Microsoft announced that the Office 365 platform was now compliant with the ISO/IEC 27001 security standards, the European Union’s Data Protection Directive (through the signing of model clauses), and the Health Insurance Portability and Accountability Act for health care environments in the United States. [2]



PasswordState Passwordstate is a web-based solution for secure management of passwords, for both individuals and teams of people. 256bit AES data encryption, code obfuscation and enterprise scalability makes it the Enterprise Password Manager of choice. Main features include the followings:

Track Shared Password Lists Password History and Comparison, Real-Time Password Change Notification, Import and Export Passwords, Secure Access to Shared Password Lists, Expiring Passwords Management and Password Auditing.

Security Administration End-to-end Auditing, Customised Email Templates, Shared Password List Reporting, Password Strength Policy, 2nd Level Password Protection, Multiple Active Directory Domain Support and User Acceptance Policy.

Data Protection and Security - Ensures the integrity of your sensitive data.

Encryption and Obfuscation, Unique Initialisation Vector, Automatic Logout Period, Integrated Windows Authentication and Optional Two- Factor Authentication for Administration Area.

MSProject Is a project management software program, developed and sold by Microsoft, which is designed to assist a project manager in developing a plan, assigning resources to tasks, tracking progress, managing the budget, and analyzing workloads. Microsoft Project was the company’s third Microsoft Windows-based application, and within a couple of years of its introduction it became the dominant PC-based project management software. [3] This software can be used for traditional (waterfall or FDD) project management although there are few templates for Scrum (but not really practical in my view).

EPIM Essential Personal Information Manager lets you manage appointments, tasks, notes, contacts, password entries and email messages across multiple devices and cloud applications. You can download and use the community edition for free. Very useful for personal and office management.



CRM & Marketing

Marketo This solution is provided on a subscription basis in three editions, including Spark, tailored specifically for small businesses. Products include software for lead management marketing automation, sales reps, social marketing and marketing analytics.

Marketing automation refers to software platforms and technologies

designed for marketing departments and organizations to more effectively market on multiple channels online (such as email, social media, websites, etc.) and automate repetitive tasks. Marketing departments, consultants and part-time marketing employees benefit by specifying criteria and outcomes for tasks and processes which are then interpreted, stored and executed by software, which increases efficiency and reduces human error. Originally focused on email marketing automation, marketing automation refers to a broad range of automation and analytic tools for marketing especially inbound marketing. Marketing Automation platforms are used as a hosted or web-based solution, and no software installation is required by a customer. The use of a marketing automation platform is to streamline sales and marketing organizations by replacing high-touch, repetitive manual processes with automated solutions. [4]

Salesforce Salesforce.com Inc. is a global cloud computing company headquartered in San Francisco, California. It’s best known for its customer relationship management (CRM) product, Salesforce and is currently ranked the most innovative company in America by Forbes magazine, as well as number 7 in Fortune magazine’s 100 Best Companies to Work For in 2014. The main features include the followings:

• Mobile

• Contact management

• Opportunity management

• Document management

• Analytics

• Marketing

• Email integration

• Forecasting

• Workflow





SugarCRM Is a software company based in Cupertino, California. It produces the web application SugarCRM, which is a customer relationship management (CRM) system that is available in both open-source and Commercial open-source applications. In February 2014, SugarCRM announced that they would no longer be releasing new open source versions of their Community Edition application and this would now be a bug fix only application. [5]

Collaboration

There are several good tools for online collaboration and they are essential to manage distributed teams. Here are listed few of them.

Microsoft Lync This is an instant messaging clients used with Microsoft Lync Server or Lync Online available with Microsoft Office 365. They are replacements for Windows Messenger, which was used with Microsoft Exchange Server. Microsoft Lync is an enterprise software; unlike Windows Live Messenger (and later on Skype), it has a different feature set that is targeted toward corporate environments. Basic features of Lync include:

Instant messaging Voice Over IP Video conferencing inside the client software



SmartSheet Is an online project management, productivity and team collaboration software as a service application based in Bellevue, Washington.

Its online project management tool works like familiar spreadsheets, but with additional functionality including cloud-capabilities for sharing, attachments, integration with file storage services and Gantt charts. Smartsheet combines functions found in Microsoft Excel, Project, Access, and Sharepoint into a single application. [6]



SkyPe Skype is a freemium voice-over-IP service and instant messaging client, currently developed by the Microsoft Skype Division. The name was derived from “sky” and “peer”. Skype was first released in August 2003. It was created by Janus Friis (Denmark) and Niklas Zennström (Sweden) in cooperation with Ahti Heinla, Priit Kasesalu, and Jaan Tallinn (Estonia), who supplied the backend which was also used in Kazaa. Skype had 663 million registered users as of the end of 2010. It was bought by Microsoft in 2011 for $8.5 billion. [7] A freemium application is a pricing strategy by which a product or service (typically a digital offering such as software, media, games or web services) is provided free of charge, but money (premium) is charged for proprietary features, functionality, or virtual goods.

XLite X-Lite is a proprietary freeware VoIP soft phone that uses the Session Initiation Protocol. X-Lite is developed by CounterPath Corporation, a Vancouver based software company. In September 2010, CounterPath released X-Lite 4.0. It incorporates many of the features from X-Lite 3.0 but has a redesigned user interface based on CounterPath’s Bria softphone.





UserVoice Is a software as a service (SaaS) company founded by Richard White and Lance Ivy in 2007 (later joined by Marcus Nelson and Scott Rutherford) that creates customer engagement tools. UserVoice Feedback is a tool for collecting and prioritize feedback from customers. UserVoice Helpdesk is a support tool which allows companies to track and respond to customer issues. UserVoice Full Service combines both the UserVoice Feedback and UserVoice Helpdesk into one integrated product. [8]

Software Development

Software development is of course everything for a software project and there are a huge number of tools available on the market. Here we’ll see only few of the most popular for Windows.

NetBeans Is an integrated development environment (IDE) for developing primarily with Java, but also with other languages, in particular PHP, C/C++, and HTML5. It is also an application platform framework for Java desktop applications and others. The NetBeans IDE is written in Java and can run on Windows, OS X, Linux, Solaris and other platforms supporting a compatible JVM and is developed by Oracle Corporation. The NetBeans Platform allows applications to be developed from a set of modular software components called modules. Applications based on the NetBeans Platform (including the NetBeans IDE itself) can be extended by third party developers. [8]

Eclipse Is an integrated development environment (IDE) developed by Eclipse Foundation and similar to NetBeans. It contains a base workspace and an extensible plug-in system for customizing the environment. Written mostly in Java, Eclipse can be used to develop applications. By means of various plug-ins, Eclipse may also be used to develop applications in other programming languages: Ada, ABAP, C, C++, COBOL, Fortran, Haskell, JavaScript, Lasso, Natural, Perl, PHP, Prolog, Python, R, Ruby (including Ruby on Rails framework), Scala, Clojure, Groovy, Scheme, and Erlang. It can also be used to develop packages for the software Mathematica. Development environments include the Eclipse Java development tools (JDT) for Java and Scala, Eclipse CDT for C/ C++ and Eclipse PDT for PHP, among others. [9]



Visual Paradigm for UML Is a UML CASE Tool supporting UML 2, SysML and Business Process Modeling Notation (BPMN) from the Object Management Group (OMG). In addition to modeling support, it provides report generation and code engineering capabilities including code generation. It can reverse engineer diagrams from code, and provide round-trip engineering for various programming languages. The community edition of VP can be particularly useful to draw UML Use Cases and Activity diagrams.

Doxygen Is a documentation generator, a tool for writing software reference documentation. The documentation is written within code, and is thus relatively easy to keep up to date. Doxygen can cross reference documentation and code, so that the reader of a document can easily refer to the actual code. Doxygen supports multiple programming languages, in particular C++, C, C#, Objective-C, Java, Python, IDL, VHDL, Fortran and PHP. Doxygen is free software, released under the terms of the GNU General Public License. [10]

Jenkins Is an open source continuous integration (CI) tool written in Java. The project was forked from Hudson after a dispute with Oracle. Jenkins provides CI services for software development. It is a server- based system running in a servlet container such as Apache Tomcat. It supports SCM tools including AccuRev, CVS, Subversion, Git, Mercurial, Perforce, Clearcase and RTC, and can execute Apache Ant and Apache Maven based projects as well as arbitrary shell scripts and Windows batch commands. Released under the MIT License, Jenkins is free software.



Visual Studio Microsoft Visual Studio is an integrated development environment (IDE) from Microsoft. It is used to develop computer programs for Microsoft Windows superfamily of operating systems, as well as web sites, web applications and web services. Visual Studio uses Microsoft software development platforms such as Windows API, Windows Forms, Windows Presentation Foundation, Windows Store and Microsoft Silverlight. It can produce both native code and managed code.

Visual Studio includes a code editor supporting IntelliSense as well as code refactoring. The integrated debugger works both as a source-level debugger and a machine-level debugger. Other built-in tools include a forms designer for building GUI applications, web designer, class designer, and database schema designer. It accepts plug-ins that enhance the functionality at almost every level—including adding support for sourcecontrol systems (like Subversion) and adding new toolsets like editors and visual designers for domain-specific languages or toolsets

for other aspects of the software development lifecycle (like the Team Foundation Server client: Team Explorer). [11]





Architecture Explorer represents structures as nodes and relationships as links. As you browse, Architecture Explorer displays nodes in successive columns. The first column shows the domains and views that you can browse. When you select a domain and a view, Architecture Explorer shows you the available nodes in that view. On the Architecture menu, point to Windows, and then click Architecture Explorer.

The Code Map feature of Visual Studio 2012 lets you visualize your code to more easily navigate its complexities. This allows you to point and click your way through complex code hierarchy as opposed to searching through countless lines of code. Once your instance of Visual Studio 2012 is updated, the Code Map feature will be available in a context menu when inside your code.

To get a visual overview of dependencies across your code, you can create dependency graphs in Visual Studio Ultimate. (DGML) On the Architecture menu, choose Generate Dependency Graph, For Solution. From there you can navigate dependencies and drill down to more detailed information. Simply hovering over an item will give detailed information about that item. Hovering over a link will also provide additional information about the type of link (such as a method call or reference). Clicking the expand button will update the graph to show the next level of detail.



To visualize how the code implements a particular method, you can create a sequence diagram from a method. The sequence diagram shows the interaction between objects as a series of lifelines and messages. Lifelines represent instances of objects, and messages represent method calls between those objects. You can generate sequence diagrams from Visual C# .NET or Visual Basic .NET code, but not from projects that share code across multiple apps. A generated sequence diagram shows elements similar to those on a UML sequence diagram.

In Visual Studio, open the code file that contains the method definition. Open the shortcut menu anywhere in the method definition, and then choose Generate Sequence Diagram.





Codemaid There are many tools for Visual Studio, and Codemaid is just one of them. Codemaid is an open source visual studio extension to cleanup, dig through and simplify our C#, C++, F#, VB, XAML, XML, ASP, HTML, CSS, LESS, JavaScript and TypeScript coding. It can do Code Cleaning, Code Digging, Finding, Joining etc..

Code cleanup can run automatically on save, or on demand. It can run on an individual file, all open files, any selection in the solution explorer, or the entire solution.





Team Foundation Server (TFS) TFS is a Microsoft product which provides source code management (either via Team Foundation Version Control or Git), reporting,

requirements management, project management (for both agile software development and waterfall teams), automated builds, lab management, testing and release management capabilities. It covers the entire Application Lifecycle Management. TFS can be used as a back end to numerous integrated development environments but is designed to provide the most benefit by serving as the back end to Microsoft Visual Studio or Eclipse (on Windows and non-Windows platforms). TFS includes Process Templates for the Microsoft Solutions Framework for Agile and CMMI and Scrum. Teams can choose to use a built-in template or one of the many templates available for use created by third parties. Process templates can be customized using the Process Template Editor which is part of the Power Tools. [12]



Continuous integration is the process of generating a build whenever a programmer checks code into the source control server. When you use this process, it is a good idea to have a dedicated build server where you can synchronize and compile the sources, and run unit tests.

Software development life cycle processes evolved over time. Development teams realized the importance of having periodic builds. It started with a weekly build. As the benefits of frequent builds became more obvious, organizations wanted more builds. And now we have continuous integration. Many organizations still count on them to get a

formal, reliable build. Team Foundation Build is the build automation tool in Visual Studio Team System. Built on top of MSBuild, Team Foundation Build integrates with other Visual Studio Team System tools such as source control, work item tracking, and test execution. This provides an end-to- end build process. Team Foundation Build does not provide continuous integration out of the box, but you can easily customize it to do so.





Microsoft Test Manager (MTM) Using Microsoft Test Manager you can plan, manage, and execute both manual and exploratory tests. You can also automate your manual tests once they are stabilized. While you are performing manual and exploratory tests, you can log bugs. The bug will contain a trace of your recent actions, a snapshot of the state of the system, and a copy of any notes you made while exploring the system. You can record your actions in the test case, so that they can be played back later.

You can also use Microsoft Test Manager to set up and manage lab machines. You can configure a virtual lab in which to install a distributed system, and link that lab to the test plan. Whenever you need to repeat tests, for example when you want to publish a change to your system, the lab can be reconfigured automatically.

You can create and manage lab environments with the Lab Management features of Microsoft Test Manager. A lab environment is a collection of virtual and physical machines, which you can use to develop and test applications. A lab environment can contain multiple roles needed to test multi-tiered applications, such as workstations, web servers, and database servers. In addition, you can use a build-deploy-test workflow with your lab environment to automate the process of building, deploying, and running automated tests on your application. Connect Microsoft Test Manager with your team project, and then open Lab Center. After you set up lab management, you can create lab environments and run tests in them.

NUnit Is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current production release, version 2.6, is the seventh major release of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages.



TestDriven.Net makes it easy to run unit tests with a single click, anywhere in your Visual Studio solutions. It supports all versions of Microsoft Visual Studio and it integrates with the best .NET development tools (including NUnit).



SpecFlow aims at bridging the communication gap between domain experts and developers by binding business readable behavior specifications and examples to the underlying implementation. It provide a pragmatic and frictionless approach to Specification-By- Example for .NET projects. SpecFlow also supports the concepts of Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD), which are often used synonymously with Specification-By-Example. SpecFlow also support NUnit.

1. Add new feature file to the project 2. Describe the first scenario of your application 3. Generate step definition skeletons 4. Implement automation & application logic until the test is green







Everything Is a proprietary freeware Windows desktop search engine that can very rapidly find files and folders by name on an NTFS volume. On October 30, 2009, Everything was ranked #857 of the 1,757 applications used by the 70,000 users of Wakoopa, making it more widely used than the WinZip archive utility. When Everything first runs, it creates an index of the names of every file and folder on the volume from file metadata in the NTFS Master File Table (it doesn’t scan all the files on the HardDisk). Because Everything doesn’t index content and relies on the NTFS change journal to filter file updates, the only file system activity it requires is updating its index, and it uses very little memory and processor time to provide its service. However, because it relies on the change journal, Everything can only search NTFS volumes.



Agile & Scrum

Here we’ll have a look at some tools dedicated to Agile and Scrum, some are open source others have a commercial proprietary license.

Scrumwise You can use Scrumwise to organize Scrum teams, or teams of software or application developers. Scrum is a method of software development using agile, incremental management techniques. The aim is to quickly and easily develop and fine-tune high quality software or applications. Scrum divides the team and assigns different roles as it works toward incremental advances in development. By industry standards, Scrumwise is a basic tool and cannot handle high-end development projects, as the managers themselves state.





JIRA Is a proprietary issue tracking product, developed by Atlassian. It provides bug tracking, issue tracking, and project management functions. The product name, JIRA, is not an acronym, but a truncation of Gojira, the Japanese name for Godzilla. JIRA integrates with source control programs such as Subversion,CVS, Git, Clearcase, Team Foundation Server, Mercurial, and Perforce. It ships with various translations including English, Japanese, German, French, and Spanish.

JIRA’s flexible plugin architecture spawned a large number of

integrations developed by the JIRA development community and third parties, including IDEs like Eclipse and IntelliJ IDEA using the Atlassian IDE Connector. The JIRA API allows developers to integrate third-party applications into JIRA. [13]



Asana Asana is a web and mobile application designed to enable teamwork without email. It was founded by Facebook co-founder Dustin Moskovitz and Justin Rosenstein, who both worked on improving the productivity of employees at Facebook. Asana is a teamwork communication manager. According to a New York Times article and someone briefed on the funding, the investors valued the company at $280 million. As of March 2014, the software product is used by tens of thousands of teams, across all industries and in every continent except Antarctica. Companies that use Asana include Airbnb, Dropbox, Disqus, Foursquare, Pinterest, Stripe, and Uber. [14]





Trello Is a free web-based project management application made by Fog Creek Software. Trello uses a paradigm for managing projects known as kanban, a method that had originally been popularized by Toyota in the 1980s for supply chain management. Projects are represented by

boards, which contain lists (corresponding to task lists). Lists contain cards (corresponding to tasks). Cards are supposed to progress from one list to the next (via drag-and-drop), for instance mirroring the flow of a feature from idea to implementation. Users can be assigned to cards. Users and boards can be grouped into organizations. Trello operates a freemium business model, as well as being crosssubsidized by other Fog Creek Software products. A basic service is provided free of charge, though a Business Class paid-for service was launched in 2013. [15]





Fengoffice Feng Office Community Edition is an open source collaboration platform developed and supported by Feng Office and the OpenGoo community. It is a fully featured online office suite with a similar set of features as other online office suites, like Google Apps, Microsoft Office Live, Zimbra, and Zoho.



Collabtive Is a web-based project management software published as free software. It provides an open source alternative to proprietary tools like Basecamp. Philipp Kiszka and Marcus Fröhner started development of Collabtive in November 2007. The primary goals include simplicity, clean design, and visual beauty. [16]



Azendoo Is a web-based collaborative task management software founded in Bordeaux, France in December 2010 by Benoit Droulin, Christophe Gagin and Grégory Lefort. The application has partnered with Evernote, Box, Dropbox and Google so that users can centralize and share all of their informational sources confidentially. Azendoo is freemium based.



Credits

[1] Scaling The Management Of XP Projects, Bernhard Rumpe, Peter Scholz. [2] http://en.wikipedia.org/wiki/Microsoft_Office_365 [3] http://en.wikipedia.org/wiki/Microsoft_Project [4] http://en.wikipedia.org/wiki/Marketing_automation [5] http://en.wikipedia.org/wiki/SugarCRM http://en.wikipedia.org/wiki/Smartsheet http://en.wikipedia.org/wiki/Skype [8] http://en.wikipedia.org/wiki/UserVoice [9] http://en.wikipedia.org/wiki/Eclipse_%28software%29 [10] http://en.wikipedia.org/wiki/Doxygen [11] http://en.wikipedia.org/wiki/Microsoft_Visual_Studio [12] http://en.wikipedia.org/wiki/Team_Foundation_Server [13] http://en.wikipedia.org/wiki/JIRA [14] http://en.wikipedia.org/wiki/Asana_%28software%29 [15] http://en.wikipedia.org/wiki/Trello [16] http://en.wikipedia.org/wiki/Collabtive

[6] [7]