At its heart, agility is about how groups of people get meaningful work done. It's focused on teams. How to form them; how to get work to them; how to lead them; how to measure them; how to make them most effective. This thought does not just lie in the agile community. To thrive in today's world of rapid change and growing complexity, Peter Senge advocates in his book The Fifth Discipline that organizations become learning organizations and describes teams as the fundamental unit of organizational learning. It is not individual intelligence we need Senge says, it is collective intelligence. In a learning organization, teams build collective intelligence to gain a better understanding of how the organization operates as a whole, as a system, and can therefore derive better, more cohesive ways to improve it.
Much about the traditional world of getting stuff done works against that goal. Corporate organizational hierarchies create boundaries between and within vertical silos of knowledge. The benefit is growing specific competencies. It is how software developers become better developers; analysts become better analysts; sales representatives become better sales reps. It is how we set guidelines and standards to improve how the vertical does what it does. It sets focus and direction (within the vertical), and is how we often manage career advancement.
On the flip slide that same vertical structure impedes getting work done. There is no one vertical knowledge silo that can accomplish an organizational goal by itself. In the product development world, there is no one vertical that can grab a new feature and work it through the product development process to deliver it to the end customer. That takes collaboration. It takes the verticals working together toward a common goal.
Project Centric Organizations
To ease the silo navigation, we form matrixed, "horizontal", teams across the verticals. Although some view that as the agile concept of cross-functional teams, project teams have always been formed this way. Where agile team concepts really come into play is in how we view those teams, and what happens to them when projects conclude.
As the need arises to start new work, project centric organizations create teams on-the-fly from available (or partially available) "resources" with the requisite skill sets. They bring people to the work. Within individual project teams, collective knowledge is repeatedly built up during the execution of the project and rapidly discarded by disbanding the team when the project is complete.
Rather than focusing on true teams, the project centric model tends to focus on individual contributors, creating more inward thinking than outward thinking. Level of engagement, productivity, quality and predictability all suffer as a result. Worse yet, they perpetuate the silos of knowledge and there is little, if any, effort expended to improve the overall organization, the system itself.
Team Centric Organizations
Enter then the notion of true high-performance agile teams. These teams are mindfully formed primarily based not on technology concerns, but people concerns. These teams group people who can learn to work together as one. These teams have a good mix of technical competencies to be sure, but more importantly are comprised of people that can build trust in one another. That can assume more accountability together. That can experiment together; make decisions together; make commitments together; succeed and fail together; learn together. Together these teams build collective intelligence becoming Peter Senge's fundamental unit of organizational learning and therefore the fundamental unit of the organizational improvement that underlie agile values, principles and practices.
Two factors come into play with these teams. Dedication and stability. How many members of a team are fully dedicated to the team, and only to that team? How often does a member of one team move to a different team? Using the project and team data available in its ALM tool, Rally (now part of CA Technologies) has published some interesting analysis of these factors. Conventional management thinking believes that assigning people to multiple projects allows for better responsiveness to changing needs. Rally's data shows very little impact to responsiveness for teams that are less than 50% fully dedicated. The impact that is revealed however, is a significant reduction in productivity, quality, and predictability. Adding team stability into the mix, as teams become more fully dedicated (around 85%) and more stable (around 80%), organizations see a 60% increase in productivity, a 40% increase in predictability, and a 60% increase in responsiveness.
Because the project centric model is more focused on individual contributors, it inhibits the formation and long-term growth of more fully dedicated, stable, high performance teams. We need a new model, a team centric model that better respects the power of teams and strives to keep team together. Team Centric organizations do not bring people to work. Instead they bring work to teams. Dedicated, stable, accountable teams. As work streams materialize, management and teams collectively decide which team is best suited for the work and prioritize it within the team's capacity. The result brings not only the performance improvements that Rally identifies, but also the ability to build collective intelligence about the organization as a system. That collective learning enables a better understanding of the system, how problems actually occur within it, and how to solve those problems in creative, insightful ways that create the long lasting improvement that agility promises.
Productivity. Quality. Predictability. Responsiveness. Are these important to your organization?
If so, start today by changing your thinking around teams. Start today by viewing teams as the corporate asset that they really are. Start today by moving away from being a Project Centric organization of individual contributors to a Team Centric organization that focuses more on people and how they work together in high performance teams that achieve your organization's highest goals.
Project Aida has a budget of $725,000 and is required by June 1st. All the requirements have been defined for a new content management system to appropriately archive sensitive corporate information within the defined retention polices. The delivery team successfully implemented all the defined requirements and the new system was ready to go June 1st. Final costs for the project total a bit over $723,000. Of the 19 departments targeted for the new content management system, three are actually using it. Was this project successful?
Did you take piano lessons as a kid? Most of that instruction centers on playing all the right notes, at the right time, using the right fingers. It focuses on the mechanics, but is that enough? Is that why famous musicians are famous? Do people swarm to a Springsteen concert because he plays (and sings) all the right notes? Vladimir Horowitz played the Brahms 2nd Piano Concerto literally thousands of times. Did he continue to pack concert halls because he used the right fingers? Musicians gain fame not because of their mechanics, but because of how they use those mechanics to "make music".
In June 2014 oil (WTI) sold for $105.79 a barrel. Today that same barrel sells for less than $50, and there is little certainty of where it is headed. The oil patch is in for a period of uncertainty and volatility. There is no better time to be agile. There is no time when it is more important to be agile.
Change takes some level of disruption so change is often delayed in deference to the comfort we feel in today. For the oil patch at least, current business conditions have supplied that disruption. The smart money is on those who view that as an opportunity. In times of disruption we have a choice. We can react by pulling back into the supposed comforts of the past, what we have done, what we know to do. Or instead we can be proactive by using the disruption to build leaner, more resilient, more responsive, more agile organizations for tomorrow.
Software development is about answering questions. Answer the right ones and you have a viable, useful, well-thought of product. Answer the wrong ones... well, we've all see that software at work. Based on my experience working with software teams, here is the series of questions I believe keep us on the path to successful product launches.
The big up front question of course is What is the business problem we need to solve? Ensuring a good answer to this question is our first critical step.
The culture change conversation seems to have cropped up again a number of times lately. It always makes me cringe a bit as agile adoptions should not be focused on changing culture. That is not our goal. Our goal is to do purposeful work that enhances the business; and to leverage the strengths, passions and diversities of the people doing that work.
Does that sound like your Scrum team? Is the sprint goal that big of deal? In short yes, the sprint goal is a VERY BIG deal. Here's why.
A team that regularly misses its sprint goal is thought of as a team that:
- can't plan its work
- does not really know its own capacity
- does not estimate stories and/or tasks very well
- does not have sufficient competence to do the work they have been asked to do
- is not trustworthy -- they don't do what they said they will do
Have you heard a manager say this about his or her team? As I have started agile adoptions in various organizations I’ve heard it pretty frequently, and I heard it again just last week. It is a common and understandable lament from the first layers of management that surround delivery teams. Oddly enough though, I think it is well intentioned.
Think true collaboration for distributed teams in not possible -- think again. Here is a stunning example of combining shared vision, barely sufficient control, and technology to achieve fearless results.
Watch Eric Whitacre's presentation at TED2011.
See Mary Abraham's original post Chaos Control Collaboration here.
I've been asked about doing agile maturity assessments a lot lately, so I have started looking at some options again. I have always shied away from doing agile maturity assessments because there is a significant potential for them to do more harm than good. Many assessment tools make being agile the goal and present some idealized "perfect" vision of agile to rate yourself against.
Agile leadership is more about influence than control; more about providing service than direction. For those new to agile leadership, language becomes an important tool to help with that mind-shift. Here are three common phrases for any agile leader to begin with.
How does your team answer that question? If your team cannot credibly answer this question based on empirical data, you are missing a key element of iterative, incremental development.
One of the goals of iterative, incremental frameworks such as Scrum is to enable stakeholders to make informed business decisions based on the reality of the effort at hand. That does not come for free, or without wrapping our heads around some new thinking. "When will we ship?" If you want your team to answer "we will ship at the end of sprint X" with credibility, then a number of things have to be in place.
As the use of agile techniques has become more common, many organizations are deciding to take the plunge into agility to see what it is all about and how they too can reap its benefits. Unfortunately, some of these organizations are unprepared for what comes after that decision to try agility and struggle as a result. As with anything, there are many ways for agile transitions to fail, but in my experience the following three failure modes are among the most common. Avoiding these won't guarantee success, but it will put your transition effort on a good path forward and greatly increase your chances of attaining the promise of agility. T
Agility as the Goal
This failure mode is driven by the ever growing volume of agile success stories that lead organizations to jump on the band wagon without realizing where they are jumping. Becoming agile for the sake of becoming agile is an awful goal. Nothing good will come of it. It all but guarantees failure because we have not defined what success is. Agility is about organizational improvement. What are we trying to improve? What problems are we trying to solve? What is really holding us back?
Page 1 of 2
- You are here:
-
Home
- Blog
