Wednesday, September 30, 2009

We don’t have time for all of these meetings!


:: Originally Posted on Pathfinder Development's Blog ::

The majority of people who develop software utilizing agile practices find that they spend much less time in meetings than they did before they discovered Agile thinking. However, time and time again teams that I have coached hear about Scrums (stand-ups) and half-day iteration planning meetings quickly exclaim, “We don’t have time for all of those meetings. What’s wrong with our weekly status meeting?” Frankly, a lot.

This meeting phobia, in my experience, stems from the fact that people aren’t accustomed to using communication as a tool in order to solve problems, build good architecture, and complete work. Secondly, they likely scarred by meetings that meander and are longer than they are useful.

Building a High Performance Agile Team: Assume You Will Be a One Hit Wonder


:: Originally Posted on Pathfinder Development's Blog ::


One thing about agile teams is that they constantly strive to get better. In my experience an Agile team takes 2-4 iterations to work through the forming stage. By iteration 10 or so the team is past forming and storming and is well into norming. At this stage the team is often moving fast enough or better than expected for the business’ needs. Now the team faces a dilemma: How to become a high performance team and why.

If you don’t keep improving and innovating your competitors will. However, there is another reason to keep improving that is often missed. The current success might be temporary or an anomaly.

Don’t fall into the trap of a one hit wonder.

Agile 2009: A reminder of why each team needs leadership


:: Originally Posted on the Pathfinder Development's Blog ::

Last week I presented at Agile 2009 a workshop for those new to Agile entitled: The Agile Game: An Experiential Workshop. I love this workshop because it allows those new to Agile to experience the rhythm of an agile project in action and learn first hand many of the practices in a non-threatening, non-technical, and fun way. I have used this workshop for clients a number of times and it works. The feedback from this session was overwhelmingly positive too. Comments such as, “Fun game, good to demonstrate how teams do and don’t work together” and “Very, very, practical way to get concept through” are always great to see.

Recently I had been wondering if Project Management was a questionable career choice. I have spent the last couple of years surrounded by talented individuals who seemed to be able to work fine without me. The test is always when the project manager (me) goes on vacation. Has the team fallen apart? Are they forgetting all of the practices they were doing? Is stuff getting delivered to clients? I was finding that I had a backlog of chores when I came back, but overall things were still humming along.

Getting a team over the fear of daily scrums


::Originally posted on the Pathfinder Development's Blog::

If my previous post about the value of agile meetings over traditional status meetings got you interested, I want to share a common pattern of behavior I often see from teams trying scrums for the first time. Hopefully you can avoid these and save yourself some time.

For new teams to Agile the statuses given in scrums are generally … well … lies. “Yep, on time. No obstacles.” I was once told by a colleague that, “You can’t hide on an Agile team.” This is true. However, this kind of exposure can be extremely uncomfortable for individuals to get used to. In traditional software teams people aren’t used to their peers asking them direct questions and paying close attention to their progress.

Great Article about how to manage technical people

The unspoken truth about managing geeks

http://www.computerworld.com/s/article/print/9137708/Opinion_The_unspoken_truth_about_managing_geeks

Tuesday, September 1, 2009

Looking Back: Creating a Software Factory – Part 2

In my last post I talked about the first iteration of the software factory I created. In it I talked about how I followed traditional management techniques to add offshore developers and testers to the team. The changes slowed individual productivity, however we could cheaply add more people from a cheaper labor market.The result was that overall the department hadn’t suffered any deterioration in throughput.

Phase Two – A good problem to have – more work. Or…A learning experience.

Once the department was stable and was beginning to enjoy some level of regularity the leadership team and I were beginning to look like heroes. We had substantially changed the mix of the department without changing the overall budget and throughput. Our success was not a secret either. We started to receive weekly visits from managers in other departments wanting to talk to us and learn from our experience.

Good things rarely last: Unexpectedly, the external market environment changed and more work came - actually twice as much work. We needed to add a lot of capacity quickly. By this time the detailed metrics were beginning to pay off. My initial estimate based on other offshore teams I had worked with in the past was that the offshore team would be 2x – 3x slower than the local team for the first 6 months. However, this offshore team was almost as fast as my local team – but with fewer technical defects. When capacity was needed we decided to add more capacity offshore.

3 months later…

The onshore team was working 50+ hours a week fixing defects from the offshore team. Depending on where you sat the requirements being handed over to the offshore team were inadequate or the offshore team couldn’t understand them. Luckily, the technical defects in production were still low - this was an internal problem.Another problem was that the managers (both in Chicago and India) were putting in 60+ hours re-planning work to accommodate schedule overruns and handle our constantly changing customer priorities. It became obvious that our previously successful model couldn't scale. Quickly, I was on my way to India in order to meet the new team members and find out why, initially, they had been so successful and why that success hadn’t lasted.

Welcome to India



The first couple of days I was there the senior manager was away. I was able to avoid the usual dog & pony show and just sit with the team. I quickly realized that there wasn’t anything fundamentally wrong with the team. They were motivated, a close knit team, hard workers, and had a great technical team lead. They even had a team moto, “Stealth, where challenging is sporting.” Due to the highly sensitive data the team was working with, they were in a secure “vault” which afforded few distractions from outside. These are all good signs and success factors. When I asked the team about what had changed they said that earlier they were updating existing models, but the new kind of work was different every time. It suddenly clicked. The factory model we created was based on recurring simple changes to an existing code base. This type of work could be optimized. Previously, each time a team member saw a new customer’s code based they lost some time learning it, but they only paid that cost once. The new type of work required some domain specific analysis to understand what the customer wanted and then some technical analysis to find an appropriate solution. This team that was 12 hours time shifted from the customers had very little opportunity to learn the customer’s domain and solve their specific problems. We needed a better model. But, first I needed to understand why they had ramped up so quickly compared to other offshore teams I had worked with in the past.

When I first got to the “vault” I noticed the team was doing something really unusual to me. At first I attributed this to cultural differences and didn’t consider this was possibly their greatest differentiator. With little manager oversight and a locked vault to hide what they were doing, they shared a single computer and worked on the same tasks together. I also noticed they met together before they wrote any code and discussed the approach and how to test it. Their technical team lead had just written a presentation on unit testing and was the local TDD police - making sure everybody wrote tests. Finally, as I started to get to know the team better, I noticed some of the QA testers were sitting with the developers while they wrote code. This was my introduction to paired programming and Test Driven Development. That evening I started to do some research into these practices which changed the way I approached software forever. I was ready to begin implementing these changes back in Chicago.

Next: How the factory retooled itself and reached high efficiency --->