Indeed, agile requirements drive identifying and delivering value during agile planning, development, and delivery.
Planning: Agile teams base product requirements on business value, and they define requirements to deliver that value. Planning covers not only the "now-view" (the current iteration) but also the "pre-view" (the release) and the "big-view" (the vision and product roadmap), with close attention to nonfunctional as well as functional requirements.
Customers drive agile planning, constantly reprioritizing requirements and evaluating risks and dependencies. The delivery team works ahead, preparing requirements for delivery.
Developing: An agile team's work is based on building concise, fine-grained requirements (typically captured as user stories). The team may also sketch organic data models, state diagrams, and interface mockups. These are like micro-specifications, with clear conditions of satisfaction; the team knows enough to estimate, develop, test, and demonstrate the requirements.
Agile teams accelerate requirements validation by developing user acceptance tests as they explore requirements.
Delivering: Requirements are built and released based on the team's clear understanding of requirements dependencies, which also drive architecture trade-off decisions. Smart agile teams analyze development and delivery dependencies to optimize value.
Far from being an oxymoron, agile requirements practices drive planning, development, and delivery of requirements.
» View Ellen's Presentation
» Read more of Ellen's articles on Requirements
When It Just Has to Work (Presentation by Nancy Van Schooenderwoert & Brian Shoemaker)|
When It Just Has to Work: Agile in Safety-Critical Environments
by Nancy Van Schooenderwoert
A pervasive view holds that software quality vs. development speed is a tradeoff . . . doubly so for safety-critical applications. But this idea is false.
A significant number of medical device recalls are for software issues: not just outright defects but also usability considerations (misuse can be just as dangerous as direct failure). As application complexity grows, these issues grow with it.
The Lean-Agile Solution
Many claim the solution is ever more rigorous stepwise development. However, we believe a different lifecycle is needed; one that is incremental and transparent. One in which teams deliver vertical slices of product functionality across hardware and software using techniques that find defects faster than they are injected.
Most traditional software teams spend at least one-third of their time on defect removal. Lean-Agile teams spend negligible time on this activity, and a clean code base is a safer code base. This breaks the trade-off between speed and quality.
Addressing Risks and Hazards
Traditional methods like fault tree analysis are even more effective when automated tests are added to continually stand guard against hazards. A serious problem in safety-critical development is inadvertently defeating a hazard mitigation when making changes to the code base. Traditional teams tend to only conduct hazard analysis and design their mitigations at the beginning of development. Lean-Agile teams recheck mitigations automatically throughout the project using their automated test framework.
Auditable Documentation Trails
Traditional teams often find that "sufficient" documentation quickly becomes information overload. Text documents just don't scale well. Lean-Agile teams govern their work with artifacts like unit tests, checklists and release plans that serve double-duty as an audit trail. They not only scale, but are kept in synch with the work.
Lean-Agile provides us a way to have both quality and speed, even in safety-critical environments.
» View Nancy & Brian's Presentation
» Learn more about agile teams' lower defect rates in "Embedded Agile Projects by the Numbers"
Using Social Media to Promote Thought Leadership (Presentation)|
The first three weeks I honestly struggled to continue, to make sense of why anyone would want to use such a ridiculous tool. In week four, however, I discovered something that's stuck with me ever since. Your experience on Twitter is totally up to you. The people you follow define the conversations you are privy to, the learning that takes place and the experiences you have.
Embracing Twitter: A CTO Gone Social
by John Moore
I have a confession to make. I'm a geek as well as a believer in the power of social media. As the CTO of a small consultancy, I was a skeptic about the power of tools like Twitter. While blogging was a natural fit for me, typing 140 character thoughts while navigating through the noise of people blowing their own horns did not appeal to me. However, as a technologist I was intrigued and so I decided to try it for a month.
Getting Started with Twitter
Here are a few tips to get you started:
Use a Twitter client like Tweetdeck or Hootsuite to improve your experience. They have advanced features to help you stay on top of conversations, follow lists, and find and share information.
Share your own content.
Try to keep your tweets primarily (80+%) industry related, 10% personal, and (if appropriate) 10% self-marketing.
Twitter is not for everyone. However, if you don't give it a chance you'll never know if it was right for you.
» View John's Presentation
» Read more of John's thoughts on social media