`
| |
|
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 »
Tuesday, May 29th, 2012
How do you measure or know the effectiveness of a Scrum Master?
IMHO on a given team, in less than 6 months, an effective Scrum Master will:
- make themselves redundant
- make process second-nature for the team
That would be the true test for their effectiveness.
In the mean time, I would look for:
- Has the SM been able to win the team’s trust and build credibility with the team? Does the team see the SM as an integral part of the team?
- Apart from effectively facilitating (not enforcing) the Scrum ceremonies, is the SM helping the team understand the rationale behind those ceremonies?
- Is the SM creating a culture of safe-fail experimentation where the team can experiment, learn and grow beyond the standard Scrum ceremonies? If the team is not evolving their practices and work culture, is the SM really doing their job?
- Does the SM encourage System’s Thinking and uses techniques like Value Stream Maps, Five Whys, A3, etc. to identify & highlighting bottlenecks in the team?
- Has the SM been successful at creating Self-Organized Empowered Team? Or is the team waiting for directions from the SM?
- Is the SM able to emerge as a leaders and be the voice of the team, shielding the team from external interferences, yet creating a healthy collaborative culture?
- Is the SM able to motivate the team and steer them towards excellence?
- Is the SM abel to put a framework in place for the team to record and surface important and relevant data about the team’s performance? Using techniques like information radiators to build informative workspaces. Basically enabling the team to get food for improvement.
- Is the SM proactive (instead of reactive) about resolving issues?
- Is the SM approachable? Believes in servant-leadership?
- Does your SM have first-hand experience working in Scrum teams? Extremely knowledgeable about processes?
- Is the SM up-to-date with the latest trends in the industry? Keen learner and open-minded?
Posted in Agile, Coaching, Metrics, Organizational | No Comments »
Saturday, October 22nd, 2011
To be successful in an agile environment, IMHO team members need to learn the following skills:
- Embracing uncertainty/change and finding effective ways to deal with it.
- Tight collaboration and communication with everyone involved.
- Collective Ownership, Drive and Discipline to getting things done.
- Eliminating Wasting: Mercilessly looking for waste and trying to eradicate it.
- Fail-fast: Breaking a large problem down into small safe-fail experiments and then willing to try & learn quickly.
- Systems thinking: Understanding how things influence one another within a whole system and avoiding local optimizations.
- Critical thinking: Reasonable reflective thinking focused on deciding what to believe or do. In other words; thinking about thinking.
- Open to experimenting with radical ideas
It very important for people to understand that in an agile environment, “Action Precedes Clarity!“
Posted in Agile, Organizational | 2 Comments »
|
