I had an intense yoga teacher training session all weekend during which we talked about core feelings, fears, and insights, etc. This opening experience in a supportive environment led to extensive personal and team growth and as a result, we each became stronger teachers and more empowered individuals. We gave each other honest feedback throughout this process, and each took ownership to help ourselves and help each other.
This got me thinking this morning about a previous software project during which I had the opposite experience:
Core feelings when I thought about the project
* Anger
* Fear
* Disappointment
* Humbled
Actions during the project
Personal:
* I diminished my own role
* I stopped speaking the truth
* I stopped listening to my own intuition
* I second guessed all of my actions
* I took it personally
* I did not grow
Team:
* We created a inefficient, cuthroat environment
* We did not take ownership over our actions
* We did not hold each other accountable
* We did not give each other honest feedback
* We took things personally
* We made decisions based on "me, me, me" instead of what made sense for the communal good (i.e. producing working software)
Software projects can be incredibly challenging since we bring together individuals with different backgrounds and experiences and have to quickly establish a team dynamic. Unfortunately, for this particular project, the inefficient environment of a sister project carried over because some of the same individuals carried over.
The agile principles and manifesto are a great tool for trying to change an environment, but ultimately people need to be open to the principles and accept that "these will result in a better product." In agile, we talk a lot about team reflection, but there's a degree of self awareness and self awareness required of the team. Everyone has accountability. I can't emphasize that enough - everyone from a tester to the project lead..and it's ultimately on every individual on the team to take responsibility and work to improve the environment so that they can truly have an agile project. We are so used to pinning things in software on leadership, but that is the wrong approach and it's putting an unfair burden on one person. Everyone has to step up.
Monday, October 10, 2011
Thursday, October 6, 2011
Agile projects require teamwork
While providing the office coffee baristas with some free passes to my yoga studio this morning (they were super interested in trying yoga when I mentioned I started teacher training), I ran into some colleagues from my previous software development project. This brought back memories as well as strong instant reactions. Since writing can be very therapeutic, I am hoping that recording these thoughts will help me process and handle these reactions and ultimately, let them go.
My last project is a classic example of how a software project can "fail" or at minimum result in a more painful process w/ high staff turnover and a lower quality product. Most members of the project acknowledge that there were challenges - the scope was too broad, the schedule too tight, process was unclear, staff mis-alignment, clients did not understand how to build software, user community was divided with no clear arbitrator, etc. However, the fundamental issue is that there was no common understanding nor agreement on the product vision and goals. Everyone's head was in their own rice bowl and decisions were made to placate individual egos/ambitions at the expense of the product. It became an "everyman for himself" type of environment, resulted in leaders feeling powerless and cut off at the knees, and this dysfunction ultimately creeped into the design/development of a product that does not ultimately help anybody.
It's very easy to fall into this trap in software projects, since teams are composed of very diverse individuals with different skillsets. Many folks in software are highly specialized and used to thinking through one lens - i.e. "I'm a tester" or "I'm a code monkey" - it takes a lot of team leadership and individual willpower to pull the team out of that thought process and start seeing the bigger picture. In addition, software targeted to a narrow customer base [e.g. custom systems development in Defense] requires lots of domain expertise, so the development team needs time to understand the domain. For my last project, we brought in domain experts (bosses of power users...not the users themselves) to help educate the team, however this brought a host of additional challenges...where in order to ensure that the product was developed to meet their needs, the domain experts expanded their roles significantly beyond their expertise and were ultimately frustrated as well.
Fundamentally, it's a shift in attitude for everyone involved - to really see the value in the rest of the team and what everyone brings to the table and forget about "me" and "my needs." There also needs to be a high degree of both group and individual accountability - everyone has a stake in making the product better and everyone can do things better. It's important for the team to realize this and feel empowered to experiment with techniques till they find what works and what doesn't work.
There are a few techniques that leaders can apply to help the team move forward. A great one discussed during the Santeon Group's "Fundamentals of Agile" Course is to hold a team exercise to develop a charter capturing vision, goals, roles and responsibilities. This exercise allows for everyone to have input in defining the end product, and also feel a greater sense of ownership. It also provides concrete guidelines which can be used to support decision making in the future - so when the project hits bottlenecks where there needs to be some horse trading, at least decisions are based on previously agreed upon criteria.
e.g. if the team defines value as "providing working software" - if the bugs list becomes out of control, resources should be shifted to addressing bugs as opposed to building new functionality
This is not idealistic - it's very achievable to some degree even within the bounds of current contracting processes. It just requires a shift in attitude.
My last project is a classic example of how a software project can "fail" or at minimum result in a more painful process w/ high staff turnover and a lower quality product. Most members of the project acknowledge that there were challenges - the scope was too broad, the schedule too tight, process was unclear, staff mis-alignment, clients did not understand how to build software, user community was divided with no clear arbitrator, etc. However, the fundamental issue is that there was no common understanding nor agreement on the product vision and goals. Everyone's head was in their own rice bowl and decisions were made to placate individual egos/ambitions at the expense of the product. It became an "everyman for himself" type of environment, resulted in leaders feeling powerless and cut off at the knees, and this dysfunction ultimately creeped into the design/development of a product that does not ultimately help anybody.
It's very easy to fall into this trap in software projects, since teams are composed of very diverse individuals with different skillsets. Many folks in software are highly specialized and used to thinking through one lens - i.e. "I'm a tester" or "I'm a code monkey" - it takes a lot of team leadership and individual willpower to pull the team out of that thought process and start seeing the bigger picture. In addition, software targeted to a narrow customer base [e.g. custom systems development in Defense] requires lots of domain expertise, so the development team needs time to understand the domain. For my last project, we brought in domain experts (bosses of power users...not the users themselves) to help educate the team, however this brought a host of additional challenges...where in order to ensure that the product was developed to meet their needs, the domain experts expanded their roles significantly beyond their expertise and were ultimately frustrated as well.
Fundamentally, it's a shift in attitude for everyone involved - to really see the value in the rest of the team and what everyone brings to the table and forget about "me" and "my needs." There also needs to be a high degree of both group and individual accountability - everyone has a stake in making the product better and everyone can do things better. It's important for the team to realize this and feel empowered to experiment with techniques till they find what works and what doesn't work.
There are a few techniques that leaders can apply to help the team move forward. A great one discussed during the Santeon Group's "Fundamentals of Agile" Course is to hold a team exercise to develop a charter capturing vision, goals, roles and responsibilities. This exercise allows for everyone to have input in defining the end product, and also feel a greater sense of ownership. It also provides concrete guidelines which can be used to support decision making in the future - so when the project hits bottlenecks where there needs to be some horse trading, at least decisions are based on previously agreed upon criteria.
e.g. if the team defines value as "providing working software" - if the bugs list becomes out of control, resources should be shifted to addressing bugs as opposed to building new functionality
This is not idealistic - it's very achievable to some degree even within the bounds of current contracting processes. It just requires a shift in attitude.
Wednesday, October 5, 2011
RIP Steve Jobs
A visionary passed away today - Steve Jobs left this world at the young age of 56. The NY Times had a great article on his life and legacy.
I found this part of the article to be particularily interesting ---
"He put much stock in the notion of “taste,” a word he used frequently. It was a sensibility that shone in products that looked like works of art and delighted users. Great products, he said, were a triumph of taste, of “trying to expose yourself to the best things humans have done and then trying to bring those things into what you are doing.”
Regis McKenna, a longtime Silicon Valley marketing executive to whom Mr. Jobs turned in the late 1970s to help shape the Apple brand, said Mr. Jobs’s genius lay in his ability to simplify complex, highly engineered products, “to strip away the excess layers of business, design and innovation until only the simple, elegant reality remained.”
Mr. Jobs’s own research and intuition, not focus groups, were his guide. When asked what market research went into the iPad, Mr. Jobs replied: “None. It’s not the consumers’ job to know what they want.”"
It's amazing to hear that Mr. Jobs relied on his intuition to guide his decision making process, even when it put him at odds with others. It takes a lot of moral courage to do that, especially when it feels like you are alone in standing up. On my last project at work, I noticed that the team was grossly misaligned with end user representatives being the ones indirectly designing the product since we had no designers. The verbalized rationale for not having designers was "there is no funding" although I suspect there were political factors at play - unfortunately, in my experience, software development in Defense is often dictacted by end user needs/wants instead of "being informed" by these needs...products end up being designed/developed incorrectly, which leads to increased user frustration and a greater desire for control.
The reality is users have no idea of what they want. If someone asked me "what features would you want your car to have" or "what is your ideal tv like," I would certainly provide some answers however those answers may not lead to development of a car or tv that truly suits my needs. A better approach would be for a designer or analyst to observe me using a tv or a car (as captured in the contextual inquiry method) so that he/she can identify common tasks I do, and see where the bottlenecks are...however, I have yet to see this process applied in Defense which is kind of strange since its fairly standard.
I found this part of the article to be particularily interesting ---
"He put much stock in the notion of “taste,” a word he used frequently. It was a sensibility that shone in products that looked like works of art and delighted users. Great products, he said, were a triumph of taste, of “trying to expose yourself to the best things humans have done and then trying to bring those things into what you are doing.”
Regis McKenna, a longtime Silicon Valley marketing executive to whom Mr. Jobs turned in the late 1970s to help shape the Apple brand, said Mr. Jobs’s genius lay in his ability to simplify complex, highly engineered products, “to strip away the excess layers of business, design and innovation until only the simple, elegant reality remained.”
Mr. Jobs’s own research and intuition, not focus groups, were his guide. When asked what market research went into the iPad, Mr. Jobs replied: “None. It’s not the consumers’ job to know what they want.”"
It's amazing to hear that Mr. Jobs relied on his intuition to guide his decision making process, even when it put him at odds with others. It takes a lot of moral courage to do that, especially when it feels like you are alone in standing up. On my last project at work, I noticed that the team was grossly misaligned with end user representatives being the ones indirectly designing the product since we had no designers. The verbalized rationale for not having designers was "there is no funding" although I suspect there were political factors at play - unfortunately, in my experience, software development in Defense is often dictacted by end user needs/wants instead of "being informed" by these needs...products end up being designed/developed incorrectly, which leads to increased user frustration and a greater desire for control.
The reality is users have no idea of what they want. If someone asked me "what features would you want your car to have" or "what is your ideal tv like," I would certainly provide some answers however those answers may not lead to development of a car or tv that truly suits my needs. A better approach would be for a designer or analyst to observe me using a tv or a car (as captured in the contextual inquiry method) so that he/she can identify common tasks I do, and see where the bottlenecks are...however, I have yet to see this process applied in Defense which is kind of strange since its fairly standard.
Why I decided to share
"Don't be afraid to speak your truth. If delivered from the heart with kindness, honesty, and genuine intent, the effects can be astonishing and can take life, health, and relationships to new levels." ~ Baron Baptiste
After a "venting session" on how to better adopt the agile mindset and associated practices within ongoing software development projects at my company, a work collegue told me "you should start a blog on what agile is and how it can be adopted." This is not the first time I have heard this - my friends have said the same thing before and my reaction at the time was "why...who cares about what I think? who would even read this?"
In retrospect, I realize that by witholding my truth from others, I denied myself. And fundamentally, I did not speak up cause I was scared that other people would not agree with what they read and would not like me as a result - that they'd think "who's this kid talking about how software should be built and managed when she has no experience." That nobody would ever promote me in my company and that there would be more backstabbing from colleagues. In spite of my intuition screaming inside, I held my tongue both at the office and in personal relationships (on many topics) and let fear take hold. I developed a strong sense of self doubt and ended up feeling disempowered.
I have made a commitment to myself to do that no longer and will authentically share my thoughts and experiences with the world through this blog. A few topics that I'm excited to write about are:
After a "venting session" on how to better adopt the agile mindset and associated practices within ongoing software development projects at my company, a work collegue told me "you should start a blog on what agile is and how it can be adopted." This is not the first time I have heard this - my friends have said the same thing before and my reaction at the time was "why...who cares about what I think? who would even read this?"
In retrospect, I realize that by witholding my truth from others, I denied myself. And fundamentally, I did not speak up cause I was scared that other people would not agree with what they read and would not like me as a result - that they'd think "who's this kid talking about how software should be built and managed when she has no experience." That nobody would ever promote me in my company and that there would be more backstabbing from colleagues. In spite of my intuition screaming inside, I held my tongue both at the office and in personal relationships (on many topics) and let fear take hold. I developed a strong sense of self doubt and ended up feeling disempowered.
I have made a commitment to myself to do that no longer and will authentically share my thoughts and experiences with the world through this blog. A few topics that I'm excited to write about are:
- agile misconceptions - no, agile does not mean "the user designs software" or that the team codes faster
- flaws in the JCIDS process - how the "it-in-a-box" concept is at odds with good design principles
- a comparison of the yoga "way of life" + agile mindset
- ...other exciting topics as I continue to learn about agile, software development, and establishing self-empowered teams
Subscribe to:
Posts (Atom)