Posts filed under ‘Agile’

Agile Change Projects – a great fit!

Yesterday (Feb 12, 2010), I attended a presentation coordinated by the PMI Chapter Frankfurt, local group Hamburg. The topic was ‘Why change projects do not work’. The guest speaker Malte Foegen (wibas GmbH) delivered a very lively, entertaining and inspiring presentation. He presented an iterative approach on how to achieve change in small but effective steps, illustrated by an example of a big German company. (I’ll see if I can point to the slides later on).

I had a big aha moment when I realized that they were actually applying an AGILE approach in this corporate change initiative!

You might have read some of my earlier blog postings about managing change, and the inherent issues. I have quite a lot of experience with change programs and ‘classic’ change methodologies, and I have learned a lot about agile approaches recently, but hadn’t made the connection so far. Listening to Mr Foegen, it really hit me that this is a very good fit. Obviously, they successfully used it in practice.

Of course there is one big difference to a ‘regular’ Scrum project: In Scrum, you have a team of usually up to 9 people who execute the work themselves. In the context of this corporate change initiative, a lot of agile elements were being used (short sprints and the respective planning and retrospectives, ‘Product’ (Change) Backlog, Vision, etc.). Care was taken for a high level of involvement of the ‘field’, e.g. by identifying ‘best of the breed’ practices already existing in the field instead of making up new bureaucratic processes. The biggest difference: The people actually needed to DO the change (for example, adopting new monitoring techniques) were scattered across the organization, indeed THE ORGANIZATION had to implement the defined changes. So the change program was organized in an agile manner, involving top management.

Doing small but effective, regular steps every month achieved a significant and sustainable change in the end. A good example Mr Foegen used throughout the presentation, would be the introduction of Planning Poker as part of a larger change initiative targeted at improving estimating and forecasting quality. As one iteration in your change project, you could roll out Planning Poker to respective parts of the organization in one month. You’d have implemented a small increment of your change, and with the positive energy created you’d build up momentum for the coming parts.

All in all, really interesting. And b.t.w. – this is also a good example for a non-software development project using Scrum (see earlier discussions in this blog).

If you’re interested, have a look at the ‘Map of change’ (links below). Sometimes you’re not sure if you should laugh or cry, maybe there’s just too much truth in it. I found myself giggling a few times. My personal highlight was ‘the big bang ferries’ that leave the ivory tower regularly but usually sink in the shallows of quick wins. A few actually reach the land but leave burnt ground :-D

Happy weekend!

February 13, 2010 at 14:53 Leave a comment

Net Present Value explained in simple words

In one of my last posts (Agile-Giving the business options back) I promised a follow-up regarding Net Present Value (NPV). Here you go! This will be VERY basic, so if you’re familiar with the concept you might be seriously bored.

NPV is a financial appraisal method that can be universally applied, and is an extraordinary fit with agile product development. I’ll try to explain it in simple everyday language, even if this might be at the cost of some academic rigor. As a start, let’s break it into two parts: NET and PRESENT VALUE.

Lets’ start with Present Value: Assume you are presented with the following choices:

  1. Someone offers you to give you 100 EUR today.
  2. Someone offers you to give you 100 EUR one year from today.

How do you choose? Of course you’d pick option 1. If you get 100 EUR today, you can invest it, and in a year from now you might have 102 EUR if your investment has a modest return of 2%. In addition, inflation will eat off a few pieces of your 100 EUR bill –  so in a year from now, the same bill might buy you only 97 EUR worth of goods. Generally, there is a preference to get money rather sooner than later, so you’d need some form of compensation to get the money later.

–> Present Value is today’s value of an amount of money in the future.

Now, let’s make it a bit harder. How about this choice:

  1. Someone offers you to give you 100 EUR today.
  2. Someone offers you to give you 105 EUR one year from today.

You get options like this often in every day life, for example fitness companies offering a discount if you pay your membership fees for two years in advance.

So, which option would you choose? Basically, you are offered a 5% mark-up that needs to reimburse you for the loss of investment (i.e. you can’t invest the 100 EUR in other projects that might give you a nice return), the risk involved (will this person have the liquidity to pay you the 105 EUR in a year from now), and the expected rate of inflation.

For you as a private person, let’s assume you could put the money in the bank and would receive 3% interest. Inflation is currently rather low, let’s expect 1.5%. The person is rich and trustworthy, so no worries about liquidity. With your 3% investment, you’d have 103 EUR in a year. Given 1.5% inflation, the 103 EUR would be worth only 101.46 EUR. So if you’d take the 100 EUR today, you’d have 101.46 EUR in a year. Option 2 would be favorable, as you would get 105 EUR! All these percentages you’re dealing with are combined into the ‘discount factor’.

Of course, there is a lot more to it mathematically, see Wikipedia.org on Present Value.

The simple version: Present Value = Future Value / (1 + discount factor) ^ years

Phew, so where does the NET come in?

Net Present Value is used to calculate the total of all cash flows (in and out) that can be directly linked to your project. If it is positive, good. Otherwise, you might reconsider the investment.

Here is how it works: First, you need to list all the cash inflows and outflows of your projects, sort by year.

Example: The initial cost of your project is 20,000 EUR in year 0, and additional 10,000 EUR in the years 1, 2 and 3. You assume that you will be able to generate cash inflows (for instance through subscriptions) from this project in the years 1-3 of 10,000 EUR each.

year 0: out: -20,000 EUR (initial project investment)
year 1: out: -10,000 EUR (project support)
year 1: in:  +20,000 EUR (income generated from investment)
year 1: net: +10,000 EUR
years 2-3: see year 1

Assuming a discounting factor of 10% (0.10):
year 0: PV = -20.000 EUR / (1+0.1)^0 = -20,000 EUR
year 1: PV =  10.000 EUR / (1+0.1)^1 =   9,091 EUR
year 2: PV =  10.000 EUR / (1+0.1)^2 =   8,264 EUR
year 3: PV =  10.000 EUR / (1+0.1)^3 =   7,513 EUR

The resulting Net Present Value is the sum of the present values above:

NPV = -20.000 EUR
      + 9,091 EUR
      + 8,264 EUR
      + 7,513 EUR
-----------------
NPV =   4,868 EUR
=================

The NPV here is positive and therefore favorable. There are other non-financial and financial investment appraisal techniques available (such as Payback and IRR), but this is a good positive indicator.

Discussion: One thing you see: The later the income generated, the less it is worth (and of course, uncertainty increases the further you look into the future). If you wouldn’t have taken the time value of money into account (i.e. you would have used the un-discounted cash amounts instead of the Present Values), you would have gotten a project return of 10,000 EUR, which looks far more favorable than the ‘correct’ NPV. Please note that this model also has limitations and should not be used as the only appraisal technique.

And now we’re finally turning the corner back to agile – yeah! Imagine you’re running this project using Scrum, and after 6 months you’re already able to get a few subscriptions of your service sold, because you could release the product earlier (maybe with core functionality only, but customers still find it valuable). You could then have an early cash inflow in year 0 already of say 3,000 EUR which boosts your NPV up by exactly this amount from 4,868 EUR to 7,868 EUR.

Agile helps you to achieve cash inflows early. Because of the time value of money, these early cash inflows are a significant help for a financially healthy investment. (Plus, softer factors like reduced risk through early exposition, being earlier at the market, etc.)

Well, you can now put your calculator away again, or read further about this topic (for instance at Wikipedia). Good to know: Excel, Openoffice.org Calc & Co. have built-in NPV and IRR functions.

Although I left out a lot of details, I hope this was still useful. Let me know either way!

February 4, 2010 at 13:07 1 comment

Agile – giving the business options back

When they hear ‘agile software development’, a lot of people think that this is somewhat of a geeky thing. While there might be admittedly also a lot more fun and fulfillment in agile projects for software developers, there are BIG benefits for the business as well. In this blog post, I’ll have a look at agile projects from the business’ / sponsor’ point of view.

I believe the key to many advantages for the business is the following: The solution is being implemented in executable increments – you get a slice more of your solution with every sprint. You can review and give feedback all the way through. This implies a lot more transparency – rather than pouring money into a black box and waiting for months until you get a glimpse of the final result, you get it from early on, piece by piece. Plus, the most critical, highest priority requirements are implemented first.

Sounds nice? It gets better when you think it through: It gives you options back!

A few examples: You could go to market earlier, when you think you have generated enough value to offer to your customers. Or, you could stop the project, if you discover risks EARLY in the project that would make it too expensive / late / whatever.

It also facilitates informed cross-project prioritization and trade-offs: Imagine you’re a few months into a project, and another high-priority project comes up. In a waterfall environment, you might just be mid way through the implementation phase – a lot of design and implementation efforts have been invested, but no result is there yet. It may be prudent but very painful to stop the project at this point.
Now imagine you had run the project using Scrum or another agile framework: At this point, you would probably have some of the highest priority requirements implemented already. So even if you decided to stop the project (i.e., not implement remaining, lower-priority user stories), you would still have generated business value!

And b.t.w. – Net Present Value (NPV), a common method for financial project/investment appraisal is a great fit with agile approaches! But that’s the topic for my next blog post…

January 11, 2010 at 11:23 5 comments

Reading Tip: Lean and Portfolio Management

Just a brief reading tip today: ‘Lean and Portfolio Management: A Winning Combination in Trying Times’. (Currently, you can download it for free at the link given. Probably for a few days only!)

Here’s the abstract: Struggling with the age-old challenge of too much demand and not enough time and resources to do it all? We all know what the solution is: focus on those things that yield the greatest value for your organization. Fortunately, two major methodologies — portfolio management and lean — have emerged over the past decade that can help you find and maintain that focus. But what if you could take these two proven approaches and bring them together? Would it work? This is the challenge that the author of this Executive Report sets out to investigate.

I really liked the report – a nice read, triggering a lot of thoughts. I’ll probably touch on it again in later posts.

This is one of several really interesting papers on Agile Project Management and Portfolio Management offered on the website of the Cutter Consortium. Most materials are for fee. I recently found another pretty good one. Here is the Summary of ‘The Lean-Agile PMO: Using Lean Thinking to Accelerate Agile Project Delivery’. I am not sure if the full report is still available for free.

Happy reading.

PS – I have no connection whatsoever to the Cutter Consortium ;)

December 30, 2009 at 15:35 Leave a comment

The agile PMO – an oxymoron?

With Scrum and other agile project management frameworks spreading more and more across the industry, there is also a certain maturing process happening: If you have a few scrum projects ‘to test the waters’ in your company, not a big deal. Once you fully commit to agilizing ;) your project portfolio, you’ll come across issues like:

‘Is there still a need for a Project Management Office (PMO)? And if so, how on earth can this fit with the self-organization and minimum-interference approach of Scrum?’

I thought a lot about this in the past weeks, gathered all my thoughts in a little mindmap, and am sharing the key thoughts with you today.

For a little fun at the start, have a look at The Biggest Little List of Oxymorons Online! Agile PMO is not in there yet, and maybe there’s no need to submit it. I believe that there is still value in having a PMO, even in times of Scrum&Co.

I’ll touch briefly on both sides of the Portfolio Management as suggested in the Portfolio Management Guidance by Craig Kilford:

  • Project Portfolio Definition – investing in the RIGHT projects
  • Project Portfolio Delivery – making sure projects are done the RIGHT WAY

Regardless of the project management approach applied, you as the owning organization still want to ensure you’re investing your resources into the RIGHT projects, i.e. the need to apply Project Portfolio Definition techniques (strategic alignment, categorization, prioritization, based on business value, financially and non-financially). I’d see no big difference here compared to the ‘classic’ approach, the same rigor should be applied when it comes to project appraisal and authorization, based on a compelling business case. Keep in mind, there is nothing in Scrum that prevents you from developing software that is not needed (if only the Product Owner thinks so).

Once your authorized projects are up and running, you’re entering the Portfolio Delivery cycle, and you’ll want to be up-to-date about the status of upcoming major milestones / releases, key impediments and risks that cannot be resolved/mitigated within the individual teams, etc.

For impediments and risks – all that lies within the team boundaries and can be resolved there should stay there. Impediments and risks that span across teams could and should be escalated to from the Scrum teams, so that the PMO can get organization-wide issues out of the way. In addition on the risk side, risks should also proactively be identified and managed across projects, as a function of the PMO.

When it comes to reporting, you’ll need to start looking at the iron triangle between time, cost, and functionality. Typically, time and cost will be fixed, with functionality somewhat flexed, as the GOAL is fixed but not the exact detailed features to get there. This will provide you a first clue where to start. A few ideas for information to gather at the end of sprints below:

  • Overall RAG status for upcoming releases
  • End-of-sprint report
  • Release Burndown Bar
  • Impediment chart, particularly any impediments that could not be resolved within the team
  • Identified risks that impact other projects, too

And this is where I’d probably stop. Minimize the overhead as much as you can, keep it simple and reuse artifacts created by the team anyway as much as possible. And remember, WITHIN Sprints, this is all a black box to everyone outside the team! No interference except the team specifically asks you for it. If you’re too curious, you can ask the team to observe (silently!!) their Daily Scrums, but that’s it.

I’d be careful when it comes to comparing velocity across teams. You’ll have to be cautious not to compare apple with pears, and furthermore you could introduce a sense of competition that might be counter-productive. This leads us to standards:

As one of the underlying philosophies of Scrum is a team that organizes itself the way it works best for this respective team, one should generally be very careful when it comes to standardizing.
However, once you have a certain number of projects running, a certain level of standardization will help you to ease the overarching functions. A few examples:

  • Use a standard environment for team collab spaces / wiki sites, e.g. provide a standard server, but allow the team to structure and fill their space as it fits best.
  • You COULD standardize story points, i.e. define a typical “5” story points user story, that everyone can relate to. Use with caution as this smooths the way to compare velocity across teams (see my comment above).
  • If you’re thinking about standardizing things like reporting or minimum requirements for tasks boards, starting with a ‘best of the breed’ approach would be wise. As a rule of thumb when it comes to standards: Always bottom-up, never top-down.

The last area where a PMO can add a lot of value is in a facilitator role to encourage the sharing of knowledge and experiences across teams. The PMO could for instance suggest rotations across teams, informal meetings between ScrumMasters, and so on.

To get an indication how the change process (i.e. Scrum adoption level) is going, the PMO could sit together with ScrumMasters from time to time (I’d say no more often than once or twice a year) and go through one of these Scrum Checklists that are available online. This will give you clues which areas are working really well already, and where further improvements could be made.

That’s it for now. I’d love to hear your thoughts and experiences. And a little health warning: This is just a collection of thoughts and not a scientific paper ;)

December 18, 2009 at 11:31 3 comments

ScrumMaster Training

After reading a lot about agile and Scrum, I attended a two-day ‘Certified ScrumMaster’ training class in Hannover last week. On the ROTaMI (Return of Time and Money Invested) scale, this course scored pretty high.

It was really helpful to reflect the core concepts and discuss them with other project managers, developers, software architects and of course the trainer. Key take-away: Most of the Scrum ‘standards’ are rather straightforward. The key are not sophisticated artifacts/tools/process flows but being able to interact with the team, nurture and support it and get together into the Flow. The changed underlying philosophy (empowering the team, encouraging exploration and changes) for the projects means significant changes for the role a PMO should play, and importantly, how.

B.t.w. now I am 100% sure that there is really no need for a PM in a Scrum project ;) I’m really looking forward to applying all of this in real-life projects!

December 14, 2009 at 14:36 Leave a comment

Scrum … and what happens to the Project Manager

In preparation for the course next week, I started to read the recommended book “Scrum – Agiles Projektmanagement erfolgreich einsetzen”.

So far, I can only recommend it (well, it helps if you understand German ;). It is really down-to-earth, with a lot of practical advice. It is useful as a starter, and it also contains advanced topics like applying Scrum for larger projects, distributed teams, and so on.

I had a few aha moments already. So far, I assumed the ScrumMaster role is the one closest to the ‘traditional’ PM role. However, it seems the Product Owner (mostly together with the team) owns a lot of the traditional PM territory: Scope, Time, Cost, Risk Management, etc. At the same time, the Product Owner needs a deep understanding of the product being developed and the used technology. The ScrumMaster is really more of a facilitator and ‘guardian’ of the Scrum process and mindset.

And to revise the ‘where’s the PM’ discussion, I tend to agree with the author: Based on these roles, there is no need for a Project Manager any more. Classic Project Management functions are distributed across the defined Scrum roles, and most importantly: The team collectively carries a lot of responsibility.

Still, no need to panic for all the PMs out there: First of all, a lot of the soft skills and experiences gained so far will be very valuable in any project, Scrum or not. Secondly, good news for all PMs who like a challenge and love to learn new stuff from time to time. And thirdly: There’ll probably still be a lot of un-Scrumish projects out there!

And a little outlook into the next posts. What has been bugging me for a while is the following: Assume Scrum is a good fit for many of your projects, and your organization was successful in making the shift towards agile project management. How does this affect / change the role of your Project Management Office (PMO)? Plus, I owe you the second part of ‘The Myth of Managing Change’.

Happy weekend!

December 4, 2009 at 22:31 Leave a comment

I caught the Agile virus

I’ve been reading stuff and discussing the agile developments for a while. After years of working in virtual teams, spread across the globe, under a very strict regime, this agile mindset somehow appeals to me ;) And even if you don’t follow e.g. the Scrum rules to the letter, there are elements that surely could be applied to a lot of projects (not only in the software space) to make them more successful.

So… I’ll attend a Scrum Master certification class next week. Really looking forward to it. I’ll let you know how it went.

December 1, 2009 at 15:43 Leave a comment

Scrum for Beginners Video

A little Monday Morning surfing tip…

If you’ve wondered for a while what all this Agile/Scrum thing is about, there’s a great little tutorial ‘Scrum in under 10 minutes’ on YouTube. I really liked it – it’s presented in a great way and with some humor (like Scrum Master is just a more fancy word for a Project Manager ;). Enjoy!

There’s some more info in Hamid’s Blog, and of course tons of books and other online materials.

B.t.w. the more I read and hear about Agile, the more I believe this is really no rocket science, rather a different mindset and should be fun to apply. Any experiences folks?

November 23, 2009 at 10:10 2 comments


June 2021
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
282930  

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 5 other followers