XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

The Ever-Expanding Agile and Lean Software Terminology

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

Distributed Standup Meetings: Spam or Ham?

Tuesday, September 8th, 2009

Distributed Stand-up meetings essentially becomes a lot of ceremony and the true value of communication, feedback, team bonding, working towards a common goal starts falling apart.

If you have done distributed stand up meetings you would have noticed that its not easy to communicate to a bunch of people on the other side of the phone. (Telephonic conversations are good when there is just one person on the other side. As the number of people on the other end of the phone starts increasing the quality of communication starts dropping).

Also if you have noticed, when a person does not know who is listening on the other side of the phone, they usually speak very little. May be they just talk about 2 out of the 3 things (What they worked on and what they plan to work on. They skip the learning/roadblocks part). I would argue that you can understand who is working on what by looking at the story wall (you don’t really need a stand-up for that). More on this @ Standup Meetings: Missing the Forest for a Tree.

People have tried using Video Conferencing and other techniques, but it usually falls short of encouraging and fostering true communication. It also leads to a lot of time wastage and ceremony (prep-time, getting to the video conferencing room or setting up the video conference tool on your machine). IMHO, its easy to get distracted when the person speaking is not in front of you. So your attention span starts reducing and if you have a team of 8-10 people, it would be difficult to comprehend and remember who said what.

So if Distributed Stand-up meetings as they stand are not the best options, what else can we do?

I have 2 suggestions:

1) Really light weight option: User a chat (conference) room. Everyone from the team shares their bits simultaneously and then people have a small chat to decide the game plan for the day. This has a nice side effect. These notes get naturally persisted in the chat history. So if someone misses the standup or if someone wants to go back and refer to some day’s standup notes, they have it accessible. Also creates a felling of async, non-blocking io (Remember the good old open source days, this is how we used to work).

2) Slightly more process centric: One-on-One Standing Meeting: Each location has their own stand-up meeting at beginning of their day (or what ever time is suitable for the local team). And then, when both teams are online, one member from each team will update the other team(s) about their progress and anything else which is important that might affect the other team(s).

Usually people think of this as a Scrum-of-Scrums where ScrumMasters from each team present their status. We don’t use ScrumMaster. Instead we make this a rotating responsibility of each team member.  Which means, one team member from each team will represent their team in the standing meeting in a round-robin fashion per day. Next day, the person who represented the team in the standing meeting, not only shares their progress with others, but also shares other team’s progress with the rest of the team. The next person in the queue then attends the next standing meeting. These meetings are usually very light weight and are done in 5-10 mins.

P.S: One pant does not fit everyone, find out what works for you and evolve from there.

Standup Meetings: Missing the Forest for a Tree

Wednesday, May 20th, 2009

I’ve seen some teams getting so caught up in answering the 3 questions of the stand-up meetings, that they even forget the objective behind the standup meeting.

Following are NOT the goals of a standup meeting:

  • Get in-sync or to know who is doing what & where they stand. 
    • That information can be achieved through the story-wall (virtual story-wall if you are using a Agile PM tool). If you are a team of 3-4 people and sitting next to each other, you’ll anyway have this information (you better).  
  • To identify impediments. 
    • Why wait till the standup meeting to identify something is blocking you. If you can’t solve something yourself, bring it up to others notice immediately. Don’t sit on it.
  • Status report. 
    • This is the worst goal you can have for standup meetings. We are moving away from micro-management. 
  • Communication to the chickens. 
    • Again they can look at the project status on the story-wall. Or they can stop by in the team room and talk to someone informally. We don’t need to have a meeting for them.
  • And so on…

IMHO the real goals of a standup meeting is

  • To come up with a Game Plan till the next standup meeting. 
    • Its an opportunity to inspect and adapt 
    • Helps in doing micro-re-prioritization 
    • Helps in keeping everyone on the same page as far as the goals/vision is concerned

If answering the 3 questions helps towards this goal, then go ahead. But don’t think of them as an end in themselves.

    Licensed under
Creative Commons License