Rhyous

We should all strive for the three-minute standup. If you stand up is different than this, you are doing it wrong:

Manager: Hey, all, let's start standup.

Manager: (looks at Dev 1) Kanban board says you moved Blah task to done yesterday and pulled in foo task today.
Dev 1: Yes.
Manager: Good work. Need anything from me or the team.
Dev 1: No

Manager: (looks at Dev 2) Kanban board says you moved Oober1 task to done yesterday and pulled in Gobblygook task today.
Dev 2: Yes.
Manager: Need anything from me or the team.
Dev 2: Yes, I need help from Dev 1 to do Gobblygook.
Manager: (looks at Dev 1) Dev 1, can you talk to Dev 2 about gobblygook after standup.
Dev 1: Yes

Manager: (looks at Dev 3) Kanban board says you moved Whatsit task to done yesterday and pulled in WrongWork task today.
Dev 3: Oops. Yes, I finished Whatsit yesteday, but I pulled in the wrong story. I am working on RightWork.
Manager: Fix the Kanban board mistake. Need anything from me or the team on RightWork.
Dev 3: Nope

Manager: (Looks at Tester) Kanban board says you finished tests for oober1 and you are working on testing Blah.
Tester: Yes, there was one bug, I verbally told Dev 2, he fixed it. I retested and all tests pass. I am testing Blah now.
Manager: Good work. Need anything from me or the team.
Tester: I'll maybe need to speek to Dev 1 about Blah sometime after lunch.

Manager: Great job team. Keep up the good work.

Stand up ends.

Notice the key to a successful standup is the Kanban board (or Scrum task board). You shouldn’t ever have to explain what you are working on, it is on the board.

If you don’t have a Kanban board or task board, get one immediately.

As a follow-up to Why your story estimation was off!“, I have created a spreadsheet for sprint management. This spread is not for helping you size a story, but instead it is for helping you determine how many stories your team can really do a single sprint.

It has the documentation on a separate sheet inside it.

Sprint Planning Spread Sheet Template.xlsx

Estimations are often very far off because those doing the estimations forget what is involved in completing a story. Often the estimation is done based on how long it takes to code it up. As you can see below, coding it up is just one of the tasks per story.

Even just doubling the code time is inaccurate. Why does a team that doubles the code time estimates still fall behind?

• Because they didn’t understand what is involved in the story.
• Because they don’t understand coding time versus work time

Reason #1 – You didn’t consider all the development tasks

There are many more tasks than just development. You need to know what these tasks are and understand them. You need to understand the risks each brings to meeting your goals.

Tasks to consider when estimating story time

First determine which tasks apply to a story. Then estimate each task individually. Then simply add up the hours. Your estimations will probably be more accurate and upper management will become aware of what tasks are slowing a story up.

Using this list can also help with getting tasks done at the same time as opposed to using the waterfall method. For example, if you are creating a new file, you can create an empty project, check it in and build and install can get working on their tasks while developer is still coding.

Let’s give an example:

So if you estimate based on coding, which is just 8 hours, you can see you aren’t even close. It will take four and a half times as long as you thought. If you estimate based on code and unit tests, 16 hours, you are still more than twice as long as you thought.

Note: I am not saying that these all have to be tasks on one story. You could break them up into separate stories. However, you will find that if Unit Tests and Automated Tests and these other tasks are separate stories, then the person in charge of prioritization of stories is now able to drop them in favor of other work and then your code will blow up one day and the developers will take some of the blame even if they shouldn’t. It is best if a story and all its tasks are 100% complete so you don’t ship half finished or a half tested product.

Reason #2 – You think developers code eight hours a day

Ok, so let’s talk about an eight hour day.

Most states have laws about two fifteen minute breaks (one ever four hours) so really, any employee is only going to work 7:30 hours a day. Ok, now add in the fact that it  usually takes five to fifteen minutes to focus back on work once back from a break. With lunch and two breaks that is 15-45 minutes. So now we are down to 6:45 minutes to 7:15 minutes. Ok, how long will be spent on email? 30 minutes to an hour. So now you are down to 5:35 to 6:45 hours of coding a day. Now factor in Stand up. 5-15 minutes, plus 5 to 15 minutes to get focus back and we are down to 5:05 to 6:35 minutes.

So on the best days a developer will likely code between five hours and 6 hours and 35 minutes.

Add a meeting or two in a day plus the refocus time after the meeting and development time is decreased further to 3 hours to 4 hours on meeting days.

So if you are assuming that your developers are going to coding 8 hours a day, you are in for a shock.

• Best Day: 5 hours to 6-1/2 hours
• Meeting Days: 3 hours to 4 hours

So add in scrum and sprint planning, story costing, and sprint retrospective, in which some meetings are longer than two hours and you lose a full day of development every sprint. So with a two week sprint, plan on 9 days of development at an average of 5 hours a day and you get 45 hours of development time.

• Average development time per sprint per developer: 45 hours

Now if you have a team of three developers. An inexperienced team might estimate with 45 * 3, or 135 hours. Unfortunately that probably won’t be accurate. Estimators will find that inevitably one of the team members has time off during a sprint. Remove 5 hours per day off (not eight). There also might be a holiday during the sprint. Well, a holiday means that 5 development hours per developer are not available, so that 135 hours becomes 120.

So lets put this into perspective. If you think that you have 8 hours a day for 10 days in a two week sprint for 3 employees and so you plan 8 * 10 * 3 and get 240 hours, and then you plan 240 hours of stories, you are only going to get half way done. This calculation is almost twice what in reality your team can do. If you plan this way, you will always be behind, and fail to meet goals and deadlines while working your developers to death.

Can you make up the hours by working the developers longer? Not really. The developers may end up putting an extra two hours a day in for 9 of the 10 days, but they will probably take one more 15 minute break on those days. Which only gets you about 1 hour and 30 minutes more per day times 3 developers times 9 days. This is 45 hours. 120 hours plus 45 hours only gets you to 165 hours. You are still 75 hours short of 240 hours.

So estimate accurately by starting with 50 developer hours per two week sprint (10 * 5 = 50) for each developer and subtract days off. Then estimate the work that can be done.

To make this easier for you, I have created A Spreadsheet for Sprint Planning that you can use.

Conclusion

If you fail to understand the number of development hours and fail to understand all the work for each development story, you will never be accurate, and you will always be behind and always be asking your developers to work longer hours, which will create a horrible work environment.

Understanding both of the above reasons above and estimating accordingly will provide accurate estimates. This will benefit the whole company. Upper management will see the true velocity. The quality of the code will be higher because the developers won’t be overwhelmed and stressed, which will result in lower bugs, maintenance, and support costs. Marketing will have realistic ideas of what is coming and what isn’t and won’t waste money getting ready for features that drop off a month before ship.

Technical Support Engineers are not all the same. There is an inclination in the industry to look down on Technical Support Engineers.

Recently the following article was published:
10 IT positions ranked by prestige

This article didn’t exactly identify the Technical Support Engineer role, but it was unfortunately encompassed in the bottom two positions with the lowest prestige, Technical and Help Desk Analyst.

Should a Technical Support Engineer have the lowest prestige of all technical jobs in the industry? If you think so, you might want to reconsider after read this.

There are multiple levels of technical support and you should know what level of technical support a person is in because that should significantly change your view of this persons technical skills and ability.

What they support and to what level they support it makes a major difference in how to view a Technical Support Engineers background.

Obviously there is a difference between someone who does tech support for a company like Cisco, Microsoft, LANDesk than someone who does technical support for a BowFlex. But this is an obvious difference. A chart that is more of gradient is needed.

Here is some information to help guide you in determining what experience a Technical Support Engineer really has in the technology industry.

So I introduced Kanban, the project management process we are using at work, to to my wife and she is going to try it out for her managing the tasks for her blog.

Of course, being a craft blogger, she made a craft project out of the idea for making a Kanban board. Check out her version of a Kanban board.

Old Window + Personal Kanban = Task Board

It makes a difference if you do something the right way from the beginning.  Everything seems to work out so much better and takes less time over all.

Here are some basic steps that I have learned will help you do it right the first time. These steps are from my experience, mostly because I did it wrong the first few times.  These are not exact steps. They are subject to change and improve.  In fact, you might have improvements to suggest immediately when you read this. But if you are new to WPF, then reading these steps before you start and following them, will have you closer it doing it the right way the first time.  It is much more pleasant to tweak a pretty good process than it is to go in with no idea for a process and do it wrong.

Step 1 – Prepare the idea

1. Some one has an idea
2. Determine the minimal features for release 1.
3. Determine the minimal features for release 2.
   1. Alter minimal features for release 1 if it makes sense to do so.
4. Determine the minimal features for release 3.
   1. Alter minimal features for release 1 and 2 if it makes sense to do so.

Step 2 – Design the Application’s back end business logic (simultaneous to Step 3)

1. Design the backend
2. Apply the “Keep it simple” idea to the business logic and makes changes as necessary.
3. Apply the “Keep it secure” idea to the business logic and makes changes as necessary.
4. Repeats steps 2 and 3 if necessary.
5. Backend development can start now as the UI and the back end should not need to know about each other, though this coding is listed as the Step 5 item.

Step 3 – Design the UI using WPF (simultaneous to Step 2)

1. Determine what development model should be used to separate the UI from the business logic.
   1. Model-View-ViewModel (MVVM) is the model I recommend for WPF.
   2. Gather libraries used for the model (such as common MVVM libraries that include the common ViewModelBase and RelayCommand objects)
2. Consider using a 3rd party WPF control set will be used.  Many 3rd party companies provide WPF controls that are better and easier to use than those included by default.
   1. If you decided to use 3rd party controls, purchase or otherwise obtain the libraries for these 3rd party controls.
3. Consider designing two WPF interfaces or skins (I will call these Views from here on out) for each screen. This will help drive the separation of the back end code from the WPF code. Also if developing two Views is not simple, it indicates a poor design.
4. Design the interface(s) (you may be doing two Views) using SketchFlow (take time to include the libraries for the 3rd party WPF Controls in your SketchFlow project and design with them)
   1. SketchFlow allows you to design the UI, which is commonly done in paint, but instead does this in XAML, and is actually the WPF code your application will use.
5. SketchFlow allows you to deliver the design (or both Views if you did two) as a package to the customer.
   1. Deliver it immediately and get feedback.
   2. Make changes suggested by the customer if in scope.
6. Take time to make the XAML in SketchFlow production ready.
7. Deliver the XAML to the customer again, to buy of that the design changes are proper.
   1. Make changes suggested by the customer if in scope.

Step 4 – Determine the delivery or install method

1. Determine the delivery method.
2. Determine when to develop the delivery method.
   1. The easier the application is, the longer you can wait to determine the installer or delivery method.
   2. The more complex the install or delivery method, the sooner this should be started.

Step 5 – Develop the business logic

1. Develop the application designed in step 2.
2. Get the application working without UI or silently. Note: Start the next step, Develop the UI, as soon as enough code is available here.

Step 6 – Add Bindings to the UI

1. Start the UI project by copying the XAML from the SketchFlow document to your Visual Studio or Expression Blend project.
2. Determine a method for setting the DataContext without linking the View to any ViewModel or Model dlls.
3. Create a project for the ViewModel code and develop it to interact with the business logic using Binding.
4. Remember to develop two Views for every UI screen as this will help, though not guarantee, that the the MVVM model was correctly used.

Step 7 – Develop the View Model

1. You should now have a backend code and a View, and now you start creating the View Model.
2. This should be in a separate dll than the View or ViewModel.
3. The ViewModel should never link to the View but can link to Model and Business libraries, though you may consider interface-based design and only link to an interface library.
4. Make sure to use the properties that the View is binding to.

Step 8 – Consider a other platforms

Macintosh

Macintosh owns a significant market share.  Determine if this application needs to run on Macintosh as well. Sure, since we are running C# your options are limited to either rewriting in objective C and Coca, or using Mono with a MonoMac UI.  I recommend the latter.

Note: It is critical that the UI and business logic are separated to really make this successful.

1. Completely ignore the WPF design and have Macintosh users users assist the design team in designing the new UI.  Macintosh’s have a different feel, and trying to convert the same UI is a mistake.
2. Create the MonoMac UI project.
3. Create a project similar to the ViewModel project in Windows, to link the UI to the business logic.

BSD/Linux/Unix

BLU (BSD/Linux/Unix) doesn’t exactly own a significant market share. However, it is still important to determine if this application needs to run on on BLU as well. Sure, since we are running C# your options are limited to either rewriting in C++, or using Mono with a GTK# or Forms UI.

1. Completely ignore the WPF and Macintosh designs and have Linux users assist the design team in designing the new UI. Linux have a different feel, and trying to convert the same UI is a mistake.
2. Create the GTK# project.
3. Create a project similar to the ViewModel project in Windows, to link the UI to the business logic.
4. GTK# doesn’t support binding, but still keep the UI separate from the business logic as much as possible.
5. Also, don’t develop for a single open source flavor, but use standard code that compiles and any BSD/Linux/Unix platform.

Mobile Platforms

1. Do you need to have this app on IOS or Android or Windows Phone?
2. Completely ignore the WPF and Macintosh and Linux designs and have Android or IOS users assist the design team in designing the new UI. Mobile platforms have a different feel, and trying to convert the same UI is impossible as the screens are much smaller.

Step 9 – Develop the delivery method

Again, you may need to do this way sooner if the application is complex.

1. Develop the install or delivery method.
2. If you decided to deploy to Macintosh or BLU you may have to develop separate install or delivery methods for those platforms as well.
3. Remember to have a plan and a test for your first patch even if you have to mock a sample patch before you release.
4. Remember to have a plan and a test for upgrading your application even if you have to mock a sample upgrade version before you release.

Step 10 – Deliver the finished Products

1. Once finished, deliver this product.
2. If you decided to create a Macintosh or BLU version, deliver them when ready as well.  It is OK and maybe preferred to deliver these at different times.

I just bought this book today and it should arrive on Wednesday.

My wife and I can read it an improve our home projects. If we can eliminate waste at home, that will be as beneficial in our personal lives as it is for our work lives.

Though we are normal parents, I work and she is a stay at home mom, we both have blogs and we are also very involved in our church, so we should be able to improve our efficiency by visualizing our work.

Depending on how good this book is, I am going to recommend it to others in my family who could benefit from Kanban principles.

At work, our development cycle is being converted to a Kanban system.  I read a book, cleverly titled Kanban, about the process and it was really good.  I have been thinking of bringing Kanban home and then I googled “Personal Kanban” and low and behold there is already a book on it.
http://www.personalkanban.com/pk/personal-kanban-the-book/

The idea of Kanban can be summed up best in two ideas that are intended to eliminate wasted time:

1. Make the work visible. – If you always know what is next, you don’t waste time wondering what to do next or forget and do something not yet needed.
2. Limit the Work in progress – By not jumping from item to item, you have less wasted time.

So it is basically like a “honey-do” list, but where you limit the amount of items you can actually be working on at one time.

The idea is to have columns similar to this:

So I am going to try this at home for a while. I may even buy the book. I did put it on my amazon wish list.