Recently there have been rumblings within the industry along the lines of “what’s next after agile?” and “what does the post-agile landscape look like?” These rumblings reflect the challenges organizations face when adopting agile within an enterprise environment. Although popular, Scrum only provides a small kernel upon which to build an agile strategy, leaving you with the heavy lifting of tailoring an end-to-end agile strategy that reflects the realities of your environment. Worse yet, the simplistic strategies promoted by agile purists sow seeds of confusion and doubt amongst people still struggling to adopt an agile mindset. Beliefs that agile requires small co-located teams, downplays architecture, delivers no documentation, doesn’t work in regulatory situations, and doesn’t …
Posts Tagged 'agile-methods'
Quite a few clients report that agile is anti-innovation. The developers have a vested interest in developing whatever they can produce within the allowable time. They are rewarded for maintaining the velocity of the project, not for their innovative solutions. Note that innovation, as we use the term here, means fresh thinking. We do not mean that innovation is the same as invention — it’s not. Innovation is thinking differently about the business problem with the intention of finding more beneficial things for the business to do. User stories that are not based on real business stories will struggle to be innovative. The user story describes what happens at the interface and is mostly what …
Many of the discussions I am exposed to as an agile consultant are about this question, “Have Agile methods crossed the chasm?” The client wants to know whether he or she will be using a software method that has reached a certain level of maturity and acceptance. Needless to say, the question is of critical importance. A client might be willing to be an early adopter, or even desire to be an early adopter, but he or she wants to be very clear up front about the maturity level of the software method to be adopted. As important as the question is, I will not try to debate it here, as beauty is often in …
The devops phenomenon is gaining traction in enterprises worldwide and its results have been turning heads in the business and user community. Bridging the gap between projects and operations, devops has the ability to deploy and manage business services in “real time.” The July 2011 Cutter IT Journal, with Guest Editor Patrick Debois, will examine both the opportunities and challenges created by the devops movement. Proposals of interest are due 29 April 2011. To respond, please visit http://www.cutter.com/content-and-analysis/journals-and-reports/cutter-it-journal/callforpapers03.html
“You did not finish the stories you committed to!” a product owner at a client of mine recently raged against the team. “What the hell are you doing all day long? This commitment was pointless!” And he was right. The team commitment Scrum includes as part of the planning ritual is a dangerous practice that needs care — and committing on a certain number of stories or story points really is pointless. “Commitment” is one of these management buzzwords you have to use carefully. You should be very clear about what you commit on, what the appropriate tools to keep that commitment are, which tools are illegal, and what happens if you don’t keep the …
The question of whether an organization should build software or buy it dates to when the first significant COTS packages (typically for accounting, computer-aided design, or manufacturing resource planning) appeared on the market between 1970 and 1990. Search for “build vs. buy software” on Google, and you get 52 million results. Most of the results on the first pages are dated around 2001-2002, so one would think that the question has been settled, mostly along the following lines: If you need a capability that is fairly generic, and will not in itself give you a competitive advantage (the way you apply it may be superior to how others do it, but the software itself will not …
In 2011 we will see successful mechanical refactoring across service and organizational boundaries. Regretfully it will take nine more years for this to become a common agile practice. In a decade we will see terms of service expressed as automated tests. Service providers will occasionally revise these terms and their tests as they upgrade their services. They will NOT, however, be obligated to support an old interface indefinitely. Rather, they will be obligated to provide automated refactoring scripts that have been shown to mechanically upgrade a well-known public suite of sample applications in such a way that the new tests pass. Careful readers will notice that I’m equating testing a service interface and testing a …
Every agilist brings his or her history to the community—agile didn’t spring from the primordial soup in 2001. While we may argue against historical practices, waterfall for example, we owe something to earlier pioneers. So while I can’t speak for other agilists, I can give a snapshot of who influenced my thinking over the years.. First, I would argue that agilists were influenced more by practical than academic literature (see Craig Larman’s Agile & Iterative Development for some historical perspectives). Writers who influenced me go back to the early work of Tom DeMarco, Jerry Weinberg, Ken Orr, Jean Dominique Warnier, Larry Constantine, Steve McMenamin, Ed Yourdon, and others during the early “methodology” period from about …
Cutter recently conducted a survey of than 100 software development organizations to study how companies deal with maintenance and other software support issues. The survey, which was analyzed by Senior Consultant E.M (Elli) Bennatan, covered a broad range of organizations: 45% with fewer than 25 developers, 23% with between 25 and 100, and 32% with more than 100 developers (of those, 18% have more than 400). The survey also covered a fair mix of both small and larger projects: at 59% of surveyed companies, projects are typically small — fewer than 5 person-years; at 35%, they are between 5 and 20 person-years (of those, at 11%, they are between 11 and 20), while the remaining …
How much architecture does an agile team need up front? Most agile methods are surprisingly silent when it comes to this question. Scrum regards architecture as an issue the team has to deal with on its own discretion — and thus does not include any advice. In Crystal Clear: A Human-Powered Methodology for Small Teams, Cutter Senior Consultant Alistair Cockburn suggests having a lead designer who is responsible for creating the system architecture description — “usually fairly early in the first iteration” — but also emphasizes that “the architecture will probably evolve” and gives two strategies to help evolving: Walking Skeleton and Incremental Rearchitecture. XP finally suggests using a metaphor to keep up the technical …



Recent Comments