Every Agile Organization has a Non-Agile Environment

An agile project team might act in a non-agile department, an agile department might be organized in a non-agile company, an agile company might serve a non-agile customer, ... and this works well when the agile organization learns to act at the border to its non-agile environment.

Abstract

An agile organization acts differently: >self-organized< with leadership principles instead of management Taylorism, in >cross-functional teams< instead of role-driven hierarchies, based on values instead of being controlled, focused on learning in steps instead of following a wrong plan.

Being agile is more natural, but during our education we get adapted by doing what our parents tell us, studying history from books, behaving compliant to legislation, being controlled by police, learning according to curricula, planning on budgets, etc. All that is not wrong, but by the way how it is usually done we forget how to decide, how to take responsibility and how to stay flexible. It is much easier to do what others say. And it is always the easiest to stay in our comfort zone.

When we re-learn being agile we always get in touch with others who don't. It is essential to accept that our environment is not agile and to learn how to map at the border, from outside to inside vice versa. The non-agile environment often is chaotic and volatile, because they often don't have systematic rules for dealing with change.

When we don't "do agile" but "are agile", then we are not only agile within our organization, but also deal with the issues at the border to the non-agile environment in an agile fashion. Also, we always need to be aware that the mapping is different for each and every organization and environment.

I have come to value being agile over applying Scrum.
That is, while there is value in applying Scrum, I value being agile by the meaning of the word more.

Details

The "Abstract" section above explains why it is essential to accept that our environment is not agile. We need to learn how to map at the border, from outside (non-agile) to inside (agile) vice versa. Many people fail to implement it, because mapping >a controlled approach and a self-organized approach< is anything but simple. It is peopleware, not hardware or software. The following paragraphs show some examples for successful implementations in my past.

An automotive supplier creates embedded systems with software on hardware in a housing. These might be radar devices for detecting other vehicles to support advanced driver assistent vehicle systems. Therefore, hundreds of engineers may work in multiple teams in several countries together in one project for maybe two years. The systems engineering guys may derive a technical architectural design from the requirements and constraints. The software teams develop the features in bunches, satisfying requirements and design decisions. Both apply the >corporate standard processes< that satisfy the regulatory and customer standards. While the system guys are pushed hard by customer and managers to modify the design whenever the need changes or misbehavior is discovered, they still try to work according to the system processes and to consider all functional safety aspects. The software teams do their Scrum Sprints according to the changes in their Backlogs, and they apply the software processes within the Sprints in cross-functional teams. This works fine when you organize it in a way that the system guys work upfront hunting for a new baseline, then the software teams do their development Sprints, and everything gets integrated and tested continuously. When the system guys learn to baseline often, when the software Sprints are kept short, when stubbing is introduced, and when automated continuous integration and regression testing is applied, then the overall progress can be really smooth and fast. This also supports a >Product Family Engineering< approach where the system guys are then working traditionally on an Architecture/Reference level of the platform and the software teams are working agile on the Component level, with a clearly organized mapping at the border.

Traditional management estimates the needed human resources by head count calculations based on expected development efforts (hours). This habit can be continued based on the role definitions of the classical standard processes. The related work then can be broken down into stories that are realized by T-shaped people in cross-functional team work within the agile organization, still working compliant to the detailed technical development sub-processes. The agile teams can easily track their efforts per Sprint from the task boards and the evaluated team velocity, and then the Scrum Master and Product Owner can compare it to the original estimations. Deviations should be discussed in the Rstrospective sessions.

Enterprise managers love steering committees, decision boards and PowerPoint reporting of melon projects (looking green while being dark red internally). This can still be supported by agile project teams, when they pass back the Sprint Goals as corrected milestones of the project plan, use Burndown Charts data as calculation base for the given PowerPoint templates, take the decisions (if any are made by accident) to the teams' Refinement sessions, and transfer the weird management view systematically into Epics and Stories. The Product Manager or Project Manager may take the role of the Product Owner or Scrum Master (different approaches are practiced in the wild), but should be strong enough to face the Enterprise managers to support the mapping.

I love to do Lessons learned sessions often, and the agile Retrospective events are nothing else for me, but now some teams tend to really doing it. Make an extra session/event for the interface to the non-agile environment, with people from both sides. Anyway, ensure that only a few topics are collected to be improved, and instantly add at least one action to the backlog of the next Sprint. Don't collect a thousand bad points and then do nothing! It is all about >improving standard processes< by best practices, team trial-and-error, or personal learning the hard way. "If you always do what you've always done, you'll always be who you always have been."