Agile*Product*AI

Sometimes I feel like half the trash I read on the agile internet groups and blogs is written by counter-culture contrarian anarchists that smoke pot and sleep in yurts on the Oregon coast (I highly recommend at least the yurt on the Oregon coast). These extremists abhor most formal process and gods forbid someone tried to profit from writing a piece of software – especially software that can help them get their job done. Most of the rest of the crap on these same groups feels like it comes from neo-McCarthy-ist control freaks that seek to institute PMI-like controls and measures on agile development including mean time between potty breaks (which of course at which you’ll be randomly drug tested). They storm the hallways wielding their ten square meter Gantt chart like a light saber unwilling to accept that any project of material scope or effort could be managed without it. Why am I so agitated today? I am very worried that something that we built that was a simple and efficient way ...

In the early days of Scrum, we talked a lot about chaos theory and self-organization. We wanted to believe that “management” was unnecessary and even counterproductive to getting software built. Well, after 15 years and many, many agile projects (some more successful than others), I’ve formed some pretty strong opinions on how self-organization and team leadership impact a software project’s success.  A team has to have a strong, management supported leader. For purposes of this discussion, this is the team lead. It’s not important what title is on the team lead’s business card.  It may be Development Manager, Project Manager, ScrumMaster, Program Manager or whatever other label your organization is comfortable with. What is important is the knowledge and experience of the team lead. The team leader must have at least five years hands-on experience actually building software (I am assuming here that we’re talking about building software products). By this, I mean that the lead...

The democrats and republicans are doing a fine job of "fire-bombing" the centrists in both their parties (I grabbed that quote from an article "It's not easy being George" in this month’s Vanity Fair). And, as I scan the agile groups and blogosphere, it seems the methodologists are doing it as well. Some of us take the "extreme" in extreme programming too literally, and others are holding on to some of agile developments long disproved stigma for far too long. My approach always has been (and hopefully always will be, unless of course I turn out like my father, which all of us eventually do...) a pragmatic one. There are many things I love about Scrum and agile - driving elaboration and development off the backlog, test-driven development, burndown charts, and much more. And there are a some that I could do without (self-organizing teams, developers and testers are interchangeable, ... I blog on these later). An agile approach needs to be tailored to y...

One of the most important things I’ve learned from my recent stint in the project and portfolio management (PPM) space is that business success is not just about efficient and effective project execution (agile or traditional). Success is more determined by making sure that your precious resources are working on projects that return the most value to the organization. I can execute the hell out of a project and bring it in 25% ahead of schedule with a satisfied customer. But if my competitors are delivering new higher value products that satisfy a broader customer base, then I will be left in the dust. The irony is that they may have worst project execution and still beat me in the end if they’ve selected the right projects to invest in! In the PPM space, determining what project investments to make is typically considered part of demand management. Demand management considers inputs from a variety of internal and external sources including customers, analysts, partners, IT, business u...

I have been repeatedly asked why agile is better than traditional approaches. The most succinct answer I have is that agile software enables you to build the right software at the right time. Agile is not about in-depth analysis and design that leads to a detailed work breakdown structure that predicts on what day of the year eighteen months in the future a team will deliver a certain set of features. Agile is about continuous prioritization and customer review to ensure that meaningful features are delivered when they are ready and when they are needed. The ability to make significant changes to design and behavior throughout the evolution of a system is perhaps one of the biggest differentiators of software development from other engineering disciplines. And because we can, we should, and usually do. This allows organization who embrace agile principles to have agility in how their business execute as well. Being agile implies applying approaches and processes that maximize an organi...

I just returned from the 2006 Project & Portfolio Management Summit. It’s an event that is put on by Gartner every year where they roll-out their annual analysis of the PPM market. Since this is Pacific Edge Software's primary market, it was critical that we made a good showing. And since were a small company in this market (CA, IBM, Microsoft, Compuware, Mercury and others have acquired their way in over the last couple years), we decided we wanted to look and feel different from the others. So, I presented "Worlds Collide: Agile Development meets PPM." PPM advocates tend to have a traditional project management and methodology focus. I was expecting my talk to be a bit on the controversial side as PPM-types tend to focus on change control, well defined business processes, approvals, and lots of other things that repulse most agile types. I was pleasantly surprised. I basically structured my presentation as a case study on Pacific Edge. We are a hardcore agile shop w...

An essential element of agile development is rhythm. As with musical composition where there are different levels of periodicity in the same passage of music, an agile development approach has nested levels of rhythm that serve different needs and interleave to form an efficient, vibrant software development approach. The build automation system is the metronome of the software engineers. It sets the pace for code submissions, defect resolution, unit testing, peer code integration and more. Weekly feature drops are the metronome for quality assurance. Stabile delivery of weekly features drive the test organization. Sprints are the metronome of the product development team. They provide high-level integration points, usability analysis and feedback, and project visibility. The highest level of periodicity is the release. It is the synchronization point for the entire organization with the customer.