You are currently browsing the monthly archive for June 2010.
I came across a good article on building technology teams at http://leanstartups.com/putting-together-strong-technical-team.html. In particular, I thought the foundational principles that the author listed were great:
Strong talent in a small team can be far more effective that average talent in a larger one.
Well directed and motivated expert teams execute effectively. They tend to need more tender loving care because they can be precious about their output, but this is a small price to pay for the results that can be delivered. You will expect to pay that expert talent more, but you can offset that by recruiting fewer people.
Try to operate like the team is a small start-up
The by-product of creating this environment is that the team feel they can operate outside of the “red tape” that besets many larger organizations and start to get creative and innovative. Typical examples are removing all the “lock downs” that most corporate organizations enforce on company provided hardware. This doesn’t mean that it’s a free-for-all – the environments should be well thought through and consistent. Also allow the team to work on a flexi-time basis.
Have a strong leadership team that is transparent
If the team know their leadership have their support and trust them then they are less likely to want to fail and will go beyond the cause to get things done and done right. A leadership team that shows they have direction and can speak to the team about it, can be open an honest about how things stand will have the respect and therefore the backing of the team – this loyalty is an extremely valuable commodity.
Cultivate the environment where everyone matters
Empowering the team and ensuring that everyone feels more than comfortable to give an opinion to anyone in the group at any level. This creates an environment where people get passionate about their work and team.
Shield the team from corporate noise
Avoid team members getting caught up in meetings etc. that take away their time from doing the work they love. This is a value add that they will respect you for.
Communicate!
Create effective communication strategies – canvass the team about what sort of information would be useful. Have at least one team meeting a week and consider having a “beer Friday” once a month – take the team outside of the work environment and let them talk. It’s amazing what you’ll find out!
Check out the article for more tips, including specific advice for hiring various roles.
First of all, I wanted to announce that the scope of this blog might be growing a bit; I was recently promoted from the Release Manager at Citysearch to Engineering Manager for several teams working on our advertiser platform. A lot of the reason I was promoted was because of my experience in process development, so there will still be a lot of correlation between the original content and where we go in the future, but I’ll definitely be growing and talking about new subjects with relationship to the broader organization.
In that light, I wanted to talk about my experience moving my software teams from Scrum to an iteration-less form of Kanban. My CTO, Christophe Louvion, provided a nice high level summary at http://runningagile.com/2010/05/31/a-few-weeks-of-kanba/ based on feedback in a presentation one of my teams gave, and I’m going to expand on the list:
Stand ups differ – going story by story, not based on individuals
The story-based focus, where we start at the right of the board and focus on how to move stories into the “complete” column, has encouraged the team to be more collaborative in analyzing, executing, and testing their story implementations. Previously, the teams were going down the list on the first day of the sprint and assigning items out one at a time in an effort to essentially maximize their work in progress. Unfortunately, this was pathological in that it ensured that only one person knew the implementation for that story (and that you were done if that person ended up getting sick) and that it discouraged the team from swarming around one or two items. Now, everyone on the team is aware of what the entire team is working on and can share the load as needed.
Less Rules: No roles prescribed, More Dynamic
This speaks to the core Kanban idea that the process itself is something that is being engineered and tailored to the team; the team feels that they don’t need to have roles (such as the Scrum Master) that the team has in many ways grown out of the need to have. If they are mature enough to self-organize, they are more than welcome to do so – and they are.
Backlog more Flexible
If you’ve ever worked in advertising you know there are a lot of stakeholders out there and when deals get done they need to be implemented irrespective of any two or four week sprint cycle. The flexibility of the “to-do” list in Kanban allows our product team to reprioritize any work that the team has not already started development on, which in turn gives the product team the ability to ensure we’re always working on the latest requirements from the business. Everyone knows they are working on the latest and most important features and that means real value when we deliver.
Pros: Better Team Focus, Less Meetings More Time to Deliver, More Flexible Work Process
Again, the second two points here speak to the ability of Kanban teams to tailor the process to themselves. The first point, however, is really worth digging in to. In my opinion, the increased team focus comes from the participation of the team in engineering their work process. Prescriptive methodologies such as Scrum, although good general rules for many teams, do not necessarily require the team to understand the why behind many of the reasons that the process is the way it is. In fact, they are designed so that even teams who do not understand the whys can be effective. In contrast, because Kanban drives change from within the team, the team is encouraged to experiment with the process (even making mistakes, as long as there are lessons learned), which results in a team that understands at a very deep level what works for them, and why. On my team Kaizen events have jumped significantly now that the team understands the process and knows that they are empowered to make changes in a safe environment.
Cons: Less Structure Could Cause issues with Some People
This is one item that I’m still learning a lot about. Kanban does seem like, much more than Scrum, it requires leaders at all levels in the organization to drive the positive process change. I’ve been on a couple different teams that were learning Scrum as they went – I’m not sure that Kanban is capable of working for teams at that level. It simply provides too much flexibility to the team and much of the guidance asks you to analyze your specific situation rather than reading out of a playbook. That said, I haven’t actually tried Kanban yet with a less mature team so my data is incomplete here.
How Its Working Out: Feels Good, Increased Our Collaboration, Communication Has Increased, Forces Follow Up to Eliminate Blockers
“Feels good” is another important component. If you saw the last video post I made, you know that two of the major elements that motivate people are autonomy and mastery. Kanban provides these in that it trusts the team to engineer their process in a way that works for them – the methodology is not from “on high” and passed down to them to execute; instead they are an integral part of the process. We hire smart people who are good at engineering software systems, it turns out those kind of people have an intuitive sense for engineering process as well. The Kanban board and metrics provide a visual way for the team to see that things are getting better and to know that they are leading themselves to an increased level of mastery.
All in all, moving to Kanban has so far been great for the team. We’ve only been experimenting with the new process for a few weeks now, but already it seems like things are on an exciting new trajectory. I’ll be updating this blog with more details on how things are going as we continue to learn and grow.
Lean Builds 