Over the last 48 hours, I’ve been engaged in some #NoEstimates conversations. A tweet this yesterday evening re- introduced a very interesting dimension to the conversation (at least in my opinion).
What risks are we possibly concerned about here? I can think of two related to the actual process of software development and one related to the people actually doing it, so in all 3 major risks (even though I wouldn’t be surprised if there are others):
- Risk of team not developing the right thing
- Risk of team not delivering on time
- Risk of team not doing their best
Getting It Right/Being On Time (Value 3, Principles 1 and 4 at least)
It is my experience that software development is largely non-deterministic and empirical. YMMV. (If this is not your experience, I’d love to hear about it and the software you develop). There is a significant amount of learning that occurs as the work is being done. Just pull any developer off any team and ask if they “figure things out as they do the work?”. I’ve been developing software long enough to remember a number of approaches to software development that tried to front-load learning via the use of documents and models of other forms. We still found ourselves learning a lot as we actually typed lines of code. We can debate ad nauseam as to whether our discovery process was broken and I imagine there are those who simply say that we should just get better at identifying and writing requirements. There may be some truth to that, but I’m positive it’s not the only way.
Agile as an approach to software development desires to exploit the uncertainty and learning that is inherent in software development. This post is not an Agile primer and yet a meaningful study of Agile methods/frameworks shows that the first two risks are actively being addressed all the time as the team works together to deliver working software. Remember the team includes the paying customer. They are part and parcel of managing the first two risks as we go along. They are part of actually providing a solution. If the customer is not heavily involved in the development of the solution, and yet wants a guarantee around the first two risks, then you may need another approach that lends itself to such an engagement – I’m not sure Agile is it?
So this puts us in the land of contracts. By contracts I am referring to any agreement (verbal or written) on what is going to be delivered and when it is going to be delivered – think funding models as well. When a team commits to delivering X scope in a period of Y, a contract has just been put in place. The nature of the contracts ultimately impacts the behavior of your teams, which impacts how software is truly developed. But we know contracts don’t guarantee results (think about all the prenup’s that have gone by the way side), they guarantee (maybe) a course of action when things go wrong. They can be an indicator of low trust.
This is an opportunity to go read up on what Agile contracts look like (there is no shortage of resources on this topic). But the essence of many of them is that the buyer makes small bets while remaining part of the team. Do they often bear a larger percentage of the risk? Possibly. They often reap a larger share of the reward as well. What they don’t do is handoff a problem and say “see me when you’re done”.
If you thought that software development happens in a bubble, you were mistaken. There are multiple organizational conditions that influence it directly and indirectly. It’s not just something that those technology guys and gals are doing. Agile software development is disruptive to the “normal” way of working. It requires the investor to be part of the team in some form or fashion.
Having a Committed Team (Principle #5)
Ok, so maybe I can leverage Agile contracts for work that is outsourced but what do we do when the team is part of our organization and is salaried? We could be paying them and not getting results. Well, this leads us to risk 3, the risk of the team not doing their best or to put it more bluntly, not being committed. While we can definitely focus on getting the team to comply with internal contracts and similar instruments (such as threats), things are not often what they seem to be. Metrics and efficiency numbers that show a team is “working hard”, “improving” or “getting faster” are not a true indicator of a teams commitment. Maybe they are an indicator of compliance, maybe. (If compliance is good enough for your organization – Agile is probably not a right fit). Leaders who are looking for what they deem to be “tangible” stuff should really be focused on how much value is being created and generated.
Here is a formula for committed teams: Hire great people, create cross-functional teams, give them meaningful work, share with them how their output as a team will make a difference, tell them about important dates and budget and then let them loose. Support them by providing enabling conditions that allow them to excel. Follow’s Drucker’s advice; see them more as volunteers than anything else. This requires you to discard your Theory X approach to management. It requires you to actually trust them – if they are committed they’ll share in the risk as well.
Manifestos and Things
Take a look at the Agile Manifesto (I’m sure you can find it). If you look at it carefully you’ll see that this post has gone over some of the Agile values and principles. This, to me, is what software development guided by the Agile Manifesto is all about. It’s not just about standups, backlogs and story points. In fact, I consider those important but lesser. It’s about a particular culture of developing software. Any method that consistently demotivates or disempowers is not Agile. This is at the center of the #NoEstimates dialogue in my estimation (excuse the pun) – the culture of software development and hence the engagement models that arise as a result of the culture. (Sidebar: I find myself continually saddened by Agile leaders in organizations and consultants who don’t get this and still claim to be leading Agile transformations. They are doing more harm than good). Agile is not mandatory, it’s choice.
In Agile software development, the risk is shared and mitigated by everyone involved (including the investors) by working together in an Agile manner with a committed team. This may or may not work for you – it does not however mean that it is not an option (or the only option).
(I really should be at the piano but I find that there are few things on my mind this morning).
I find myself engaged in my fair share of conversations around accountability in various settings – particularly the Western world’s spin on it. That is, who can we hold accountable when something goes wrong? As I’ve blogged in the past, I personally think that individual accountability for team outcomes is a bit misguided. Debating “who gets called in the middle of the night” is truly missing the point. If you structure your organization in a manner such that individuals are solely accountable for team outcomes then don’t be suprised by the behavior that follows.
(As a leader, you are first and foremost a system designers and influencer. Don’t forget that.).
However, I do wonder what would happen if leaders spent half the time they spend debating who is accountable, actually promoting individual and team ownership in their organizations. Do individuals and teams feel ownership over their work, processes, techniques and outcomes? Or do they feel like their stuck simply following instructions? A means to an end? It’s not enough to simply talk about it, we need to intentionally create the conditions that actually support ownership at all levels.
Does your organization have a culture of ownership? What would a random survey show if you asked that question within your organization? How much time is spent discussing what needs to be done so that individuals and teams actually take more ownership? Nothing is a panacea and yet low ownership levels leaves a lot on the table.
Let’s focus more on a culture of ownership, maybe it’ll address our accountability problem.
(Now off to the piano…)
Is your organization highly centralized or highly decentralized?
Lean organizations are characterized by pushing decision-making to the “lowest” possible level. In the using the word “lowest”, I am just reflecting the hierarchy that exists in most organizations. What we’re really talking about here is ensuring that decision-making occurs where the work is actually happening. In order to enable this, the information also needs to be shared with the team(s) actually doing the work.
This is at odds with traditional work structures where people at the top were paid handsomely to have all the information and the peons were given such dumbed down tasks, that they didn’t have to do much thinking. Take a few minutes to study the history of industrialization. You may be surprised at what you uncover. Unfortunately, this “thinking” still influences the control structures of the average organization.
Even though in knowledge work, the “associate” is often a highly trained and educated individual (see Drucker), most organizations still create structures where all the important information is held at the top. You know, with Director X, VP Y or C-level exec Z. Nothing meaningful gets done without a decision being made by someone with a big title. Supposedly, those at the top are more informed and have more experience. Supposedly. The Taylorist mindset lives on; cloak and dagger style.
You can choose whether you want to work in organization like these. I made up my mind a few years ago that I wouldn’t except I was helping to the change that situation. You know why? I can’t stand to see so much human potential wasted.
Additionally, the delays introduced as a result of waiting for people at the top to make decisions impacts us economically (well except we’re a monopoly). Innovation is stifled, creativity pretty much killed. But someone still ends up with a fat bonus.
As a leader, how much decision making is centralized in you? How much decision-making is decentralized on your team? How much information is given to individuals and teams that enables them to actually make decisions? How many centralized boards and bodies does your organization have?
The greater the centralization the lesser the ability for the organization to scale and the more human potential is being wasted. The waste of human potential is such a sorry thing.
Are we are addicted to the old status quo? Could it be that all change initiatives we participate in are just a facade? Lipstick on a pig? Fun and games? Could it be that the way it is, is the way we really want it to be? I could get into examples but I’ve decided to protect the innocent today.
How can we tell? Well, change often implies that we enroll in some way new of thinking. A different set of values (supposedly) become important to us. We make decisions based on fresh set of principles.
I get that. So pray tell, how can we tell? Ask yourself this: what happens when things get tough? When things become uncomfortable? Do we revert to our old values and principles? Do our entrenched mental models step into high gear? What behaviors emerge? Old or new?
I often find in organizations (faith-based, social, work etc etc) that we talk a good game about how we want to change and how we intend to act differently. Unfortunately, our actions speak so loud that no one can hear what we’re saying (Jeff Van Gundy). Our behaviors are unchanged.
I’ve always believed that true change can only come about by assessing if our actions as invidivuals and groups are congruent with our (new) values and principles and then asking for help when they are out of wack. Change is hard. Good intentions are not enough. A lot of humility is required. The humility lacking in many of us.
Are we addicted to the status quo?
Really? Ok maybe. Then again, maybe not. It’s totally up to you and your organization.
Change is hard as it goes against what we know or what we are currently comfortable doing. It’s always been interesting to me that the Satir J-curve models going from chaos to new status quo as going up a steep slope. It’s very clear that we’re working against gravity and the pull to go back to where we were and what we’re familiar with.
The 4 values and 12 principles of the Agile Manifesto are supposed to help us see the areas where we can get better – at least if we wanted to be guided by Agile philosophy. Getting better often means challenging and changing some tough stuff. Tough stuff that actually makes a difference. Not just implementing 3 week iterations or estimation with that thing called story points. I mean those things are good, but in doing so we often ignore the most important stuff. I often run into folks who consider leaving the (old) status quo as being pragmatic and suggest that those who desire change are “purists” or “idealists”. Ok, possibly guilty as charged.
Here lies my comfort. Progress is dependent on the unreasonable woman and man.
Last night I tweeted:
One of the most intelligent guys I know (and just reconnected with) Abiodun Ofuya, responded with:
Leave it to Abiodun to pull in both Greek mythology and Alexander Pope. He’s been doing this since we were in high school 20+ years ago. The message came through loud and clear. From Alexander’s Pope’s poem “An Essay On Criticism”:
A little learning is a dang’rous thing
Drink deep, or taste not the Pierian spring
Little learning is often worse than ignorance as little learning gives a false sense of understanding and prevents additional learning whereas ignorance is simply that, ignorance. Little learning is one of the more common conditions present in many organizations that they are unaware of. Little learning leads to the improper implementation of methods, practices and measures. The moment we believe that “we’ve got it” or have become “an expert”, we may be dangerously close to “little learning”. Regardless of where this “little learning” lies within the organization, it is often leads to the creation of bad system. As Dr. Deming said:
A bad system will defeat a good person every time
So what’s the antidote:
Make a personal commitment to continual learning. Allow your existing mental models to be challenged. Consult those who are further along the learning path. As the child of two academics, I believe (based on my personal experience) that learning never ends and I’m always amazed by the new stuff I learn even in areas where I’ve been highly engaged and involved with for a long time. Remember that:
…drinking largely sobers us again
* See Pierian Spring for more information.
Accountability is defined in the dictionary as:
The quality or state of being accountable; especially : an obligation or willingness to accept responsibility or to account for one’s actions
Responsibility is often used as a synonym for accountability however frameworks such as RACI distinguish between the two words stating that those who do the work are “responsible” and the individual who is ultimately answerable is “accountable” as only one person can be accountable because accountability cannot be shared. I suppose this may work in non-team environments or co-acting groups but I struggle to see how it can really work in organizations that are committed to self-directed work teams.
For example, let’s take a a football (soccer) team, and apply the RACI matrix to it. Based on the RACI definitions, the players (workers) on the team are not accountable (answerable) for their play or the teams outcomes, only the coach or manager is. Or how about a choir? Should the members of the choir not be accountable for their performance or is the choir director the only one accountable? I wouldn’t want to be a part of a team where my teammates did not feel we were collectively accountable for our results.
George Santanya famously said:
Those who do not remember the past are condemned to repeat it.
It’s important that we don’t forget that matrices such as RACI are products of project management which is a by-product of scientific management. If you are a manager and/or leader in an organization, hopefully you are aware of scientific management and Taylorism. My experience (unfortunately) however, is that many managers and leaders are not familiar with management theories. Read the label before use, please.
Self-directed teams are accountable for delivering a work product that pleases those who will use or benefit from their work product. Accountability for delivering the work product should be that of the team and not that of a single individual whether that individual is the lead developer, architect, product owner, project manager or simply the smartest guy or gal in the room. Team members are individually accountable for meaningfully contributing to the overall success of the team. If you intend to make one individual accountable for the work product, then you must also give them full control and strip the rest of the team of their accountability. As Stephen Covey said:
You can’t hold people accountable for results if you manage their methods.
Is this something your really want to do?
While we’re talking about accountability, I should point out team accountability is not an idea original to Agile. A review of the work and study done on team-based work structures make it very clear that one of the conditions needed for self-directed teams to be successful is team accountability.
Some of my colleagues in Agile-sphere have an aversion to the word accountability because it often translates to a “who do we blame when things go wrong” culture. I happened to work in an organization with a business unit that had a strong culture of blame. I can recall an experience where a VP wanted me to let him know who on my team would be working on a certain piece of functionality so that he would know who to go to when things went wrong. He wanted to know who was accountable. Unfortunately for him, I wasn’t in the mood to provide that type of information so I ultimately became accountable. I don’t believe that accountability needs to translate to a culture of blame if individuals and teams take both responsibility and accountability. Unfortunately, many organizations are challenged in this area.
If you’re truly making the commitment to self-directed work teams, make the commitment to team accountability as well. More to come on this….
PS: I started this post in October of last year (2014) but never really got to completing it.
1. Leading Self-Directed Work Teams by Kimball Fisher
2. Leading Teams: Setting the Stage for Great Performances by J. Richard Hackman