Agile development has always included the practice of timeboxing–setting a fixed project time limit. However, timeboxing can also be used in another interesting way–timeboxing capabilities and stories rather than estimating them. Working with a client that was in an early stage of development of a medium sized (over 75 people on the project), lengthy (over 2 years) project we used the idea of timeboxing capabilities during release planning. Some of the capabilities in the backlog were reasonably well defined and others were ambiguous. There were in fact a significant number of capabilities for which the potential scope was wide and estimates ranged from x to 10x or more. Furthermore, some of these capabilities were tentatively …
Monthly Archives: August 2009
My morning scan of the RSS feeds contained fewer blog posts from Agile 2009 attendees. This leads me to the conclusion that Tuesday night was a social one (and that the coffee stations had better be will stocked this morning!) Cutter folks are presenting several sessions over the next couple of days. Here’s where you’ll find them: Wednesday 8/26 11:00 am Rachel Davies & Johanna Hunt Telling Your Stories: Why Stories are important for your team Columbus GH 2:00 pm Christopher Avery & Ashley Johnson Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership Regency B 2:00 PM Mark Levison & Linda Rising Learning: the best approaches for your brain Columbus GH Thursday 8/27 …
It’s day two of Agile 2009 in Chicago, and we’ve gotten reports from our Agile consulting team of morning runs and cycling along the lakefront as well as consumption of classic Chicago pizza at Lou Malnati’s (I’m thinking the latter makes the former necessary!) Practice Director Jim Highsmith reports that he had 100 plus folks at both of his sessions (Advances in Release Planning and Zen & the Art of Software Quality) on Monday, a day that culminated with his election as President of the APLN. Congrats, Jim! Rachel Davies & Liz Sedley’s session, What Does an Agile Coach Do?, followed by today’s Top 10 Tips for Agile Coaches got great feedback, leaving folks anxious …
There is a mystique about assessing the first hundred days of just about anything. Presidents are compelled to take stock of their first hundred days in office, and Napoleon managed to fumble his comeback in “les cent jours.” So when I realized today (don’t ask me why I thought of counting) that this is the 100th day since a slightly forced repurposing of my professional life from corporate type to independent consultant, I asked myself if my recent experience could create a teachable moment for other would-be consultants. In fact, it is amazing, when you do something like this by yourself, how many distinct and diverse threads of activity you need to pursue almost simultaneously. …
“Be quick, but don’t hurry,” is a famous quote from John Wooden, the legendary basketball coach of UCLA. In other words, do the right things, but learn how to do them quickly. Author Andrew Hill recounting his playing days with Wooden, says, “Life, like basketball, must be played fast–but never out of control.” In product development, lack of quickness results in competitive disadvantage, while hurrying causes mistakes. Balance is one of the keys to agility. “Wooden’s genius was in helping his players find and maintain that razor’s edge between quickness and hurrying,” says Hill. The epitome of competitiveness is forcing your competition to hurry. Your team can turn out a new product in 9 months–they …
Enterprise Architecture has become a mainstream activity in large or information intensive organizations. In the past few years, the industry has seen lots of changes: “the cloud”, Enterprise 2.0, an updated Zachman Framework, unprecedented growth in TOGAF certification, maturing definition of business architecture, financial crisis and new priorities. How have these trends affected EA in different organizations? What activities are they focused on? Have they been able to hire qualified candidates? What are the new issues and challenges being faced by organizations? Several years ago, Cutter IT Journal covered the emerging best practices in EA and since then, readers have requested that we check back to explore how things are evolving. So that’s what we’re …
A few weeks ago, I had a little electrical incident at my house. After the fire department left and the mess was cleaned up, we took stock of the damage. Except for the offending surge “protector” that caught fire, our UPCs pretty much did their job. No computers were damaged — just a dead scanner, a zapped paper shredder, fried cordless phone, and, most frustrating of all, an ex-coffee maker. I really like coffee … a hot cup of joe for breakfast, espresso in the afternoon, coffee to take in the car, iced coffee on a hot summer day, coffee for entertaining — you get the point. I had already been suffering coffee cravings because …
If agile methods are to achieve the position of strategic organizational capability rather than tactical engineering capability, then one of the key factors in achieving that position is changing the way we measure success. Many agile teams are now caught in a dilemma. On one hand they are told to be agile, flexible, and adaptable, but on the other they are told to conform to pre-planned traditional Iron Triangle framework of scope, schedule, and cost. In essence they are being told “be flexible in a very small box.” Agile teams are striving to meet one set of goals and managers and executives are measuring against another set. Measuring success it tricky. Motorola’s ill-fated, multibillion-dollar satellite-based …
One of the touted benefits of agile development is better early information on project problems and issues. This early detection enables management — project and otherwise — to take adaptive actions. However, early problem detection comes with its own problem — discomfort with early information. In waterfall projects management and staff are used to getting information about problems late. This leads to a perception that projects are typically on-track until late in the lifecycle. In fact, the lack of working software until late in the project provides a false sense of progress. Because coding and testing come late in waterfall projects, they “appear” to be in good shape — until the end when the project …
A primary function of IT architecture is managing change. This change happens at varying rates in and between levels of abstraction (think of wind moving at different speeds at different altitudes). So we can think of “horizontal” change — change in time within a particular level — as well as “vertical change” — the relationship between one level and another. A robust IT architecture maximizes the potential for improvements in all levels while minimizing the negative impact of change between levels. Sometimes IT architecture emerges through acquisition. In the old days, vendors imposed architecture that was bundled with their software development products. (Why would anyone have otherwise considered something like systems application architecture [SAA]?) As …


Recent Comments