All About Agile... Guest Post

A week or so ago Kelly Waters reached out and asked me to do a guest post for his blog All About Agile. Kelly has been writing on Agile topics for a while and was one of the first bloggers that I ever started following. Needless to say it was quite an honor and I was happy to contribute. My post is called "The One Million Dollar Question"... it's about teamwork... and I think you'll like it.

Hop on over and take a look... and if you are not already subscribed to Kelly's blog... I highly recommend you take this opportunity to do so. Happy reading!

Subscribe to Leading Agile

Are Scrum Roles Really Sufficient?

Okay... so you are making the transition to Scrum... awesome!

Let's start by taking a quick inventory of your team and figure out who is going to do what in this new methodology. Scrum defines three roles for us: ScrumMaster, Team Member, and Product Owner. Everyone's pretty excited and ready to get going, so let's take a look, and see where everyone fits in.

If your organization is like most traditional software development organizations, your team probably has a bunch of developers, several QA analysts, maybe some interaction designers, a database guy, and usually a Business Analyst and a Project Manager. You might be working with a real customer, but more often than not, you are working with a Product Manager who's job is to define your product requirements.

Is that everyone on the project? It might be everyone on your project team, but is that really everyone on your project?

When you look outside the immediate project team, the number of people with influence over your project actually gets much larger. You likely have several Product Managers, maybe a few marketing folks, a sales team, and of course your support organization. You may have a team of engineers that implement your product and probably a few consultants that train your customers on how to use new features.

Do you have any interested functional managers, directors, or vice presidents? What about the Business Development and Strategy team? Does your project have visibility at the Senior Executive level? Where do the CIO... the CFO.. the CEO all fit in? These folks not only have an interest in how the project is coming along, they might need to actually insert some requirements and shape the direction and timing of your project.

More than likely, these folks actually funded your project. Do these individuals have a defined role in Scrum? If so, what do we call them... what do they do? Is it sufficient to call them chickens and tell them to talk to the ScrumMaster?

Over the next few posts, we are going to take a look at the role of ScrumMaster, Team Member, and Product Owner and explore how many of our traditional roles play on an Scrum team. We'll examine how, from the team's perspective, many of our traditional stakeholders are abstracted behind the role of the Product Owner, what this means for the agile team, and its implications for the broader organization.

We'll assess some of the risks and suggest an alternative or two for dealing the Product Owner at scale.

Subscribe to this blog Subscribe to Leading Agile

Building Projects Around Motivated Individuals

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." - The Agile Manifesto

This is the one principle behind the Agile Manifesto that keeps me up at night. It’s the first part, the one about building projects around motivated individuals that has me worried. It is probably the single most important factor for a successful Agile team, and the one that is the most difficult for a project manager to really influence.

When I was introduced to Agile a few years back, that was the first thing that caught my attention. I was amazed at how dependent these lightweight methodologies were on the quality of the people on the team. For Agile to work, you really need to select your team members carefully and, to quote the Manifesto, give them the environment and support they need… to get the job done.

But here's the catch… many of us don't get the opportunity to hire our people or even pick our team. That is decided for us before we are handed the project.

And that is why this principle worries me. As companies try to realize the benefits of Agile, they are going to do it with their existing people. Most companies, especially the big ones, are going to have a mix of talents and people that are motivated in different ways. Can we assume that by creating an Agile environment, empowering the team, and encouraging them to self-organize that motivation will necessarily follow?

Don't we need motivated people first?

I sincerely believe that creating an environment where people can be successful will have a wonderful impact on attitudes and bring out the best in folks. Just be aware that Agile is not going to solve any of your personnel problems. It will, however, bring these issues to the surface so that they can be dealt with quickly. As managers we need to do everything we can to support the team and help them be successful.

Sometimes that means helping find new team members.

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/building-projec.html

Subscribe to this blog

Subscribe to Leading Agile

What About Me?

We've spent the better part of the past few decades building software organizations around individuals with very specialized skillsets. We have people that do the analysis and design, others that do the coding, another group to do the testing, and yet another to do the doc.

We have a specialized group of people to manage the people with the specialized skillsets and to manage the complex interdependencies all this specialization creates. We have project managers, and program managers, configuration managers, deployment managers, and release managers.

Agile software development basically calls for two roles… the product owner and the team. Okay… Scrum has three… product owner, team member, and ScrumMaster. As agile methods become mainstream we had better understand what we plan to do with everyone else.

Specialized skills are not required on the project all of the time. Specialization requires us to understand when folks are needed and when they'll be free. Answering these questions leads us down the path of predictive project planning and complex portfolio models to manage the interdependencies.

Eventually we start thinking more about matrices and less about teams. If we are truly committed to the idea that great teams can deliver more than a collection of talented individuals, specialization presents a real problem.

Our teams needs all the skills required to deliver working software. In an ideal world we have people that are capable of performing in more than one role. This flexibility allows the team to adjust to the changing needs of the project. Less specialization leads to less constraints, and therefore, less complexity and faster delivery.

Traditional software teams need to address this issue head-on as they consider adopting agile methods. Business analysts, quality testers, and technical writers should be full time members of the development team. Team members should be encouraged to diversify their skillsets so they can help in other areas as necessary.

Do we know what is all of this going to mean for the individual, their development plans, and their career path? If not, we owe it to our people to figure it out.

Some team members will want to stay specialists. Often, what we do becomes part of who we are and change can be uncomfortable. Like any kind of organizational change, this change needs to be managed. We need to shepherd people through the transition, get them the tools they will need to be successful, and encourage them along the way. Some will decide agile is not for them and leave in spite of your best efforts. Wish them well.

We must be intentional about helping everyone make the transition to agile, otherwise we will create a vocal group of detractors that will oppose our efforts to lead change. Let's define the path, point the way, and hope everyone is willing to come along for the ride.

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/what-about-me.html

Subscribe to this blog

Subscribe to Leading Agile

One Team

Why is teamwork such an important part of the agile value system?

As people work together over time they learn each other's abilities and communication styles. They learn how to interact with each other in ways that are more productive. Teams develop a culture and establish norms that allow for very efficient communication. They learn to leverage each other's strengths. Over time, this allows a team to establish predictable throughput and a regular pattern of delivery.

We often underestimate what it takes to bring people into relationship with each other. We seem to think that we can matrix people into teams and expect them to start performing right away. We seem to discount the fact that teams need time to form and get to know each other before they can be productive. We overlook personality and chemistry between team members and expect everyone to operate as if they've worked together for years.

The belief that we can breakdown and reform teams on the fly is a belief in local optimization. It is a belief that if we optimize the abilities of the individual through specialization and optimize the process through definition of best practice, people become interchangeable. Aside from the interpersonal issues we've just discussed, this has led our industry toward an ever increasing level of resource management, project management, and portfolio management complexity.

Our challenge is that we focus too much of our limited time and energy managing complex resource interdependencies rather than solving our real business problems. Simplifying means we focus less on developing individual specialties and more on the overall capability of the team. To optimize our teams we will have to broaden the teams collective skill. We have to let go of our addiction to individuals with specialized knowledge that become a single points of failure. We need more people that know more things.

This will require courage and a commitment to broadening the skills of our people. It will require a commitment to team building. It will require commitment to the belief that a well functioning team can deliver more than a collection of talented individuals.

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/one-team.html

 Subscribe to this blog

Subscribe to Leading Agile

The Road Less Traveled By

"Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference" - Robert Frost (1874 - 1963)

As leaders, what prevents us from letting go and empowering our organizations?

In my earlier post "The Road to Agility" I encouraged teams to begin their Agile journey by proving themselves trustworthy. The idea was that we cannot expect leaders to empower a team when that team has not proven itself ready to be trusted.

Well what about our leaders? These folks need to have some skin in the game as well, right? What might be a good first step for a leader that wants to build an empowered, self-directed team? I suggest that as leaders, the first step is to challenge our motivations and learn to control our ego.

As leaders we are ultimately accountable for the performance of our organizations. As such, a poor performing team is a reflection of our ability to do our job. It is our duty to make sure the team is performing well because we will be held accountable. To take it one step further, a poor performing team will make us look bad.

How we see ourselves as people can make a big differences in how we choose to respond. How well we keep our egos in check can make all the difference.

If we allow our self-worth to be tied to the performance of our team, we will be inclined to get performance at all costs. With a team that is struggling, the leader is likely to create a rules based system that measures performance based on process rather than results. Any bump in the road is an attack, any deviation from plan a threat to us personally. When the team does well, the leader is likely to take the credit and share little of the glory.

The team becomes a vehicle for validating us as individuals.

Separating our self-worth from team performance allows us the freedom to operate as a mentor and coach. We seek out opportunities for the team to develop and gain new experiences. We create structures that allow them to be successful. We look for ways to recognize members for their contribution. We desire to serve rather than be served, support rather than command, and empower rather than control.

We as individuals become the vehicle for validating the team.

As leaders, we are always going to be accountable for the performance of our teams. How we respond to that challenge will make all the difference in our ability to embrace Agility. Challenge your motives and ask yourself what you desire as a leader. Ironically, the less you can make it about your success, and more about the success of the team, the more successful you will be in the end.

What you bring as a person, what road you choose, will make all the difference.

Link to orginal post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/the-road-less-t.html Subscribe to Leading Agile

An Afterthought

I've got a question for you... Do the same rules for leading volunteers apply when leading employees?

We pay people to come to work but can we buy their enthusiasm and creativity? What about their passion and excitement? Maybe we need to consider applying the same or similar leadership principles in our businesses that we've discussed for our volunteer organizations? Do we need to modify our list for business and employees? Let me know your thoughts and what's working for you.

Here's a link to my original post on Leading Volunteers:
http://www.leadingagile.com/2008/02/leading-volunteers.html Subscribe to Leading Agile

Leading Volunteers

Are you a part of a volunteer organization? Lots of us are. You might be a member of a Church, some sort of professional organization, or even your local outdoor club.

I am involved with several. I am the Treasurer of APLN, the President of a small private school my wife and I helped start a few years ago, an adult leader with The Boy Scouts of America, and an active member of my Church. It seems that all these groups have one thing in common; they need more people to help. Said another way, it seems that the same few people are doing almost all the work. Sound familiar?

Being a leader in many of the organizations I support, I have begun to see a pattern. When we feel like we are doing more than our share of the work, we tend to get upset with the people who aren't. We are so passionate about what we are doing it is beyond us why everyone else is not driven to that same level of performance.

I'm not making excuses for anyone but people are just spread too thin. Between our jobs, our families, getting the kids to their various activities, and trying to find some time to relax; there is just not enough time in the day to be consistently involved. As leaders, this is our reality. So then, what can we do to increase the number of people willing to chip in and do their part? What could make the work of our group so important that people would make time in their busy schedules to volunteer?

I've become pretty convinced that telling our volunteers to step up or leave won't work. Most of them will probably just leave. Likewise, mandating some set number of hours they have to work probably won't do it either. Those folks will probably leave too. We want people that are passionate about our organizations. We want the people that want to do their part. Do we really need a bunch of guilty people dragging around out of some perceived sense of obligation? I don't think so.

I suggest that we begin by letting go of our negative feelings and start taking responsibility. You just can't lead effectively running around hacked off at your membership. Chances are you missed some things along the way that could have helped people get more involved. Let's take a few minutes, figure out what those things are, and let's get busy doing them. No more whining, got it?

So here goes Mike's list of nine things you better be doing if you want to effectively lead a group of volunteers.

1. Have a Compelling Vision
Let's create a vision that really gets people excited, inspires them, and shows them what is possible. A well crafted vision communicates where we are trying to go, what mountain we are trying to climb. Involve your volunteers in creating the vision. Give them some say in what you'll do as an organization to make the vision a reality.

2. Provide Opportunities to get Involved
Opportunities must be right there and readily available. We must make it simple and clear what needs to be done and what they can do to help. People don't always want to figure those things out for themselves, they want to be led. They want to know what to do and how their contribution supports the overall mission of the group.

3. Give People Simple Guidance
Folks only need a few rules to help them along the way. Guide rails if you will to instill the internal confidence that they are headed down the right path. They need to know they are doing the right things and that your organization will stand behind their efforts.

4. Get Out of the Way
Nothing kills initiative like being told how to do something. Once you have given your team their objectives, leave it up to them how the work gets done. You'll have to accept that some work won't be done exactly like you would have done it. As long as it furthers the goal, let it go.

5. Follow-Up
This communicates to the team that their contribution is important. Review deliverables and help your team to adjust if something does not get done. Agree on the impact of the missed objective and what each of you will do to help recover.

6. Accountability for Results
You have given your volunteers important work. They have accepted their mission and taken your guidance to heart. Outside of moral, ethical, or legal issues; you are holding the team accountable for what was delivered, never how they got there. Holding people accountable for results taps into their creativity and energizes their passion. Now we are really getting somewhere!

7. Make It Okay to Make Mistakes
People will feel more comfortable taking initiative because it is safe. They won't feel like they have to be perfect in order to contribute. People taking initiative is key in a healthy volunteer organization.

8. Give Praise.
People want encouragement, they need it, they thrive on it. Many people never ever hear they are doing a good job. If your organization is the one that tells them, just think what a powerful motivator that could become. As leaders, it is easy to take our volunteers for granted because we are working so hard ourselves. They need it, so make it happen.

9. Have Fun
People don't want to work with a bunch of grumps. Enough said.

At the end of the day, we all want empowered, motivated, and self-directed volunteers that are working toward our common goals. If that doesn't sound like the people in your organization, take responsibility. Look first at how you are leading your organization and if you are doing everything you can to create opportunity and empower your team.

We get so caught up in the work of our organizations, we often don't take time to really lead them. Giving people a means to serve and the guidance to serve well is a powerful contribution. It is probably the most powerful contribution you can make to the long term health of your organization.

If you have something to add, please leave a comment. Feel free to disagree with the nine items I chose. These just seemed to me to be the most essential. I look forward to your feedback.

Good luck, lead well.

Link to orginal post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/leading-volunte.html Subscribe to Leading Agile