Posts

Showing posts from September, 2009

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

Image
:: 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

Image
:: 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

Image
:: 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

Getting a team over the fear of daily scrums

Image
::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

Looking Back: Creating a Software Factory – Part 2

Image
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 mor