Agile vs Rigidity.

I think we humans have a problem expressing decent without recognizing existing value.

A system with invented boundaries, requires that people decent when the boundaries are breached.

A system with intentional boundaries requires that those boundaries are challenged.

The evolution of a flexible system is an interplay between the intentional rigidity of good rules and the intentional experimentation of alternatives.

Breaching boundaries is the clue that we are assessing the current rules.

Limiting change is not rigidity, it is the siting of theories that describe optimal flow, each of which requires proofs.

Who Prioritizes Agile Stories. Ops, Security, Devs or the Business?

The problem is an old one; who decides what a development team should focus on next. Traditionally, we say "the business" but we know that product quality and technical debt can loose out. When does "the business" consider security important? Unfortunately, in todays tech world, security is consistently an afterthought.

I believe I have a solution, which stems from trying to understand the question. "Who decides the priority of a story" is the wrong question. It obviously depends on the story. Agile teams profess working together for a common goal, all skills sharing ideas, planning and implementing together, but we never said that everyone on the team knows everything or is skilled or knowledgable enough to make all decisions. Hence the team thing.

So the answer is "Allow prioritization within skill scope" or said more verbosely, "People with specific skill sets make prioritization decisions related to the scope of their skills and goals".

At the end of the day, everyone in the company wants the same thing. Lets make some money, using quality products that are stable and support the services the business sells all the time, and no one wants our products to be exposed to attack.

Story priorities must be defined in this sequence:

1) Production Operations Team

At the top of the list are stories written by the Production Operations Team. These people know how the products they watch over run and are solely responsible for the day to day stability of these products.

Since all businesses want to maintain the services they are selling, it makes sense that a story addressing a problem in this scope must be prioritized first.

An example might be, the automation of a task that results in errors when performed manually. The removal of pageable errors from log files that have no corrective action. A product deployment process that minimizes over night work.

The impact of a problem that this team faces must be reviewed by everyone, but as soon as it impacts this teams ability to operate the products, then they get first dibs at priority list.

2) Security

Next on the list, a security team is responsible for the monitoring, response to attacks and verification that the development teams are building secure products. Any action that detracts from these goals must be prioritized above anything else since it is core to the businesses desire to protect their customers.

A Security Team is responsible for evaluating risk/reward against all possible attacks, but once a protection is deemed needed it gets into the next sprint, right behind any outstanding Production Operations stories.

An example might be, add validation to a field to prevent an injection attack. Integrate a static analysis tool into the CI build to invest in continuous verification of code.

3) Development Team

A development team is responsible for the building and delivering of quality products to production. They are responsible for ensuring they can perform their duties fast and efficiently and with zero defects.

To address this responsibility the Development Team must write stories that address items that might jeopardize their success. It is within their rights to define how they can best achieve the goals of the team.

An example might be, remove duplicate code to eliminate potential bugs. Implement a test framework that will ensure the code always works. Re-write a legacy code module that continues to introduce bugs to the product and slows down feature delivery.

The Development Team also wants to deliver quality features as fast as possible so is responsible about how they asses the risk/reward of changes.


4) The Business

Does it seem strange that the lowest priority group to set priorities is The Business? This was a revelation to me. I thought of it in a tribe retrospective a few weeks ago, when someone asked  a simple question, "Why did we let ourselves create this problem"?

The phrase "The Business" is mis-used of coarse. A company has many departments performing functions that sustain happy customers. IT is one of those departments and is therefore also "The Business". The mixture of skill sets hired by a company including, accounting, purchasing, HR, and programmers, all allow the business to achieve its goals and make money.

So, lets state it this way, if a department in the business needs some changes in a product, then various skills will be involved to achieve that; IT, support organizations, BI groups, operations teams, sales and marketing, training and the list goes on. To make a change to an established product, lots of stuff has to happen and all those teams are responsible for performing their duties to best achieve the companies goals.

Planning that change and prioritizing it against all the other changes from all the departments is part of the business benefit evaluation that occurs to produce road maps.

In the end, that change, written out as a set of stories, optimized for MVP, and evaluated by the development teams to maintain the road map, gets slotted in to the list of stories that the team must work on.

Fear

I hear you say this is crazy. The business pays me and can fire me? What if the developers decide to take 6 months to make the code pretty, you know how much they want to get rid of all those tabs and it takes them so long to get anything done as it is?

Trust between groups is always a challenge. Different people with different skills and different goals will never completely understand each other so mis-trust is easy. However, people are a companies most powerful asset, so fix that first, and allow them to thrive together.

Conclusion

The most efficient way to move forward is to optimize how each team works. Let the developers prove they can deliver features fast. Let security make our customers safe by allowing them to drive how these products should protect them. Let operations teams sleep well because they know how to optimize their work. With these goals, all "Business" changes will be delivered fast and without question.

Tribe Level Ceremonies

We take new words from Spotify to describe a scaled agile organization. Tribes contain squads which deliver features. Guilds share subjects and Chapters share skills.

This is about extending traditional Agile to optimize for larger teams. Scrum talks of teams with daily Stand Ups and a Scrum of Scums to share between teams. It assumes that information is shared between teams via a Scrum of Scrums representative but this doesn't really work.

We don't do team Stand Ups anymore. We don't do Scrum of Scrums anymore. Instead, all Squads in a Tribe attend a daily Stand Up and share red, yellow, green status of the Squad. Thirty people in one room for 10 minutes. Thats four Squads in one room for 10 minutes. Thats four announcements of green most days, occasional yellows with some details and followup actions assigned and a rare red where everyone takes note and assesses how to change resource, blockers or what ever it takes.

This benefits us in a few ways. We decided a long time ago that a Squad Stand Up with a single developer reporting "Finished X, moving on to Y today, no blockers" was not effective. Its not effective because the information is too detailed for most listeners, and redundant for everyone on the Squad because they are all working and communicating everyday. The goal of Stand Ups is to decide if the current plan needs changing and how to change it. Everyone knows the current plan so no point reiterating it but risks and blockers potentially drive change and that is the key that these discussions should focus on.

So, from the old Stand Up definition.

- Please tell everyone what you did yesterday, what you are going to do today and any blockers you have.

We now have a definition:

- Your Squad must indicate the red, yellow, green status of your Sprint commitments and, if not green, what the projected problems are.

This change is made possible because these people have been doing Agile for years and so the need for a single team to "share status" every day is irrelevant now, they do that all day. They all sit within 10' of each other and openly announce issues as they occur. They commit and push code all the time and they ensure the build is always watching them.

If you have developers sitting in cubes, don't do this. If you are new to Agile, don't do this. The habits of the people on your team can not sustain this kind of automatic behavior.

How do you know if you can do this? Do you feel an uneasy fear if you have't pushed for more than 15 minutes? When you pull do you look at the code changes and immediately give feedback? Do you feel strange not having someone sitting next to you arguing with your approach to a problem? Would you feel comfortable if the code you just pushed was to be release to production now.

People go through changes when they practice Agile. Its more than a process, its a re-programming of a developers instincts. 

Making Change a Habit

I adopted a new rule in 2000 that states, "If you think the problem can be solved by just trying a little harder, then you have the wrong solution". We spent decades of wasted time telling ourselves to just try harder to write tests, then TDD came along and it was obviously a better answer.

The try harder admonishment is an endless, repeated, diatribe about of our personal failures and how we should just buckle down and be better. Stop trying harder and start thinking.

I am not saying that, on an individual level, we don't have things we can do better at, and need to be pushed and cajoled into doing something about, but as an answer to an industry of professionals that work hard to build the best solutions they can, "try harder", is wasted breath.

Some things we here today are "Developers just have to try harder to make their code secure", this will never happen so just stop saying it. Instead, change the process to make security a primary focus on every team. Add a security engineer to every team who only, reviews, writes tests and verifies a product evolves appropriately. Enterprise level security initiatives are valuable but are not the full answer, as evidenced by the hacked reality we see every day.

Have you heard this one; "We have to try harder to share information from Scrum of Scrums with the rest of the team". I get that some of you probably do this well, but most do not, and the solution of trying hard doesn't work. Getting the right information into the right minds at the right time is an adventure in frustration. However, allowing for time-to-share and getting how-to-get-information concepts shared is much easier. The human brain works well in a limited number of prescribed scenarios and no-everything-all-the-time is not one of them. Optimize focus, intentionally limit sharing till required and allow time for understanding.

What about from your ops team; "If developers would only try harder they would understand the operations requirements and build the products we could use". Does your ops team hate you? If you are doing it right, a member of your ops team is sitting next to you for some hours of the day talking to you about what they will need to operate the feature you are adding. DevOps is a hard change, do it. Add operational intelligence as an aspect of every feature you implement with acceptance criteria and functional tests. Think of it as BI for the operations teams.

Has  your business every asked you to try harder to get BI reports out faster? "Why does it takes so long for the reporting about a feature to come out after the feature is in production? BI teams and dev teams are usually separated. This doesn't work. Every feature has a BI impact and needs consideration at the time the feature is implemented. Release your feature and the BI reporting as one package.

We have a support desk that answers the phone every day, and they hate us. "Oh please try harder to ensure we can answer customers questions. Just try harder to tell us what you are changing". How do we get support teams, with the hours they work, synchronized with feature development activity that we are working on. Send an email on release day? Sure that will work. "Oh, by the way, that button you used to use, just moved, good luck."  I don't know what the next change needs to be for this one, yet.

If you and your team want to be better, first change how you do things, then measure, and then change again. If you are not changing, you make it hard to change, and inevitably become a lagger in the ways of our ever improving approach to our profession.

If you believe that change damages teams because it introduced confusion, then you see change as an obstacle and will never master it. Don't use change as a tool, if you are not ready. With change comes chaos, and only teams experienced with change know how to own chaos. If your team members do not communicate, do not challenge each other and are not willing to be part of a solution, then change will destroy them. First empower the team, then master change.

On an experienced team, what happens is, a team member sees a change, and reacts by calling the team to order and facing it, they argue about how to address it, devise an approach to it and then reengage to the mission.

Change does disrupt, but since it offers the opportunity to grow, mastering it must be a primary goal.

Change is exciting.