`
| |
|
Sunday, July 8th, 2012
| A |
Acceptance Criteria/Test, Automation, A/B Testing, Adaptive Planning, Appreciative inquiry |
| B |
Backlog, Business Value, Burndown, Big Visible Charts, Behavior Driven Development, Bugs, Build Monkey, Big Design Up Front (BDUF) |
| C |
Continuous Integration, Continuous Deployment, Continuous Improvement, Celebration, Capacity Planning, Code Smells, Customer Development, Customer Collaboration, Code Coverage, Cyclomatic Complexity, Cycle Time, Collective Ownership, Cross functional Team, C3 (Complexity, Coverage and Churn), Critical Chain |
| D |
Definition of Done (DoD)/Doneness Criteria, Done Done, Daily Scrum, Deliverables, Dojos, Drum Buffer Rope |
| E |
Epic, Evolutionary Design, Energized Work, Exploratory Testing |
| F |
Flow, Fail-Fast, Feature Teams, Five Whys |
| G |
Grooming (Backlog) Meeting, Gemba |
| H |
Hungover Story |
| I |
Impediment, Iteration, Inspect and Adapt, Informative Workspace, Information radiator, Immunization test, IKIWISI (I’ll Know It When I See It) |
| J |
Just-in-time |
| K |
Kanban, Kaizen, Knowledge Workers |
| L |
Last responsible moment, Lead time, Lean Thinking |
| M |
Minimum Viable Product (MVP), Minimum Marketable Features, Mock Objects, Mistake Proofing, MOSCOW Priority, Mindfulness, Muda |
| N |
Non-functional Requirements, Non-value add |
| O |
Onsite customer, Opportunity Backlog, Organizational Transformation, Osmotic Communication |
| P |
Pivot, Product Discovery, Product Owner, Pair Programming, Planning Game, Potentially shippable product, Pull-based-planning, Predictability Paradox |
| Q |
Quality First, Queuing theory |
| R |
Refactoring, Retrospective, Reviews, Release Roadmap, Risk log, Root cause analysis |
| S |
Simplicity, Sprint, Story Points, Standup Meeting, Scrum Master, Sprint Backlog, Self-Organized Teams, Story Map, Sashimi, Sustainable pace, Set-based development, Service time, Spike, Stakeholder, Stop-the-line, Sprint Termination, Single Click Deploy, Systems Thinking, Single Minute Setup, Safe Fail Experimentation |
| T |
Technical Debt, Test Driven Development, Ten minute build, Theme, Tracer bullet, Task Board, Theory of Constraints, Throughput, Timeboxing, Testing Pyramid, Three-Sixty Review |
| U |
User Story, Unit Tests, Ubiquitous Language, User Centered Design |
| V |
Velocity, Value Stream Mapping, Vision Statement, Vanity metrics, Voice of the Customer, Visual controls |
| W |
Work in Progress (WIP), Whole Team, Working Software, War Room, Waste Elimination |
| X |
xUnit |
| Y |
YAGNI (You Aren’t Gonna Need It) |
| Z |
Zero Downtime Deployment, Zen Mind |
Posted in Agile | No Comments »
Saturday, September 5th, 2009
So, when it comes to using a tool for Story Wall (read it as Agile PM tools): My first reaction is, you don’t need them unless you have used physical story wall (task boards) enough that you understand their limitations and you want to evolve.
If you are a small, co-located team, it is just simpler to use a physical story wall backed with a wiki or a spreadsheet. As the team grows (smell something is wrong), you might want to break down the large team into smaller self-contained (cross-functional) teams and continue using the same practice at 2 levels.
- Team Level: Each team manages the user stories they are working on.
- Meta Level: At a meta level, we manage the features (epics) each team is working on.
This scales fairly well.
For distributed teams, I’ll use the following approach:
- Start using Physical Story wall at each location backed with a wiki or a spread sheet. How the story wall is used really depends on how the work is distributed across teams.
- If all the development and testing is taking placing in one location (offshore), then I would only use one story wall at that location.
- If development takes places in both location, I would duplicate the story wall on both sides and during the “one-on-one standing meeting” (not a distributed stand-up meeting, I don’t think they work), each side updates their story wall with updates from others side. This ensures both sides are really collaborating.
- And sometimes, teams can maintain their independent story walls and then sync up once a week.
- One needs to figure out what works best for their situations.
- Once the team understands and matures using this. Next step could be to do away with the physical story wall in each location and just use a Wiki or a Distributed SpreadSheet (something like GoogleDocs) to maintain their backlog and story wall.
- If you belong to an organization where everything has to be “enter-price” class, then I might consider one of the following tools:
- Mingle from ThoughtWorks
- Silver Catalyst
- Jira and GreenHopper
- VersionOne or Rally
- And so on…
You might ask, what about tracking, planning, project management dashboard (fancy charts: burn-downs) and so on. Well, IMHO a lot of it is hype. You don’t really need all of that. You need some of them and its simple to generate them without having to use a heavy weight tool that adds more complexity than it takes out.
At one point, I really wanted to try out a tool for distributed teams. There was nothing good available at that point (2004), so I wrote one myself using RoR. The tool was fine, but it was very difficult to get the same feel as real story wall. So I dropped the tool and went back to physical story wall (this was a distributed team).
Posted in Agile, Tools | 10 Comments »
|
