Agile
Articles
|
How Agile Practices Reduce Requirements Risks Requirements risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. As requirements expert and agile coach Ellen Gottesdiener explains, agile practice can go a long way in mitigating those risks. |
||
|
Principles for managing a Scrum-based Agile Program Agile project management philosophy, though not very different from the traditional management practices and framework, needs to be rationalized to suit the demands of the agile methodologies. The project management practice remains the same for requirements, planning, initiating and tracking the progress of the project in line with the business vision. However, the focus is more on adaptability towards changing requirements, team work, collaboration and the ability to plan and deliver small chunks of useable software in short intervals of time |
Anonymous
July 7, 2009 |
|
|
Timing Matters in Managing Change Implementing change can be a colossal challenge. People tend to prefer what's familiar, safe, and predictable to that which is new, unfamiliar, uncertain, confusing, or potentially risky. But the timing of a change effort can influence how readily people accept the change and adjust to it. |
||
|
Rocks into Gold: Part 1 This short book, written by Clarke Ching, is a "biztech" parable for software developers who want to survive—and then thrive—through the credit crunch. We have republished the book in a four-part series. In part one, we meet the main characters who have just found out that their jobs are on the line after discovering their major client's business is failing. Follow the story as our characters fight to keep their jobs by implementing creative business ideas and management skills taken from agile development. |
||
|
ScrumBut: Failure to Deliver In this article, Michele Sliger discusses one of the more common "ScrumBut" practices that, while allowing teams to say "We suck less," isn't really in keeping with intended Scrum practices. This ScrumBut practice is the persistent failure of the team to complete the agreed-upon features in the iteration or sprint. |
||
|
Distributed Agile Day to Day "Distributed" isn't a word that always has appeared favorably in works about agile methodology. After all, the proximity of agile team members while working is highly regarded. In this article, an excerpt of which originally appeared in the May 2009 Iterations eNewsletter, Chris McMahon takes a look at how "agile" and "distributed" can work together successfully. |
||
|
A Second Look at "Requirements Come Second" My article, "Requirements Come Second," in a recent issue of Agile Journal caused something of a fuss. The piece was picked up by several more sites and was widely commented on - both on websites and in my inbox. I'm not entirely surprised by this reaction, I've been discussing this research for a year or so now and often find it surprises people. Given this level of interest it is worth looking at how people responded. It is also worth restating the key message: Requirements are an essential part of maximizing business value, but when an organization is struggling with effectiveness it is best to start change by improving delivery. |
||
|
Feature Injection: Part One We are leaving the "last responsible moment" for a while. This month we start a discussion of Feature Injection, an analysis process based on real options and Kolb's circle of learning. The first episode ( of five ) introduces the "Information Arrival Processes. |
||
 |
Ending Right Jeff Patton has been building software using the agile approach for a while now. His observations of how others are implementing agile development fall short of complete, but he has noticed is that the adoption breaks down during the evaluation phase. In this column, Jeff goes through the agile development process and offers guidance on the correct way of conducting an agile evaluation during this phase in the software development lifecycle. |
|
|
Are You a Good Listener? Some people freely admit that they're not good listeners. But many who claim to be good listeners aren't. That's because they fall short in a critical aspect of listening. In this week's column, Naomi Karten offers ideas and examples that will help you be-and be perceived as-a good listener. |
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
StickyMinds is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.