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