Atlanta APLN Leadership Summit: Early Bird Expires on August 31st

Early bird rates expire on August 31st. After the 31st, the price of the conference goes from $399 to $599. The conference is an exceptional value at $399 so make sure to register this week to take advantage of the early bird pricing!

"Leading the Agile Transition"

September 25th and 26th
Marriott Atlanta Perimeter Center

http://summit.aplnatlanta.org

We are proud to announce that the next APLN Leadership Summit is coming to Atlanta!

For the past few years, local APLN chapters have organized and hosted regional Leadership Summits. These events have been very well received and attract fantastic speakers and exceptional local thought leaders.

This is your chance to attend an Agile conference specifically designed to address the needs of the Agile community in Atlanta and the Southeast. Our speakers will discuss topics ranging from Product and Portfolio management to Agile Architecture and Metrics. Each speaker will present two talks, one geared toward the practitioner that is looking for tools and techniques they can use on a daily basis, the other toward leaders considering, or leading, a switch to Agile.

The summit is geared toward new and seasoned Agile leaders at all levels: organizational leaders, product leaders, development leaders, and project leaders. This is your chance to spend a whole day with some of the leading experts in the area of Agile Leadership, to network with with other agile leaders, and to share your experiences and concerns with those who are in the same situation as yourself.

The Dallas and Seattle Summits were a huge success! Next up is Atlanta!

The APLN Leadership Summit format includes:

• Networking opportunities throughout the day
• Speakers addressing how to lead their organizations to become agile.
• "Think Tank" sessions on Agile Leadership with topics addressing advanced leadership tools, experiences, lessons learned, and issues yet to be resolved.
• Networking social at the end of the first day to review think tank solutions and suggestions.

The APLN Atlanta planning committee has lined up an all star group of speakers and local Agile leaders. The conference is limited to 120 participants so you need to act now. If you are in the area, or able to make a the trip, the Atlanta Summit will be well worth attending.

For more information (including speaker bios and abstracts) and information on how to register, please visit the APLN Summit home page: http://summit.aplnatlanta.org

Subscribe to Leading Agile

Refactor Your PMP: Human Resource Management

Back so soon? I told you guys it was time to get this knocked out! Last post we talked about Quality Management, this post we are going to hit Human Resource Management.

According to PMI, Human Resource Management includes the processes that manage and organize the project team. Pretty simple huh? This is an interesting topic because we generally want agile teams to be self-managing and self-organizing. Do we throw this one out all together? Is there any way we'll be able to bridge the gap?

I've got to honest with you guys, I am not exactly sure where this one is going to end up. Let's jump in and see what we can do.

Human Resource Planning

PMI Definition: Identifying and documenting project roles, responsibilities, and reporting relationships, as well as creating the staffing management plan

Does a RACI diagram have any place on an agile team?

Agile tends to assume that you are staffing your team with specializing generalists. What is a specializing generalist you ask? These are people that may have specialization in a given area but are willing and able to operate outside their area of specialization.

Specialization is problematic because it leads to matrixed organizations. If a specialized skill set is required only part of the time, we need to find something else for that person to do with their downtime. Organizations end up filling that downtime with other project work. The problem here is that working on more than one project dilutes focus and creates artificial dependencies between projects. Real dependencies are one thing, self imposed dependencies are quite another.

Specializing generalists allow me to have a single person do more than one kind of work, eliminating constraints, and reducing the need to matrix people across multiple projects.

Teams work best when they stay together and are all focused on a common objective. They establish a stable throughput, they trust each other, they understand how to work together. Agile values continuity and it's part of what keeps agile teams fast and lightweight. This is a very difficult, if not impossible, to achieve in a matrixed organization.

That said, we still need to know overall what skills are required. We need to do the necessary due diligence to make sure that our team collectively has the competencies required to deliver. We need people that can potentially fill several roles on the team. If a RACI diagram helps you figure that out… go for it.

Acquire the Project Team

PMI Definition: Obtaining the human resources needed to complete the project

After giving this one some thought, I don't think agile has much to say here or much overlap with PMI. I'll just take this opportunity to restate the importance of building teams with specializing generalists. Getting the right people on the bus makes all the difference.

Develop the Project Team

PMI Definition: Improving the competencies and interaction of team members to enhance project performance

Agile teams improve competency through collaboration and teamwork.

How does collaboration and teamwork come into play on agile teams? Most teams will have a mix of senior people and junior people, people who are better in one are of the application than in another area of the application. Agile encourages close collaboration amongst team members, pair programming, and shared ownership. It gives everyone the opportunity to broaden their skillsets, learn new technologies, and become proficient in areas of the application they might not otherwise touch.

Daily standup meetings keep people involved and connected with each other. Retrospectives help the team learn from each other and decide how to work together more effectively. Creating this collaborative learning environment is one of the reasons that collocation is such an important aspect of building agile teams. Agile leaders value team building and collaboration so much, they tend to focus more energy on activities that give opportunity to develop closer interpersonal relationships.

If your team members lack a particular competency, and no one on the team has that skill, training one or more folks becomes a critical success factor. Make sure you have that time and money in your overall project plan for formal training.

Manage the Project Team

PMI Definition: Tracking team member performance, providing feedback, resolving issues, and coordinating changes to enhance project performance.

Ideally we want our teams to be self-managing and self-organizing. Give people the objective and get them the environment and the tools they need to deliver. The agile project manager can play a huge role in creating the kind of environment for this kind of behavior to emerge.

An agile PM needs to lay out the vision, make sure the team has the necessary skills to do the job, layout the initial planning structure, establish the metrics, and support the team by removing the things that get in their way. Part of establishing structure is keeping things visible and maintaining a culture of accountability. Iteration planning, daily stand-ups, product demos, and retrospectives help create this culture.

As an agile PM, I almost always track project burndown, iteration burndown, defect trends, and historical velocity. These metrics, in conjunction with the daily standup, usually give me a pretty good idea of how the team is doing. There have been times when I have needed to track individual hours and individual velocity but these cases should be the exception to the rule.

Agile definitely puts more emphasis on leading the team over managing the team. The reality is that sometimes your team is not healthy and mature or in a good place to manage themselves. A good manager, with a focus on servant leadership, can help create an environment where teams can thrive and people can learn what it means to take full ownership of project outcomes.

Now if we could just get PMI to stop calling our team members Human Resources!

Subscribe to this blog Subscribe to Leading Agile

PMI Agile Special Interest Group

The past few weeks I have been involved with a group of folks that are working to start up a special interest group within the PMI, specifically around agile methodologies. There are some pretty heavy hitters involved: Michele Sliger, Stacia Broderick, Mike Griffiths, Mitch Lacey, and Jesse Fewell amongst others.

As the PMI begins to accept some of the agile practices into the PMBOK, this group could be influential in helping to shape that content. There may be room for a domain specific addendum specifically addressing agile practices.

I am interested to know what you think. Is this a bad idea? Think it is a good idea and want to help out? Should APLN support this initiative? What are the risks? There are lots of questions to answer and I am really interested in your thoughts.

Please feel free to share your comments? If you want know more, take a look at the following FAQ for a little more information.

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Quality Management

Okay… it has been a while since my last installment in this series. Aside from my general inability to stay focused on a single topic (what was I thinking committing to a nine part series) I got really swamped preparing for Agile 2008. I've got two talks coming up in November on this material, one of which has a presentation due in early September, so I guess it is time to get busy and get this series wrapped up.

Last time we covered Communications Management, in this post we'll discuss Quality Management.

As always, let's start with the PMI definition of Quality Management. According to PMI, Project Quality Management includes all the activities of the performing organization to determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. There are three processes included in this knowledge area: quality planning, perform quality assurance, and perform quality control.

If you've been following this series, you'll know that my general approach with the PMI is to take guidance from the PMBOK and figure out how to satisfy the intent of the process with a more agile practice or principle. Agile is all over quality planning, quality assurance, and quality control but we often use different language to describe how we satisfy these objectives and we often plan for these activities in a pretty different way.

Let's see what we can do to bridge the gap...

Quality Planning

PMI Definition: Identifying which quality standards are relevant to the project and determining how to satisfy them

Quality planning is really about the initial set of assumptions (we make as an agile team) about how we are going to manage quality on our projects. As it relates to developing software, quality planning has mostly been done for us… it is implicit… it is understood by virtue of the fact that we are using an agile methodology.

When we have discussions about doing test driven development, pair programming, or continuous integration; we are making decisions about how we are going to handle quality. The decision to make use of acceptance criteria is simply a decision on how we will know we have met the requirements of our stakeholders.

Are we going to do unit testing? How about manual regression? Will we need to test for performance, scalability, or security? How will we know we have met any applicable regulatory or audit requirements? I would venture to say that most agile teams are having these conversations. Even if your team is not writing this stuff down or getting sign-off, you are implicitly developing your quality plan.

It is up to the team to balance how much of this needs to be documented. Ask yourself to what degree will a document facilitate understanding or help with stakeholder communication? Consider how much documentation is required by your organization. Keep things simple, minimally prescriptive, and make provisions to adapt your plan as you learn more about the emerging solution.

Perform Quality Assurance

PMI Definition: Applying the planned, systematic quality activities to ensure that the project employs all processes needed to meet the requirements

You've made some initial decisions about how your team will meet the quality expectations of the organization… now it is time to execute. Quality assurance is about making sure we are building the right product from the very beginning.

Early in the iteration, we meet as a team with our customers to define exactly what is to be built. Every role on the project has the opportunity and is encouraged to be involved. There are people looking at the requirements from every conceivable angle: system architecture, development, QA, analysis and design, and usability. We explore the problem from all perspectives, before we set off writing code, to ensure we are building a complete product.

Once we get started building out the features, we immediately execute our testing plans. At a minimum, agile teams are writing unit tests and doing continuous integration. We know at every moment of the project how well the code is performing against the requirements.

If your team has dedicated QA members, the QA folks are testing right along with the development team. Sometimes it is more exploratory and we are not looking for sign-off, we are really looking for feedback. Feedback from the QA team is essential to making sure that the product is evolving according to the quality standards we agreed to at the beginning of the iteration.

The team holds itself accountable by meeting in a daily standup. This allows the team to stay plugged in, assess progress, and identify impediments. In addition, the team has constant access to the product owners. This constant visibility allows the customer to fine tune the solution, as it is being built, to ensure that the product will meet market requirements.

Perform Quality Control

PMI Definition: Monitoring the specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance.

Even though quality is the focus from the very beginning in an agile project, we still seek to validate outcomes and formally track the quality of the product we are building.

The advantage of automated testing is that we know the health of the product in real time. We are able to measure and track defects and get them resolved as soon as they are introduced into the build. Manual testing, in parallel with the automated testing, gives a more intuitive way to exercise aspects of the code the are difficult to automate.

As a project manager I am constantly tracking burndown at the project level to see how well the team is doing against the backlog. Within the iteration, I am tracking task progress to make sure that we can deliver on our commitments. Agile teams also track defects, defect status, and test trends. All this gives the team a way to continuously control the project quality.

Agile teams don't wait until the end of the project to test, when we have the least amount of time to actually fix a problem, or respond to a change. We know at all times the health of the project, if the team is burning hot, if defects counts are trending up or down, how well we are resolving issues, and if those issues are becoming impediments to getting new product built.

Agile teams review features with their customer as they are completed. They do formal product demonstrations and retrospectives at the end of every iteration. These processes allow the team to control, not only the quality of the emerging product, but also of the processes we are using to deliver that product.

All of this feedback gets folded back into the plan, adjustments are made, and the team adapts based on what they have learned from regularly delivering code.

Next up… Procurement and Human Resources. We'll save Risk Management and Integration Management for last!

Subscribe to this blog Subscribe to Leading Agile

Push eMail Addiction

Okay... I have not really written anything in the past few weeks while I got prepared for Agile 2008 and my subsequent ASPE webinar this past Tuesday. I have to admit, I am kind of tired of thinking agile thoughts for the moment.

Give me the weekend and I'll get back in the game.

I did have an experience last week at Agile 2008 I'd like to share with you guys. A few posts back, I was lamenting the things my new iPhone didn't do that my Blackberry was very good at.

One thing noticeably absent from my commentary was the iPhone's battery life. At the time I wrote that post I'm not sure I knew how bad it actually was. If I have GPS, Bluetooth, 3G, Wi-Fi, and push email running at the same time, and I don't use the phone as an actual phone, I can sometimes get the battery to last about 5-7 hours. That is just terrible.

Last week, while at Agile 2008, I turned all those services off so I could actually have a phone for the entire day. The good news was that I could get the phone to work from 6 AM to sometime after midnight. Not stellar, but acceptable. I was able to function.

So... now the point of this post. When I wanted to get email, I actually had to go into the mail client and check for it. I basically went an entire week with no push email. You know what... I didn't even miss it. The world did not come to an end and no major catastrophe took place becuase I didn't instantly get notified of every new mail that hit my inbox.

The last evening of the conference I was sitting at dinner with a good friend of mine that still has his Blackberry. We were discussing the conference and a myriad of other personal things going on in our lives. It was a great conversation, pretty deep, and pretty meaningful. Our dinner was interrupted no less than five times with an incoming email. Is there anything that important?

Do people deserve to have email answered immediately? Is that a reasonable expectation in today's day and age? Shouldn't the people we have dinner with be able to expect our undivided attention? Is it too much to ask someone to be fully present for an intimate conversation?

It seems that the Blackberry has created a world where we expect instantanous response. I have been on both sides so I am in no place to judge. I've decided for myself that people need to be able to wait 24 hours. If you have to get a hold of me, give me a call. If you choose to send email, expect to wait a few hours for me to get back to you.

For now, I am leaving push email off on my new iPhone. I like my life better without the constant intrusion of email.

Subscribe to this blog Subscribe to Leading Agile

See You in Toronto

It has been quite a week. My Agile 2008 presentations are finally complete and I am ready for Toronto. This is my first time speaking at the conference and I'm pretty excited about it. This is also my first time attending the conference on the vendor side. All in all this will shake out to be a great week, I am sure of it.

I keep telling my wife that while yes, the conference is going to be fun, I am not going to Toronto for vacation. I'll plan to keep the pictures of the VersionOne boat cruise to myself.

Before I head out, I want to give everyone a little more information on my talks, how they came to be, and what you can expect to get out of them. A few months ago I published my abstracts, but now that the talks are actually written, it is time for a little bit of an update. Every one of my talks at Agile 2008 started right here as blog posts and are based on my personal experiences running agile (and not so agile) project teams.

If you are heading to the conference, please come and introduce yourself. I would love to meet you guys!

Leading Volunteers with Agility
August 6th, 2:00PM - 3:30PM, Huron Room

This is a topic I am very passionate about.

I am involved in lots of different volunteer communities, anything from APLN and DSDM, to the small private school my wife and I help run. As I became immersed in thinking and teaching agile, I began to see significant parallels between running great software teams and running great volunteer organizations. Any time you need to engage someone's heart and mind, their passion and creativity, or their enthusiasm and excitement, the principles and the techniques are the same.

This is a workshop so fortunately I don't get to do all the talking. We are going to build on the ideas in my original blog and see where we can take it. We will engage the audience to help explore the problem space a little more deeply, brainstorm some ideas for agile principles that can be applied to volunteer situations, and then see if we can come up with some practical guidance to share with other people trying to lead great learning organizations.

http://www.leadingagile.com/2008/02/leading-volunteers.html

The Good and Bad of Agile Offshore Development
August 7th, 4:00PM - 5:30PM, Conference Room H

Back at CheckFree I was really fortunate to have the opportunity to work with a great team of folks at Infosys in Pune. It is one thing to hear about the pros and cons of off-shoring, but getting to experience some it first hand was invaluable. This is my opportunity to share some of those experiences, and the lessons learned, with the broader agile community.

This talk is an experience report so I only have 30 minutes to get my most important points across. This talk does comes with a six page experience report, so if you are interested, look me up in the conference proceedings. I'll post the report to my blog (and the VersionOne site) after the conference has concluded.

http://www.leadingagile.com/2008/05/taking-agile-offshore.html

Using the Unified Process as a Scaling Framework for Scrum
August 8th, 8:30AM - 10:00AM, Conference Room C

This one is the most controversial of my three talks. Prior to joining VersionOne, I was managing a portfolio of projects supported by a team over 70 people. That team was responsible for several products, each with significant architectural subcomponents, some of which were external to the company, and which collectively spanned a wide range of new and legacy technologies.

We found out pretty quickly that some of the principles being taught in the agile community just didn't seem to resonate when you got bigger than seven people or so. When the skillsets required to deliver became significantly diverse, and the number of people required to build the system get really big, what do you do? We could not find the answers.

Our company happened to be going through a RUP deployment and I had some background using RUP from a previous job. We basically took some guidance from the RUP and used it to scale Scrum.

We used the RUP phases to control risk and prioritize the backlog. Phases also helped us establish more agile tollgates with the business. We took some guidance on use cases and architectural decomposition and we took the 'spirit of RUP'. We learned that doing agile at scale sometimes means you have to be more intentional about architecture, sometimes you need to write more things down to keep everyone on the same page, and we created models for helping everyone, across all the teams, work in effective synchronization.

I start my talk saying that this is not a 'questioning agile talk' it is a 'scaling agile talk'. To some degree this is really a 90 minute experience report on how we scaled agile. Is this the final word on the subject? Probably not. There are others in the community writing in this space. I will be interested to see if this approach gains any traction.

Be warned, the community did not like this talk. I think I got six reviews and all of them were bad. The conference selected me anyway. I am hoping those six people are not lying in wait ready to throw rotten vegetables at me! I am not a RUP apologist, but at the same time, I am not an agile purist either. I am a pragmatist… it's all about getting projects delivered!

http://www.leadingagile.com/2007/09/agile-heart-of-unified-process.html

See you in Toronto!

Subscribe to this blog Subscribe to Leading Agile