I spoke at the Agile Ontario Meetup on December 10th for the December meetup. I have been attending to this meetup for a long time. This time was different, I was speaking at it. The topic that I was talking about was standardization of practices and processes amongst the teams and how will or will not help the team. It was an honour to be a speaker at that meeting. When I look back, I am feeling that the Agile Community in Toronto inspired me, guided me and helped me florish. This is a community that you feel like a family when you are part of, and you want to be part of it. It truly felt like a family to me. I even spent one of my birthdays with them, two years ago. And the day that I was speaking at was a very special day for me, both good excuses to spend with good friends.
 |
| My birthday, celebrated with my Agile family two years ago |
 |
| My birthday surprise at the end of AgileOntario Two years ago |
 |
| Special day, spent half a day with my Agile family |
As you might imagine, this is a very wide open topic to talk about. It was a very interesting conversation, obviously, I’m biased, as Fernando and I were the conversation leaders. It was a very engaging one and the fact that heard everyone talk was something that I rely my observation upon.
We started by prescribing the audience a Standard protocol for this meeting. We told them that we have hired many advisors and coaches to help us with finding how we can be more efficient. The only way that we could find was to standardize the meeting.
That was obviously an ice breaker, we continued by asking the participants on what they have in mind when it comes to standardization. If they have any examples or thoughts in their mind to talk about. I am summarizing some important conversation starter points below based on the two hour conversation and some of my thoughts based on the research that I did.
Think about the value and your goals
- Think about the value you are after. Practices can be mandatory (standard) or recommended , make it mandatory in case they are providing clear value. When standards no longer add value they should be dropped.
- You can take it in a different direction. Think about what are your organizational goals? What’s the least standardization necessary to achieve those goals? That’s what you want to standardize. Identify the smallest constraint set that will deliver those goals. That would be a good candidate for defining standards.
- -Sample: If your goal is the ability to manage flow and see where teams are bottlenecked, you might use a common workflow to allow you to see patterns across teams. But teams could move work from ‘Ready’ to ‘In Progress’ via a virtual huddle on a chat platform, or at the daily standup, or by the team member who signed up for the story deciding that it meets DoR, etc. They might have different Definitions of Ready. Etc. etc.
Innovation and Creativity
- The less you standardize, the more teams will come up with creative solutions and the more adaptable they will be to change. And the more you will learn from them.
- A good example of innovation is “square-wheeled tricycle”. You can see that this couldn’t happen if there was a standard process to follow, who invents wheels these days any more?!
Self-Management & Self-Organizing
- A team can hardly be considered self-managing if it can’t develop its own processes. Consider the fact that I am not saying a standard process is good or bad here. I am stating the fact that a standard can be helpful if the team came up with it. Otherwise, it won’t be that helpful to the growth of the team.
- Another aspect to look at is the standard that can span among all teams. It think that a won’t be necessarily true that a single standard can not successfully span all teams. It will be more valuable to have a discussion with the team and ask them what you are looking for and why and maybe give them guideline, and give them the freedom to chose their own process and standardize it.
Sub-optimization
- In standardization, you want to make sure that you are not making a sub-optimization in part of a process while you are introducing those standards.
Empowering the team
- If a team comes up with something that works, there’s nothing wrong with other teams deciding to adopt that practice.
Root Causes of Standardization
- It gives more control to the upper management. Facilitates upper-management control of the way people work. If you are in an Agile organization, or claiming to be, that notion of control is in direct opposition to agile principles. Agile organisations should be based on trust, not control.
- The desire to control is strong and standardization satisfy that desire.
- Standardization is showing people’s effectiveness for work that is repetitive or doesn’t add value. In this case, can you look at the process and figure out why there is no value being added? Isn’t it waste (in terms of lean thinking)
- It drives from manager’s ego to know what’s happening when they decide to look more closely.
- Another reason might be that the management wanted people’s ability to move teams instantly when they switch teams.
Transformation
- If the organisation is going through the transformation, the role of “management” should be to support the teams, to help them to leverage the expertise that. If they are making something mandatory, they are saying that you know more about what the teams are doing and how they should do it than the teams themselves do.
Examples of Standards
- A Common Language
- If we all spoke a different language then cooperation would be difficult. The fact that we speak a common language makes things much simpler.
- Working Agreement
- At the team level, a “working agreement” is standardization. A career growth model is standardization.
- Definition of Done
- This is a very good example of a standard that team decides upon that. This is a standard that is evolving and can be helped to generalized that idea.
- Automated tests are part of the deliverables. Checking code into the departmental source control system is an aspect of the DoD and deliverable.
- Coding Standards
- Is is something you want to introduce if the team doesn’t like it / want it? What if the team doesn’t know what is the standard? What is the outcome if the team is not buying into the coding standard? Can they even follow that?
-
Culture
- Isn’t culture a standard for behaviours? Maybe not! Think about it!
Points to consider for good standards:
- Evolve
- Standards can (and should) evolve over time as the organization, its culture, and its needs evolve; standardization should not mean staid and stagnant. Flexibility is critical.
- Lightweight
- Easy to implement, hard to master! Standardization doesn’t have to be heavy, complex, or intensive. Lightweight frameworks and guideline-style rules are great types of simple standardization. Scrum (for example) is a standardized process control framework, but is far more lightweight than CMMI/traditional waterfall, and also adaptable and malleable.
-
Automation
In software development, if anything ought to be standardized then it ought to be automated.
Cynefin
- We talked about the Cynefin framework. The point of the conversation was to make sure that you understand first what is the situation you are at. Moving from one quadrant to another using standards might not be useful at all. It might even gets you in to the chaos. Something that Agile does very well, to put the organizations in a chaos mode. Standard might not be the answer to getting out of it (and it’s not).
Change
- -Make progress with what information you do have and adjust as new information arrives
Tips and Tricks to Influence Standaridzation
- Make them easy to use
- The trick to standard practices is to make them easier to use than not to use. An example would be organization wide communication. If you have skype integrated, there is less chacne that a team want to use google hangouts. (disclaimer: In one organization I saw that happened)
- Influencing Standards by Socializing them
- Socialize ‘things’ that were working for other teams, if the team thought it worth looking into they did. Over time you would end up some standard approaches among various teams.
Coaching is the Answer?
- Coaching individuals first!
- Instead of making things mandatory, teach everybody why certain practices work (or not), how those practices interact with others, what benefits they might provide, how people do things in other organizations. Then let them choose what works for them.
- Coaching organisation second!
- Teams should be allowed to self-organize, experiment with mechanism to deliver, measure success/failures. There are problems that exist above the service delivery capabilities of a single team that require consistent, commonly understood information to be shared by the team. That consistent, commonly understood information probably comes from a standard which describes the information that teams are required to produce. This would be a good opening for having a conversation with the upper layer managers and coach them. The result might still be the need for standards!
Policies v.s. Procedures v.s. Standards v.s. Guidelines
- Policies v.s. Standards v.s. Procedures v.s. Guidelines
- We need to understand the definition of each before talking about them. It will give you a better understanding of what it is, how to talk about it and where to head in that discussion.
Measurements ==> Behaviours ==> Processes ==> Standards
- Measurements drive behaviours, behaviours drive processes and processes introduce standards. If you look at the standards this way, you can influence them. This path to influence is not easy. However, if you flroish the environment that produces these kinds of standards, there will be staying there for a long time. I will guarantee that!
CMM (Capability Maturity Model) 5 Levels
- This is what I found looking up for processes in Software Development world.
- At the initial level, processes are disorganized, even chaotic. Success is likely to depend on individual efforts, and is not considered to be repeatable, because processes would not be sufficiently defined and documented to allow them to be replicated.
- At the repeatable level, basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.
- At the defined level, an organization has developed its own standard software process through greater attention to documentation, standardization, and integration.
- At the managed level, an organization monitors and controls its own processes through data collection and analysis.
- At the optimizing level, processes are constantly being improved through monitoring feedback from current processes and introducing innovative processes to better serve the organization’s particular needs.