Email the Author

About the Book

So many companies are struggling this way right now. According to many researches on the use of Agile/Lean methodologies, Agile practices for developing tech products are massively used around the globe. There are many teams that domain planning and organizing practices like writing user stories to represent requirements, crafting and prioritizing a backlog or using relative weighting to estimate the size of user stories and their delivery capacity. Many teams deal really well with agile engineering practices like TDD, refactoring and pair programming. And many other do really good developing hypothesis, crafting A/B tests and delivering small pieces of well-crafted and functional software in small chunks of time so they can look for fresh and focused feedback on the recent features.

Although all these practices are of great value for the code quality, team organization and product features results and usefulness, they’re all team practices. If well used, they can make a team become really well-organized and focused on their results. But that’s all.

Outside the team there’s a huge and anxious world that’s actively seeking for information about integrations, dependencies, readiness, dates, performance, security, availability and so more. Although it’s a management anti-pattern to keep this outside world 100% informed about every tiny anxiety of them, it is also a management anti-pattern to keep them blind. And it surely helps to increase the anxiety and the unnecessary interruptions a team suffers from an ecosystem seeking for answers they don’t have right now, but should have to keep going forward.

None of the agile team progress charters, reports or tools that focus on informing outside teams or areas about the progress or deliveries of a team for some few months ahead is sufficient to keep a company well-aligned on its communication. The level of information is pretty low and it easily becomes overwhelming and hard to manage and even publish or communicate. This level of information - team-level information - may also change so much during a month and suffer many variations that it simply become untrustable. It’s so much information about execution, and not so much information about strategy, delivery or availability of features. From the teams’ perspective, they’re well-organized, well-planned and executing like a charm. But from the company’s - and internal customers’ - perspective, they’re developing anything but the features and products they’re expecting to have by the end of a quarter. Also, the language of the information a team makes available may not be clarifying and assertive enough - again the low level problem - for the company product/features level.

Those people that keep themselves around a team seeking for information of completeness and delivery I call “periphery”. The teams that depend on the product of a team, the managers and directors of the company and internal customers need another level of information, communication and language. For the set of tools and charters a team can use to keep its periphery informed I give the name of “Peripheral Agility”. And every team should be aware of how they’re structuring their Peripheral Agility and why. And every organization should be able to help their teams to structure their Peripheral Agility.

About the Author

Rafael Nascimento

@rafanasil

Agile Coach and software developer with 15+ years of experience in the IT market, building applications that help people, growing multidisciplinary, self-organizing teams and mentoring/coaching large companies and startups during their Agile adoption process. My goal is to facilitate people's lives through simple software and cultivate corporate environments that inspire people to reach their full potential.

I truly believe that each company has its own way of doing Agile, because none of their daily challenges and living personalities are the same.