Agile Projects and Portfolios

A year ago my RUP Reference and Certification Guide was released and has been the best-selling book for IBM product certifications since then. Although the “unified process” family has often been seen as heavyweight process documentation based on a phased approach, it has one thing in common with agile processes and frameworks ; iterative-incremental development.

I see the demand in RUP certification as a signal of interest in iterative practices. The RUP may therefore continue to be a stepping stone to agile processes in the future as well.

I will also co-teach a second CSM course offered by Rally Software together with Joe Little. That certification course will take place 11/18 and 11/19 in Falls Church near Washington D.C.  More details and enrollment at the Agile University.

In conjunction with Rally Software and Tamara Sulaiman as the instructor, I will be co-teaching a Scrum Master Certification course.  This open enrollment course in Manhattan will take place 11/4 and 11/5 at 71W 23rd Street, Suite 515, New York, NY 10010.  This will mark my first step towards the Scrum Trainer certification (CST) after I received the certificate for scrum practitioner back in September this year. You will find more info on scrum and its certification process here.

We had Niel Nickolaisen present “Got 5 Minutes to Improve Project Results?” at our APLN NYC meeting. The quick model in which he assesses a project organization, is very much in-line with the risk-reward diagram outlined in my book. Although organizations are often keen on identifying pearl-projects, it is the oyster section which may provide innovative breakthrough (technical or business). These sections translate to Niel’s high mission-critical and market-differentiating segments.

Large organizations with PMO have typically some form of project selection process, even if it is as simple as someone saying “let’s do it”. Although this example is not very sophisticated, it puts a project on the map and unites project resources with a goal and strategy. When I began working with PMO’s and applied agile development practices, the selection process was however exactly like that. The problem is not necessarily that the decision makers didn’t want to do market research, proposal evaluation and consumer analysis in a periodic fashion, the problem was that the development process was differently organized; waterfall-ish. You would have found a requirement document which fed the process and after a certain point of time the team handed over the deliverable. Yes, there were a few gates in between to monitor the development phases (e.g. analysis, design, programming and testing), but none of them embraced significant changes in product vision. They were purely for control and progress purposes (plan vs. actual).

When agile projects are now being squeezed into a waterfall process for portfolio management, many advantages of agile development are simply lost. That’s when I started not only implementing an agile portfolio management process with iterative gates, but also decided to write about this topic. Remember, an agile portfolio is not only a portfolio which contains agile projects but is managed agile as well.  It will have iterative gates, is managed dynamically and depends on a few lean but powerful metrics. The best agile portfolio management approach is when the agile project teams don’t even feel it and flows naturally with what they are doing anyways. Anything which creates overhead or distracts the agile project team from achieving their short-term goals must be prevented.

This year’s Columbus Day reminded me how distributed our world became in only a few hundred years.  We came a long way from an explorer who searched for better routes to trade goods by ship, to assembling IT systems across the globe today. Columbus and many others who followed used ships to exchange merchandise and knowledge. That kind of travel was obviously very slow. Today we are using planes and modern electronic communication which are faster and more offered very frequently. 

In the Asset Portfolio Management chapter, I am discussing the concept of total cost of ownership and used a “green” example to illustrate this idea. Here is another thought. Air traffic is the transportation medium for distributed teams. Even today, travel expenses are often not allocated to individual projects and impact the organization as a whole. If travel costs would be tagged and directly allocated to a project the total cost of ownership (development) would tell a different story. But there are also other costs which are harder to determine and linkable to an individual project. The carbon footprint for example for a project that has one person travel between Bangalore and NYC twelve times a year would be 1800 times higher than the footprint of US average person.  Many distributed organizations exceed that travel schedule easily which increases the footprints even further.  The costs can’t be however not be ignored when total cost of ownership is calculated.

I often use the following traffic situations when I talk about agile processes and portfolios. I thought it would be a good idea to share them here. They may also inspire you to find your own “local” examples.

The first is a typical rush hour traffic jam, caused by a lack of space and number of vehicles.  Surprisingly, the situation looks crowded but there are actually not that many cars and trucks on the road. The problem is created by strict traffic rules, for example lanes, traffic lights, intersections and of course interfering pedestrians.  Not obeying these rules may turn into harsh penalties. But even if the lights switch green, the traffic hardly flows.

.

.

.

In contrast, the other example is a picture of Grand Central Terminal, one of the larger traffic hubs in the city.

No lanes, no traffic lights or control. Actually the opposite is the case, the tracks are assigned just minutes before departure. Grand Central is simply a large hall with an information booth in the center. The train schedules and track information is on boards across the walls and screens. The responsibility of finding the gate and train information is delegated to every individual. Yes, sometimes a few folks bump into each other and not everyone will walk the most optimal path. But minor corrections and reactions based on others movements are necessary to prevent collisions. The system works faster and is extremely reliable even during peak hours.
Agile processes and PMO’s are the information booth and product roadmaps represent the train and track information. Self-organized agile teams will define what is needed to get to their goal and make the necessary adjustments.

A reminder that business visions and strategies constantly change. Mergers, spin-off’s and take-overs will re-shuffle the exsiting portfolios. Workers replace Lehman Brothers sign with Barclays at Times Square.

I am big fan of metrics, because they turn “data” into “information”.  But many metrics have a timely context which means information today may not be relevant tomorrow.  A second issue is, that metrics can be filtered and massaged to the needs of the audience. For example, recently I saw a town/community advertise their “we are green” campaign by releasing their recycling quota. That quota was measured in tons of returned material. You may think, that the higher the quota, the better and greener the town.  Actually wrong! People who prevent garbage in the first place by not purchasing products won’t need to recycle at all. The same is true for lines of code measurements. My approach is simple; I’d rather use no metrics than using the wrong one.

Recently, I came across the Nokia Test.The test is based on a few very basic assessment questions. For example “Are your iterations between 2-4(6) weeks long?”  Depending on the answers, project teams are categorized as “excellent scrum”, “good scrum”, “pretty good scrum” and “scrum but(t)’s”. The latter are the projects which believe they are doing scrum, but do in reality only pieces of it.

Interesting about this test is that it reflects on the purity of the Scrum process rather than the progress and success of each individual project. In other words, if you follow Scrum out of the textbook, your score will be higher. Isn’t Scrum empirical, which allows me adapt?  In that context, I couldn’t find the question “Are you performing retrospectives at the end of each iteration?” or “Does your project team adapt the process to their project environment/situation?” The test is more or less a checklist.

Then someone took the Nokia test to the next level and linked the assessment score to the annual revenue of organizations practicing Scrum. The result is stunning, the higher the score, the higher the annual revenue. A finding like this seemed too good to be true, so it kept my interest.

The first and most obvious issue I noticed was the relationship between the metrics. The agile assessment performed on a project level versus the annual revenue which is based on the entire organization.  Because Scrum is empirical, a Scrum-Butt here and there seems almost natural for a few projects in a very large organization. It seems also impossible to assess a large organization whose development efforts are spread across the globe. Comparing these two metrics seems highly impractical.

Another problem I could see is the timely context. A full year of agile development combined with a timely assessment of the entire project organization. That would require that someone assesses every project at the end of each iteration. And the entire organization would need to transition at the very same time. Wow, that is an amazing investment into something executives already believed in when they started with Scrum.

Linking the Nokia test to the annual revenue seems also somehow articial. Some of the companies listed in the test-result, have increased their annual revenue significantly up to 300%. But how can a company of 10,000 employees or larger truthfully say that Scrum is the reason of all that?  In fact, I know that some of the companies listed in the report may use Scrum, but they are dominantly applying XP practices. So, how would I know that the results are linked to Scrum and not to XP? Perhaps they are linked to something totally different? For example, being  innovative , creative or simply lucky by releasing the right product at the right time to the marketplace? 

Some of “very good Scrum” organizations, which enjoy seeing their revenues going through the roofs, disguised their names. That is in particular disappointing because it does not allow us verifying the findings with public company financial records.

I think I have a feeling what the creators were trying to do with this metric, but unfortunately I believe it is not that easy. I think we may have found a pattern in the industry that successful organizations are embracing agile development and project management practices. But linking Scrum to the annual revenue seems out of league. By the way, not every company measures success with agile adoption with their balance sheets. If so, looking at the current development at the financial markets, 2008 would not be a good year for agile.

When you live in Europe, getting your shoes hand-tailored in Italy is not a crazy thought. A friend of mine for example found such a shoemaker in Italy, who is extremely passionate about his work and profession. For the first pair of shoes the shoemaker requires each customer to show up in person. Feet are measured individually and the walking style is analyzed. This step does not only allow the shoemaker to produce a highly customized pair of shoes but leaves behind a template which can be used in the future.  He also meets the person and creates a customer relationship.

The production of the shoes is then performed start to finish by the very same person. The result is a very high-end product. Shoemaking is real craftsmanship, which requires not only technical skills to measure, cut, stitch, but also knowledge around the material itself, for example the chosen leather.

When you observe the shoemaking process of the craftsman and compare it with mass-produced, cost-reduced pairs, you will notice some subtle but important differences. For example, a craftsman does not separate the technical steps into clearly divided phases. Although the stitching has to follow the cutting, the steps are briefly interrupted to adjust the current work. Considering that no two feet are identical that seems to be a logical necessity. The same is true for the stitches which are set depending on how the shoe will roll. A constant re-evaluation of the work-in-progress is therefore a critical element in the overall production process. This integrative work is directly linked to the quality and customer satisfaction of the final product. By applying continuous integration, we are favoring something very similar in agile development.

The end-result comes of course with a higher price-tag, because a good pair of shoes takes more time, good talent and better ingredients than a crappy one. It is simple like that. The price can be justified if you look at the durability of the product.  It will outlive the majority of mass-produced shoes, even if worn on a daily basis.

What we have done to software engineering in the late 1990s and early 2000s translates to the following example with our shoemaker. To achieve a 10% reduction in price, we would offer the shoemakers to ship the cut materials into a low-cost country and have all the stitching performed there. Upon completion the shoes return for the final steps back to Italy.  Our shoemaker would probably argue that this is a totally crazy idea. As a matter of fact, in the case of our passionate Italian craftsman, you would probably be asked to leave the store. Why? It is not that the folks in low-cost countries can’t stitch, cut or sew. But it is because the shoemaker is aware of the importance of the integrative work. Delegating one entire production step would sacrifice the small, but essential adjustments while the product is being shaped.  But more important, the shoemaker who has a personal relationship with the customer from the initial foot measuring has distanced the work and made the production faceless. He would therefore delegate an important piece of his business model; quality! Who guarantees him that the other side of the production process is as passionate about shoemaking as he is? Remember the other side of the production process will never see the smile of the customer.

Although many executives have understood the problem we created in the past in offshore-software-development, we have not resolved the root cause of the problem yet. While it was “popular” in the early 2000s to delegate QA to an offshore partner, we realized later that the programming and testing go hand-in-hand. Combining programming and testing will then expose the interface to analysis & design. If we would integrate A&D, we would then create a distance to requirements, which has interfaces to product management, vision and executive management.  It is obvious that the integration of activities is so crucial that the entire “project” must be distributed and not engineering activities. That model will carry the passion for the product, motivate innovation but also create a great product.

Based on this model, distributing agile teams literally means the entire team! In a scrum project, it would mean the team, scrum master, product owner but also executives who will infuse the team with their vision. It also requires distributed professionals, team members who have a passion for their work. But keep in mind, in many off-shore-countries, attrition of 20% or higher is very typical which does not foster passion and great work-ethic. Without a doubt, distributing agile teams introduces challenges. And it does not matter if you distribute your team one floor apart from each other or if you move to a different continent. But the length of distance introduces additional cultural issues, time-difference and language barriers. 

At the end, picture the Italian shoemaker starting from scratch because he would be embarrassed sending the final product to his clients.