Agile - Individuals and Interactions

Agile - Individuals and Interactions

The Agile Manifesto tells us that we should value individuals and interactions over processes and tools. Today I want to talk about this principle and what it means in the context of an organizational Agile transformation.  I chose a picture of a rowing team because it symbolizes a group of individuals, working together towards a common goal. They must work in harmony, all pulling together, to achieve the desired outcome.

There are only a few things that I am certain about, but here is one.  If a team does not have a clear, shared vision and sense of purpose they will not perform to their capabilities.  You can put all the processes and tools in place and hire people with great skills and experience, but if they don't understand what they are trying to achieve or why it is important, they will not apply themselves fully to achieving the goal.

I have had the privilege to work with some incredible teams in the game industry. What made them incredible? They were driven by a desire to build an awesome game. They understood the design and were excited about the features. Okay, it wasn't perfect, and we didn't always agree on the design and features, but you get the point. When the team is fired up, there is almost nothing they couldn't accomplish. I watched junior guys come into the organization and become incredible engineers and artists because of the culture and level of performance of those around them. A high level of engagement is contagious. I used to keep a sign on my desk that said "Attitudes are contagious, is yours worth catching".  If you can create a culture of engagement and sense of purpose it will fuel incredible energy and productivity.  Then you have to channel that energy into the right activities to deliver value.

Valuing individuals and interactions over processes and tools is about leadership; not titles. Great leaders get people to want to do what they want them to do. That is what shared vision and purpose are about. Another word we hear a lot on this topic is "context".  People need to understand the context. Don't just tell them about the constraints (budget, timeline, technical, etc); explain them. Give them context so they know why those constraints exist.  When you show the team the design concepts, make it a pitch with all the excitement and energy that you would give potential investors.  After all, you are asking your team to invest in the project. You want them bought in.

I'll make two more points before this blog post gets too long.  Talk with, not to, individuals when you talk about the vision and purpose. It is good to have a big meeting with lots of excitement and marketing glitz to introduce the team to the project, but you also have to talk to each member of the team individually to make sure they understand why they are important and what their role is. Make it a conversation, not a lecture.  And don't do it just once. Have regular conversations with individuals about the project and their contributions.

The second point is about culture and encouraging individuals to work together to solve problems. You want them talking to each other freely and unconstrained. They need to collaborate, ideate, help each other and feel completely safe sharing their feelings and reservations about the work they are doing.  This is really the "interactions" part of what the Agile Manifesto is suggesting you should value.  Interactions occur both within the team and also with other teams and parts of the organization. The more openly communication flows and information is shared, the better the decisions will be and more comfortable all with be with those decisions.

Have you ever seen a championship basketball team play together? They are constantly talking to each on the court and seem to know what each other will do before they do it.  They each have a unique role, and they know their role and understand why their role and their actions are important to the success of the team. That is valuing individuals and interactions over processes and tools.  The coach may have a system, but on the court, the team must make decisions, trust each other and coordinate their activities.

As the manifesto points out, there is value in processes and tools.  Just don't let them get in the way of getting people to talk to each other.

Agile Mindset First

Today I want to talk about why, in my first two blog articles about Agile, I never mentioned Scrum, Lean, XP, Kanban or any other approach to Agile software development.  I believe that we must first accept an Agile mindset and an understanding of why we need to be Agile before we can jump into figuring out which software development approach will work best for us.

The goal is not to use Scrum or Lean. The goal is to be agile and to experience the benefits of both running product development projects with agility and running a company with agility.  We must know our strengths and weaknesses as an organization and face the challenges to becoming agile. An Agile transformation is not easy.  Adopting Agile software development techniques does not solve problems, it exposes them.  Let's take a quick look at the Agile Manifesto for a refresher.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I will write a blog on each of the four principles to talk about the ramifications of each in the context of an Agile transformation. Today I want to encourage you to not get the process backwards. Adopting Scrum for a project within an organization that is not agile isn't a terrible way to start learning about Agile software development, but be warned.  It is almost impossible to be Agile on one project in isolation.  Agility is about collaboration, communications, rapid change, and quickly releasing software.  It is really hard to do those things within an organization that does not yet support or has not yet adopted Agile practices.  You will run into resistance from business folks, Finance, PMO and other stake holders because they don't understand what you are doing and why.

In my last blog post, Agility - using all your senses, I pointed out that you need to measure agility across 5 areas: externally, internally, financial, operational, and people. When you do a single project using Scrum, the only pieces you are touching are the internal and the people directly involved in your project.  I'm not saying you should never start an Agile initiative by introducing Scrum or another Agile approach for software development.  What I am saying is, understand the challenges you are going to face organizationally.  You may want to release software quickly with a very short development cycle, but the PMO, QA, and Operations may oppose you because they have policies, processes and procedures that prohibit releasing software without their blessing and sign off.

I'll give you a specific example from a project I worked on from 2015 into 2016.  We embarked on a mobile software development project using a Scrum approach within an organization that had never done Agile software development before. This was a contracted services arrangement where the client hired us to come in and develop the software and specifically requested that we introduce Agile practices. We ran into a QA department that was completely unwilling to adopt an Agile approach.  They insisted that they would wait to review the software until we got to a major milestone. Only then would they do full end-to-end testing, and show the software to actual users.  They also demanded comprehensive design documentation and insisted that any feature or functionality that was not supported by comprehensive documentation would not be accepted.

As you can imagine, this project became waterfall by Sprints, not Agile using Scrum.  Senior leadership was unwilling to change their QA processes and we were completely blocked from doing usability testing until about 9 months into development.  Of course, the project was not highly successful and the organization is now going through fairly dramatic changes. The actual Agile transformation as begun. So, my warning about trying to initiate Agile software development with a single project comes from experience.  That said, sometimes you have to expose the problems with a failed project in order to wake folks up and force hard conversations. That organization will be much more successful on future projects because of what they learned over the past year and their new willingness to change.

Agility - Use all your senses

In my last post, Agility - Chasing a Moving Target, I suggested that agility involves observation and the ability to make quick decisions to adjust to changing terrain and the movements of our target. Today I want to talk more about what I mean by observation. Of course, metrics are involved but using "all your senses" means we are going to go beyond the standard metrics like Sprint burn down charts and tracking development velocity.

Using all your senses means observing not only what you are doing and how well you perceive you are doing it. I'll suggest that there are 5 general areas we need to observe to have a more complete picture of what we are doing and where we should be applying our efforts to move forward and achieve the desired outcomes.

Externally

These are the observations of how our product is doing in the market. This assumes that we have put product into the hands of our customers.  In the Agile mindset, this means short release cycles. We must quickly deliver new features and enhancements and then measure the response.  We hear a lot of talk these days about "continuous delivery".  This is literally the shortest possible release cycle. With continuous delivery, you deliver updates to your digital products every day or even multiple times a day.  Continuous delivery is a topic that deserves a much deeper dive so we'll tackle that one in another blog. My point here about external observation is that you must have the monitoring capability to see how your customers are interacting with your product. What features are they using or not using? What problems are they reporting, and what are they sharing on social media?

Of course, we could break down external metrics or observations into customer metrics, market trends, competitor's products and their performance in the market, etc. There are many pieces of data we can collect. Don't just collect them. Observer them constantly so you know what they mean and can spot trends and meaningful fluctuations. Don't collect data you can't interpret and react to.

Internally

Yes, Sprint burn down charts and measuring development velocity can be helpful. I break internal metrics into three sub-categories:

1. Productivity
2. Efficiency
3. Quality

Productivity is the output measure. How much work are we getting done?  Efficiency is the measure of what it costs us to get that work done. The more efficient we are, the more value the team can deliver without increasing the size of the team. Quality level affects efficiency. If we produce high quality work, we spend much less time and effort (cost) going back and fixing defects or reworking something that did not meet expectations.  Measuring quality can be a lengthy discussion so we'll save it for another blog post.

Financial

We cannot talk about observation and exclude financial impacts.  Product development involves expenses and there must be some quantitative measure of the return on that investment. Again, there are many ways we may be measuring value that go beyond just the standard revenue or profit margin metrics, but we better have a clear understanding of our financial model and expectations and track our performance over time.

Operational

Under the internal heading I referred to efficiency metrics. There we were talking about product development efficiency. Here we are talking about operational efficiency. This includes things like the ability to release, support and maintain the product.  We don't want to put all that effort into developing a high quality product and then not have it accessible to our customers. Under this category we may be observing all kinds of performance and stability metrics. This may also include keeping data secure, having business continuity plans, and responding to regulatory or compliance issues.

People

Talking about people last does not in any way indicate it is less important. In fact, it may be the most important thing you measure. The capacity, engagement level, and performance of your teams will determine the success or failure of your organization. You need to constantly assess the makeup of your teams.  Do you have the right people, with the right skills and tools to do the job you are asking them to do? Do you have leaders who inspire and share a vision that provides every individual with a sense of purpose and urgency? If you don't know then you are not observing your people.

In conclusion, you can't just measure one aspect of your organization's performance. Use all your senses and see the whole picture. Your ability to grow as a business is a complex interdependence of multiple factors.  Look at the whole system and identify all potential areas of weakness.  Figuring out what to measure and how to interpret what you observe is not easy.  Every business is unique but you are not alone.  Let's work together to share our experiences and lessons learned.

Comments are welcome and you can also reach out to me directly at eric@byronconsultingservices.com.

Agility - Chasing a Moving Target

We hear lots of buzz about Agile product development and businesses undergoing Agile Transformations but what does it mean to be agile and why is it so important? We all understand that the world is changing faster and faster.  This means that our markets are changing and, for us to be competitive, the solutions we offer to the markets must change just as quickly.  Here is where I draw a distinction between Agile product development and more traditional Waterfall approaches. With Waterfall we assume the target is stationary, but in Agile we assume the target is moving.

I'm not condemning Waterfall as a valid approach to running projects.  It may be a fine approach for internal projects that solve known problems for organizations, i.e. operational efficiency projects, or regulatory compliance projects where we set an objective and then plan and execute to achieve that outcome. I would still caution about assuming the target is stationary.  Long running projects of any kind are going to encounter changing requirements so even internal projects should be no more than 6 months in duration to increase the odds of a successful outcome.

That said, when we are doing product development we need to be like the cheetah.  We need to move fast, adjust to the terrain, and keep an eye on that moving target. This is what it means to be Agile. Product development, and I include all digital interfaces we have with our customers under that heading, has to evolve quickly and continuously.  This means always moving forward with our eyes open, observing the terrain and scanning for targets.  It is a hunt and we are also being hunted.

I lead a panel discussion about Agile metrics recently at a conference in Hong Kong.  We talked about how we can measure our product development projects and our agility.  It is great to say "we are agile" and "we do Agile software or product development" but really measuring our agility at both the project level and organizationally is hard.  I'll save a deeper dive into Agile metrics for another blog and I'll leave you with this question for today.

Are you running your projects like the cheetah?  There should be a great sense of urgency and constant vigilance to observe and adjust as you move forward.  If you are standing still you are easy prey to be taken by another hunter.  Every move you make doesn't have to be successful.  Learn, try again, and do it quickly.