Organizational Culture Change

As an Agile enthusiast, trainer and coach I’m pretty passionate about being Agile regardless of the specific framework being followed. In fact, my passion lies in the culture of being Agile, rather than a dogmatic adherence to a framework.

Following a Framework

A dogmatic approach to a framework may work well if you are a “.com”, start-up, or other application development shop. But, for those of us working with large corporations a dogmatic approach feels impossible. Here are a few of the reasons why:

• Team members are not co-located
• Teams are not developing software
• Team members are not fungible
• Teams cannot deliver anything fully functional at the end of a sprint (1 – 4 weeks)
• Teams rely heavily on other teams to deliver components, and struggle with dependencies
• Organizations have a legacy structure that doesn’t support being Agile
• Organizations want the teams to be Agile, but they don’t want to change anything else

I fully support adopting a framework, so don’t get me wrong. Organizations should try to adopt as much as possible of their chosen framework, and specifically note exceptions acknowledging deviations from a given framework. However, before the organization gets concerned about the framework they are trying to follow, I ask them to look at the Agile Manifesto and Twelve Principles. How much cultural change is the organization willing or able to accept in order to adopt a framework? As true agility requires both, a change to the new framework and a change in culture.

Cultural Change
When the “gurus” got together in Colorado, they not only defined the Scrum Framework, they created the Agile Manifesto, and Twelve Principles. These two items identify the Culture of Agile. To truly be Agile, organizations must work on the cultural change required regardless of the framework.

From the Manifesto:
Does your organization really put Individuals and Interactions over Processes and Tools?

Carte blanche rules for processes and tools don’t always work for everyone within the organization. Some tailoring must be done to truly be effective. Marketing teams may not need to use the same story writing and management tools as Software Teams.

Do they favor Working Software (Value Delivery) or Comprehensive Documentation?

Note: For non-development teams, I prefer to consider what “value” the team is delivering as working software does not apply.

This is not an excuse for skipping documentation all together.

Does your environment allow for true Customer Collaboration over Contract Negotiation?

Or do you have a hard time trying to figure out who is the recipient of the value you are delivering? A culture of “us versus them” may keep workers away from collaboration

Does the organization Respond to Change over Following a Plan?

Or are we all so worried about scope creep, we have a rigorous change policy? Or has the pendulum swung the other way, and you’re experiencing the “Chicken Little -sky is falling” scenario all the time?

Acknowledging the Agile Manifesto and how an organization may adopt their culture to it, is one of the first steps to agility.

Twelve Principles
To be honest, I find the majority of teams I work with have no understanding of the 12 Principles of Agile. How can that be? Does leadership really believe a framework will work without other changes? Yes, it is hard. Yes, someone will always be unhappy. Welcome to the real world.  If you fail at adopting Agile, and you haven’t tried to change culturally, is it really Agile that doesn’t work? Are teams working to be Agile, while the rest or the organization continues with business as usual?

Think of the simple scale from “Somewhat Agree to Somewhat Disagree”, and for each of the Principles score your organization.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (or just value delivery)

This allows our customers to see steady and ongoing progress towards are end goal.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Changes of scope may have an impact, but we need to quit complaining about change.

3. Deliver working software (value) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Reduce risk, increase collaboration, break work down into small pieces, and get feedback after each delivery.

4. Business people and developers must work together daily throughout the project.

If the team doing the work has no access to the recipients of the value, are you playing the “telephone game” with requirements and feedback?

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile teams are self-organizing, self-managed, and empowered to do what it takes to deliver quality value at regular intervals. If you’ve truly hired good people who want to do a good job, why micromanage them? Empower your folks, and see what happens. With any luck teams will learn to pick up the stick, and run with it.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Skip multiple emails, and meet face-to-face even if it is over the internet!

7. Working software (quality value) is the primary measure of progress.

If you’re not creating software, deliver small pieces that act as building blocks towards completing your value delivery.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

A little extra time here and there is okay. However if working 50 – 60 hours is the norm, it’s hardly sustainable.

9. Continuous attention to technical excellence and good design enhances agility.

Going faster doesn’t cut it if quality drops. The focus should always be on delivering quality.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Do you remember the 80/20 rule? We have a phrase “no gold plating”, so focus on what really matters to the 80%.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Learning new practices, and engaging regularly to ensure the foundation is sound enables teams to take advantage of emerging technology and practices.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Without continuous improvement, being Agile slips further and further away from reality.

Summary

Cultural change is key within organizations in order to really support the Agile Manifesto and its Twelve Principles.  Where does your organizations culture fall when using the Manifesto’s scales, and the Twelve Principles? Work to move the pendulum a little at a time as needed. The origins of Agile lie not in black and white answers but in collaborating to do what is best in our drive to deliver value. Your customers will be happy, and you’ll retain employees and keep them and shareholders happy.

When an organization decides they want to “Go Agile”, they usually go through a multitude of changes before they get into a rhythm of the method(s) they have decided to use.  Once a team gets into a rhythm of ‘going’, or just doing, they will most likely be so engrossed that they forget to look up and see where they are.  However, it is important that they stop at some point to examine how things are going overall in their Agile journey and whether or not their method(s) are working for them.

The most popular framework that teams choose when first moving toward being Agile is Scrum.  In order for a team to really grasp the idea of sprints and incremental development, they will need to do a number of sprints before stopping to examine themselves; one sprint does not give the full feel for the changes and mindset shift that occurs.  Whether they stop after 4 sprints or after 10 sprints, the team will usually feel one of two ways:  “Scrum seems to be working for us; let’s keep it up, using continuous improvement to get better, and examine again in another few sprints” or “this doesn’t seem to be working; let’s forget Scrum and just do the work”.

When a team feels that Scrum is working for them, they have usually tweaked the framework a bit to allow for their team to feel they are abiding by the Agile Manifesto the best they can to ensure value.  As teams work together, they will tend to work toward continuous improvement and look for ways to work with the customer to ensure their satisfaction.  They will strive to continue to tweak their process to be successful in being Agile.  This type of team is most likely tightknit and feels good in the rhythm they have gotten into—so much so that they may not want to stop to examine, but realize they need to.

The other feeling that comes out is the aforementioned “this doesn’t seem to be working; let’s forget Scrum and just do the work”.  When a team has been doing Scrum for a while and they take stock of where they are, they sometimes conclude that Scrum is more work than they want to expend.  They can see the ceremonies as too much time wasted or that the timebox simply doesn’t fit their needs.  When this happens, they typically chose to abandon the framework and simply ‘work’.  They could just leave Scrum behind and choose a different method to become more Agile, but usually that is not the case because they have come to believe that the road to Agile is the problem; not its implementation of the method or framework.  When the team abandons Scrum, they don’t just abandon the sessions, like sprint planning or retrospectives, they tend to abandon the mindset that being Agile instills.  As they move away from Scrum, they also are likely to shy away from concentrating on the customer and the value they can provide to the customer, which is the core of the ‘Agile way’.  They see the ‘failure of Scrum’ as ‘failure of Agile’ because somewhere along the way, they have equated the two: Scrum = Agile and Agile = Scrum.

As the team ‘does what they want’ and does not follow any Agile methodology, they can easily fall into the trap of ignoring the customer’s wants and needs to the point of missing the mark.  When this happens, we have to examine why the team chose to move toward Agile in the first place:  to deliver what is really needed/wanted and not just what is listed.  If they don’t feel Scrum is working, the team will have a tendency to focus on what they want to do and stuff they find easy. In the end, the product is not what the customer is looking for; there tends to be wasted effort and time.  This wasted effort then results in many other issues with the project/product like not meeting dates, going over budget, risking the cancellation of the project/product, etc.

With all this said, it is not every team that reverts to ‘just working the list’; some simply find other avenues to be Agile other than that of Scrum.  These are the teams that understand that Scrum is maybe not for them, but understand that their attempt to be Agile is not the problem.  These teams usually find a way to move to other methods more suitable, such as Feature Driven Development, Extreme Programming, or even Kanban.

It’s important to remember that the point is to take time and examine what it is that is working, or not working, overall.  Most teams do this at the retrospective, but that should be focused on the team and the sprint.  There should be a time when teams do a more encompassing retrospective that looks at the process as a whole, which would look at things like release planning and working with other teams in the organization.  It is crucial that they take stock of what is working and what is not so they feel empowered to make changes to be as Agile as they can be!