Posts Tagged ‘Scrum’

Buying and Selling Agile Projects

1 Comment »

When talking about agile projects many books seems to be written under the assumption that you work with the whole life cycle, from its initial conception to maintenance and support of the system. But quite often, parts of the project are done by another supplier. This other supplier may have a different underlying motivation and his business may not be the same. The most common price unit in knowledge-based work is probably price per hour, direct or indirect. The buyer’s income model is probably different; it may be based on cost savings, or on either revenue from or new opportunities emerging from the product (or transaction), or interval based, such as price per month. Therefore, a built-in conflict may exist between the revenue model for the buyer and that of the supplier.

 

Who should take the commercial risk?

The buyer can handle the project on their own and just hire or contract some consultants that will work on a per-hour basis, in which case the full risk remains with the buyer.  Or the buyer can outsource a part of the project to a supplier, who also takes an agreed-upon portion of the risk as part of the deal.

 

This is often handled with a requirement phase that produces a requirement document that one or more suppliers use to develop a bid for winning the contract from the buyer. The contracts often include the total cost, some options (often add-ons) and a time when the delivery shall be done.

 

The problem with this is that it doesn’t facilitate changes and the flexibility to apply knowledge that you gain during the project very easily. When the project starts, keeping to the original plan becomes more important for both parties instead of maximizing the business value. This prevents either party from incurring cost or schedule overruns that could turn their side of the contract into a losing proposition.

This inflexibility negates the benefits of agile development projects, which are adaptive so as to maximize business value. But there are alternatives to fixed-scope/fix-price types of contracts. I will talk about different kinds of contracts soon but first I would like to explain maximal value focused.

Read the rest of this entry »


Organizing Software Development

Comments Off on Organizing Software Development

Organizing work is a combination of doing the right thing, in the right way in an optimal way. This is hard and what makes it even harder is that the right thing and the right way are constantly changing. Over the years I work with software development; first the traditional project management schools with their view that if you only know what you did, success would come from making good plans and them focusing on executing that plan as effective as possible. Then the agile and lean view became the dominated methodologies that was convinced that if people was just empower, self-organized, became more business oriented and changed to adaptive planning great things would happen.

 

What was the Problem with the Traditional Project Management School?
The traditional view of project management was focusing on administrating passive resources that needed to be managed are not a view that was optimal for knowledge based work. The problem with the traditional view of organizing software development was foremost the underlying view that we were doing something repeatable, if we only was experienced enough we would be as effective as any manufacturing industry. A factory has a deterministic process, where you can expect a certain outcome based on the input, this works when the variation within the process is quite small. But the problem with our craft is that we develop products based on knowledge and collaboration, and then the variations within that process comparing to factories or building buildings are much higher. Software development is therefore a non-deterministic process that actually has more to do with developing new products than building houses or producing something in a factory.

 

The Agile Problem!
The biggest trend in organization of software development the last years are probably transcend to more agile methodologies. My view of the agile manifest is that many people foremost reacted against bad leadership and management style that wasn’t adapted to the knowledge based work people performed. The underlying idea of just empower everyone and give them give them the right to self-organize, isn’t optimal in all situations. I believe that when people realized that the plan-driven view wasn’t working they all started to look on those who shouted most and earliest, (and with all respect to the old gentlemen’s that wrote the agile manifest) they were a little to overrepresented by the anarchists. Don’t miss understand me, I’m a pro agile methodology. I just felt that leadership somewhere was lost in the focus on new process and tools. The problem with scrum trainers is that they value the scrum process and tools over individuals and interactions.

 

The Future
The traditional view of project management and the agile view both have its pros and cons. In the future both worlds will need to connect better in order to get the best from both. I believe that software developments sometimes are a deterministic process where you only install an out of box system and just tweak some things, and sometime it’s more of an exploratory journey into the world complexity.

 

P.S.

I know all Scrum trainers are in London this week, on the Scrum Gathering 2011. Goto Jurgen Appelos sessions he seams to be the only one besides D Snowden that understand the basis of our work, complexity. I’m in London this week as well but unfortunately without attending the Scrum Gathering.

D.S.


What is the difference between Scrum Master and Scrum Product Owner?

Comments Off on What is the difference between Scrum Master and Scrum Product Owner?

In Scrum, there are basically three roles of Product Owner, Scrum Master and Team Member. The purpose of the Product Owner role is to connect product line with product development. A Product Owner in Scrum, you control the project or development work yourself instead of relying on a project, and that means you have a coach (Scrum Master) to help the team to work efficiently and supports collaboration within and outside the team. Compare it with the OGC model with Steering Committee – Project Manager – Team Leader is to be in the scrum map it to Management – Product Owner – Scrum Master.


Burndown Chart Makes Projects a Sport!

Comments Off on Burndown Chart Makes Projects a Sport!

BowlingWhat makes sports so engaging is that when someone understands the rules they immediately knows how good a specific throw was.  How fun would bowling be if you didn’t have direct feedback on how many pins you have hit? If you instead got a progress report from your project manager once a month, with the conclusions of last month’s game.

But this is quite common in today’s knowledge based work people don’t know if today’s work effort was a complete failure or a success. Three month from know they might get a “bug report” that indicated that something this week wasn’t optimal. How easy is it to get better and realize what lead to success if there is no natural feedback on your work. Feedback is essential for engagement.

This makes the “monitor board”/”agile dashboard” with burndown chart to a great tool. Everyone can see what no one start working with, what someone is working on and how things are going relative to the plan. People tend to understand how things are going and get more engage that people who get reports or review of work they did three month ago.

Agile Dashboard

Used with permission from Henrik Kniberg‘s source “Scrum and XP from the Trenches”.

Through detailed planning in the short term and follow up on a daily basis in a visual way everyone understand how the co-operative game goes. You know when you are in trouble and you know when you’ve made a strike. This creates job satisfaction and commitment.


Everyone are happy when they know they made a strike. You know it’s the best you can do you feel satisfied. It’s the same in work life people feel good about themself if they know they done a good result. As a project manager this is a great tool, because this creates transparency, people know when they need to start focusing on delivery without you being there looking over their shoulder. I use to end my presentations about Scrum with showing the following video, in order to show how powerful visualization and messurement is.


If You Adapt to Change! How Do You Handle the Price?

4 Comments »

A couple of days ago I wrote a blog-post “Plan-driven versus Agile = Predictive versus Adaptive”, the first comment I got on the post was a question from Hila Annis about how are these changes are priced. A great question and here is an explanation.

Hila Annis question:

I like your entry but I have a question – how are these changes in what the customer wants priced? I mean, in the end, we’re talking about a business, and if customer signed off on B but wants C, how do you price these changes along the way?

My Answer:

The answer is hopefully nothing! Let me explain a couple of principles and then I will get explain why it shouldn’t cost the customer anything.

Explanation:

First of all agile is not about selling or delivering the (B) + (Something) it’s actually to deliver (B) + (Something) – (Something else). In order to explain how the process works I will explain

  • Statistics about features never used
  • The project Iron-triangle is turned upside-down
  • Time boxing
  • Product backlog

Features Never UsedStandish report on features never used

In a 2002 report from The Standish Group, an investigation was made into failed projects to see how much the built-in features were used. They found that 20% of the features were used either always or often. The interesting part was that 45% of the features were never used. There could be many explanations for why features are never used in a system or product. But if you ask stakeholders to give you all the requirements up front, you end up with a lot of things that will never be used. If you deliver work in small pieces and work first on the first priority and also allow stakeholders to re-prioritize work, this problem can be addressed.

The Project Triangle Turned Upside Down

The traditional plan-driven projects are based on the traditional “iron triangle” of Time, Cost and Quality. All requirements have to be accounted for in the requirement phase and then the project is planned around the expected features to be delivered.  The features are the first ones to be fixed, afterwards an estimation of time and costs in delivering those features is drawn up.

triangleupsidedown

The Agile mindset, on the other hand, is to fix time and cost to manage a variable scope. This leads to the ability to hit deadlines both in the short and long perspective. This way it’s easier to focus on features that build value and to avoid building features that never will be used.

Remember Pareto’s principle – the old 80-20 rule. Vilfredo Pareto, an Italian economist, observed in 1906 that 80% of the land in Italy was owned by 20% of the population; he also observed that 20% of the pea pods in his garden contained 80% of the peas.  This is how he came to formulate this principle. In business, people say that “80% of your sales come from 20% of your clients”.  So wouldn’t it be great if you could avoid building features that will never be used?

Time boxing

Time boxing means that you budget the project based on time and not scope. You plan to have a specific crew in a specific time. You work for example for 4 iterations that last 3 weeks with a 4 person crew, it becomes what it becomes during that time. That way you can plan a budget.

Conclusion so far:

If you do big upfront design and requirement you will not capture all requirements and not understand what’s creates 80% of the value for the customer. Let’s look on some tools that help you handle this and how this might work in Scrum.

The Scrum Process

When planning the project you start with some requirements either as a user story, scenario or as a use case. Then you make a rough estimate of what it will cost to deliver that requirement. Then you order them all in a product backlog. All requirement have a unique priority, two requirement can never be prioritized the same, someone is always more important. Then you look on all requirements and their estimate and summarize the cost and then you got a rough budget of what it will cost to implement all requirements. When you start the first iteration (called sprint in Scrum) you look on how many persons you have for example 4 persons working on this project for 40 hours a week and the iteration will last 3 weeks. This means that you take out the top requirement until you reach  360 (4 x 40 x 3) hours of planed work. This requirements cannot be changed from now, but all other requirements in the backlog can be change and re-prioritized or you can remove or add new requirements. At the end of each sprint everything that has implemented is demonstrated or even better delivered for use. When you demonstrate and users use the software new requirements will evolve, they might say “When I see this you will need to do this also, otherwise this has no value!” Now the backlog grows and the value of all implemented requirements and all new are higher then what you budget the project from start. But at the same time the things that goes down in the backlog is the requirement that wasn’t prioritized.

The Product Backlog

Conclusion

The trick is not to sell a project that have a “fixed” scope but a project that have fixed budget, time and quality. The thing that is variable is the scope. This way the customer will not get all requirements that they thought when the project was planned but because the customer can re-prioritize whenever he like he will be able to adapt to new knowledge and therefore get the things he appreciate most at the end and within a fixed budget. If the customers would like to implement the requirements that fell out of the budget you can directly give him a price of what it will take to implement them. But often they will have change their mind and realized that those requirements will not produce any business value.  This way it also gets easy to argue for further development that is outside the original budget. If we added requirements that where estimated to 40 hours and they where prioritized higher than something estimated 40 from start, it’s not strange that the first requirement is not done within the budget. If you get 40 hours on something you have to remove something else worth 40 hours. The requirements that will not fit inside the budget will not be implemented or you have a good foundation for a new “offer”. This way the business value of (C) gets greater than the value of (B). Changing your mind when you have acquired new knowledge is just a benefit, a late change in requirement are a competitive advantage.

So hope this answers your questions Hila Annis!