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
It’s been a minute since I’ve blogged as a lot has happened in life recently, the biggest being the passing and laying to rest of the matriach of our family, my grandmother. Hannah Joji Ikonne. She was the best grandmother ever and her passing away is one of the sources of inspiration for this post.
Who are you? When I ask myself that question I realize that I am the sum total of the experiences and circumstances (and more) that have occurred during my lifetime. Let me quickly share a few:
- I grew up in a home of faith
- I grew up in a third world country
- I did farm work, cutting foliage with a cutlass, planting corn, cassava etc etc
- I walked 3 miles to my high school and 3 miles back home every day for 4 years in the scorching sun
- I lived on a university campus where academic rigor was the order of the day
- Etc etc…
How have these factors impacted me as an individual?
- I am person of faith
- I have empathy for the less fortunate and I’m content with whatever I have as I realize there are people who have much less
- I am not afraid of hard work and get irritated often when people complain about certain aspects of our white collar jobs
- I appreciate having a car :-)
- I have little respect for those who haven’t done their research on a subject and yet have such a loud opinion on the subject
These are how the factors impacted me, not anyone else. A lot of the folks I grew up with experienced similar conditions and were impacted in a different way. (You know who you are).
But the point of this post is not to make my life experiences material for the public domain but rather to remind us of something we already knew, we are complex creatures. I feel that this is extremely important to remember as we interact with one another, especially in the workplace.
Don’t be quick to judge or jump to conclusions. Remember that the individual on the other side of the table is also a product of their life experiences just like you are. Have empathy. Be tolerant. Be vulnerable.
Now I know for a fact that this is easier said than done (I personally struggle with being vulnerable for example) but we need to keep trying if we want to experience deep and meaningful relationships. Paraphrasing St. Francis:
Seek to understand then be understood
Rest in peace Mama Ukwu.
Is there such a thing as “sequential Agile software development”? Possibly. Maybe. Look at your process. How many phases does a piece of work have to go through before its complete? How many (in)formal stages does your process have? How about sign-offs? How about handoffs? Interestingly enough, the hallmark of the strawman referred to as Waterfall is the fact that work passes through different phases in a sequential manner just like a bottle of Coke goes through the bottling process. Until work is completed in one phase, work in the next phase cannot be started. Is this how your process works? Is it possible that you have mini-waterfalls occuring in your iterations? #justasking.
But Eb, product development phases have to be sequential you say. At least that’s how we were taught. Yeah, I remember those classes as well. But let’s think about it. Is it possible (for example) that certain test activities can occur while code is being developed? Can testing commence after some code is checked in even if the story is not 100% complete? Can different disciplines perform activties on the same work item in parallel? Can we challenge ourselves to identify how we can all contribute concurrently to the completion of a work item? Do we even have these conversations? Please don’t tell me you won’t know when the work item is ready for you to work on it. What happened to face-to-face conversation and all its 21st century incarnations?
Classic Agile task boards are famous for having only three phases: To Do, In Progress and Done (or something similar). The goal is that everyone should be working together concurrently and collaboratively on the items “In Progress”. Phases should overlap such that there is no value in explicitly calling them out because the work item cycles through each phase quickly and concurrently. Could your team get by with three phases? If the answer is no, why? How many phases do you need? Do your phases foster a true spirit of teamwork and collaboration? Is this an area worthy of inspecting and adapting?
The essence of this post is not to suggest that every team should have only three (or any number for that matter) phases but rather to spur us to take a hard look at how we’re working as Agile team and consider whether our process fosters as much collaboration as is possible or leaves some collaboration on the table. Are we dependent on handoffs and sign-offs? Can we only pick up an item after its completely through a previous phase? Are we really more waterfall-esque than maybe we’d want to admit? To start and finish together, the team needs to work on the same things together. Take a look at the image below, which type reflects your current process? Hopefully at least Type B? Maybe Type C?
Image Credit: The New New Product Development Game – HBR
So this post has been on my mind for a while, but something happened at work today….
It would seem to me that it’s human nature to explain occurrences in the simplest manner possible, often in the form of linear “cause and effect” relationships. You know, after you kick a ball, you realize the that the kick (cause) led the ball to move (effect) and so we are always looking for that “kick” that led something to happen. For example, why did we find fewer defects this sprint? Well, it’s because we went from a 3 week sprint to a 2 week sprint.
Is it really that simple? I don’t think so. I’m reminded of the phrase “correlation does not imply causation“. In the domain of systems thinking (and every one responsible for the system should have a basic understanding of systems thinking), we realize that there are often many variables at play in the system.
Take the “fewer defects” example I mentioned earlier. While it is true that the sprint duration was shortened, is it possible that other conditions changed as well? Was the team now a bit more familiar with the work? Was their less pressure because they committed to less in that particular sprint? Was this work less complex than the work before? Was technical expertise that had been missing before made available? What about the conditions we are not aware of? I mean, we can’t be aware of everything can we?
The additional challenge we have is that we rarely have the luxury of repeating our experiments. Every time we try something new, the conditions are different. How many times do we get the opportunity to develop the same feature repeatedly just to capture how effective a change is? I assume rarely, if ever. Our laboratories don’t allow us to reset and run the exact same experiments over and over.
So where does this leave us? (Especially those of us who consider ourselves to be expert problem solvers!). Does this imply that we cannot attribute cause to the things that happen around us? I think we need to be a bit more respectful of the complexity of the problems we often face. We need to understand that the underlying structures and conditions continually impact one another. To use systems thinking parlance, structures reinforce and balance one another. There are often many factors at play and we should be careful latching onto a single one as THE (only) cause. This complicates things for us in some regards, but put us in a position where we can actually dissolve problems.
It is rarely as simple as we often make it out to be.
PS. Some links to my posts on systems thinking.
A current (ok now its old) conversation on LinkedIn was the source for the first post of 2015. (Yes I’ve been slacking a bit).
While on vacation, I spent some thinking about the fact that many organizations have “Product” groups that are separate (read completely different organizational structure) from the “Technology” group. In fact, the only organizations where I have not seen this are the technology startups that I have been involved with.
I happened to bring up this point in the LinkedIn conversation only to be told the following:
Software Engineering – Build what product management tells you to build. Worry about predictability, quality, productivity and extensibility
Product Management – What should be build? What is the business case for it?
Really? Is that really what Software Engineering is about? Building what product management tells you to build? Could it be true? We shouldn’t care about what we’re actually delivering? I believe that such an opinion leaves a lot on the table and yet I’ve found it to be a common opinion in more than one organization. Ever heard this: “don’t ask why, just do it”! Unfortunately, statements like this reveal a complete lack in understanding of software engineering.
I won’t get into a discourse on software engineering as there are many institutions of repute (and Google) that can you help you out with that but I do want to point out an important aspect of software engineering that trained software engineers are very familiar with – requirements engineering. Requirements engineering is all about determining what problem needs to be (dis)solved and what outcome is desired. I realize that “requirements” is often a red word in Agile circles because of its literal application in many command and control type organizations. I mean, who hasn’t heard the “go read the requirements” reply before? But when you really think about it, you’ll see that Agile methods promote performing requirements engineering throughout the entire product development process.
So its my belief that software engineers need to understand “what should be built” and “the business case for it”. In fact, I’d suggest that it’s irresponsible not understanding why. Sure, there may be another group (for example product) focused on idea generation and problem identification but instead of walls between product and development, let’s have a mesh with ideas and information flowing both ways. It is product development afterall, isn’t it? Software engineers ultimately need to understand the problem to be able to deliver the best solution (they are capable of delivering).
As I pointed out here:
To get the “best” solution, it seems to work best IME when those delivering the solution understand “why” and the outcome desired. I have been told many times in the past to do X because it was needed but if I had understood “why” and the outcome, would have done X+ or maybe Y. A key component of software engineering is requirements engineering. Requirements engineering asks us to understand the problem.
So friends, don’t let friends tell you that software engineering is just about building what we are told to build. It’s more than that!
Plans fail, and they tend to fail quite often. In all walks of life, even the simplest plans tend not to unfold as originally designed.
Organizations spend a lot of money and time creating groups solely focused on ensuring that plans do not fail. Senior leaders hire individuals and give them the sole responsibility of managing plans to success. It is quite the lucrative profession to be given such responsibility.
Recently, I asked our church pianist to perform special music at church. Early in the service, a group of children came up to perform special music. As they were singing, I walked over to the pianist to discuss a couple of things but before I could say anything he whispered in my ear “the kids are singing my song!” I couldn’t believe it! What were the odds that the children and pianist would choose to sing the same song on the same day? Pretty small. But it had just happened.
So our best plans fail to go exactly as we thought they would when we drew them up. It is rare that we are 100% certain that things will work out exactly the way we expect them to yet we often behave as if that’s the case. There is always the chance that something unforeseen will swoop in, alter the landscape and impact our plans.
How then do we proceed? Do we stand a chance of getting anything done? Do we have to spend all our effort trying to ensure that our plan unfolds as we originally designed it?
Back to my story… I was beginning to feel very concerned for our church pianist as I didn’t know what he would do given that the children were singing the song he had prepared. At that moment he leaned forward and whispered “don’t worry I prepared two songs, I’ll sing the other one.”, He had prepared two songs! He had options! His options allowed him to adjust when his original plan did not work out as he thought it would have.
When you develop plans, do you identify options for when things go wrong? Do you explicitly consider the fact that even the best plans fail? Some may consider options to be “contigencies”, “alternatives” or “backups”. As I type this post, I’m at Owo-Ahiafor, Nigeria – my hometown. When I planned the trip to Nigeria, I identified options for various pieces of the plan where things could go wrong. Having options is part of developing a risk mitigation technique. It’s common sense but then again common sense is often not that common. Options should be identified based on the likelihood of the plan not working out as originally designed or based and/or on the impact (financial, social, physical) of the plan not working out. In the case of my church pianist, the odds that the two songs he prepared would be sung on the same day, were pretty slim because it was a regular church service. However, if it had been a concert, he may have needed three or four song options to reduce the odds even further.
At the organizational level, I’ve observed that many an organization will spend a lot of time creating plans and yet don’t spend the time to consider the fact that even the best plans fail, ergo, they have no options or scramble to find options when things don’t go according to the plan. As a result of this, certain people in the organization are incentivized to make sure the plan works at all and any cost. Often, they are not the individuals actually executing the plan leading to unnecessary friction within the organization. I’ve lost track of how many times I’ve seen people recognized because they “rescued the plan”. In previous posts, I’ve hinted that outcomes are what we truly care about. The plan is often a means to an end.
Do you have two songs in case someone else sings the song you originally intended to sing. Do you have options for when things don’t work out as planned? As we head into 2015, remember, even the best plans fail.