Feature flags are ways to control the full lifecycle of your features. They allow you to manage components and minimize risk. You can do pretty cool things like roll out features to certain users, exclude groups from seeing a feature, A/B test, and much more. Basically, deploy when you want and release when you’re ready. In this In this presentation we'll discuss the following topics:
If a Team of Teams methodology can win a war on terrorism imagine the benefits our IT organizations would gain by applying its principles to software development. This article is part 2 in my series on Team of Teams. Part 1 highlights General McChrystal's transformation to a Team of Teams and its benefits. Part 2 focuses on strategies we can adopt to help transform IT organizations into software development Team of Teams.
Which intersection below most closely resembles a Team of Teams? A free flowing intersection with self-driving cars (see Figure 1) or a traffic light controlled intersection with traditional cars (see Figure 2)?
Comparing self-driving vs traditional cars from a Team of Teams perspective
Self-drivingcars
Traditionalcars
Notes
SharedConsciousness
Yes
Limited
Self-driving cars are constantly communicating their route and speed in realtime. Traditional cars are limited because they can only communicate their route via turn signals.
Trust
Yes
No
Self-driving cars have trust because of their constant sharing of accurate information. It's difficult to trust traditional cars because they are unpredictable and have limited information sharing.
Empowerment
Yes
No
Self-driving cars are empowered to proceed full-speed through the intersection because of their shared communication and trust. Traditional cars must wait for a green light (command structure) to proceed due of their limited trust and information sharing.
Why Software Development Team of Teams?
How efficient is your team able to release a small task to production? After adopting a Team of Teams methodology the General’s teams were able to go from intel to strike within an hour. Their efficiency gains allowed them to execute 17 times more raids per month. Our goal should be the same - from requirement to release within a few hours resulting in 17 times more releases a month. Let's review the top strategies we can apply to build stronger and more efficient software development Team of Teams.
Bake craftsmanship (continuous improvement) into the process
Do you think the General's teams didn't train, condition or workout? It's part of their lifestyle and built into their process. I classify craftsmanship in two categories: training and refactoring (enhancements, defects). The The Phoenix Project ( p229) recommended an allocation of 20% for continuous improvement activities. Create a backlog exclusively for these types of tasks and empower your teams to continuously improve their skills, process, and software.
Reduce batch size
When the task force launched a mission their goals were small, precision strikes. Small strikes improved their frequency (10 strikes a day). If your teams are fortunate enough to have the efficiency of a CI/CD pipeline then the only limiting factor to daily releases is batch size. Try releasing at least every iteration or more often (daily). Frequent releases promote speed to market, reduce risk, are simpler to manage, and produce quick wins building team morale. Teams must be empowered to reduce batch size. CI/CD pipelines provide little value if releases are monolithic.
"Power up" to improve team health
Have you ever played Fortnite? Many of the team strategies applied in this battle royale game apply well to software development. One strategy in particular is the “power up” strategy or boosting your teammates health when they are running low. On a software development team we can boost the health of the overall team by information sharing and paired programming. The most effective team I have been on was a client project in 2003. This project had around 30 developers and we were required to pair program 100%. Pairs needed to rotate drivers and a new partner was required for the the morning and afternoon sessions. Software quality was very high and knowledge sharing with a new partner was an effective way to "power up" the resources across the team. Paired programming improves craftsmanship (continuous improvement), reduces defects, improves information sharing, and builds trust.
Transparent leadership
Having a transparent leader that posts frequently on Twitter isn't all bad. Has our president read Team of Teams? General McChrystal said his transparency (all calls on speakerphone and O&I briefings with thousands) saved many lives. In addition, his transparency greatly improved trust and shared consciousness across all teams. Perhaps we should try the same techniques. Would transparency and trust improve if we removed all cubicle walls, removed all office doors, replaced all phones with speakerphones, and made everyones calendar transparent?
Build a liaison program
A liaison program was General McCrystal's primary strategy for building trust across his teams. From a development perspective, liaison programs are opportunities to join other teams for short-term projects or assignments. In addition to improving trust these opportunities also expose developers to alternative coding practices, techniques, and team dynamics. Furthermore, moving cheese or trying new cheese often sparks new learning and growth opportunities from a team and individual perspective. Teams without a mature shared consciousness will be very resistant to this type of change highlighting a flaw within their own team. Anyone adopting new cloud or platform technologies? What better way to learn than actually join their teams for several iterations.
Continuous gardening
Managers have the most important role in regards to tending our Team of Teams. In particular, they need to provide water, fertilizer, and weed control for the resources across the teams:
Water - growing trust and transparency. Water is the most important ingredient. A garden will not survive without water and a Team of Teams will not exist without trust and transparency.
Fertilizer - building "power up" opportunities for resources to learn and grow. Resources won't reach their full potential if they are not given the opportunity to grow and learn. In addition, incentivize developers to attend conferences or meetups, watch YouTube developer channels, or contribute to open source.
Weed control - eliminate rubber stamps and command structures that reduce team productivity. Without weeds teams will become more empowered and efficient.
Build an empowerment radar
Does your team have high, medium or low empowerment? Document rubber stamps, command structure decisions, and shared consciousness limitations that impede a free flowing software development life cycle. Then, tend the garden to remedy those limitations. Remember, empowerment fuels motivation - an individual or team who makes a decision becomes more invested in its outcome. The goal is to eliminate these impediments so your team can become as efficient as self-driving cars.
A Team of Teams is, "An organization within which the relationships between constituent teams resembled those between individuals on a single team: teams that had traditionally resided in separate silos would now have to become fused to one another via trust and purpose” (p132). To win the war on terrorism General McChrystal was quick to realize their traditional management style and team dynamics (see Figure 1) needed to adapt to keep pace with the more agile and adaptive Al Qaeda enemy in Iraq. This article is part 1 in my series of Team of Teams. Part 1 highlights General McChrystal's transformation to a Team of Teams and its benefits. Part 2 focuses on strategies we can adopt to transform IT organizations into Software Development Team of Teams.
Figure 1. From Command to Team of Teams
Why Team of Teams?
General McChrystal's teams (SEALs, Army Special Forces, Rangers) were able to execute operations 17 times faster. With their old command structure they managed 18 raids per month; with a Team of Teams they preformed 300 raids a month. These efficiency gains were the direct result of their improved information sharing, trust, and empowerment resulting in more effective decision making.
The Ingredients
A Team of Teams strategy is built upon three key ingredients: shared consciousness, trust, and empowerment (see Figure 3). Let’s review each and highlight the implementation strategies General McChrystal’s adopted to transform an organization of thousands across 70 remote locations.
Figure 3. Team of Teams ingredients
Shared Consciousness
This ingredient is a generalized awareness about what other teams are doing and sharing information. The book reviewed two tragic examples that were direct results of failed shared consciousness - the Apollo project and GMs faulty ignition switch. Both examples highlight the importance of shared consciousness on critical projects.
How much time should we allocate to information sharing across teams? The best answer I found was this quote pertaining to the Apollo project, "Specialists continued to do specialized work, but they needed an understanding of the project as a whole, even if establishing that understanding took time away from other duties and was, in some ways, “inefficient”. NASA leadership understood that, when creating an interactive product, confining specialists to a silo was stupid: high-level success depended on low-level inefficiencies. Even the engineers most ardently opposed to systems management found that many technical problems could be solved only by sharing information" (p149).
Here are a few strategies General McCrystal applied to improve their shared consciousness:
They moved teams to open workspaces (p159).
General McCrystal never used his private office, instead he sat in their open workspace and took all calls on speakerphone for everyone to hear (p163).
They had a daily O&I (operations and intelligence) briefing that was the core of their transformation. This meeting pumped information about the entire scope of operations to all members of the Task Force and partner agencies. It also offered everyone the chance to contribute. The O&I was a hour and a half video conference across seventy remote locations with thousands of people (p171, p227-228).
They didn't want all teams to become generalists. Rather, they wanted to fuse generalized awareness with specialized expertise (p153).
Trust
Trusted relationships across teams is a positive enabler for information sharing and promotes team empowerment. Trust is the most important ingredient of the three. Without trust shared consciousness and empowerment will not exist.
Here are a few strategies General McCrystal applied to improve their trust:
To build trust between the different teams (SEALS, Army Rangers, Army Special Forces) they took one member from each team and embedded them on the others for 6 months. Each group was incentivized to send their best resource because they were representing their organization. There was great resistance to this but as a result the teams built stronger connections (p176).
More than directing, leaders must exhibit personal transparency. Team members must be allowed to monitor the leader. This is the new ideal (p232). The General's transparency was demonstrated during their O&I briefings, open workspace participation, and broadcasting calls on speakerphone.
Empowerment
Empowerment is when leadership gives the team approval in decision making. When Task Force units (SEALS, Army Special Forces, Rangers) would wake up General McChrystal for air strike approval he’d always ask if they wanted him to approve the strike. Life or death decisions confirmed the role as an important leader but the General often questioned his value in the process because he’d rarely have groundbreaking insight. His approval was a rubber stamp that slowed the process.
Here are a few strategies General McCrystal applied to enable empowerment:
With shared information teams could “do the right thing” rather than “do things right”. People at every level of the organization had the information and connectivity to determine what the right thing was, in real time. But, held back by their internal processes, they lacked the ability to act on that determination (p203).
The General was always ultimately responsible and more often than not those below him reached the same conclusion. This way their team would be empowered to do what was needed (p209).
Eventually a rule of thumb emerged: "If something supports our effort, as long as it is not immoral or illegal," you could do it (p214).
An individual or team who makes a decision becomes more invested in its outcome (p215).
Sustainable Garden
With our three key ingredients in hand, the most important step is growing and maintaining the sustainable garden (see Figure 4). This becomes the primary responsibility for leaders. General McChrystal spent most of his efforts growing and maintaining his Team of Teams. Without constant watering, fertilizing, and weeding the garden becomes unsustainable and breaks down.
Figure 4. Leaders tend the sustainable garden
With three key ingredients, cultural change, transparent leadership and continuous gardening the General's Task Force transformed itself into an organic entity that dramatically improved their speed and precision. In part 2, we'll focuses on strategies we can adopt to transform IT organizations into Software Development Team of Teams.
What are the characteristics of a successful app? Is it revenue, number of downloads, app rating, active user count, or your crash-free rating? While each metric plays a role in overall success the important factor is we have the ability to improve the metrics that are most valuable to us. For example, a primary goal for our HealthPartners app this year was to improve our 3.8 app rating. Let's explore the strategy we applied at HealthPartners that improved our app rating to 4.6 in just 12 days. This strategy is actually easier done than said.
Identify the top 3 'Make Good Happen' moments in your app
The most important tip for a successful user review is a timely prompt after the user has finished a simple and valuable workflow. For example, in our HealthPartners app we identified these following workflows as our top 'Make Good Happen' moments:
After a user refills a prescription
After a user schedules a clinic appointment
After a user submits an account reimbursement
After users complete these simple and valuable workflows they will be more likely to submit a positive app review. According to our iTunes Connect metrics 93% of our reviews have been 4 stars or higher.
App ratings
Trigger app review prompt
Prompting an app review requires minimal code.
if #available(iOS 10.3, *) {
SKStoreReviewController.requestReview()
}
Apple released their rating and review capabilities in iOS 10.3. Therefore, a version check is necessary if you support a prior iOS version. Otherwise the requestReview() trigger is quite simple. However, Apple will only trigger a prompt within your shipped app 3 times a year. Apple's requestReview() algorithm ultimately determines the frequency and timing of the actual prompt.
Limit app review prompt to core users (optional)
Since it's not clear when Apple may display the review prompt I wanted to avoid an app review prompt for first time users. A core user or returning user is more likely to provide positive feedback. Therefore, I limited the review prompt to core users.
App rating trends mashup
Appbot recently published an article comparing app rating trends titled, "Has iOS 11 really affected star ratings?". I performed a mashup and included HealthPartners within their rating diagram to gather a greater perspective of the improvement our app has experienced.
Are these tasks easier done than said? Simply add review prompts to your apps top 3 'Make Good Happen' moments and your ratings will improve dramatically too.
