Archive for June, 2008
Our team has decided to take a step back towards scrum and away from our previous semi-Kanban approach. I think that it’s a good plan at this time, although I also suspect that many of the benefits of our earlier approach will continue to show through.
Why did we do this? Here’s some of my thoughts. They do not at all reflect the thoughts of anybody else on my team or in my company.
- We were unable to fully realize the benefits of Kanban. For example, we had a visual mapping of our value stream, but we never made the transition to using that visualization to improve how the team communicates within itself or to the outside.
- We lacked the process maturity to accurately forecast release dates for specific features based on lead times and SLA. I believe this was in large part due to the ongoing issues we’ve had with controlling batch size (both too large and inconsistently sized). I think we’ll be able to better do this in the future, but the current failures did not go a long way to building trust in our approaches with stakeholders.
- We had early success with Scrum before we changed product targets. Scrum has been highly effective for our management team in planning features at a high level. I believe that ordering and allowing the dev group to choose the amount of focus on each one would be more productive overall; however, we’ve had issues in determining a good order, and we’ve struggled to structure a good focus across roles within the group.
I anticipate that our “outward facing” status and planning will be Sprint-based, while our internal approach will remain somewhat Kanban. The sprint backlog will serve as our feeding buffer, while we’ll manage how much work we allow to be active amongst the team during a sprint the same way that we are now. The biggest difference is that our in-process lead time is artificially fixed at 30 days and our overall response time to external requests will average around 45 days.
In the beginning, there is no resume, only an application.
Then, there is the resume.
Later, the resume becomes an afterthought, used to round out the paperwork.
Until, eventually, there is no resume, only trust.
Thanks Dan, I don’t have time for this, but you went and called me out.
Here is the trace of how this request eventually got to me:
1. How old were you when you started programming?
I was a bit of a late bloomer. Other than playing around with Commodore BASIC and Q-Basic when I was five, I probably didn’t do any “real” programming until I was in college.
2. How did you get started in programming?
I graduated college, arrived for my first day on the job for Embedded development, and was handed this big book on COM to go with the C++ I had already learned in college. I never did get to do any hardware work.
3. What was your first language?
Commodore BASIC when I was a wee one, then C++/ATL/WTL for the real world
4. What was the first real program you wrote?
I wrote a C++ program for a local company during my first summer off school. It modeled heat flow dynamics in a washing machine. I’m still not entirely sure WHY they wrote it, since it didn’t seem to match the stated goals of the program, but it was the result of multiple generations of interns working away at it.
5. What languages have you used since you started programming?
BASIC, C++, C#, Java, VB, VB.NET, and unofficially, BF.
6. What was your first professional programming gig?
An intern after my first year of college. After that, I went to SEP, Inc. right out of school and stayed there for seven years.
7. If you knew then what you know now, would you have started programming?
I think I would have. I probably would have planned ahead a bit more on how I’d integrate other aspects than just coding, but definitely would write code.
8. If there is one thing you learned along the way that you would tell new developers, what would it be?
- Read. Write. Share. Talk.
- Essentially, see Dan’s, because he pretty much nailed it. It all comes down to partaking of the experience of others so you don’t have to make the same mistakes.
9. What’s the most fun you’ve ever had … programming?
Honestly, it’s been this last push where I’ve been able to take a brand new technology and bend it to my will, producing a VERY sexy consumer app in the process.
10. Who are you calling out?
Sorry, the line stops here, otherwise I’d have to call out my team, and they’re all WAY to busy.
Lots of little things with various results. The breaking changes list got me through 99% of them, here’s some of the others, and I’ll probably update now and then with more.
1 – Image.Source property. Before, I could use this to find out if I’ve already initialized an image (in a hover-popup in this case). Now, it returns a valid BitmapImage, even if it’s empty. Good, but not what I expected and it failed silently until I realized my previews weren’t showing.
if ( PreviewImage.Source == null )
2 – ActualHeight and ActualWidth seem to be getting set later in the first layout pass than they were before. This led to some issues in setting a ScaleTransform during the first layout pass.
The concepts surrounding batch size have been floating around my head again in recent days. My current assignment is a rather large batch of work with Silverlight 2.0, but it’s one that I’ve been able to subdivide into a number of small batches that rapidly build on each other. Thus, each one of my check ins to my private branch are able to show continual improvement in what I’ve made available. Unfortunately, from a throughput perspective, the value of this is exactly _zero_. Why? Because until Silverlight 2.0 Beta 2 is released, we don’t have a GoLive license from Microsoft. Thus, this environmental constraint has forced me into a situation where I have a very large batch that can’t be released until a specific point.
What does this mean? For starters, it means that our board has a VERY large balloon of work in the middle, and that overall we have near-zero flow. Our work in progress is artificially limited to three requirements, but the actual size of one of those is 10x the other two.
What are the implications of a large, all or nothing batch of work? Probably 90% of the features within the requirement would apply as MMF’s, so they can’t really be dropped out. I can’t do partial releases due to policy constraints (although, we’ll be bending that a bit since it’s not RTW). I’m going to think about this, and I’ll try to remember to post what comes out of this. For now, I’ve got more code to write. Mixing methodologies a bit, I should be able to trickle out a couple more inch-pebbles tonight