Archive

Posts Tagged ‘scrum’

New project, new examples

As of a couple of days ago, I’m splitting my time between two projects. As it happens it’s also on two different locations here in Stockholm so I’m happy that we have a warm autumn here in Stockholm so I can ride my bike between the projects, but what is really fun is that we’re using Specification By Example in both projects.

One major difference between my work will though be that I’m a core team member in my “old” project, while I will be an outsider/stakeholder in the new project. I’m supporting our product owner and writing examples but not be an active team member. This will very interesting to experience in combination with Specification By Examples – does example writing business people have to be part of the team?

This means that I’m that fortunate that while learning this I get lessons in two rather different projects and from two rather different styles of implementation of the examples.

Today, I had the first specification session with the new project and we started of discussing what we want to catch in the examples in the project. We then started writing examples, both some that are included in the scope of the original user stories but also the framework for examples to be implemented in later stories. Tomorrow we will test the examples on the team. This will be really interesting to see and hear.

Another difference between the projects is that we will be using a more conservative form of scrum in this project which is also very interesting when comparing with the other project where we have used something more of an almost post agile process with few fixed artifacts and more a continious adaptation of our process in order to improve productivity.

Using our kanban board for continuous improvement

Why do you use a kanban board? Why do you use a scrum dashboard? Really? Think about that. And then think again?

Do you track your workload? Do you calculate if you’re going to complete the sprint objectives? Do you use it to divide the work or fetch your tasks?

And why do you manage projects? Is to have something to do? To be able to track progress? Or divide work or just to feel that you’re in control of what is happening?

What ever is your reason if it’s one of the above, I state that this will not help you in the long run. Because this objectives will not improve your work.

This summer I read The Goal and learnt about The Theory Of Constraints. As always, I recommend you reading the complete book, but here is your five minute version.

All processes have constraints. You cannot remove all the constraints in the process, because if one step stops being a constraint, a new step becomes the new constraint.

image

A process with step 2 as the constraint

image

If step 2 becomes more effective, the risk is that the constraint is moved to the next step. So, you cannot just map your process, “remove the constraints” and be happy about your highly effective process. You need to work this continuously.

So, the objective is to constantly improve your process so that the effect of the current constraint is minimized and so that new constraints are identified. But how is that done.

Well, first you identify your current process. All the steps are mapped and then you see where there is some queuing going on. And here comes your Kanban board. Or your scrum board. Or what ever tool you’re using.

Here you follow the value stream of the process and by having a visual tool, you can identify your current constraint.

For example, let’s say that you’re going waterfall. What happens (probably) is that a queue forms at the testing steps. When people finally get to test stuff, a queue of bugs will start to form. And it can form quickly. The step to take then is to try to even the identifying of bugs. Hence you get continuous testing during the process. But then something else starts queuing. And you then use the board to identify that and to improve those steps.

A mistake, according to The Goal, is that we spend too much time optimizing the steps that are not a constraint. But by doing so you just add to the queue. So, if you have a problem with testing not being done, making the software coding faster is not increasing the productivity of the whole process.

I’m really excited to be working with this in TUI Nordic. We’re an organization who is working with lean values and empathic leadership, so this will fit nicely into the culture of the organization. Will it be easy? Hell, no. But a real challenge, yes.

Why Estimate is a bad word

What is an estimate?

According to Dictionary.com the verb means:

1.
to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately: to estimate the cost of a college education.

2.
to form an opinion of; judge.

and the noun means

4.
an approximate judgment or calculation, as of the value, amount, time, size, or weight of something.

5.
a judgment or opinion, as of the qualities of a person or thing.

6.
a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work.

So, why is that a bad word? Well, I don’t think it’s really a bad word, but in the case of software development, the use of the word results in some serious problems.

Case 1: A developer leaves a task unfinished, that is not according to Definition of Done. The reason is that he’s run out of time according to the estimate so he drops it or finish it with lacking quality.

Case 2: A developer starts working on “something else”. The reason is that he finished what he was supposed to in less than the estimated time and felt free to spend the rest of the time with that other stuff.

Case 3: A project manager gets upset that a project is late. The reason is that he feels that the project is late because things took longer than the estimates.

So, why is estimate a bad word? It’s because it can cause people being pushed into not completing the tasks or not doing the things that have the highest priority. It causes confusion.

And if you consider a project where Case 1 and Case 2 are common, what happens? It causes some stuff to be bug infested which probably causes later delays and you’re never able to make up the time since when the developers are faster than the estimate, instead of moving on to the next item, they fill up the time with other stuff. Observe that I don’t assume that they are surfing the web or just idling, perhaps they refactor or something else. So, it is often good stuff, but not the most important stuff. And it does not help in catching up. So, what does this lead to; Case 3. If the project delivers poor quality and unfinished work and never makes up the time, of course the project will be delayed.

So, what word is better? Planned? Don’t think so, even if Microsoft Project use that word. This word most definitely leads to all these cases. Assumption is no better. When you think about it, you just have to realize that the word will lead to misunderstandings. So, what do you do?

Well, to handle Case 1 & 2 you need leadership and here I think that Kanban is a real savior. You cannot just drop the work and you cannot use the estimate as “your time”.

But what about that project manager? When it comes to the project manager’s need for planning, it’s important for him to realize that an estimate is a guess. A good or a bad guess. And when you’re guessing, you need to know the value of the guess. I like working the PERT analysis when this is a big issue (isn’t always??). You give three estimates; an optimistic, a probably and a pessimistic. Here is an excellent presentation on PERT analysis by Ricardo Vargas.

You can also add a value of risk to the estimate. So, when you estimate something, you estimate the size and the risk. And you would be stupid if you don’t realize that if you have a big task with a high risk, you cannot take that estimate for granted.

Are you planning a project or just drawing a Gantt chart?

I guess the main reason for most project managers to use Microsoft Project is drawing the traditional Gantt chart. It’s kind of obvious, since the Gantt chart view is the default view of the program. This view is also confirmed by the default fields that are visible. A task is in Microsoft Project described by over a hundred fields but only eight of these are visible using the default settings.

If you just start up a default session of Microsoft Project and don’t change any setting, this is how you define a Task:

· Name (Text)

· Duration (Days)

· Start (Date & time, even if only the date is visible)

· Finish (Date & time, even if only the date is visible)

· Predecessors (Numbers – ID of tasks which the task directly depends on)

· Resource Names (Names of Resources)

clip_image002

If you open one of the templates provided by Microsoft, they all look something like this:

clip_image004

There are all these tasks where one leads to the other and where the assignment is already done. You’re supposed to enter the Duration (in Days).

What is important is to understand what Duration is and what it’s not. In agile methodologies such as scrum, when defining tasks during sprint, you estimate how much work a task should result in. In other words; how many man hours it is estimated that a task will result in. This attribute is in Microsoft Project referred to as Work. And that is not the same as Duration. You cannot even see Work with the default settings. Work is what you get when you add resources to a task. But why is this? I believe that it all comes back to what I assume is the basic use for Microsoft Project; drawing the Gantt chart.

The Gantt chart is made up of all these blue bars, all connected to each other and leading to the end of the project. So the assumption of the Gantt chart is that if you make a Gantt chart, you can calculate when the project should be completed. That sounds great! Just what my stakeholders want.

The individual bars in the Gantt chart have a length and a place in time. The length is the attribute Duration, and therefore it makes sense to have the attribute Duration clearly visible and editable. And to place the bar in time you can use two methods, you can either link them together or you can place them on a specific date. The linking information is saved in the field Predecessors and you can specify a date by changing the Start or Finish Columns.

The final touch to the Gantt chart is the displaying of the resources names and that is stored in the field Resource Names.

So, there you have it; the columns in the default view of Microsoft Project are the ones which you need to draw the Gantt chart.

But does this mean that you can calculate the finish date of the project based on this? Well I think that experience talks against this. Just the fact that you cannot see the assumed workload makes the planning blind. And as I’ve previously discussed; since the focus factor is 100%, no holidays are in the system and the slack is 0, we all know that this is an illusion. Looking at the Gantt chart, I see the similarity with stairways and you get the feeling that all tasks are individual steps on the stairways. You just have to walk down that and you’re done. You can just check of the steps as you fly by them. Right.

Another problem with having the Gantt chart as the objective of your planning is what you want to do with that Gantt chart. Yes, you want that planned end date but you also want to show the chart to your steering group. And then you need to print it or take a screen copy and enter it into your PowerPoint presentation. Let’s see what happens when we open one of the templates:

clip_image006

But hey, I can’t see all those bars, and I cannot see all those rows! But then I need to collapse the heading tasks and change the timescale:

clip_image008

But then I’m missing out on my nice blue bars and it looks strange. So, to keep my project nice and clean, it’s better to keep the number of tasks down. Also, linking in the Chart view is a pain if you cannot see all the tasks at the same time.

And here, we also see a conflict with agile values. In most agile methodologies, you want to keep the tasks as small as possible to enable more accurate estimates. But this clutter up the Gantt chart, making it hard to read and linking becomes complicated.

Finally, we have another problem with having the Gantt chart drawing as the objective of our planning. The product backlog does not fit into this scenario. A product backlog is a prioritized list of requirements but this does not mean that the product backlog items are interlinked. So you cannot link them in the Gantt chart. But if you don’t link them, you don’t get your Gantt chart.

Next time you start Microsoft Project, ready to create the plan for you next project, keep your objectives clear; is your goal drawing a dreamy Gantt chart or do you have higher goals?

I’ve on this blog posted a tutorial on using Microsoft Project as a planning tool. I cannot say it’s easy but neither is planning. Thinking that you’ve planned your project just because you have a Gantt chart to show your steering group is a first step towards a challenged project.

Don’t forget to harvest the passion of the developers

2009/06/17 1 comment

Most of the software developers I’ve worked with want to solve the problems of the users. Many are real professionals with the attitude of a craftsman. Many are innovative about different solutions. And most of them love to write code.

If you take a developer who wants to solve problems, is a craftsman, innovative and loves to write code you are sure to hear loads of good ideas of what he could do, if he only was given the opportunity.

Many times, his suggestions are not highest on the priority list from the business people. And then you run into the situations when his stuff is never done. Yes, I know that there are other stakeholders who’s ideas never becomes a reality too, but this guy stands there with his hands deep into the code every day, thinking about those things he could do, given that he get the opportunity.

So, you should leave some room for that in your plan. For example, if you’re using scrum or another iteration based method, let the guys pick one thing if they are successful in a sprint.

If you’re doing kanban, you can be a little bit more spontaneous. The other day, one of the developers came up with a great idea. I could see the passion in his eyes. He really wanted to do it. And I could hear that he’d given the thought a lot of thinking (this proved to be correctly later). Since we’re in a situation where the next stuff on the list cannot be completed due to lacking resources of a specific competence, I was considering what we should do next. So, why not? So, I said to him to go ahead. Given that the stuff in progress is done, this will be next.

I think we’ll get so much more code/function/quality out of this than we would have if the stuff had been done with someone who didn’t think this was his stuff, someone who wasn’t thrilled about the idea. And this joy about his work will probably continue after his work with this is done. Just because now it’s done.

But besides from sometimes prioritizing the stuff the developers have passion for, one can also help developers becoming more passionate about all the other stuff. And that is best done (I think) by including them in discussions, requirements and story writing.

Quick tips for using Team System Work Item Tracking for scrum process

2009/06/14 2 comments

I’ve already posted a bunch of posts on how I use and have used TFS as a support in our scrum projects. Elegant Code have now published an interesting presentation with some hands-on advice and comparisons. You can find the presentation here. Observe that the presentation is not for beginners. You need to understand the basics behind work item tracking and is in the mode of already using TFS but thinking about which work item template and which tools are appropriate.

A note to the presentation, though. Escrum won’t be updated in the future so even if you were considering transition to that template, you should probably rethink your decision. Myself, I’m using Conchango’s Scrum For Team system and EPIServer Scrum Dashboard.

Here more about the future of escrum by bharry.

Categories: Agile Tags: , ,

About kanban and estimations – just a clarification

I previously wrote a post about how we’re starting to implement kanban and I think there is room for some clarification about how we use our estimates.

What you need to keep in mind is that on top of our software development process, we have our project management process. This process raises the funds and priority for the project. When we implement a project, this affects the budget for different departments, based on the assumption that we save time or increase income. To give you a very basic principle, we can have a project which consists of two themes. So, we build a business case:

  Benefit department A Benefit department B Sum
Theme 1 500 100 600
Theme 2 100 300 400
  600 400 1000

 

In our business case, we should have a budget of at most 1000 to be able to break even. So, for simplicity sake only, lets say that we include resources matching 1000. The budget for department A & B will now be affected so A carries 60% of the costs and B 40%.

We start with Theme 1, since this has the highest priority. But we must not forget that we cannot continue with theme 1 during the whole project. If we would only deliver theme 1, department B would probably be disappointed. They got to carry 40% of a project which does not benefit them as much.

So, what I do with the estimates is just delivering this to the developers. They are made to understand about how much time will be spent on the different themes. But it’s important to stress that this does not affect the quality they will deliver. It just give them an idea on how big big part of their time should be spent on the different themes. This to enable them to deliver with quality. I see this as transparency in information between customers and developers.

This does not mean that the developers commit to an estimate and here I see the big difference with scrum. You cannot commit to deliver on an estimate. In most cases, things tend to take a little bit longer than expected. In some cases it takes shorter time. The important thing is that the team spend the right time on the right stuff to deliver the right quality.

So, how do I use the estimates? Well, I just keep the guys informed on how much of the budget on each theme that is spent and when we get near the end of the budget of theme 1, it becomes really important to finish the important things on that theme so that we don’t stand there and are faced with the options of delivering 1 with poor quality or 2 with too little effort.

In practice this means that when we’ve used 30% of our resources, I start to really stress completing the tasks, verifying with customers that they have the features they really need so that we can use the rest of the time just completing the work. By now, the guys think they are about 90% done, but means that half the work remains so now we should really avoid new features.

Categories: Agile, planning Tags: , ,