Agile Chronicles

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!

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://blog.versionone.net/blog/2008/02/leading-volunte.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://blog.versionone.net/blog/2008/05/taking-agile-of.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!

This blog actually predated my time with VersionOne.  Here is a link the post on my personal blog:

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

See you in Toronto!

iPhones and Blackberries

So… if you happening to be following me on Twitter or Plaxo, you'll know that I just switched from a Blackberry to an iPhone. The Blackberry was a fixture in my life for many years. My six year old even knew what it meant to be Crackberry Addict and thought it was funny to give me grief over my addiction

I am sure I am going through some sort of post-Blackberry traumatic stress syndrome. I may very well be dealing with a high-tech version of the shakes. That said, humor me while I share a few observations about this new iPhone and how it compares to the old Blackberry.

The latest Blackberry in my possession (I had 5 different models at one time or another) was Blackberry Curve 8310. The Curve is a very cool device. Great form factor and small with a full Qwerty keyboard. I thought it was a great device until I found out version 4.2 of the OS has a memory leak. After a few days of normal use, the device would start deleting my email messages. This is how the device is designed to behave when it runs out of memory.

It was impossible to use Telenav for more than a few minutes, Google Maps was problematic, and much to my chagrin I was unable to use Guitar Hero III Mobile Edition. That was the straw that broke the camel's back. No Guitar Hero III? What kind of crap is that!

After waiting for months for a patch I got fed up and started looking for other devices. Now that the iPhone has GPS and support for Active Synch it became a viable candidate and now I have a new iPhone. And by the way, my old Curve is listed on eBay. If you happen to be interested, and you might be after this post, you can click here to Buy It Now.

My overall opinion of the iPhone is that it is the coolest piece of consumer electronics I have ever owned. It is beautiful, the interface is slick, I love its seamless integration with iTunes, the audio is fantastic, the web browsing is great, and I can pour a virtual beer and pretend to drink it. I have not found Guitar Hero III yet, but other than that, what more could you ask for in a business device?

Wait a minute… none of that stuff I mentioned makes it particularly good for business. It makes it fun, it makes it cool, and it makes it neat, but it does not make it good for business. Your business might be different from mine, so who am I to judge. I do want to share with you a few things that the iPhone does not do that I think are going to kill it for the business user:

• No ability to do a full text search through anything. That includes your address book, your email, your calendar, or your todo list. It is very fast scrolling through data and I admit maybe that should be enough. I miss full text searching
• No ability to cut and paste.  Someone told me that is supposed to be included in release 2.1.
• No ability to invite a user to a meeting from the calendar. Sure, I have my calendar synched with Outlook but am unable to create a new invitation and ask someone to join me in one motion.
• I miss the integrated mailbox of the Blackberry. I have to go to too many places to find new messages. SMS is in one application, email in another, instant messages in yet another.
• It generally takes me about 6 clicks to get from one inbox (for work email) to another inbox (for personal email). I find that very frustrating.
• Blackberry was able to push my personal email, no matter who my provider was. iPhone is selling push email but you have to do Exchange integration or use their MobileMe. Both work fine but I want to be able to push Gmail too!
• Someone told me you could do background Instant Messaging but I have yet to see it work. I want to be able to be working in email and get an alert that someone is trying to message me. This could be a user training issue, but no one had to train me on the Blackberry.
• Best I can tell, I am unable to tell the maibox to delete all messages, mark all read, mark all unread, or delete messages prior to a certain date. Not a huge deal, but seems it should be easy to implement.
• eMail comes in its native format. If it is HTML, the message is HTML. If it is plain text, I get plain text. Rich text, I get rich text. That is cool… but… if the message is HTML sometimes the text is really small. In the Safari browser I can rotate the device and the screen will rotate. In the mail client this is not the case. My only option is to resize the message and then use my fingers to scroll around and read the message. Not so cool.

I also find the iPhone much harder to use one handed. Where this really aggravates me is when I am driving. I have decided that this is a feature that will probably keep me alive so I am going to give Apple a pass. I am using my iPhone much less on the road than I used my Blackberry. The Blackberry was so easy to use one handed, it encouraged bad habits. If you like to use your Blackberry while you drive, and you know who you are BCS, you might really want to reconsider this device.

One last thing... I find the virtual keyboard very difficult to type on. That said, the iPhone is excellent at figuring out what word I actually wanted to type, so this has been okay, but is not helping me get more accurate.

The Agile tie in???

You have to respect Apple's ability to get a really good product in market.  The first release was good.  The second release was better.  They are capturing market share, validating their model, and making money to build out subsequent releases. 

What if Apple had waited until they had everything I am complaining about in release one?  Chances are they would have delivered a poor product with too much ill conceived functionality.  Using an incremental approach allows Apple to get feedback from their customers and create a product that matches how the device will be used. 

I don't know if Apple is an Agile company, but I think their strategy reflects good Agile principles.  Now that said, I sure hope some of this stuff I am complaining about is on their backlog. I am not sure how much time they have before RIM responds. 

So… in summary:

The iPhone is totally cool. I am happy I have it and am willing to change how I think about mobile devices. If I were still in mainstream corporate America, I would not be able to use it. There is just too much basic business functionality it is missing to make it a viable alternative.

APLN Atlanta Leadership Summit - September 25th and 26th

"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.

You will have the opportunity to learn from:

Peter Hodgkins from Enthiosis as he speaks on Agile Roadmappng
Mitch Lacey on mixing roles in Scrum and how to fail with agile
Michele Sliger on Bridging agile with PMP and how to sell agile in your organization
Roland Cuellar from Lithspeed on Agile Metrics and Portfolio Management
David Hussman from DevJam on agile architecture and what it means to be test driven

In addition you will have the opportunity to hear keynotes from Robert Holler, founder of VersionOne, discussing industry trends and the shift toward agility.  We will also have Christopher Avery, one of my very favorite speakers, discuss personal responsibility and how to lead responsible agile transitions.  We got really lucky having Christopher, he is keynoting the Agile Business Conference in London the day before, and we are flying him in direct from Heathrow!   

This is your chance to attend an Agile conference specifically designed to address the needs of the Agile community in Atlanta and the Southeast.

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

Understanding Real Options

I had the distinct pleasure of spending time with Chris Matts and Olav Maassen last week at the Seattle APLN Leadership Summit. It was a good time all around.

We explored the impolite topics of religion and politics and even shared an idea or two about Agile Leadership. Talking with Chris and Olav was the first time I had anyone sit down and explain to me the concept of Real Options. I was fortunate that I got to hear it straight from the guys that are driving some of the thought leadership in this area.

There is no better way to solidify a concept in your brain than to write about it and teach it others. I am no expert on Real Options but would like to see if I can share with you what I learned. Hopefully we'll generate some conversation along the way.

The concept of Real Options is very straightforward. It is so straightforward that you can summarize it on the back of a business card:

Options have value
Options expire
Never commit early unless you know why

Like most things that appear simple, I think there is a little more to the story, a little more that needs to be explained.

Options Have Value

An option is a choice. It is a decision to select one strategy over another strategy. To buy one product over another product. To build one feature over another feature. To decide on one course of action over another course of action.

Every choice we make has the possibility to yield a particular return on our investment. Our goal is to maximize the value that we derive from our decision making.

Our options, the decisions we make, have value. The interesting thing here is that it is not just the options we know about that have value, the options we don't know about have value too. We are generally pretty good at determining the value of the known options, but what about the value of the unknown options? That's just it… we can't know the value of an option that isn't there yet.

We need time to learn about what we don't know.   We need time to understand the value of the unknown.

Options Expire 

Options have value, but that value does not live forever, it expires. We cannot wait indefinitely to make a decision and we can't wait until we know everything. At some point in time, the window of opportunity for a particular option will close, and the value of that choice will no longer be available to us.

Our goal is to keep our options open until just the point they are ready to expire. We use that time to gather more information and to learn about new options that might present themselves.

Waiting to the last responsible moment, just before the option is ready to expire, allows us to make decisions when we have the most possible information available to us. Decisions cannot be held indefinitely... but they can be deferred.

Never commit early unless you know why

Most people want to make good decisions. Unfortunately, most people would rather make a wrong decision than to live with uncertainty.

This was probably the most clarifying concept I learned during my time with Chris and Olav. We would rather be wrong than to defer a decision. Our need for certainty drives us to make decisions before we have to. Sometimes it drives us to make bad decisions.

Waiting helps us make better decisions. Knowing how long we can wait helps us be more disciplined about waiting. Using Real Options theory can help us determine how long we can wait.

If you need to make an early decision, the key is to understand why. Don't make a decision early for the sole purpose of making the decision. Wait and gather more information. If there is a good reason to make the decision early, and you are comfortable with the outcome, make the decision.

Sometimes there are good reasons for making an early decision. If the value of the option is low or of little risk, you might consider making an early decision. In that case you are making the decision to focus your energy on higher value options. Alternatively, if a situation is high risk and making an early decision would yield an acceptable outcome, that might be a good time to make a decision early. Making the decision would mitigate risk.

Understand why you are making the decision and be aware the limits that decision will place on any current or future options.

So… that is my take on Real Options. If any of you are experts on this topic, please weigh in. I found the concept intriguing and wanted to share with you my understanding.

Open Platform

This is the first in a series of technical articles about the VersionOne API.  The goal of this series is to help the reader better understand the VersionOne open platform. 

The VersionOne application supports a robust RESTful API that is available on all installations regardless of license.  REST is an acronym for REpresentational State Transfer, a proven and commonly used web services architecture based on HTTP & XML.  Unlike SOAP, a RESTful API does not require an intermediate messaging layer, resulting in a simpler approach with superior performance.  Since there are no cross-platform implementation issues or complexities, you can access this API using any programming language or directly from your web browser.  VersionOne offers client side libraries in C# and Java to make application development easier, but in this article I will use URLs so you can experience the power of our API using your favorite web browser. 

The first important thing to know when using the API is that the interface does not refer to assets using the same terminology as the UI.  The best example of this is the ‘Project’ asset, which is referred to as ‘Scope’ when accessed through the API.  The secret decoder ring for all asset types is located in the ‘‘Data API’’ section on the Core API page mentioned in the reference section of this article.

The second important thing to know is that our API is really comprised of 3 interfaces: 

• A Data API which allows you to create, retrieve, and manipulate information in the application.
• A Meta API which allows you to discover information about the asset types and attributes available through the Data API.
• A Localization API which allows you to retrieve the localized value for a specific term.  For example you could use this API to discover that ‘Story’ is called ‘Backlog Item’ when using the SCRUM template.

Finally, here are some basic attributes that all asset types share:

• Name – the name of the asset. 
• Description – the description text. 
• Number – the identifier used by the UI

Now let’s look at some basic queries using the Data API.  The most basic query will return all assets for the selected type.  This query is in the format

        http://{server}/{instance name}/rest-1.v1/Data/{asset type}

As an example, http://localhost/VersionOne/rest-1.v1/Data/Scope returns all project data from the VersionOne application running on my local machine.  If you receive an error verify the URL by removing ‘‘/rest-1.v1/Data/Scope’’, and also check for spelling and case on the asset type (they are case sensitive).  Also note that when using the Data API the browser will prompt you for credentials unless you are using integrated security or the browser has cached your credentials.

Next let’s see how to filter query results.  Consider a case where we want to retrieve the Story we see in our backlog with the ID ‘S-01001’.  Remember, ‘ID’ in the UI is ‘Number’ to the API, so we need to query Story assets with a where clause that only returns’S-01001’.  This query looks like this: 

        http://localhost/VersionOne/rest-1.v1/data/Story?where=Number='S-01001'

The important things to note here are the question mark between the asset type and the parameter ‘where’ and the tick marks around the value.  To reduce the amount of information being returned we can use the ‘sel’ parameter to select specific attributes.  Try the following example

        http://localhost/VersionOne/rest-1.v1/Data/Story?where=Number='B-01001'&sel=Name,Description,Number

Note the ampersand sign before the ‘sel’ parameter. 

I hope this basic information about our API has been informative.  In the next issue I’ll cover some more advanced queries and show how to improve the appearance of the API results.  In the meantime you can use the links below to find out more information about the API and REST, or consider attending one of our API training classes.

More information on the VersionOne Core API (Data, Meta, and Localization) can be found at
http://community.versionone.com/sdk/Documentation/CoreAPI.aspx

More information about Representational State Transfer (REST) can be found at
http://en.wikipedia.org/wiki/Representational_State_Transfer

More information about API training classes can be found at
http://community.versionone.com/training

Refactor Your PMP: Communications Management

As promised… next up we're talking about Communications Management.

According to PMI, Project Communications Management employs the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information. This knowledge area provides the critical links between people and information that are necessary for successful project communications.

There is a neat little book by Andy Crowe called "Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not". This book surveyed over 5000 project managers to find out what the best project managers are doing differently. One of Andy's conclusions is that top project managers spend significantly more time communicating than their less successful brethren.

In some cases these top project managers spent up to 90% of their time communicating in one form or another. I have to say, that is certainly consistent with my personal experience. If something is going wrong on one of my projects, it is usually because people are not talking to each other.

But maybe I am taking a naïve view of what it means to communicate on a project? It seems to me that the PMI definition of Communications Management is a little broader than just making sure the team is talking to each other. Communications management deals with documents and plans and stakeholders. Communications management is really about managing the flow of information.

Since it's common knowledge that Agile teams don't do documents, I am guessing we have some work ahead of us to reconciling these points of view.

Okay… I was kidding with the Agile documentation comment. That said, there is clearly a difference in how these two project management perspectives treat the issue of documentation, reporting, and even interpersonal communication.

Both PMI and Agile have quite a bit to say about how to manage project communications so let's get started.

Communications Planning

PMI Definition: Determining the information and communication needs of the projects stakeholders

When Agile teams talk about communications, they are usually talking about communications within the team. Agile puts a great deal of emphasis on the free flow of information between team members, between team members and the product owner, and even between the team and the direct customer. In some ways, the Agile community has really abstracted the entire stakeholder community behind the role of Product Owner.

Communication between team members, and between the team and its customers, is essential but it is not the only component of communication that must be planned. Sometimes there are other stakeholders that we must take into consideration.

At the team level, we usually deal with team member communication through collocation, whiteboards, wikis, and other rich and collaborative workspaces. Agile teams trade a great deal of written documentation for these more osmotic forms of information exchange. On a small team with a single customer, it might be sufficient to suggest that customers get all the information they need from attending planning meetings, daily stand-ups, and iteration reviews.

When there is more than one stakeholder, or possibly a hierarchy of stakeholders , sometimes it is not sufficient to suggest that these stakeholders come down to the team room and check out the team's progress on the Kanban board. Sometimes we need to do some roll-up reporting across a portfolio of projects or even programs. Sometimes we need to report status at a much higher level of abstraction for a more senior audience.

The key to planning communications on an Agile project is to follow the principle of simplicity. Don't write documentation for the sake of documentation. Find out what your stakeholders really need and provide it as quickly and as simply as possible. Make use of natural information sources that the team is already producing (task boards, burndown charts, architectural representations) and create documentation that enables your business to make decisions.

Keep things light, go for face to face whenever possible, and when your stakeholders require more; make things as simple, clear, and accurate as possible.

Information Distribution

PMI Definition: Making needed information available to project stakeholders in a timely manner

At the team level, information distribution focuses on those rich channels of communication I mentioned in the last section. Agile teams keep their status up to date using large, visible information radiators that everyone in the team room has access to and can update themselves. These repositories of information are there for the team to know where it is at all times and so they can manage their work. The side effect of these radiators for the Project Manager is that you have instant access to real time information about the health of the project, release, or iteration.

Often, design and architecture will be worked out on whiteboards and then minimally documented on a Wiki or Sharepoint so they can be easily changed as we learn more about the evolving system. Agile teams lean toward lightweight artifacts and central, universally accessible document repositories. Agile teams recognize that the only truly accurate representation of the product is the code itself ; therefore documentation is kept light and at a pretty high level.

Sometimes a customer has a need for more detailed documentation to manage an external dependency or possibly an audit requirement. In these cases, that increased level of documentation is built into the estimate for the feature. Documentation is not free and it will slow down the creation of working software.

The key once again is to figure out what is the minimum amount of documentation needed to satisfy the requirement. Document systems at the highest level of abstraction you can get away with. Make sure you understand the information needs of the external stakeholder, make sure that work is represented in the backlog, and that it is prioritized to meet the needs of the organization.

Use the same collaborative techniques you would use to build features to create the documentation required by the business.

Performance Reporting

PMI Definition: Collecting and distributing performance information.  This includes status reporting, progress measurement, and forecasting

Okay… so we've already talked about things like burndown charts and Kanban boards. These are tools that a team will use to organically manage their work and make sure they are on track. As an Agile project manager is your responsibility to help the team and encourage that these tools are kept up to date. For the most part, these are the only tools you will need to understand the health of your project, and you largely get them for free.

Performance on Agile projects is pretty simple. You know how big your backlog is and you know how much you are able to complete each iteration. Based on these two variables you are able to predict how many features you will be able to complete before the end of the project, release, or iteration. I personally like to keep a high level project roadmap that helps me understand where the project is expected to be at certain points as it progresses to completion. This is also useful for managing external dependencies.

These simple tools help you understand what progress you are making against expectations and if you'll need to extend the release, adjust scope, or request additional funding. Since you are an agile team, you'll more than likely be communicating how early you'll be, how much more you'll be able to do, and how much more value you've delivered to the organization.

Either way, you have a tremendous amount of information at your disposal to communicate project to the project stakeholders. Think EVM based on delivery of working product.

Manage Stakeholders

PMI Definition:  Managing communications to satisfy the requirements and resolve issues with project stakeholders.

Managing stakeholders is really about managing the issues that come up during the life of the project. A significant benefit of Agile is that nothing is hidden. This level of visibility gives the project manager the information they need to resolve problems and remove impediments.

Issues can arise during iteration planning, execution, closedown, or just in the course of day to day work. Just like on any project, these need to get tracked and dealt with as soon as possible. Issues are reviewed during the daily stand-up meetings and retrospectives.

There are always going to be some issues that cannot be dealt with by the team. I typically hold a weekly or bi-weekly meeting with senior stakeholders where they get a distillation of significant impediments and what I need them to do to help me resolve the issue.

It is my opinion that stakeholders need to be managed and issues resolved no matter what your software development methodology.

I think that does it for this installment. That was much longer than I had expected. I figured communications management would be one of the easier topics to discuss. Maybe I just need to go home for the day.

Let see… next up… Quality Management.

Managing Too Much Complexity

"Any fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction" - Albert Einstein.

Why is managing an enterprise portfolio so hard? It is hard because we make things too damn complicated. We have fragmented our organizations to the point that getting anything done is nearly impossible. We are so focused on optimizing the subcomponents of our organizations we forget about making a cohesive whole.

Let me give you an example. It is pretty common for development organizations to create silos of people organized around a particular skill set. You have a manager for the BA team, the QA team, one for the Java developers, and another for the Cobol folks. The idea is that we want the best group of QA people we can possibly get. We want to establish best practice and consistency. We want managers that know how to train and develop QA talent.

Now what happens when we need to get a project done? Well... we reach out to each of the functional managers and request resources. Sounds reasonable until you realize that each of these resources is not required on the project 100% of the time. I only need that QA person part time during a few specific months of the project. What does that person do with the rest of their time? They work on something else.

You have just established your first two dimensions of complexity.

When you look at a project portfolio this way, you create a series of interdependencies between projects that are very complicated to manage. The likelihood of any one project, deliverable, or task landing exactly when it is planned is generally pretty low. Any deviation from plan creates a chain reaction through the portfolio that decreases the likelihood that anything will get done when you planned.

Most companies are not content to stop with two dimensions of complexity, they want more. I routinely see organizations trying to manage 5 or more. Let's explore some of these dimensions before we talk about how to detangle this mess.

Organizational Complexity

This is the functional silo arrangement that we already discussed. This results from a desire to optimize for individual skills over team work or product alignment.

Project Complexity

Project complexity results when we create dependencies between projects due to tight coupling of resources or shared components. Projects are essentially investment decisions. Tight project coupling limits the organizations ability to take advantage of new market opportunities.

Team Complexity

This one is related to Project Complexity in the sense that it results from building teams of matrixed resources. Often organizations will see value in building teams but fail to align them with a particular initiative or product line.

Architectural Complexity

To some degree, most companies take advantage of reusable system components and other shared services. I am loosely referring to this set of shared components as the Architecture of the system. Unless you have total shared ownership of the code, it creates another dimension that has to be managed.

Product Complexity

Product complexity results from matrixing the product roadmap across any of the other dimensions of complexity. This type of complexity results from lack of consistent investment in the product line.

These are the five I see most frequently but please let me know if there are others I am missing.

Okay… back to our original question. Why is managing an enterprise portfolio so difficult? It is because we are trying to manage across too many dimensions of complexity. We are creating too many tightly coupled entities that all have to operate in perfect synchronicity.

We know this is complex and nearly impossible to manage so what do we do? We create huge bureaucracies to deal with the complexity. We have to make sure that people are in the right place at the right time working on the right things that all the interdependencies are managed and the schedules are kept up to date. Phew!

This is a crushing amount of work. Even if you can model it, the people in your organization either can't or won't invest the time to understand it. It is a complex abstraction of reality but it isn't real. People don't believe it, don't have any ownership of it, and therefore it gets ignored.

People will pay lips service to the model until it gets to be crunch time.  When crunch time hits, people will simplify your organization for you. They work on their number one initiative and everything else will get put on the back burner. If your lucky, your organization will deliver its highest priority, but everything else will suffer.

The Solution

Let's get intentional about how we manage complexity in our organizations. I believe that a well run organization can deal with maybe two dimensions of complexity. Most management systems can adequately deal with two dimensions of complexity. It is something people can get their heads around and own.

So… what does this mean? It means that you have to pick two dimensions and align the rest of the variables in accordance with the two you choose to manage.

For example, you could choose to align your Organization, Team, and Architecture on one axis and align your Product and Project structure on the other. An alternative might be to align your Organization, Team, Architecture, and Product while keeping Projects on a separate axis. Most agile literature assumes one axis with all the dimensions of complexity in alignment.

This is part of what makes Agile so hard to implement in many companies.  Its just not how we are currently structured.

Every organization is different and operates under different constraints. You will have to decide for yourself what dimensions of complexity you business can really handle. The goal is to reduce complexity than to try to manage it.

Good luck!

Refactor Your PMP: Scope Management

Okay… let's get back to our discussion on how to look at the PMI knowledge areas from a more Agile point of view. Last time we tackled Cost Management, this post let's look at Scope Management

According to the third edition of the Project Management Body of Knowledge, Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. PMI states that project scope management is primarily concerned with defining and controlling what is and is not included in the project.

I find it a little entertaining how these statements seem to be universally interpreted as "define everything you are going to do up front and make sure you deliver what was originally defined". While that may have been the intent of the PMBOK Guide, some projects don't lend themselves to that kind of up front planning. Some projects must allow for discovery. Some projects must adapt to changing markets, or at the very least, adapt based on the teams understanding of the emerging product.

For some of us working in more dynamic problem domains, ensuring that "the project includes all the work required", is a process of discovery. Controlling what is included, and what is not included, is an ongoing concern rather than something done once for the entire project. We need a project management framework that embraces this uncertainty rather than wishing it away or pretending it doesn't exist.

I am becoming convinced that Project Managers default to this static point of view because we have never been taught another way of managing projects. We just don't have the tools to deliver projects any other way. So… that said, let's take a moment to look at the PMI Scope Management processes from a more Agile point of view. I bet we find another way of approaching Scope Management that does not involve defining everything up front and then locking it down for the duration of the project.

Scope Planning

PMI Definition:  Creating a project scope management plan that documents how the scope will be defined, verified, controlled, and how the Work Breakdown Structure will be created and defined

Agile project management practices are really the embodiment of a scope planning approach. As a project manager, especially a traditional project manager making the switch to Agile, I have no problem documenting this for my organization. An Agile Scope Management Plan is going to address things like creating the backlog, characteristics of a good backlog item, how we are going to establish velocity or throughput, how we are going to measure burndown against the backlog, and how we are going to deal with changes to the backlog.

Scope Definition

PMI Definition:  Developing a detailed project scope statement as the basis for future project discussions

Scope on an Agile project is defined in the product backlog. The backlog is a listing of the features that your product owner would like to have included in their project. One of the most important considerations to keep in mind is that every item in the backlog should be independent of each other. This is the secret sauce that makes it possible to reprioritize and make changes on the fly. Bill Wake has a great explanation of what makes a good backlog item on his website: http://xp123.com/xplor/xp0308/index.shtml.

Rather than looking at the product backlog as a static indicator of what WILL be built, look at it as the baseline for further adaptation. It is expected to change as we learn more about the emerging product.

Create WBS

PMI Definition:  Subdividing the major project deliverables and project work into smaller, more manageable components

This is one of the toughest things for traditional project managers to get their heads around. There is no WBS on an Agile project, at least not one in the traditional sense. From the Scope Definition section, we learned that our backlog represents the scope of the project and that each of the backlog items should be independent of each other. Independence is key because it allows us to do just in time scheduling.

Agile projects are broken down into smaller projects called releases. Project releases are broken down into smaller time-boxes called iterations. Content is pulled into a release just prior to its start, and only as the previous release is winding down. Likewise, content is only pulled into the upcoming iteration as the previous iteration is coming to a close. The idea here is that we are going to review what the team was able to complete and make decisions about the next increment based on what we learned from delivering the previous increment.

As an Agile Project Manager, I am generally comfortable laying out a high level plan to understand where I expect to be at certain points in the project. I am also comfortable keeping a chart of external and internal dependencies to help manage commitments. The key is to use these as guidance for decision making and indicators of progress. Problems arise when these tools restrict our ability to learn and adapt to the realities of our projects.

Scope Verification

PMI Definition:  Formalizing acceptance of the completed project deliverables

Each iteration we will decide the next best increment to build and then review the outcome once we are complete. The stakeholders either accept or reject the outcome of the iteration and work with the team to decide the next best set of features to build.

Because we want to maintain the ability to adjust the product as we learn more about the emerging solution, we focus on making and meeting commitments in smaller increments. Scope verification is done based on the outcome of these small increments of product and how they align with the product vision and the goals of the release.

Scope Control

PMI Definition:  Controlling changes to project scope

Agile teams take a value driven approach to delivery rather than an activity based, or even deliverables based, approach to delivering projects. The product owner can change the scope of the product at will, but is always focused on delivering the most value possible given the available times and resources.

Agile teams give the product owner a tremendous amount of discretion over how the system is constructed and even accommodate changes even late into the life of the project. It is understood by Agile teams that changing scope involves tradeoffs. The product owner is substituting features that add greater value for those that provide less. To add one thing, something often has to be taken away.

Next Up…  Communications Management

Delivering Value

Last week I was out on a client visit to do a couple days of product training. The customer was not only new to VersionOne but also new to Agile. The idea for the engagement was to blend product training with some targeted methodology training to see if we could get them jumpstarted and on their way.

It became pretty obvious by the middle of the first day that our original training plan was not going to suit their needs. While I was prepared to deliver exactly what they asked for, the training would not have delivered the value that they expected.

Had we followed the original training plan, I would have left the customer unable to effectively use our software.

Coming from a traditional project background, I am a firm believer that some degree of up front planning is essential.  The problems start when we are so confident in our plans that we stop listening. When we stop listening, we stop learning. When we are unable to learn, we are unable to adapt.

I met with the customer and shared with them my observations. We discussed an alternative approach for our second day and agreed to take the training in a different direction. We came up with a new plan that better met their needs and put them in a much better position to be successful.

Did changing course introduce some risk? Absolutely. Change always introduces some risk and following the original agreement would have been the safer approach. By taking that risk we were able to generate greater value for both the customer and ultimately for VersionOne.

At the end of the day, isn't that what it is really all about?