Presenters: Cherifa Mansoura, Bhawana Gupta, Kurt Solarte – All IBM
Disclaimer
What follows is my interpretation and reporting of the presentation. I may have misunderstood things, but I probably didn’t. Still, this is my opinions along with actual facts. Keep in mind.
This session will focus on Agile with DAD (Disciplined Agile Delivery)
They start off by saying that it’s impossible to know all requirements up front, and that even users don’t know what they want until they see it.
They show the project triangle – scope, time, and cost.
In Structured requirements, the idea is to do Big Requirements Up Front (BRUF) approach.
In the room next door, someone is playing LOUD electric guitar music. Seeing as how this is being held in a huge open room (Southern Hemisphere I) it’s a big distraction.
Back to the triangle, Scope = value. Accept that not ‘all’ will be done and then prioritize.
They say to consider an agile approach. They say that it’s best if agile is tested on a project first.
Prioritization of requirements (the backlog) is ongoing. This will allow the concept of “velocity” and “done”, both items that don’t exist in a traditional waterfall approach.
So I’m digesting this all and I think it’s good, for software projects. If the software needs to run on custom hardware/interfaces, I can’t see this being as useful. It’s easy to iterate on software, but hardware is much more challenging.
They say that going Agile gets people out of their silos and more into a whole team approach.
Agile way of defining requirements
Initial requirements are very high level. The goal of the requirements envisioning is to identify the high-level requirements as well as the scope of the release. In other words, what you think the system should do.
Prioritization should be based on value delivered to stakeholders.
So how to do this?
User Stories
Stories are short, simple descriptions of a feature told from the perspective of the person who desires the feature. Stories should be able to fit into a single iteration. If it can’t be, then break it down.
Epics should be used to collect related stories (helps organize) and as a placeholder for functionality/group of stories where the work hasn’t been clarified.
There is a card, conversation, and confirmation. Card is the need. Conversation is information gathering, and confirmation is a test.
So why not use cases instead? Bhawana asked this question but I am not sure she answered it.
Where do User Stories fit in? (There’s a pyramid shown, with Epics at the top, Features at the middle, and Stories at the bottom) User Stories are implemented by tasks. Epics span releases and Features Fit in Releases.
Common Pitfalls with Agile Requirements
- Major challenges with attitude over new language
- Getting team on the same page, using new terms
- Major challenges with requirements and details
- context
- upfront business commitments
- backlog items don’t fit into stories
- aside from user stories, other ways to represent needs?
- what are the business rules
- what about my quality of services (NFR)
- where do I track other constraints
- Major challenges with stories
- user vs. system story
- finding epics and stories from process models
- who is in charge of discovering stories?
Adopt SEVEN Habits
1. Establish Context and Scope
i. everything is a requirement
ii. consider scaling factors
iii. consider all work that needs to be done (defects, change requests, etc.)
iv. take all work into account when creating backlog
* Functional Requriements - Stories.
* Non Functional Requirements, business rules - Stories and/or acceptance criteria
* May be able to pull the above into the user stories.
* Create a backlog with context (this would have requirements, defects, tasks, all shown in one place -- so all is seen and considered)
* Create TECH stories for non-user facing stuff.
2. Focus on Business Value
3. Prioritize (based on Business Value At The Time)
* Kurt is a firm believer of ranking everything. You cannot have two #1 priorities. Kurt obviously hasn't worked for any of my clients! ;)
4. Elaborate requirements progressively
* This slide was illegible. It had a graphic on it with lots of small fonts. Break this up into multiple slides. As a result of this, I could not follow this portion of the presentation. I have no idea what the Bhawana was talking about.
* She summed it up as "growing details over time."
* Obtain "just enough detail" when needed. Apply "just barely enough" practice. The idea is to evolve and improve over time.
Note: I am not sure about this. I have seen environments where just barely good enough is where things stay.
* Testing is always occurring.
* If time is running out, or scope is extending, reevaluate.
At this point, Kurt showed an user story and how it was developed using Agile.
5. Collaborate, Communicate
* Communicate anytime, anywhere.
* Try not to create/support a task-based culture where work isn't collaborative. Support a value-based culture.
In general I agree with the above bullet. However, like in school, sometimes there are strong members of the team and sometimes weak members of the team who will refuse to grow. Pairing a strong person with a difficult weak person will only cause the performance of the strong person to degrade. Remember those group projects in college? Management is key here, because you want weak people who are able to grow.
6. Focus on quality
* This is essentially built into the process.
7. Manage
* Use the product backlog
* Manage, not control
* Do not undermine self-organization
* Involve the teams
* Define effective "doneness" criteria
* Checklists can help
* Use Metrics to track team progress
There were quite a few RTC screenshots shown throughout.
My Thoughts
This is the best presentation I’ve been to so far. Liberal use of screenshots with actual details shown. The presenters really knew their stuff and really put work in. This was a very subtle advertisement for RRC, RTC, and RQM, and it was very effective. I don’t believe Agile is best for every project, but perhaps for pieces of projects it’s good. I like the idea of focusing on getting stuff done. I think it has the ability for engineers to take pride in their work. This is a great presentation that attendees should seek out online if they couldn’t attend in person.