Supporting Agile

John Boghos is writing a blog. This post is to let you know a little about John and why you need to care about his new site... Supporting Agile.

John and I work together at VersionOne. John is our customer support lead and is passionate about being excellent in customer service. John is one of those rare... albeit strange folks that are really interested in this space and want to explore how to do it better.

I did a few years of customer support early in my career. It is a hard, often thankless job, and I did not last long. John has made a career out of this. Over the past twenty-four years John has worked in food service, telemarketing, telecommunications, project management, and the software industry.

John's blog is going to explore how to manage a support queue using agile techniques and principles. He will also discuss how to best work with an agile team when you are the guy supporting their product. This is an interesting space that needs some more attention.

There are lots of teams out there using iterations, story points, backlogs, and velocity to try to make some sense out of their support queues. These are teams that are striving to become more predictable and eliminate waste in their processes. I am really interested in what John has to say and look forward to reading more from his experiences.

Visit http://www.supportingagile.com to hear what John has to say. I doubt you will be disappointed.

Subscribe to this blog Subscribe to Leading Agile

Agile Portfolio Management

Functional silos… matrixed teams… unnecessary levels of specialization… these are the factors that make it really hard to run stable projects.

People are spread across too much stuff. Keeping up with where people are supposed to be (and when) is a nightmare. When projects change, it is very difficult to assess the impact because of the number of cascading interdependencies.

Unpredictable projects make for unpredictable portfolios. One significant change and the whole thing falls apart. The cost of change is way too high.

When faced with overwhelming system complexity, we move toward service oriented architectures. In the face of overwhelming requirements complexity, we move toward user stories and use cases. These strategies create independence between agents, hide their complexity, and have them interact with each other across defined boundaries.

It helps make each problem self contained and very well defined. When one component is changed, these strategies contain the cascading impact.

Think about Bill Wake's INVEST model for user stories. Stories should be independent, negotiable, valuable, estimateable, small, and testable. What if we applied the same logic at the project level? What if we created a project portfolio that followed this same general framework?

Let's see what that might look like?

Independent - Projects have minimal dependencies between them. They only share resources when absolutely necessary. You align releases to minimize date dependencies.

Negotiable - Project objectives are defined up front, not detailed requirements. Negotiable is manifest in the agile backlog.

Valuable - Expected return is defined up front. At the end of the project we can clearly assess if the project yielded the expected return.

Estimateable - Projects are well defined enough to get a handle on their size

Small - No project bigger than 3 - 6 months. Make investment decisions in smaller increments.

Testable - Projects must have well defined acceptance criteria

Could an organization run a backlog of projects like it runs a backlog of stories? Could a portfolio owner make decisions about what projects to bring into the next release based on their priority and relative business value? Could we take the sprint planning metaphor and elevate it to the portfolio? The same kinds of things we do to manage the flow of backlog items through the system would be done to manage the flow of projects, just one level up?

Stories are to projects as projects are to portfolios

Do these same metaphors apply? I know some folks are doing this. I don't know of anywhere where this is being written about. Anybody know of someone that has defined a model like this?

Photo Credit: http://www.onshoretechnology.com/EnterpriseServices/BusinessConsulting/tabid/132/Default.aspx

Subscribe to this blog Subscribe to Leading Agile

Why Twitter?

Staying in Touch is Hard

As you might imagine… I lead a pretty busy life. I travel some for my work to train, consult, and speak at conferences. I have three kids involved in Boy Scouts and Tae Kwon Do. My wife and I run a private school we helped start. My free time is usually spent in coffee shops or places as deep in the woods as I can walk. It is very hard to find time for my close friends and family.

There is almost no time for the folks who I genuinely value, would like to stay in touch with, but are not part of my immediate circle.

Prior to the whole social networking movement, those people just drifted away. I might be lucky to see someone at a 20 year reunion or happen upon them in an airport somewhere. Even if you are able to spend time writing email or occasionally talking, it is really intense trying to get people up to speed with what is going on. The result is that people are only marginally connected and only marginally involved in your life.

Keep People in the Know

The beauty of Twitter is that people can stay involved in your life no matter where they are, what they are doing, or what you are doing. When you do get the opportunity for face time, you are not starting from scratch. There are people I have not seen in a year that, next time we get together, will know about my trips to Milan, Paris, and London; they will know what I am thinking about and interested in, they will have seen the latest pictures of my kids, and maybe even know who I intend to vote for.

We have a much better starting place to begin a new conversation.

I can't tell you how many people came up and wished me a happy birthday last month because Facebook or Plaxo let them know it was coming up (it was September 29th by the way). That is a pretty small thing, but it was meaningful to me. I'll bump into people around town that will ask about my last vacation or how some issue I was complaining about got worked out.

Again… it gives us a point of reference and a place to start besides "hey… what have you been up to lately"… they already know.

Building Relationships

There is this one guy who started following me on Twitter that I follow as well. I have never met this guy but I know he is a product manager for a small software company in Toronto, he is obsessed with Batman, likes to play video games, and eats out frequently with his wife. He made an offhand comment one day about a VersionOne competitor so I responded directly to him.

This opened up a dialog that we took off Twitter and onto email. I was able to help him with an agile question he was dealing with and he returned the favor by reviewing a white paper I am writing. That is pretty amazing. Here are two people that never met but in effect know each other so well they are willing to go out of their way to help each other out.

When I was in London a few weeks ago, I was getting really frustrated with some of the poor presentations I attended. I twitted that I was going to write a blog about delivering great presentation (http://www.leadingagile.com/2008/10/delivering-great-presentation.html). A friend of mine in the Netherlands picked up my twit from Facebook and mentioned that he was writing a presentation on giving presentations.

I happened to be traveling with a mutual friend from Denmark who was also writing a presentation on how to deliver a great presentation. I was able to hook the two of them together and now they are going to collaborate rather than working independently. Creating connections where connections don't exist is powerful stuff.

It gives us one more way to stay connected with each other in an increasingly depersonalized world.

Over the Top?

My wife thinks I am a nut. On a good day, I'll probably send out 8-10 updates. Does anyone really care what I am doing that many times a day? Probably not…. but the people in my network are now a bigger part of my life than they would have been otherwise.

If you have any of your own Twitter success stories, I would love to hear them. You can post a response to this blog or shoot me an email directly. If you are interested in following me on Twitter, my id is @mcottmeyer. I'll d you my email address. I'd love to have you come along for the ride!

Staying Connected

Here are just a few things that I do to stay connected:

• Update Twitter from my iPhone
• Twitter updates automatically feed into Plaxo and Facebook
• I use Twitterfeed to automatically generate a twit when I post a blog either to blog.mikecottmeyer.com or www.leadingagile.com.
• My agile blog automatically publishes on Plaxo
• I use TripIt to manage my itineraries and push a travel feed to both my blogs. This let's people know where I am headed and when I will be there.
  
• I have Picassa and Del.icio.us automatically update Plaxo as well
• I have become a guest writer on Agile Software Development in an attempt to grow my network and I also allowed DZone to republish my posts from www.leadingagile.com
  

Anything else you think I should be doing to stay connected?

Subscribe to this blog Subscribe to Leading Agile

Scream Free Project Management

So here is another post I originally did for Artem's Agile Software Development blog. This is one of my attempts to blend a non-agile topic (parenting) with agile thinking and project management. Hope you enjoy it.

Scream Free Project Management

A few weeks ago I had the opportunity to read a book by Hal Edward Runkel called Scream Free Parenting. The title is a little misleading because the book is not really about screaming and the lessons Hal teaches go beyond just parenting. The book is about controlling your anxiety so you can build healthy relationships.

The key idea of the book is that anxiety is at the root of much our conflict. Think about it… we want better behavior from our kids, we are not getting it, and not getting that desired behavior stresses us out. When we yell at our children, we are really saying "I want to be calm, you are not allowing me to be calm, I demand you change your behavior so I can be calm".

How about with our teams? We desire a certain outcome on the project, we might not be getting it, so we start to get anxious. We might not scream at our team but we do exert pressure, we threaten, we manipulate, and we control. When we behave this way as managers, we are in effect screaming at the team to change their behavior so we can be at peace.

The problem is that the more we try to control, the more pressure we put on people, the less likely we are to get what we really want. Princess Leia said it best back in the 70's… "The more you tighten our grip Tarkin, the more star systems will slip through your fingers". The more we scream… the more we demand… the more we try to control… the less likely we are to get what we want.

Being anxious leads us to demand control. The more we try we try to control, the less likely we are to actually get the outcomes we desire.

As project managers we need to get ourselves under control first. We need to operate from a position of confidence and strength. It is up to us to lay out the vision and lead the team. We can establish boundaries and set guidelines for behavior. As project managers we monitor the system, give support, and ensure accountability.

At the end of the day… an empowered, self-directed team will deliver more than one that is being heavily managed. It is this kind of team that will help us meet our goals and deliver on the objectives of the organization. Our anxiety is all that is standing in our way… it the only thing stopping us from creating the kinds of teams that are really going to deliver. The challenge is that we have to get ourselves under control first!

Projects come in all shapes and sizes. Some are software… some are community organizations… and some projects live in your house and eat all your food. Focus on creating context… focus on managing the environment… focus less on managing people and controlling outcomes and you've got a much better shot at making things happen.

You'll lead a richer life and have more fun along the way.

Here is a link to the original post on ASD: http://www.agilesoftwaredevelopment.com/blog/mcottmeyer/scream-free-project-management

Subscribe to this blog Subscribe to Leading Agile

Delivering a Great Presentation

Many of you know that a few weeks ago I started writing for Artem Marchenko's Agile Software Development Blog. If it wasn't for that commitment to Artem, I am not sure if I would have posted anything the past few weeks. This post is one I delivered last week while in London for the Agile Business Conference. I am reposting here for the benefit of my Leading Agile readers.

Delivering a Great Presentation

This week I am in London attending the Agile Business Conference. A few weeks ago I got to attend Agile 2008 in Toronto. Over the next few weeks I will be at the APLN Leadership Summit in Atlanta, the PMI Global Congress in Denver, the Vancouver Agile Conference, and the Better Software Conference down in Orlando.

That is a lot of conferences, a lot of speakers, and a lot of presentations.

If you are delivering a talk over the next few months, especially one that I am attending, please ask yourself the following question: are you are talking with the audience or are you talking at the audience? It is not enough to tell me what you think, you need to make me part of the conversation. Great speakers engage their audience, they show empathy, and they understand what their audience needs to take from the experience.

They deliver value.

Sometimes speakers are content to just get through their 45 minutes and be done with it. It is as if the audience does not exist. Far too many speakers don’t know how to really listen to their audience. It is the speaking equivalent of having a big up front design and following your plan to the end. As speakers we need to be able to adapt to the changing needs of our listeners.

In other words, You need to embody the change you are speaking about.

Here is an idea to consider… why not think about your talk like you would a software project? You could prepare your outline to be a high level roadmap… a vision if you will for where you plan to take the audience. Have a prioritized backlog of key points you want to make and information you want to deliver. Deliver your talk in short iterations and seek feedback from your audience. Adapt based on what you hear. Always… always… deliver value.

To hard? Maybe, but that is why you were asked to come talk in the first place!

Reposted from Artem's Agile Software Development Blog:
http://www.agilesoftwaredevelopment.com/blog/mcottmeyer/delivering-great-presentation

Photo Credit:
www.jpprufino.com/?p=104

Subscribe to this blog Subscribe to Leading Agile

Agile or Iterative and Incremental

Many companies want the benefits of agile but are not ready to make the organizational changes necessary to take full advantage of the methodology. Companies want to say they are agile… they want to derive the benefits of agile… but they are not fundamentally ready to do the heavy lifting required to really make it work. People want to hold onto predictive planning. They want to hold on to functional silos. They want to hold onto matrixed teams. People want to keep their specializations and spread their time over multiple concurrent projects.

What does a concept like velocity mean in such an environment? What about empowered teams? When I talk about iteration planning, daily meetings, and retrospectives; people can't comprehend how they will do this with every project they are working on. They fear they will spend all their time in meetings, and you know what… they are right. Agile assumes team. It assumes you are part of a cohesive whole that plans together, works together, and delivers together. Agile trades the big up front design, heavy documentation, and predictive planning for collocation, teamwork, and collaboration.

You can't collocate, work as a team, and collaborate when you spread across so many projects. You can't stop doing heavy project documentation if you aren't willing to replace it with high bandwidth communication between team members. To get that level of communication and collaboration, people need to be in the same room, they need to know each other, and they need to work together on a daily basis. People need to be part of a real team; not a collection of loosely coupled individuals.

The bottom line is this… you won’t get the speed and adaptability you are looking for unless you are willing to make the tough organizational changes that allow this to happen.

You can still get some mileage from delivering software in two or four week cycles, daily interactions between project members, and frequent project reviews. You can make use of loosely coupled requirements, prioritized backlogs, and rolling wave planning. There is value in understanding the definition of done and making sure that once you've delivered, you have really delivered. Managers can do product planning, release planning, and iteration planning without being particularly agile.

Even though you won't get the speed and adaptability of an agile team, you can still derive some benefits from iterative and incremental delivery. Just keep in mind that while agile prescribes iterative and incremental delivery, not all iterative and incremental delivery is agile. Agile adds all the aspects of team, collaboration, empowerment, inspection and adaptation. For a good article on the difference between incremental and iterative vs. agile, take a look at the following post I found on the AgileCollab blog:

http://www.agilecollab.com/iterative-and-incremental-is-not-equal-to-agile-key-aspects-of-agile

For a siloed waterfall team, this might be a good first step. It would definitely move the needle toward becoming agile.

What get's confusing is when we equate iterative and incremental with agile. Agile is incremental and iterative but it is also a value system… a way of structuring teams… a way of treating individuals. Agile is an approach to engineering products, a technique for managing projects, and philosophy for leading organizations.

It is valuable for leaders to know how to define what their teams are doing. It is valuable for teams to understand where they are in comparison to where they want to be. We can take baby steps towards greater organizational and project agility by implementing some of the practices. If we declare victory before we've done the hard work, we risk never meeting our goals and diluting what it means to be an agile organization.

We should acknowledge where we are, understand where we want to be, and ask ourselves if we are really willing to make the changes required to get there.

Image Source:
http://www.dorlingkindersley-uk.co.uk/static/clipart/uk/dk/rock/image_rock004.jpg

Subscribe to this blog Subscribe to Leading Agile

You are the Impediment

In my post "Secretaries Make the Best ScrumMasters", I made the point that ScrumMasters and Agile Project Managers need to be held to a higher standard. Tracking impediments is not enough. Helping the team remove impediments is not enough. We need project leaders than can help the team anticipate impediments and work to make sure those things never become impediments in the first place.

Project leaders should be able to understand what the team is building, what technologies they are using, and the impacts of using those technologies. We don't' need to be experts but we need to be able to keep up in a conversation. We need to understand what the business needs and what they are trying to accomplish. Project managers and ScrumMasters should be asking questions and digging into places where people disagree.

A good Project Leader can help identify disconnects, find things out of alignment, and anticipate the resources and tools that will be needed to keep the team on track. Some times the team is just too deep in the weeds . That ability is what separates a good project leader from a great project leader. If you are serving in the capacity of a project lead, you need to be focused on developing these skills. The problem is that some people are content to make and track an impediment log.

If you see yourself as the keeper of the impediments… you are the impediment!

Project Managers, Agile Project Managers, and ScrumMasters tend to fall into one of three camps. A lot has to do with their background, experience, and level of professional development. Which camp do you fall into?

The Tracker

This kind of ScrumMaster does a really good job of keeping up with the Impediment log. Whenever an impediment is identified, it gets logged so that it can be reviewed in the next standup meeting. These people spend their time keeping the impediment log up to date. Come hell or high water, they want to see a status update. Our job is to get the impediment from open to closed but don't really play a part in making it happen. These people incessantly follow-up with the team to make sure that every item on the list is being worked on.

Like I said, if you are only tracking the impediment, you have become an impediment. You can expect to be replaced with a spreadsheet, Sharepoint, or Wiki. Some people on the team have tolerance for this, some less proactive people might even like the constant reminders, but in general, if you are only tracking impediments, people will grow tired of having you around.

The Remover

This ScrumMaster does a really good job of working with the business, the team, and other project stakeholders to resolve issues. The will keep a log of impediments but build networks of people necessary to get issues dealt with in a timely manner. These people have some degree of technical and business understanding and actually contribute to the solution. Folks like this can be a real asset to the team. This person will doggedly pursue resolution until the issue is taken care of.

Being able to remove impediments is a great skill to have. If you are able to quickly get issues resolved and keep things moving, you are adding value. The problem with focusing on impediment removal is that it is inherently reactive. You have to have an impediment before you move into action. The goal should be to have as few impediments as possible. If you are content to stay at this level of maturity and knowledge, once again, you are the impediment!

The Anticipator

This is where a ScrumMaster really starts earning their keep. This is a person who can anticipate problems and work with the team to ferret out the things that could go wrong. A ScrumMaster at this level of maturity keeps track of project risks, works with the team to craft mitigation strategies, prioritizes and makes sure that these risks never become impediments to the team.

Sometimes, no matter what kind of strategies you have in place, bad things happen to good software projects. That is where your impediment log and great impediment removal skills come into play. It just has to do with focus and priorities. I choose to work first to keep bad stuff from happening. Once I have done my best preventing problems, I need to be really good at helping the team eliminate them. I choose to be proactive rather than reactive.

So what do you think? Are you an asset to the team or an impediment? Are you are former secretary up to the task?

Subscribe to this blog Subscribe to Leading Agile

Agile and UI design

A few days ago, one of my Twitter buddies asked me to explain how the UI designers fit in on an agile team. I have some experience working with dedicated design teams and user experience folks so I thought I'd take a stab at his question and share my perspective. Once I finished my note it seemed like it might make a good blog post. I'd be interested to hear what you guys think about my answer.

Here goes...

Just to set a little context... my friend asked me to explain the role of the UI designer on an agile team. He explained that they were creating user stories but were not sure how to incorporate the UI designers into the process.

The unfortunate thing about explaining agile is that there is no one right way of doing things. There are principles that I like to see teams apply. Agile is all about creating situationally specific strategies. You just take the principles of agile and apply them the best you can given your constraints.

That said.. my friend seemed to be on the right track. They were creating stories with using a typical agile patterns... "As a user, I want to be able to create a new account, so that I can do X". The principle that I encouraged him to apply is that the story is small enough to be done in a single sprint, all disciplines are involved in implementing the feature (including the UI guys) and at the end of the sprint, it is potentially shippable... in other words, done.

What would that ideal look like in real life? During the sprint planning meeting, the team would collaborate around a whiteboard on what it means to be able to create a new account. The developer might talk about what methods might need to be created. The QA engineer would discuss how it would be tested. The UI designer would be involved helping the team understand what the screen would look like. The product owner would weigh in on the business value and keep the implementation discussions in check.

At the end of the discussion everyone is on the same page about how the feature will be built. Since everyone is on the same page, the UI person can go off and start iteratively working on a mockup (if necessary), the developer goes off and does code, maybe the QA person goes off and starts test planning. If the team is pushing new code up every day, continuous integration in other words, everyone gets to see the evolving product and respond to it.

Just like the code evolves, the doc evolves, the plan evolves, the product evolves.

The typical response from dedicated designers and QA people is that they want to be able to do the work once and for all. Operating in this way feels like waste. I encouraged my friend to keep in mind agile principles like barely sufficient documentation, simplicity of design, deferring decisions to the last responsible moment, and constant refactoring... The key is to keep the focus on working product and off comprehensive documentation.

Just like the dev team will refactor often, the supporting team members may have to refactor as well.

But what if everyone is not in the same room, on the same team, maybe not even in the same company (external customer)? You apply the same principles and adapt them to your environment. I have seen teams do just enough UI design in the previous sprint to keep the dev team moving in the subsequent sprint.... This makes things more complicated and creates more dependencies than an pure agile approach.

When teams take this approach, I liken it to the product owner grooming the backlog and specifying requirements in advance. The UI mockup becomes like a requirement to the dev team.

As a team you just have to decide how much time and energy you want to invest in up front design. You can do agile practices with an up front design, it just causes you to do even more rework if you want to change anything. It really depends on the uncertainty of your market. If things are prone to change, invest less up front. If things are stable, you can invest more.

Subscribe to this blog

Photo credit: jaysmith.us/wp-content/uploads/2008/06/agile.jpg Subscribe to Leading Agile

APLN Atlanta Leadership Summit - Early Bird Rate Extended to September 24th

We are interested in helping as many people as possible attend the APLN Leadership Summit next week. Yes... next week... it is nearly here.

To that end, we are extending the $399 early bird price up to the day before the summit. This is going to be an excellent event and well worth the price of admission.

Michele Sliger from Sliger Consulting and former Rally consultant is speaking on bridging the PMI world to the agile world.

Roland Cuellar is speaking on agile portfolio management and agile metrics

David Hussman from DevJam is speaking on buidling test driven organizations and agile architecture

Peter Hodgkins from Enthiosys is discussing agile product roadmaps and their relationship to quality

Mitch Lacey is going to discuss roles on agile projects and the challenges when we wear multiple hats.

In addition to the outstanding lineup of speakers, we have 5 leaders from Atlanta and the Southeast that have led, or are leading, agile transitions. We are fortunate to have the following leaders come to help:

Paul King - VP Products and Engineering, Agentek, Inc. - Alpharetta, GA
Rick McMichael - VP Product Development, CheckFree - Norcross, GA
Bob Myer - Pillar Technologies, President/COO - Columbus, OH
Steve Cover - Sage Software, VP R&D - Lawrenceville, GA
Bud Phillips - Valtech (former VP at CapitalOne) - Richmond, VA

Come talk to these guys and see how they did it.

Finally we have three awesome keynote presentations.

Robert Holler from VersionOne will be speaking on the need for Agile.

Bud Phillips from Valtech will be exploring the creation of a
development value chain

One of my personal favorites, Christopher Avery will be talking about leading responsible agile transitions.

Needless to say, we are going to feed you some great food the two days you are with us and we'll have an open bar Thursday night... just in case you needed one more selling point to throw you over the edge!

Time is running out. Register today to secure your spot!

For more information visit: http://summit.aplnatlanta.org

To register: http://www.regonline.com/Checkin.asp?EventId=628805 Subscribe to Leading Agile

Secretaries Make the Best ScrumMasters

Okay... so my writing is slowing down again.

I just spent the past few weeks preparing for Agile 2008 and now am in the thick of getting ready for the APLN Leadership Summit in Atlanta (http://summit.aplnatlanta.org) and preparing more presentations for talks coming up in the next few months. I have new found respect for folks that can write as a full time job. Being creative all the time is hard.

This article was my inaugural post for Artem Marchenko's blog Agile Software Development (http://www.agilesoftwaredevelopment.com). I'll be writing for Artem twice a month. The posts I do for ASD will show up there first, and then a week or so later, I'll share them on Leading Agile. If you are not currently subscribing to ASD, I highly recommend you fix that and add Artem to your RSS reader!

So… to get started, let's kick this thing off with a question… are you ready? Do you believe the title of this post?

If you do, don't feel bad, you are not alone. I have been working in project management and around project managers for years. Over that time, I have worked in traditional environments and agile environments. I have worked with PMPs and CSMs. It consistently amazes me the number of people that are converted into project managers for the sole reason they are good at following people around and asking them when they are going to be done.

Before I get into a full blown rant on this, and the potential is there because this issue really hacks me off, let's be fair… a ScrumMaster is not the same role as that of a project manager. A ScrumMaster is more of an enabler of the team. They are there to remove impediments. They are there to be a facilitator and to make sure the Scrum process is being properly implemented. The team is self-managing, self-organizing, and empowered. The team works with the product owner to get the project done. The ScrumMaster is there to enable the Scrum process.

By design, this is a barely sufficient description of what it means to be a project leader. This perspective breaks down at scale and it breaks down with a team that is not prepared to deal with the full implications of what it means to be empowered and self-organized. On most project teams I work with, the ScrumMaster is a project leader, sometimes even a manager or a director. They have a degree of accountability for the project that is equal to or greater than any other individual team member on the project.

When I've got serious money on the line, when I have made hard commitments to the market, I need someone that really understands how all this works. I need someone that can set the context and coordinate between the team and the business. I need a leader that understands methodology, someone that understands what it takes to build software, someone who understands the business domain and how to work with executives. I want someone that can motivate people, stay focused on the vision, and communicate the right information, at the right time, and tailored to the needs of the audience.

A really good project leader, or a really good ScrumMaster, should be able to help the team [not only] remove impediments but anticipate impediments. They need to help the team stay focused and manage risk. They need to be able to broker complex conversations and help the team come to consensus when communication breaks down and egos get in the way. Most importantly, they need the breadth of experience to help the team devise situationally specific strategies for solving complex business problems.

We need to hold our project leaders to a higher standard. We need to nurture and develop leaders that can do more than facilitate a meeting and go get the pizza when the team gets hungry. We need seasoned IT professionals that know how to balance agility and discipline. We need people that have the experience and judgment to take what they know and apply it for the good of the team and the good of the project. We need people that can really lead a self-organized, self-managing, and empowered team. We need people that can hold them accountable.

None of this is easy, and the people that can do this are really hard to find. I am sure there are many great secretaries, that with the right training and experience, could do a really bang up job leading software projects. I have worked with one or two over my career that I would hire in a heartbeat.

As an agile community, I believe that we undervalue the role of project leadership and the breadth of background and experience required to do it well. Much of the problem though is of our own making. Project managers, and even ScrumMasters, have been applying stupid, simple processes for way too long. We have been operating as if we have all the answers and the team is there to do what we tell them. It is our own fault that people don't generally want to have much to do with us. It is our own fault that we have people defining our role so lightly on agile teams as to make us irrelevant. The problem for us is that the ScrumMaster role is necessary but it is not sufficient.

As project managers, we need to focus more on servant leadership and situationally specific strategies. We need to focus less on checklists, Gantt charts, and documents that no one is going to read. Let's establish the right balance of agility and discipline and create a context that enables great project teams to deliver great product. When project management begins to make sense again, we'll start to see project managers recongnized as they professionals they are or should be.

And by the way... I am happy to go get the pizza and occasionally remove an impediment or two. Do you prefer peperoni or sausage?

Subscribe to this blog Subscribe to Leading Agile