CMSI 543 / SYEG 557: Welcome to Week 03

This Week's Class Agenda

• Organizational Cultures
• Differing Viewpoints Within an Organization
• Team Member's View
• Manager's View
• Executive's View
• Other Stakeholders' Views

Organizational Cultures

What is Corporate Culture? Well, think about a society with which you are familiar, and ask yourself the following questions: Are there certain rules that are followed? Are there laws that must be adhered to? How many people are involved in the day-to-day activities? Is there a hierarchy within the society? How does that hierarchy affect the day-to-day activities? How does it affect the overall social construct? How does it affect the way that people go about their tasks? How does it affect the way they THINK about their tasks and their adtivities? Are there unwritten rules or guidelines that help to govern the actions of the society's members? How are those rules and guidelines changed/maintained/enforced? These are all questions that also pertain to any organization, since an organization is actually a social construct, a society if you will. You'll no doubt bump into some of these concepts as you are working on your project this semester! But why do we care?

We care because the organizational culture surrounds what we do with software development. If we are working on a team within an organization to develop an application, for example, there may [or may not] be specific processes that need to be followed for that work. There may be processes associated with THOSE processes that provide ways of changing the process, or provide guidelines for planning, coding, testing, deployment, maintenance, tool use, configuration management, and many other activities.

It is also a known fact that changing culture is HARD and takes a long time to accomplish. For an example, think about the American Civil Rights movement in the 1960's. It took DECADES just for people to end legalized racial discrimination, disefranchisement, and racial segregation in the U.S. [check out a brief history here.] So trying to get an organization that is accustomed to all the activities that go with the Waterfall approach can be difficult, and can take a long time.

Why is it so hard and why does it take so long? One big reason is that an organization's culture is built up over a long period of time. It evolves on a continuing basis, with every interaction and experience, every reaction to those events, becoming part of the organization's mindeset. Those attitudes become part of the way people think, feel, and act within that organization, and new people who are brought in also assimilate that culture. Thus, over time, the culture develops into something like a large container ship which is churning on its way and is very hard to turn.

Let's look at some specific contributors and a few ways to deal with them.

Differing Viewpoints Within an Organization

Because an organization may have many people and those people may have differing roles in the activities of the organization, there are a number of different views that may be applicable. It's similar to the ANSI SPARC three-layer model for databases; different stakeholders have different needs, may have different requirements, and likely have different feelings about the data they want or need to see. The analog is of the different members of the organization with respect to organizational activities.

Team Member's View

Team members on an Agile team are typically either developers or testers [also called quality assurance role in your textbook]. The category could [and should!] include other members of the organization, as we will see later. There are a number of key Agile principles that might be deemed highly desireable to these individuals:

Teams can be self-organizing

The term self-organizing in this context means that the individuals on the team are allowed to select the specific thing they WANT to work on, in most cases. Since the individuals are responsible for the parts of the project on which they are involved, letting them pick the part they want fosters better engagement with the project and [more importantly] with the team.

One of the first things that happens in an Agile team is the team members will create a working agreement, which allows the team to establish its own rules and guidelines. Being able to do this activity with little to no oversight from management helps the team feel a sense of ownership and responsibility to the team, along with a sense of their own destiny.

Another good thing with self-organizing teams is that the team members are not constrained by management's ideas of task assignment. In the past, managers assigned the tasks without the team member getting much of a say in what that assignment might be. The feeling was that the manager understood the work and could then make the appropriate assignment. With Agile, the developers get to pick the tasks, and often may come up with a better solution to the problem that management has not considered, and this solution can be implemented without relying on management.

Yet another advantage is the ability to spontaneously cross-train on the team. Team members often want to learn about other parts of the project, and will ask to be assigned to parts in which they have an interest so that they can grow their skill set.

There is another aspect of self-organizing teams that isn't addressed here: the idea of letting the team members self-select whether they WANT to be on a particular team. Granted there may not always be such a choice, it is kind of a luxury in many organizations. However, there are often opportunities which arise that potential team members may become aware of ahead of time, such that they can ask management to include them on the team for that project. This is the way we work in school here at LMU much of the time, and is definitely part of the self-organizing concept

Continuous Improvement

Another big idea of Agile teams is the fostering of ownership of continuous improvement. Since each team member is responsible for a particular portion of each iteration, the onus is on that person to insure that portion works correctly, and that problems from that portion are not carried forward from iteration to iteration. Again this fosters higher engagement with the team and the project.

The second idea associated here is the concept of what is known as the reflective practitioner approach. This means that at the end of every iteration, the team gets together for a special meeting to review how that iteration went. This is referred to as a lessons learned meeting, sometimes called a post-mortem meeting. The idea is for everyone on the team to chime in and give their input and feedback on what went right, what went wrong, and suggestions for improving the process. Note that this is ENTIRELY independent of things like burn-down and velocity, it is more focused on process and procedure. Reflection allows the team to be actively engaged in the resolution to problems, further fostering their sense of ownership in the activity.

Frequent Delivery

One of the main benefits of Agile is that there is a very short time between the planning and delivery portions of an iteration. This allows the customer [and other stakeholders] to have an ongoing view to how the project is progressing, and gives them the chance to provide feedback frequently during the development process. This feedback also allows the stakeholders to make corrections and adjustments if they are needed, to keep things on track and verify that the application is going to be something that will be correct and provide business value.

Teams will deliver code with very short turnaround times, typically just two or three weeks. This will be fully-functional, tested code that works as a minimum viable product [MVP]. As has been said by Alistair Cockburn in the Crystal Agile Methodology [in Ashmore, p.19]:

The single most important property of any project, large or small, agile or not, is that of delivering running, tested code to real users every few months. The advantages are so numerous that it is astonishing that any team doesn't do it:

• The sponsors get critical feedback on the rate of progress of the team
• Users get a chance to discover whether their original request was for what they actually need and to get their discoveries fed back into development
• Developers keep their focus, breaking deadlocks of indecision
• The team gets to debug their development and deployment processes, and gets a morale boost through accomplishments

All of these advantages come from one single property, Frequent Delivery.

Feedback is a critical part of the puzzle, and getting that feedback is fundamental to the ability of an organization to fix things if something isn't going quite right or doesn't meet actual customer requirements. In the Waterfall method, it's more of a Big Bang approach, in which the stakeholders get the finished product all at once, at the end of the project, with no opportunity to make any changes or adjustments. Incorporating feedback during the development of the project can save money in the long run, since change is cheaper to make when the effects to the code, testing, and debugging efforts are small.

Removing the Us v. Them Scenarios

Prior to Agile, testing was often done by independent teams. The product was handed off to the Q.A. team to perform a battery of tests, most of which was designed with two things in mind: 1) make sure the software functioned per the requirements; and 2) list things that didn't work per the requirements so that they could be corrected. While testing, in general, is a GOOD thing, there were several problems with this approach: Even if the requirements were met, there was no way to guarantee that they were actually the RIGHT requirements to fit the customer's needs There was often a let's see if we can break it or crash it philosophy with the test team that fostered an attitude of Us versus Them The test team was an independent group, and was not considered a part of the development team or their process The test team was often, in fact, a completely separate department; this creates a structural organization within the organization which is known as silos With Agile, however, this attitude is never allowed to arise, since the test team is an integral part of the development. Developers and testers are now collaborating to create the highest quality software possible, and all team members have an equal stake in the project's success. Further, the product owner, as a team member, has the job of making sure the requirements are clear and properly prioritized, so that the team knows what they are doing and is able to do it correctly.

You may have noted that a central tenet of this process is that the team succeeds or fails as a unit; in other words, like the Three Musketeers of fiction: All for one, and one for all!

Physical Workspace

In the best-case scenario, the entire Agile team is co-located in one room. Everyone has a space to work, and whatever infrastructure they need to do their jobs. Such conditions help to foster collaboration and speed communication, since if one team member has a question or needs better understanding of an issue, they can simply ask the rest of the team in real time. There is never a need to send and recieve e-mails or schedule extra meetings to accomplish simple communication within the team. This includes testers and other roles as well.

Team Dynamics

Strong teams that have been allowed to self-organize usually know each other well, allowing all team members to address both the personal and professional subtleties of the group, which helps maximize the GROUP'S effectiveness.

Strong teams also demonstrate an ability to course correct, meaning they can adjust and adapt to unexpected issues when they arise. Action can be taken quickly and directly, to help the team maintain productive progress. Concerns can be addressed early, respectfully, in a way that is focused on resolving the problem.

Virtual Resources

In a global environment, it is quite likely that one or more team members may be in a different time zone, or even a different country. This presents some unique challenges to the co-located team. There is, of course, the lack of immediate face-to-face communication. However, this can be mitigated by modern technology [Skype, Discord, Slack, etc.] and by properly scheduling virtual meetings. Another mitigation is to bring the remote people in to a central location at the start of the project and have them remain for a period of time, typically the first two iterations, to help them get to know the local team members, and the reciprocal. In that way, ALL team members get to feel included and unified.

Optimizing the Workspace

Take the workspace seriously, and look for potential optimizations, such as these:

• Individual workstations which should be arranged to facilitate the team's collaboration with all team members.
• Agile Scrum Room which is a discussion area that is NOT shared with other teams, and may even be separated [somewhat] from the normal team environment. It should be fully equipped with whiteboards and other tools to facilitate brainstorming, diagramming, and other such activities.
• Company Conference Rooms which can be used for larger meetings which often require scheduling and invitations to make sure everyone can attend, and to utilize shared spaces within the larger organization.

Common Mistakes

Here are a few:

• Failure to self-organize meaning that one or more of the team members may be reluctant to become fully engaged with the project or their potential role in it. There may be push back from such people; they may even just not be the kind of person that is a good fit for an Agile team. Another scenario involves bullying or hostility toward other members of the team, which CANNOT BE TOLERATED. If the team can't resolve this on its own, management has to step in.
• Inability to adapt meaning that one or more team members are uncomfortable with changing in the face of project issues. For example, time zone changes, overlapping work hours, and requirements clarification may require the team to adapt and adjust. Another example is if a team member has trouble moving to an open environment, preferring to be in a cubicle or in an office.
• Lack of commitment in which team members may fail to honor a commitment that has been made. This is an attitude and may require that the team member has to have an attitude adjustment of some variety, which may even mean they are removed from the team entirely.

Manager's View

Agile managers need to learn one big lesson: Stay Out of the Way. The following paragraphs show what this means and why it is hard.

Questions, Not Solutions Managers are typically seen as project owners, who are responsible for defining solutions to problems the project encounters. However, with Agile, that job now belongs to the TEAM, not the MANAGER. Thus the manager needs to learn a new function ~ that of facilitator. The best Agile managers respond to problems by asking questions rather than offering solutions. They leave it to the team to determine or uncover their OWN solutions. The development team members are the experts and most often will be able to suggest a solution and a way forward from an issue. The manager should focus on helping the team members continually improve and learn. Clearing Roadblocks Hand in hand with facilitating is for the manager to clear roadblocks so that the team can be successful. This might include navigating the organizations political environment as a team representative. Managers who are free from having to monitor every minute detail of a development project will have the time to give to such things as nurturing employee development, or driving the direction of the project toward simplicity and performance improvement. They can also help recruit new team members and make sure they add constructively and coherently to the team. The ideal Agile manager will do whatever is necessary to insure the success of the team.

Trusting the Team

Another change managers must make is to TRUST the team members. Many managers adopt a Command and Control attitude that holds the belief that the manager knows best. This attitude is not one which is productive for an Agile team. It may be difficult for a manager to let go of this belief and just trust the team. An effective Agile manager trusts the team to do good work, and allows the team to own its issues and resolve them without interfering. This approach frequently means the manager will just turn the problem around and give it back to the team to solve, and will assist by asking questions to help the team come to their own resolution.

Problems: Command and Control

Some managers simply cannot relinquish the command and control mentality. It's who they are, how they manage; it's their style. Sometimes it's helpful for these people to remember the techniques that were mentioned above, of 1) asking questions; 2) letting the team be accountable; and 3) do not talk and stay out of the way. If it is too difficult for a manager to adapt, then perhaps that manager should stick with the traditional Waterfall approach where such talents are a better fit.

Problems: Territorial

Some managers truly feel they own the project and that they are the only ones who should make any decisions for the development, because they understand it the best. This does not work for an Agile team! Agile is a collaborative effort and is customer-focused not manager-focused. Ownership is a difficult challenge in Agile development, because we WANT team members and their teams to feel a sense of accountability. The difference is that instead of ownership for the sake of itself, we want accountability for the sake of delivering business value to the customer. If an Agile manager feels that their toes are being stepped on, the usual best course of action is to take a step back and look at the business problem rather than the technical details.

Problems: Team Oversight

Many managers feel they simply can't let go of the team. They feel it is their job to be intimately involved with every aspect of the project. One of the best cures for this attitude is for the manager to simply stop attending meetings. Over time, the team will realize that they no longer have to wait for the manager to come to the meeting or to make decisions, and they will step up and begin to exercise their own accountability.

Executive's View

Believe it or not, executives play a critical role in Agile development, because they hold the power to allocate resources to the project. Resources might be money, location, infrastructure/equipment, and of course people.

Embracing Evolving Requirements

Executives deal with budgets, progress reports, earned value, meeting milestones, boards of directors, and shareholders. Executives are in their comfort zone when they can see the entire project laid out from beginning to end, so that they feel they can estimate the cost and schedule of the project. However, because the global economy causes markets to change so fast, it is VERY HARD to try to plan a project at its inception. Agile executives must learn to let go of much of that traditional activity in favor of and environment that is built on rapid prototyping, construction, and deployment, which is MUCH harder to track in the traditional sense. Executives need to be courageous in their representation of the Agile project philosophy to their boards and shareholders. [See Jeff Bezos' 1997 letter to Amazon's shareholders for an example

Respecting Priorities Another thing that Agile Executives must learn to do is to place a high priority on the feedback that is provided by short iterations. Keeping the customers happy makes them confident in the organization's ability to meet their needs, and fosters repeat business as well as new business brought in by the reputation that is established by successes. However, many executives have a knee-jerkreaction to problems which causes them to want to focus on re-prioritizing the tasks to fix apparent problems. Executives are decisive, action-oriented, and results driven, so tiey naturally want to mandate an immediate response. Instead, they need to respond by allowing the team to manage the situation itself, by folding its own resolution into the next iteration. Staying the Course An effective Agile executive will work through the issues of command and control managers who fight the changes of Agile, developers who refuse to embrace the increased accountability, and unknown issues that are systemic to the organization but only appear after an Agile approach has been instituted. The Agile executive must learn the inspect and adapt way of thinking by moving carefully but rapidly forward and by learning from every decision. The executive must recognize that although there are people in the organization that have YEARS of experience, if those people are not willing and/or able to pursue Agile as a collaboration which helps foster learning and knowledge transfer, those people don't belong on an Agile project. Finally, the Agile executive must realize that nothing comes for free; if Agile is to be successful in an organization, the executive must be its champion to get the resources needed. The Agile executive will stay the course when confronted with such issues.

Focus on Sustainability

Agile processes promote sustainable development. This means that no Agile team member is required to work to the point of burn out. Ever. Full stop. Executives are responsible for sustainability because they control the resources and the expectations of the organization. An unsustainable pace will result in the following conditions [Hartman in Ashmore, p.38]:

• Defects will increase. Tired teams let more defects through.
• Work output will decrease. Tired teams do less work in more time!
• Morale will drastically decrease. This may lead to employee turnover at a most unfortunate time in the project.
• The blame game will become common. [Not our fault you didn't say X. I said X. Did not. Did so.]
• The team starts to abandon good practices for those that seem faster. Sorry but test-driven development [TDD} is actually faster than just writing the code and throwing it over the wall to QA!

Focus on Technical Excellence

An effective Agile executive will make sure that the teams have both the time and the resources to make wise decisions about the project architecture and design that allow the application to properly scale and perform.

Focus on Simplicity

Simplicity in Agile can be from the implementation itself, embracing the unknown and trying new things. Simplicity can also be based on the organization's or the product's objectives; if they are too complex or ambitious, the organization can become fragmented. The Agile executive knows that simplicity can move the organization forward while complexity can hold it back, eventually making it irrelevant.

Problems: Not Honoring Commitments

One of the most common errors executives make is not allowing teams to honor their commitments. Once a sprint goal is committed to, THERE SHOULD BE NO CHANGES TO THAT GOAL. This was discussed above. In addition, an effective Agile executive will work to keep other executives in line so that the sprint can remain isolated from their potential influences.

Problems: Not Engaging the Rest of the Organization

Because the Agile development is part of the overall organization, the entire organization MUST BE committed to it. The people in other departments must also be brought on board with the Agile idea so that the development team can get proper support for its daily activities. Customer-facing parts of the organization may have the best ideas of how to deal with customers, and should be consulted as to what parts of the development should be prioritized. The Agile executive must be the team's champion.

Problems: Valuing the Wrong Metrics

An effective Agile executive must be able to measure the right things about the project, and must resist the impulse to measure the wrong things. For example:

• Actual time vs. estimated time to complete a task: Which is more important, working software or correct estimates? If it's the former, the time estimation becomes secondary and trying to ensure that a project stays within a certain time estimated at the beginning of the project is counterproductive.
• Compared velocity of team A vs. team B: There are a wide number of reasons why two teams cannot be compared. For example, one team may be working on a smaller number of story points because they are more complex. Or, perhaps one team has hit a development snag that the other team didn't have to deal with. It is even possible that there is a technical difficulty for one team and not the other. Trying to do a comparison between two teams is folly.
• Number of stories with acceptance critieria vs. those without: User stories are written to reflect the way the software will be used. Just because a story doesn't have an acceptance criteria doesn't mean it is less valid than on that does. If the story is trivial, there may be no need for a criteria. If it is an epic, it may not have any criteria because it's impossible to write meaningful criteria for something that large.

Other Stakeholders' Views

Let's think of some and document them!

In-Class Exercises

Discussion questions — Consider the most productive team you have worked on, and discuss amongst yourselves what you might answer to the following questions. Then write down an answer that the team feels is the most representative for each question:

• What factors do you feel contributed the most to the project's success?
• What skill sets did your team mates have?
• Do you feel those skill sets provided value to the effort?
• What do you feel was your strongest contribution to the team?
• How did the teams various abilities complement each other?
• What lessons did you learn?
• What lessons have you brought [or tried to bring] to projects you have worked on since?

Discussion topic number two: Why do you think it is so difficult to estimate the time and complexity of a software development project? How does estimating software development differ from other types of projects you may know about?