It’s no longer the kid it once was. From 1957 to 2016, Agile has progressed through the stages of cute kiddo, awkward teenager, eager twenty-something, to mature thirty-ish adult. With this new stage in life comes a lot of positives (steady growth, deepening maturity) but also some negatives (hesitancy, failed adoptions) as shown in the 2016 report.
Here are some of the most telling trends found in the annual State of Agile report.(more…)
Books like Khoi Tu’s “Superteams” and articles in the Harvard Business Review discuss what makes successful, high-performing teams. In the Agileverse¹, we talk a lot about self-organizing teams, transparency, servant leadership, and the power of cross-functional teams. One of the important aspects of these teams is the sharing that occurs and how it leads to their success. Successful Agile teams share. Agile teams recognize that to be successful they have to move away from the traditional ego identification with their work product and toward something collaborative.
Let’s consider the first of the four value statements in A Manifesto for Agile Software Development (“The Agile Manifesto”): Individuals and interactions over processes and tools. That word “interactions” is critical in all of this. As one colleague said to me ages ago, “processes and tools don’t create software, people do.”
I’ve identified several characteristics that I’ve found to be shared by those successful teams. I call it Agile Shared CARGO™. And of course, being a techie, it’s an acronym.
Let’s dig in…
CARGO = Commitment, Accountability, Responsibility, Goals, and Ownership
Since these Agile transformation misalignment pitfalls are straightforward and related to one another, we thought it would be easier to deliver them in one post. These pitfalls are geared more towards the IT Enterprise rather than a product shop but still good lessons to keep in mind. Read the previous posts if you need a refresher.
Agile Transformations Pitfall #9: Teams Not Aligned With Customers
IT organizations are shifting the focus from projects to products. This is a good thing for a few reasons.
In a project-focused environment, a team is assembled for a specific project and re-allocated to another when complete. This has two impacts:
Breaking the team apart and moving members around will cause a decrease in performance. Everything you have invested in team building and domain knowledge by the team is lost.
Customers lose support and attention. When a team goes away after the project is done, in order to get any additional enhancements to the product they have to get another project approved. y This typically requires getting something approved again through their portfolio management budgeting process which may happen months or years later.
And…we’re back to our regularly scheduled program. Before the holiday break, we discussed Agile Pitfall #7, Not Improving Technical Practices. Time for number eight, solely focusing on optimizing at a team level instead of optimizing across the whole organization.
How leadership deals with issues raised by the eighth pitfall could mean the start of a great era in the organization….or a failed transformation.
It’s common for leadership to believe that as long as the team is implementing Scrum and all of its trappings, the transformation is going smoothly. In the beginning, that may be the case. However, as the team matures with agile practices, they will face roadblocks they cannot remove on their own. Perhaps it’s a new testing environment or another test engineer–whatever it is, teams will need to escalate these issues to management.
Here, leaders encounter a fork in the road. How they respond to their team can make or break an Agile transformation.
While the team is responsible for the day-to-day implementation of Agile, it’s the organization’s responsibility to support the endeavor. It doesn’t say much for the leadership team if they ask the team to adopt Agile but doesn’t do anything to remove impediments or ensure success.
Did they really want the team to BE Agile or just SAY that they are? What effects will these actions (or lack of) have on trust between the team and leadership? Leaders need to change their questions from, “How productive is the team?”, to “What are you learning?” and “How can I support you?”
According to a survey by Interaction Associates on workplace trust, employees believe that a high level of trust in leadership is necessary for them to be effective at their jobs. Of the five ways leadership can build trust according to employees surveyed, “Set me up for success with learning and resources” was number three. Other ways include:
Soliciting input from the team especially if they will be affected
Providing background information when possible
Admitting mistakes
Not punishing people for raising issues
As issues are raised and roadblocks identified, it’s imperative to have a system for handling them, particularly with new transformations. With Agile, the management team is freed up to work on cross-team, organizational concerns since they are no longer in the day-to-day. One solution is to have a team of managers who help solve problems.
Another solution is to create a Transformation Team with an executive team member championing the transformation. The Transformation Team consists of cross-functional representatives who are excited and passionate about the new direction. Having the management team or the transformation team (having both is better), will help to optimize the whole value stream and shorten time to market.
Check out the final installment of the series, Pitfalls #9 and #10. Catch up on the series by reading pitfalls 1 – 7 listed below.
Becoming Agile is not just a process change. That’s the first and probably most common misconception–and pitfall–in an organization’s Path to Agility®. There are several facets of an Agile transformation, and a big one is to improve technical practices. (more…)
Part 6 in our 10 Agile Transformation Pitfalls and How to Address Them
Being one of many is a red flag on the Path to Agility®. The success of your Agile transformation depends on cross-functionality from feature teams. Image courtesy of Ohmymag.com
Look around you. If you and all of your neighbors have the same job title, it may be time for a new seating arrangement. While there are some advantages to having specialist or component teams, for the most part, they create silos and impede communication. In our sixth installment of our Agile transformation pitfalls series, we discuss how your definition and makeup of “team” could be impeding your organization’s adoption. Here are links to previously discussed pitfalls if you need to catch up.
You would think that within that behemoth of a project plan required of waterfall processes there would be a page or two outlining fixes and time needed to tidy up. But for the most part…there isn’t. Bugs, misses, lost features are part of what I like to call, the “hidden project plan,” time spent after the end of the plan devoted to cleaning up work kept from stakeholders. Unfortunately, this is the work that draws the team away from their current project and back to the project they thought they’d finished.
I’m no saint. During my 35 years in tech, I have participated in my share of hidden project plans. However, it didn’t leave me feeling very good about my work. This experience is what drew me to Agile and why I stayed. With Agile, there is no hidden agenda as visibility and transparency are core to the practice.
Agile Transformation Consists of Phases
Throughout our experience training, coaching, and guiding organizations through their Agile adoption, we have determined that an Agile transformation consists of five stages.
For people outside the Scrum Team, it can be difficult to decipher the finished product from code. Agile can help solve issues arising from this inherent challenge. When you walk into an Agile organization, there are physical signs that work is being done. Ideas are transformed into user stories which are written down and added to the backlog or on the Sprint board. Post-its and note cards are taped in organized columns marking progress. Release plans and burnup charts are displayed for all to see.
In addition to visual cues, there are also auditory signs of work. In fact, increased vocal communication is hallmark to an Agile transformation. Talking to your neighbor is faster than email; face-to-face provides more clarity than emojis. Video and task management technology allow distributed teams to also communicate in an efficient manner.
Daily stand-ups allow for teams to discuss what they are working on and remove roadblocks at the task level while sprint retrospectives make room in everyone’s schedule to applaud successes and fix broken processes at a higher level. And we shouldn’t forget sprint reviews as they showcase work to stakeholders and allow for on-the-spot feedback.
Making Progress
Without conquering visibility, an organization cannot get to the next phase of the Agile transformation, Predictable. It’s very difficult to know how much work will be accomplished without analyzing data, you can’t analyze if there was no data gathered, and you can’t gather what is not communicated.
Eliminating the hidden project plan takes guts because it can leave one vulnerable. However, having processes and meetings in place to master the visibility phase can make life easier for the communicator and recipients.
What has been your experience with the hidden project plan? How do you communicate and manage tech debt and bug fixes? Tell us about it by commenting below.
For more on our approach to building lasting business agility, you can check out our Transformation Servicespage.
Part 5 in our 10 Agile Transformation Pitfalls and How to Address Them
With Agile, internal stakeholders, team members, and management have visibility into team activity like they’ve never had before. This transparency is a powerful asset, and how it is wielded has a large impact on the success of an Agile adoption or transformation. This blog discusses pitfall #5 in our blog series, 10 Agile Transformation Pitfalls and How to Address Them. Read about the previous pitfalls in our series:
Unlike a carpenter building a dresser or cabinet, you can’t physically see what a developer is building. Agile transparency allows visibility into the virtual. Often when an organization is implementing Agile, this is the first time anyone on the team has had this sort of visibility available to them. To a manager, this extreme transparency sounds like a dream. To a team member unsure about the motives of leaders, this can seem frightening. This is why successful Agile teams need a substantial amount of trust between teams and managers. For team trust to be cultivated and earned, transparency has to be used well, not abused.
Part 4 in our 10 Agile Transformation Pitfalls and How to Address Them
To the change agents spearheading Agile transformations in their organizations, the benefits seem obvious. Why wouldn’t everyone want their team, or organization, to be Agile? But assuming everyone is on board can create a serious void of communication, leading to misaligned leadership, and ultimately, an organization that struggles to be truly Agile. This blog discusses pitfall #4 in our blog series, 10 Agile Transformation Pitfalls and How to Address Them. Read about the previous pitfalls in our series:
IT professionals adopt Agile for many reasons based on a diverse set of business goals, including improving time to market, reducing risk, producing better quality products, and boosting culture and morale. While numerous case studies and analyst reports prove Agile can meet these needs, because the business goals are different in every organization, so are reasons for an Agile adoption.
Organizations cannot afford to assume that everyone understands or supports a transition. The assumption that everyone understands or supports implementing Agile can be catastrophic. Let’s look at an example of the chaos lack of alignment can cause.
Open communication and over-communication is vital.
If the project manager of a traffic bridge does not communicate with the builders, the bridge might never get finished. If the builders don’t communicate to the project manager, the bridge will likely not turn out to be what it was meant to be. Likewise, a transformation or Agile adoption requires buy-in from the bottom, middle, and the top of technology organizations, regardless of where the case for change is originating. You can ensure that your organization is aligned by following a few of the guidelines below. These guidelines have been developed over years in the field working with teams who are implementing Agile.
Avoid and fill communication vacuums
The first step to filling a potential or current communication vacuum is knowing what to say. The discontentment bred by a lack of communication is often due to not understanding the “Why?” behind the change.
Be sure to clearly communicate the reasons for the Agile transformation and tie the change initiative to significant company goals. Narrow it down to 2 – 5 items you’d like to improve or achieve the transformation. It is also important to communicate the message to everyone, not just a select group. This will keep team members from guessing and filling the communication void with resistance. Everyone needs to understand and have buy-in to achieve alignment. If you’re in leadership, be sure the rest of your colleagues hear the story as well as your tech team, who will put in a significant portion of the work to become Agile. If you’re a developer, be sure that your team and leadership understands and supports the transformation.
A key piece of communication is training. This is a great tool and experience to foster alignment. Train everyone, from the Scrum Team to leadership, at the same time. That way the team and leaders can ask questions, struggle, discover and achieve together.
Establish a transformation team
The most successful transformations we see have an internal cross-functional transformation team behind them.
Key members of a transformation team include:
An executive sponsor
A development representative
A QA representative
A business or customer representative
The team’s function is to own their organization’s change process, as well as contribute to driving the change across the broader organization. We recommend transformation teams approach change like a Scrum team, adopting the same cadences and ceremonies and practices as any other Scrum team. create and manage a transformation backlog, prioritize and accomplish tasks in 2 – 4 week periods.
Part 3 in our 10 Agile Transformation Pitfalls and How to Address Them
As more IT and software organizations transition to Agile, they’re discovering Agile to be a better way to get quality work done faster. They’re also discovering that the transition can be tough to navigate. This blog discusses pitfall #3 in our blog series, 10 Agile Transformation Pitfalls and How to Address Them. Read about the previous pitfalls in our series: (more…)
IT organizations are shifting the focus from projects to products. This is a good thing for a few reasons. 
And…we’re back to our regularly scheduled program. Before the holiday break, we discussed Agile 
Part 4 in our 10 Agile Transformation Pitfalls and How to Address Them