With the signing of the Agile Manifesto approaching its 20 year anniversary, why has Agile had so much difficulty evolving to meet modern needs? In fact, it seems to have intentionally pushed itself to obsolescence. I am not alone in this belief. If the transformative nature of it is so powerful, why are we still talking about Agile. Isn’t it time to level set the expectations requiring those career minded executives, software developers, business owners and startup founders to come to the table already fully immersed in the Agile practices of the last 20 years? After all, do you really want to transform yourself or your organization back to 2001? Let’s not transform to Agile, instead transition to Agile and then move beyond.
Let’s begin by leveling that expectation. Let’s make the assumption that we have the critical mass of people with innate agile knowledge and move on to high performing teams: The HiPER TEAM. Let’s act extreme in the spirit of Extreme Programming and do our part to evolve. My hope, through the HiPER TEAM, is to give back to the Agile community that has been so inclusive and supportive of my journey.
So what is wrong with today’s Agile? Perhaps many things are wrong, but let’s start with dogma. When people attempt to apply dogma to Agile by saying things like “You’re not Agile,” or “That’s not Agile behavior,” we have lost our way. An organization’s ability to grow is severely limited by this attitude. It reverses progress in what should be an ever evolving and maturing environment. Trying to ‘be Agile’ is an ambiguous, moving target, which is intentional and, basically, a good thing. When we try to hit that target with dogmatic tools and behavior, Agile health radars or the subjective evaluation of supposed experts, well, “Houston, we have a problem.”
Let’s move past this destructive behavior. In fact, let’s move on from Agile by removing it from our vocabulary, at least for now. Let’s move on to the HiPER TEAM so we can employ the amazing practices of the last 20 years to create high performing environments. In no way can anyone declare you are not behaving HiPER because there is no such limiting definition. In fact, let’s never limit ourselves again.
The HiPER TEAM is built emphasizing, but not limited to, the learnings and practices of the last 20 years with metrics that can be applied to any team. With that in mind, let’s build out a version of a high performing environment. I’m hoping the definition and example below might help you build your own.
The HiPER TEAM
The HiPER TEAM needs three components:
* A delivery team of high performers
* A continuous learning program fueling and nurturing team member development
* A way to measure the delivery performance and value of delivery
The Team
Remember what a few folks in the mountains of Utah stated back in 2001? Something about “Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done”. Well let’s really emphasize this idea. In fact, let’s put it on steroids.
Build your team with innately Agile, motivated individuals who love collaboration and learning. Suffice to say, they are already eating Agile for breakfast, lunch, and dinner. It is instinctual, ingrained in discipline, habits and experience.
Pull in all your favorite practices, frameworks, and initiatives from the last 20 years to create a powerful combination of rapid delivery, quality, and sustainability. Pull in the best of Scrum, Kanban, Extreme Programming (XP), Behavior Driven Development (BDD), DevOps, User Stories, User Story Mapping, and all others deserving mention.
Recommend that the HiPER TEAM has the following traits. It should, after all, look a little familiar:
2-5 team members
Cross-functional, cross-skilled, and self organizing
Highly developed client engagement and business development skills to complement technical excellence
Innate Agility, pulling from frameworks and practices of their choosing
Minimal reliance on roles, frameworks, and methodologies
All the skills and business domain knowledge needed to deliver exists within the team
Continuity – the team stays together delivering solutions with a wide variety of technology stacks and business domains
Highly developed sense of teamwork
Continuous dedication to learning
Continuous Learning
If the team plans to stay together, a dedicated learning component must exist. This will allow them to deliver solutions across tech stacks and business domains with ever increasing competence and performance. The learning component accelerates performance by adding new skills, cross-skilling, and exposing the team to the latest industry trends. As a welcome side-effect, it maintains the health and sustainability of each team member.
Given the unbelievable speed that cloud providers are rolling out innovative new offerings, a dedication to continuous learning has never been more critical to maintaining the high performance of your team.
Job satisfaction is often measured through Autonomy, Mastery, and Purpose (AMP). An argument could be made that the learning component emphasizes and supports all three, but it is unquestionably dedicated to mastery.
In summary, Continuous Learning:
Is the fuel that empowers the team to maintain high performance with mastery of a wide variety of tech stacks and business domains
Keeps the team together; the real power lies in continuity
Supports learning new business domains, tech stacks, and entirely new disciplines, enabling aggressive pivots towards business goals
Nurtures the cross-functional, cross-skilled team by design
Adds and maintains learning targets to the team backlog
Assesses and maintains the health of team members
Measure
How does a team know it is a high performing team? They need a way to measure delivery performance that is agnostic of team size and practices so we can both compare to other teams and assess continuous improvement ideas. A good metric must be simple to employ and not burden the team. Here’s a summary of the goals of a good metric:
Simple to employ, preferably automated, and does not burden the team
An objective measure to assess productivity, continuous improvement, and value delivered
Must apply to any team, team size, or methodology
Measure time-to-value, feature usage, cost, and business value delivered
Measure the value that is most important for their organization
Specific Example of a HiPER TEAM
Blink Fusion is designed to help startups. Our goal is to leverage many of the best practices from the last 20 years, paired with cloud native tech stacks to rapidly build out the business and technology for early stage startups. Suffice to say we have learned a lot and remain an excellent incubator for ideas around the HiPER TEAM through actual execution. This sets the stage for rapid delivery of value with absolute attention to software craftsmanship.
The below exemplifies a HiPER TEAM that we are experimenting with putting into practice. Our goal is to create and support an environment of cross-skilling by extending the idea of the full stack developer to not only technology stacks but also business advisory, facilitation and consulting.
Personal Trainer
Commit to Continuous Learning by adding a personal trainer to the team to help team
members in their journey. As with all team members, the personal trainer is also cross-functional.
The Personal Trainer:
Customizes training programs for each team member
Intimately knows each person’s learning style and personal goals
Assesses health and sustainability of each team member
Vets hundreds of courseware options, selecting highly rated courses that best meet the team member needs. E.g., Udemy, AWS, and Linux Academy
Rapidly on-boards new team members
Supports team members as they prepare for certifications
Strategic planning to best position the team to meet future demand
Researches topics, provides on-demand training, and lunch-and-learns
Writes curriculum in development of custom courses
Prepares just-in-time training for upcoming projects
Suggests team members take on particular assignments to reinforce learning
Measure
Feature Delivery: Define initiatives as features to deliver the full, targeted business value rather than an arbitrary, small slice selected simply to appear to deliver something. Through a combination of an in-house developed Jira plug-in and usage analytics deployed with each feature, automate the metrics to include status notifications.
Track the following metrics:
Lead Time - Time from when feature development begins to release to production - This it the measure of time when feature enters the Kanban in Jira to the time its deployed to production
Weighted Lead Time: Time to value - Time from when development begins to time that usage metrics goals are met - The calculation is Lead Time + Time it takes to meet usage analytics goals
Cost to deliver feature - Cost to deliver a feature with a clock mirroring Lead Time
Business Value : Usage Analytics - How much the feature is used in production - Each feature is deployed with usage analytics attached generally at the micro-service level - Reports are generated indicating when Weighted Lead Time is met - Usage reports continue for all features
Conclusion
The HiPER TEAM is an ever evolving environment that, by design, learns, pivots, and grows to maintain high performance and rapidly deliver high quality software products.
The team is created with people who want to become high performing together as a single entity. They are dedicated to delivery, continuous learning, and to each other. Long term continuity and teamwork are an important part of their ability to perform at ever growing levels.
The team measures its performance against a simple, automated metric that can be applied to any other team. The metric provides the evidence that the team is truly a high performing team. No dogma, adherence to framework rules, or subjective evaluation of an ‘expert’ is required.
Are you or your teams ready to be part of a HiPER TEAM? Let’s get started!
Written by: Mark Thias
Mark is a Founder, Software Engineer and Agile Coach with 30+ years in software development and consulting. Mark is currently working to create and incubate early stage startups in Chicago.
Readings
Matts, Chris. Weighted Lead Time
Murphy, Brad. The Apocalypse of Cloud-Native Is Already Here...And Your Agile Transformation Will Not Save You
https://www.linkedin.com/pulse/apocalypse-cloud-native-already-here-your-agile-save-you-brad-murphy/
Beck, Kent. Extreme Programming Explained: Embrace Change. Reading, MA: Addison-Wesley, 2000. Print
Kawasaki, Guy, and Michele Moreno. Rules for Revolutionaries: The Capitalist Manifesto for Creating and Marketing New Products and Services. New York: HarperBusiness, 1999. Print
Thiel, Peter A., and Blake 1986- Masters. Zero to One: Notes On Startups, or How to Build the Future. Unabridged. [Westminster, MD], 2014. Print
Commenti